URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 129920
[ Назад ]
Исходное сообщение
"Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp"
Отправлено opennews , 06-Мрт-23 10:35 
Торстен Кукук (Thorsten Kukuk), лидер группы по развитию технологий будущего в компании SUSE (Future Technology Team, развивает openSUSE MicroOS и SLE Micro), ранее 10 лет руководивший проектом SUSE LINUX Enterprise Server, предложил избавиться от файла /var/run/utmp в дистрибутивах для полного решения проблемы 2038 года в Glibc. Все приложения, использующие utmp, wtmp и lastlog, предлагается перевести на получение списка пользователей при помощи systemd-logind...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=58750

Содержание
Сообщения в этом обсуждении
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 10:35 
Ура, товарищи, прибьем glibc ржавыми гвоздями к systemd!
Glibc надо переименовать linux-only c library - LoLibc, как вам такое?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:02 
Юз йор факин айз: Change all applications, which read utmp, to query systemd-logind instead. То есть к системдосу будут прибивать приложения, а не глибц.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено _hide_ , 06-Мрт-23 15:22 
Да, действительно, logind очень нужная зависимость для вывода текущего системного времени в консоль. Очень странная ситуация, если честно.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено llolik , 06-Мрт-23 15:28 
> для вывода текущего системного времени в консоль

facepalm. Это-то тут причём?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 21:08 
> к системдосу будут прибивать приложения

"Нам только загрузку подускорить", - пищали поттеринги...

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 00:05 
>> к системдосу будут прибивать приложения
> "Нам только загрузку подускорить", - пищали поттеринги...

Самое смищное [нет], то что а сегодняшний день системы с openrc или с голым sysvinit загружаются быстрее, не говоря уже про всякие runit'ы. Так что подукорить там слилось ещё где-то в середине и сектанты переобувались в полёте лихорадочно изучая мантры про "портянки на баше" и подобные ужосы.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено anonymous , 06-Мрт-23 13:02 
А мы будем жить в 2038 году?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 15:01 
Хороший вопрос.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено псевдонимус , 06-Мрт-23 19:45 
Не все.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 21:18 
Зависит от высоты прыжков.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено uis , 06-Мрт-23 14:14 
LOLd - Linux Only Libraryd
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 14:16 
> прибьем ... ржавыми гвоздями ...

Стоп! Вот уж тут ржавчина (пока) не виновата!

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Kuromi , 06-Мрт-23 17:07 
А самое забавное случится через N лет когда появится новый еще более модный SystemX, который должен будет заменить все-все-все и ВДРУГ окажется что пресловутый и ужасно устаревший SystemD прибит гвоздями буквально ко всему и теперь надо задалбаться его отдирая. И все будут такие "А как это получилось?", "А кто это сделал?".

Предыдущая поделка Лени PulseAudio ведь уже "устарела", так что все возможно. Все уже забыли как из раздувшихся Иксов долго и болезненно убирали излишний функционал, а ведь тоже было "а давайте все в кучу".

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено псевдонимус , 06-Мрт-23 19:47 
Уже не появится. Мутант умрет вместе с ядром.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено ИмяХ , 06-Мрт-23 10:35 
Шикарно. Теперь ещё и glibc будет зависеть от systemd. Вот Лёнька молодец, всех под себя подмял!
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено iPony129412 , 06-Мрт-23 10:41 
Тут вспоминается одна пословица про то как не захочет - не вскочит.
В оригинале боюсь приводить. Зоотематика всё же.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено llolik , 06-Мрт-23 11:10 
Читаем внимательно, да

> Все приложения, использующие utmp, wtmp и lastlog, предлагается перевести на получение списка пользователей при помощи systemd-logind.
> Все ПРИЛОЖЕНИЯ

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:24 
подмял и свалил ЛОЛ
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено ИмяХ , 06-Мрт-23 20:03 
Никуда он не свалил. Всё так же за компьютером сидит, что-то там программирует.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 00:01 
> подмял и свалил ЛОЛ

Просто его диверссионное задание "под прикртием" закончилось и он вернлся в штаб

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 10:37 
Идея полностью дропнуть 32 бита в libc звучит более здраво, чем прибить libc к сд-костылям.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:08 
Раз уже все равно все прикладухи надо переписывать (под использование systemd-login), не проще ли было таки пофиксить в них 32->64 бита?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:30 
> несмотря на внедрение 64-разрядного типа time_t, для сохранения совместимости с 32-разрядными приложениями пространства пользователя в некоторых случаях на 64-разрядных платформах продолжает применяться 32-разрядный тип time_t

- А что, если в 64-битных аппликухах использовать 64-разрядный time_t, ведь 32-оси уже давно дропнуты?
...
- Да ну на! Давайте на 64-разрядных платформах юзать 32-разрядный time_t!

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено InuYasha , 06-Мрт-23 11:55 
"да ладно вам! ни один компьютер столько не проработает..."
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 10:35 
> "да ладно вам! ни один компьютер столько не проработает..."

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 11:08 
> Забавно, как молодые ехидно ругают дидов за недальновидность, а сами прелагают абсолютно тоже самое - просто увеличить диапазон.

Только диапазон теперь будет больше 100 миллиардов лет. Уверен, что человечество столько просуществует?  Ну если вдруг через столько лет будет линукс и в нем time_t, это наверное станет причиной конца сверхцивилизации, ибо вряд ли тогда кто-то будет помнить про это ограничение.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 14:08 
Ну так и 32-битное число выбрали не потому что "хватит всем", а потому что регистры были 32-разрядные. Странно, что вообще приходится это объяснять, и сотни лет не прошло.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 18:05 
Вы уверены что 50 лет назад регистры были именно 32 битные?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Совершенно другой аноним , 07-Мрт-23 18:57 
Скорее 18-ти разрядные. Если интересна история, то почитать можно тут: https://en.wikipedia.org/wiki/Unix_time
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 11-Мрт-23 19:19 
> Только диапазон теперь будет больше 100 миллиардов лет. Уверен, что человечество столько
> просуществует?

Если ты о теле человека, то нет.

Чарез ~4 миллиарда лет наше Солнце зажарит Землю, наступит смерть нашей Солнечной системы.

Через ~16 миллиардов лет Наша Галактика столкнётся с галактикой Андромеды.

А через ~80 миллиардов лет все радиоактивные изотопы распадутся и наступит вообще смерть всей Нашей Вселенной.

Но насчёт человеческой "цивилизации" ты не грусти, так долго ждать не придется, всё закончится намно-о-о-о-о-го быстрее!

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 11-Мрт-23 19:23 
> А через ~80 миллиардов лет все радиоактивные изотопы распадутся и наступит вообще
> смерть всей Нашей Вселенной.

А лёгкие элементы "сгорят" в термоядерном синтезе...

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:03 
Проще, но как тебя принудить к использованию зонда от правильной компании?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено не придумал , 06-Мрт-23 13:57 
думать запрещено, сказали на систем д, значит на систем д
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 11-Мрт-23 19:18 
> Раз уже все равно все прикладухи надо переписывать (под использование systemd-login), не
> проще ли было таки пофиксить в них 32->64 бита?

Проще и правельнее.

Но цель стоит всех поставить раком и всем вставить в *опу сытемды.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Admino , 06-Мрт-23 12:04 
Да, именно это авторы glibc и решили сделать.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 08:48 
> Идея полностью дропнуть 32 бита в libc звучит более здраво

...то то эмбедовка всякая рада будет. Ну там дебиан какой, допустим, с портами на ARM/MIPS.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 07-Мрт-23 19:37 
просто в следующей версии выбросят эти немодные устаревшие порты.
Будете клепать эмбедовку на 64разрядных кипятильниках.
Нефти - ж-пой жуй, газа - до х:я, угля мегатонны (но уголь только на пол-шишечки, не дальше 2028 года объявлен экологичненьким). АЭС вот ниикaлaгичны - их запретили прямо в этом году.

И ВСЕ делают так и такие вот феноменально-одаренные. Под аплодисменты баранов.

"эмбедовка не использует glibc "
Отправлено Алексей , 08-Мрт-23 07:14 
Там musl, uclibc, и т.п., а потому всё равно, что, как, и когда выкинут из glibc. Это раз.

И пользователи как правило на встроенные системы не заходят, поэтому страдания с [uw]tmp никак не волнуют. Это два.


"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено фф , 14-Мрт-23 09:07 
ну дык после 2038 года время просто не влезет в эти 32 бита, и что тогда делать этой эмбедовке? жить в 1970-м?
поле все равно надо расширять всем, не важно сколько бит влезает в регистры.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 03-Янв-24 20:54 
А 32-разрядной ембеддовке принципиально запрещается использовать time64_t ?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено iPony129412 , 06-Мрт-23 10:39 
В будущее с Кукуком ☝️
Главное вовремя выкидывать усаревшие технологии
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 13:24 
Да уж, тут ты прав. Выкинул бы я устаревшую технологию юникса еще в 90е - сейчас бы был богаче, успешнее и совсем не беспокоился бы ни о следующем месте работы, ни о безбедной старости.
Толку от нее сегодня все равно около нуля.

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

Нет, я правда и жизненных планов на такой срок не строил, конечно - сдох бы в 2005м, как ожидалось, и тоже переживать было бы не о чем.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:46 
Ой, да ладно тебе. Зато ты можешь с умным (не всегда) видом писать комментарии тут. Это ли не успех?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 08:50 
> Главное вовремя выкидывать усаревшие технологии

И как, выкинул уже хотя-бы ДВС-ы и свинцовокислотные акумы? XIX век, аж, а до сих пор в куче автомобилей... ну значит и сюда годков через 150 приползай, как с вон теми. Или кто банкет будет? Вон те, которые програмеров как раз увольняют? А, может ты на альтруизме перепишешь?! Так то пожалста.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено xPhoenix , 07-Мрт-23 11:21 
Сколько лет вилкам, ложкам и чайникам? А резьбовые соединения удалось заменить на что-то другое? Уууу! Отсталые!

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 07-Мрт-23 19:32 
> И как, выкинул уже хотя-бы ДВС-ы и свинцовокислотные акумы? XIX век, аж, а до сих пор
> в куче автомобилей...

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

За запретом эксплуатации того что уже выпустили - тоже не залежится.

И да, корень проблемы тот же что и в торжествующем шествии системдряни. Люди - т-пы.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено аноним.orig , 07-Мрт-23 23:25 
Угу. Только свинцовые аккумуляторы даже в упсах стоят.
Так что резать будут как обычно — по повесточке.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено A , 07-Мрт-23 22:45 
> Главное вовремя выкидывать усаревшие технологии

Алфавит, алфавит с арабскими цифрами очень морально устарел. И аксиомы арифметики - туда же. Менять надо.

Тока ничего никто не придумал на замену.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 08-Мрт-23 13:12 
Это просто Поттеринг до туда ещё не добрался :)
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 10:44 
> Просто заменить поле со временем в utmp с 32-разрядного на 64-разрядный тип не получится
> так как это приведёт к ... нарушению совместимости с приложениями, использующими utmp
> В итоге ... предлагается перевести все приложения на ... systemd-logind
> и после того как не останется актуальных программ, обращающихся к utmp, ...
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 10:46 
Т.е. смена ABI это опасносте, а systemd-logind окнорм?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено НяшМяш , 06-Мрт-23 11:02 
- Сохраняем ABI
- В 2038 году все приложения ломаются
- "Кококо надо было переходить на systemd-olologind"

Могли бы выпустить Glibc версии 3.0. Раз всё равно приложение чинить и пересобирать ¯\_(ツ)_/¯

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:05 
Так если всё равно все приложения переписывать и в случае перехода на 64 бита и в случае принудительного системд. Можно сразу покарать всех хомячков и прибить их к системд я считаю здраво. Хомячки должны страдать.  
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:32 
Надо было менять ABI. ABI - не API, решается перекомпиляцией софта.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено uis , 06-Мрт-23 14:23 
Чтобы не ломать ABI, мы сломаем API. Хотя и ABI сломаем тоже.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 08:52 
> - "Кококо надо было переходить на systemd-olologind"

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:03 
Будем надеяться, что Линукс покажет этому дядке большой 64-битный палец
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:25 
КТО такой Линукс?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено anonymous , 06-Мрт-23 12:48 
Пингвин вроде какой-то.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 15:02 
Ээ не, то Тукс
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено anonymous , 06-Мрт-23 15:38 
То Тукс, а это рофл)
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено анон , 06-Мрт-23 20:55 
Что там за история с дочерью? я не в курсе
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:14 
Проще не значит лучше, нужно просто в саму glibc внести все необходимые функции без привязки к systemd.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:46 
>нужно просто в саму glibc внести все необходимые функции
>просто

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Admino , 06-Мрт-23 12:05 
Да, именно это авторы glibc и решили сделать.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 15:04 
То есть своего демона logind написать?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Массоны Рептилоиды , 06-Мрт-23 11:28 
> лидер группы по развитию технологий будущего

Ничего не выйдёт без согласования с лидером по откапыванию технологий прошлого

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено ivan_erohin , 06-Мрт-23 16:25 
ну и что бы вы откопали ?
завести /var/run/*tmp64t и прогибать юзерлэнд чтобы читали и писали в туда ?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:32 
Хорошо. Если logind нет нужно просто написать демон с таким же API как у logind
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:33 
https://wiki.gentoo.org/wiki/Elogind
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Ня тян , 06-Мрт-23 18:20 
оооо, какая же ламповая эта вики) меньше по объёму чем у арча, но в моём сердечке на первом месте, ибо часов за чашкой горячего кофе в ней проведено немерено
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:35 
В комментариях конечно параксизм ненависти от "экспертов" и прожжённые стулья
Это ясно надо не читая
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено kusb , 06-Мрт-23 11:40 
Оправдано.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:37 
https://sr.ht/~kennylevinsen/seatd/
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:43 
Спасибо. Есть еще надежда.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 11:33 
Если всё равно надо переписывать приложения, то почему именно на системду?!
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено kusb , 06-Мрт-23 11:38 
Возможно вы путаете причину и следствие. Сначала ищут причины, по которым переписывание на системду может быть полезным.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:06 
Да полезным для кого? Как говорится Шерше ля фам.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено kusb , 06-Мрт-23 12:32 
> Да полезным для кого? Как говорится Шерше ля фам.

Я это подразумевал. Полезным не то чтобы для владельцев ОС.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 13:27 
Для rhbm очень даже полезно.
А вы - не владельцы, у вас ничего не было и нет.
И не будет уже.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:40 
А у тебя есть?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 17:59 
Конечно полезно, у них поддержка дистрибутива 15 лет с сохранением ABI. Им нужно уже сейчас проблему решать.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:53 
Потому что systemd это стандарт. Разработчикам не хочется изобретать велосипед с квадратными колесами, когда есть готовый хороший менеджер сеансов
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 13:28 
Когда есть готовый монолитный паровоз с треугольными.

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:44 
Пусть так. Никто не предложил лучше, остальные только балаболить и гореть могут.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 15:20 
естественно - у остальных-то нет права комитов в глибс (и зарплаты от rhbm)
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 17:56 
https://www.redhat.com/en/blog/patches-welcome-how-contribut...

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 18:06 
покажешь хоть один принятый твой патч?

А отправить-то да, можешь - devnull у них бездонный.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:44 
Покажи хоть один твой опровергнутый патч. Фантазировать на тему бездонности /dev/null можно бесконечно.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 18:49 
слив засчитан.
Нет там твоих патчей. А, ну да, ты ж не умеешь кодить...

.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено ivan_erohin , 06-Мрт-23 16:29 
> Потому что systemd это стандарт.

ISO (CCITT, ITU-T, ГОСТ, ...) про системд нам ничего не говорят.
следовательно, вы лжете.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 02:42 
Принципы проектирования ПО и здравый смысл говорят о том, что привязываться надо не к системд, а к формально описанному стандартизированному API.

Можно взять за основу и systemd-шный API, главное - наличие альтернативных реализаций, и тестирование работы с ними в рамках принятого стандарта, а не только с systemd.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено InuYasha , 06-Мрт-23 11:50 
То чувство, когда ты, живя в бум компьютерных технологий 1980ых, разрабатываешь костыли под очередной процессор, а 30 лет спустя получаешь ими по бошке.

> Future Technology Team

Создана после хаоса Y2K? :D

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 06:40 
> Y2K

Упала только Netware.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Ананий , 06-Мрт-23 11:51 
Интересно, как проблему будут рушать во FreeBSD.
Уж там-то точно не будет системд.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено kusb , 06-Мрт-23 11:53 
Теперь будет
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:03 
Видимо будут обновлять w, who, uptime, login, su, sudo, useradd, tcsh, xterm дисплейные менеджеры, emacs, openssh, qemu и т.п
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено r1 , 06-Мрт-23 19:02 
Поди успеют за 15 лет то.... в отличии от
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:06 
Её не будут решать фрёй в 2038 никто уже не будет пользоваться.  
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено cd , 06-Мрт-23 12:14 
а от линyпсa останется одна системдa
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:06 
> Её не будут решать фрёй в 2038 никто уже не будет пользоваться.

Её не будут решать, потому что её уже решили еще 20 лет назад, в отличие от "светочей прогресса"
https://people.freebsd.org/~peter/time64.diff


"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 14:16 
Решили потому что знали что всё равно будет не нужна. Да и зависимостей у неё мало потому что софта тоже нет.  
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:01 
> Интересно, как проблему будут рушать во FreeBSD.

Там, внезапно, своя libc и формат записи не прибит к конкретной разрядности (т.е. на 64-битных платформах он уже давно 64 бита).

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:14 
>> Интересно, как проблему будут рушать во FreeBSD.
> Там, внезапно, своя libc и формат записи не прибит к конкретной разрядности
> (т.е. на 64-битных платформах он уже давно 64 бита).

Кстати да, никаких проблем не то что с w/who/su/login, но и с emacs/openssh/xterm не наблюдается
https://lwn.net/Articles/925135/
>  FreeBSD has a semi-traditional implementation of getutxent that reads a file, but the on-disk format is a separate struct that their libc manually converts to struct utmpx, so it doesn't matter that struct utmpx is different between 32-bit and 64-bit programs. (This is in contrast to glibc where struct utmp, struct utmpx, and the on-disk format are all identical.)
>

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:29 
насколько я понял это проблема glibc от проекта GNU, в BSD-системах свои BSD libc, к-е вроде как не подвержены этой проблеме.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:49 
> насколько я понял это проблема glibc от проекта GNU, в BSD-системах свои BSD libc, к-е вроде как не подвержены этой проблеме.

Если "решат" проблему с помощью "Все приложения, использующие utmp, wtmp и lastlog, предлагается перевести на получение списка пользователей при помощи systemd-logind.", то своя либц тут ничем не поможет.


"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 13:35 
они ее так порешали что лучше бы уж не решали - как все последние достижения этого гальванизируемого трупа.

Там в 11й перешли на utmpx. Обычные last/w/who конечно переделали.
А вот opiepasswd - "переделали" так что теперь он локальный терминал - не считает секьюрным. (Вполне возможно не потому что плюс и минус перепутали а потому что там вообще мимо буфера читают и готовый rce, но pr присылать бесполезно - все кто не заняты гендерными штудиями, и так перегружены и читать его им недосуг)

Сколько и чего еще аналогично попереломали - наукой не установлено, потому что нет уже дураков тратить время на мертвую систему с works as intended во всех местах.

Один дефайн поменять вместо этой всей ненужной деятельности? Ну что вы, что вы, так же ж можно сломать совместимость незнамосчем.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено YetAnotherOnanym , 07-Мрт-23 00:36 
> как проблему будут рушать во FreeBSD

Вважаю, швыдко будут.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено фф , 14-Мрт-23 09:12 
не знаю как там фряха, в опенке еще в прошлом десятилетии просто сменили размерность на 64 бита, и кто не спрятался, тот сам виноват. Я ручками exim правил при обновлении системы например.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Admino , 06-Мрт-23 12:06 
Я насчитал пять человек, которые не смогли прочитать текст новости целиком, а вместо этого увидели слова "glibc" и "systemd" и решили, что теперь glibc будет прибита гвоздями к systemd.

Опеннет-эксперты as it is.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено kusb , 06-Мрт-23 12:37 
Я новость читал невнимательно, но комментарии внимательнее. Из них я понял, что это программы хотят привязать к ней, а до этого они пользовались функциями Glibc какими-то.
Ничего особенно не знаю что там они делают, но они возвращают какое-то значение, где мало байтиков и оно растёт со временем (может быть это время) и размер который был там выделен переполнится в будущем.
Правда я нефига не понял, они типа хотят сохранить обратную совместимость и не могут увеличить размер до 64, но могут заставить программы обращаться к systemd. И то и другое по моему одинаково ломает эту совместимость.

Я не программист и не очень хорошо разбираюсь в компьютерах, но звучит как-то странно.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Admino , 06-Мрт-23 12:53 
> Я новость читал невнимательно, но комментарии внимательнее. Из них я понял, что
> это программы хотят привязать к ней, а до этого они пользовались
> функциями Glibc какими-то.

Не функциями, а файлом. Файл называется utmp и лежит в нужном месте. И вот в нём отметки времени в uint32.

> Правда я нефига не понял, они типа хотят сохранить обратную совместимость и
> не могут увеличить размер до 64, но могут заставить программы обращаться
> к systemd.

Они хотят убрать формирование файлика utmp вообще, чтобы программы брали эту информацию из других мест. Например, через systemd. Но можно сделать и другие интерфейсы. BSD без опасносте.

Файлик этот всё равно надо выкидывать, потому что разные программы с ним всё равно работают по-разному, плюс вопросы безопасных прав записи, плюс возможность DDOS.

Поэтому разработчики glibc не хотят просто менять шило на мыло и делать файлик utmp64, лучше сделать сразу по-нормальному.

> И то и другое по моему одинаково ломает эту
> совместимость.

Нельзя просто взять и выкинуть старый код, совместимость так или иначе придётся сломать.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Имя , 07-Мрт-23 13:49 
Вообще-то сам заголовок статьи сформулирован так, что максимально вводит в заблуждение, так что не нужно удивлятся.
>Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Admino , 07-Мрт-23 16:28 
Да. Больше хайпа богу хайпа.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:07 
Вместо пустопорожнего трепа дружно переходим на Devuan и по мере сил и возможностей портируем недостающие пакеты в репы.
Вот тогда это будет *реальная* помощь в борьбе с systemd
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:17 
И в 2038 году дружно выкидываем Devuan в помойку (так-то вряд ли кто про него через пятнадцать лет вспомнит, но мало ли).
Впрочем, школьники в категориях таких сроков не мыслят.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 15:36 
У redhat 9 поддержка заканчивается в 2034 году, а у redhat 10 примерно в 37-38
И ABI redhat не меняет.
Мне кажется, разработчикам, желательно решить проблему заранее  проблему решить как-нибудь
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Анеони , 06-Мрт-23 17:29 
уже.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено ip1982 , 06-Мрт-23 12:08 
> лидер группы по развитию технологий будущего

Сколько пафоса!

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено ip1982 , 06-Мрт-23 12:12 
В чём проблема писать 32-битное время? Если оно больше нуля, значит после 2038-го года :) К тому времени 32-битные приложения сами отомрут.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:22 
Да будет просто вторая 32-х битная эпоха. А под эпоху место под отдельную переменную зарезервированное есть. Интересно сколько лучше всего бит выделить по 32х битную эпоху.  
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено kusb , 06-Мрт-23 12:39 
> Да будет просто вторая 32-х битная эпоха. А под эпоху место под
> отдельную переменную зарезервированное есть. Интересно сколько лучше всего бит выделить
> по 32х битную эпоху.

А что будет, когда переполнится счётчик эпох?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено kusb , 06-Мрт-23 12:40 
А ещё такое провоцирует ошибки, потому что люди не будут проверять ещё и эпоху, может быть. И так же всё работает.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Admino , 06-Мрт-23 12:55 
> Да будет просто вторая 32-х битная эпоха.

Сегодня – 28, месяца Последнего зерна, 433 год эпохи Акатоша. Близятся последние дни третьей эры, и последние часы моей жизни…

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено ИмяХ , 06-Мрт-23 20:09 
>>месяца Последнего зерна,

Вы, аннунаки, только в марте последнее зерно досеиваете? Или заканчиваете собирать?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Admino , 06-Мрт-23 20:35 
Thank Talos, it's fredas.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Обычный сиродильских НВах , 08-Мрт-23 00:01 
Нет места прелестней во всём Нирне в это время года, чем Ввандерфел!

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено A , 07-Мрт-23 22:50 
>  К тому времени 32-битные приложения сами отомрут.

Будут на каких-нибудь атомных электростанциях, моделях токомака и коллайдерах. А то и просто в банках - кэш отменят, но окажется, что крипта бегает поверх апликухи от дедов.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:13 
>  В кодовую базу следующего выпуска systemd 254 уже включены необходимые функции для предоставления заменяющих utmp данных через libsystemd с использованием API sd-login.h или через DBUS.

смотри какие быстрые! :) просто так совпало! Одни добавляют, другие проблему озвучивают, третьи профитируют.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:16 
Почему диды glibc на сишечке это не предусмотрели ещё 35 лет назад?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:20 
Потому что с 640Кб оперативы было не разгуляться с размерами переменных.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено A , 07-Мрт-23 22:54 
Потенциальное увеличение размера можно было учесть.

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

Да и смотря для чего писать код. Если выкинуть пену, останется не так много заменить...?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено crypt , 06-Мрт-23 12:58 
смотря, какие https://www.opennet.me/openforum/vsluhforumID3/129920.html#59
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:32 
сразу нафиг - нефиг systemd прибивать гвозьдями
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено freehck , 06-Мрт-23 12:45 
А я поддержу. При всей моей нелюбви к systemd, от данной интеграции сообщество выиграет: во-первых эта часть sd-login.h вполне себе reimplementable отдельно от systemd, во-вторых мы получим нормальное не нарушающее ABI разделение между старым и новым интерфейсами, причём хорошо так загодя до того, как грянет гром. Флаг им в руки.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:58 
Разработчики devian просто добавят демон реализующий эту часть API logind и все.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено crypt , 06-Мрт-23 12:56 
было приятно узнать, что FreeBSD лишена проблемы by design.

FreeBSD and macOS both support utmpx only, not traditional utmp. But they do support 64-bit timestamps at least on 64-bit architectures, because the ut_tv field of struct utmpx is a struct timeval, which on these systems uses 64-bit or 32-bit timestamps depending on the architecture. FreeBSD has a semi-traditional implementation of getutxent that reads a file, but the on-disk format is a separate struct that their libc manually converts to struct utmpx, so it doesn't matter that struct utmpx is different between 32-bit and 64-bit programs. (This is in contrast to glibc where struct utmp, struct utmpx, and the on-disk format are all identical.)

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 12:58 
>предлагается перевести на получение списка пользователей при помощи systemd-logind

Совсем кукукнулся этот Thorsten Kukuk.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:01 
Gentoo с OpenRC -- наше всё! Хотя нет, ещё Guix с Shepherd. Ударим свободными системными менеджерами по блоатвари и разгильдяйству!
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:31 
> Gentoo с OpenRC -- наше всё! Хотя нет, ещё Guix с Shepherd.
> Ударим свободными системными менеджерами по блоатвари и разгильдяйству!

лайк

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено _kp , 06-Мрт-23 13:19 
>>Просто заменить поле со временем в utmp с 32-разрядного на 64-разрядный тип не получится, так как это приведёт к изменению ABI Glibc

А вот если похерить сам glibc - то это совсем другое дело.

Вообще то glibc и сам по себе используется.
И приматывать его скотчем к initd - нельзя.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 13:39 
можно ж - уже примотали. И ничего, и это сожрете.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 14:28 
Очередной опеннетный эксперт не смог прочитать текст.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:23 

:~$ lastb
lastb: невозможно открыть /var/log/btmp: Отказано в доступе

сразу всё понятно.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 13:45 
>предлагается перевести на получение списка пользователей при помощи systemd-logind.

Да, нужно дропнуть все ядра, кроме Linux. Вслед за SystemD.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Легивон , 06-Мрт-23 14:10 
А вариант однократно перезагрузить все хосты в момент ошибки не рассматривался?
Если нужно делать это раз в 70 лет, то это не выглядит как проблема. И не подрывает SLA.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 14:15 
Отличная идея. Завязать Glibc на Systemd, а потом дропнуть Systemd, объяснив всем, что Systemd устарел и уже очень старый, надо заменить на что-то новое. Отличный коллапс тогда будет, Стив Балмер аплодирует стоя
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 14:18 
Системд хоть к ядру шиндоуз жестко завязывай. Если ты уже всех подсадил делай что хочешь.  
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено oficsu , 06-Мрт-23 14:42 
Класс, а давайте coreutils завяжем на systemd-logind, а что такого?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 14:44 
А можно просто предположить, что залогинившихся 70 лет назад пользователей быть не может, и решить проблему патчем одной строчки glibc.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Ананоним , 06-Мрт-23 15:14 
Странные разработчики. Они что, собираются возвращаться в прошлое на личной машине времени? Ну считали бы с 2037 года время с нуля и делов то...
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено HyC , 06-Мрт-23 15:34 
А рядом положить новые файлы с 64-битными счетчиками чтоб все к ним привыкли до 2038 года не судьба ?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 15:35 
Перечитал новость. Оказывается, речь про 2038 год, то есть - нескоро. Хотя, местные специалисты недавольны, и могут уже сейчас форкать glibc, через 15 лет эти форки обгонят какой-то там glibc по качеству.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 16:00 
Это уже практически завтра.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 17:29 
https://github.com/linux-pam/linux-pam/pull/541

Тем временем PAM уже переделали на logind
Им надо было перед этим спросить мнение у экспертов по Си с опеннет.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 18:11 
> Тем временем PAM уже переделали на logind

привет девуану.

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

Юникс-экосистема мертва. Не потому что была плоха, а потому что рабы всегда и все делают максимально х-ево.
А эпоха свободных людей в этом вашем опенсорсе прошла безвозвратно.


"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:25 
О чем вы? systemd это клон launchd
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:32 
>А эпоха свободных людей в этом вашем опенсорсе прошла безвозвратно.

Почему вы все время ноете? LFS у вас поделка, systemd как в винде, хотя в macos и вроде бы в solaris аналогичные менеджеры.
Судя по изменениям там опциями компиляции выбирается использовать logind или нет.
Сделать адаптер из одного api в другой несложно, уж бинарный файл заполнить данными можно даже на kotlin
Свободных людей нет... Возможно нужно меньше ныть на опеннет?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:35 
Devian себе могут seatd поставить и будет менеджер сеансов, вообще не часть systemd и не привязанный к linux
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 18:39 
он уже научился вон с pam работать?
Ну и давайте, давайте - менеджер сеансов, менеджер фаянсов - так и перекопипастите весь systemd.

Б-ть ну вот как мы без вас жили и без ваших дерьмоменеджеров вовсе?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:22 
Вместо старого интерфейса через бинарный файл в который может писать кто угодно, будет новый на основе менеджера сеансов. Вот кому от этого плохо?
И logind не один такой менеджер сеансов, остальные могут просто реализовать такой же API и всё.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено погроммист , 06-Мрт-23 17:42 
Для избавления  от проблемы 2038 года предлагаю прекратить использование glibc.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено пох. , 06-Мрт-23 18:12 
> Для избавления  от проблемы 2038 года предлагаю прекратить использование glibc.

ну так в винде и нет этой проблемы


"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 17:46 
А если freebsd не использует systemd, gentoo и прочие дистрибутивы с сайта  https://nosystemd.org/ не использующие systemd. Всех прибивают гвозями к systemd, аудит безопасности которой никто не производил (там все слишком запутано).
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 17:47 
BSD не ипользует glibc. у них свой BSDшный libc
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 18:46 
> BSD не ипользует glibc. у них свой BSDшный libc

И как отсутсвие проблем в своей libc им поможет, если в качестве решения "Все приложения, использующие utmp, wtmp и lastlog, предлагается перевести на получение списка пользователей при помощи systemd-logind."?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 20:24 
Все приложения в линукс (из coreutils я полагаю). Ты думаешь в BSD работают линуксовые приложения, работающие в utmp?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 06-Мрт-23 21:14 
>> с приложениями, использующими utmp ... tcsh, xterm, ... дисплейные менеджеры, emacs, openssh
> Все приложения в линукс (из coreutils я полагаю).

Угу, угу. "Родина слонов"(с).
> Ты думаешь в BSD работают линуксовые приложения, работающие в utmp?

Ну ... tcsh, xterm, openssh и emacs работают точно (дисплейные менеджеры когда-то тоже вполне работали). А так, utmp во фре заменили на utmpx где-то лет 12 назад.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 01:58 
Что-то я сомневаюсь, что разработчики openbsd буду переписывать openssh под системд. tcsh, xterm появились ещё до линукса и, что самое важное, они используются не только в линукс и авторы с большой долей вероятности не будут их патчить под системд.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 13:02 
Что-то я сомневаюсь, что _те_ авторы xterm и tcsh вообще еще что-то патчат.
Но речь шла о предложенном "решении", которое надежно и точно ломает совместимость с "нелинухами".

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Tron is Whistling , 06-Мрт-23 23:24 
utmp64 добавить совсем-совсем никак?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Ivan_83 , 07-Мрт-23 01:21 
Яиц просто нет у разрабов.

Написать в хидере чтобы не давал себя собирать с time32_t и всё.
За месяц авторы всех остальных утилит бы поаравили свои поделия или юзеры патчей накидали.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено IdeaFix , 07-Мрт-23 09:10 
Зачем в сусе думают от технологиях будущего?
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 09:13 
То есть заменить на 64-битный time_t трудоёмко, а на на systemd-logind - нет? Интересно.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Дворник , 07-Мрт-23 10:06 
Летят цветные бумеранги..

`utmp`

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 10:47 
Скажи systemd НЕТ! Не плоди заразу в дистрах.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 15:52 
Мне одному кажется, что используя удобный повод хотят пользователей тупо перевести на systemd-logind?

Если есть проблема её надо решать, какой бы трудной она не была. А не сбегать в ненавистный системД.

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено pic , 07-Мрт-23 18:16 
Нет. Согласен.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 08-Мрт-23 16:56 
> Мне одному кажется

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

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 07-Мрт-23 19:57 
А что, если использовать тип 64-битный?
...
Да ну на! Давайте всё прибьём к системде!
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 08-Мрт-23 14:01 
man utmp

"POSIX.1 does not specify a utmp structure, but rather one named utmpx, with specifications for the fields ut_type, ut_pid, ut_line, ut_id, ut_user, and ut_tv.  POSIX.1  does  not  specify  the  lengths  of  the ut_line and ut_user fields."

То есть файл есть, но структура не стандартизована

"Linux utmp entries conform neither to v7/BSD nor to System V; they are a mix of the two. v7/BSD  has  fewer  fields;  most  importantly it lacks ut_type, which causes native v7/BSD-like programs to display (for example) dead or login entries.  Further, there is no configuration file which allocates slots to sessions.  BSD does so because it lacks ut_id fields. In Linux (as in System V), the ut_id field of a record will never change once it has been set, which reserves that slot without needing a configuration file.  Clearing ut_id may result in race conditions  lead‐ing  to corrupted utmp entries and potential security holes.  Clearing the abovementioned fields by filling them with null bytes is not required by System V semantics, but makes it possible to run many programs which assume BSD semantics and which do not modify utmp.  Linux uses the BSD conventions for line contents, as documented above. System V has no ut_host or ut_addr_v6 fields."

То есть у линукса свой формат файла ни с чем не совместимый

А что есть в freebsd? Нету там его там utmpx
И не только в ней
https://lists.dragonflybsd.org/pipermail/commits/2019-Septem...

Дальше:
Location
Depending on the system, those files may commonly be found in different places (non-exhaustive list) :

Solaris:
/var/adm/utmp (deprecated), /var/adm/utmpx
/var/adm/wtmp (deprecated), /var/adm/wtmpx

HP-UX:
/etc/utmp (deprecated), /etc/utmpx
/var/adm/wtmp (deprecated), /var/adm/wtmpx
/var/adm/btmp (deprecated), /var/adm/btmpx

FreeBSD 9.0 introduced new files while adding support for utmpx:
/var/run/utx.active (replaces utmp)
/var/log/utx.lastlogin (replaces lastlog)
/var/log/utx.log (replaces wtmp)

То во всех ос свой файл и свой формат.


Вот эти вот люди которые почти 200 комментариев исписали про "прибить к systemd чтобы было несовместимо с другими ос" они точно понимаю о чем пишут?

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 08-Мрт-23 15:13 
> А что есть в freebsd? Нету там его там utmpx
> И не только в ней
> https://lists.dragonflybsd.org/pipermail/commits/2019-Septem...

.
> FreeBSD 9.0 introduced new files while adding support for utmpx:
> /var/run/utx.active (replaces utmp)
> /var/log/utx.lastlogin (replaces lastlog)
> /var/log/utx.log (replaces wtmp)
> То во всех ос свой файл и свой формат.

.
Но "есть один нюанс, Петька!"
https://man.freebsd.org/cgi/man.cgi?query=utmpx&sektion=3&ma...
> STANDARDS
>     The endutxent(), getutxent(), getutxid(), getutxline() and    setutxent()
>     functions are expected to conform to IEEE Std 1003.1-2008 ("POSIX.1").

https://man.dragonflybsd.org/?command=endutxent§ion=3
> The endutxent(), getutxent(), getutxid(), getutxline(), pututxline(),
>     setutxent() all conform to IEEE Std 1003.1-2001 ("POSIX.1") (XSI
>     extension), and previously to X/Open Portability Guide Issue 4, Version 2

в отличие от.
Пингвинята тут не парились - сделали "Linux defines the utmpx structure to be the same as the utmp structure", а теперь вот - не знают, куды бечь.

> Вот эти вот люди которые почти 200 комментариев исписали про "прибить к
> systemd чтобы было несовместимо с другими ос" они точно понимаю о чем пишут?

Ну да, с одной стороны - программам для кросплатформенности достаточно использовать стандартно-посиксные вызовы в либц.
С другой - _одна_ платформа, для которой сначала допустили ошибку при реализации, а теперь боятся сломать совместимость с костылями и настойчиво предлагают в качестве "фикса" просто перевести все программы на "новый стандарт"-API этой самой единственной платформы.
Ей-ей, еще лет 10 назад, читая последний абзатц, в голову пришел бы МС или на крайняк, эппл ...

"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 08-Мрт-23 15:57 
все ок, тут иксперты сидят, понимать надо
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено keydon , 09-Мрт-23 13:35 
Выражу свою обострившуюся параною: всё подбивают под systemd (наверное как и предполагает EEE сделают альтернативу, но опцией, а опции как известно не в приоритете, и противникам systemd прибавится еще одна маленькая, но очередная, проблема), автор которого в мелкософте. Ну и аргументация прибития к systemd страдает. Звучит как еще один шажок (как всегда "безобидный") захвата линукса.
"Для избавления Glibc от проблемы 2038 года предложено прекра..."
Отправлено Аноним , 11-Мрт-23 18:59 
> Например, для записи в utmp требуются специальные права, что требует предоставления процессам дополнительных привилегий.


ls -l /var/run/utmp
-rw-rw-r-- 1 root utmp 3840 Mar 11 22:43 /var/run/utmp

Надо добавить в групу utmp.

> Ещё одна проблема связана с тем, что архитектура utmp допускает совершение локальными пользователями DoS-атак, приводящих к нарушению работы сервиса utmp через манипуляции с блокировками на файл, из-за чего нельзя быть уверенным, что содержимое utmp отражает реальное состояние в системе. Для обработки доступа к utmp предлагалось использовать дополнительный фоновый процесс

Нет! Для этого надо использовать MAC. А предлагают очередной костыль типа  polkitd+JS.

Да DAC дает много безопасности с дисретностью пользователь, группа. для более тонкой настройки есть MAC и CAP.

Есть системы, работающие без systemd, elogind, dbus, polkit+JS и прочим троянцам.

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