Вот я и докатился - 2 (c)

Да. Это тенденция, какой-то общий шаблон в мире Линукса уже давно. Звук, шину сообщений, систему инициализации и оконную систему «чинили» этим же методом.

Поясните, я чего-то как говорится ни х(рена) не понял.

Чтобы не сломать совместимость из-за замены на 64-битный формат или еще какой костыль они решили совсем все сломать и прибить программы гвоздями к systemd там где было бы достаточно слегка пропатчить и перекомпилировать?!

Это они с каких веществ так упоролись или я чего-то неправильно понимаю?

React OS .... // И мерзко захихикал.

Всё правильно понимаете)

При чем в 2038-м году всему 32-битному ABI-совместимому с текущей версией glibc юзерленду в любом случае настанет конец. Время считать правильно такие программы больше не смогут, а значит отвалится всё, что завязано с SSL и другими криптографическими и сетевыми задачами. То есть в практическом отношении система становится бесполезна.

Ну и вообще если в 2038-м году кому-то потребуется гонять 32-битный юзерленд, совместимый с glibc из 00-х, то у этих людей проблемы посерьёзнее проблемы дат. Это будет какое-то дремучее легаси на предприятиях типа заводов и фабрик.

Поэтому можно смело делать utmp несовместимым и выпускать glibc с инкрементированной версией soname. Дополнительные проблемы по ссылке высосаны из пальца.

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

Не было никаких косяков. В 70-е годы, скорее всего, косяком бы (неоптимальным впопытке решить ненужное) сочли решения с 64-битным time_t Сюда же и 4-х байтный IP адрес - могли бы сразу например 8 байтный сделать и проблемы исчерпания не стояло бы, но была бы в 70-80-е проблема объяснить на кой хрен это надо.

Ну и вообще если в 2038-м году кому-то потребуется гонять 32-битный юзерленд, совместимый с glibc из 00-х, то у этих людей проблемы посерьёзнее проблемы дат. Это будет какое-то дремучее легаси на предприятиях типа заводов и фабрик.

Промоборудование такая вещь, что может работать 10-летиями и даже 100 летиями. Как говорится, зачем менять, если все устраивает? Видел на ютубе ролик, показывали на каком-то предприятии и сейчас работающий обдирочный станок выпуска примерно 1900-го года плюс/минус. Все довольны, работает получше многих новых.

Выпустят приказ считать 1970-й год за 2038-й =)

Oniguruma лучше! :)

В связи с тем, что в GNUтой экосистеме уже практически окончательно закончились программисты.

В FreeBSD они тоже закончились. Старых выгнали молодые ради diversity, и теперь там никого нет.

То есть неспособность к масштабированию это не косяк? Ты жеследующим сообщением написал совершенно обратное про станки. Весеннее обострение?

Прямо как про X11 vs Wayland. Сломать например механизм захвата ввода или древний алгоритм растеризации/вывода шрифтов боятся, а всё сломать и выкатить недовелосипед не боятся.

Тоже вариант. Можно считать дату циклической и в код прошивать номер текущего цикла (или начало эпохи). В бумажных документах встречается аналогичная практика: 19__, 20__.

Можно считать дату циклической и в код прошивать номер текущего цикла (или начало эпохи).

А потом номер цикла переполнится, как это в GPS случилось.

Какой интересный внезапный баг gcc:

https://stackoverflow.com/questions/72588712/why-is-gcc-with-attribute-ms-abi-returning-values-differently-than-ms

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105932

Я на https://godbolt.org/ проверил, это не недавняя регрессия. gcc 4.4.7 эту опцию еще не поддерживал, а gcc 4.5.3 уже генерирует бажный код.

Это что получается, опция не работала вообще никогда.

А в чём проблема? Жизнь на земле закончится раньше, чем тормознутый glibc regex успеет переполнить 32-битное смещение.

Не удивлюсь если с Clang всё в порядке. Я уже не таз сталкивался с проблемами когда GCC генерирует битый код, а с Clang всё в порядке. В том числе при компиляции под RISC-V.

Нее, он вообще эту опцию не поддерживает. Но он хотя бы честно об этом говорит.

Сейчас, похоже, в tcc нашел баг от механического copy-paste.

В файле присутствует два вида условий, такое:

#if defined(TCC_TARGET_PE) || TARGETOS_FreeBSD || TARGETOS_OpenBSD

и такое

#if !defined(TCC_TARGET_PE) && !TARGETOS_FreeBSD || TARGETOS_OpenBSD

И если с первым всё понятно, то насчёт второго я долго ломал голову, что оно может значить. Пока не посмотрел коммит: https://repo.or.cz/tinycc.git/commitdiff/cd91ea658a8c29c51aea1d4ab410bfbcc84fe5e5

Автор механически везде дописал || TARGETOS_OpenBSD и не увидел, что половине случаев получается не то, что нужно.

это весеннее обострение штоле?

Ну и вообще если в 2038-м году кому-то потребуется гонять 32-битный юзерленд, совместимый с glibc из 00-х, то у этих людей проблемы посерьёзнее проблемы дат.

Тут вот в gentoo отвалились пакеты из-за K&R C. Это же галимая хрень, с неявным типом int и наркоманскими прототипами, уже в C89 была deprecated, а пакетов судя по баг трекеру много затронуло: https://bugs.gentoo.org/870412

Dragonflybsd, например.

Будто /lib такой большой.

Вангую, что там в основном «implicit declaration of function». Варнинг, который уже 20 лет назад нужно было сделать ошибкой и не тянуть кота за яйца. Забавно, как раз сегодня об этом размышлял, глядя на логи компиляции.

Прочие «фичи» K&R C уже давно издохли вместе с соответствующими проектами. Ну если где остались, это либо дремучее легаси, либо по невнимательности текущей команды поддержки.

Ну, в контексте Bluetooth звука всякое пщщ нужно. Но реализация огонь, да.

11 гигов на моей системе, если что)

Но дело не в размере, а в том, что это принципиальный вопрос об организации пакетной базы: сохраняем совместимость ABI, чтобы пакеты из 2004-го года запускались без перекомпиляции, или нет.

То есть вопрос о том, бинарный ли у нас дистрибутив или source-based)

Варнинг, который уже 20 лет назад нужно было сделать ошибкой и не тянуть кота за яйца.

В обсуждении написано что это ввели в Clang 15, но откатили Clang 15.0.1, так как много всего сломалось.

Теперь вот снова вводят в Clang 16…

Молодцы.

Мне, как бывшему пользователю FreeBSD, в которой make world тривиален, этот кипиш не понятен.

Есть же проприетарный софт еще.

Если уж не контейнеры, то chroot хватит всем.

А сейчас самое то — накатывать FreeBSD уже.

Так а как там будут решать сабжевую проблему 2038 года? Или никаких планов ещё нет?

Стула-то два: сломать ABI или выкинуть Legacy. Оба решения так себе, но последнее хотя бы сбрасывает груз поддержки различной археологии…

Так для старых компиляций она не решаема в принципе, соответственно решать нечего. А новым можно спокойно ломать ABI. (Если вообще кому-то еще нужно новый код собирать под i486-linux-gnu)

Думаю, проблемы не будет. Свой софт перебирается легко, коммерческий все равно в линуксяторе с /lib любимого дистрибутива.

То есть неспособность к масштабированию это не косяк? Ты жеследующим сообщением написал совершенно обратное про станки. Весеннее обострение?

Ага масштабировать, с расчетом, что потребность возникнет через 50-60 лет. Ты реакцию на это представляешь? Тем более тогда программированию и компьютерам вообще было лет 20-30 от силы. Особенно, если такое масштабирование не бесплатное и понижает хотя бы на 5% скорость и приводит к увеличению расхода памяти. В 70-е машинка с 512Кб RAM была очень крутой и даже в 80-е сильно не начального уровня.

Если вообще кому-то еще нужно новый код собирать под i486-linux-gnu

Есть разные промышленные встраиваемые решения на современных или относительно еще современных процессорах с i486-й системой команд. Всякие там Vortex86 и прочие. Там частота может быть под гигагерц, встроенные usb 2.0 и прочее, как бы не из эпохи 486-х, но тем не менее с их системой команд в основе.

Ну тут есть такие соображения:

1. Я не думаю, что там нужна поддержка utmp в принципе.
2. Я не думаю, что там нужна поддержка бинарной совместимости с древним кодом.
3. Можно собирать под musl, она из коробки имеет 64-битное время в 32-битной версии.
4. Можно собирать и под glibc, там с какой-то из относительно недавних версий завезли нужную опцию сборки.

Я и говорю, в GNU программисты закончились)

Нет. Просто GNU-way не Ваш way.

Еще в копилку.

По тем же причинам 2038-го года в glib2 объявлен устаревшим GTimeVal и все функции для работы с ним.