LINUX.ORG.RU

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

 drepper, , ,


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 ()
Последнее исправление: AP (всего исправлений: 2)

Ответ на: комментарий от stack_protector

Заставляя быдлокодера обращать внимание на undefined behavior. Один раз разработчики из adobe напоролись на такую проблему — в следующий раз будут внимательнее читать маны (или что там у них в винде)

Хм... Я думал, он для людей хотел что-то полезное сделать, а он всего лишь мелким пакостником оказался

deis
()
Ответ на: комментарий от stack_protector

Сохранение обратной совместимости с быдлокодом — это именно поощрение плохого стиля программирования.

Сохранение обратной совместимости подъездов и улиц с инвалидами — это именно поощрение людей становиться инвалидами.

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

Ну мы же соревнуемся в бредовых высказываниях, разве нет?

geekless ★★
()

Хорошее решение под лозунгом «Долой некрофилию!».

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

Так что Дреппер — мужик

Кто знает :(

Однажды Линус ныл, что у него какая-то софтина вызывает getconf с огромной частотой и говорил, чтобы Ульрих не парсил каждый раз то ли /proc то ли /sys, а кешировал результат хотя бы на секунду. Ульрих вроде стоял на своём. Но потом внезапно в репозитории появился его, Ульриха, коммит, добавляющий такое кеширование.

pv4 ★★
()

Считается, что Itanium почти целиком вытеснен PowerPC

Это кем считается? 0_о

PowerPC вообще хоть где-то кроме мелкософтовского X-box стоит?

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

У людей нет выбора, быть или нет инвалидами. А чтобы писать небыдлокод, нужно в данном случае всего лишь один раз заглянуть в документацию по библиотеке. А для правки уже написанного — один раз автоматически произвести замену одного слова и пересобрать.

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

PowerPC вообще хоть где-то кроме мелкософтовского X-box стоит?

В серверах и мэйнфреймах IBM. И во встроенных системах.

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

По-моему, как раз проприетарщики так говорят. Ну кто их просил пользоваться недокументированными возможностями. Это всё равно что, как некоторые делают, чистить чайник от накипи кока-колой. А потом, если кислотность кока-колы понизится, возмущаться, почему её испортили.

Какой далеко идущий вывод, однако.

Ты код адобеплеера видел? И я не видел. И программиста того мы не знаем. Может он 10 лет назад опечатался в одном месте от усталости в конце рабочего дня, а может тот код, где был баг, когда-то вообще не предполагал работу с перекрывающимися участками. Кто в этом виноват? Да никто не виноват. Самое главное: всё все эти годы прекрасно работало, и не было никаких причин думать, что оно работает неправильно. Потому что glibc не выдаёт никакой диагностики о наличии UB. А потом оно сломалось.

Если уж свербит найти виновного, то гораздо больше на эту роль подходит не тот неведомый программист, а вполне известный программист, закоммитивший в glibc. Потому что, еще раз повторяю, glibc не имеет диагностики UB, она не сыпала в логи ворнинги «тут UB, исправь код!», и у того программиста не было возможности выявить проблему.

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

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

А чтобы исправить проблему сразу везде, достаточно добавить 1 строку прямо в код glibc, ага.

Все такие умные когда надо исправить чужой быдлокод, но почему-то никто не хочет править собственный.

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

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

Смешно смотреть как домохозяйки рассуждают о разработке. :)

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

еще раз повторяю, glibc не имеет диагностики UB, она не сыпала в логи ворнинги «тут UB, исправь код!», и у того программиста не было возможности выявить проблему.

LOL. Еще одна кухарка учит разрабатывать. :)

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

Ты код адобеплеера видел? И я не видел. И программиста того мы не знаем. Может он 10 лет назад опечатался в одном месте от усталости в конце рабочего дня, а может тот код, где был баг, когда-то вообще не предполагал работу с перекрывающимися участками. Кто в этом виноват? Да никто не виноват.

А что, у adobe нет исходников флешплеера? Есть. А что, им трудно заменить memcpy на memmove? Это тривиальная задача.

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

А чтобы исправить проблему сразу везде

кроме флеша ещё назовёшь проги которые завязаны на нестандартном поведении memcpy?

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

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

Потому что glibc не выдаёт никакой диагностики о наличии UB

А может, это сделано намеренно, иначе будет отъедаться много ресурсов? А поскольку это достаточно низкоуровневая функция, то программист должен прочитать документацию по ней, где чёрным по белому написано, что участки не должны пересекаться. А для пересекающихся сделали memmove.

А «сломали», как я понял, из-за того, что новая реализация должна работать быстрее.

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

PowerPC вообще хоть где-то кроме мелкософтовского X-box стоит?

Архитектура применяется дофига где. Даже в приставках PS3, Wii :) Унылый интел - это профлый век. Правильно выпилили.

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

Даже домохозяйке будет понятно, что, если написано, что так делать нельзя, то, нарушая это, ты делаешь это на свой страх и риск. И сам будешь виноват, если в результате будет что не так.

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

LOL. Еще одна кухарка учит разрабатывать. :)

Рад, что ты верно оцениваешь свои навыки. А теперь живо на кухню, женщина.

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

Выкинули два года назад же.

Windows Server 2008 поддержка есть, ничего новее не существует.

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

А что, у adobe нет исходников флешплеера? Есть. А что, им трудно заменить memcpy на memmove? Это тривиальная задача.

А что, не заменили до сих пор? Я без понятия.

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

кроме флеша ещё назовёшь проги которые завязаны на нестандартном поведении memcpy?

А ты готов составить исцерпывающий список прог, которые точно не завязаны? Неужели, не готов?

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

Если уж свербит найти виновного, то гораздо больше на эту роль подходит не тот неведомый программист, а вполне известный программист, закоммитивший в glibc

А вот хрен там. С точки зрения формальной логики, то достопамятное ломание и фикс в glibc/memcpy явллся абсолютно валидным. Потому, что логика функции на всем множестве правильных исходных значений была абсолютно правильной. UB означает «всё что угодно, от 'всё правильно скопировалось' и вплоть до segmentation fault». И это именно задача прикладного программиста - избегать UB если оно явно упомянутое в документации.

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

А ты готов составить исцерпывающий список прог, которые точно не завязаны?

Следуя дальше твоей логике надо вообще libc весь переписывать и вставлять проверки на каждый чих. И почему только libc? Все остальные либы тоже, а то вдруг что-то там навернётся.

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

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

А может, это сделано намеренно, иначе будет отъедаться много ресурсов?

Доо, несколько cmp и j** — съедают ну просто ОЧЕНЬ МНОГО ресурсов. Каникулы — время невероятных открытий на ЛОРе.

программист должен прочитать документацию по ней, где чёрным по белому написано, что участки не должны пересекаться

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

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

Доо, несколько cmp и j** — съедают ну просто ОЧЕНЬ МНОГО ресурсов.

Если memcpy вызывается очень часто, до да, может быть заметно.

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

Ну так если не уверен, что участки не будут пересекаться, почему нельзя использовать memmove?

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

Сам ты домохозяйка. Обоснуй, где я в этой фразе что неправильно сказал.

Ты явно не представляешь, что такое коммерческая разработка больших проектов. Но при этом спешишь высказать своё авторитетное мнение по этому поводу. Делать мне больше нечего, кроме как доказывать что-то таким агрессивным дилетантам как ты.

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

LOL. Еще одна кухарка учит разрабатывать. :)

Рад, что ты верно оцениваешь свои навыки. А теперь живо на кухню, женщина.

Ухожу-ухожу. А вы продолжайте, я потом почитаю. :)

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

Видишь ли, диванный теоретик [...] Если вызывающая сторона нарушает контракт вызова, то об этом следует четко, внятно и исчерпывающе сообщить в процессе работы программы

И эти люди называют других «диванными теоретиками» :/

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

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

Переписывать — это что из области юных пионеров. Вот дописывать — да, кое-где надо. При чем, большая часть дописывания сведётся к проверкам на NULL. Всё остальное — ­редкие случаи типа этого memcpy.

И почему только libc? Все остальные либы тоже, а то вдруг что-то там навернётся.

Не все, но многие.

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

Пионерией только ты занимаешься, выдавая подобные реплики. Желаю тебе побольше подобных ситуаций, «когда что-то сегфолтится» без каких-либо логов, с танцами вокруг коры дохлого процесса. Исключительно с благими целями: чтобы поумнел.

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

Ну так если не уверен, что участки не будут пересекаться, почему нельзя использовать memmove?

Ты безнадежен. Иксренне надеюсь, что ты не программист.

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

Ты явно не представляешь, что такое коммерческая разработка больших проектов.

И что там такого, что даёт право писать кривой код, лишь бы он работал на компьютере, на котором тестируется? Тем более в нашем случае не допускать кривизну было легко: не уверен, что участки не будут пересекаться — используй memmove. Хуже не будет. И исправить тоже легко, если даже третьи лица в бинарниках, не имея исходников исправили.

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

Людей которые специально закладывают в свои программы использование недокументированных фич ничем не вылечить. И тех кто их защищает тоже.

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

Если уж свербит найти виновного, то гораздо больше на эту роль подходит не тот неведомый программист, а вполне известный программист, закоммитивший в glibc

А вот хрен там. С точки зрения формальной логики, то достопамятное ломание и фикс в glibc/memcpy явллся абсолютно валидным. Потому, что логика функции на всем множестве правильных исходных значений была абсолютно правильной.

А с точки зрения логики обычного человека - ну вот нафига трогать абсолютно рабочий код, проблем не вызывающий на гарантированно ломающий флеш и потенциально неизвестное количество быдлокода?

Скорости ему захотелось.. Линус правильно спросил - где она, эта скорость? И внятного ответа так и не было... Зато всё сделано «правильно»...

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

Да объясните же мне наконец, что я не так говорю? По-моему, всё очевидно, даже не программисту. Есть memcpy и memmove. Множество задач, выполняемых memcpy, входит в множество задач, выполняемых memmove. Но memcpy имеет определённые требования к входным данным. Не уверен, что можешь выполнить эти ограничения — используй memmove. Где ошибка в моих суждениях?

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

Людей которые специально закладывают в свои программы использование недокументированных фич ничем не вылечить. И тех кто их защищает тоже.

Интересно, что ты сказал это в ответ человеку, который вам, идиотам, уже 2 часа пытается объяснить, что есть такое правило хорошего тона: закладывать в программу код для детектирования попыток использования UB и бить за это по рукам линейкой. Скажи, ты уверен, что трезв, пребываешь в здравом уме и адекватно воспринимаешь действительность?

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

И что там такого, что даёт право писать кривой код, лишь бы он работал на компьютере, на котором тестируется?

И много у тебя компьютеров, отличных от того, под который ты пишешь? И что, подо все комбинации всего подряд тестируешь? И весь зоопарк линуксовых дистрибутивов? Все версии?

Чтобы код был портируемым реально, его надо реально тестить, а без этого будешь огребать проблемы там, где даже не ждёшь.

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

ну хорошо
если допустима ошибка, но требуется быстродействие
как должна быть написана системная либа, с которой работает весь софт?
или по либе на каждую программу?

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

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

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

И эти люди называют других «диванными теоретиками»

Я нипадеццки прусь с Улриха: как пукнет — сразу внеплановая дисциплина Специальной Олимпиады. Талант, млин!

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