The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Для избавления 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.ru/opennews/art.shtml?num=58750

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. Скрыто модератором  +17 +/
Сообщение от Аноним (1), 06-Мрт-23, 10:35 
Ответить | Правка | Наверх | Cообщить модератору

8. Скрыто модератором  +13 +/
Сообщение от Аноним (8), 06-Мрт-23, 11:02 
Ответить | Правка | Наверх | Cообщить модератору

118. Скрыто модератором  –4 +/
Сообщение от _hide_ (ok), 06-Мрт-23, 15:22 
Ответить | Правка | Наверх | Cообщить модератору

119. Скрыто модератором  +3 +/
Сообщение от llolik (ok), 06-Мрт-23, 15:28 
Ответить | Правка | Наверх | Cообщить модератору

169. Скрыто модератором  +4 +/
Сообщение от Аноним (169), 06-Мрт-23, 21:08 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

177. Скрыто модератором  +6 +/
Сообщение от Аноним (177), 07-Мрт-23, 00:05 
Ответить | Правка | Наверх | Cообщить модератору

65. Скрыто модератором  +11 +/
Сообщение от anonymous (??), 06-Мрт-23, 13:02 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

111. Скрыто модератором  +1 +/
Сообщение от Аноним (111), 06-Мрт-23, 15:01 
Ответить | Правка | Наверх | Cообщить модератору

161. Скрыто модератором  +3 +/
Сообщение от псевдонимус (?), 06-Мрт-23, 19:45 
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

172. Скрыто модератором  –2 +/
Сообщение от Аноним (169), 06-Мрт-23, 21:18 
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

101. Скрыто модератором  +4 +/
Сообщение от uis (??), 06-Мрт-23, 14:14 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

103. Скрыто модератором  +6 +/
Сообщение от Аноним (103), 06-Мрт-23, 14:16 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

132. Скрыто модератором  +5 +/
Сообщение от Kuromi (ok), 06-Мрт-23, 17:07 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

162. Скрыто модератором  –1 +/
Сообщение от псевдонимус (?), 06-Мрт-23, 19:47 
Ответить | Правка | Наверх | Cообщить модератору

2. Скрыто модератором  +13 +/
Сообщение от ИмяХ (?), 06-Мрт-23, 10:35 
Ответить | Правка | Наверх | Cообщить модератору

5. Скрыто модератором  –4 +/
Сообщение от iPony129412 (?), 06-Мрт-23, 10:41 
Ответить | Правка | Наверх | Cообщить модератору

13. Скрыто модератором  +3 +/
Сообщение от llolik (ok), 06-Мрт-23, 11:10 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

47. Скрыто модератором  +/
Сообщение от Аноним (47), 06-Мрт-23, 12:24 
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

163. Скрыто модератором  –1 +/
Сообщение от ИмяХ (?), 06-Мрт-23, 20:03 
Ответить | Правка | Наверх | Cообщить модератору

176. Скрыто модератором  +1 +/
Сообщение от Аноним (177), 07-Мрт-23, 00:01 
Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

3. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +19 +/
Сообщение от Аноним (3), 06-Мрт-23, 10:37 
Идея полностью дропнуть 32 бита в libc звучит более здраво, чем прибить libc к сд-костылям.
Ответить | Правка | Наверх | Cообщить модератору

12. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +6 +/
Сообщение от Аноним (12), 06-Мрт-23, 11:08 
Раз уже все равно все прикладухи надо переписывать (под использование systemd-login), не проще ли было таки пофиксить в них 32->64 бита?
Ответить | Правка | Наверх | Cообщить модератору

16. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +3 +/
Сообщение от Аноним (169), 06-Мрт-23, 11:30 
> несмотря на внедрение 64-разрядного типа time_t, для сохранения совместимости с 32-разрядными приложениями пространства пользователя в некоторых случаях на 64-разрядных платформах продолжает применяться 32-разрядный тип time_t

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

Ответить | Правка | Наверх | Cообщить модератору

29. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от InuYasha (??), 06-Мрт-23, 11:55 
"да ладно вам! ни один компьютер столько не проработает..."
Ответить | Правка | Наверх | Cообщить модератору

189. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (189), 07-Мрт-23, 10:35 
> "да ладно вам! ни один компьютер столько не проработает..."

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

196. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (196), 07-Мрт-23, 14:08 
Ну так и 32-битное число выбрали не потому что "хватит всем", а потому что регистры были 32-разрядные. Странно, что вообще приходится это объяснять, и сотни лет не прошло.
Ответить | Правка | Наверх | Cообщить модератору

199. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (199), 07-Мрт-23, 18:05 
Вы уверены что 50 лет назад регистры были именно 32 битные?
Ответить | Правка | Наверх | Cообщить модератору

201. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Совершенно другой аноним (?), 07-Мрт-23, 18:57 
Скорее 18-ти разрядные. Если интересна история, то почитать можно тут: https://en.wikipedia.org/wiki/Unix_time
Ответить | Правка | Наверх | Cообщить модератору

221. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Аноним (221), 11-Мрт-23, 19:19 
> Только диапазон теперь будет больше 100 миллиардов лет. Уверен, что человечество столько
> просуществует?

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

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

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

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

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

Ответить | Правка | К родителю #192 | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

32. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Аноним (32), 06-Мрт-23, 12:03 
Проще, но как тебя принудить к использованию зонда от правильной компании?
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

95. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от не придумал (?), 06-Мрт-23, 13:57 
думать запрещено, сказали на систем д, значит на систем д
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

220. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (221), 11-Мрт-23, 19:18 
> Раз уже все равно все прикладухи надо переписывать (под использование systemd-login), не
> проще ли было таки пофиксить в них 32->64 бита?

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

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

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

33. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Admino (ok), 06-Мрт-23, 12:04 
Да, именно это авторы glibc и решили сделать.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

183. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (-), 07-Мрт-23, 08:48 
> Идея полностью дропнуть 32 бита в libc звучит более здраво

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

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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


Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

223. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от фф (?), 14-Мрт-23, 09:07 
ну дык после 2038 года время просто не влезет в эти 32 бита, и что тогда делать этой эмбедовке? жить в 1970-м?
поле все равно надо расширять всем, не важно сколько бит влезает в регистры.
Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

225. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (225), 03-Янв-24, 20:54 
А 32-разрядной ембеддовке принципиально запрещается использовать time64_t ?
Ответить | Правка | Наверх | Cообщить модератору

4. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –2 +/
Сообщение от iPony129412 (?), 06-Мрт-23, 10:39 
В будущее с Кукуком ☝️
Главное вовремя выкидывать усаревшие технологии
Ответить | Правка | Наверх | Cообщить модератору

74. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –8 +/
Сообщение от пох. (?), 06-Мрт-23, 13:24 
Да уж, тут ты прав. Выкинул бы я устаревшую технологию юникса еще в 90е - сейчас бы был богаче, успешнее и совсем не беспокоился бы ни о следующем месте работы, ни о безбедной старости.
Толку от нее сегодня все равно около нуля.

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

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

Ответить | Правка | Наверх | Cообщить модератору

91. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +9 +/
Сообщение от Аноним (91), 06-Мрт-23, 13:46 
Ой, да ладно тебе. Зато ты можешь с умным (не всегда) видом писать комментарии тут. Это ли не успех?
Ответить | Правка | Наверх | Cообщить модератору

184. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (-), 07-Мрт-23, 08:50 
> Главное вовремя выкидывать усаревшие технологии

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | К родителю #184 | Наверх | Cообщить модератору

208. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от аноним.orig (?), 07-Мрт-23, 23:25 
Угу. Только свинцовые аккумуляторы даже в упсах стоят.
Так что резать будут как обычно — по повесточке.
Ответить | Правка | Наверх | Cообщить модератору

205. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от A (?), 07-Мрт-23, 22:45 
> Главное вовремя выкидывать усаревшие технологии

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

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

211. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (211), 08-Мрт-23, 13:12 
Это просто Поттеринг до туда ещё не добрался :)
Ответить | Правка | Наверх | Cообщить модератору

6. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +3 +/
Сообщение от Аноним (6), 06-Мрт-23, 10:44 
> Просто заменить поле со временем в utmp с 32-разрядного на 64-разрядный тип не получится
> так как это приведёт к ... нарушению совместимости с приложениями, использующими utmp
> В итоге ... предлагается перевести все приложения на ... systemd-logind
> и после того как не останется актуальных программ, обращающихся к utmp, ...
Ответить | Правка | Наверх | Cообщить модератору

7. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +15 +/
Сообщение от Аноним (7), 06-Мрт-23, 10:46 
Т.е. смена ABI это опасносте, а systemd-logind окнорм?
Ответить | Правка | Наверх | Cообщить модератору

9. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +6 +/
Сообщение от НяшМяш (ok), 06-Мрт-23, 11:02 
- Сохраняем ABI
- В 2038 году все приложения ломаются
- "Кококо надо было переходить на systemd-olologind"

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

Ответить | Правка | Наверх | Cообщить модератору

34. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –3 +/
Сообщение от Аноним (32), 06-Мрт-23, 12:05 
Так если всё равно все приложения переписывать и в случае перехода на 64 бита и в случае принудительного системд. Можно сразу покарать всех хомячков и прибить их к системд я считаю здраво. Хомячки должны страдать.  
Ответить | Правка | Наверх | Cообщить модератору

81. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (81), 06-Мрт-23, 13:32 
Надо было менять ABI. ABI - не API, решается перекомпиляцией софта.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

106. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +7 +/
Сообщение от uis (??), 06-Мрт-23, 14:23 
Чтобы не ломать ABI, мы сломаем API. Хотя и ABI сломаем тоже.
Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

185. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (-), 07-Мрт-23, 08:52 
> - "Кококо надо было переходить на systemd-olologind"

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

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

10. Скрыто модератором  +/
Сообщение от Аноним (10), 06-Мрт-23, 11:03 
Ответить | Правка | Наверх | Cообщить модератору

48. Скрыто модератором  +/
Сообщение от Аноним (47), 06-Мрт-23, 12:25 
Ответить | Правка | Наверх | Cообщить модератору

55. Скрыто модератором  +6 +/
Сообщение от anonymous (??), 06-Мрт-23, 12:48 
Ответить | Правка | Наверх | Cообщить модератору

112. Скрыто модератором  +2 +/
Сообщение от Аноним (112), 06-Мрт-23, 15:02 
Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором  +/
Сообщение от anonymous (??), 06-Мрт-23, 15:38 
Ответить | Правка | Наверх | Cообщить модератору

168. Скрыто модератором  –1 +/
Сообщение от анон (?), 06-Мрт-23, 20:55 
Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

14. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +3 +/
Сообщение от Аноним (14), 06-Мрт-23, 11:14 
Проще не значит лучше, нужно просто в саму glibc внести все необходимые функции без привязки к systemd.
Ответить | Правка | Наверх | Cообщить модератору

25. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +5 +/
Сообщение от Аноним (25), 06-Мрт-23, 11:46 
>нужно просто в саму glibc внести все необходимые функции
>просто

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

Ответить | Правка | Наверх | Cообщить модератору

35. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Admino (ok), 06-Мрт-23, 12:05 
Да, именно это авторы glibc и решили сделать.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

114. Скрыто модератором  +/
Сообщение от Аноним (-), 06-Мрт-23, 15:04 
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

15. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Массоны Рептилоиды (?), 06-Мрт-23, 11:28 
> лидер группы по развитию технологий будущего

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

Ответить | Правка | Наверх | Cообщить модератору

129. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от ivan_erohin (?), 06-Мрт-23, 16:25 
ну и что бы вы откопали ?
завести /var/run/*tmp64t и прогибать юзерлэнд чтобы читали и писали в туда ?
Ответить | Правка | Наверх | Cообщить модератору

17. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (199), 06-Мрт-23, 11:32 
Хорошо. Если logind нет нужно просто написать демон с таким же API как у logind
Ответить | Правка | Наверх | Cообщить модератору

18. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +5 +/
Сообщение от Аноним (199), 06-Мрт-23, 11:33 
https://wiki.gentoo.org/wiki/Elogind
Ответить | Правка | Наверх | Cообщить модератору

147. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +5 +/
Сообщение от Ня тянemail (?), 06-Мрт-23, 18:20 
оооо, какая же ламповая эта вики) меньше по объёму чем у арча, но в моём сердечке на первом месте, ибо часов за чашкой горячего кофе в ней проведено немерено
Ответить | Правка | Наверх | Cообщить модератору

20. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –2 +/
Сообщение от Аноним (199), 06-Мрт-23, 11:35 
В комментариях конечно параксизм ненависти от "экспертов" и прожжённые стулья
Это ясно надо не читая
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

23. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от kusb (?), 06-Мрт-23, 11:40 
Оправдано.
Ответить | Правка | Наверх | Cообщить модератору

21. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (199), 06-Мрт-23, 11:37 
https://sr.ht/~kennylevinsen/seatd/
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

24. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (24), 06-Мрт-23, 11:43 
Спасибо. Есть еще надежда.
Ответить | Правка | Наверх | Cообщить модератору

19. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Аноним (169), 06-Мрт-23, 11:33 
Если всё равно надо переписывать приложения, то почему именно на системду?!
Ответить | Правка | Наверх | Cообщить модератору

22. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от kusb (?), 06-Мрт-23, 11:38 
Возможно вы путаете причину и следствие. Сначала ищут причины, по которым переписывание на системду может быть полезным.
Ответить | Правка | Наверх | Cообщить модератору

36. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (32), 06-Мрт-23, 12:06 
Да полезным для кого? Как говорится Шерше ля фам.
Ответить | Правка | Наверх | Cообщить модератору

49. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от kusb (?), 06-Мрт-23, 12:32 
> Да полезным для кого? Как говорится Шерше ля фам.

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

Ответить | Правка | Наверх | Cообщить модератору

76. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от пох. (?), 06-Мрт-23, 13:27 
Для rhbm очень даже полезно.
А вы - не владельцы, у вас ничего не было и нет.
И не будет уже.

Ответить | Правка | Наверх | Cообщить модератору

85. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (81), 06-Мрт-23, 13:40 
А у тебя есть?
Ответить | Правка | Наверх | Cообщить модератору

143. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (199), 06-Мрт-23, 17:59 
Конечно полезно, у них поддержка дистрибутива 15 лет с сохранением ABI. Им нужно уже сейчас проблему решать.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

56. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –8 +/
Сообщение от Аноним (199), 06-Мрт-23, 12:53 
Потому что systemd это стандарт. Разработчикам не хочется изобретать велосипед с квадратными колесами, когда есть готовый хороший менеджер сеансов
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

77. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +4 +/
Сообщение от пох. (?), 06-Мрт-23, 13:28 
Когда есть готовый монолитный паровоз с треугольными.

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

Ответить | Правка | Наверх | Cообщить модератору

89. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –4 +/
Сообщение от Аноним (89), 06-Мрт-23, 13:44 
Пусть так. Никто не предложил лучше, остальные только балаболить и гореть могут.
Ответить | Правка | Наверх | Cообщить модератору

116. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от пох. (?), 06-Мрт-23, 15:20 
естественно - у остальных-то нет права комитов в глибс (и зарплаты от rhbm)
Ответить | Правка | Наверх | Cообщить модератору

141. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (199), 06-Мрт-23, 17:56 
https://www.redhat.com/en/blog/patches-welcome-how-contribut...

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

158. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от пох. (?), 06-Мрт-23, 18:49 
слив засчитан.
Нет там твоих патчей. А, ну да, ты ж не умеешь кодить...

.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

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

> Future Technology Team

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

Ответить | Правка | Наверх | Cообщить модератору

182. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (182), 07-Мрт-23, 06:40 
> Y2K

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

Ответить | Правка | Наверх | Cообщить модератору

27. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Ананий (?), 06-Мрт-23, 11:51 
Интересно, как проблему будут рушать во FreeBSD.
Уж там-то точно не будет системд.
Ответить | Правка | Наверх | Cообщить модератору

28. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от kusb (?), 06-Мрт-23, 11:53 
Теперь будет
Ответить | Правка | Наверх | Cообщить модератору

31. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (31), 06-Мрт-23, 12:03 
Видимо будут обновлять w, who, uptime, login, su, sudo, useradd, tcsh, xterm дисплейные менеджеры, emacs, openssh, qemu и т.п
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

160. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от r1 (?), 06-Мрт-23, 19:02 
Поди успеют за 15 лет то.... в отличии от
Ответить | Правка | Наверх | Cообщить модератору

37. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (32), 06-Мрт-23, 12:06 
Её не будут решать фрёй в 2038 никто уже не будет пользоваться.  
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

43. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от cd (?), 06-Мрт-23, 12:14 
а от линyпсa останется одна системдa
Ответить | Правка | Наверх | Cообщить модератору

67. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (67), 06-Мрт-23, 13:06 
> Её не будут решать фрёй в 2038 никто уже не будет пользоваться.

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


Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

104. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (104), 06-Мрт-23, 14:16 
Решили потому что знали что всё равно будет не нужна. Да и зависимостей у неё мало потому что софта тоже нет.  
Ответить | Правка | Наверх | Cообщить модератору

63. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Аноним (67), 06-Мрт-23, 13:01 
> Интересно, как проблему будут рушать во FreeBSD.

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

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

70. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (67), 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.)
>

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

Ответить | Правка | Наверх | Cообщить модератору

78. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (31), 06-Мрт-23, 13:29 
насколько я понял это проблема glibc от проекта GNU, в BSD-системах свои BSD libc, к-е вроде как не подвержены этой проблеме.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

159. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (159), 06-Мрт-23, 18:49 
> насколько я понял это проблема glibc от проекта GNU, в BSD-системах свои BSD libc, к-е вроде как не подвержены этой проблеме.

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


Ответить | Правка | Наверх | Cообщить модератору

82. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от пох. (?), 06-Мрт-23, 13:35 
они ее так порешали что лучше бы уж не решали - как все последние достижения этого гальванизируемого трупа.

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

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

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

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

178. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от YetAnotherOnanym (ok), 07-Мрт-23, 00:36 
> как проблему будут рушать во FreeBSD

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

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

224. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от фф (?), 14-Мрт-23, 09:12 
не знаю как там фряха, в опенке еще в прошлом десятилетии просто сменили размерность на 64 бита, и кто не спрятался, тот сам виноват. Я ручками exim правил при обновлении системы например.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

38. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +5 +/
Сообщение от Admino (ok), 06-Мрт-23, 12:06 
Я насчитал пять человек, которые не смогли прочитать текст новости целиком, а вместо этого увидели слова "glibc" и "systemd" и решили, что теперь glibc будет прибита гвоздями к systemd.

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

195. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Имя (?), 07-Мрт-23, 13:49 
Вообще-то сам заголовок статьи сформулирован так, что максимально вводит в заблуждение, так что не нужно удивлятся.
>Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

198. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Admino (ok), 07-Мрт-23, 16:28 
Да. Больше хайпа богу хайпа.
Ответить | Правка | Наверх | Cообщить модератору

39. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (39), 06-Мрт-23, 12:07 
Вместо пустопорожнего трепа дружно переходим на Devuan и по мере сил и возможностей портируем недостающие пакеты в репы.
Вот тогда это будет *реальная* помощь в борьбе с systemd
Ответить | Правка | Наверх | Cообщить модератору

71. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (71), 06-Мрт-23, 13:17 
И в 2038 году дружно выкидываем Devuan в помойку (так-то вряд ли кто про него через пятнадцать лет вспомнит, но мало ли).
Впрочем, школьники в категориях таких сроков не мыслят.
Ответить | Правка | Наверх | Cообщить модератору

122. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –2 +/
Сообщение от Аноним (199), 06-Мрт-23, 15:36 
У redhat 9 поддержка заканчивается в 2034 году, а у redhat 10 примерно в 37-38
И ABI redhat не меняет.
Мне кажется, разработчикам, желательно решить проблему заранее  проблему решить как-нибудь
Ответить | Правка | Наверх | Cообщить модератору

133. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Анеони (?), 06-Мрт-23, 17:29 
уже.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

41. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от ip1982 (ok), 06-Мрт-23, 12:12 
В чём проблема писать 32-битное время? Если оно больше нуля, значит после 2038-го года :) К тому времени 32-битные приложения сами отомрут.
Ответить | Правка | Наверх | Cообщить модератору

46. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (32), 06-Мрт-23, 12:22 
Да будет просто вторая 32-х битная эпоха. А под эпоху место под отдельную переменную зарезервированное есть. Интересно сколько лучше всего бит выделить по 32х битную эпоху.  
Ответить | Правка | Наверх | Cообщить модератору

52. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от kusb (?), 06-Мрт-23, 12:39 
> Да будет просто вторая 32-х битная эпоха. А под эпоху место под
> отдельную переменную зарезервированное есть. Интересно сколько лучше всего бит выделить
> по 32х битную эпоху.

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от kusb (?), 06-Мрт-23, 12:40 
А ещё такое провоцирует ошибки, потому что люди не будут проверять ещё и эпоху, может быть. И так же всё работает.
Ответить | Правка | Наверх | Cообщить модератору

58. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +4 +/
Сообщение от Admino (ok), 06-Мрт-23, 12:55 
> Да будет просто вторая 32-х битная эпоха.

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

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

164. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –2 +/
Сообщение от ИмяХ (?), 06-Мрт-23, 20:09 
>>месяца Последнего зерна,

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

Ответить | Правка | Наверх | Cообщить модератору

167. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Admino (ok), 06-Мрт-23, 20:35 
Thank Talos, it's fredas.
Ответить | Правка | Наверх | Cообщить модератору

209. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Обычный сиродильских НВахemail (?), 08-Мрт-23, 00:01 
Нет места прелестней во всём Нирне в это время года, чем Ввандерфел!

Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

44. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –5 +/
Сообщение от Аноним (44), 06-Мрт-23, 12:16 
Почему диды glibc на сишечке это не предусмотрели ещё 35 лет назад?
Ответить | Правка | Наверх | Cообщить модератору

45. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Аноним (32), 06-Мрт-23, 12:20 
Потому что с 640Кб оперативы было не разгуляться с размерами переменных.
Ответить | Правка | Наверх | Cообщить модератору

207. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от A (?), 07-Мрт-23, 22:54 
Потенциальное увеличение размера можно было учесть.

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

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

Ответить | Правка | Наверх | Cообщить модератору

60. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от crypt (ok), 06-Мрт-23, 12:58 
смотря, какие https://www.opennet.ru/openforum/vsluhforumID3/129920.html#59
Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

50. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (50), 06-Мрт-23, 12:32 
сразу нафиг - нефиг systemd прибивать гвозьдями
Ответить | Правка | Наверх | Cообщить модератору

54. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от freehckemail (ok), 06-Мрт-23, 12:45 
А я поддержу. При всей моей нелюбви к systemd, от данной интеграции сообщество выиграет: во-первых эта часть sd-login.h вполне себе reimplementable отдельно от systemd, во-вторых мы получим нормальное не нарушающее ABI разделение между старым и новым интерфейсами, причём хорошо так загодя до того, как грянет гром. Флаг им в руки.
Ответить | Правка | Наверх | Cообщить модератору

61. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (199), 06-Мрт-23, 12:58 
Разработчики devian просто добавят демон реализующий эту часть API logind и все.
Ответить | Правка | Наверх | Cообщить модератору

59. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от crypt (ok), 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.)

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

64. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +6 +/
Сообщение от Анонимemail (64), 06-Мрт-23, 13:01 
Gentoo с OpenRC -- наше всё! Хотя нет, ещё Guix с Shepherd. Ударим свободными системными менеджерами по блоатвари и разгильдяйству!
Ответить | Правка | Наверх | Cообщить модератору

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

лайк

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

Ответить | Правка | Наверх | Cообщить модератору

107. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (107), 06-Мрт-23, 14:28 
Очередной опеннетный эксперт не смог прочитать текст.
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

73. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (199), 06-Мрт-23, 13:23 

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

сразу всё понятно.
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

100. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Легивон (?), 06-Мрт-23, 14:10 
А вариант однократно перезагрузить все хосты в момент ошибки не рассматривался?
Если нужно делать это раз в 70 лет, то это не выглядит как проблема. И не подрывает SLA.
Ответить | Правка | Наверх | Cообщить модератору

102. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +3 +/
Сообщение от Аноним (102), 06-Мрт-23, 14:15 
Отличная идея. Завязать Glibc на Systemd, а потом дропнуть Systemd, объяснив всем, что Systemd устарел и уже очень старый, надо заменить на что-то новое. Отличный коллапс тогда будет, Стив Балмер аплодирует стоя
Ответить | Правка | Наверх | Cообщить модератору

105. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (104), 06-Мрт-23, 14:18 
Системд хоть к ядру шиндоуз жестко завязывай. Если ты уже всех подсадил делай что хочешь.  
Ответить | Правка | Наверх | Cообщить модератору

108. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от oficsu (ok), 06-Мрт-23, 14:42 
Класс, а давайте coreutils завяжем на systemd-logind, а что такого?
Ответить | Правка | Наверх | Cообщить модератору

109. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Аноним (109), 06-Мрт-23, 14:44 
А можно просто предположить, что залогинившихся 70 лет назад пользователей быть не может, и решить проблему патчем одной строчки glibc.
Ответить | Правка | Наверх | Cообщить модератору

115. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Ананоним (?), 06-Мрт-23, 15:14 
Странные разработчики. Они что, собираются возвращаться в прошлое на личной машине времени? Ну считали бы с 2037 года время с нуля и делов то...
Ответить | Правка | Наверх | Cообщить модератору

120. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от HyC (?), 06-Мрт-23, 15:34 
А рядом положить новые файлы с 64-битными счетчиками чтоб все к ним привыкли до 2038 года не судьба ?
Ответить | Правка | Наверх | Cообщить модератору

121. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (44), 06-Мрт-23, 15:35 
Перечитал новость. Оказывается, речь про 2038 год, то есть - нескоро. Хотя, местные специалисты недавольны, и могут уже сейчас форкать glibc, через 15 лет эти форки обгонят какой-то там glibc по качеству.
Ответить | Правка | Наверх | Cообщить модератору

126. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (3), 06-Мрт-23, 16:00 
Это уже практически завтра.
Ответить | Правка | Наверх | Cообщить модератору

134. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –3 +/
Сообщение от Аноним (199), 06-Мрт-23, 17:29 
https://github.com/linux-pam/linux-pam/pull/541

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от пох. (?), 06-Мрт-23, 18:11 
> Тем временем PAM уже переделали на logind

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

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

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


Ответить | Правка | Наверх | Cообщить модератору

151. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (199), 06-Мрт-23, 18:25 
О чем вы? systemd это клон launchd
Ответить | Правка | Наверх | Cообщить модератору

153. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (199), 06-Мрт-23, 18:32 
>А эпоха свободных людей в этом вашем опенсорсе прошла безвозвратно.

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

Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

154. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (199), 06-Мрт-23, 18:35 
Devian себе могут seatd поставить и будет менеджер сеансов, вообще не часть systemd и не привязанный к linux
Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

155. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от пох. (?), 06-Мрт-23, 18:39 
он уже научился вон с pam работать?
Ну и давайте, давайте - менеджер сеансов, менеджер фаянсов - так и перекопипастите весь systemd.

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

Ответить | Правка | Наверх | Cообщить модератору

148. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (199), 06-Мрт-23, 18:22 
Вместо старого интерфейса через бинарный файл в который может писать кто угодно, будет новый на основе менеджера сеансов. Вот кому от этого плохо?
И logind не один такой менеджер сеансов, остальные могут просто реализовать такой же API и всё.
Ответить | Правка | К родителю #134 | Наверх | Cообщить модератору

136. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от погроммист (?), 06-Мрт-23, 17:42 
Для избавления  от проблемы 2038 года предлагаю прекратить использование glibc.
Ответить | Правка | Наверх | Cообщить модератору

146. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от пох. (?), 06-Мрт-23, 18:12 
> Для избавления  от проблемы 2038 года предлагаю прекратить использование glibc.

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


Ответить | Правка | Наверх | Cообщить модератору

137. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Анонимemail (137), 06-Мрт-23, 17:46 
А если freebsd не использует systemd, gentoo и прочие дистрибутивы с сайта  https://nosystemd.org/ не использующие systemd. Всех прибивают гвозями к systemd, аудит безопасности которой никто не производил (там все слишком запутано).
Ответить | Правка | Наверх | Cообщить модератору

138. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (31), 06-Мрт-23, 17:47 
BSD не ипользует glibc. у них свой BSDшный libc
Ответить | Правка | Наверх | Cообщить модератору

157. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (159), 06-Мрт-23, 18:46 
> BSD не ипользует glibc. у них свой BSDшный libc

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

Ответить | Правка | Наверх | Cообщить модератору

165. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (31), 06-Мрт-23, 20:24 
Все приложения в линукс (из coreutils я полагаю). Ты думаешь в BSD работают линуксовые приложения, работающие в utmp?
Ответить | Правка | Наверх | Cообщить модератору

170. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –2 +/
Сообщение от Аноним (159), 06-Мрт-23, 21:14 
>> с приложениями, использующими utmp ... tcsh, xterm, ... дисплейные менеджеры, emacs, openssh
> Все приложения в линукс (из coreutils я полагаю).

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

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

Ответить | Правка | Наверх | Cообщить модератору

180. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (31), 07-Мрт-23, 01:58 
Что-то я сомневаюсь, что разработчики openbsd буду переписывать openssh под системд. tcsh, xterm появились ещё до линукса и, что самое важное, они используются не только в линукс и авторы с большой долей вероятности не будут их патчить под системд.
Ответить | Правка | Наверх | Cообщить модератору

194. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (159), 07-Мрт-23, 13:02 
Что-то я сомневаюсь, что _те_ авторы xterm и tcsh вообще еще что-то патчат.
Но речь шла о предложенном "решении", которое надежно и точно ломает совместимость с "нелинухами".

Ответить | Правка | Наверх | Cообщить модератору

175. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Tron is Whistling (?), 06-Мрт-23, 23:24 
utmp64 добавить совсем-совсем никак?
Ответить | Правка | Наверх | Cообщить модератору

179. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Ivan_83 (ok), 07-Мрт-23, 01:21 
Яиц просто нет у разрабов.

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

Ответить | Правка | Наверх | Cообщить модератору

186. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от IdeaFix (ok), 07-Мрт-23, 09:10 
Зачем в сусе думают от технологиях будущего?
Ответить | Правка | Наверх | Cообщить модератору

187. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +3 +/
Сообщение от Аноним (187), 07-Мрт-23, 09:13 
То есть заменить на 64-битный time_t трудоёмко, а на на systemd-logind - нет? Интересно.
Ответить | Правка | Наверх | Cообщить модератору

188. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Дворник (??), 07-Мрт-23, 10:06 
Летят цветные бумеранги..

`utmp`

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

Ответить | Правка | Наверх | Cообщить модератору

191. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +3 +/
Сообщение от Аноним (191), 07-Мрт-23, 10:47 
Скажи systemd НЕТ! Не плоди заразу в дистрах.
Ответить | Правка | Наверх | Cообщить модератору

197. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (-), 07-Мрт-23, 15:52 
Мне одному кажется, что используя удобный повод хотят пользователей тупо перевести на systemd-logind?

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

Ответить | Правка | Наверх | Cообщить модератору

200. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от pic (?), 07-Мрт-23, 18:16 
Нет. Согласен.
Ответить | Правка | Наверх | Cообщить модератору

216. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (-), 08-Мрт-23, 16:56 
> Мне одному кажется

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

Ответить | Правка | К родителю #197 | Наверх | Cообщить модератору

204. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +2 +/
Сообщение от Аноним (169), 07-Мрт-23, 19:57 
А что, если использовать тип 64-битный?
...
Да ну на! Давайте всё прибьём к системде!
Ответить | Правка | Наверх | Cообщить модератору

212. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (199), 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 чтобы было несовместимо с другими ос" они точно понимаю о чем пишут?

Ответить | Правка | Наверх | Cообщить модератору

213. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +/
Сообщение от Аноним (159), 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 назад, читая последний абзатц, в голову пришел бы МС или на крайняк, эппл ...

Ответить | Правка | Наверх | Cообщить модератору

215. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  –1 +/
Сообщение от Аноним (215), 08-Мрт-23, 15:57 
все ок, тут иксперты сидят, понимать надо
Ответить | Правка | К родителю #212 | Наверх | Cообщить модератору

217. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от keydon (ok), 09-Мрт-23, 13:35 
Выражу свою обострившуюся параною: всё подбивают под systemd (наверное как и предполагает EEE сделают альтернативу, но опцией, а опции как известно не в приоритете, и противникам systemd прибавится еще одна маленькая, но очередная, проблема), автор которого в мелкософте. Ну и аргументация прибития к systemd страдает. Звучит как еще один шажок (как всегда "безобидный") захвата линукса.
Ответить | Правка | Наверх | Cообщить модератору

219. "Для избавления Glibc от проблемы 2038 года предложено прекра..."  +1 +/
Сообщение от Аноним (219), 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 стоит обеспечить хотябы нормальное монтирование дисков.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру