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

"В 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 ..."	+10 +/–
Сообщение от Аноним (1), 30-Янв-26, 09:59
Ну вот, а говорили, что devuan не нужен.
Ответить | Правка | Наверх | Cообщить модератору

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

	8. "В Debian 14 намерены удалить слой для совместимости systemd ..."	–23 +/–
	Сообщение от Аноним (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 +/–
	Сообщение от freehck (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 ..."	+/–
	Сообщение от gumanzoy (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 ..."	+/–
	Сообщение от freehck (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 ..."	–2 +/–
	Сообщение от 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 ..."	+3 +/–
	Сообщение от Аноним (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ообщить модератору

	176. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от Аноним (-), 30-Янв-26, 17:09
	> Ждём /etc/fstab deprecated? :) Вон там криворукий сэр кидающий предъявы - очень нарывается на такой расклад :). Выпилят ему fstab он и косячить в нем не сможет. Будет юниты sd пилить как зайчик или пойдет на мороз.
	Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

	171. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от Аноним (171), 30-Янв-26, 16:47
	> Админ старой закалки рапортует внутрь. За последние 10 лет было уже три > случая, когда приходилось выезжать на сервер из-за поломанного /etc/fstab. Надо ввести > пароль рута и т.д. > А с sysvinit, s6 и прочими такой фигни не было. Они прекрасно > грузятся и с поломанным fstab ;) За именно такие соотношения этих админов и поуходили нахрен в приличных местах уже. 1) Out of band management? Не, не слышали! 2) Почему-то на боевых серверах телепают fstab вообще. Это наверное best practices. 3) Вон те - прекрасно НЕ грузятся с кучей всего еще. А также кладут на сбои критичных сервисов, факапы старта пререквизитов, и что там еще - без единой записи в какие либо логи. Так что угадай вообще почему это месиво костылей и подпорочек тут не раздуплилось. 4) А уж watchdog api за 5 минут прикрутить как знакомый devops к проблемному сервису... :) > Был правда и случай, когда NetworkManager помог - получил адрес по DHCP. > Но пока только один такой случай ;) Плохому танцору всегда что-то мешает. А nm на сервере вообще вызывает определенные вопросы :)
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	54. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от freehck (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 +/–
	Сообщение от freehck (ok), 30-Янв-26, 13:07
	> Лучше бы ты приложил свой коммент как системд тебе все сломала и как ты бессонными подымал сервера. Или страдания с вейландом и иксами. В очередной раз повторяю: здорового человека страдания других людей расстраивают, а не радуют. Обратись к специалистам. Тебе нужна помощь.
	Ответить | Правка | Наверх | Cообщить модератору

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

	172. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от Аноним (171), 30-Янв-26, 16:52
	> Они пользуются Windows 11. Вообще-то Win11 с его AI, рекламой, онлайн аккаунтами и прочими "улучшениями качества обслуживания" - пользователей бесит просто неимоверно. Я думаю что если бы выбор был - большая часть остались бы на чем-то типа Win7 а не страшенных маркетинговых потугах опосля нее. Но ее уже давно не поддерживает MS и на нее уже подзабивают девы. И вот приходится выбирать - кушать г-но или г-но? Потому что конфеты майкрософт уже давно разучился производить. И теперь шоколадный у них только глаз.
	Ответить | Правка | Наверх | Cообщить модератору

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

	177. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от Аноним (-), 30-Янв-26, 17:13
	> Бесит, да - но они никогда не выберут Linux. Never say never. Вот прям ща меня донимают два юзверя с онлайн подсказками как нарулить эту их убунточку и еще кой-какой софт. Да, это жрет мое время. Но у меня свои виды на это все - в будущем они научатся ходить ко мне на пантеон и мы вместе подевелопаем интересные нам вещи. А совсем потребители умеющие только качать права - вот они пусть куда угодно и деваются. Мне их участь пофиг.
	Ответить | Правка | Наверх | 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
	Systemd, для смузихлебов.
	Ответить | Правка | К родителю #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 ..."	+/–
	Сообщение от Аноним (15), 30-Янв-26, 11:01
	Аргументов касательно безопасности лапши на баше, конечно, никто приводить не станет.
	Ответить | Правка | Наверх | Cообщить модератору

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

	90. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от Аноним (-), 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 ..."	+1 +/–
	Сообщение от Аноним (128), 30-Янв-26, 14:23
	> Про runit или dinit вы не слыхали. Слыхали. Очередные васяноподелия, используемые в маргинальных дистрах вроде antiX, Dragora, Void, Chimera, Artix и тд. Дальше что? Ты продолжи свою мысль.
	Ответить | Правка | Наверх | Cообщить модератору

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

	154. Скрыто модератором	+/–
	Сообщение от Аноним (72), 30-Янв-26, 15:46
	Bash не работает низкоуровнево с памятью. Значит, никаких выходой и юзов после освобождения. Это основные аргументы проблем работы с памятью из уст любителей Раста.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

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

	33. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от freehck (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 +/–
	Сообщение от freehck (ok), 30-Янв-26, 11:43
	> Красноглазики - ко ко ко корпорации зло и нам нужен стандарт. Чел от корпов выкатывает стандарт и ко ко ко это галимый стандарт и вобще фу. Не, ну если передёргивать, то можно конечно и так историю преподнести, и это даже забавно звучит. =) Однако на самом деле: - "Красноглазики" считали, что нужен "стандарт, основанный на консенсусе". - Корпы это саботировали и пропихнули "стандарт, основанный на вендор-локе". Да, и то, и другое — "стандарт". Но есть нюанс. =) Полная история тут: https://www.opennet.me/openforum/vsluhforumID3/138071.html#174
	Ответить | Правка | Наверх | Cообщить модератору

	64. Скрыто модератором	+1 +/–
	Сообщение от Fyjy4 (-), 30-Янв-26, 12:14
	> Однако на самом деле: >  - "Красноглазики" считали, что нужен "стандарт, основанный на консенсусе". Учитывая сколько инитов породили "красноглазики", то консенсуса не могло быть даже в теории. Плюс, когда делали очередной новый инит, то его делали как раз для себя из-за отсутствие консенсуса и забив на мнение всех остальных. >  - Корпы это саботировали и пропихнули "стандарт, основанный на вендор-локе". Корпы сделали хороший системный менеджер. И все остальные просто вымерли везде где "нужно ехать", а не шашечки. > Да, и то, и другое — "стандарт". Но есть нюанс. =) Как первое могло стать стандартом, если так и не смогли договориться?)) > Полная история тут: https://www.opennet.me/openforum/vsluhforumID3/138071.html#174 Прохладная история :)
	Ответить | Правка | Наверх | 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 ..."	+1 +/–
Сообщение от Fyjy4 (?), 30-Янв-26, 11:57
Как-то дебианцы разбушевались в последнее время! То armel и mips64el выкидывают, то конвертор в занюханные башпортянки. Что дальше? Будут обновлять версии софта на менее копролитные? Неужели деб превращается в нормальных дистр?!
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

	146. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+1 +/–
	Сообщение от freehck (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 ..."	+/–
	Сообщение от freehck (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ообщить модератору

	175. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от Аноним (61), 30-Янв-26, 17:07
	>Каждая такая фича увеличивает attack surface. Вы забыли приложить доказательства. >Если фича используется только в одном-двух сервисах — так может ей лучше не быть в pid-1? Давайте запускать всё от рута, а то ботнеты совсем расти перестали. >Таким образом, из нетривиальных сервисов systemd-специфичные опции используются за пределами самого systemd — исключительно в софте от Red Hat. Да? А это тогда что https://github.com/tmux/tmux/blob/d7f59eccaf7f9435065017fa21... ? Или tmux тоже разработан Red Hat?
	Ответить | Правка | К родителю #152 | Наверх | 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 ..."	+/–
	Сообщение от freehck (ok), 30-Янв-26, 16:10
	> Например, потому что он использует NixOS. Есть два дистрибутива. RHEL (и его производные) и Debian (и его производные). Смысла смотреть на NixOS нет никакого, этот дистрибутив в продакшене встретить невозможно в принципе. >> Ну кстати тут уже видно, что многие security-фичи не используются нигде и никем. > А с чего вы взяли, что каждая опция должна обязательно использоваться в любом случайном юните? Вообще-то всё наоборот, команды выше как раз учтут юнит в подсчёте, если есть хоть одна из обозначенных тобой опций. > Про декларативные переопределения, шаблонные юниты вы скромно промолчали. А что про них говорить? Это же просто специфика systemd: если есть — хорошо, если нету — плевать.
	Ответить | Правка | Наверх | Cообщить модератору

	174. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+/–
	Сообщение от Аноним (61), 30-Янв-26, 16:58
	>Есть два дистрибутива. RHEL (и его производные) и Debian (и его производные). Очередная ложь. >Смысла смотреть на NixOS нет никакого, этот дистрибутив в продакшене встретить невозможно в принципе. Продакшин - это вещь растяжимая. Вначале люди ставят centos, а потом отключают selinux. Это уже продакшин или ещё нет? >Вообще-то всё наоборот, команды выше как раз учтут юнит в подсчёте, если есть хоть одна из обозначенных тобой опций. Вы почему-то считаете, что каждая опция будет хотя бы в одном юните в вашей системе. Почему? Вполне логично, что часть опций использоваться не будет. Даже торт не обязан содержать все виды посыпок одновременно. >Это же просто специфика systemd: если есть — хорошо, если нету — плевать. Это единственный адекватный вариант. В противном случае, у вас будет костыль, неожиданно разваливающийся из-за погоды на Марсе.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	74. "В Debian 14 намерены удалить слой для совместимости systemd ..."	+1 +/–
	Сообщение от Аноним (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. Скрыто модератором	–1 +/–
Сообщение от Аноним (-), 30-Янв-26, 14:35
>Переход аргументируется повышением уровня безопасности запускаемых служб systemd, а также более надёжным контролем над запуском и циклом работы службы. Жалкий аргумент. Жалкий проект.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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