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

"Для избавления 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. Сообщение от Аноним (1), 06-Мрт-23, 10:35	+17 +/–
Ура, товарищи, прибьем glibc ржавыми гвоздями к systemd! Glibc надо переименовать linux-only c library - LoLibc, как вам такое?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #65, #101, #103, #132

2. Сообщение от ИмяХ (?), 06-Мрт-23, 10:35	+13 +/–
Шикарно. Теперь ещё и glibc будет зависеть от systemd. Вот Лёнька молодец, всех под себя подмял!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #13, #47

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

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

5. Сообщение от iPony129412 (?), 06-Мрт-23, 10:41	–4 +/–
Тут вспоминается одна пословица про то как не захочет - не вскочит. В оригинале боюсь приводить. Зоотематика всё же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

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

7. Сообщение от Аноним (7), 06-Мрт-23, 10:46	+15 +/–
Т.е. смена ABI это опасносте, а systemd-logind окнорм?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9

8. Сообщение от Аноним (8), 06-Мрт-23, 11:02	+13 +/–
Юз йор факин айз: Change all applications, which read utmp, to query systemd-logind instead. То есть к системдосу будут прибивать приложения, а не глибц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #118, #169

9. Сообщение от НяшМяш (ok), 06-Мрт-23, 11:02	+6 +/–
- Сохраняем ABI - В 2038 году все приложения ломаются - "Кококо надо было переходить на systemd-olologind" Могли бы выпустить Glibc версии 3.0. Раз всё равно приложение чинить и пересобирать ¯\_(ツ)_/¯
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #34, #81, #106, #185

10. Сообщение от Аноним (10), 06-Мрт-23, 11:03	+/–
Будем надеяться, что Линукс покажет этому дядке большой 64-битный палец
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48

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

13. Сообщение от llolik (ok), 06-Мрт-23, 11:10	+3 +/–
Читаем внимательно, да > Все приложения, использующие utmp, wtmp и lastlog, предлагается перевести на получение списка пользователей при помощи systemd-logind. > Все ПРИЛОЖЕНИЯ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

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

15. Сообщение от Массоны Рептилоиды (?), 06-Мрт-23, 11:28	+/–
> лидер группы по развитию технологий будущего Ничего не выйдёт без согласования с лидером по откапыванию технологий прошлого
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #129

16. Сообщение от Аноним (169), 06-Мрт-23, 11:30	+3 +/–
> несмотря на внедрение 64-разрядного типа time_t, для сохранения совместимости с 32-разрядными приложениями пространства пользователя в некоторых случаях на 64-разрядных платформах продолжает применяться 32-разрядный тип time_t - А что, если в 64-битных аппликухах использовать 64-разрядный time_t, ведь 32-оси уже давно дропнуты? ... - Да ну на! Давайте на 64-разрядных платформах юзать 32-разрядный time_t!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #29

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

18. Сообщение от Аноним (199), 06-Мрт-23, 11:33	+5 +/–
https://wiki.gentoo.org/wiki/Elogind
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #147

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

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

21. Сообщение от Аноним (199), 06-Мрт-23, 11:37	+1 +/–
https://sr.ht/~kennylevinsen/seatd/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #24

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

23. Сообщение от kusb (?), 06-Мрт-23, 11:40	+/–
Оправдано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

24. Сообщение от Аноним (24), 06-Мрт-23, 11:43	+/–
Спасибо. Есть еще надежда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от Аноним (25), 06-Мрт-23, 11:46	+5 +/–
>нужно просто в саму glibc внести все необходимые функции >просто Ну так внеси, если просто. Пока там эти дурачки разговоры разговаривают, ты покажи как надо работу делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

26. Сообщение от InuYasha (??), 06-Мрт-23, 11:50	–2 +/–
То чувство, когда ты, живя в бум компьютерных технологий 1980ых, разрабатываешь костыли под очередной процессор, а 30 лет спустя получаешь ими по бошке. > Future Technology Team Создана после хаоса Y2K? :D
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #182

27. Сообщение от Ананий (?), 06-Мрт-23, 11:51	+1 +/–
Интересно, как проблему будут рушать во FreeBSD. Уж там-то точно не будет системд.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28, #31, #37, #63, #78, #82, #178, #224

28. Сообщение от kusb (?), 06-Мрт-23, 11:53	+1 +/–
Теперь будет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

29. Сообщение от InuYasha (??), 06-Мрт-23, 11:55	+2 +/–
"да ладно вам! ни один компьютер столько не проработает..."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #189

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

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

33. Сообщение от Admino (ok), 06-Мрт-23, 12:04	+/–
Да, именно это авторы glibc и решили сделать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

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

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

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

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

38. Сообщение от Admino (ok), 06-Мрт-23, 12:06	+5 +/–
Я насчитал пять человек, которые не смогли прочитать текст новости целиком, а вместо этого увидели слова "glibc" и "systemd" и решили, что теперь glibc будет прибита гвоздями к systemd. Опеннет-эксперты as it is.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51, #195

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

40. Сообщение от ip1982 (ok), 06-Мрт-23, 12:08	+8 +/–
> лидер группы по развитию технологий будущего Сколько пафоса!
Ответить | Правка | Наверх | Cообщить модератору

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

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

43. Сообщение от cd (?), 06-Мрт-23, 12:14	+2 +/–
а от линyпсa останется одна системдa
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

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

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

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

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

48. Сообщение от Аноним (47), 06-Мрт-23, 12:25	+/–
КТО такой Линукс?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #55

49. Сообщение от kusb (?), 06-Мрт-23, 12:32	+/–
> Да полезным для кого? Как говорится Шерше ля фам. Я это подразумевал. Полезным не то чтобы для владельцев ОС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #76

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

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

52. Сообщение от kusb (?), 06-Мрт-23, 12:39	+/–
> Да будет просто вторая 32-х битная эпоха. А под эпоху место под > отдельную переменную зарезервированное есть. Интересно сколько лучше всего бит выделить > по 32х битную эпоху. А что будет, когда переполнится счётчик эпох?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #53

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

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

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

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

57. Сообщение от Admino (ok), 06-Мрт-23, 12:53	+4 +/–
> Я новость читал невнимательно, но комментарии внимательнее. Из них я понял, что > это программы хотят привязать к ней, а до этого они пользовались > функциями Glibc какими-то. Не функциями, а файлом. Файл называется utmp и лежит в нужном месте. И вот в нём отметки времени в uint32. > Правда я нефига не понял, они типа хотят сохранить обратную совместимость и > не могут увеличить размер до 64, но могут заставить программы обращаться > к systemd. Они хотят убрать формирование файлика utmp вообще, чтобы программы брали эту информацию из других мест. Например, через systemd. Но можно сделать и другие интерфейсы. BSD без опасносте. Файлик этот всё равно надо выкидывать, потому что разные программы с ним всё равно работают по-разному, плюс вопросы безопасных прав записи, плюс возможность DDOS. Поэтому разработчики glibc не хотят просто менять шило на мыло и делать файлик utmp64, лучше сделать сразу по-нормальному. > И то и другое по моему одинаково ломает эту > совместимость. Нельзя просто взять и выкинуть старый код, совместимость так или иначе придётся сломать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

58. Сообщение от Admino (ok), 06-Мрт-23, 12:55	+4 +/–
> Да будет просто вторая 32-х битная эпоха. Сегодня – 28, месяца Последнего зерна, 433 год эпохи Акатоша. Близятся последние дни третьей эры, и последние часы моей жизни…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #164

59. Сообщение от crypt (ok), 06-Мрт-23, 12:56	+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.)
Ответить | Правка | Наверх | Cообщить модератору

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

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

62. Сообщение от Аноним (81), 06-Мрт-23, 12:58	+/–
>предлагается перевести на получение списка пользователей при помощи systemd-logind Совсем кукукнулся этот Thorsten Kukuk.
Ответить | Правка | Наверх | Cообщить модератору

63. Сообщение от Аноним (67), 06-Мрт-23, 13:01	+2 +/–
> Интересно, как проблему будут рушать во FreeBSD. Там, внезапно, своя libc и формат записи не прибит к конкретной разрядности (т.е. на 64-битных платформах он уже давно 64 бита).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #70

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

65. Сообщение от anonymous (??), 06-Мрт-23, 13:02	+11 +/–
А мы будем жить в 2038 году?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #111, #161, #172

67. Сообщение от Аноним (67), 06-Мрт-23, 13:06	+1 +/–
> Её не будут решать фрёй в 2038 никто уже не будет пользоваться. Её не будут решать, потому что её уже решили еще 20 лет назад, в отличие от "светочей прогресса" https://people.freebsd.org/~peter/time64.diff
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #104

70. Сообщение от Аноним (67), 06-Мрт-23, 13:14	+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.) > Такие вот замшелые, непрогрессивные технологии, че ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

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

72. Сообщение от _kp (ok), 06-Мрт-23, 13:19	–1 +/–
>>Просто заменить поле со временем в utmp с 32-разрядного на 64-разрядный тип не получится, так как это приведёт к изменению ABI Glibc А вот если похерить сам glibc - то это совсем другое дело. Вообще то glibc и сам по себе используется. И приматывать его скотчем к initd - нельзя.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #84, #107

73. Сообщение от Аноним (199), 06-Мрт-23, 13:23	–1 +/–
:~$ lastb lastb: невозможно открыть /var/log/btmp: Отказано в доступе сразу всё понятно.
Ответить | Правка | Наверх | Cообщить модератору

74. Сообщение от пох. (?), 06-Мрт-23, 13:24	–8 +/–
Да уж, тут ты прав. Выкинул бы я устаревшую технологию юникса еще в 90е - сейчас бы был богаче, успешнее и совсем не беспокоился бы ни о следующем месте работы, ни о безбедной старости. Толку от нее сегодня все равно около нуля. И ведь предлагали и помогали... нет, венда ваша выглядит уежищно, под капотом трэшак, с сетями работает криво, хачю юникс но чтоб забесплатно. Тьфуй... И ведь так радовался, что они возвращаются... Нет, я правда и жизненных планов на такой срок не строил, конечно - сдох бы в 2005м, как ожидалось, и тоже переживать было бы не о чем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #91

76. Сообщение от пох. (?), 06-Мрт-23, 13:27	–1 +/–
Для rhbm очень даже полезно. А вы - не владельцы, у вас ничего не было и нет. И не будет уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #85, #143

77. Сообщение от пох. (?), 06-Мрт-23, 13:28	+4 +/–
Когда есть готовый монолитный паровоз с треугольными. У разработчиков был велосипед, с круглыми, но поменять один дефайн они не могут, это не по пацански - давайте всех заставим жрать дерьмо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #89

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

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

82. Сообщение от пох. (?), 06-Мрт-23, 13:35	–1 +/–
они ее так порешали что лучше бы уж не решали - как все последние достижения этого гальванизируемого трупа. Там в 11й перешли на utmpx. Обычные last/w/who конечно переделали. А вот opiepasswd - "переделали" так что теперь он локальный терминал - не считает секьюрным. (Вполне возможно не потому что плюс и минус перепутали а потому что там вообще мимо буфера читают и готовый rce, но pr присылать бесполезно - все кто не заняты гендерными штудиями, и так перегружены и читать его им недосуг) Сколько и чего еще аналогично попереломали - наукой не установлено, потому что нет уже дураков тратить время на мертвую систему с works as intended во всех местах. Один дефайн поменять вместо этой всей ненужной деятельности? Ну что вы, что вы, так же ж можно сломать совместимость незнамосчем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

84. Сообщение от пох. (?), 06-Мрт-23, 13:39	+/–
можно ж - уже примотали. И ничего, и это сожрете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

85. Сообщение от Аноним (81), 06-Мрт-23, 13:40	+/–
А у тебя есть?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

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

90. Сообщение от Аноним (90), 06-Мрт-23, 13:45	+/–
>предлагается перевести на получение списка пользователей при помощи systemd-logind. Да, нужно дропнуть все ядра, кроме Linux. Вслед за SystemD.
Ответить | Правка | Наверх | Cообщить модератору

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

95. Сообщение от не придумал (?), 06-Мрт-23, 13:57	+1 +/–
думать запрещено, сказали на систем д, значит на систем д
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

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

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

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

103. Сообщение от Аноним (103), 06-Мрт-23, 14:16	+6 +/–
> прибьем ... ржавыми гвоздями ... Стоп! Вот уж тут ржавчина (пока) не виновата!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

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

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

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

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

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

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

111. Сообщение от Аноним (111), 06-Мрт-23, 15:01	+1 +/–
Хороший вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

112. Сообщение от Аноним (112), 06-Мрт-23, 15:02	+2 +/–
Ээ не, то Тукс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #124

114. Сообщение от Аноним (-), 06-Мрт-23, 15:04	+/–
То есть своего демона logind написать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

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

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

118. Сообщение от _hide_ (ok), 06-Мрт-23, 15:22	–4 +/–
Да, действительно, logind очень нужная зависимость для вывода текущего системного времени в консоль. Очень странная ситуация, если честно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #119

119. Сообщение от llolik (ok), 06-Мрт-23, 15:28	+3 +/–
> для вывода текущего системного времени в консоль facepalm. Это-то тут причём?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

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

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

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

124. Сообщение от anonymous (??), 06-Мрт-23, 15:38	+/–
То Тукс, а это рофл)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112

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

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

130. Сообщение от ivan_erohin (?), 06-Мрт-23, 16:29	+2 +/–
> Потому что systemd это стандарт. ISO (CCITT, ITU-T, ГОСТ, ...) про системд нам ничего не говорят. следовательно, вы лжете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

132. Сообщение от Kuromi (ok), 06-Мрт-23, 17:07	+5 +/–
А самое забавное случится через N лет когда появится новый еще более модный SystemX, который должен будет заменить все-все-все и ВДРУГ окажется что пресловутый и ужасно устаревший SystemD прибит гвоздями буквально ко всему и теперь надо задалбаться его отдирая. И все будут такие "А как это получилось?", "А кто это сделал?". Предыдущая поделка Лени PulseAudio ведь уже "устарела", так что все возможно. Все уже забыли как из раздувшихся Иксов долго и болезненно убирали излишний функционал, а ведь тоже было "а давайте все в кучу".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #162

133. Сообщение от Анеони (?), 06-Мрт-23, 17:29	+/–
уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

134. Сообщение от Аноним (199), 06-Мрт-23, 17:29	–3 +/–
https://github.com/linux-pam/linux-pam/pull/541 Тем временем PAM уже переделали на logind Им надо было перед этим спросить мнение у экспертов по Си с опеннет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #145, #148

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

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

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

141. Сообщение от Аноним (199), 06-Мрт-23, 17:56	+/–
https://www.redhat.com/en/blog/patches-welcome-how-contribut... Уточните, пожалуйста, где Ваша реализация решения проблемы 2038 года? Любой может отправить им патч, если реализация хорошая её примут
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #144

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

144. Сообщение от пох. (?), 06-Мрт-23, 18:06	+1 +/–
покажешь хоть один принятый твой патч? А отправить-то да, можешь - devnull у них бездонный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #156

145. Сообщение от пох. (?), 06-Мрт-23, 18:11	+2 +/–
> Тем временем PAM уже переделали на logind привет девуану. Ну вам же давно говорили - ваше мнение никого не интересует. топтопы rhbm на своих лаптопчиках пользуются виндой и их рабы молча и радостно реализуют их т-пейшие указания чтоб было какввенде. Юникс-экосистема мертва. Не потому что была плоха, а потому что рабы всегда и все делают максимально х-ево. А эпоха свободных людей в этом вашем опенсорсе прошла безвозвратно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #151, #153, #154

146. Сообщение от пох. (?), 06-Мрт-23, 18:12	–1 +/–
> Для избавления  от проблемы 2038 года предлагаю прекратить использование glibc. ну так в винде и нет этой проблемы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

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

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

151. Сообщение от Аноним (199), 06-Мрт-23, 18:25	+/–
О чем вы? systemd это клон launchd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

152. Сообщение от Аноним (-), 06-Мрт-23, 18:31	+/–
> Gentoo с OpenRC -- наше всё! Хотя нет, ещё Guix с Shepherd. > Ударим свободными системными менеджерами по блоатвари и разгильдяйству! лайк
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

153. Сообщение от Аноним (199), 06-Мрт-23, 18:32	+/–
>А эпоха свободных людей в этом вашем опенсорсе прошла безвозвратно. Почему вы все время ноете? LFS у вас поделка, systemd как в винде, хотя в macos и вроде бы в solaris аналогичные менеджеры. Судя по изменениям там опциями компиляции выбирается использовать logind или нет. Сделать адаптер из одного api в другой несложно, уж бинарный файл заполнить данными можно даже на kotlin Свободных людей нет... Возможно нужно меньше ныть на опеннет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

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

155. Сообщение от пох. (?), 06-Мрт-23, 18:39	–1 +/–
он уже научился вон с pam работать? Ну и давайте, давайте - менеджер сеансов, менеджер фаянсов - так и перекопипастите весь systemd. Б-ть ну вот как мы без вас жили и без ваших дерьмоменеджеров вовсе?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #154

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

157. Сообщение от Аноним (159), 06-Мрт-23, 18:46	–1 +/–
> BSD не ипользует glibc. у них свой BSDшный libc И как отсутсвие проблем в своей libc им поможет, если в качестве решения "Все приложения, использующие utmp, wtmp и lastlog, предлагается перевести на получение списка пользователей при помощи systemd-logind."?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #165

158. Сообщение от пох. (?), 06-Мрт-23, 18:49	+1 +/–
слив засчитан. Нет там твоих патчей. А, ну да, ты ж не умеешь кодить... .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #156

159. Сообщение от Аноним (159), 06-Мрт-23, 18:49	+1 +/–
> насколько я понял это проблема glibc от проекта GNU, в BSD-системах свои BSD libc, к-е вроде как не подвержены этой проблеме. Если "решат" проблему с помощью "Все приложения, использующие utmp, wtmp и lastlog, предлагается перевести на получение списка пользователей при помощи systemd-logind.", то своя либц тут ничем не поможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

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

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

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

163. Сообщение от ИмяХ (?), 06-Мрт-23, 20:03	–1 +/–
Никуда он не свалил. Всё так же за компьютером сидит, что-то там программирует.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

164. Сообщение от ИмяХ (?), 06-Мрт-23, 20:09	–2 +/–
>>месяца Последнего зерна, Вы, аннунаки, только в марте последнее зерно досеиваете? Или заканчиваете собирать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #167, #209

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

167. Сообщение от Admino (ok), 06-Мрт-23, 20:35	+2 +/–
Thank Talos, it's fredas.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

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

169. Сообщение от Аноним (169), 06-Мрт-23, 21:08	+4 +/–
> к системдосу будут прибивать приложения "Нам только загрузку подускорить", - пищали поттеринги...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #177

170. Сообщение от Аноним (159), 06-Мрт-23, 21:14	–2 +/–
>> с приложениями, использующими utmp ... tcsh, xterm, ... дисплейные менеджеры, emacs, openssh > Все приложения в линукс (из coreutils я полагаю). Угу, угу. "Родина слонов"(с). > Ты думаешь в BSD работают линуксовые приложения, работающие в utmp? Ну ... tcsh, xterm, openssh и emacs работают точно (дисплейные менеджеры когда-то тоже вполне работали). А так, utmp во фре заменили на utmpx где-то лет 12 назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #180

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

175. Сообщение от Tron is Whistling (?), 06-Мрт-23, 23:24	+2 +/–
utmp64 добавить совсем-совсем никак?
Ответить | Правка | Наверх | Cообщить модератору

176. Сообщение от Аноним (177), 07-Мрт-23, 00:01	+1 +/–
> подмял и свалил ЛОЛ Просто его диверссионное задание "под прикртием" закончилось и он вернлся в штаб
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

177. Сообщение от Аноним (177), 07-Мрт-23, 00:05	+6 +/–
>> к системдосу будут прибивать приложения > "Нам только загрузку подускорить", - пищали поттеринги... Самое смищное [нет], то что а сегодняшний день системы с openrc или с голым sysvinit загружаются быстрее, не говоря уже про всякие runit'ы. Так что подукорить там слилось ещё где-то в середине и сектанты переобувались в полёте лихорадочно изучая мантры про "портянки на баше" и подобные ужосы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

178. Сообщение от YetAnotherOnanym (ok), 07-Мрт-23, 00:36	–1 +/–
> как проблему будут рушать во FreeBSD Вважаю, швыдко будут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

179. Сообщение от Ivan_83 (ok), 07-Мрт-23, 01:21	+1 +/–
Яиц просто нет у разрабов. Написать в хидере чтобы не давал себя собирать с time32_t и всё. За месяц авторы всех остальных утилит бы поаравили свои поделия или юзеры патчей накидали.
Ответить | Правка | Наверх | Cообщить модератору

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

181. Сообщение от Аноним (181), 07-Мрт-23, 02:42	+/–
Принципы проектирования ПО и здравый смысл говорят о том, что привязываться надо не к системд, а к формально описанному стандартизированному API. Можно взять за основу и systemd-шный API, главное - наличие альтернативных реализаций, и тестирование работы с ними в рамках принятого стандарта, а не только с systemd.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

182. Сообщение от Аноним (182), 07-Мрт-23, 06:40	+1 +/–
> Y2K Упала только Netware.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

183. Сообщение от Аноним (-), 07-Мрт-23, 08:48	+/–
> Идея полностью дропнуть 32 бита в libc звучит более здраво ...то то эмбедовка всякая рада будет. Ну там дебиан какой, допустим, с портами на ARM/MIPS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #203, #210, #223

184. Сообщение от Аноним (-), 07-Мрт-23, 08:50	+/–
> Главное вовремя выкидывать усаревшие технологии И как, выкинул уже хотя-бы ДВС-ы и свинцовокислотные акумы? XIX век, аж, а до сих пор в куче автомобилей... ну значит и сюда годков через 150 приползай, как с вон теми. Или кто банкет будет? Вон те, которые програмеров как раз увольняют? А, может ты на альтруизме перепишешь?! Так то пожалста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #193, #202

185. Сообщение от Аноним (-), 07-Мрт-23, 08:52	+/–
> - "Кококо надо было переходить на systemd-olologind" Агаблин, грязный хмырь выглядывающий из люка бункера матерится на повисший навигатор и глючащий дозиметр, пытаясь перезапустить лаптоп.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

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

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

188. Сообщение от Дворник (??), 07-Мрт-23, 10:06	+1 +/–
Летят цветные бумеранги.. `utmp` Интересно, что мог бы подумать сейчас тот самый программист, который в своё время второпях вкорячивал очередной хак для срочного решения очередной задачи по контролю, и, быть может, лишь на секунду задумался над именованием очередной сущности, подумал, возможно, о временности и непостоянстве бытия, мол само быстро отвалится, потому пусть и будет utmp. И вот, продолжаем наблюдать, как отваливается.
Ответить | Правка | Наверх | Cообщить модератору

189. Сообщение от Аноним (189), 07-Мрт-23, 10:35	–1 +/–
> "да ладно вам! ни один компьютер столько не проработает..." Забавно, как молодые ехидно ругают дидов за недальновидность, а сами прелагают абсолютно тоже самое - просто увеличить диапазон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #192

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

192. Сообщение от Аноним (-), 07-Мрт-23, 11:08	+2 +/–
> Забавно, как молодые ехидно ругают дидов за недальновидность, а сами прелагают абсолютно тоже самое - просто увеличить диапазон. Только диапазон теперь будет больше 100 миллиардов лет. Уверен, что человечество столько просуществует?  Ну если вдруг через столько лет будет линукс и в нем time_t, это наверное станет причиной конца сверхцивилизации, ибо вряд ли тогда кто-то будет помнить про это ограничение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #196, #221

193. Сообщение от xPhoenix (ok), 07-Мрт-23, 11:21	–2 +/–
Сколько лет вилкам, ложкам и чайникам? А резьбовые соединения удалось заменить на что-то другое? Уууу! Отсталые! Вы не путайте проверенную временем, надёжную технологию и кривое решение, которое тащат десятилетиями только ради того, чтобы у каких-то ретроградов не дай б-х что-нибудь не сломалось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184

194. Сообщение от Аноним (159), 07-Мрт-23, 13:02	+/–
Что-то я сомневаюсь, что _те_ авторы xterm и tcsh вообще еще что-то патчат. Но речь шла о предложенном "решении", которое надежно и точно ломает совместимость с "нелинухами".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

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

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

197. Сообщение от Аноним (-), 07-Мрт-23, 15:52	+1 +/–
Мне одному кажется, что используя удобный повод хотят пользователей тупо перевести на systemd-logind? Если есть проблема её надо решать, какой бы трудной она не была. А не сбегать в ненавистный системД.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #200, #216

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

199. Сообщение от Аноним (199), 07-Мрт-23, 18:05	+/–
Вы уверены что 50 лет назад регистры были именно 32 битные?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #201

200. Сообщение от pic (?), 07-Мрт-23, 18:16	+/–
Нет. Согласен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

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

202. Сообщение от пох. (?), 07-Мрт-23, 19:32	+/–
> И как, выкинул уже хотя-бы ДВС-ы и свинцовокислотные акумы? XIX век, аж, а до сих пор > в куче автомобилей... у меня для тебя херовые новости - эта куча рискует буквально через пять-восемь лет быть порезанной на металлолом - причем за счет своих владельцев. Производство и продажи _уже_ запрещены в куче долбанутых зелененькой темкой стран, не прямо вот сейчас, но уже с вполне конкретными сроками и датами. За запретом эксплуатации того что уже выпустили - тоже не залежится. И да, корень проблемы тот же что и в торжествующем шествии системдряни. Люди - т-пы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #208

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

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

205. Сообщение от A (?), 07-Мрт-23, 22:45	+/–
> Главное вовремя выкидывать усаревшие технологии Алфавит, алфавит с арабскими цифрами очень морально устарел. И аксиомы арифметики - туда же. Менять надо. Тока ничего никто не придумал на замену.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #211

206. Сообщение от A (?), 07-Мрт-23, 22:50	+/–
>  К тому времени 32-битные приложения сами отомрут. Будут на каких-нибудь атомных электростанциях, моделях токомака и коллайдерах. А то и просто в банках - кэш отменят, но окажется, что крипта бегает поверх апликухи от дедов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

207. Сообщение от A (?), 07-Мрт-23, 22:54	+/–
Потенциальное увеличение размера можно было учесть. Могли не учесть, сколь немного будет людей, способных заменить написанное вот сейчас быстро. Да и смотря для чего писать код. Если выкинуть пену, останется не так много заменить...?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

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

209. Сообщение от Обычный сиродильских НВах (?), 08-Мрт-23, 00:01	+/–
Нет места прелестней во всём Нирне в это время года, чем Ввандерфел!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

210. Сообщение от Алексей (??), 08-Мрт-23, 07:14	+/–
Там musl, uclibc, и т.п., а потому всё равно, что, как, и когда выкинут из glibc. Это раз. И пользователи как правило на встроенные системы не заходят, поэтому страдания с [uw]tmp никак не волнуют. Это два.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183

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

212. Сообщение от Аноним (199), 08-Мрт-23, 14:01	+1 +/–
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, #215

213. Сообщение от Аноним (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ообщить модератору
Родитель: #212

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

216. Сообщение от Аноним (-), 08-Мрт-23, 16:56	+/–
> Мне одному кажется Ты комменты бы хоть почитал. Не переживай, ты не один такой, нечего стесняться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

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

219. Сообщение от Аноним (219), 11-Мрт-23, 18:59	+1 +/–
> Например, для записи в 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ообщить модератору

220. Сообщение от Аноним (221), 11-Мрт-23, 19:18	–1 +/–
> Раз уже все равно все прикладухи надо переписывать (под использование systemd-login), не > проще ли было таки пофиксить в них 32->64 бита? Проще и правельнее. Но цель стоит всех поставить раком и всем вставить в *опу сытемды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

221. Сообщение от Аноним (221), 11-Мрт-23, 19:19	+2 +/–
> Только диапазон теперь будет больше 100 миллиардов лет. Уверен, что человечество столько > просуществует? Если ты о теле человека, то нет. Чарез ~4 миллиарда лет наше Солнце зажарит Землю, наступит смерть нашей Солнечной системы. Через ~16 миллиардов лет Наша Галактика столкнётся с галактикой Андромеды. А через ~80 миллиардов лет все радиоактивные изотопы распадутся и наступит вообще смерть всей Нашей Вселенной. Но насчёт человеческой "цивилизации" ты не грусти, так долго ждать не придется, всё закончится намно-о-о-о-о-го быстрее!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #222

222. Сообщение от Аноним (222), 11-Мрт-23, 19:23	+/–
> А через ~80 миллиардов лет все радиоактивные изотопы распадутся и наступит вообще > смерть всей Нашей Вселенной. А лёгкие элементы "сгорят" в термоядерном синтезе...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221

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

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

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

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

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