LINUX.ORG.RU

Glibc удаляет поддержку архитектуры IA64

 , , ,


0

2

Glibc, основная системная библиотека для *nix-систем, прекращает поддержку архитектуры IA64. Коммит прислал главный разработчик Ульрих Дреппер (Ulrich Drepper), ранее высказавшийся в списке рассылки о практической смерти IA64 и предложил желающим энтузиастам поддерживать IA64 самостоятельно.

На данный момент это решение кажется необоснованным. Считается, что Itanium почти целиком вытеснен PowerPC, однако Intel все еще продолжает активную разработку IA64, а HP использует ее в собственных операционных системах HP-UX и OpenVMS, к тому же, Huawei и Inspur в апреле прошлого года приняли решение использовать процессоры Itanium в серверах собственной сборки.

Нелишне также напомнить что Ульрих Дреппер (Ulrich Drepper) не единожды был критикуем сообществом свободного ПО. Так, многие помнят решение о переходе Debian на Eglibc, состоявшееся, в том числе, из-за нежелания работать с Ульрихом в дальнейшем.

>>> Коммит

★★★★★

Проверено: Shaman007 ()

Какая из стандартных библиотек лучше?

sgasgar ()
Ответ на: комментарий от no-dashi

Если ты обычный человек - нехрен лезть в разборки специалистов, поскольку ты не понимаешь, о чем идет речь.

когда я начинаю страдать из-за разборок этих специалистов - вот тогда я и начинаю вмешиваться. Я спрашиваю: вот вам делать нечего, что вы полезли менять рабочую реализацию? Если бы с этой реализацией были проблемы, если бы она не работала правильно, если бы все на неё жаловались - тогда было бы понятно, с какой целью сломался мой кривой код.

Можно ведь много чего поломать просто ради принципа. И сидеть с разбитой системой, в которой нихрена не работает, зато всё правильно. См. некоторые GNU проекты.

Лично я вообще этот случай рассматриваю как косяк дистростроителей. Авторы glibc были вправе менять реализацию как хотят, а вот то, что это выплыло к юзерам - это действительно вопрос.

deadman ★★ ()
Ответ на: комментарий от anonymous

glibc везде один. eglibc с ним бинарно совместим.

Deleted ()
Ответ на: комментарий от geekless

Как ты докатился до того, что обычная пользовательская программа может снести корневой раздел?

Deleted ()
Ответ на: комментарий от AGUtilities

о_О

Выбрасывать IA64 - это стандарт?

Deleted ()
Ответ на: комментарий от Zombieff

man IBM POWER

Стоит еще в PS3 и нескольких сериях ынтырпрайз-серверов IBM.

Deleted ()
Ответ на: комментарий от Quasar

Наверно среди разработчиков glibc есть пользователи Alpha.

Сомневаюсь. Скорее всего, дело в том что наш дорогой Ульрих вдруг решил, что он такой мягкий и пушистый выполняет работу за инженеров HP. И вместо того чтобы поднять трубку и сделать пару звонков своим «коллегам», решил действовать другим путем и преподнес прекрасный новогодний подарочек им, и еще сотне своих «коллег» по всему земному шару.

Macil ★★★★★ ()
Ответ на: комментарий от true_admin

Кто свои поделки не прогонят через valgrind тот осёл.

Не все так однозначно. Поделки с гуем при прогоне через valgrind очень-очень сильно тормозят. А представь, как через него прогонять флеш...

Deleted ()
Ответ на: комментарий от matumba

Долой x86 из поддержки. Только x86-64, только хардкор. Кому-то мешает IA64, чем конкретно он усложняет разработку по сравнению с другими архитектурами? Факт в том, что железо ещё есть, оно будет дальше выпускаться и glibc было бы совсем не лишним его поддерживать.

zink ★★ ()
Ответ на: комментарий от Deleted

Леннарт создавая ломает всё вокруг. SystemD и PulseAudio кривые? Хорошо, давайте уберём директорию /usr/ . Текстовые логи это скучно и старо? Давайте запилим бинарный блобообразный формат логов, который будем открывать отдельной софтиной.

Проблема Леннарта в том, что он чинить то, что и без него работает и вместо того чтобы клепать рабочие и годные поделки пытается поставить остальную систему на костыли лишь бы самому ничего не делать.

zink ★★ ()

Сегодня вроде не 1 апреля...

anonymous ()

Ну что сказать. Ульриху действительно обидно, что инженеры HP и Intel не выделают денег/раб. силы на поддержку. И вместо того чтобы об этом открыто сказать он решил намекнуть. Как жаль, что вы не хотите поделиться с нами доходами. Будет очень жаль, если с поддержкой вашего процессора что-то случится. Впрочем по вышеупомянутому треду с багом и так понятно, что общаться с людьми и выражать свои мысли ему очень трудно.

zink ★★ ()
Ответ на: комментарий от Quasar

На серверах и менйфреймах POWER, а не PowerPC.

Да, это я ошибся. Но там же ISA почти одинаковые.

tailgunner ★★★★★ ()
Ответ на: комментарий от Deleted

Поделки с гуем при прогоне через valgrind очень-очень сильно тормозят.

Гуй тестить отдельно, либы отдельно.

Конечно оно тормозит, кто спорит, но процесс тестирования должен быть автоматизирован. Запустил на билд-сервере тесты, а в это время пишешь дальше. Никто же не требует запускать тесты на каждый коммит (хотя бывает и такое).

Потом есть куча разных либ которые дебажат такие вот мелкие функции работы с памятью, они дают горздо меньше оверхеда. Но они не отлавливают многих других ошибок в отличие от валгринд.

true_admin ★★★★★ ()
Ответ на: комментарий от geekless

Я тебе пример привёл к чему ведёт использование костылей и workaround-driven development, а ты сразу штампы навешивать.

Я вижу ты особый любитель кривого софта.

Кстати, ты сам-то код на сях писал или так, языком почесать любишь о том чего не знаешь?

true_admin ★★★★★ ()
Ответ на: комментарий от Quasar

И модель разработки под оффтопик совсем иная: софт неимоверно быстро устаревает, из-за чего быдлокодеры уже считают обычным делом переписывание софтины с нуля
В линуксе софт переписывают с нуля гораздо чаще. Известные примеры — kde, gnome, grub, qutim, etc. Закономерный вывод — в линуксе быдлокодеров, пишущих некачественный код, больше.

wintrolls ☆☆ ()
Ответ на: комментарий от true_admin

gui нельзя протестировать автоматически. тесты проверят только ядро программы, но проблема может быть и при взаимодействии ядра с гуем. в некоторых особенно тяжелых случах приходится таки запускать целую программу под valgrind'ом

Reset ★★★★★ ()
Ответ на: комментарий от Macil

Не совсем удачный пример.

Как скажешь

В новых поколениях уже будет ARM.

А в текущих - PowerPC.

tailgunner ★★★★★ ()
Ответ на: комментарий от true_admin

Я тебе пример привёл к чему ведёт использование костылей и workaround-driven development, а ты сразу штампы навешивать.

Я вижу ты особый любитель кривого софта.

Выйди уже из состояния автотроллинга и осознай, что я уже 3-е или 4-е сообщение подряд пытаюсь тебе намекнуть (да что там намекнуть, прямым текстом сказать), что твои аргументы относятся к чему-то другому, но не к нашему предмету разговора.

Если ты всё еще не видишь логических нестыковок в собственных рассуждениях, я уже ничем не могу помочь.

Кстати, ты сам-то код на сях писал или так, языком почесать любишь о том чего не знаешь?

Писал. Дальше что?

geekless ★★ ()
Ответ на: комментарий от Quasar

У меня есть подозрение, что они работают в очновном на чпуксах и чпуксы на линукс там менять никто не собирается

У меня есть подозрение, что на i386 в основном работает сам знаешь что.

Я не исключаю, что есть определённая доля итаников, которые на линуксах крутятся.

Есть, сам видел.
Проблема в том, что выкинуть ее хочет один чудак, с ЧСВ овер 9000. По причине - не нужно.

kostian ★★★★☆ ()
Ответ на: комментарий от matumba

итаник вполне жив, и интел собирается его продавать и дальше. Конечно, линукс не конкурент чпуксу и опенвмс, но при таких странных подходах со стороны редхат он вообще сольется в роутеры.

anonymous ()
Ответ на: комментарий от zink

Необоснованные обвинения. Pulseaudio - нужен как минимум как единственная адекватная гонялка звука по сети. Systemd - нужен, т.к. быстр и функционален. Насчет логов - хз, не смотрел.

Все, кроме логов, вполне юниксвейно и правильно. Разве нет? А с логами его я просто не знаком.

Deleted ()
Ответ на: комментарий от Ttt

Для этого не обязательно программировать.

Возможно. Однако речь идёт о поддержке определенной архитуктуры и тут уж нужно быть в курсе о стоимости этой поддержке (речь идет не о деньгах).

alex-w ★★★★★ ()
Ответ на: комментарий от Ttt

Борется за корректность кода

Предлагает использовать 3rd-party бинарные патчи

Просто уйди.

Lighting ★★★★★ ()
Ответ на: комментарий от Deleted

uclibc

Для нее уже можно собрать NFS?

Юзаю на arm платке builroot'овский корень с NFS сервером

Т.е., RPC там таки работает? Значит, моя инфа устарела.

Этот обмен мнениями двух экспертов просто прекрасне, сцуко.

tailgunner ★★★★★ ()
Ответ на: комментарий от Deleted

Я сказал что PA не нужен? Я сказал что он крив и вместо фикса багов Леннарт пытается прогнуть всю систему наизнанку. SystemD не понимает /usr/ вынесенный на другой раздел — давайте тогда выпилим /usr

zink ★★ ()
Ответ на: комментарий от geekless

закладывать в программу код для детектирования попыток использования UB и бить за это по рукам линейкой

Угу. А в микроволновку закладывать биодетектор в обязательном порядке. А в автомобиль детектор паров алкогодя... и пофиг на стоимость.

Любой лишний код — это компьютерное время. Хотя разработчики GTK, видимо с тобой согласны, тип каждой переменной проверяется при каждом вызове любой функции GTK/GLib.

А насчет того, что может делать UB: на MacOS6 последовательностью NewObject, KillObject, KillObject (фактически, повторный free) я однажды убил систему. Запустил, на вопрос отладчика дважды нажал «продолжить». После этого всё упало и пришлось восстанавливать ОС.

А вариант закладываться на быдлокодеров глупо. В первых версиях Windows (95/98) можно было обратиться к памяти после free. В SimCity это использовалось (скорей всего, ошибочно). Потом MS сделала специальный патч, который смотрел имя процесса и для simcity.exe делал free вида void free() {}. Но никто ведь не считал, что надо убрать защиту памяти вообще ради разработчиков SimСity.

monk ★★★★★ ()
Ответ на: комментарий от alex-w

Остальные архитектуры же как-то и зачем-то поддерживают. А тут собираются выпилить поддержку вполне живой архитектуры. Я бы ещё понял, если бы предлагающий был бы единоличным автором всего порта glibc под IA64, написал всё с нуля, писал, писал, устал и сказал «ну в топку, мне надоело». Но ведь нет, есть ещё как бы и остальное комьюнити и кому-то даже эта самая поддержка нужна, но ведь есть те кому «виднее».

zink ★★ ()
Ответ на: комментарий от zink

systemd требует libdbus, который по FHS должен лежать в /usr/lib. Ты (как и дистростроители) свободен поместить его в /lib и тогда systemd будет работать и с отдельным /usr. Здесь не systemd виноват, а дистростроители и FHS.

Deleted ()
Ответ на: комментарий от zink

Я сказал что он крив и вместо фикса багов Леннарт пытается прогнуть всю систему наизнанку.

Пруф или не было?

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.