The OpenNET Project / Index page

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

Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp

06.03.2023 09:26

Торстен Кукук (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.

19 января 2038 года произойдёт переполнение счётчиков эпохального времени, заданных 32-разрядным типом time_t. В библиотеке Glibc, несмотря на внедрение 64-разрядного типа time_t, для сохранения совместимости с 32-разрядными приложениями пространства пользователя в некоторых случаях на 64-разрядных платформах продолжает применяться 32-разрядный тип time_t. Одним из таких случаев является файл /var/run/utmp, хранящий данные о пользователях, в данный момент работающих в системе. Поле с временем в utmp задаётся с использованием 32-разрядного значения time_t.

Просто заменить поле со временем в utmp с 32-разрядного на 64-разрядный тип не получится, так как это приведёт к изменению ABI Glibc (изменится тип в функциях, подобных login(), getutid() и utmpname()) и нарушению совместимости с приложениями, использующими utmp, в числе которых w, who, uptime, login, su, sudo, useradd, systemd, sysvinit, tcsh, xterm дисплейные менеджеры, emacs, openssh, qemu, samba, rsyslog и т.п. Из-за обилия возможных подводных камней и трудоёмкости идея замены в utmp разрядности типа time_t была отвергнута разработчиками Glibc. По той же причине был отброшен вариант с использованием имеющегося в структуре utmp свободного пространства для добавления дополнительного 64-разрядного поля для времени.

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

При этом даже при решении проблемы с DoS-атаками содержимое utmp остаётся лишь информационным, не гарантирующим отражение реальной действительности. Например, разные эмуляторы и мультиплексоры терминалов по-разному отражают своё состояние - запуск пяти терминалов GNOME приведёт к отражению в utmp одного пользователя, а запуск пяти терминалов konsole или xterm в KDE - шести. Аналогично отличается поведение screen и tmux, в первом случае каждый сеанс учитывается как отдельный пользователь, а во втором отражается только один пользователь на все сеансы.

В итоге в качестве наиболее простого решения предлагается перевести все приложения на использование уже существующего альтернативного сервиса systemd-logind и после того как не останется актуальных программ, обращающихся к utmp, прекратить запись в utmp. Для замены wtmp предлагается подготовить программные интерфейсы для записи и чтения информации о пользователях при помощи systemd-journald. В кодовую базу следующего выпуска systemd 254 уже включены необходимые функции для предоставления заменяющих utmp данных через libsystemd с использованием API sd-login.h или через DBUS.

  1. Главная ссылка к новости (https://www.thkukuk.de/blog/Y2...)
  2. OpenNews: 14 июля эпохальное время Unix достигнет отметки в полтора миллиарда секунд
  3. OpenNews: 30 июня при синхронизации времени появится лишняя секунда
  4. OpenNews: Перевод мировых атомных часов на одну секунду привёл к массовому зависанию серверных приложений
  5. OpenNews: Решено с 2035 года приостановить синхронизацию мировых атомных часов с астрономическим временем
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/58750-utmp
Ключевые слова: utmp, wtmp, glibc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (185) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 10:35, 06/03/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]
  • +17 +/
     
     
  • 2.8, Аноним (8), 11:02, 06/03/2023 Скрыто ботом-модератором
  • +13 +/
     
     
  • 3.118, _hide_ (ok), 15:22, 06/03/2023 Скрыто ботом-модератором
  • –4 +/
     
     
  • 4.119, llolik (ok), 15:28, 06/03/2023 Скрыто ботом-модератором
  • +3 +/
     
  • 3.169, Аноним (169), 21:08, 06/03/2023 Скрыто ботом-модератором
  • +4 +/
     
     
  • 4.177, Аноним (177), 00:05, 07/03/2023 Скрыто ботом-модератором
  • +6 +/
     
  • 2.65, anonymous (??), 13:02, 06/03/2023 Скрыто ботом-модератором
  • +11 +/
     
     
  • 3.111, Аноним (111), 15:01, 06/03/2023 Скрыто ботом-модератором
  • +1 +/
     
  • 3.161, псевдонимус (?), 19:45, 06/03/2023 Скрыто ботом-модератором
  • +3 +/
     
  • 3.172, Аноним (169), 21:18, 06/03/2023 Скрыто ботом-модератором
  • –2 +/
     
  • 2.101, uis (??), 14:14, 06/03/2023 Скрыто ботом-модератором
  • +4 +/
     
  • 2.103, Аноним (103), 14:16, 06/03/2023 Скрыто ботом-модератором
  • +6 +/
     
  • 2.132, Kuromi (ok), 17:07, 06/03/2023 Скрыто ботом-модератором
  • +5 +/
     
     
  • 3.162, псевдонимус (?), 19:47, 06/03/2023 Скрыто ботом-модератором
  • –1 +/
     

     ....ответы скрыты модератором (13)

  • 1.2, ИмяХ (?), 10:35, 06/03/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]
  • +13 +/
     
     
  • 2.5, iPony129412 (?), 10:41, 06/03/2023 Скрыто ботом-модератором
  • –4 +/
     
  • 2.13, llolik (ok), 11:10, 06/03/2023 Скрыто ботом-модератором
  • +3 +/
     
  • 2.47, Аноним (47), 12:24, 06/03/2023 Скрыто ботом-модератором
  • +/
     
     
  • 3.163, ИмяХ (?), 20:03, 06/03/2023 Скрыто ботом-модератором
  • –1 +/
     
  • 3.176, Аноним (177), 00:01, 07/03/2023 Скрыто ботом-модератором
  • +1 +/
     

     ....ответы скрыты модератором (5)

  • 1.3, Аноним (3), 10:37, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +19 +/
    Идея полностью дропнуть 32 бита в libc звучит более здраво, чем прибить libc к сд-костылям.
     
     
  • 2.12, Аноним (12), 11:08, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Раз уже все равно все прикладухи надо переписывать (под использование systemd-login), не проще ли было таки пофиксить в них 32->64 бита?
     
     
  • 3.16, Аноним (169), 11:30, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > несмотря на внедрение 64-разрядного типа time_t, для сохранения совместимости с 32-разрядными приложениями пространства пользователя в некоторых случаях на 64-разрядных платформах продолжает применяться 32-разрядный тип time_t

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

     
     
  • 4.29, InuYasha (??), 11:55, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    "да ладно вам! ни один компьютер столько не проработает..."
     
     
  • 5.189, Аноним (189), 10:35, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > "да ладно вам! ни один компьютер столько не проработает..."

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

     
     
  • 6.192, Аноним (-), 11:08, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Забавно, как молодые ехидно ругают дидов за недальновидность, а сами прелагают абсолютно тоже самое - просто увеличить диапазон.

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

     
     
  • 7.196, Аноним (196), 14:08, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так и 32-битное число выбрали не потому что "хватит всем", а потому что регистры были 32-разрядные. Странно, что вообще приходится это объяснять, и сотни лет не прошло.
     
     
  • 8.199, Аноним (199), 18:05, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вы уверены что 50 лет назад регистры были именно 32 битные ... текст свёрнут, показать
     
     
  • 9.201, Совершенно другой аноним (?), 18:57, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее 18-ти разрядные Если интересна история, то почитать можно тут https e... текст свёрнут, показать
     
  • 7.221, Аноним (221), 19:19, 11/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Только диапазон теперь будет больше 100 миллиардов лет. Уверен, что человечество столько
    > просуществует?

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

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

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

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

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

     
     
  • 8.222, Аноним (222), 19:23, 11/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А лёгкие элементы сгорят в термоядерном синтезе ... текст свёрнут, показать
     
  • 3.32, Аноним (32), 12:03, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Проще, но как тебя принудить к использованию зонда от правильной компании?
     
  • 3.95, не придумал (?), 13:57, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    думать запрещено, сказали на систем д, значит на систем д
     
  • 3.220, Аноним (221), 19:18, 11/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Раз уже все равно все прикладухи надо переписывать (под использование systemd-login), не
    > проще ли было таки пофиксить в них 32->64 бита?

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

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

     
  • 2.33, Admino (ok), 12:04, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, именно это авторы glibc и решили сделать.
     
  • 2.183, Аноним (-), 08:48, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Идея полностью дропнуть 32 бита в libc звучит более здраво

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

     
     
  • 3.203, пох. (?), 19:37, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    просто в следующей версии выбросят эти немодные устаревшие порты.
    Будете клепать эмбедовку на 64разрядных кипятильниках.
    Нефти - ж-пой жуй, газа - до х:я, угля мегатонны (но уголь только на пол-шишечки, не дальше 2028 года объявлен экологичненьким). АЭС вот ниикaлaгичны - их запретили прямо в этом году.

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

     
  • 3.210, Алексей (??), 07:14, 08/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Там musl, uclibc, и т.п., а потому всё равно, что, как, и когда выкинут из glibc. Это раз.

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


     
  • 3.223, фф (?), 09:07, 14/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ну дык после 2038 года время просто не влезет в эти 32 бита, и что тогда делать этой эмбедовке? жить в 1970-м?
    поле все равно надо расширять всем, не важно сколько бит влезает в регистры.
     
     
  • 4.225, Аноним (225), 20:54, 03/01/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А 32-разрядной ембеддовке принципиально запрещается использовать time64_t ?
     

  • 1.4, iPony129412 (?), 10:39, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    В будущее с Кукуком ☝️
    Главное вовремя выкидывать усаревшие технологии
     
     
  • 2.74, пох. (?), 13:24, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Да уж, тут ты прав. Выкинул бы я устаревшую технологию юникса еще в 90е - сейчас бы был богаче, успешнее и совсем не беспокоился бы ни о следующем месте работы, ни о безбедной старости.
    Толку от нее сегодня все равно около нуля.

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

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

     
     
  • 3.91, Аноним (91), 13:46, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Ой, да ладно тебе. Зато ты можешь с умным (не всегда) видом писать комментарии тут. Это ли не успех?
     
  • 2.184, Аноним (-), 08:50, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Главное вовремя выкидывать усаревшие технологии

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

     
     
  • 3.193, xPhoenix (ok), 11:21, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сколько лет вилкам, ложкам и чайникам? А резьбовые соединения удалось заменить на что-то другое? Уууу! Отсталые!

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

     
  • 3.202, пох. (?), 19:32, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > И как, выкинул уже хотя-бы ДВС-ы и свинцовокислотные акумы? XIX век, аж, а до сих пор
    > в куче автомобилей...

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

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

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

     
     
  • 4.208, аноним.orig (?), 23:25, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Только свинцовые аккумуляторы даже в упсах стоят.
    Так что резать будут как обычно — по повесточке.
     
  • 2.205, A (?), 22:45, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Главное вовремя выкидывать усаревшие технологии

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

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

     
     
  • 3.211, Аноним (211), 13:12, 08/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это просто Поттеринг до туда ещё не добрался :)
     

  • 1.6, Аноним (6), 10:44, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Просто заменить поле со временем в utmp с 32-разрядного на 64-разрядный тип не получится
    > так как это приведёт к ... нарушению совместимости с приложениями, использующими utmp
    > В итоге ... предлагается перевести все приложения на ... systemd-logind
    > и после того как не останется актуальных программ, обращающихся к utmp, ...
     
  • 1.7, Аноним (7), 10:46, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +15 +/
    Т.е. смена ABI это опасносте, а systemd-logind окнорм?
     
     
  • 2.9, НяшМяш (ok), 11:02, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    - Сохраняем ABI
    - В 2038 году все приложения ломаются
    - "Кококо надо было переходить на systemd-olologind"

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

     
     
  • 3.34, Аноним (32), 12:05, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Так если всё равно все приложения переписывать и в случае перехода на 64 бита и в случае принудительного системд. Можно сразу покарать всех хомячков и прибить их к системд я считаю здраво. Хомячки должны страдать.  
     
  • 3.81, Аноним (81), 13:32, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Надо было менять ABI. ABI - не API, решается перекомпиляцией софта.
     
  • 3.106, uis (??), 14:23, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Чтобы не ломать ABI, мы сломаем API. Хотя и ABI сломаем тоже.
     
  • 3.185, Аноним (-), 08:52, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > - "Кококо надо было переходить на systemd-olologind"

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

     

  • 1.10, Аноним (10), 11:03, 06/03/2023 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]
  • +/
     
     
  • 2.48, Аноним (47), 12:25, 06/03/2023 Скрыто ботом-модератором
  • +/
     
     
  • 3.55, anonymous (??), 12:48, 06/03/2023 Скрыто ботом-модератором
  • +6 +/
     
     
  • 4.112, Аноним (112), 15:02, 06/03/2023 Скрыто ботом-модератором
  • +2 +/
     
     
  • 5.124, anonymous (??), 15:38, 06/03/2023 Скрыто ботом-модератором
  • +/
     
  • 4.168, анон (?), 20:55, 06/03/2023 Скрыто ботом-модератором
  • –1 +/
     

     ....ответы скрыты модератором (5)

  • 1.14, Аноним (14), 11:14, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Проще не значит лучше, нужно просто в саму glibc внести все необходимые функции без привязки к systemd.
     
     
  • 2.25, Аноним (25), 11:46, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >нужно просто в саму glibc внести все необходимые функции
    >просто

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

     
  • 2.35, Admino (ok), 12:05, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, именно это авторы glibc и решили сделать.
     
  • 2.114, Аноним (-), 15:04, 06/03/2023 Скрыто ботом-модератором
  • +/
     

  • 1.15, Массоны Рептилоиды (?), 11:28, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > лидер группы по развитию технологий будущего

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

     
     
  • 2.129, ivan_erohin (?), 16:25, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    ну и что бы вы откопали ?
    завести /var/run/*tmp64t и прогибать юзерлэнд чтобы читали и писали в туда ?
     

  • 1.17, Аноним (199), 11:32, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хорошо. Если logind нет нужно просто написать демон с таким же API как у logind
     
     
  • 2.18, Аноним (199), 11:33, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    https://wiki.gentoo.org/wiki/Elogind
     
     
  • 3.147, Ня тян (?), 18:20, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +5 +/
    оооо, какая же ламповая эта вики) меньше по объёму чем у арча, но в моём сердечке на первом месте, ибо часов за чашкой горячего кофе в ней проведено немерено
     
  • 2.20, Аноним (199), 11:35, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В комментариях конечно параксизм ненависти от "экспертов" и прожжённые стулья
    Это ясно надо не читая
     
     
  • 3.23, kusb (?), 11:40, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Оправдано.
     
  • 2.21, Аноним (199), 11:37, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://sr.ht/~kennylevinsen/seatd/
     
     
  • 3.24, Аноним (24), 11:43, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо. Есть еще надежда.
     

  • 1.19, Аноним (169), 11:33, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Если всё равно надо переписывать приложения, то почему именно на системду?!
     
     
  • 2.22, kusb (?), 11:38, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно вы путаете причину и следствие. Сначала ищут причины, по которым переписывание на системду может быть полезным.
     
     
  • 3.36, Аноним (32), 12:06, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да полезным для кого? Как говорится Шерше ля фам.
     
     
  • 4.49, kusb (?), 12:32, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Да полезным для кого? Как говорится Шерше ля фам.

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

     
     
  • 5.76, пох. (?), 13:27, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для rhbm очень даже полезно.
    А вы - не владельцы, у вас ничего не было и нет.
    И не будет уже.

     
     
  • 6.85, Аноним (81), 13:40, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А у тебя есть?
     
  • 6.143, Аноним (199), 17:59, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно полезно, у них поддержка дистрибутива 15 лет с сохранением ABI. Им нужно уже сейчас проблему решать.
     
  • 2.56, Аноним (199), 12:53, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Потому что systemd это стандарт. Разработчикам не хочется изобретать велосипед с квадратными колесами, когда есть готовый хороший менеджер сеансов
     
     
  • 3.77, пох. (?), 13:28, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Когда есть готовый монолитный паровоз с треугольными.

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

     
     
  • 4.89, Аноним (89), 13:44, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Пусть так. Никто не предложил лучше, остальные только балаболить и гореть могут.
     
     
  • 5.116, пох. (?), 15:20, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    естественно - у остальных-то нет права комитов в глибс (и зарплаты от rhbm)
     
     
  • 6.141, Аноним (199), 17:56, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.redhat.com/en/blog/patches-welcome-how-contribute-upstream-glibc

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

     
     
  • 7.144, пох. (?), 18:06, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    покажешь хоть один принятый твой патч?

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

     
     
  • 8.156, Аноним (199), 18:44, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Покажи хоть один твой опровергнутый патч Фантазировать на тему бездонности dev... текст свёрнут, показать
     
     
  • 9.158, пох. (?), 18:49, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    слив засчитан Нет там твоих патчей А, ну да, ты ж не умеешь кодить ... текст свёрнут, показать
     
  • 3.130, ivan_erohin (?), 16:29, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Потому что systemd это стандарт.

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

     
  • 2.181, Аноним (181), 02:42, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Принципы проектирования ПО и здравый смысл говорят о том, что привязываться надо не к системд, а к формально описанному стандартизированному API.

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

     

  • 1.26, InuYasha (??), 11:50, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    То чувство, когда ты, живя в бум компьютерных технологий 1980ых, разрабатываешь костыли под очередной процессор, а 30 лет спустя получаешь ими по бошке.

    > Future Technology Team

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

     
     
  • 2.182, Аноним (182), 06:40, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Y2K

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

     

  • 1.27, Ананий (?), 11:51, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интересно, как проблему будут рушать во FreeBSD.
    Уж там-то точно не будет системд.
     
     
  • 2.28, kusb (?), 11:53, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Теперь будет
     
  • 2.31, Аноним (31), 12:03, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо будут обновлять w, who, uptime, login, su, sudo, useradd, tcsh, xterm дисплейные менеджеры, emacs, openssh, qemu и т.п
     
     
  • 3.160, r1 (?), 19:02, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поди успеют за 15 лет то.... в отличии от
     
  • 2.37, Аноним (32), 12:06, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Её не будут решать фрёй в 2038 никто уже не будет пользоваться.  
     
     
  • 3.43, cd (?), 12:14, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а от линyпсa останется одна системдa
     
  • 3.67, Аноним (67), 13:06, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Её не будут решать фрёй в 2038 никто уже не будет пользоваться.

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


     
     
  • 4.104, Аноним (104), 14:16, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Решили потому что знали что всё равно будет не нужна. Да и зависимостей у неё мало потому что софта тоже нет.  
     
  • 2.63, Аноним (67), 13:01, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Интересно, как проблему будут рушать во FreeBSD.

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

     
     
  • 3.70, Аноним (67), 13:14, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Интересно, как проблему будут рушать во 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.)
    >

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

     
  • 2.78, Аноним (31), 13:29, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    насколько я понял это проблема glibc от проекта GNU, в BSD-системах свои BSD libc, к-е вроде как не подвержены этой проблеме.
     
     
  • 3.159, Аноним (159), 18:49, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > насколько я понял это проблема glibc от проекта GNU, в BSD-системах свои BSD libc, к-е вроде как не подвержены этой проблеме.

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


     
  • 2.82, пох. (?), 13:35, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    они ее так порешали что лучше бы уж не решали - как все последние достижения этого гальванизируемого трупа.

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

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

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

     
  • 2.178, YetAnotherOnanym (ok), 00:36, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > как проблему будут рушать во FreeBSD

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

     
  • 2.224, фф (?), 09:12, 14/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    не знаю как там фряха, в опенке еще в прошлом десятилетии просто сменили размерность на 64 бита, и кто не спрятался, тот сам виноват. Я ручками exim правил при обновлении системы например.
     

  • 1.38, Admino (ok), 12:06, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Я насчитал пять человек, которые не смогли прочитать текст новости целиком, а вместо этого увидели слова "glibc" и "systemd" и решили, что теперь glibc будет прибита гвоздями к systemd.

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

     
     
  • 2.51, kusb (?), 12:37, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Я новость читал невнимательно, но комментарии внимательнее. Из них я понял, что это программы хотят привязать к ней, а до этого они пользовались функциями Glibc какими-то.
    Ничего особенно не знаю что там они делают, но они возвращают какое-то значение, где мало байтиков и оно растёт со временем (может быть это время) и размер который был там выделен переполнится в будущем.
    Правда я нефига не понял, они типа хотят сохранить обратную совместимость и не могут увеличить размер до 64, но могут заставить программы обращаться к systemd. И то и другое по моему одинаково ломает эту совместимость.

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

     
     
  • 3.57, Admino (ok), 12:53, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не функциями, а файлом Файл называется utmp и лежит в нужном месте И вот в нём... большой текст свёрнут, показать
     
  • 2.195, Имя (?), 13:49, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то сам заголовок статьи сформулирован так, что максимально вводит в заблуждение, так что не нужно удивлятся.
    >Для избавления Glibc от проблемы 2038 года предложено прекратить использование utmp
     
     
  • 3.198, Admino (ok), 16:28, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да. Больше хайпа богу хайпа.
     

  • 1.39, Аноним (39), 12:07, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Вместо пустопорожнего трепа дружно переходим на Devuan и по мере сил и возможностей портируем недостающие пакеты в репы.
    Вот тогда это будет *реальная* помощь в борьбе с systemd
     
     
  • 2.71, Аноним (71), 13:17, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И в 2038 году дружно выкидываем Devuan в помойку (так-то вряд ли кто про него через пятнадцать лет вспомнит, но мало ли).
    Впрочем, школьники в категориях таких сроков не мыслят.
     
     
  • 3.122, Аноним (199), 15:36, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    У redhat 9 поддержка заканчивается в 2034 году, а у redhat 10 примерно в 37-38
    И ABI redhat не меняет.
    Мне кажется, разработчикам, желательно решить проблему заранее  проблему решить как-нибудь
     
  • 2.133, Анеони (?), 17:29, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    уже.

     

  • 1.40, ip1982 (ok), 12:08, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    > лидер группы по развитию технологий будущего

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

     
  • 1.41, ip1982 (ok), 12:12, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В чём проблема писать 32-битное время? Если оно больше нуля, значит после 2038-го года :) К тому времени 32-битные приложения сами отомрут.
     
     
  • 2.46, Аноним (32), 12:22, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да будет просто вторая 32-х битная эпоха. А под эпоху место под отдельную переменную зарезервированное есть. Интересно сколько лучше всего бит выделить по 32х битную эпоху.  
     
     
  • 3.52, kusb (?), 12:39, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Да будет просто вторая 32-х битная эпоха. А под эпоху место под
    > отдельную переменную зарезервированное есть. Интересно сколько лучше всего бит выделить
    > по 32х битную эпоху.

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

     
     
  • 4.53, kusb (?), 12:40, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А ещё такое провоцирует ошибки, потому что люди не будут проверять ещё и эпоху, может быть. И так же всё работает.
     
  • 3.58, Admino (ok), 12:55, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Да будет просто вторая 32-х битная эпоха.

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

     
     
  • 4.164, ИмяХ (?), 20:09, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >>месяца Последнего зерна,

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

     
     
  • 5.167, Admino (ok), 20:35, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Thank Talos, it's fredas.
     
  • 5.209, Обычный сиродильских НВах (?), 00:01, 08/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет места прелестней во всём Нирне в это время года, чем Ввандерфел!

     
  • 2.206, A (?), 22:50, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >  К тому времени 32-битные приложения сами отомрут.

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

     

  • 1.42, Аноним (42), 12:13, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    >  В кодовую базу следующего выпуска systemd 254 уже включены необходимые функции для предоставления заменяющих utmp данных через libsystemd с использованием API sd-login.h или через DBUS.

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

     
  • 1.44, Аноним (44), 12:16, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Почему диды glibc на сишечке это не предусмотрели ещё 35 лет назад?
     
     
  • 2.45, Аноним (32), 12:20, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что с 640Кб оперативы было не разгуляться с размерами переменных.
     
     
  • 3.207, A (?), 22:54, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Потенциальное увеличение размера можно было учесть.

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

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

     
  • 2.60, crypt (ok), 12:58, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    смотря, какие https://www.opennet.ru/openforum/vsluhforumID3/129920.html#59
     

  • 1.50, Аноним (50), 12:32, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    сразу нафиг - нефиг systemd прибивать гвозьдями
     
  • 1.54, freehck (ok), 12:45, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А я поддержу. При всей моей нелюбви к systemd, от данной интеграции сообщество выиграет: во-первых эта часть sd-login.h вполне себе reimplementable отдельно от systemd, во-вторых мы получим нормальное не нарушающее ABI разделение между старым и новым интерфейсами, причём хорошо так загодя до того, как грянет гром. Флаг им в руки.
     
     
  • 2.61, Аноним (199), 12:58, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Разработчики devian просто добавят демон реализующий эту часть API logind и все.
     

  • 1.59, crypt (ok), 12:56, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    было приятно узнать, что 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.)

     
  • 1.62, Аноним (81), 12:58, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >предлагается перевести на получение списка пользователей при помощи systemd-logind

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

     
  • 1.64, Аноним (64), 13:01, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Gentoo с OpenRC -- наше всё! Хотя нет, ещё Guix с Shepherd. Ударим свободными системными менеджерами по блоатвари и разгильдяйству!
     
     
  • 2.152, Аноним (-), 18:31, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Gentoo с OpenRC -- наше всё! Хотя нет, ещё Guix с Shepherd.
    > Ударим свободными системными менеджерами по блоатвари и разгильдяйству!

    лайк

     

  • 1.72, _kp (ok), 13:19, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >>Просто заменить поле со временем в utmp с 32-разрядного на 64-разрядный тип не получится, так как это приведёт к изменению ABI Glibc

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

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

     
     
  • 2.84, пох. (?), 13:39, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    можно ж - уже примотали. И ничего, и это сожрете.

     
  • 2.107, Аноним (107), 14:28, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Очередной опеннетный эксперт не смог прочитать текст.
     

  • 1.73, Аноним (199), 13:23, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/



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



    сразу всё понятно.
     
  • 1.90, Аноним (90), 13:45, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >предлагается перевести на получение списка пользователей при помощи systemd-logind.

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

     
  • 1.100, Легивон (?), 14:10, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А вариант однократно перезагрузить все хосты в момент ошибки не рассматривался?
    Если нужно делать это раз в 70 лет, то это не выглядит как проблема. И не подрывает SLA.
     
  • 1.102, Аноним (102), 14:15, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Отличная идея. Завязать Glibc на Systemd, а потом дропнуть Systemd, объяснив всем, что Systemd устарел и уже очень старый, надо заменить на что-то новое. Отличный коллапс тогда будет, Стив Балмер аплодирует стоя
     
     
  • 2.105, Аноним (104), 14:18, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Системд хоть к ядру шиндоуз жестко завязывай. Если ты уже всех подсадил делай что хочешь.  
     

  • 1.108, oficsu (ok), 14:42, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Класс, а давайте coreutils завяжем на systemd-logind, а что такого?
     
  • 1.109, Аноним (109), 14:44, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А можно просто предположить, что залогинившихся 70 лет назад пользователей быть не может, и решить проблему патчем одной строчки glibc.
     
  • 1.115, Ананоним (?), 15:14, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Странные разработчики. Они что, собираются возвращаться в прошлое на личной машине времени? Ну считали бы с 2037 года время с нуля и делов то...
     
  • 1.120, HyC (?), 15:34, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А рядом положить новые файлы с 64-битными счетчиками чтоб все к ним привыкли до 2038 года не судьба ?
     
  • 1.121, Аноним (44), 15:35, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Перечитал новость. Оказывается, речь про 2038 год, то есть - нескоро. Хотя, местные специалисты недавольны, и могут уже сейчас форкать glibc, через 15 лет эти форки обгонят какой-то там glibc по качеству.
     
     
  • 2.126, Аноним (3), 16:00, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже практически завтра.
     

  • 1.134, Аноним (199), 17:29, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    https://github.com/linux-pam/linux-pam/pull/541

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

     
     
  • 2.145, пох. (?), 18:11, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Тем временем PAM уже переделали на logind

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

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

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


     
     
  • 3.151, Аноним (199), 18:25, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    О чем вы? systemd это клон launchd
     
  • 3.153, Аноним (199), 18:32, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    >А эпоха свободных людей в этом вашем опенсорсе прошла безвозвратно.

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

     
  • 3.154, Аноним (199), 18:35, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Devian себе могут seatd поставить и будет менеджер сеансов, вообще не часть systemd и не привязанный к linux
     
     
  • 4.155, пох. (?), 18:39, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    он уже научился вон с pam работать?
    Ну и давайте, давайте - менеджер сеансов, менеджер фаянсов - так и перекопипастите весь systemd.

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

     
  • 2.148, Аноним (199), 18:22, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вместо старого интерфейса через бинарный файл в который может писать кто угодно, будет новый на основе менеджера сеансов. Вот кому от этого плохо?
    И logind не один такой менеджер сеансов, остальные могут просто реализовать такой же API и всё.
     

  • 1.136, погроммист (?), 17:42, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для избавления  от проблемы 2038 года предлагаю прекратить использование glibc.
     
     
  • 2.146, пох. (?), 18:12, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Для избавления  от проблемы 2038 года предлагаю прекратить использование glibc.

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


     

  • 1.137, Аноним (137), 17:46, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А если freebsd не использует systemd, gentoo и прочие дистрибутивы с сайта  https://nosystemd.org/ не использующие systemd. Всех прибивают гвозями к systemd, аудит безопасности которой никто не производил (там все слишком запутано).
     
     
  • 2.138, Аноним (31), 17:47, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    BSD не ипользует glibc. у них свой BSDшный libc
     
     
  • 3.157, Аноним (159), 18:46, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > BSD не ипользует glibc. у них свой BSDшный libc

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

     
     
  • 4.165, Аноним (31), 20:24, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Все приложения в линукс (из coreutils я полагаю). Ты думаешь в BSD работают линуксовые приложения, работающие в utmp?
     
     
  • 5.170, Аноним (159), 21:14, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> с приложениями, использующими utmp ... tcsh, xterm, ... дисплейные менеджеры, emacs, openssh
    > Все приложения в линукс (из coreutils я полагаю).

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

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

     
     
  • 6.180, Аноним (31), 01:58, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то я сомневаюсь, что разработчики openbsd буду переписывать openssh под системд. tcsh, xterm появились ещё до линукса и, что самое важное, они используются не только в линукс и авторы с большой долей вероятности не будут их патчить под системд.
     
     
  • 7.194, Аноним (159), 13:02, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то я сомневаюсь, что _те_ авторы xterm и tcsh вообще еще что-то патчат.
    Но речь шла о предложенном "решении", которое надежно и точно ломает совместимость с "нелинухами".

     

  • 1.175, Tron is Whistling (?), 23:24, 06/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    utmp64 добавить совсем-совсем никак?
     
  • 1.179, Ivan_83 (ok), 01:21, 07/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Яиц просто нет у разрабов.

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

     
  • 1.186, IdeaFix (ok), 09:10, 07/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем в сусе думают от технологиях будущего?
     
  • 1.187, Аноним (187), 09:13, 07/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    То есть заменить на 64-битный time_t трудоёмко, а на на systemd-logind - нет? Интересно.
     
  • 1.188, Дворник (??), 10:06, 07/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Летят цветные бумеранги..

    'utmp'

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

     
  • 1.191, Аноним (191), 10:47, 07/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Скажи systemd НЕТ! Не плоди заразу в дистрах.
     
  • 1.197, Аноним (-), 15:52, 07/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мне одному кажется, что используя удобный повод хотят пользователей тупо перевести на systemd-logind?

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

     
     
  • 2.200, pic (?), 18:16, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Согласен.
     
  • 2.216, Аноним (-), 16:56, 08/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне одному кажется

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

     

  • 1.204, Аноним (169), 19:57, 07/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А что, если использовать тип 64-битный?
    ...
    Да ну на! Давайте всё прибьём к системде!
     
  • 1.212, Аноним (199), 14:01, 08/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    man utmp POSIX 1 does not specify a utmp structure, but rather one named utmpx,... большой текст свёрнут, показать
     
     
  • 2.213, Аноним (159), 15:13, 08/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но есть один нюанс, Петька https man freebsd org cgi man cgi query utmp... большой текст свёрнут, показать
     
  • 2.215, Аноним (215), 15:57, 08/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    все ок, тут иксперты сидят, понимать надо
     

  • 1.217, keydon (ok), 13:35, 09/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Выражу свою обострившуюся параною: всё подбивают под systemd (наверное как и предполагает EEE сделают альтернативу, но опцией, а опции как известно не в приоритете, и противникам systemd прибавится еще одна маленькая, но очередная, проблема), автор которого в мелкософте. Ну и аргументация прибития к systemd страдает. Звучит как еще один шажок (как всегда "безобидный") захвата линукса.
     
  • 1.219, Аноним (219), 18:59, 11/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    code ls -l var run utmp -rw-rw-r-- 1 root utmp 3840 Mar 11 22 43 var run utm... большой текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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