>>>>> "AC" == Artem Chuprina <r...@ran.pp.ru> writes: >>>>> Ivan Shmakov -> debian-russian@lists.debian.org:
AC> Впрочем, если смотреть шире, то в данном случае это вообще AC> замечательная и вся из себя прекрасная идея ленивых вычислений. AC> Которая, кстати, давно частично реализована в юниксах в части AC> сетевых взаимодействий (inetd). AC> Но полезность inetd ограничена тем, что он, во-первых, не умеет AC> действовать по схеме "при первом запросе поднять сервис и оставить AC> его работать" (а это довольно часто нужно), а во-вторых, не умеет AC> поднять зависимости. А в-третьих, тем, что он это умеет только для AC> сети. IS> Что примечательно, – inetd (почти уверен, — во всех его вариантах) IS> умеет работать не занимая PID 1. Зачем сие потребовалось Systemd — IS> совершенно не представляю. AC> Тут скорее следует говорить о том, что inetd не выполняет функции AC> init, поэтому не заменяет его, потому и не занимает PID 1. Верно. При этом, повторюсь, — запуск процессов — вне зависимости от поддержки зависимостей, Cgroups, и прочих Dbus — совершенно ортогонален выполнению функций init. Примеры — все варианты Inetd, Supervisor, а равно и упомянутый в [1] некий Circus. [1] http://blog.jorgenschaefer.de/2014/07/why-systemd.html AC> А systemd - выполняет, вследствие чего заменяет (ибо нафига тогда AC> еще и init?), поэтому совершенно естественно, что PID 1 достается AC> именно ему. BTW, какие именно функции init (в смысле PID 1) берет на себя Systemd? «Усыновление осиротевших процессов» и запуск условного /etc/init.d/rcS при запуске системы? Так с этими задачами /уже/ справляется SysV init. Для чего потребовалась заново решать эту задачу «с нуля»? -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4tiaeq2....@violet.siamics.net