Рич Фелкер (Rich Felker), автор системной библиотеки musl (http://www.musl-libc.org/), участник проекта Openwall (http://www.openwall.com/) и член группы Austin Group (http://en.wikipedia.org/wiki/Austin_Group), развивающей и поддерживающей стандарты POSIX,
опубликовал (http://ewontfix.com/14/) заметку "Broken by design: systemd" с критикой systemd. По мнению Фелкера, архитектура systemd изначально является ущербной из-за интеграции в init-процесс сторонних функций, непосредственно не связанных с процессом загрузки. Подобное нагромождение негативно сказывается на надёжности и безопасности.
Фелкер выделяет три основные архитектурные проблемы systemd:- В Unix-системах PID 1 имеет специальное назначение, в частности, PID 1 становится родителем для осиротевших процессов и поддерживает специальную семантику сигналов. В случае краха обработчика PID 1, происходит крах всей системы (kernel panic). Традиционные системы инициализации минимизируют размер кода и число функций обработчика PID 1, в то время как systemd выносит на уровень PID 1 серию демонов, реализующих вторичные функции, что приводит к общему снижению надёжности. Если традиционный init-процесс занимается лишь обработкой сигнала SIGCHLD от осиротевших процессов и реагирует на смену администратором текущего уровня запуска (runlevel), то systemd дополнительно занимается такими вещами, как управление подключением и отключением устройств, изменением точек монтирования, слежение за состоянием элементов в ФС и даже обработка запросов через DBus API.
- В защищённой системе без systemd, обычно присутствует только один привилегированный процесс, критичный для проведения атаки, - sshd. Все остальные компоненты управляются и получают входные данные только от пользователя root. В случае systemd присутствуют каналы взаимодействия с непривилегированным пользователем. Реализация расширенных функций в systemd приводит к необходимости выполнения на привилегированном уровне лишнего кода по выделению ресурсов, обработки файлов, разбору сообщений и обработке строковых данных, что увеличивает риск возникновения уязвимостей, которые могут быть эксплуатированы непривилегированным пользователем.- Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.
URL: http://ewontfix.com/14/
Новость: http://www.opennet.me/opennews/art.shtml?num=39050
Слава богу остались еще здравомыслящие!
Нам от этого не легче, т.к. системг уже повсюду.
Гентушники не прогнутся!
У гентушников нет такой чёткой зависимости на те или иные технологии.
Это и есть идея этого дистрибутива.Установлен и systemd, и openrc (который работает поверх sysvinit). Работаю на последнем.
Первый просто не дотягивает по надёжности до второго. Сильно не дотягивает.
Вот и всё.В бинарных дистрибутивах всё несколько иначе (дебиан например). Хочешь, не хочешь, а будешь работать с тем, что есть.
> Первый просто не дотягивает по надёжности до второго. Сильно не дотягивает.
> Вот и всё.Ага. Никто, кроме OpenRC, не умеет так надежно зависать, что при загрузке, что при выключении. Поэтому в генте системГ, как ни странно, наиболее вменяемый вариант - более-менее поддерживается (в отличие от sysv) и при этом не виснет.
а systemd ? тут недавно были репорты об этом..
> а systemd ? тут недавно были репорты об этом..Да, под вяндой не запускается :)
> а systemd ? тут недавно были репорты об этом..Что, не работает у тебя в восьмерочке? Или что там у тебя, макось?
>Ага. Никто, кроме OpenRC, не умеет так надежно зависать, что при загрузке, что при выключении.OpenRC вообще не процесс.
OpenRC — это набор утилит для настройки окружения в котором будут (от слова будущее) выполнятся демоны и только.
Процессами в генту (с OpenRC) управляет /sbin/init из стандартного sys-apps/sysvinit.Так что не знаю где вы нахватались этих «знаний», но каша у вас в голове знатная.
> OpenRC вообще не процесс.
> OpenRC — это набор утилит для настройки окружения в котором будут (от
> слова будущее) выполнятся демоны и только.
> Процессами в генту (с OpenRC) управляет /sbin/init из стандартного sys-apps/sysvinit.И зависает при загрузке/выключении тоже он? А почем в дебиане не виснет?
А кто тебе сказал, что зависает?
Сам то ты не мог этого видеть, потому как вообще не знаешь что это.
> А кто тебе сказал, что зависает?
> Сам то ты не мог этого видеть, потому как вообще не знаешь что это.А чего тут знать? Включаешь, начинает грузиться, останавливается. И все.
>А чего тут знать? Включаешь, начинает грузиться, останавливается. И все.Брехня.
>>А чего тут знать? Включаешь, начинает грузиться, останавливается. И все.
> Брехня.Openrc не виснет, ага. Верю. Эти глаза не могут лгать!
Да кстати, категории верю-не_верю — это ваш удел.
> Да кстати, категории верю-не_верю — это ваш удел.Ну вы же ничего, кроме голословных утверждений, предложить не можете.
Могу. И приводил. Повторяю:
# equery belongs /sbin/init
* Searching for /sbin/init ...
sys-apps/sysvinit-2.88-r4 (/sbin/init)
^C
# eix sys-apps/sysvinit
[I] sys-apps/sysvinit
Available versions: 2.88-r4 ~2.88-r5 ~2.88-r6 {ibm selinux static KERNEL="FreeBSD"}
Installed versions: 2.88-r4(21:27:31 06.06.2013)(-ibm -selinux -static KERNEL="-FreeBSD")
Homepage: http://savannah.nongnu.org/projects/sysvinit
Description: /sbin/init - parent of all processesИ это тот же самый init, что и в debian, который и обсуждаем.
Теперь ты приводишь пруф, где openrc заменяет процесс с PID = 1.
> И это тот же самый init, что и в debian, который и обсуждаем.
> Теперь ты приводишь пруф, где openrc заменяет процесс с PID = 1.А теперь, внимание, вопрос - зачем нужна левая прослойка между инитом и системой, если она все равно кривая и глючная?
Ты пруф для начала предоставь.
А то слишком асимметрично получается — я тебе с пруфами, а ты мне только брехнёй.
> Ты пруф для начала предоставь.Только после вас :)
> А то слишком асимметрично получается — я тебе с пруфами, а ты мне только брехнёй.
Я пока пруфов от вас не видел, только "философию".
Понятно, от тyпого бота ничего другого и не ожидал. ☺
> Гентушники не прогнутся!У гентушников свой поттеринг (Luca U Barbato), который не чуть не менее фимозен, чем редхатовский. Поэтому и не прогнутся.
А можно чуть подробней про данного товарища?
Чем он вреден?
> А можно чуть подробней про данного товарища?
> Чем он вреден?Можно погуглить. Его тоже NIH кусает довольно конкретно, только по своему.
> Нам от этого не легче, т.к. системг уже повсюду.Живу на альте с sysvinit и нас тут таких в core team достаточно.
>> Нам от этого не легче, т.к. системг уже повсюду.
> Живу на альте с sysvinit и нас тут таких в core team
> достаточно.И себе на альт переехать, что ли?! Переходить на сыстемГ пока не планируете?
Они уже перешли на десктопных :)Но серверные дистрибутивы нет и сборки есть без этого Г
Есть выбор при установке - systemd или sivinit...
> И себе на альт переехать, что ли?! Переходить на сыстемГ пока не планируете?Переедь на убунту.
>>> Нам от этого не легче, т.к. системг уже повсюду.
>> Живу на альте с sysvinit и нас тут таких в core team
>> достаточно.
> И себе на альт переехать, что ли?! Переходить на сыстемГ пока не планируете?В официальные десктопы 7.0.x воткнули ради NM/udisks (по сути polkit), в официальном сервере -- на выбор, а мои сборки вот: http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkima.../ (ассортимент обсуждаем, но в число стартеркитов входит экспериментальный инсталер TDE/sysvinit). См. тж. http://altlinux.org/sysvinit
> Живу на альте с sysvinit и нас тут таких в core team достаточно.У вас в альте вообще нездоровой некромансии на мой вкус как-то слишком много, что достаточно сильно нагибает развитие вашей системы, если вы еще вдруг не заметили. Скатывается в маргинальное местечковое болотце, по типу какого-нибудь опенбсд, только от линукса.
>> Живу на альте с sysvinit и нас тут таких в core team достаточно.
> У вас в альте вообще нездоровой некромансииВспомнился диалог: "а чем вы вирусы лечите? -- а мы их не лечим, они у нас и так здоровые!"...
Когда убунтушник рассказывает о нездоровой некромансии, остаётся пожать плечами и пожелать удачи в краю победившей здоровой некромансии.
> а мы их не лечим, они у нас и так здоровые!"...Тут скорее уместнее юмор про то что с такими друзьями - никаких врагов не надо. Граждане сами нагибают развитие своего проекта рядом странных решений, до состояния когда всерьез это никто не воспринимает практически. Ну то-есть какая-то групка маргиналов копошится и что-то делает, но результат работы таковых только этой групке нужен и понятен.
> Когда убунтушник рассказывает о нездоровой некромансии, остаётся
> пожать плечами и пожелать удачи в краю победившей здоровой некромансии.Забойный аргумент. Но убунтами почему-то пользуется толпа народа, так что проблем найти софт под них нет, в отличие от. А самолично все программы собирать может и задолбать.
> Но убунтами почему-то пользуется толпа народаа виндой — ещё большая толпа. убунта — нищебродский красноглазый отстой получается по такой «логике».
>> Когда убунтушник рассказывает о нездоровой некромансии, остаётся
>> пожать плечами и пожелать удачи в краю победившей здоровой некромансии.
> Забойный аргумент. Но убунтами почему-то пользуется толпа народа...как и некрософтом. В первую очередь -- жертвы рекламы, во вторую -- массовости.
> Нам от этого не легче, т.к. системг уже повсюду.В убунте его нет и не будет.
> В убунте его нет и не будет.Да, примерно так: # ls -la /usr/lib/upstart
lrwxrwxrwx 1 root root 6 авг 22 18:42 upstart -> /usr/lib/systemd
Ждем systemd2 несовместимый с первым
И включающий в себя первый системд, иксы, вэйланд и ядро.
Гнум забыл.
> Ждем systemd2 несовместимый с первымОт компании Canonical. Им как раз нужен ход конем.
у них уже есть
прям внутре упстарта
и другого не надо
> остались еще здравомыслящие!Да их много. И подобных доводов тоже.
Просто в опенсорсе стала наблюдаться определённая тенденция — обозвать таких людей ретроградами (или ещё как похуже) и к их мнению уже можно не прислушиваться.Кстати, для параноиков из безопасности сам факт навязывания не нужной (не необходимой) функциональности должен стучать колоколом по голове — просто так усложнять систему с чёткими требованиями обычно никто не собирается.
чем сложнее система - тем легче внедрить бекдоры. и тем выше спрос на топовое железо.
возможно, это стратегия других мыслящих, привязавших к поттерингу удочку с морковкой.
аналогично дело с гномом третьему (чей gdm даже в гентухе systemd требует), а также прочими безвременно усопшими от излишнего весу продуктами.
> чем сложнее система - тем легче внедрить бекдоры. и тем выше спрос на топовое железо.По этой логике, все должны использовать FreeDOS.
По этой логике все должны использовать системы ровно настолько сложные, насколько это необходимо.
Что собственно и составляет принцип KISS — http://ru.wikipedia.org/wiki/KISS_%28%D0%BF&#...
>KISS (англ. keep it simple, stupid — «не усложняй, тупица» или более вежливый вариант англ. keep it short and simple — «делай короче и проще») — … Эрик Рэймонд в своей книге резюмирует философию Unix как широко используемый принцип KISSИли в общем случае — философию Unix — http://ru.wikipedia.org/wiki/Unix_way
>Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.А вот то, что сказали вы — это либо зачаточное развитие вашего логического мышления,… либо методичка беспринципного тролля.
Так кто же вы?
> По этой логике все должны использовать системы ровно настолько сложные, насколько это необходимо.А кто определяет меру этой сложности и сравнивает ее с эталоном?
И кто определяет понятие "необходимого"? Вот на слаке, например, управление зависимостями не считается необходимой фичей пакетного менеджера. С точки зрения слакварщика, portage - это блоатварь и не юниксвейно.
>А кто определяет меру этой сложности и сравнивает ее с эталоном?Функциональные требования определяют.
Если конечно вы гуманитарий, а не инженер, то простительно этого не понимать.
Так вы ответите на вопрос или нет?
Или будете продолжать заниматься передёргиванием и подменой понятий?
> Функциональные требования определяют.
> Если конечно вы гуманитарий, а не инженер, то простительно этого не понимать.Ну вот управление зависимостями в пакетном менеджере - это функциональное требование?
Слакварщики говорят, что нет. И, раз у них все работает, они, видимо, правы.
А значит, portage - поттеринг-стайл блоатварь.> Так вы ответите на вопрос или нет?
> Или будете продолжать заниматься передёргиванием и подменой понятий?Я продолжаю выставлять напоказ ваше стремление бросаться красивыми фразами.
Решили съехать с благодатной темы управления процессами?
Понимаю. С вашими э-м-м… данными только офтопить и остаётся.
> Решили съехать с благодатной темы управления процессами?
> Понимаю. С вашими э-м-м… данными только офтопить и остаётся.Всего лишь показываю несостоятельность вашей "философии".
Просто в силу того, представления о необходимом - в большинстве случаев субъективны.
Ау! Гуманитарий! Речи ро философию вообще не было.
Тебе на другой ресурс надо. Речь про построение инженерных систем.
> Ау! Гуманитарий! Речи ро философию вообще не было.См. комментарий 118.
> Тебе на другой ресурс надо. Речь про построение инженерных систем.
"Настоящий технарь", вроде вас, подходит к этому вопросу исключительно с философской точки зрения :)
>> Ау! Гуманитарий! Речи ро философию вообще не было.
>См. комментарий 118.Не поверишь, там про технические требования.
>"Настоящий технарь", вроде вас, подходит к этому вопросу исключительно с философской точки зрения :)Не правда, исключительно с технической.
Это для вас юникс-вей — это философия. Для меня же список технических требований и рекомендаций.
Вы, гуманитарии, должны чётко это понимать при общении с технарями.
> Не поверишь, там про технические требования."Технические требования" в рамках данной философии - вещь субъективная. Поэтому и "философия".
Вася скажет, что необходимо одно, а Петя - что другое. И начнется философский спор...> Это для вас юникс-вей — это философия. Для меня же список технических требований и рекомендаций.
Для вас это красивые фразы, которые можно использовать как угодно, не более.
>"Технические требования" в рамках данной философии - вещь субъективная.Мы тут всё больше про технические требования в рамках данной конкретной задачи init/systemd.
>Для вас это красивые фразы, которые можно использовать как угодно, не более.Докажи.
> Мы тут всё больше про технические требования в рамках данной конкретной задачи init/systemd.Разработчики большинства дистрибутивов, включая Дебиан, считают, что фичи systemd таки необходимы для системы инициализации. Иначе они не стали бы его включать.
> Докажи.
А чего тут доказывать - достаточно перечитать ваши комментарии.
> Функциональные требования определяют.А кто задает эти требования? <#include trollface.txt>
Кто сказал, что GNU/Linux должен копировать Unix и следовать его философии? GNU прямо отрицает это: GNU is Not Unix. Systemd является вполне логичным подтверждением этого принципа, я считаю.
>GNU is a recursive acronym for "GNU's Not Unix!", chosen because GNU's design is Unix-like, but differs from Unix by being free software and containing no Unix codeТолько айзен и мс-боты стоят на страже свободы подменять понятия и манипулировать фактами.
Самое забавное (в тему паранойи, наличие которой как известно не говорит о том, что за тобой не следят), что и systemd, и gnome3 развивается компанией, которая прямо заявило, что десктопный сегмент её не интересует.
Соответсвенно от фэйла этого сегмента она и не пострадает.зыж
Ну пока что gdm-3.10.0.1.ebuild выглядит так:
…
systemd? ( >=sys-apps/systemd-186[pam] )
!systemd? (
>=x11-base/xorg-server-1.14.3-r1
>=sys-auth/consolekit-0.4.5_p20120320-r2!<sys-apps/openrc-0.12
)
…
т.е. вполне (ещё?) возможно собрать без systemd
в любом случае, я пользуюсь slim что и остальным рекомендую.
"Во-первых, я тот кувшин не брала, во-вторых, уже вернула, в-третьих, он и так был с трещиной" :)
Сделка или “Выражайтесь яснее!“
> Сделка или “Выражайтесь яснее!“Уровень вашей аргументации и ее логичность показаны яснее некуда :)
Да, и это правда ☺
> чем сложнее система - тем легче внедрить бекдоры. и тем выше спрос
> на топовое железо.скорее - тем лече продать услуги по настройке и сопровождению. Что кстати и продает redhat ...
> Да их много. И подобных доводов тоже.Только доводы у них какие-то откровенно притянутые за уши. И заодно, бьющие по довольно широким полям - systemd, upstart, openrc.
> Кстати, для параноиков из безопасности сам факт навязывания не нужной (не необходимой)
> функциональности должен стучать колоколом по голове — просто так усложнять систему
> с чёткими требованиями обычно никто не собирается.Что, разработчики openrc отказались от идеи внедрения cgroups? А то на современной генте смотришь в вывод mount, и понимаешь, что леннард и сюда добрался.
>Только доводы у них какие-то откровенно притянутые за уши. И заодно, бьющие по довольно широким полям - systemd, upstart, openrc.Для гуманитариев разве что.
>Что, разработчики openrc отказались от идеи внедрения cgroups? А то на современной генте смотришь в вывод mount, и понимаешь, что леннард и сюда добрался.cgroups — это трэйд-марк похтеринга?
или вы решили побить рекорд самого тупого комментатора?
>>Только доводы у них какие-то откровенно притянутые за уши. И заодно, бьющие по довольно широким полям - systemd, upstart, openrc.
> Для гуманитариев разве что.Нужно быть гуманитарием, чтобы увидеть, что в upstart и openrc начали пихать все подряд по образу и подобию леннарда?
> cgroups — это трэйд-марк похтеринга?
cgrups _в ините_ - безусловно. Это целиком его идея, никто до него раньше такого не делал.
И что характерно - это не является функциональным требованием. init отлично работает без cgroups, а наличие в нем дополнительного кода делает его более уязвимым.
>Нужно быть гуманитарием, чтобы увидеть, что в upstart и openrc начали пихать все подряд по образу и подобию леннарда?Да! :D
>cgrups _в ините_ - безусловно. Это целиком его идея, никто до него раньше такого не делал.
Интересно, а для чего тогда придумали cgroups, как не для управления процессами?
Во бред то.>И что характерно - это не является функциональным требованием. init отлично работает без cgroups, а наличие в нем дополнительного кода делает его более уязвимым.
Именно поэтому в openrc можно включить поддержку cgroups, а можно и не включать:
# cat /etc/rc.conf|grep cgroup
# If you have cgroups turned on in your kernel, this switch controls
# /sys/fs/cgroup.
#rc_controller_cgroups="YES"
# The following settings allow you to set up values for the cgroup
# rc_cgroup_cpu="
#cgroups, see Documentation/cgroups/* in the linux kernel source tree.
#rc_cgroup_blkio=""
#rc_cgroup_cpu=""
…
>>Нужно быть гуманитарием, чтобы увидеть, что в upstart и openrc начали пихать все подряд по образу и подобию леннарда?
> Да! :DТогда в код и чейнджлоги openrc и upstart лучше не смотреть - можно зашквариться.
>>cgrups _в ините_ - безусловно. Это целиком его идея, никто до него раньше такого не делал.
> Интересно, а для чего тогда придумали cgroups, как не для управления процессами?Почему-то, до появления поттера, это управление прекрасно жило в сторонних демонах, никак не связанных с инитом.
>>И что характерно - это не является функциональным требованием. init отлично работает без cgroups, а наличие в нем дополнительного кода делает его более уязвимым.
> Именно поэтому в openrc можно включить поддержку cgroups, а можно и не включать:Ну так многие фичи systemГ тоже можно не использовать. От этого связанный с ними код исчезает?
>Тогда в код и чейнджлоги openrc и upstart лучше не смотреть - можно зашквариться.Не вам, господин гуманитарий, говорить о коде и чейнджлогах.
Вы, как выяснилось ниже, вообще не понимаете о чём пытаетесь рассуждать.
> Не вам, господин гуманитарий, говорить о коде и чейнджлогах.Ну да, я-то туда хотя бы заглядывал. А значит, зашкварился гуманитарщиной :)
"Настоящий технарь" должен только рассуждать о философии unix.> Вы, как выяснилось ниже, вообще не понимаете о чём пытаетесь рассуждать.
То есть, вы перешли от аргументированных (хоть как-то) возражений к слепому отрицанию.
>> Не вам, господин гуманитарий, говорить о коде и чейнджлогах.
> Ну да, я-то туда хотя бы заглядывал.Брехня. Вы до сегодняшнего обсуждения не знали что openrc не заменяет init.
> Брехня. Вы до сегодняшнего обсуждения не знали что openrc не заменяет init.Что, прям так не может работать как PID 1?
Угу.
Я ж не просто бот как ты. Вынужден ограничиваться рамками сабжа.
>> Что, прям так не может работать как PID 1?
> Угу.А вы, я смотрю, великий знаток OpenRC.
Про великий не знаю, мне такие категории не интересны.
Но про то как именно он работает с init стараюсь быть в курсе.
Так тебя никто говорить и не заставляет.
зыж
>Нужно быть гуманитарием, чтобы увидеть, что в upstart и openrc начали пихать все подряд по образу и подобию леннарда?
>cgrups _в ините_ - безусловно. Это целиком его идея, никто до него раньше такого не делал.
>И что характерно - это не является функциональным требованием. init отлично работает без cgroups, а наличие в нем дополнительного кода делает его более уязвимым.Самое интересное тут то, что /sbin/init НЕ имеет отношения к openrc.
Представляете, господин гуманитарий? ☺
Openrc работает ПОВЕРХ sys-apps/sysvinit
Представляете КАК вы некомпетентны, если этого не знали, но пытаетесь обсуждать.
Openrc предоставляет расширенную функциональность (включая cgroups) НЕ в составе init (как следствие и не с PID = 1)
> Самое интересное тут то, что /sbin/init НЕ имеет отношения к openrc.
> Представляете, господин гуманитарий? ☺
> Openrc работает ПОВЕРХ sys-apps/sysvinit
> Представляете КАК вы некомпетентны, если этого не знали, но пытаетесь обсуждать.
> Openrc предоставляет расширенную функциональность (включая cgroups) НЕ в составе init
> (как следствие и не с PID = 1)Это что-то меняет? Позволяет системе работать после краха openrc? Улучшает безопасность?
>Это что-то меняет? Позволяет системе работать после краха openrc? Улучшает безопасность?Читайте сабж. Там всё написано.
зыж
Это меняет многое.
А в контексте обсуждения это однозначно указывает на то, что вы полный, законченный гуманитарий (нет в системе процесса openrc. нет его. вообще. и «крахнуться» по этой причине он не может)
При том из тех, кто нифига не смыслит в инженерном проектировании систем.
И как следствие — полная бессмысленность дальнейшего обсуждения этого вопроса с вами.
> Это меняет многое.
> А в контексте обсуждения это однозначно указывает на то, что вы полный,
> законченный гуманитарий (нет в системе процесса openrc. нет его. вообще. и
> «крахнуться» по этой причине он не может)Ага, и вообще никакого openrc нет, это все выдумки :)
А когда я включаю rc_parallel=yes и пытаюсь загрузить систему - виснет, конечно же, /sbin/init, который sysvinit.> При том из тех, кто нифига не смыслит в инженерном проектировании систем.
Ну да, ну да, моя фамилия не Дарьтаньян :)
> И как следствие — полная бессмысленность дальнейшего обсуждения этого вопроса с вами.
Можно засчитывать слив, или еще побарахтаетесь?
>Ага, и вообще никакого openrc нет, это все выдумки :)
>А когда я включаю rc_parallel=yesА вы не включайте.
Не с вашими знаниями куда-то лезть.
Это ж надо, перепутать init и openrc! У вас похтеринг всего мозга. ☺
> А вы не включайте.
> Не с вашими знаниями куда-то лезть.
> Это ж надо, перепутать init и openrc!Да, если я буду знать, что загрузка повис не из-за /sbin/init, а из-за прослойки, построенной над ним - мне определенно станет легче с этим смириться.
>Да, если я буду знать, что загрузка повис не из-за /sbin/init, а из-за прослойки, построенной над ним - мне определенно станет легче с этим смириться.Конечно. Ведь это прослойка между стулом и компьютером.
Ну гвозди себе в голову вы же не будете забивать только из-за того, что делали то, чего не понимаете?
>>Да, если я буду знать, что загрузка повис не из-за /sbin/init, а из-за прослойки, построенной над ним - мне определенно станет легче с этим смириться.
> Конечно. Ведь это прослойка между стулом и компьютером.Вы серьезно заблуждаетесь относительно места openrc в архитектуре системы :)
> Ну гвозди себе в голову вы же не будете забивать только из-за
> того, что делали то, чего не понимаете?Самое обидное, что "разработчики" openrc тоже не будут. Наоборот, они будут пытаться всюду пропихнуть этот откопанный и наспех подкрашенный труп.
>Вы серьезно заблуждаетесь относительно места openrc в архитектуре системы :)Нет.
# ps -ef -H
root 1 0 0 фев08 ? 00:00:02 init [3]
root 3796 1 0 фев08 ? 00:00:05 /usr/lib/systemd/systemd-udevd --daemon
message+ 4962 1 0 фев08 ? 00:00:04 /usr/bin/dbus-daemon --system
root 5047 1 0 фев08 ? 00:00:01 /usr/sbin/NetworkManager --pid-file root 5668 5047 0 фев08 ? 00:00:00 /sbin/dhcpcd -B -K -L -G -c
…
>Самое обидное, что "разработчики" openrc тоже не будут. Наоборот, они будут пытаться всюду пропихнуть этот откопанный и наспех подкрашенный труп.Мне необходимо и достаточно, чтобы они не шли на поводу у таких горлопанов как вы.
А остальное не важно, хоть забрызгайте дерьмом весь опеннет.
> всюду пропихнуть этот откопанный и наспех подкрашенный труп.Прикольно это в дебиане выглядело. Уж так взвились. То чуть ли не годами болт на баги клали, то починили все как ужаленные.
> Это что-то меняет? Позволяет системе работать после краха openrc? Улучшает безопасность?скажи, а как ты дожил до своего возраста вообще? с таким уровнем дебилизма ты давно должен был сыграть в ящик от какого-нибудь бытового несчастного случая. ну, типа, голову в микроволновке высушить или что-нибудь ещё более дебильное сделать.
это скорее не "Леннарт добрался" а "Udev добрался".
некоторые дистры - пытались бороться с косяками укуренных создателей Udev и его фимозным поведением, непредсказуемым, но большинство - сдались.
даже калька - сдулась, увы.
> это скорее не "Леннарт добрался" а "Udev добрался".
> некоторые дистры - пытались бороться с косяками укуренных создателей Udev и его
> фимозным поведением, непредсказуемым, но большинство - сдались.
> даже калька - сдулась, увы.Написали бы свой udev, с барышнями и преферансом. А то пока все такие попытки заканчивались дарением конфеток Леньке и копипастой из "апстрима".
Так давно, mdev сие зовётся. В Gentoo многими используется вместо udev/eudev.
> Так давно, mdev сие зовётся. В Gentoo многими используется вместо udev/eudev.mdev - это аналог udev для встраиваемых систем, с предельно урезанной функциональностью (что на десктопе создает определенные проблемы). К Gentoo никак не относится.
>> Так давно, mdev сие зовётся. В Gentoo многими используется вместо udev/eudev.
> mdev - это аналог udev для встраиваемых систем, с предельно урезанной функциональностью
> (что на десктопе создает определенные проблемы). К Gentoo никак не относится.Просто некоторые странные личности пытаются пропихнуть его в качестве замены udev. Что неизбежно приведет к запихиванию новых фич и расширению кодовой базы... разработчики mdev/busybox будут в восторге.
>Что неизбежно приведет к запихиванию новых фичУ вас есть какие-то основания для подобных утверждений?
>>Что неизбежно приведет к запихиванию новых фич
> У вас есть какие-то основания для подобных утверждений?Железо у десктопников несколько более разлапистое и фичастое чем у встраиваемых систем, знаете ли.
И какие же проблемы это создаёт?К Gentoo очень даже относится - https://wiki.gentoo.org/wiki/Mdev
> И какие же проблемы это создаёт?hotplug, например.
> К Gentoo очень даже относится - https://wiki.gentoo.org/wiki/Mdev
Ну так туда и systemd вместо нормального инита поставить можно, и что?
Что именно "hotplug"? Проблемы с хотплагом в mdev? Какие?>Ну так туда и systemd вместо нормального инита поставить можно, и что?
И то. Многие ставят и пользуются. А вот в бинарных дистрибутивах не очень-то выходит.
> mdev - это аналог udev для встраиваемых систем, с предельно урезанной функциональностью
> (что на десктопе создает определенные проблемы).опиши их, пожалуйста. нет, это не в плане «поиздеваться»: если эти определённые проблемы есть и определены, то никто не мешает выдернуть из ящика mdev, дописать туда решения и забыть про udev как про страшный сон вообще.
> проблемы есть и определены, то никто не мешает выдернуть из ящика
> mdev, дописать туда решения и забыть про udev как про страшный сон вообще.Есть только одна проблема: в процессе он фалломорфирует в такого же монстра как udev :). А так все хорошо, прекрасная маркиза...
> Есть только одна проблема: в процессе он фалломорфирует в такого же монстра
> как udev :)а сие мне неизвестно. для моего использования «на десктопе», например, mdev и сейчас подходит. вот я и интересуюсь знать, что же там за проблемы такие. но, видимо, никогда не узнаю, автор комментария предпочитает играть в партизана на допросе. а мне как-то надоело играть в гестаповца.
С нетерпением ждем вброса Линуса нашего Товальдса про дрочащих на безопасность обезьян.
Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.Ндаа, Винда
Вот не люблю сисямд, но этот пункт - конкретный бред, т.к. systemd, как и любой другой init, умеет сериализовать своё состояние и перезапуститься без перезагрузки системы, сделав exec себя...
Вот не надо фантазий. В новой версии вполне может быть другой АПИ/АБИ.
Так что вот это:
>SIGTERM
> Upon receiving this signal the systemd system manager serializes its state, reexecutes itself and deserializes the saved state again.не относится в общем случае к случаям обновления вообще никак.
> Вот не надо фантазий. В новой версии вполне может быть другой АПИ/АБИ.Когда другой апи/аби - это мажорное обновление системы, вообще-то. Там заодно и ядро, и libc, и все остальные библиотеки обновляются. И тоже со сменой апи/аби. Вряд ли удастся обойтись без перезагрузки.
А при плановом обновлении безопасности, апи/аби не трогают - оно делается за счет бэкпортирования исправлений.
Ещё раз, другими словами, проектирование реагирования на сигнал SIGTERM не предполагало никаких обновлений. Поэтому приписывание этой, побочной функциональности в корне не верно, т.к. грозит нештатными ситуациями.Поэтому высказывание:
>Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.справедливо на все 100%.
Более того, к необходимости перезагрузки приводит обновление не НЕобходимых компонентов.
> Поэтому высказывание:
>> Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.
> справедливо на все 100%.С точки зрения диванных теоретиков - может быть. А федоре или rhel7 после обновления пакета systemd просто выполняется systemctl daemon-reexec, и опа - вместо старого инита уже новый.
>С точки зрения диванных теоретиковКак по http://www.opennet.me/openforum/vsluhforumID3/93954.html#96 ☺
Ещё раз, крайний, для самых тyпых и ещё тyпее ботов — обработка сигналов процессами НИКАК не коррелирует с обновлением ПО.
При чём это известно даже для тех инженеров, которые купили диплом в переходе.
> Как по http://www.opennet.me/openforum/vsluhforumID3/93954.html#96 ☺И в чем это должно кого-то убедить?
> Ещё раз, крайний, для самых тyпых и ещё тyпее ботов — обработка сигналов процессами НИКАК не коррелирует с обновлением ПО.
Скажите это Игорю Сысоеву, например.
> При чём это известно даже для тех инженеров, которые купили диплом в переходе.
Ну точно, Сысоев ведь именно там его купил.
> В новой версии вполне может быть другой АПИ/АБИ.Если в новой версии вполне может быть другой АПИ/АБИ - авторы systemd ССЗБ, т.к. в том же апстарте на уровне этого самого сериализованного представления специально поддерживается совместимость...
Хотя в принципе может это так и есть, вон вроде в journal недавно ломали...
> Вот не люблю сисямд, но этот пункт - конкретный бред, т.к. systemd,
> как и любой другой init, умеет сериализовать своё состояние и перезапуститься
> без перезагрузки системы, сделав exec себя...Что за бред? Укажите строчку в исходниках любого из инитов (sd,v,upstart), где он делает "обновление" через "exec себя".
> Что за бред? Укажите строчку в исходниках любого из инитов (sd,v,upstart), где
> он делает "обновление" через "exec себя".Я могу указать команду, по которой sysvinit делает exec себя - telinit q.
Искать соответствующую строчку в коде - лень.
> Я могу указать команду, по которой sysvinit делает exec себя - telinit q.Не q, а u.
U or u tell init to re-execute itself (preserving the state).
>> Что за бред? Укажите строчку в исходниках любого из инитов (sd,v,upstart), где
>> он делает "обновление" через "exec себя".
> Я могу указать команду, по которой sysvinit делает exec себя - telinit
> q.
> Искать соответствующую строчку в коде - лень.http://www.opennet.me/openforum/vsluhforumID3/93954.html#280
> Вот не люблю сисямд, но этот пункт - конкретный бред, т.к. systemd,
> как и любой другой init, умеет сериализовать своё состояние и перезапуститься
> без перезагрузки системы, сделав exec себя…псто не читай @ фигню отвечай. я знаю, что тебе это пофигу, но я был о тебе сильно лучшего мнения.
> Вынос на уровень системы инициализации дополнительных функций приводит к необходимости
> перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу
> PID 1.Теперь понятно, почему они так обеспокоены скоростью перезагрузки.
> Ндаа, Винда
Это, как известно, не новость.
Я правильно понимаю, вам шашечки главное, а мне вот ехать надо...
не сложно уехать далеко на машине у которой колеса приварены вместо стяжки болтами, но поездка хороша до первого прокола, и пофиг шашечки там или нет... потом только проблемы.
> не сложно уехать далеко на машине у которой колеса приварены вместо стяжки
> болтами, но поездка хороша до первого прокола, и пофиг шашечки там
> или нет... потом только проблемы.Думаю, не каждый догадается, что это стеб над дубовыми "юниксвейными" инитами :)
Ехать на машине, грозящей развалиться при езде?
Главное чтоб с QR-кодами.
> Главное чтоб с QR-кодами.И с безопасной отправкой подписанных логов, которые невозможно подделать, на другой хост по сети!!
> И с безопасной отправкой подписанных логов, которые невозможно подделать, на другой хост
> по сети!!В линуксе это нафиг не надо. Оставим бинарные логи юниксу.
> Ехать на машине, грозящей развалиться при езде?Ну да, автомобили - это ненадежно. Вот телеги - это да, ничего лишнего же!
> Ну да, автомобили - это ненадежно. Вот телеги - это да, ничего
> лишнего же!Тоолсто. Идите пешком. Так надежней.
>О, опять стенания теоретиков. Как это мило.Самостоятельно скомпилируйте systemd для arm, mips или sh.
Со всеми прибамбасами.
Кроскомпилятором.
На практике.О результатах отпишите. Вместе посмеемся.
Не знаю, что вы подразумеваете под самостоятельно. Но в Yocto, Poky, PTXdist systemd есть и вполне стабильно работает. Где смеяться-то?
> Не знаю... Но в ...Понятно. =)
А у вас возникали какие-то фатальные проблемы? Расскажите.
> А у вас ...Понятно. =)
какой же это теоретик - "...автор системной библиотеки musl, участник проекта Openwall ..."
Эдак вы и таблицу умножения теоретизированием объявите.
Да и вообще, что это за эфемерные цифирки да значки - вот одно яблоко, вот два яблока - бери да перекладывай из корзинки в корзинку, и пальцы загибай, будь практиком!
Пустое и никчемное, Вы забыли добавить.
А уж геометрия-то - вообще смех один! Бесконечная плоскость, а? Нет, вы видели этих бесполезных теоретиков? Да где ж они видели такую? Её ведь не-бы-ва-ет!
Любой процесс обработки данных - теоретизирование.
> какой же это теоретикЭто юное дарование знает слово "теоретизирование" (видимо, кто-то его носом ткнул), но не знает о проекте Openwall.
Клевета ушла под нож без лишних объяснений автору.
> Это юное дарование знает слово "теоретизирование" (видимо, кто-то его носом ткнул), но
> не знает о проекте Openwall.Чтобы оценить уровень практических знаний автора доводов в области, о которой он рассуждает, достаточно просто прочитать его рассуждения.
В данном случае такая критика играет даже на пользу systemd - понятно, что автор не докопался ни до каких серьезных проблем, и начал разводить турусы на колесах.
> Это юное дарование знает слово "теоретизирование" (видимо, кто-то его носом ткнул), но
> не знает о проекте Openwall.Одна из главных проблем линуксов в том, что дофига народу бежит кодить, вместо того, чтобы слегка подумать.
> вместо того, чтобы слегка подумать.Есть и обратная проблема: дофига тех кто лучше всех знает как надо, но кодить напрочь не желает. Иногда идеи может и не самые плохие, но кроме автора идеи никто лучше не знает, так что...
> какой же это теоретик - "...автор системной библиотеки musl, участник проекта Openwall ..."Он не теоретик. Но из категории тех кто готов жить в бетонном бункере на километровой глубине. На случай падения метеорита и ядерной войны. Если почитать сайтец проекта. Наработки интересные, но надо быть очень хардкорным мазохистом чтобы ими еще и пользоватся на практике.
> Если почитать сайтец проекта. Наработки интересные, но надо быть очень хардкорным
> мазохистом чтобы ими еще и пользоватся на практике.Ну почему -- куча наработок Openwall используется в альте (или сделана совместно), пользуюсь, мазохистом себя не считаю. :)
Давно замечено, если враги (в данном случае вендузятнеги) нас хвалят, значит что-то делаем не так.
> Давно замечено, если враги (в данном случае вендузятнеги) нас хвалят,
> значит что-то делаем не так.http://fritzmorgen.livejournal.com/660369.html (найдите слово "LOR") -- я о таком уже предупреждал, в т.ч. http://www.opennet.me/openforum/vsluhforumID3/90829.html#134
PS: а, вот эти сообщения подразумевал:
http://www.opennet.me/openforum/vsluhforumID3/93536.html#123
http://www.opennet.me/openforum/vsluhforumID3/93536.html#165Осенью 2013 практически одновременно было отмечено использование новой техники "обвини выбранного оппонента в том, в чём ему логично обвинить тебя, первым" ботами как в общественно-политических обсуждениях, так и на технических форумах. Сперва немного удивился и перепроверил, но эта хуцпа подтвердилась.
Суть такой превентивной контратаки состоит в том, чтобы ошеломить собеседника наглостью подмены понятий; вестись на неё не стоит, а стоит либо стирать/игнорировать, либо показать привселюдно явное противоречие в утверждении бота и то, что его обвинение уместно применительно к нему самому в первую очередь.
Классический пример -- хасид, обвиняющий кого-нибудь в антисемитизме и ненавидящий арабов (которые семиты); нынешний -- "борец за systemd", обвиняющий sysvinit в неюниксвейности.
Имейте в виду и не теряйтесь при виде подобной наглости. Здесь -- "к модератору".
>[оверквотинг удален]
> ботами как в общественно-политических обсуждениях, так и на технических форумах.
> Сперва немного удивился и перепроверил, но эта хуцпа подтвердилась.
> Суть такой превентивной контратаки состоит в том, чтобы ошеломить собеседника наглостью
> подмены понятий; вестись на неё не стоит, а стоит либо стирать/игнорировать,
> либо показать привселюдно явное противоречие в утверждении бота и то, что
> его обвинение уместно применительно к нему самому в первую очередь.
> Классический пример -- хасид, обвиняющий кого-нибудь в антисемитизме и ненавидящий арабов
> (которые семиты); нынешний -- "борец за systemd", обвиняющий sysvinit в неюниксвейности.
> Имейте в виду и не теряйтесь при виде подобной наглости. Здесь
> -- "к модератору".Как можно видеть из соседних топиков, есть люди которые пользуются этой техникой, правда из-за низкого интеллекта не всем такая техника приносит успех.
Миша, поскольку по одной из ссылок ответ на мой комент здесь, то хочу заметить, что платные боты как раз вовсю врут со стороны власти (никоим образом не оправдываю других).
Тут как бы давно курсе о особенностях твоего мышления и твоих предпочтениях.
Фрицморген, в частности, на которого ты сослался - платная жжшлюха.
> Тут как бы давно курсе о особенностях твоего мышления и твоих предпочтениях.
> Фрицморген, в частности, на которого ты сослался - платная жжшлюха.Не знаю, кто это (а Вас не знаю даже по нику) -- но порой и на microsoft.com ссылаюсь, когда там вдруг написана правда. Здесь счёл нужным обратить внимание на то, что уже озвученное получило подтверждение с ещё одной стороны (разумеется, можно попытаться меня "уличить" в негласной связи с тем оратором, но удалю как заведомую ложь).
PS: #252 и ряд других сообщений того же автора удалены на основании озвученной им самим цели -- "навредить линуксу". Передёргивать вредно для здоровья, как и предупреждали.
PPS: http://wiki.opennet.ru/ForumHelp п. 6
> Давно замечено, если враги (в данном случае вендузятнеги) нас хвалят, значит что-то делаем не так.Да, линксмастрип всегда поддерживал противником systemd, например :)
>> Давно замечено, если враги (в данном случае вендузятнеги) нас хвалят,
>> значит что-то делаем не так.
> Да, линксмастрип всегда поддерживал противником systemd, например :)А он обиженный, но не виндузятник.
> но не виндyзятник.Уверены? У него мышление какое-то проприетарно-подстилочное.
О, практик-юзверь не сумевший настроить звуковушку обсуждает разработчиков.
Хорошо тебе висеть у мамы на шее и говорить о теоретиках?
> Я правильно понимаю, вам шашечки главное, а мне вот ехать надо…слушай, сколько тебе скинуться на мотороллер, чтобы ты уже насовсем уехал?
ну, или давай я тебе байдарку подарю и отправлю на Белое море, а? авось утонешь.
и где он раньше был?
когда дебиановцы голосовали =)"Если кто-нибудь из присутствующих знает причину, по которой этот союз невозможен, пусть скажет сейчас или умолкнет навеки!"
> и где он раньше был?
> когда дебиановцы голосовали =)
> "Если кто-нибудь из присутствующих знает причину, по которой этот союз невозможен, пусть
> скажет сейчас или умолкнет навеки!"Во-первых, дебианщики еще ничего не решили. Они еще раз 10 голосовать будут, и все равно в итоге оставят sysv.
Во-вторых, они все-таки технари, и на сабжевое водолейство не поведутся.
http://www.opennet.me/opennews/art.shtml?num=39047
> http://www.opennet.me/opennews/art.shtml?num=39047Повторяю: они ничего не решили. Сначала отменят голосование, потом скажут, что вообще ни имеют права такие вещи решать.
> и где он раньше был?
> когда дебиановцы голосовали =)мир как-то не крутится вокруг бебиана. прикинь.
Отсутствие чувства юмора – это не болезнь, а врожденный порок, который не лечится.
=D
смех без причины — признак очень высокого интеллекта.
в техкомитете Дебиана после "срочного" голосования по системд все окончательно рассрались.
Ян Джексон предложил скинуть с поста председателя техкомитета Бдейла, сказав, что "дико зол". фактически, бдейл слил в сортир все усилия техкомитета по безконфликтному решению проблемы.
уже инициировали процедуру выкидывания Яна Джексона из техкомитета.
Ян Джексон ушёл в оффлайн на несколько дней чтобы успокоится и поставил в блэклист всех членов техкомитета.
т.е. санта барбара ушла на каникулы на несколько дней? =)
ждем продолжения
ян джексон один из самых адекватных людей в дебиане. реально пытался несколько месяцев разработать документ, который бы всех устроил. за который можно было бы голосовать всем.
бидейл несколько раз вбрасывал прстоейшее голосование -- "чё выбираем? системд? апстарт?" -- типа сначала надо решить этот вопрос, остальное потом. причём решить не как сейчас положено -- нужно было набрать 2 к 1 перевес голосов чтобы выиграл претендент, а простым большинством.
а вопросов кроме этого тьма ещё -- поддерживать ли остальные системы инициализации кроме основной, можно ли позволять пакетами требовать какую-то систему инициализации и пр.
в общем бидейлу типа надоело и он решил показать что он тут самый главнюк.либо яна джексона выкинут из техкомитета либо он сам уйдёт. может и из дебиана вообще.
расс олбери предлагает всем успокоиться и не голосовать никому ни за чьё выкидывание
Скандалы, интрига, расследования.
вот что и обидно, сейчас этой возней развалят один старейших и почитаемых дистрибутивпотом меня мучает вопрос, хорошо будет системд, как потом мне с 7ки бесшовно переползти на 8ку? или все таки оставят инит параллельно для серверов, которым нафиг не уперся гном?
==
не есть хорошо в связи с новостями - центом перешедшим под крыло красношапки + переход научного на репы цента
А был бы линукс проприетарныйм, сейчас бы все на форумах фапали на то, какая крутая система инициализации у линукс по сравнению с виндой... opensource разработчики сами роют себе яму...
Systemd отлично поддерживает старые rc скрипты.
> ян джексон один из самых адекватных людей в дебиане. реально пытался несколько
> месяцев разработать документ, который бы всех устроил. за который можно было
> бы голосовать всем.Этот человек упорно пытается протолкнуть upstart. Причем очень эмоционально и фанатично, не считаясь с интересами пользователей.
Например, давеча он предлагал выкинуть (вообще выкинуть из дебиана, насовсем) все DE, использующие API systemd ("чтобы у пользователя была свобода выбора"). Сейчас это гном и E17, а в перспективе и KDE. А вместо них, надо полагать, запихать юнити с миром.Вот такой он вменяемый человек.
>предлагал выкинуть
>гном
>вообще выкинуть из дебиана, насовсемПравильный мужик.
> Правильный мужик.Просто фанбой Марка.
Весьма разумно. Понятия о гигиене у него вполне адекватные.
> Например, давеча он предлагал выкинуть (вообще выкинуть из дебиана, насовсем) все DE,
> использующие API systemd ("чтобы у пользователя была свобода выбора"). Сейчас это
> гном и E17И как это у меня E17 работает без systemd... предупреждение за сознательную ложь.
> И как это у меня E17 работает без systemd... предупреждение за сознательную ложь.Тем не менее, именно E17 стало первым DE, которое поддерживает systemd как инициализатор сеанса.
Поддерживать, и поддерживать только systemd — разные вещи.
>> И как это у меня E17 работает без systemd... предупреждение за сознательную ложь.
> Тем не менее, именно E17 стало первым DE, которое поддерживает systemdЗдесь нет слова "только" и, следовательно, оснований для истерики с тенью на плетне из #120.
> Например, давеча он предлагал выкинуть (вообще выкинуть из дебиана, насовсем) все DE,
> использующие API systemdприкинь, и правильно сказал. правда у вас, фанбоев лёни, все, кто против вашей святыньки — те всенепременно за конкурента.
а вот если бы у тебя были мозги и ты умел читать, то увидел бы, что… а, не важно, всё равно ты идиот.
Я так понимаю, только после того, как systemd был официально включен в деб, рх и еще куче главных дистрибутивов, провелю код-ревью? А ведь основополагающий важный системный компонент.
а там не заинтересованы в данной проверке были, иначе давно бы сделали
А вот да. Systemd обеспечит работу на долгие годы вперед распушхим отделам программистов рх и другим коммерческим компаниям, занимающимся разработкой и поддержкой linux. Никто из внештатных добровольцев этим заниматься не будет.
> А вот да. Systemd обеспечит работу на долгие годы вперед распушхим отделам
> программистов рх и другим коммерческим компаниям, занимающимся разработкой и поддержкой
> linux. Никто из внештатных добровольцев этим заниматься не будет.Как будто им ядра linux мало было. На его фоне, systemd - капля в море.
> приводит к необходимости перезагрузки системы при установке обновлений компонентов systemdДа ладно! Вон nginx перезапускается без остановки при смене бинарника. Пусть подсмотрят и сделают также. Да и старичёк init ведь тоже это умеет. Неужто в systemd не осилят.
А с первыми двумя пунктами что делать?
Ну просто нужно писать ровно:) Ядро же тоже монолитное и огромное.
Вы так это говорите как будто это что-то хорошее.
Он как раз и намекает, что ядро огромное, что "потенциально" ухудшает надежность/безопасность/т.п. Но тем не менее ядро линукс - торт. Никто же эту тему не подымает.
Ядро Линукса совершенно не торт, и вроде все об этом в курсе. К сожалению, иначе, чтоб были драйвера и фичи, и не слишком тормозило, не выходит. Но это не делает его тортом ни в коей мере.
Тогда что же для тебя торт, прости?
ИМХО, торты познаются в сравнении. И в сравнении с остальными, Линух - самый торт. По крайней мере, лучше пока ничего не придумали.
> Тогда что же для тебя торт, прости?
> ИМХО, торты познаются в сравнении. И в сравнении с остальными, Линух -
> самый торт. По крайней мере, лучше пока ничего не придумали."Лучше" - смотря в плане чего. Если в плане безопасности, простоты и надежности (о которых сегодня речь), то есть множество вариантов куда лучше линукса. Правда, фич в них меньше, но это же вторично, правда?
> Но тем не менее ядро линукс - торт. Никто же эту тему не подымает.Поднимают, но в ядре совсем другой стиль управления проектом.
Кстати, да -- интересно, что скажет Линус, когда его достанет "не мытьём, так катаньем" в исполнении шляпы. "F*ck you redhat"?
> Кстати, да — интересно, что скажет Линус, когда его достанетперейдёт на другой сорт вазелина и сменит позу.
> Да ладно! Вон nginx перезапускается без остановки при смене бинарника. Пусть подсмотрят
> и сделают также. Да и старичёк init ведь тоже это умеет.
> Неужто в systemd не осилят.Вообще-то, systemd умел это с самого начала. Только песня была совсем не о том...
самостоятельно форкнуть системД дебианом, перепилить с учетом критики, юзать дав возможность установить остальные альтернативы..
и получить в итоге openrc? =)
> и получить в итоге openrc? =)Наоборот. Если долго допиливать openrc, получится systemd.
нет.
Сколько раз обновлял systemd, не разу не делал сразу после этого перезгрузку, система работает как часики...
ЧЯДНТ?
админишь локалхост
Даже не админю, сижу разработкой занимаюсь, в игрушки играю. Одмины пусть одминят, им до нас далеко
Лёню Поттеринга уже ткнули носом в чтиво ? А то он знай других тыкает, а сам за собой косяков не замечает.
чичас он прочтет, проведет "исследование" и накатает опус, что все не так как написано, его код неправильно поняли и он один дартаньян
=D
> чичас он прочтет, проведет "исследование" и накатает опус, что все не так
> как написано, его код неправильно поняли и он один дартаньян
> =DИ в общем-то, будет прав. В частности, обновление на лету - одна из киллeр-фич systemd (хотя год назад ее таки уперли в upstart).
Размножение костылей ? Ну-ну...
> Размножение костылей ? Ну-ну...Когда некий чувак говорит, что systemd не умеет обновляться на лету - ура, systemd отcтой, я всегда это знал!
Когда выясняется, что systemd таки умеет обновляться на лету - да это же просто ненужный костыль!
> И в общем-то, будет прав. В частности, обновление на лету - одна
> из киллeр-фич systemd (хотя год назад ее таки уперли в upstart).вот ведь… читаю man telinit:
U or u tell init to re-execute itself (preserving the state).киллер-фича, угу.
А вот да, можно ли запустить systemd без dbus-а? На сервере непрозрачные шины ну совсем не впёрлись.
>А вот да, можно ли запустить systemd без dbus-а? На сервере непрозрачные шины ну совсем не впёрлись.Совсем скоро. После пропихивания dbus в ядро.
http://www.opennet.me/opennews/art.shtml?num=38739
> После пропихивания dbus в ядро.Нет уж, оно на серверах всё равно выключено будет.
Так что вопрос остаётся открытым.
> На сервере непрозрачные шины ну совсем не впёрлись.А вы всегда серверные ядра пересобираете без NETLINK? И как после этого на них сеть работает, если не секрет?
>Традиционные системы инициализации минимизируют размер кода и число функций обработчика PID 1Сказки дядюшки микроядерщика
Ядро-то тут причем?
> Ядро-то тут причем?Наверное, при том, что оно предоставляет такую широкую область для атак, что размер инита существенной роли не играет - пока он не дорос до размеров, сопоставимых с ядром. Мегабайтный systemd (со всеми компонентами) на фоне стаметрового ядра немножко... теряется.
Только вот для атаки на ядро со стороны не-root процессов векторов поменьше
Ну и глибсы туда запихни, фигли там на фоне ядра - тоже копейки будут.
Да, даже в Солярисе PID 1 это не svc.startd
Повылазило всяких кэпов, понимаишь. Типа это и так не было понятно всем, кто оборудован матушкой-природой работающим мозгом. Хотя я отчасти понимаю - чтение лениного кода - "удовольствие" еще то.
> Хотя я отчасти понимаю - чтение лениного кода - "удовольствие" еще то.А вы надеетесь, что хоть кто-то из доблестных борцов с systemd, включая сабжевого чувака, хоть раз заглядывал в этот код?
Рич не дочитал до cgroups просто. Если ядро предоставляет к чему-то доступ, то использовать это опасно, да.
Это мнение не в тренде, тебе не рады ленивые одмины
"Unfortunately, it also gets the other properties, including bringing down the whole system when it crashes. This matters because systemd is complex. A lot more complex than traditional init systems"Ну-ну, это инит скрипт то простой в отличие от systemd ? Его случайно не /bin/bash исполняет, такой простой-простой блоб - интерпретатор. Или "простые" скрипты сами себя волшебством исполняют? Сначала изобрети аппаратный интерпретатор скриптов, потом про простоту говори.
В догонку, "Fundamentally, upgrading should never require rebooting unless the component being upgraded is the kernel"Bсе ясно в этим "разработчиком". Неявные зависимости сервисов друг от друга ему похрену, че то там обновили частично, че то перегрузили. То что студент разработчик пять лет назад указал в зависимостях ручками, и сидим довольные. Вроде работает, мышку пошевелил - двигается. Влияние эти подмененные сервисы на другие кнеперегнуженные компоненты не оказывают. Потому что "Я так сказал".
>Ну-ну, это инит скрипт то простой в отличие от systemd ?ты идиот? Скрипты не исполняются в PID 1.
>ты идиот? Скрипты не исполняются в PID 1.Ты программироване по комиксам учил? Автор набросил бред сто раз рассмотренный еще в первые же недели появления systemd. Про якобы простоту скрипров на баше. Игнорируя факт того, что скриgты исполняет охрененный блоб по имени bash, который гораздо сложнее systemd. И в итоге по сложности баш+скрипты сложнее systemd.
> Ну-ну, это инит скрипт то простой в отличие от systemd ?Вы профнепригодны. Марш рассматривать pstree -p на различных системах, в т.ч. во время запуска/останова "тяжёлых" сервисов.
Последующую чушь подобного порядка буду стирать без комментариев.
>> Ну-ну, это инит скрипт то простой в отличие от systemd ?
> Вы профнепригодны. Марш рассматривать pstree -p на различных системах, в т.ч.
> во время запуска/останова "тяжёлых" сервисов.
> Последующую чушь подобного порядка буду стирать без комментариев.а, ну многое становится теперь понятно. Забань по кукисам, плиз с обоих компов, а то биланй динамический адрес дает.
собственно нумер два. еще раз спасибо.
> а, ну многое становится теперь понятно.Сомнения берут, начиная с призыва банить.
> "охрененный блоб по имени bash, который гораздо сложнее systemd"
Хорошо бы увидеть критерии сравнения -- хотя бы по объёму кода, SLOC или ldd, даже без call graph.
К примеру, вот sloccount по systemd-208 без src/{lib,}udev:
Totals grouped by language (dominant language first):и bash-3.2 без {doc,examples,lib,po}:
ansic: 127981 (99.61%)
python: 345 (0.27%)
sh: 161 (0.13%)ansic: 44546 (77.37%)
sh: 5172 (8.98%)
perl: 4105 (7.13%)
yacc: 3749 (6.51%)Вас там точно никто не покусал вот с такими глазами?
> Хорошо бы увидеть критерии сравнения -- хотя бы по объёму кода, SLOC
> или ldd, даже без call graph.300-360К man bash -vs- сборник блого-трудов (как на него |wc ??) Ленарта S-d для S-админов в 26, ... 45? частях.
скажи, пожалуйста: ты всегда пишешь под этим ником? и только под этим? мне это важно, чтобы я щёлкнул кнопочкой и больше не видел твоего дебилизма.
Да, и кукисы никогда не удаляю. Заранее спасибо.
взаимно благодарю.
> Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1."Откинтесь на спинку кресла и отдохните, пока система все сделает за вас". (c) Дядя Билли.
http://monolight.cc/2011/05/the-systemd-fallacy/
Вот вам еще аргументиков.
> Традиционные системы инициализации минимизируют размер кода и число функций обработчика PID 1, в то время как systemd выносит на уровень PID 1 серию демонов, реализующих вторичные функциихахахаха :D ..
ну понятное дело что у systemd есть разные модули (система-то ведь модульная) -- но PID 1 к этим модулям не отновится -- это понимает любой болван.
очевидно -- статья призвана опорочить systemd -- в глазах тех людей кто не знает что это такое
> ну понятное дело что у systemd есть разные модули (система-то ведь модульная)
> -- но PID 1 к этим модулям не отновится -- это понимает любой болван.ldd /proc/1/exe сделать сами справитесь? Или ls -l /proc/1/fd/ посмотреть?
> в глазах тех людей кто не знает что это такое
Ещё один с отрицательной компетентностью...
Уважаемый Xasd, Вы лично _ни хрена_ не понимаете ни в UEFI, ни в systemd, но какого-то лешего лезете со своим розовым бредом в любую тему и по тому, и по другому. Эти бы усилия да в мирных целях -- например, на ответы по соответствующим проблемам на том же stackoverflow.
>> ну понятное дело что у systemd есть разные модули (система-то ведь модульная)
>> -- но PID 1 к этим модулям не отновится -- это понимает любой болван.
> ldd /proc/1/exe сделать сами справитесь? Или ls -l /proc/1/fd/ посмотреть?и зачем эту команду набирать? что это должно показать? список зависимых динамических библиотек необходимых для старта? а для чего на них смотреть? в чём намёк?!
не всё ли равно какое там их количество?!?!?!
если /init УЖЕ запустился -- то УЖЕ не важно сколько там динамически слинковано всего было.
после fork() -- дочерние процессы могут хоть по 20 раз crash`иться -- всё равно родительский процесс (pid 1) будет всё дальше продолжать работать.
> Вы лично _ни хрена_ не понимаете ни в UEFI
ну в этой теме я не буду писать про UEFI . расслабтесь :)
>и зачем эту команду набирать? что это должно показать? список зависимых динамических >библиотек необходимых для старта? а для чего на них смотреть? в чём намёк?!
>не всё ли равно какое там их количество?!?!?!
>если /init УЖЕ запустился -- то УЖЕ не важно сколько там динамически слинковано всего было.Ну как бы они (библиотеки) используются для обработки данных из разных источников (тех же дескрипторов из ls -l /proc/1/fd/), и могут быть использованы для эксплуатации возможной уязвимости при атаке на pid 1. Соответственно, для того чтобы эти уязвимости закрыть, надо презапустить pid 1. И чем больше библиотек в зависимостях, тем больше поводов перезапускать pid 1. Доступно объяснил, или надо ссылку с картинками?
> Ну как бы они (библиотеки) используются для обработки данных из разных источников
> (тех же дескрипторов из ls -l /proc/1/fd/), и могут быть
> использованы для эксплуатации возможной уязвимости при атаке на pid 1. Соответственно,
> для того чтобы эти уязвимости закрыть, надо презапустить pid 1. И
> чем больше библиотек в зависимостях, тем больше поводов перезапускать pid 1.Перезапустить PID 1 - дело максимум двух-трех секунд.
Вы лучше подумайте о том, что от рута работает не только PID 1.
> Перезапустить PID 1 - дело максимум двух-трех секунд.А ядро linux уже научилось работать без pid 1?
>> Перезапустить PID 1 - дело максимум двух-трех секунд.
> А ядро linux уже научилось работать без pid 1?Когда-то относительно дёшево можно было научить, кстати. В 2.4, кажется, это изменилось.
>> Перезапустить PID 1 - дело максимум двух-трех секунд.
> А ядро linux уже научилось работать без pid 1?А вы слышали про такой вызов - exec?
> А вы слышали про такой вызов - exec?Нет, только про execve ).
А вы в курсе что при exec* теряется текущий контекст (включая обработчики сигналов, открытые дескрипторы, и прочая), и что "обновлять" init таким образом, ..э, не целесообразно?
>> А вы слышали про такой вызов - exec?
> Нет, только про execve ).
> А вы в курсе что при exec* теряется текущий контекст (включая обработчики
> сигналов, открытые дескрипторы, и прочая), и что "обновлять" init таким образом,
> ..э, не целесообразно?А про telinit q вы тоже не в курсе?
> А про telinit q вы тоже не в курсе?При чем здесь telinit q?Это просто перечитывание конфигов, никакого exec при этом не делается.
>> А про telinit q вы тоже не в курсе?
> При чем здесь telinit q?Это просто перечитывание конфигов, никакого exec при
> этом не делается.Пардон, telinit u :)
> Пардон, telinit u :)сейчас у него будет ступор, а потом — возможно — поток малосвязной бредятины.
> если /init УЖЕ запустился -- то УЖЕ не важно сколько там динамически
> слинковано всего было.Вот как раз и важно в контексте этого субтреда: при обновлении mmap()-нутых библиотек надо заменить реализацию и в адресном пространстве процессов.
> после fork() -- дочерние процессы могут хоть по 20 раз crash`иться --
> всё равно родительский процесс (pid 1) будет всё дальше продолжать работать.Именно на этот любопытный факт и хотел обратить Ваше внимание.
Вот как выглядят предложенные выхлопы у init(8), за которым привычки падать не наблюдаю:
# ls -l /proc/1/fd/*(и то поналинковали уже со всякими selinux/pcre)
lrwx------ 1 root root 64 фев 10 15:02 /proc/1/fd/10 -> /dev/initctl
# ldd /proc/1/exe
linux-vdso.so.1 (0x00007fffb17ff000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f0916221000)
libc.so.6 => /lib64/libc.so.6 (0x00007f0915e71000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f0915c6c000)
libpcre.so.3 => /lib64/libpcre.so.3 (0x00007f0915a2b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0916463000)
> (и то поналинковали уже со всякими selinux/pcre)Это точно.
<code>
# ldd /proc/1/exe
linux-vdso.so.1 => (0x00007fffa67ff000)
libc.so.6 => /lib/libc.so.6 (0x00007f3a83809000)
/lib/ld-linux-x86-64.so.2 (0x00007f3a83b8a000)
#
</code>
извращенцы, чо.
# ldd /proc/1/exe
not a dynamic executable
дети малые, блин — тащут в рот всякую гадость…
> понимает любой болван.пока что я вижу тут в качестве болвана тебя. как обычно — с желанием Вещать на темы, в которых то не понимаешь вообще ничего.
подытоживая сказанное: реальных проблем нет, но FUD-то надо из чего-то высосать, поэтому будем ныть про то что сделано не "как у нас"
> подытоживая сказанное: реальных проблем нет, но FUD-то надо из чего-то высосать, поэтому
> будем ныть про то что сделано не "как у нас"всё так, да..
причём повелось -- достаточно много народу, похоже, судя по комментариям
> Просто кто-то говорит вещи, которые укладываются в их религиозное мировоззрение. А значит, принимаются истинными без попыток критической оценки.Очень тонко.
Уважаемый знаток системДы, дайте пожалуйста (на чисто русском) почитать, чем именно и как крут этот кусок системы. Это не сарказм, это просьба, потому как есть в ваших словах правда.
О, щас тебе расскажут примерно такой набор щита: сокет-активейшн, пять строк на замену скрипта запуска демона вместо десяти страниц баш-портянок, быстрый перезапуск, неизменяемые логи, простой дебаг, поголовная модульность. Половина из этого не работает нормально но думать некогда - трясти надо.
> О, щас тебе расскажут примерно такой набор щита: сокет-активейшн,Это надо делать в inetd. Чего его не запиливают в RH?
> пять строк на замену скрипта запуска демона вместо десяти страниц баш-портянок,
Быстренько приведите всё разнообразие всех существующих демонов и их требований к пяти переменным. Быстрее!!
> быстрый перезапуск,
Ну, это делают 2 из известных мне демонов. Предлагаю их пропатчить, чтоб они принимали одинаковые сигналы при, одинаково реагировали **на все** промежуточные состояния, ошибки, одинаково откатывалисть пр неудаче и одинаково же сообщали об этом внешнему "агенту".
... Тогда и запускать их _одним баш-скриптом не будет проблемой.
Патчи для больше 2ух демонов - приветствуются!
> неизменяемые логи, простой дебаг, поголовная модульность.
А ты не про S-d? Ну-ну.
насчёт «неизменяемых логов», кстати, тоже очень смешно.
В чём участвует Рич я вижу. А ты чё за хер с горы? Мальчик который даже в tcpdump не шарит?
Просьба к Xasd.
> Просьба к Xasd.если существует определённая <сложность> -- то она обязательно будет где-то реализованна. вопрос -- "где?".
[1] ваше предложение:
пускай /init будет реализован как можно проще без <сложностей> (и работает безотказно), но при этом вся <сложность> перейдёт внутрь демонов, которые запускаются через /init.
[2] предложение systemd:
часть <сложности> будет перенесено из демонов -- внутрь /init. но этот /init будет хорошо отлажен.
итог: в чём разница на практике(?):
в том что в случае [2] -- нужно отлаживать /init -- его <сложность> (и ТОЛЬКО его <сложность>)! например достаточно исправить только 1 ошибку которая может казаться внутри <сложности> /init -- и эта ошибка уже НЕ появится внутри ВСЕХ демонов.
в случае [1] -- так как <сложность> находится внутри каждого демона -- то высока вероятность что разрабочики каждого из демонов будут наступать всякий раз на одни и теже грабли, допуская примерно одинаковые ошибки внутри реализации своих <сложностей>.
в случае [1] -- суммарное число кода больше, и суммарная <сложность> всей системы больше, так как каждый демон реализовывает <сложность> поновой ещё раз.
кому какая разница что /init будет работать безотказно, если каждый из демонов изредка глючит поотдельности.
простой пример -- операция fork() является двольно опасная (дочерние нити Threads -- не клонируются во время fork, но при этом клонируются все состояния примитивов синхронизации). если сделать fork() неосторожно -- то можно в итоге наткнуться на редкий случай зависания. разработчик демона -- может допустить ошибку с fork() очень легко, и очень долго её не замечать [а редкие случаи зависания закрывать в багрепортах -- как not_confirmed]. некоторое библиотеки тоже начинают криво работать после fork() [допустим разработчик демона не совершал ошибок, но разработчик библиотеки накосячил слегка когда не думал о том что кто-то будет использовать fork()].
systemd позволяет не использовать fork() для старта демона [но при этом получить сигнал о том, успешно ли стартонул демон].
ну и кроме fork() -- разумеется systemd решает и другие <сложности>. материала на эту тему есть в избытке. просто привёл один из наиболее примитивных примеров.
> если существует определённая <сложность> -- то она обязательно будет где-то
> реализованна. вопрос -- "где?".hint: часть довольно общей сложности реализована, скажем, в glibc. А не в init.
Однако системды это только полбеды, потому как есть конкретно что ответить по ссылке ниже http://slated.org/the_poetterisation_of_gnu_linux ?
нет никакой беды, не нравится - предложи свой код
Забыли добавить пункт про фирменный стиль кодогенерации автора поделки. Пульсу вон до сих пор костылями подпирают.
>Пульсу вон до сих пор костылями подпирают... в том числе, запилеными аж в ядро.
>>Пульсу вон до сих пор костылями подпирают
> ... в том числе, запилеными аж в ядро.Ну да, заставить звуковые дрова работать в соответствии с API - это определенно костыли.
Ну ничего сейчас Поттеринг еще пару костылей сделает, ну и описанные в новости проблемы станут еще более весомыми, но это тоже будет смотреться как изменения в быстро растущей популярности systemd. В итоге скорее всего через пару релизов, многие дистрибутивы вернутся к той системе которую использовали до перехода на systemd кроме красной шапки конечно, для них все будет решатся пачками патчей.
И резко перейдут с ядра Linux на Hurd, ага :)
> И резко перейдут с ядра Linux на Hurd, ага :)Да фиг знает что в голову придет ))) все равно странно получилось сначала засунули systemd почти во все дистрибутивы а теперь говорят о том что не такой то он хороший как говорилось. У systemd идея была вполне нормальная, реализация идей как всегда не очень, слишком быстро размыли границы что же все таки должна делать система инициализации, а чего не должна. Подпорка там, подпорка тут, работает вроде, выглядит как нечто сделанное на скорую руку.
> все равно странно получилось сначала засунули systemd почти во все дистрибутивы а теперь говорят о том что не такой то он хороший как говорилось.Засунули одни, а говорят другие. Причем их слова звучат убедительно только для тех, кто уже и так убежден, по внерациональным мотивам.
> У systemd идея была вполне нормальная, реализация идей как всегда не очень, слишком быстро размыли границы что же все таки должна делать система инициализации, а чего не должна.
Размытие границ коснулось и альтернативных решений (см. ударное внедрение cgroups в upstart и openrc).
> У systemd идея была вполне нормальная, реализация идей как всегда не очень, слишком быстро размыли границы что же все таки должна делать система инициализации, а чего не должна
Хм. Можете привести конкретный пример таких подпорок?
[deleted: ответил не туда]
> что же все таки должна делать система инициализации, а чего не должнаsystemd это системный демон, а не система инициализации.
"система инициализации" это лишь часть системного демона (хотя и не спорю: это самая главная его часть).
Перезагрузки и BSOD при подключении устройств - где-то я это уже видел...
> systemd дополнительно занимается такими вещами, как управление подключением и отключением устройств, изменением точек монтирования, слежение за состоянием элементов в ФС и даже обработка запросов через DBus API.Большинство дополнительных функций systemd реализовано отдельными демонами.
> Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.
Видимо, человек никогда не работал с systemd.
# systemctl --help|grep daemon-
daemon-reload Reload systemd manager configuration
daemon-reexec Reexecute systemd manager
> Видимо, человек никогда не работал с systemd.вот странно: каждый раз, как вижу кого-то, кто утвержает подобное процитированному — оказывается, что он в лучшем случае материал читал, но не понял. а то и вовсе не читал.
собственно, уже одно это — достаточный резон для того, чтобы держаться от системды подальше. с такой ЦА нормальному человеку не по дороге.
Тонко: https://lists.debian.org/debian-ctte/2014/02/msg00376.html
> Тонко: https://lists.debian.org/debian-ctte/2014/02/msg00376.htmlПо ссылке какая-то истерика очередного фанбоя. Что тут тонкого?
Истерика? Фанбоя? Вы слишком серьёзно воспринимаете написанное. Серьёзно стоит воспринимать, к примеру, вот это: http://slated.org/the_poetterisation_of_gnu_linuxНо никак не пост с превышенным кол-вом восклицательных знаков в каждой строке :)
Да это наоборот довольно толсто.
А вот у Лени получилось тонко - написать жирный оверинженернутый инит, терпеливо подождать, пока дебиановцы на него наткнутся, а потом сидеть и издалека наблюдать, как они бьют друг другу морды за него, и как сообщество одного из самых старых и почитаемых дистров разваливается на куски. А сам Леня, какбэ, ни при чем. Вот это - тонко.
ну, суть автор - точно подметил
сьюстемдЭ - это не инит, это троянский конь, это закабаневшая, монструозная зверюга, в пол-дистра размером, в самом его Сердце(куда его Никто не звал).
грубо гря - это способ Извратить линукс изнутри, попытавшись продолжить эксплуатировать комьюнити.
т.е. пилить эти маразмы в своем болоте - им показалось мало, им надо трахнуть в мозг Все комьюнити и пить кровь и пот, его мемберов.
> ну, суть автор - точно подметил
> сьюстемдЭ - это не инит, это троянский конь, это закабаневшая, монструозная зверюга,
> в пол-дистра размером, в самом его Сердце(куда его Никто не звал).
> грубо гря - это способ Извратить линукс изнутри, попытавшись продолжить эксплуатировать
> комьюнити.
> т.е. пилить эти маразмы в своем болоте - им показалось мало, им
> надо трахнуть в мозг Все комьюнити и пить кровь и пот,
> его мемберов.А помимо эмоций и красивых слов, есть что сказать?
Rich Felker дело говорит. Я за него!
Когда ждать от redhat systemD 666 "Демон под шляпой"(тм) с Kpatch в зависимостях?