The OpenNET Project / Index page

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



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

"В Debian 14 намерены удалить слой для совместимости systemd со скриптами sysv-init"  +/
Сообщение от opennews (??), 30-Янв-26, 09:59 
Команда сопровождающих Debian изначально планировала удалить слой совместимости systemd-sysv-generator в Debian 13 (Trixie), но решение было отложено на следующий релиз (Debian 14)....

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

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

Оглавление

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


1. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +9 +/
Сообщение от Аноним (1), 30-Янв-26, 09:59 
Ну вот, а говорили, что devuan не нужен.
Ответить | Правка | Наверх | Cообщить модератору

3. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +13 +/
Сообщение от Нонон (?), 30-Янв-26, 10:07 
Споры про нужность systemd вечны)
Даже когда systemd уже стандарт у всех настольных дистров
Ответить | Правка | Наверх | Cообщить модератору

8. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –22 +/
Сообщение от Аноним (8), 30-Янв-26, 10:16 
Чушь не мели! сустемды не стандарт и более того - большинством сообщества воспринимается в штыки. И только бараны + корпорасты продвигают это 4у4ело.
Ответить | Правка | Наверх | Cообщить модератору

9. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +3 +/
Сообщение от Аноним (9), 30-Янв-26, 10:18 
> большинством сообщества воспринимается в штыки

откуда инфа? давай прув или gtfo

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

72. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +5 +/
Сообщение от Аноним (72), 30-Янв-26, 12:21 
А давай пруф на стандарт. Разумеется, от уважаемых институтов международной стандартизации.
Ответить | Правка | Наверх | Cообщить модератору

11. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Eneeld (?), 30-Янв-26, 10:20 
>большинством сообщества воспринимается в штыки

А кроме nixOs и ответвлений от debian и arch? (Ну и slackware)

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

41. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (41), 30-Янв-26, 11:44 
В NixOS как раз systemd уже давно единственным вариантом.
Ответить | Правка | Наверх | Cообщить модератору

43. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Анонисссм (?), 30-Янв-26, 11:47 
>А кроме nixOs и ответвлений от debian и arch

лолушки, арчи одними из первых скушали это.
alpine и void из хорошего, хотя лично мне пакетная политика void бы и с systemd подошла

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

55. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Аноним (55), 30-Янв-26, 12:07 
А что у них такое с пакетной политикой хорошее?
Ответить | Правка | Наверх | Cообщить модератору

149. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Анонисссм (?), 30-Янв-26, 15:19 
> А что у них такое с пакетной политикой хорошее?

ядер сколько на /boot влезет, а не одно. пакеты - роллинг, всегда умеренно свежее. короче, арч некурильщика.

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

84. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от morphe (?), 30-Янв-26, 12:39 
> nixOs

В NixOS наоборот на системду стараются завязать как можно больше всего, потому что кроме systemd в NixOS есть только одна единственная автогенерируемая баш портянка под названием activation script

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

20. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +3 +/
Сообщение от freehckemail (ok), 30-Янв-26, 11:16 
> Чушь не мели! сустемды не стандарт и более того - большинством сообщества воспринимается в штыки.

Честно говоря, здраво оценивая ситуацию, большинству просто плевать.

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

25. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (25), 30-Янв-26, 11:19 
Ну а что есть стандарт? Кто его определяет?
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

81. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 12:34 
https://ru.wikipedia.org/wiki/Международная_организация_по_стандартизации
https://ru.wikipedia.org/wiki/Институт_инженеров_электротехники_и_электроники
https://en.wikipedia.org/wiki/International_Electrotechnical...
Ответить | Правка | Наверх | Cообщить модератору

96. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (96), 30-Янв-26, 13:03 
И какая из этих организаций утвердила systemd в качестве стандарта?
Ответить | Правка | Наверх | Cообщить модератору

99. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 13:06 
Никая. Значит, этот, так называемый "стандарт", васянский.
Ответить | Правка | Наверх | Cообщить модератору

158. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (-), 30-Янв-26, 15:52 
> Никая. Значит, этот, так называемый "стандарт", васянский.

"man стандарт де-факто" :). Т.е. если вы например удумаете хотеть работать в отрасли и делать что-то связанное с Linux - можете сравнить количество вакансий где sd знать надо и где не надо. При том количество вторых еще и постоянно сокращается.

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

157. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (-), 30-Янв-26, 15:50 
> https://ru.wikipedia.org/wiki/Международная_организация_по_стандартизации
> https://ru.wikipedia.org/wiki/Институт_инженеров_электротехники_и_электроники
> https://en.wikipedia.org/wiki/International_Electrotechnical...

А, то-есть допустим ГОСТ - васяны? Вместе с NIST, AOM, IETF и еще чертовой кучей наименований? :)

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

100. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от gr (??), 30-Янв-26, 13:06 
ibm hat
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

31. Скрыто модератором  –3 +/
Сообщение от Аноним (31), 30-Янв-26, 11:30 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

18. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (18), 30-Янв-26, 11:03 
> уже стандарт

Когда-то стандарт был симбиан, причём единственный на смартах. Когда-то - autoexec.bat. Ещё было 640 кБ.

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

39. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от kusb (?), 30-Янв-26, 11:42 
Нужен /AUTOEXEC.SH
Ответить | Правка | Наверх | Cообщить модератору

83. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 12:37 
И CONFIG.CFG
Ответить | Правка | Наверх | Cообщить модератору

91. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (91), 30-Янв-26, 12:53 
Нет никаких споров. Народ просто плюется.
Системд - это как мессенджер максут, только вместо минцифры ИБМ, а вместо ВК - редхат )))
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

142. Скрыто модератором  +/
Сообщение от Djon (??), 30-Янв-26, 14:48 
Ответить | Правка | Наверх | Cообщить модератору

7. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от gumanzoyemail (ok), 30-Янв-26, 10:15 
Так systemd-sysv-generator не нужен если используется SysVinit

Если же используется systemd то логично что запуск всех сервисов должен быть через юниты.

Проблема для пользователей SysVinit будет если в Debian начнут более активно удалять из пакетов скрипты запуска /etc/init.d/

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

163. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (-), 30-Янв-26, 16:09 
> Так systemd-sysv-generator не нужен если используется SysVinit

Так там и systemd не нужен тогда по идее :). Только желающих так делать при наличии альтернативы в виде sd осталось - немного.

> Если же используется systemd то логично что запуск всех сервисов должен быть
> через юниты.

В теории - да. На практике - если у некоего сервиса уже был стартовый скрипт а юнит ему еще не написали - вот тут может быть удобно втулить этот скрипт. Прада с sysv если он не от того дистро - уже большой вопрос, юнит sd написать с ноля может стать проще чем убедить ЭТО работать.

> Проблема для пользователей SysVinit будет если в Debian начнут более активно удалять
> из пакетов скрипты запуска /etc/init.d/

Было бы хорошо если бы они этим по крайней мере не гадили в системы с s-d. Как и прочими ошметками типа runit каких там еще.

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

19. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (25), 30-Янв-26, 11:10 
Ну вот реально, чем systemd не угодил? Ну удобная же вещь.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

22. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от freehckemail (ok), 30-Янв-26, 11:18 
> Ну вот реально, чем systemd не угодил? Ну удобная же вещь.

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

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

29. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Bottle (?), 30-Янв-26, 11:27 
И что он там найдёт? Очередной визг про философию мёртвой операционки?
Ответить | Правка | Наверх | Cообщить модератору

35. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (35), 30-Янв-26, 11:36 
Мертвой?
Линукс номер один в мире. Серверы, встройка + андрогин.
Ответить | Правка | Наверх | Cообщить модератору

38. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Fyjy (?), 30-Янв-26, 11:42 
> Мертвой?
> Линукс номер один в мире. Серверы, встройка + андрогин.

Речь же про юникс разумеется. Который сдох давно и почти не воняет.
На unix way которого невероятно наяривают системд-хейтеры.
Хотя забывают, что по тому самому way нужно "пишите программы, которые делают что-то одно и делают это хорошо", а окаменелые иниты уже не делают это хорошо - они застряли где-то во времена юниксов))

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

49. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (49), 30-Янв-26, 11:56 
Пока я вижу, что люди, которые собрались и пилят что-то для себя, вызывают у тебя негативные реакции. Ты точно на тот сайт пришёл?
Ответить | Правка | Наверх | Cообщить модератору

71. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (35), 30-Янв-26, 12:19 
Линукс может быть сертифицирован как юникс. Юникс тоже не мертв.
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

80. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноним (80), 30-Янв-26, 12:29 
Ничего, что macOS - это сертифицированный unix?
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

122. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от пэпэ (?), 30-Янв-26, 14:13 
Ничего. Это прикол "для своих", на который подкроватники десятки лет смешно ведутся. Думаю Возняк дичайше веселился, когда это придумал.

Хинт: если дедушке выдать сертификат, что он бабушка - у него от этого грудь не вырастет. Сертификат - это бумажка.

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

125. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (125), 30-Янв-26, 14:16 
> Ничего, что macOS - это сертифицированный unix?

А ничего что инит в макоси это launchd.
Попробуй пошевелить извилиной и догадаться, чем systemd был heavily inspired.
Даже название так непалевно одолжили.

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

167. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (-), 30-Янв-26, 16:22 
>> Ничего, что macOS - это сертифицированный unix?
> А ничего что инит в макоси это launchd.

Я так смотрю типа-"юниксоидам" навроде freehck, пох-нах и прочих user двойные стандарты череп не жмут.

Они на отличненько топят за юниксвэй, юзая... дадам! Всякую проприетарь типа винды и мака! Откуда с козтей мордой рассказывают как крут sysv init, как офигенен Xorg, все дела. Сами они такую блевоту, конечно, для себя не юзают, находя 1000 извинений почему эот "великолепие" с всеми его вэями должно быть у кого-нибудь - но только не у них на их компе.

И господ совсем не смущает что на их системе сервисы рулит launchd или scm и никакого xorg оказывается совсем нет. Но когда вопрос в том чтобы так же и линух сделал - эти лживые лицемеры просто заходятся в ярости. Чего стоит их вэй в таком виде - ну вы поняли. Ложь, двойные стандарты и пробивание стен чужим лбом? No way.

> Попробуй пошевелить извилиной и догадаться, чем systemd был heavily inspired.
> Даже название так непалевно одолжили.

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

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

89. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 12:50 
Не забываем, MacOS - это UNIX (TM). И у неё >9% десктопов.
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

123. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Аноним (125), 30-Янв-26, 14:14 
> Не забываем, MacOS - это UNIX (TM). И у неё >9% десктопов.

Макос это такой же юникс, как андроид линукс.
Но даже если так - расскажи мне про юниксвей в макоси.

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

140. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 14:46 
Им выдали официальный сертификат. Так что, такова се ля ви.
Ответить | Правка | Наверх | Cообщить модератору

169. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (-), 30-Янв-26, 16:31 
> Макос это такой же юникс, как андроид линукс.
> Но даже если так - расскажи мне про юниксвей в макоси.

Вот такой вот юниксвэй. Оказывается, launchd вместо sysv - вполне юниксвэйно. И без Xorg жизнь оказывается есть. И даже более того - господа это юзают у себя на десктопе - и почему-то не читают эпплу лекции как они должны выпинуть launchd в пользу sysv и юзать xorg вместо нормальной графической подсистемы.

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

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

37. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –4 +/
Сообщение от Fyjy (?), 30-Янв-26, 11:39 
Да понимаешь, тут просто слишком много разных хейтеров.

Часть просто неосиляторы, которые только могут ныть про то, как "плахая системДА паламала им процессы". Это в общем-то неудивительно - тело привыкло обмазываться башпортянками, мозги закостенели и выучить новое уже не в состоянии.

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

Часть - "копротивленцы", которые видят слово RedHat и их глаза наливаются кровью, а моск перестает работать. Остается чистая ненависть. Еще они любят позатирать про какое-то сообщество, свободу и прочее.

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

44. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +3 +/
Сообщение от Аноним (49), 30-Янв-26, 11:47 
>много разных хейтеров

Я тебя может удивлю, но у девуана хейтеров тут гораздо больше. Хотя казалось бы...

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

52. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +2 +/
Сообщение от Аноним (52), 30-Янв-26, 11:58 
Админ старой закалки рапортует внутрь. За последние 10 лет было уже три случая, когда приходилось выезжать на сервер из-за поломанного /etc/fstab. Надо ввести пароль рута и т.д.
А с sysvinit, s6 и прочими такой фигни не было. Они прекрасно грузятся и с поломанным fstab ;)

Был правда и случай, когда NetworkManager помог - получил адрес по DHCP. Но пока только один такой случай ;)

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

61. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 12:12 
>За последние 10 лет было уже три случая, когда приходилось выезжать на сервер из-за поломанного /etc/fstab

Ну и зачем вы fstab ломаете?
>А с sysvinit, s6 и прочими такой фигни не было. Они прекрасно грузятся и с поломанным fstab ;)

Поломайте корень, и покажите, как они загрузятся без проблем.

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

95. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (52), 30-Янв-26, 13:02 
Так fstab не ломается из-за того, что туда usb -диск ДОПИСАЛИ или NFS-шару. В итоге защита, от которой вреда больше чем пользы. И в systemd такого г-на предостаточно.

> Поломайте корень, и покажите, как они загрузятся без проблем.

А давай я тебе шаблон сломаю. Информация о rootfs есть в загрузчике... ;) remout rw не сработает, но это ещё не конец.

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

105. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 13:15 
>Так fstab не ломается из-за того, что туда usb -диск ДОПИСАЛИ или NFS-шару.

То-есть, вы обвиняете systemd в чьих-то чужих кривых руках? Монтирование внешних носителей осуществляется либо через udisks, либо через некий юнит запускающий скрипт, либо через mount юнит. fstab для этого трогать не нужно.
>Информация о rootfs есть в загрузчике... ;) remout rw не сработает, но это ещё не конец.

Всегда можно сломать что-то ещё, например удалить бинарник ssh.

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

111. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (52), 30-Янв-26, 13:36 
> fstab для этого трогать не нужно.

Много чего можно. Например, паниковать ТОЛЬКО если не удалось загрузить информацию о rootfs.

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

116. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 13:59 
Чтобы что? А если /etc не смонтирован - паниковать можно или нельзя? И как условный ssh в этом случае должен запустится?
Ответить | Правка | Наверх | Cообщить модератору

126. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (52), 30-Янв-26, 14:17 
С etc будем дальше разбираться. Может и нельзя, как зависимости лягут.

Сейчас получается «ой паника, из 10 строк одну не понял, исправляйте. Вообще грузиться не буду, а то мало ли что!» Чтобы «Мадо ли что» произошло надо ещё постараться...
А получится «ой тут не нашлось /var/lib/postgres, значит никакого вам постгреса.

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

130. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:27 
>С etc будем дальше разбираться.

Каким образом? Конфиги ssh в initramfs зашьёте?
>А получится «ой тут не нашлось /var/lib/postgres, значит никакого вам постгреса.

Вы так и не ответили, почему не монтируете с помощью юнитов.

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

148. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (52), 30-Янв-26, 15:15 
> Вы так и не ответили, почему не монтируете с помощью юнитов

Потому что такой получается троллейбус, с квадратными колёсами ;) Команду mount отменили что ли?

fstab как самый наглядный пример. С файлами .desktop такая же фигня: «я не знаю что там вам в этих ваших DE потребовалось добавить, но тут куча неизвестных параметров, ай-ай как всё плохо». Валидация ini-шника - это вообще ахтунг головного мозга. Не распарсил параметр - тупо игнорь, у файла специально такая структура. Не понял значение параметра - бери дефолт.
Не особо программист, но все мои хелло-ворды стартуют, даже если вместо ini-файла какой-нибудь mkv подсунуть. Если там i не должно n превышать, то значит будет обрезано или расширено до корректного значения (это вот вообще раз в жизни потребовалось, обычно дефолт ни к каким страшным последствиям не приведёт).

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

161. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 15:59 
>Команду mount отменили что ли?

Будете руками монтировать?
>Не особо программист, но все мои хелло-ворды стартуют, даже если вместо ini-файла какой-нибудь mkv подсунуть.

Есть такой принцип "мусор на входе - мусор на выходе". Ничего осмысленного данные программы сделать не смогут.
>Не распарсил параметр - тупо игнорь
>Не понял значение параметра - бери дефолт.

Выдай ошибку и заверши работу.
>Потому что такой получается троллейбус, с квадратными колёсами ;)

Получается осмысленная система. Те принципы, которые подходят для проектирования деревенского туалета, почему-то перестают работать при проектировании городского водоснабжения. Не подскажите почему?

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

103. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (103), 30-Янв-26, 13:08 
/etc/fstab конвертируется в mount-юниты systemd: https://man.archlinux.org/man/systemd.mount.5#FSTAB

Ждём /etc/fstab deprecated?
:)

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

151. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (52), 30-Янв-26, 15:33 
Станет лучше, кстати. С fstab работает mount, а тут всё решит systemd-mountd, которы сам весь /usr соберёт десятком unit'ов.
Ответить | Правка | Наверх | Cообщить модератору

54. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от freehckemail (ok), 30-Янв-26, 12:06 
> Часть просто неосиляторы...
> Часть - одмины старой закАлки, которым нужен зоопарк...
> Часть - "копротивленцы"...

Альтернативный взгляд:
https://www.opennet.me/openforum/vsluhforumID3/137683.html#54

Тут правда не про systemd, но суть уловите.

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

75. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Fyjy4 (-), 30-Янв-26, 12:26 
> Тут правда не про systemd, но в целом суть та же.

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

И как эти все нехорошие люди заставили тебя перейти с прекрасного линя на отвратительную макось! Было бы также бесполезно, зато душевно))

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

102. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от freehckemail (ok), 30-Янв-26, 13:07 
> Лучше бы ты приложил свой коммент как системд тебе все сломала и как ты бессонными подымал сервера. Или страдания с вейландом и иксами.

В очередной раз повторяю: здорового человека страдания других людей расстраивают, а не радуют. Обратись к специалистам. Тебе нужна помощь.

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

170. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (103), 30-Янв-26, 16:31 
Они пользуются Windows 11.
Ответить | Правка | Наверх | Cообщить модератору

121. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (125), 30-Янв-26, 14:10 
> страдания других людей расстраивают

Других обычных людей - да.
А идеологических противников, которые стараются сделать хуже тебе и всей индустрии... это вряд ли :)

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

66. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (66), 30-Янв-26, 12:15 
Ага, случай с XZ ничему не научил (апрель 2025г.).
Очень удобно - всех хакать через завязку на systemd и dbus.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

69. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +2 +/
Сообщение от КО (?), 30-Янв-26, 12:18 
До поры до времени. Пока этот мега комбайн не начнет чудить.
И что делать в случае shell боле-менее понятно.

Из примеров. Развлекался тут с ollam'ой. Если пускать из под пользователя в shell - видяхи видит. Из под того же пользователя, через unit systemd - нет.
В логах тишина. Инет знает, как в systemd запретить видеть видяхи, а вот как разрешить - не знает. Вот как после этого верить, что systemd во всем лучше bash-портянок?

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

73. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –3 +/
Сообщение от Аноним (61), 30-Янв-26, 12:23 
>Развлекался тут с ollam'ой. Если пускать из под пользователя в shell - видяхи видит. Из под того же пользователя, через unit systemd - нет.

Вот удивительно - есть у вас глючный софт - ollam-а, которая не видит видеокарту. При чём не просто не видит, а молча не видит, а виноват systemd. Нормальный софт должен написать что-то вроде /dev/dri doesn't exist - и всё, пользователь понимает в чём проблема.

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

87. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (87), 30-Янв-26, 12:47 
> должен написать что-то вроде /dev/dri doesn't exist - и всё, пользователь понимает в чём проблема.

да! Пользователь сразу понимает, что права на /dev/dri он получил благодаря метке uaccess, logind и динамическим ACL

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

92. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от КО (?), 30-Янв-26, 13:00 
Так ей не обязательно dri она может и без него работать. А писать в лог, что не нашла всего, чего могла бы найти в принципе, это как-то странно.
Ответить | Правка | Наверх | Cообщить модератору

107. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (87), 30-Янв-26, 13:24 
> А писать в лог, что не нашла всего, чего могла бы найти в принципе, это как-то странно.

ну если оно пишет условное "нет устройства …" вместо "нет прав на …", то выбор сообщения странный.

А так не странно — права на /dev у пользователя, запустившего сессию, и пользователя, указанного в юните, могут быть разные.

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

115. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от КО (?), 30-Янв-26, 13:56 
>А так не странно — права на /dev у пользователя, запустившего сессию, и пользователя, указанного в юните, могут быть разные.

С учетом, что это один и тот же пользователь _ollama_ - это несколько странно.

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

117. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:02 
Пользователь - это uid. Видеокарта может быть недоступна по куче причин - uid, mount namespace, selinux и так далее. Что именно ломает доступ в вашем случае - вопрос открытый.
Ответить | Правка | Наверх | Cообщить модератору

124. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (87), 30-Янв-26, 14:15 
на /dev/dri/card0 стоят права 660 и владелец root:video. Несмотря на это мой пользователь, не состоящий в группе video, может работать с видеокартой. Просто через связку udev+logind он получил дополнительные права, которые можно узнать используя getfacl.

короче, это игра в угадайку (подробностей мало) и оффтоп здесь, но я клоню к тому, чтобы добавить _ollama_ в группы video, render, … напрямую или через SupplementaryGroups в юните

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

88. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +2 +/
Сообщение от КО (?), 30-Янв-26, 12:50 
Она то видит, причем не молча. Не видит при запуске из systemctl start ollama.
Запись от нее в логе, что она искала и не нашла есть.
Вот если, например, selinux рубит кому-то доступ к чему-то, то в журнале об этом появляется запись в журнале. Systemd-ы выше этого. Что он кому и как отрубил - никому знать не положено.
Но фанаты будут с пеной у рта кричать что классная штука. Раз в год 2 секунды на старте экономит. И да - есть декларативное описание. А вот у шелла нет.
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

118. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:05 
>Systemd-ы выше этого. Что он кому и как отрубил - никому знать не положено.

Как вы себе это представляете? У любого процесса есть состояние - переменные окружения, пространства имён и так далее. Как systemd должен угадывать, что процессу чего-то не хватает?
>Она то видит, причем не молча. Не видит при запуске из systemctl start ollama.

Ну а что пишет?

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

119. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:09 
>Не видит при запуске из systemctl start ollama.

Откуда конфиг брали? Как минимум сюда посмотрите https://github.com/NixOS/nixpkgs/blob/nixos-25.11/nixos/modu..., и сравните со своим, у вас может банально устройств нехватать.

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

120. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:10 
Если точнее, то сюда https://github.com/NixOS/nixpkgs/blob/fa83fd837f3098e3e678e6...
Ответить | Правка | Наверх | Cообщить модератору

85. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 12:45 
> Ну вот реально, чем systemd не угодил? Ну удобная же вещь.

Кто в Схему сможет, тому Shepherd гораздо удобнее и гибче покажется.

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

21. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от mos87 (ok), 30-Янв-26, 11:17 
правильно говорили.

если у вас старые сервера какие-то с древинм sysV init only софтом, то на них и не ставится свежий дистр.

всё логично.

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

67. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (67), 30-Янв-26, 12:16 
Зачем его туда ставить?
Ответить | Правка | Наверх | Cообщить модератору

166. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от mos87 (ok), 30-Янв-26, 16:22 
сморя каво да куда
тема нераскрыта
Ответить | Правка | Наверх | Cообщить модератору

139. Скрыто модератором  +/
Сообщение от Аноним (139), 30-Янв-26, 14:40 
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

155. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (-), 30-Янв-26, 15:48 
> Ну вот, а говорили, что devuan не нужен.

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

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

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

5. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +3 +/
Сообщение от Аноним (80), 30-Янв-26, 10:13 
>Переход аргументируется повышением уровня безопасности запускаемых служб systemd

Осталось только получить аргументы касательно безопасности systemd.

>также более надёжным контролем над запуском и циклом работы службы

Т.е. полный контроль над пк пользователя?

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

15. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноним (15), 30-Янв-26, 11:01 
Аргументов касательно безопасности лапши на баше, конечно, никто приводить не станет.
Ответить | Правка | Наверх | Cообщить модератору

56. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Аноним (67), 30-Янв-26, 12:08 
На баше невозможно выйти за границу буфера. При том что весь системд состоит и сплошных cve.
Ответить | Правка | Наверх | Cообщить модератору

90. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноним (-), 30-Янв-26, 12:52 
> На баше невозможно выйти за границу буфера.

Используя баш? Зачем?? Там хватает кривых переменных и экранирования.

> При том что весь системд состоит и сплошных cve.

Пф, пруфы в студию.

Ты слышал про Bashdoor/Shellshock ?
Это когда в баше нашли тонну CVE живущих с версии 1.13 (1992 год)
Понятно что баш сам не виноват, что его писали бракоделы на дырявом языке из 70х.

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

156. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 15:48 
А в системде ещё сколько CVE не нашли ещё с момента его десткого возраста?
Ответить | Правка | Наверх | Cообщить модератору

101. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (101), 30-Янв-26, 13:06 
Про runit или dinit вы не слыхали.
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

128. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (128), 30-Янв-26, 14:23 
> Про runit или dinit вы не слыхали.

Слыхали. Очередные васяноподелия, используемые в маргинальных дистрах вроде antiX, Dragora, Void, Chimera, Artix и тд.

Дальше что? Ты продолжи свою мысль.

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

131. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:29 
Что именно должны услышать?
Ответить | Правка | К родителю #101 | Наверх | Cообщить модератору

154. Скрыто модератором  +/
Сообщение от Аноним (72), 30-Янв-26, 15:46 
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

24. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от mos87 (ok), 30-Янв-26, 11:19 
>Осталось только получить аргументы касательно безопасности systemd.

самый безопасный сервер - выключенный.

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

33. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от freehckemail (ok), 30-Янв-26, 11:33 
>>Переход аргументируется повышением уровня безопасности запускаемых служб systemd
> Осталось только получить аргументы касательно безопасности systemd.

Ага, разбежался. Уже были разговоры на этот счёт неоднократно. Лучшее, что они втирают — про возможность ограничения сисколлов, мол, такая фича у systemd из коробки есть. Однако на поверку оказывается, что почти никто из мейнтейнеров её не использует. И с остальными фичами — та же самая история.

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

17. Скрыто модератором  –1 +/
Сообщение от Аноним (15), 30-Янв-26, 11:02 
Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

78. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от morphe (?), 30-Янв-26, 12:28 
> Однако на поверку оказывается, что почти никто из мейнтейнеров её не использует

Вбей systemd-analyze security, и увидишь как много сервисов это используют, systemd-analyze security NAME покажет что именно у тебя для конкретного сервиса не выключено

Большинству сервисов можно поставить DynamicUser=yes и уже защититься от огромного числа проблем, потому что этот флаг сразу запрещает сервису кучу всего делать

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

68. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 12:16 
>Лучшее, что они втирают — про возможность ограничения сисколлов, мол, такая фича у systemd из коробки есть. Однако на поверку оказывается, что почти никто из мейнтейнеров её не использует. И с остальными фичами — та же самая история.

А это тогда что? https://github.com/NixOS/nixpkgs/blob/fa83fd837f3098e3e678e6...

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

82. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от morphe (?), 30-Янв-26, 12:35 
NixOS к сожалению тут не лучший пример, hardening systemd в NixOS до сих пор отстаёт, даже sshd ещё не прикрыт: https://github.com/NixOS/nixpkgs/pull/348701

Сам поддерживаю большой конфиг для того чтобы всё что можно на DynamicUser и прочее перевести, но в NixOS это сложно просто добавить и никому ничего не сломать

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

160. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноня (?), 30-Янв-26, 15:57 
Усы лапы и хвост, вот мои аргументы.
А если серьезно, для больших контор потеря репутации - значительные риски.
В отличие от васянских скриптов с полными правами.

> Т.е. полный контроль над пк пользователя?

Удали то что тебе не нужно. И не ставь васянодистры впредь.

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

165. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Смузихлеб забывший пароль (?), 30-Янв-26, 16:11 
> для больших контор потеря репутации - значительные риски

к чему эти сказки ?
нет у них никакой репутации - есть лишь то что о них публикуют карманные/прикормленные пейсатели и растаскивают повсюду прикормленные медиа

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

23. Скрыто модератором  –1 +/
Сообщение от arthi747 (ok), 30-Янв-26, 11:18 
Ответить | Правка | Наверх | Cообщить модератору

40. Скрыто модератором  +2 +/
Сообщение от freehckemail (ok), 30-Янв-26, 11:43 
Ответить | Правка | Наверх | Cообщить модератору

64. Скрыто модератором  +1 +/
Сообщение от Fyjy4 (-), 30-Янв-26, 12:14 
Ответить | Правка | Наверх | Cообщить модератору

30. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (30), 30-Янв-26, 11:28 
Так, а сами скрипты оставят? Для остальных init-ов.
Ответить | Правка | Наверх | Cообщить модератору

47. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (49), 30-Янв-26, 11:50 
А зачем? Весьма очевидно, что поддержка systemd усложняет поддержку других инитов. Так что либо поддерживаем systemd, либо другое. Выбор очевиден, и лишней работы делать не надо. Берёшь нужный инит и поддерживаешь его в своём дистрибутиве.
Ответить | Правка | Наверх | Cообщить модератору

57. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Аноним (67), 30-Янв-26, 12:09 
Только переход на девуан.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

45. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от kusb (?), 30-Янв-26, 11:47 
Да блин, что за ужас вы пишете.
Ответить | Правка | Наверх | Cообщить модератору

46. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Учи слова капитуляция и репарации (?), 30-Янв-26, 11:48 
Надо понимать, что devuan тоже на помойку отправится? Ведь своё они неспособны замутить из-за явного недостатка человекочасов и как раз полагались на эту прослойку.
Ответить | Правка | Наверх | Cообщить модератору

48. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Аноним (49), 30-Янв-26, 11:52 
Ничего страшного не случится. От дебиана откололось часть человек, отколится ещё, кто каким-то образом умудрялся использовать его без systemd. Так что даже наоборот, число пользователей только возрастёт.
Ответить | Правка | Наверх | Cообщить модератору

50. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноним (50), 30-Янв-26, 11:57 
У меня systemd работает на дешманских ноутбуках Lenovo и на древнем компе с i5 третьего поколения. Кому нужно что то более древнее? Тем, кто сидит на коре дуба? Я конечно долго думал, не поставить ли Linux на мой древний комп 2004 года, на котором стоит еще XP. Но так и не решился. А пока думал, 32бита уже випилили.
Ответить | Правка | Наверх | Cообщить модератору

59. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (67), 30-Янв-26, 12:10 
Поставь туда 32 бита без системд.
Ответить | Правка | Наверх | Cообщить модератору

104. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 13:10 
>на древнем компе с i5 третьего поколения

Ну ты зажрался.

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

109. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (50), 30-Янв-26, 13:26 
Да вот так время летит. То, что было в 2011-2012 году - уже древнее. Мой P4 уж подавно древний. Так совпало, что он был неплохой, ибо уже прошло время 478 сокетов и памяти на 133МГц. Там все таки было 2 гига DDR2 на 400МГц и это было уже круть. Виста даже шла без тормозов.
Ответить | Правка | Наверх | Cообщить модератору

51. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Fyjy4 (?), 30-Янв-26, 11:57 
Как-то дебианцы разбушевались в последнее время!
То armel и mips64el выкидывают, то конвертор в занюханные башпортянки.
Что дальше? Будут обновлять версии софта на менее копролитные?
Неужели деб превращается в нормальных дистр?!
Ответить | Правка | Наверх | Cообщить модератору

65. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (65), 30-Янв-26, 12:15 
Бери лучше сразу Редхет или Федору, там за тебя всё корпорации порешают.
Ответить | Правка | Наверх | Cообщить модератору

58. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 12:10 
В каждой теме, где возникают хейтеры systemd, я задаю им простую задачу: напишите на башпортянке полноценный аналог юнита. С лимитами, изоляцией, понижением прав, шаблонностью, статусом, зависимостями, декларативным переопределением и прочими фичами. Задача со звёздочкой: реализовать это без внешних зависимостей. И каждый раз в ответ красноречивая тишина. Вот и ответ на вопрос, почему systemd безальтернативен - никто из башпортянщиков не может создать ничего стоящего.
Ответить | Правка | Наверх | Cообщить модератору

62. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +2 +/
Сообщение от Аноним (67), 30-Янв-26, 12:12 
Ты так и не понял что ты хочешь ненужного? Это как четвертая камера в телефоне или новая блестящая упаковка. Ты просто хочешь маркетинг ради маркетинга.
Ответить | Правка | Наверх | Cообщить модератору

86. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от freehckemail (ok), 30-Янв-26, 12:47 
> Ты просто хочешь маркетинг ради маркетинга.

Нет, всё проще. Он хочет потратить наше время впустую.

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

63. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +4 +/
Сообщение от Аноним (35), 30-Янв-26, 12:14 
Такое никому не нужно. Системда-2.
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

77. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Fyjy4 (-), 30-Янв-26, 12:27 
> Такое никому не нужно.

Такое не нужно локалхостникам. И может домохозяйкам.
А всем остальным нужно и очень даже полезно.


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

98. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 13:06 
>Такое не нужно локалхостникам. И может домохозяйкам.

Ещё как нужно. getty@.service.d не даст соврать - даже обычный tty - шаблонный юнит.

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

70. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноним (65), 30-Янв-26, 12:18 
А это кому-то нужно: " С лимитами, ... понижением прав, шаблонностью, статусом, зависимостями, декларативным переопределением и прочими фичами." ?
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

79. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от freehckemail (ok), 30-Янв-26, 12:29 
> А это кому-то нужно: " С лимитами, ... понижением прав, шаблонностью, статусом,
> зависимостями, декларативным переопределением и прочими фичами." ?

Да нет, конечно. Вот вам навскидку замеры, сделанные в 2019м:
https://www.opennet.me/openforum/vsluhforumID3/116899.html#101

Последний раз я делал замеры в 2025м, в том числе и по иным фичам. Где-то публиковал цифры, но не помню, где именно, однако прямо скажу, что ситуация в целом не изменилась: там какой-то ничтожный процент использования.

Если вам не влома, то сделайте актуальные замеры.

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

93. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 13:01 
>Последний раз я делал замеры в 2025м, в том числе и по иным фичам. Где-то публиковал цифры, но не помню, где именно, однако прямо скажу, что ситуация в целом не изменилась: там какой-то ничтожный процент использования.

Есть ложь, наглая ложь, и статистика. Итак:
$ ls | grep -P '\.service$' | wc -l
163
$ for i in $(find -type l); do grep -P '(AmbientCapabilities|DynamicUser)' -rl "$i"; done | wc -l
21
$ for i in $(find -type l); do grep -P '(AmbientCapabilities|User|ProtectProc|ProcSubset|BindPaths|BindReadOnlyPaths|Group|CapabilityBoundingSet|AmbientCapabilities|NoNewPrivileges|SecureBits|Limit|ProtectSystem|ProtectHome|ReadWritePaths|ReadOnlyPaths|InaccessiblePaths|ExecPaths|NoExecPaths|TemporaryFileSystem|PrivateTmp|PrivateDevices|PrivateNetwork|PrivateUsers)' -rl "$i"; done | wc -l
98
Если честно, мне просто лень копировать все опции из мануала, так что список не полный, однако уже хорошо видно, как freehck манипулирует статистикой в свою пользу.
Декларативные переопределения
$ ls | grep -P '\.d$' | wc -l
50
Шаблонные юниты
$ ls | grep '@' | wc -l
42
>Всё. Из 238 сервисов только 4 используют это. И те -- systemd-шные.

Как видим, ложность утверждений freehck очевидна любому, кто более мнее в состоянии открыть мануал. Зато неокрепшие умы, столь подверженные мракобесию, воспримут это за чистую монету.

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

112. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от freehckemail (ok), 30-Янв-26, 13:41 
Ололо, сколько же тут ошибок и подтасовок. Чуть позже отпишу. )
Ответить | Правка | Наверх | Cообщить модератору

146. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от freehckemail (ok), 30-Янв-26, 15:09 
>>Последний раз я делал замеры в 2025м, в том числе и по иным фичам. Где-то публиковал цифры, но не помню, где именно, однако прямо скажу, что ситуация в целом не изменилась: там какой-то ничтожный процент использования.
> Есть ложь, наглая ложь, и статистика.

А ещё есть подтасовки от анонимов на OpenNet. У меня на руках совершенно случайно свежая коробка с чистой, только что поставленной LTS-системой, на которую накинуты все самые актуальные обновления. (Ну вы меня знаете, в силу профессии у меня ВСЕГДА на руках есть подобная коробка).


# (source /etc/os-release; echo $PRETTY_NAME)
Ubuntu 24.04.3 LTS

# cd /usr/lib/systemd/system

Итак, команды анонима:


# ls | grep -P '\.service$' | wc -l
223

# for i in $(find -type l); do grep -P '(AmbientCapabilities|DynamicUser)' -rl "$i"; done | wc -l
0

# for i in $(find -type l); do grep -P '(AmbientCapabilities|User|ProtectProc|ProcSubset|BindPaths|BindReadOnlyPaths|Group|CapabilityBoundingSet|AmbientCapabilities|NoNewPrivileges|SecureBits|Limit|ProtectSystem|ProtectHome|ReadWritePaths|ReadOnlyPaths|InaccessiblePaths|ExecPaths|NoExecPaths|TemporaryFileSystem|PrivateTmp|PrivateDevices|PrivateNetwork|PrivateUsers)' -rl "$i"; done | wc -l
14

Цифры очень печальны, но давайте будем честны к анониму: он почему-то делает find -type l, тогда как любой из вас может лично удостовериться, что надо таки смотреть не на симлинки, а на сами файлы.

Давайте исправим анонима, и посмотрим чисто по файлам:


# find /usr/lib/systemd/system -type f -iname '*.service' | wc -l
205

Ну вот, уже другое дело. На это число мы будем делить, так что давайте великодушно не станем считать ещё и симлинки, например под предлогом того, что они ссылаются на файлы в этой же директори. Сделаем статистику анониму лучше. )

Что там было по AmbientCapabilities и DynamicUser? Ну давайте не сочинять новые команды, как это делает аноним, а передадим уже готовый список файлов из предыдущей команды в xargs, и грепнем.


# find /usr/lib/systemd/system -type f -iname '*.service' | xargs grep -P '(AmbientCapabilities|DynamicUser)' -rl | wc -l
6

Ну вот, уже лучше, чем нуль. Это 6/205 получается, что очень близко к тому, что было в 2019м году: 4/238. Что интересно, по сравнению с 2019м, из systemd-timesyncd пропал DynamicUser, сейчас остаётся только AmbientCapabilities. Проверим ещё разок замер 2019го года:


# find /usr/lib/systemd/system -type f -iname '*.service' | xargs grep -P AmbientCapabilities -rl | sort
/usr/lib/systemd/system/e2scrub_reap.service
/usr/lib/systemd/system/e2scrub@.service
/usr/lib/systemd/system/systemd-networkd.service
/usr/lib/systemd/system/systemd-resolved.service
/usr/lib/systemd/system/systemd-timesyncd.service
/usr/lib/systemd/system/xfs_scrub@.service

Итого за последние 6 лет оказывается scrub-ам добавили AmbientCapabilities. Что ж, не мудрено. Стабильные программы с понятным функционалом. Только в таких вот программах в целом и возможно так сделать и быть относительно уверенным в том, что ничего не сломается.

Итак, исходный замер 2019го подтвердили, сделали аналогичный замер 2026го (ой ладно, пусть будет 2024го, ибо всё-таки Ubuntu 24.04), видим полностью аналогичную картину.

===

Но ладно, поехали дальше. Аноним хочет ведь нам показать, что аж половина сервисов используют systemd-специфичные фичи безопасности.

Дёрнем команду анонима по всем опциям, которые он укзал:


# find /usr/lib/systemd/system -type f -iname '*.service' | xargs grep -P '(AmbientCapabilities|User|ProtectProc|ProcSubset|BindPaths|BindReadOnlyPaths|Group|CapabilityBoundingSet|AmbientCapabilities|NoNewPrivileges|SecureBits|Limit|ProtectSystem|ProtectHome|ReadWritePaths|ReadOnlyPaths|InaccessiblePaths|ExecPaths|NoExecPaths|TemporaryFileSystem|PrivateTmp|PrivateDevices|PrivateNetwork|PrivateUsers)' -rl | wc -l
44

Вау, аж 44 сервиса из 205, да это ж практически четверть! Не 90+, как писал аноним, ну да ладно, уже немало. Правда смотреть на список проверяемых опций не удобно, глаза рябит, давайте улучшим вывод, а заодно пройдёмся по каждому в отдельности:


files=$(find /usr/lib/systemd/system -type f -iname \*.service)
opts="AmbientCapabilities User ProtectProc ProcSubset BindPaths BindReadOnlyPaths Group CapabilityBoundingSet NoNewPrivileges SecureBits Limit ProtectSystem ProtectHome ReadWritePaths ReadOnlyPaths InaccessiblePaths ExecPaths NoExecPaths TemporaryFileSystem PrivateTmp PrivateDevices PrivateNetwork PrivateUsers"
for opt in $opts; do
  n=$(echo $files | xargs grep -P $opt -nl | wc -l)
  printf '%-25s %-5d\n' $opt $n
done | sort -hrk2

User                      25
ProtectHome               21
NoNewPrivileges           21
ProtectSystem             20
Group                     19
PrivateTmp                16
CapabilityBoundingSet     15
PrivateDevices            12
PrivateNetwork            8
ReadWritePaths            7
Limit                     7
ProtectProc               6
AmbientCapabilities       6
PrivateUsers              2
TemporaryFileSystem       0
SecureBits                0
ReadOnlyPaths             0
ProcSubset                0
NoExecPaths               0
InaccessiblePaths         0
ExecPaths                 0
BindReadOnlyPaths         0
BindPaths                 0

Ну кстати тут уже видно, что многие security-фичи не используются нигде и никем.

Но теперь, когда есть табличка, в глаза бросается нюанс. Оказывается аноним включил в список User и Group. Они точно не systemd-специфичные, это передёргивание: такая возможность есть в любом init. Давайте-ка посмотрим, что без них будет:


# find /usr/lib/systemd/system -type f -iname '*.service' | xargs grep -P '(AmbientCapabilities|ProtectProc|ProcSubset|BindPaths|BindReadOnlyPaths|CapabilityBoundingSet|AmbientCapabilities|NoNewPrivileges|SecureBits|Limit|ProtectSystem|ProtectHome|ReadWritePaths|ReadOnlyPaths|InaccessiblePaths|ExecPaths|NoExecPaths|TemporaryFileSystem|PrivateTmp|PrivateDevices|PrivateNetwork|PrivateUsers)' -rl | wc -l
31

Что ж, 31 это тоже довольно неплохо, хоть уже и не 44. Но сколько среди них не относятся к самому systemd, а используются реальными мейнтейнерами?


# find /usr/lib/systemd/system -type f -iname '*.service' | xargs grep -P '(AmbientCapabilities|ProtectProc|ProcSubset|BindPaths|BindReadOnlyPaths|CapabilityBoundingSet|AmbientCapabilities|NoNewPrivileges|SecureBits|Limit|ProtectSystem|ProtectHome|ReadWritePaths|ReadOnlyPaths|InaccessiblePaths|ExecPaths|NoExecPaths|TemporaryFileSystem|PrivateTmp|PrivateDevices|PrivateNetwork|PrivateUsers)' -rl | grep -v 'systemd-' | wc -l
18

Уже не так много. А что это собственно за сервисы?


# (cd /usr/lib/systemd/system; find . -type f -iname '*.service' | xargs grep -P '(AmbientCapabilities|ProtectProc|ProcSubset|BindPaths|BindReadOnlyPaths|CapabilityBoundingSet|AmbientCapabilities|NoNewPrivileges|SecureBits|Limit|ProtectSystem|ProtectHome|ReadWritePaths|ReadOnlyPaths|InaccessiblePaths|ExecPaths|NoExecPaths|TemporaryFileSystem|PrivateTmp|PrivateDevices|PrivateNetwork|PrivateUsers)' -rl | grep -v 'systemd-') | sort -h
./apport-coredump-hook@.service
./apt-news.service
./e2scrub_reap.service
./e2scrub@.service
./esm-cache.service
./fstrim.service
./fwupd-refresh.service
./fwupd.service
./logrotate.service
./lxd-agent.service
./man-db.service
./modprobe@.service
./nftables.service
./polkit.service
./rsync.service
./rsyslog.service
./uuidd.service
./xfs_scrub@.service

Из этих 18 штук: fwupd, fwupd-refresh, polkit — разработки Red Hat, а все остальные — это либо тривиальные сервисы, которым либо почти ничего не нужно, либо чей код отлажен и не изменялся годами (за исключением, быть может, минимальных исправлений).

===

Итак, мы наглядно видим, что большинство фичей systemd мейнтейнерами оказались не востребованы.
Это всё, конечно, навскидку, ибо я на самом деле не делал полноценного замера по всем фичам, и я делал замеры только по базовой системе.

Что вы можете сделать, чтобы уточнить цифры?

1) Пройдитесь по своим реально используемым серверам, сделайте замеры.
2) У многих из вас есть десктоп-системы, в которых установлено большое количество пакетов. Укажите DE, которая установлена в вашей системе, и сделайте замеры в ней.

Хотите знать истину? Ну потратьте полчаса.

NB: красивые вставки кода на opennet делаются обрамлением текста в тэги [_code][/_code] (подчёркивания перед code убрать)

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

152. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Анонимусс (-), 30-Янв-26, 15:38 
> Из этих 18 штук: fwupd, fwupd-refresh, polkit — разработки Red Hat

И вполне логично, что создатель системд использует ее фичи в своих продуктах.
Подозреваю, что они писались как раз по из запросу.

> большинство фичей systemd мейнтейнерами оказались не востребованы...

... в Ubuntu LTS 24.04.
Возможно в RHEL или SLES все обстоит совсем иначе.

Справедливости ради, наличие security-фичи может быть оправдано если используется даже одним единственным сервисом, напр. nftables или polkit.

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

168. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от freehckemail (ok), 30-Янв-26, 16:23 
>> Из этих 18 штук: fwupd, fwupd-refresh, polkit — разработки Red Hat
> И вполне логично, что создатель системд использует ее фичи в своих продуктах.
> Подозреваю, что они писались как раз по из запросу.

Да, именно так. Таким образом, из нетривиальных сервисов systemd-специфичные опции используются за пределами самого systemd — исключительно в софте от Red Hat. А нетривиальных сервисов, которые бы были за пределами Red Hat и использовали бы systemd-специфичные опции — нет.

>> большинство фичей systemd мейнтейнерами оказались не востребованы...
> ... в Ubuntu LTS 24.04.
> Возможно в RHEL или SLES все обстоит совсем иначе.

Моя база — это преимущественно Debian и Ubuntu. Я с большим интересом посмотрел бы, как обстоят дела в других дистрибутивах.

> Справедливости ради, наличие security-фичи может быть оправдано если используется даже
> одним единственным сервисом, напр. nftables или polkit.

И да, и нет. По архитектуре systemd все эти фичи встроены в pid-1. Каждая такая фича увеличивает attack surface. Если фича используется только в одном-двух сервисах — так может ей лучше не быть в pid-1?

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

153. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 15:45 
>Ubuntu 24.04.3 LTS
>Итак, это — навскидку. Мы наглядно видим, что многие фичи systemd вообще не используются никак. Принятие у мейнтейнеров -- крайне низкое.

Вы провели тест адекватности убунты. У них и файрвол по умолчанию не настроен. И снап, чьи тормоза стали легендарными.
>он почему-то делает find -type l

Например, потому что он использует NixOS.
>Стабильные программы с понятным функционалом. Только в таких вот программах в целом и возможно так сделать и быть относительно уверенным в том, что ничего не сломается.

Во-первых, писать юниты может изначальный автор программы. Во-вторых, мейнтер может самостоятельно добавить параметры по усмотрению и выгрузить в нестабильную ветку.
>Вау, аж 44 сервиса из 205, да это ж практически четверть! Не 90+, как писал аноним

А ничего, что у нас системы разные?
>Ну кстати тут уже видно, что многие security-фичи не используются нигде и никем.

А с чего вы взяли, что каждая опция должна обязательно использоваться в любом случайном юните? Если в условный торт не засунули майонез, кетчуп, горчицу, несколько видов перца - торт плохой, невкусный будет? А в условную отбивную нужно обязательно добавить глазурь, сливки, сахарную пудру и вишенку?
>Оказывается аноним включил в список User и Group. Они точно не systemd-специфичные, это передёргивание: такая возможность есть в любом init.

А почему это только User и Group? С той же cgroups можно через голый баш работать. Те же самые пространства имён тоже можно. Всё можно.
>Давайте-ка посмотрим, что без них будет:

Как что? В каждой уважающей себя программе будет отдельный велосипед, для понижения прав.
>Мы наглядно видим, что многие фичи systemd вообще не используются никак.

Про декларативные переопределения, шаблонные юниты вы скромно промолчали.

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

164. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от freehckemail (ok), 30-Янв-26, 16:10 
> Например, потому что он использует NixOS.

Есть два дистрибутива. RHEL (и его производные) и Debian (и его производные).

Смысла смотреть на NixOS нет никакого, этот дистрибутив в продакшене встретить невозможно в принципе.

>> Ну кстати тут уже видно, что многие security-фичи не используются нигде и никем.
> А с чего вы взяли, что каждая опция должна обязательно использоваться в любом случайном юните?

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

> Про декларативные переопределения, шаблонные юниты вы скромно промолчали.

А что про них говорить? Это же просто специфика systemd: если есть — хорошо, если нету — плевать.

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

74. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Анонимemail (74), 30-Янв-26, 12:25 
Хотел тут перейти на Линуху !  С поставил дистр на systemd . И поставил только vmware и  что-то из снап-пакетов. Так оно стало завершать работу по 2 минуты и более ...  

  

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

76. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –2 +/
Сообщение от Аноним (61), 30-Янв-26, 12:26 
Сколько анонимов понабежало. Конечно не нужно: давайте всё запускать от рута и выставлять голыми портами в интернет. Желательно ещё и на дыряшечке всё это делать, а то бедные ботнеты расти не будут.
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

97. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 13:04 
На Баше через работу с /sys любой каприз.
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

106. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 13:19 
"Болтовня ничего не стоит. Покажите мне код" - как говорил самый первый линуксоид.
Ответить | Правка | Наверх | Cообщить модератору

110. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 13:27 
Конкретное ТЗ ?
Ответить | Правка | Наверх | Cообщить модератору

113. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 13:45 
ТЗ - простое: воссоздайте функционал unit на bash-е настолько, насколько это возможно.
Ответить | Правка | Наверх | Cообщить модератору

114. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 13:55 
Это абстрактное абстрактно.
"Сколько вешать в граммах?" Что конкретно надо запустить?
Ответить | Правка | Наверх | Cообщить модератору

129. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:24 
>Что конкретно надо запустить?

Какая разница? Речь не о программе, речь об опциях запуска. Вот допустим, нужно запустить tmux new-session -d, при этом вам нужно отслеживать состояние конкретного юнита, а не любого экземпляра tmux. Далее, при запуске tmux завершается, совершив двойной форк, вам нужно отслеживать его дочерние процессы, при этом все дочерние процессы должны быть завершены при остановке юнита. Далее, вам нужно указать ограничение по памяти. Запуск должен быть от конкретного пользователя, при этом должны быть ограничения по доступу к файловой системе - проброшены только отдельные файлы. Каждый пользователь должен иметь возможность запускать несколько копий юнита, при этом юниты не должны конфликтовать как между пользователями, так и между собой. Каким-то юнитам нужно дать возможность доступа к отдельным путям. Нужно ограничить доступные системные вызова и capabilities. Давайте для начала такой вариант.

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

132. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:30 
И да, пока не забыл - покажите ещё как вы в баше в tmux будете пути передавать, с экранированием, разумеется.
Ответить | Правка | Наверх | Cообщить модератору

135. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 14:36 
В Баше нет некаких юнитов. За кем следить, за процессом?
А что, запускает процесс не тот пользователь, который нужен?
>при этом должны быть ограничения по доступу к файловой системе - проброшены только отдельные файлы.

Вам нужно запустить процесс в контейнере?

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

141. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 14:46 
>В Баше нет некаких юнитов.

Процесс ничего не значит - условный php-fpm состоят из нескольких процессов.
>Вам нужно запустить процесс в контейнере?

Вы предлагаете сразу докер ставить? А кто будет за зависимостями следить?

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

150. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (72), 30-Янв-26, 15:31 
LXC
Зависимости тоже в контейнер.
Ответить | Правка | Наверх | Cообщить модератору

159. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 15:54 
>LXC

Ну отлично. Теперь вместо одной системы будет целая россыпь контейнеров. Куча вещей, типа пакетного менеджера, glibc будет дублироваться. Новых пользователей придётся добавлять в куче мест одновременно. И в итоге, всё равно нужно будет ставить lxc в каждую систему.

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

94. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Аноним (94), 30-Янв-26, 13:02 
Тяжело жить в мире, где не изобрели bsd init.
Ответить | Правка | Наверх | Cообщить модератору

136. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +1 +/
Сообщение от Аноним (-), 30-Янв-26, 14:38 
Сейчас все тупо используют пакет sysVinit. И никто не размещает скрипты в чистом виде именно, как SysV init и BSD-init. Чувак твоё убогое сознание затряло в 1980-х гг.
Ответить | Правка | Наверх | Cообщить модератору

127. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (127), 30-Янв-26, 14:17 
>Переход аргументируется повышением уровня безопасности запускаемых служб systemd, а также более надёжным контролем над запуском и циклом работы службы

Под этим предлогм можно и UKI, lockdown, SecureBoot (залоченный на кого надо), TEE, DRM и FIDO2 требовать. Вангую, что и до этого дойдёт. Не секрет, что это основной драйвер изменений в ядро Linux в последнее время. Как только ядро потребует - так и остальные проекты-содержанки тоже. Не форкать ядро ведь?! Ведь не потянут.

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

137. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноним (137), 30-Янв-26, 14:38 
> Под этим предлогм можно и UKI, lockdown, SecureBoot (залоченный на кого надо), TEE, DRM и FIDO2 требовать.

А что в вышеперечисленных вещах плохого?

> Не секрет, что это основной драйвер изменений в ядро Linux в последнее время.

Логично. Раньше многим было плевать на безопасность, цепочки поставок и прочие странныен вещи. А теперь мир изменился.

> Как только ядро потребует - так и остальные проекты-содержанки тоже.

Содержанкой была твоя мамаша, а эти проекты партнеры ядра - они вместе развивают линукс.

> Не форкать ядро ведь?!

А зачем если им норм?
Ну вот по какой причине? Потому что горстка шизов бухтит?

> Ведь не потянут.

Да, не потянут.
Это просто факт, печальный для всяких повальных какеров и васянов-потребядей.
Как и то, что в ядре решают те, что создает код, а не плебс с улицы.

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

138. "В Debian 14 намерены удалить слой для совместимости systemd ..."  –1 +/
Сообщение от Аноним (137), 30-Янв-26, 14:39 
> Под этим предлогм можно и UKI, lockdown, SecureBoot (залоченный на кого надо), TEE, DRM и FIDO2 требовать.

А что в вышеперечисленных вещах плохого?

> Не секрет, что это основной драйвер изменений в ядро Linux в последнее время.

Логично. Раньше многим было плевать на безопасность, цепочки поставок и прочие странныен вещи. А теперь мир изменился.

> Как только ядро потребует - так и остальные проекты-содержанки тоже.

Содержанкой была твоя мамаша, а эти проекты партнеры ядра - они вместе развивают линукс.

> Не форкать ядро ведь?!

А зачем если им норм?
Ну вот по какой причине? Потому что горстка шизов бухтит?

> Ведь не потянут.

Да, не потянут.
Это просто факт, печальный для всяких повальных какеров и васянов-потребядей.
Как и то, что в ядре решают те, что создает код, а не плебс с улицы.

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

133. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Фнон (?), 30-Янв-26, 14:31 
Забавная тема.
Самое смешное что больше всех против системд топит freehck.
Которого, тем не менее, совершенно не парит launchd на его макбуке.

Я понимаю что уровень "вы не понимаете это другое!" на сайте уже зашкаливает, но такого маневрирования я давненько не встречал.

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

143. Скрыто модератором  +/
Сообщение от mos (??), 30-Янв-26, 14:59 
Ответить | Правка | Наверх | Cообщить модератору

144. Скрыто модератором  +/
Сообщение от Фнон (-), 30-Янв-26, 15:04 
Ответить | Правка | Наверх | Cообщить модератору

145. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (61), 30-Янв-26, 15:05 
>Которого, тем не менее, совершенно не парит launchd на его макбуке.

Вначале продал душу Дьяволу, а теперь Дьявол требует отработки.

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

147. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Fyjy5 (-), 30-Янв-26, 15:12 
>>Которого, тем не менее, совершенно не парит launchd на его макбуке.
> Вначале продал душу Дьяволу, а теперь Дьявол требует отработки.

Сейчас он расскажет, что он просто "предатель рокнрола" и вообще невинная жертва.
Потому что его ВЫНУДИЛИ перейти на macos (плак, плак, какая грустная история).


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

134. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноним (-), 30-Янв-26, 14:35 
>Переход аргументируется повышением уровня безопасности запускаемых служб systemd, а также более надёжным контролем над запуском и циклом работы службы.

Жалкий аргумент. Жалкий проект.

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

162. "В Debian 14 намерены удалить слой для совместимости systemd ..."  +/
Сообщение от Аноня (?), 30-Янв-26, 16:02 
Жалкий коммент. Жалкий аноним.
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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