Участник проекта Debian Майкл Штапельберг (Michael Stapelberg (http://people.debian.org/~stapelberg/)) ответил на критику systemd, высказанную другими разработчиками в рамках проведённого (http://www.opennet.ru/opennews/art.shtml?num=37032) в конце мая опроса. В своём блоге Майкл попытался (http://people.debian.org/~stapelberg//2013/06/09/systemd-blo... опровергнуть аргументы, традиционно выдвигаемые против systemd.
systemd имеет много зависимостей.Для опровержения этого аргумента был приведён отдельный документ (http://people.debian.org/~stapelberg/docs/systemd-dependenci... включающий в себя список зависимостей пакета systemd и его исполняемого файла. В частности в нём видно, что большинство библиотек уже есть в среднестатистической системе и потребуется очень мало дополнительных библиотек. Также он приводит список возможных проблем с зависимостями:
-
1. Циклические зависимости.Майкл упоминает о том, что systmed зависит от DBus, тогда как тот сам должен быть загружен системой инициализации, что потенциально может быть источником проблем. Однако systemd
не
зависит от dbus-daemon, а использует интегрированную минимальную реализацию.
-
2. Усложнение кода.Здесь автор приводит ссылку на фрагмент кода systemd (http://cgit.freedesktop.org/systemd/systemd/tree/src/core/ex... с целью показать его читаемость и простоту.
-
3. Зависимость от большого количества библиотек.Автор утверждает, что большинство библиотек уже активно используются такими программами, как DBus, Udev, SELinux, libcap, pcre и т.п., поэтому установка пакета приведёт к установке лишь небольшого числа этих библиотек на обычной системе (всего около 10 пакетов).
-
4. systemd использует больше памяти, чем sysvinit.В качестве опровержения этого утверждения, разработчик пишет, что большинство библиотек уже загружено в память и systemd в худшем случае загрузит около 500 кБ дополнительных библиотек, что является небольшой ценой за предоставленные возможности и актуально разве что в нише встраиваемых систем, где systemd всё равно не слишком необходим (примечание переводчика).
systemd перегружен функциональностью и является bloatware.Майкл отсылает критиков к статье на Wikipedia (http://en.wikipedia.org/wiki/Software_bloat) с определением bloatware как программы, замедляющейся и разрастающейся от релиза к релизу. В качестве контраргумента он утверждает, что systemd работает быстрее, чем sysvinit и занимает памяти всего на 1 мБ больше, а также на то, что функциональноть systemd разбита по небольшим отдельным бинарным файлам.
systemd делает слишком много вещей.
Автор согласен с этим утверждением, однако предлагает воспринимать его как положительную черту - это открывает множество дополнительных способов использования, а также использование на широком спектре устройств. Кроме того упоминается, что не обязательно использовать все возможности systemd, которые разбиты по разным файлам и иногда даже разным пакетам.
systemd слишком усложнён.
Здесь Майкл предлагает сравнить монолитное ядро Linux с systemd и микроядро Minix с sysvinit, а также упоминает, что не унифицированные и дублирующие друг друга скрипты на Shell порой более сложны и медленны, а также вызывают больше проблем, чем стандартный код на языке C.
Вывод.
Из написанного выше, автор делает вывод - критики systemd во многом правы, но иногда следует посмотреть на вещи с положительной стороны и увидеть, что systemd просто старается сконцентрировать в одном месте усложнённость множества различных init-скриптов, оставив сложности внутри себя, а простой, но в то же время гибкий интерфейс - снаружи. В итоге, упрощается работа мэйнтейнеров пакетов по написанию сервисных файлов (аналог скриптов инициализации) и предоставляются целостные и надёжные средства для управления сервисами. System отличается от sysvinit, а альтернативные подходы первое время часто кажутся усложнёнными. То, что systemd потребляет больше ресурсов, чем sysvinit, компенсируется задействованием данных ресурсов для учёта большей информации о сервисах, а более детальизированный контроль состояния позволяет администратору более глубоко контролировать работу служб.
URL: http://people.debian.org/~stapelberg//2013/06/09/systemd-blo...
Новость: http://www.opennet.ru/opennews/art.shtml?num=37130
товарищи! если кому не лень, объясните пожалуйста: зачем так пиарят и продвигают этот сыстемд? неужто на нём свет таким серьёзным клином сошёлся, что без него вообще никак?
(южу гентуху - потребности не вижу)
systemd просто старается сконцентрировать в одном месте усложнённость множества различных init-скриптов, оставив сложности внутри себя, а простой, но в то же время гибкий интерфейс - снаружи. В итоге, упрощается работа мэйнтейнеров пакетов по написанию сервисных файлов (аналог скриптов инициализации) и предоставляются целостные и надёжные средства для управления сервисами.
>сконцентрировать в одном месте усложнённость множества различных init-скриптовВ systemd скрипты? Подробнее, пожалуйста. Что такое усложнённость и зачем её концентрировать?
>В итоге, упрощается работа мэйнтейнеров пакетов по написанию сервисных файловЧем упрощается? Каким образом? И вообще, с чего ты взял, что она упрощается?
>целостные и надёжные средства для управления сервисамиВ чём заключается целостность и надёжность управления? И почему все другие реализации стали ненадёжные?
Я новость процитировал, где на исходный вопрос отвечено.> Чем упрощается? Каким образом? И вообще, с чего ты взял, что она упрощается?
Устройством модулей, вероятно.
ps. Лично мне от systemd ни холодно, ни горячо, и с ним жить можно, и без него. Я только против режима "базарных бабок", когда слухи, фобии и стереотипы проецируют на какую-то тему только для того, чтобы можно было говорить одними и теми же шаблонами, создавая иллюзию общения. Это не общение, это конкурс попугаев. И я в подобных темах обычно не общаюсь, тут зашёл случайно - человек написал вопрос, ответ на который был шестью строчками выше его вопроса - вот я ему и скопировал.
не флудите, товарищ. шестью строчками выше ответы на не те вопросы.
потому что поясняю:> systemd просто старается сконцентрировать в одном месте усложнённость множества различных init-скриптов. ... [etc.]
0. вопрос не про старания системд. вопрос про старания тех, кто пиарит.
1. сложность скриптов инициализации системы связана с тем, что инициализация системы - штука непростая. и всё. перенос этой сложности "в себя" == перенос инициализации из скриптов инициализации - явный нонсенс.
2. с systemd связано множество усложнений. если кто не хочет связываься с ними - должен иметь возможность выбора чего-то попроще, поклассичнее, etc.как вариант результата:
0. systemd в конечном итоге захватывает загрузку систем;
1. rh (или ещё ктонить) прибирает к рукам systemd;
2. ...
3. profit. хошь грузить линух - изволь лицензию на systemd приобрести.
а разрабов у init-скриптов ужо не будет, за невостребованностью.как вариант того, что должно быть:
0. список возможных проблем, юзеры пополняют со временем.
1. группа, стандартизирующая требования к софту подобного рода.
2. стандарты, выпущенные группой.
3. много проектов, наравне с systemd, не подминающие под себя удевы, следующие стандартам.
4. все довольны.
чтобы переписать все скрипты на systemd, требуется примерно в 100 раз меньше усилий, чем на ежедневное нытьё на форумах про то, как всё плохо
> требуется примерно в 100 раз меньше усилий, чем на ежедневное нытьё на форумах про то, как всё плохоЗато сколько удовольствия!
Люди ищут сострадания, а им говорят "вот вам инструмент получше, только не нойте"...
давайте начнем с того что "а надо ли" переписывать. Чуть раньше была новость что сравнив скорость загрузки sysv init и systemd - получили что systemd проигрывает по скорости. Хотя это пиарилось как его главное достоинство. Теперь начинают срочно искать другие достоинства? раз уж со скоростью облажались...
> давайте начнем с того что "а надо ли" переписывать. Чуть раньше была
> новость что сравнив скорость загрузки sysv init и systemd -
> получили что systemd проигрывает по скорости. Хотя это пиарилось как его
> главное достоинство. Теперь начинают срочно искать другие достоинства? раз уж со
> скоростью облажались...Что надо - решают разработчики Debian. И пишут об этом в release notes. Мы почти прозрачно перешли на конкурентную загрузку в 6.0, прозрачно перейдём и на systemd, и на upstart, и на /etc/rc, если так решат маинтайнеры. Потому что Debian.
> давайте начнем с того что "а надо ли" переписывать.А вот это уже для себя каждый сам решает. Я вот вижу что даже разработчикам софта нынче стало зачастую не лениво 5 строчек в service-файл накатать. А как по мне - я опять же для запуска моих кастомных демонов предпочту 5 строк в конфиг кинуть чем выписывать костыли на три страницы на скриптах. Особенно весело когда метровый интерпетер с портянкой на 3 страницы пиинается для старта 20 кб прожки. Что еще веселее, если лыжи не едут, придется самому дописывать логгинг и дебаггинг. Потому что в дефолтных стартовых скриптах он отсутствует чуть более чем полностью. Так что если что-то где-то не получается, в sysvinit с этим отдельный гемор.
И демонизация в каждых дистрибутивах разная, поэтому универсальный init-скрипт не имел смысла.
да что вы говорите $app_name & разная? или ключик у программы вдруг поменяется?тем неменее init скрипты уже шли с init скриптами под каждый дистрибутив. Теперь надо менять это все - с учетом того что товарищи писатели systemd - вопросами портируемости между дистрибутивами не заморачиваются. "Весь мир прогнется под нас"... ведь так?
> да что вы говорите $app_name & разная?А это, внезапно, вообще костыль. И да, таки отличие у программ бывают. Кто-то дергает соотв. сискол, кто-то нет, кто-то делает закат солнца вручную сам. По факту интимных особенностей можно запросто выкусить.
> или ключик у программы вдруг поменяется?
Не, ну зачем же ключик. Например у разных дистров директории разные бывают. И вот тебе вываливается портяна на три страницы, где константы типа директорий равномерным слоем размазаны по всему тексту. Сколько времени убьется на ее фиксинг под другой дистр? Правильно - полчаса колупания в програмерском редакторе, а если лыжи не поехали - потуги отладить это и понять в чем грабли, с самоличным дописыванием логгинга. Потому что штатного механизма логинга результатов операций в башевых портянка вообще совсем нет.
> тем неменее init скрипты уже шли с init скриптами под каждый дистрибутив.
Потому что они разные. И скрипты от одного дистра не только не подойдут для другого. Их еще и переделывать геморно будет. А вот исправить пути в файле конфигурации на 5 строк - дело ерундовое. Тем более что при факапе тот кто парсил конфиг залоггит в чем проблема. По крайней мере - он это может и должен делать. Так что если где-то допустим доступа нет или опечатка, нормальный стартер вполне себе может залоггить это по человечески. У него для этого все карты на руках - он сисколы дергал, коды возврата видел. А вот самолично это дописывать к каждой портянке да еще на шеллскриптах - вот уж спасибо, сами так упражняйтесь.
> Теперь надо менять это все - с учетом того что товарищи
> писатели systemd - вопросами портируемости между дистрибутивами не заморачиваются.Знаете, пять строк конфига с путями - я и сам напишу за пару минут. А вот патчить дистро-специфичную трехстраничную простыню на баше где константы по всему коду - вот уж нафиг!
> "Весь мир прогнется под нас"... ведь так?
Именно так. Лохов и лузеров в этом мире не лю. И вообще, станно что по поводу линукса так ратует фанатик бсд/соляр. А то что там системы инициализации и все остальное ни с чем не совместимое и все фигачат на своей волне - это видимо ничо так, нормальненько.
>> да что вы говорите $app_name & разная?
> А это, внезапно, вообще костыль. И да, таки отличие у программ бывают.
> Кто-то дергает соотв. сискол, кто-то нет, кто-то делает закат солнца вручную
> сам. По факту интимных особенностей можно запросто выкусить.Ой.. А что clone(2) уже отличается в разных дистрибутивах?
или с каких пор '&' костыль? даже в POSIX / SUSv3 это есть - откройте уже для себя man sh...
если уже сильно хочется - посмотрите в posix complatible.
>> или ключик у программы вдруг поменяется?
> Не, ну зачем же ключик. Например у разных дистров директории разные бывают.так вы разберитесь о чем вы говорите - о демонизации или о разных путях в дистрибутивах?
разные пути - правильными разработчиками подменяются при помощи autotest утилит в конце configure.
и никаких проблем..
> И вот тебе вываливается портяна на три страницы, где константы типа
> директорий равномерным слоем размазаны по всему тексту. Сколько времени убьется на
> ее фиксинг под другой дистр?минут 5-10. sh -x / bash -x / set -x в начале файла.
> понять в чем грабли, с самоличным дописыванием логгинга. Потому что штатного
> механизма логинга результатов операций в башевых портянка вообще совсем нет.да что вы говорите ?! а set -x вы не знали ?
>> тем неменее init скрипты уже шли с init скриптами под каждый дистрибутив.
> Потому что они разные. И скрипты от одного дистра не только не
> подойдут для другого.в прошлом сообщении вы говорили что unit файлы будут разные под каждый дистрибутив - так в чем разница?
> По крайней мере - он это может и должен
> делать. Так что если где-то допустим доступа нет или опечатка, нормальный
> стартер вполне себе может залоггить это по человечески. У него для
> этого все карты на руках - он сисколы дергал, коды возврата
> видел. А вот самолично это дописывать к каждой портянке да еще
> на шеллскриптах - вот уж спасибо, сами так упражняйтесь.Признайтесь вы что не читали ничего по shell scripting?
вот у меня вполне работает конструкция сbash-3.2$ find *sh -exec cat {} \; | wc -l
51452и нет никакой проблемы с поддержкой этого test framework на шеле - хотя и есть ограничения у него.
>> Теперь надо менять это все - с учетом того что товарищи
>> писатели systemd - вопросами портируемости между дистрибутивами не заморачиваются.
> Знаете, пять строк конфига с путями - я и сам напишу за
> пару минут. А вот патчить дистро-специфичную трехстраничную простыню на баше где
> константы по всему коду - вот уж нафиг!90% простыни занимают комментарии. Так и скажите что не ослили shell scripting, а дальше вы же не лох?
А теперь пожалуйста расскажите как вы сделаете дополнительные опции по управлению сервисом?
Вот вызов httpd --configtest я сделаю за 10 минут в init файле. и будет доступно через команду service httpd configtestсколько вам потребуется что бы сделать тоже самое при помощи systemd ?
>> "Весь мир прогнется под нас"... ведь так?
> Именно так. Лохов и лузеров в этом мире не лю.А сам не лох и лузер? видимо просто школяр. А ратую за простую вещь - соблюдение Single Unix specification v3/v4. Хотя видимо вам уважаемый эти слова не скажут ничего.
> А сам не лох и лузер? видимо просто школяр. А ратую за
> простую вещь - соблюдение Single Unix specification v3/v4.Вы сами не знаете, кто вы? Вот уж воистину, левая голова не ведает, что творит правая.
>> А сам не лох и лузер? видимо просто школяр. А ратую за
>> простую вещь - соблюдение Single Unix specification v3/v4.
> Вы сами не знаете, кто вы? Вот уж воистину, левая голова не
> ведает, что творит правая.ответьте чем требование использовать sh - уходит за пределы SUS ?
>>> тем неменее init скрипты уже шли с init скриптами под каждый дистрибутив.
>> Потому что они разные. И скрипты от одного дистра не только не
>> подойдут для другого.
> в прошлом сообщении вы говорили что unit файлы будут разные под каждый
> дистрибутив - так в чем разница?Переделать unit-файл под другой дистр - максимум минута.
>>> Теперь надо менять это все - с учетом того что товарищи
>>> писатели systemd - вопросами портируемости между дистрибутивами не заморачиваются.
>> Знаете, пять строк конфига с путями - я и сам напишу за
>> пару минут. А вот патчить дистро-специфичную трехстраничную простыню на баше где
>> константы по всему коду - вот уж нафиг!
> 90% простыни занимают комментарии. Так и скажите что не ослили shell
> scripting, а дальше вы же не лох?#cat /etc/init.d/nfs |wc -l
239#cat /etc/init.d/nfs | grep -vE "(^$|^#)" |wc -l
18190% говорите? Ну, ну.
> А теперь пожалуйста расскажите как вы сделаете дополнительные опции по управлению сервисом?
> Вот вызов httpd --configtest я сделаю за 10 минут в init файле.
> и будет доступно через команду service httpd configtest
> сколько вам потребуется что бы сделать тоже самое при помощи systemd ?ExecStartPre=apachectl configtest ? И не 10 минут, и будет работать автоматом при каждом старте сервиса, а не ручками каждый раз запускать.
>>>> тем неменее init скрипты уже шли с init скриптами под каждый дистрибутив.
>>> Потому что они разные. И скрипты от одного дистра не только не
>>> подойдут для другого.
>> в прошлом сообщении вы говорили что unit файлы будут разные под каждый
>> дистрибутив - так в чем разница?
> Переделать unit-файл под другой дистр - максимум минута.а мне init файл переделать уходит 5 минут, что характерно в разы больше уходит что бы переделать весь src.rpm между дистрибутивами.
>> А теперь пожалуйста расскажите как вы сделаете дополнительные опции по управлению сервисом?
>> Вот вызов httpd --configtest я сделаю за 10 минут в init файле.
>> и будет доступно через команду service httpd configtest
>> сколько вам потребуется что бы сделать тоже самое при помощи systemd ?
> ExecStartPre=apachectl configtest ? И не 10 минут, и будет работать автоматом при
> каждом старте сервиса, а не ручками каждый раз запускать.а зачем мне это в prestart? когда я хочу отдельной командой проверять конфиг на коректность.. ?
да да - расскажите как в systemd дописать другие команды к управлению сервисом - к примеру у apache по service httpd status - мог вызываться lynx который вытаскивал $host/status-page и выдавал на консоль.расскажите как сделать ровно тоже на базе systemd?
>[оверквотинг удален]
> а мне init файл переделать уходит 5 минут, что характерно в разы
> больше уходит что бы переделать весь src.rpm между дистрибутивами.
>>> А теперь пожалуйста расскажите как вы сделаете дополнительные опции по управлению сервисом?
>>> Вот вызов httpd --configtest я сделаю за 10 минут в init файле.
>>> и будет доступно через команду service httpd configtest
>>> сколько вам потребуется что бы сделать тоже самое при помощи systemd ?
>> ExecStartPre=apachectl configtest ? И не 10 минут, и будет работать автоматом при
>> каждом старте сервиса, а не ручками каждый раз запускать.
> а зачем мне это в prestart? когда я хочу отдельной командой проверять
> конфиг на коректность.. ?А зачем вам проверять конфиг на корректность? Наверное, чтобы демон успешно запустился? А если уж так хочется, то никто не мешает запустить apachectl configtest (даже более дистрибутивонезависимо получается). Зачем для этого отдельный параметр в init-e? Каждые 5 минут правите конфиг?
> да да - расскажите как в systemd дописать другие команды к управлению
> сервисом - к примеру у apache по service httpd status -
> мог вызываться lynx который вытаскивал $host/status-page и выдавал на консоль.
> расскажите как сделать ровно тоже на базе systemd?Можно из буханки хлеба сделать троллейбус, но зачем?
> А зачем вам проверять конфиг на корректность? Наверное, чтобы демон успешно запустился? А если уж так хочется, то никто не мешает запустить apachectl configtest (даже более дистрибутивонезависимо получается). Зачем для этого отдельный параметр в init-e? Каждые 5 минут правите конфиг?А если я не хочу помнить apachectl? есть общее управление сервисом - service $srv-name без параметров выходит список команд. Зачем помнить что-то о apachectl?
И как раз таки по тому что я правлю не часто - помнить все команды мне не хочется.
Хотя ответ напоминает - традиционный ответ windows юзеров - "потребности в колбасе нету".
> Можно из буханки хлеба сделать троллейбус, но зачем?А можно из удобного инструмента - сделать помойку - которая требует кучу зависимостей, не выполняет половины старых функций - и объявить это прорывом.
А учитывая количество багов в багтрекере systemd - очень реально нарваться на ситуацию когда он вообще сломается. Но адептов это не смущает..
> Именно так. Лохов и лузеров в этом мире не лю. И вообще,
> станно что по поводу линукса так ратует фанатик бсд/соляр. А то
> что там системы инициализации и все остальное ни с чем не
> совместимое и все фигачат на своей волне - это видимо ничо
> так, нормальненько.Они там вполне вменяемые, никаких велосипедов. И, самое главное - появились значительно раньше. Что характерно. После чего пингвиноиды кинулись к своим велосипедам в спринтерском темпе.
> И демонизация в каждых дистрибутивах разная,Для начала там пути разные. А вот заменять пути, зачастую еще и вычисляемые из переменных, в простыне на 3 страницы и без логгинга того что обломалось - на редкость не прикольное начинание. Поправить конфиг на 5 строк при том что тот кто его парсил в лог ругнется если что-то где-то не работает - на порядок менее трудозатратно.
set -x в начале файла уже отменили ?и получим весь лог выполнения в syslog.
ну и товарищи определитесь - вы о демонизации или о разных путях?
и если вы еще подумаете - то если кому-то делать ничего не хочется - есть каталог /opt в который можно ставить пакеты, есть еще и /usr/local - который есть везде. Так что зависит от того как пакетировать.
> set -x в начале файла уже отменили ?
> и получим весь лог выполнения в syslog.
> ну и товарищи определитесь - вы о демонизации или о разных путях?
> и если вы еще подумаете - то если кому-то делать ничего не
> хочется - есть каталог /opt в который можно ставить пакеты, есть
> еще и /usr/local - который есть везде. Так что зависит от
> того как пакетировать.Да с кем ты разговариваешь, эти утырки скрипты читать-то не умеют. Не то, что писать их грамотно. Но каждый - что характерно! - мнит себя системным программистом.
> чтобы переписать все скрипты на systemd, требуется примерно в 100 раз меньше
> усилий, чем на ежедневное нытьё на форумах про то, как всё
> плохоВидимо нытье связано с тем, что поехрили ту систему инициализации, которая на 100% устраивала ноющих, таких как я например :)
Был арч, а в нем был rc.conf, в нем была секция DAEMONS=(....)
В ней можно было прописать:
1. порядок загрузки демонов - кто вперед, а кто после
2. Способ загрузки:
2.1 последовательный - это когда демон ждет когда загрузится демон идуший в списке перед ним.
2.2 параллельный, это когда демон отправляется в бекграунд, и следующий за ним по списку не дожидается загрузки "параллельного" демона.
2.3 Запрет загрузки, указав в начале имени демона знак "!" - можно было запретить его загрузку, это позволяло не вычеркивать имя демона из списка, чтобы не забыть.3. Загрузка своих демонов - достаточно было поместить файл в /etc/rc.d/ назвав его myscript, а в самом файле написать просто /opt/myprog - и этот демон без базара запустился бы.
Как мне переписать скрипты на системД, при условии что мне параллелизация не только не нужна, но и является главным врагом и рушит мне всю схему загрузки, которую я организовал на sysvinit ?
Еще поди для systemD просто файла с содержимым вида /opt/myprog не хватит ? там поди нужно синтаксис соблюдать особый ?То что было, то есть sysvinit - это и был KISS, а я перешел на Arch именно из-за такой вот простоты и гибкости, а вовсе не из-за AUR.
дружище, ты вопросами свой ник не оправдываешь или просто не знаешь слова "документация"?
В арче был BSD инит, вот это был KISS. Дистр плюющий на свою идеологию, небудет стоять в моей системе
> В арче был BSD инит, вот это был KISS. Дистр плюющий на
> свою идеологию, небудет стоять в моей системеДистр не может плевать - у него нет рта.
Все из-за кучки ментейнеров, которые стали его перепиливать, насколько я знаю из Арча ушли все отцы основатели, и остались только школьники, которые так запутались, что решили все исполняемые файлы в /usr/bin свалить.
Причем не осилили сделать прозрачную процедуру переноса, а заставили делать бедных пользователей ручные манипуляции :)
Не осилили сделать даже вменяемую инструкцию, в которой бы уточнялось, что на каталоги /bin /sbin /usr/sbin будут сделаны симлинки автоматически(!!), после обновления filesystem.
Зато напихали инструкцию туманными формулировками типа "если файлы пакета находятся не /usr/bin - исправьте пакет".
А как исправить - это и так всем понятно, типа.
По поводу systemd - если бы эта система была действительно такой, какой ее преподносят, была бы лишена тех мелких глюков, типа когда не поднимается сеть после загрузки, когда первая выборка из journalctl длится секунды, даже для последних 10 строк, когда для некоторых сервисов нужно писать свои unit-файлы - короче Потной Попке Потти не пришлось бы развенчивать мифы про systemd, все просто бы пользовались и были бы счастливы.PS: Гори в аду Поттеринг, вместе со своими бредовыми идеями, гействующий маргинал, урод, подонок и сволочь.
Какой фееричный бред everywhere. Прям с удовольствием прочитал.
>Я новость процитировал, где на исходный вопрос отвечено.А ты сам ответить не в состоянии? Своими словами, аргументированно, доходчиво. Тем более вопрос простой.
>Устройством модулей, вероятно.
Каких модулей? Каким конкретно устройством?
>Я только против режима "базарных бабок"Я тоже против. Если нахваливаешь товар, то давай сюда конкретику. А то это какой-то пустой трёп даже ниже уровня маркетологов.
> А ты сам ответить не в состоянии? Своими словами, аргументированно, доходчиво. Тем более вопрос простой.Меня не интересуют чужие фобии.
Если разработчики Debian решат, что им удобнее поддерживать систему через systemd, возьмут systemd. Если это окажется не так - не возьмут. Они так делают уже двадцать лет, и не вижу, что им может помешать.
И мне всё равно, что они выберут, для меня это не принципиальный вопрос. Это им поддерживать всю операционную систему.
>> А ты сам ответить не в состоянии? Своими словами, аргументированно, доходчиво. Тем более вопрос простой.
> Меня не интересуют чужие фобии.
> Если разработчики Debian решат, что им удобнее поддерживать систему через systemd, возьмут
> systemd. Если это окажется не так - не возьмут. Они так
> делают уже двадцать лет, и не вижу, что им может помешать.
> И мне всё равно, что они выберут, для меня это не принципиальный
> вопрос. Это им поддерживать всю операционную систему.Ошибаетесь, им нужно только собрать систему, поддерживать будете Вы!
> зачем так пиарят и продвигают этот сыстемд?Выросло новое поколение, хотят доказать, что они тоже чего-то умеют.
Самый оптимальный вариант повышения ЧСВ - сломать что-то значимое.---
Пример из SuSE
if test -d /media && ! mountpoint -q /media; then
mount -t tmpfs tmpfs /media
fiУтиль mountpoint -q проверяет примонтирован ли кто-нибудь в указанный каталог иль нет,
по результату монтирует туда tmpfs иль нет. Причем всем пох...ю, что во fstab уже прописано
/media/flash
/media/disk
/media/vmsysvinit - делаю vi /etc/init.d/boot.localfs, ставлю три коммента, umount /media; mount -a; работаем дальше.
systemd - редактирую юнит, правлю штук 10 параметров, иль даже создаю новый юнит,umount /media; пускаю юниты, работаем!Для рабочей системы нужно минимум: ядро/libc/sh/init
Для рабочей системы c systemd нужно минимум: ядро/libc/dbus/libcap/pcre/shГде БЛЯ профит?!
> Где БЛЯ профит?!Профит, Павел, в том, что "минимально рабочая система" на куй никому не нужна.
Безусловно, для того, чтобы запустить single user mode, в Линуксе даже init не нужен: init=/bin/sh в параметр ядра в загрузчике добавляем, и понеслась.
Ну и что? Чисто поржать, что ли? Зачем такая система-то?
А если речь идёт о реальном сервере, а не о сферическом в вакууме, тогда ядра+libc+init+sh совершенно точно мало: /usr/bin/хрень-какая-нибудь либо должна уметь мониторить себя сама (что плохо, так как приводит к дублированию одной и той же функциональности в различных программах), либо на сервере надо разворачивать систему мониторинга и автоподнятия упавших сервисов, так как last bug in our programs won't be corrected until last user is dead (C), и софт почему-то всё равно ходит в core dump, как его не вылизывай. А запущенный процесс в фоне -- это ещё не сервис, если он не мониторится, это просто запущенный процесс в фоне. :)
systemd позволяет решить проблему мониторинга сервисов и управления ресурсами унифицированным путём. Нравится ли то, как он это делает, не нравится ли -- всё равно софт с такой функциональностью в системе нужен, как ни крути. А вместо ли init'а он будет, или рядом с init'ом, как в Солярисе -- это вкусовщина всё.
> Ну и что? Чисто поржать, что ли? Зачем такая система-то?Загляни в любой домашний маршрутизатор.
Заглянул, systemd нет, дальше что?
Там вообще не десктопный дистр линукса, если ты не в курсе
> Заглянул, systemd нет, дальше что?
> Там вообще не десктопный дистр линукса, если ты не в курсеТы бы как-нибудь на досуге почитал на что отвечаешь.
> Там вообще не десктопный дистр линукса, если ты не в курсеЭто не отменяет того момента что там Linux. Мир не заканчивается на вас, вашем долбаном чсв и пыльном десктопе/нотике.
> Загляни в любой домашний маршрутизатор."No silver bullet". (C)
Ембеддовка так устроена, что для неё перезагрузка -- "лёгкая" операция. Если что-нибудь отваливается, просто выходим из BusyBox'а, и ядро перезагружается по "исчезновению init".
Но что-то мне не хочется, чтобы мои сервера так себя вели, для них перезагрузка -- довольно "тяжёлая" операция. ;)
>> Загляни в любой домашний маршрутизатор.
> "No silver bullet". (C)
> Ембеддовка так устроена, что для неё перезагрузка -- "лёгкая" операция. Если что-нибудь
> отваливается, просто выходим из BusyBox'а, и ядро перезагружается по "исчезновению init".
> Но что-то мне не хочется, чтобы мои сервера так себя вели, для
> них перезагрузка -- довольно "тяжёлая" операция. ;)Ты задал вопрос, получил короткий, но ёмкий ответ.
> Ты задал вопрос, получил короткий, но ёмкий ответ.1. Я не задавал никаких вопросов, я отвечал Павлу на его вопрос, где профит.
2. Я вёл речь о серверах, а не о embedded-платформах, советую читать внимательно посты перед тем, как на них отвечать.
3. SysV init в embedded-системах отсутствует. И systemd отсутствует. Там BusyBox. Это вообще вне обсуждаемой тематики, так как в Debian'е заменили SysV init на systemd.
>> Ты задал вопрос, получил короткий, но ёмкий ответ.
> 1. Я не задавал никаких вопросов, я отвечал Павлу на его вопрос,
> где профит.профит в замедлении скорости загрузки? в потери управляемости?
> 2. Я вёл речь о серверах, а не о embedded-платформах, советую читать
> внимательно посты перед тем, как на них отвечать.а роутер уже не сервер ?
> 3. SysV init в embedded-системах отсутствует. И systemd отсутствует. Там BusyBox. Это
> вообще вне обсуждаемой тематики, так как в Debian'е заменили SysV init
> на systemd.Вы давно смотрели на OpenWRT? внутри обычный SysV init... из состава busybox :)
> Вы давно смотрели на OpenWRT? внутри обычный SysV init... из состава busybox :)И именно поэтому он взлетает почти минуту на роутерах :(
>> Вы давно смотрели на OpenWRT? внутри обычный SysV init... из состава busybox :)
> И именно поэтому он взлетает почти минуту на роутерах :(почти минуту? вы где-то в паралельной вселенной. TPLINK взлетает секунд за 15, RTN-16 где-то секунд 25, учитывая сколько там сервисов навешано, и то что для запуска используется блоб от wl драйвера с кучей обвязки.
Опять же перезагрука даже роутера - это всьма редкая операция - раз в месяц, и даже реже. выискивать тут лишние 15 секунд - это даже не смешно (посчитайте сколько это процентов времени выигрыш).а если посмотреть на рядом стоящий Opteron - то инициализация всего железа на борту занимает 2-3 минуты. При этом остальная загрузка идет около 40 секунд. сократите вы это до 20 секунд (если сможете) - а куда девать 2-3 минуты которые нужны биосу для инициализации устройств SATA, SCSI, сетевые набортные и тп.. ?
> почти минуту? вы где-то в паралельной вселенной.Слушай, ты, ИМХО, дядька грамотный. Напиши, пож-ста, на Опеннете и/или на ЛОРе аргументированную статью вида: "почему системд - школьное поделие, нарушающее Sys V и т.п.".
Очень буду признателен!
"потому что пищит и портит текст" (ц)и память жрёт
потому что потеря управляемости. Потому что в багтрекере systemd больше 700 багов, часть из которых помечена как critical. - потому что предлагается управлять через доп утилиты - то что делалось простым редактором. Мало? потому что udev теперь часть systemd и без него не собирается - нарушая модульность.потому что "наелся" другого софта этого автора - и не уверен что он в состоянии сделать вменяемый софт.
> потому что потеря управляемости. Потому что в багтрекере systemd больше 700 багов,
> часть из которых помечена как critical. - потому что предлагается управлять
> через доп утилиты - то что делалось простым редактором. Мало? потому
> что udev теперь часть systemd и без него не собирается -
> нарушая модульность.
> потому что "наелся" другого софта этого автора - и не уверен что
> он в состоянии сделать вменяемый софт.Что-то со счетчиком у вас, видимо. Текущая раскладка по открытым багам:
systemd - 120
Upstart - 119
OpenRC - 100Даже если их вместе сложить - 700 никак не набирается.
да ну?
Status: NEW, VERIFIED, ASSIGNED, MODIFIED, ON_DEV, ON_QA, RELEASE_PENDING, POST Product: systemd Component: systemd Alias: systemd Summary: systemd Whiteboard: systemd Content: "systemd"
...This result was limited to 1000 bugs. See all search results for this query.
...
> профит в замедлении скорости загрузки?Вообще-то мне так думается что обкушенный systemd может прокатить и для роутеров, кстати.
> в потери управляемости?
Вы уже давно управляемость потеряли: 2 слова по прввилам языка связать не можете. А если уж мы о управляемости, так многостраничные дистроспецифичные простынки где константы размазаны по коду - вот это грабли с точки зрения управляемости, да.
>> профит в замедлении скорости загрузки?
> Вообще-то мне так думается что обкушенный systemd может прокатить и для роутеров,
> кстати.да да - и вынуждать производителей ставить больше памяти в роутеры.
Хрестоматийный пример - linksys WRT-54G
L - линукс модфикация - требовала для себя в 2 раза больше памяти в ram/flash чем без буковки L и с wxworks..Такой вот он linux.
>> в потери управляемости?
> Вы уже давно управляемость потеряли: 2 слова по прввилам языка связать не
> можете. А если уж мы о управляемости, так многостраничные дистроспецифичные простынки
> где константы размазаны по коду - вот это грабли с точки
> зрения управляемости, да.да да у вас русский идеален :-) Поздравляю - а по теме кроме того что вы не осилили shell scripting что сказать то можете.
> да да - и вынуждать производителей ставить больше памяти в роутеры.
> Хрестоматийный пример - linksys WRT-54G
> L - линукс модфикация - требовала для себя в 2 раза больше
> памяти в ram/flash чем без буковки L и с wxworks..
> Такой вот он linux.А в абсолютных цифрах это сколько?
А в возможностях?
>> да да - и вынуждать производителей ставить больше памяти в роутеры.
>> Хрестоматийный пример - linksys WRT-54G
>> L - линукс модфикация - требовала для себя в 2 раза больше
>> памяти в ram/flash чем без буковки L и с wxworks..
>> Такой вот он linux.
> А в абсолютных цифрах это сколько?было 32Мb RAM, 16Mb flash, стало 16Ram - 2mb flash. Почувствуйте разницу.
после чего умножте на тираж устройств и посчитайте выигрыш..> А в возможностях?
выигрыша нету. Только периодические глюки и выливающиеся в необходимость ребутить каждую ночь.
Есть некому не нужный openvpn и тп.. то что пользователю нафик не сдалось (рядовому).
> было 32Мb RAM, 16Mb flash, стало 16Ram - 2mb flash. Почувствуйте разницу.у меня был роутер с linux, вайфаями и поднятием соединений с 8 mb ram и 2 mb flash.
Ах, то есть фичи были, но они "были не нужны" мифическому "рядовому пользователю". Кто этот ваш "рядовой пользователь"? Фермер вконтакта? Людям могут требоваться довольно-таки разные вещи. И чем меньше у них запросов тем более тупой роутер им подойдёт. И линукс там, возможно, будет лишним. Кому-то хватит просто кабель в компьютер воткнуть или минимальную АР поднять, даже без шифрования (потому что пароль - это слишком сложно для этих ваших пользователей).
Так покупайте и дальше с wxworks, в чём проблем а-то? А, не делают... говорят, что всем остальным лучше новый, да и на лицензиях на linux производители сэкономили больше, чем на всех этих твоих мегабайтах RAM. Ну что-же теперь остаётся, выкупай старые запасы у дилеров, а ещё можно сорганизоваться с такими-же бедолагами, как ты, и оплатить разработку нового роутера. С wxworks и без vpn'а.
Делают.. делают и продают.
Вот и покупаю - попутно не давая переплачивать знакомым. Которым ушлые продавьцы рассказывают как это круто когда linux на борту - при этом ничего не добавляя к функционалу который есть у более дешевой модели.Вы лучше ответьте почему Cisco в своих каталистах и роутерах использует линукс только как морду управления? Если он такой супер надежный :)
> Делают.. делают и продают.
> Вот и покупаю - попутно не давая переплачивать знакомым. Которым ушлые продавьцы
> рассказывают как это круто когда linux на борту - при этом
> ничего не добавляя к функционалу который есть у более дешевой модели.
> Вы лучше ответьте почему Cisco в своих каталистах и роутерах использует линукс
> только как морду управления? Если он такой супер надежный :)Немного перефразирую и возможно Вы сами ответите на свой вопрос:
"Почему тостеры не используется для бурения скважин, если тостеры такие надёжные?
> в Debian'е заменили SysV init на systemdпруфы?
>так как в Debian'е заменили SysV init на systemd.Вы в этом уверены?
> Ембеддовка так устроена, что для неё перезагрузка -- "лёгкая" операция.То-то многие девайсы с линем грузятся секунд по 30, пока скриптопортянки бизибоксовским init'ом жуют. Без параллелищации и прочая даже. Нет, есть и те кто систему за секунду грузит. Но они как вы понимаете этим скриптошитом не пользуются.
> То-то многие девайсы с линем грузятся секунд по 30, пока скриптопортянки бизибоксовскимТам процессор 500Mhz - что вы от роутера хотите то ?
> Ембеддовка так устроена,Бсдшники нас будут учить о том как устроена эмбедовка. Феерично.
Вы про NetBSD слыхали?
> systemd позволяет решить проблему мониторинга сервисов и управления ресурсами унифицированным путём.1. а можно пример из жизни ?
2. А вы уверены что системД работает без сбоев, то есть работает всегда так, как вы ожидаете ?Вот мой пример из жизни:
Команда
journalctl -u postfix -n50
обрезает вывод по ширине до определенного кол-ва символов, и чтобы прочитать всю строчку нужно перенаправить вывод на | less.
еще эта сволочь консоль не отпускает, пока Ctrl+C не нажать.
>[оверквотинг удален]
>> systemd позволяет решить проблему мониторинга сервисов и управления ресурсами унифицированным путём.
> 1. а можно пример из жизни ?
> 2. А вы уверены что системД работает без сбоев, то есть работает
> всегда так, как вы ожидаете ?
> Вот мой пример из жизни:
> Команда
> journalctl -u postfix -n50
> обрезает вывод по ширине до определенного кол-ва символов, и чтобы прочитать всю
> строчку нужно перенаправить вывод на | less.
> еще эта сволочь консоль не отпускает, пока Ctrl+C не нажать.journalctl -a -u postfix -n50 и всех делов-то )
> journalctl -a -u postfix -n50 и всех делов-то )[root@postadm ~]# journalctl -a -u postfix -n8
-- Logs begin at Вт 2013-01-15 15:48:00 YEKT, end at Пн 2013-06-10 16:39:35 YEKT. --
июн 10 05:10:31 postadm postfix/anvil[24898]: statistics: max cache size 1 at Jun 10 05:07:10
июн 10 09:00:07 postadm postfix/smtpd[25016]: connect from 114-32-207-47.HINET-IP.hinet.net[114.32.207.47]
июн 10 09:00:09 postadm postfix/smtpd[25016]: NOQUEUE: reject: RCPT from 114-32-207-47.HINET-IP.hinet.net[114.32.207.47]: 554 5.7.1 <114-32-207-47.HINET-IP.hinet.net[114.32.207.47]
июн 10 09:00:09 postadm postfix/smtpd[25016]: lost connection after RCPT from 114-32-207-47.HINET-IP.hinet.net[114.32.207.47]
июн 10 09:00:09 postadm postfix/smtpd[25016]: disconnect from 114-32-207-47.HINET-IP.hinet.net[114.32.207.47]
июн 10 09:03:29 postadm postfix/anvil[25018]: statistics: max connection rate 1/60s for (smtp:114.32.207.47) at Jun 10 09:00:07
июн 10 09:03:29 postadm postfix/anvil[25018]: statistics: max connection count 1 for (smtp:114.32.207.47) at Jun 10 09:00:07
июн 10 09:03:29 postadm postfix/anvil[25018]: statistics: max cache size 1 at Jun 10 09:00:07Строчка с NOQUEUE не входит полностью, полность. она выглядит как
июн 10 09:00:09 postadm postfix/smtpd[25016]: NOQUEUE: reject: RCPT from 114-32-207-47.HINET-IP.hinet.net[114.32.207.47]: 554 5.7.1 <114-32-207-47.HINET-IP.hinet.net[114.32.207.47]>: Client host rejected: Invalid hostname (looks like is an ip-adress) (dsl); from=<0546@msa.hinet.net> to=<superedm002@yahoo.com.hk> proto=SMTP helo=<83.234.146.250>
>[оверквотинг удален]
> (smtp:114.32.207.47) at Jun 10 09:00:07
> июн 10 09:03:29 postadm postfix/anvil[25018]: statistics: max connection count 1 for (smtp:114.32.207.47)
> at Jun 10 09:00:07
> июн 10 09:03:29 postadm postfix/anvil[25018]: statistics: max cache size 1 at Jun
> 10 09:00:07
> Строчка с NOQUEUE не входит полностью, полность. она выглядит как
> июн 10 09:00:09 postadm postfix/smtpd[25016]: NOQUEUE: reject: RCPT from 114-32-207-47.HINET-IP.hinet.net[114.32.207.47]:
> 554 5.7.1 <114-32-207-47.HINET-IP.hinet.net[114.32.207.47]>: Client host rejected:
> Invalid hostname (looks like is an ip-adress) (dsl); from=<0546@msa.hinet.net> to=<superedm002@yahoo.com.hk>
> proto=SMTP helo=<83.234.146.250>Хм, возможно баг. Но вы ведь не открывали тикет, я прав?
даже чтоб лог полностью посмотреть - нужно в багзиллу багрепорт отправлять?)))
> даже чтоб лог полностью посмотреть - нужно в багзиллу багрепорт отправлять?)))Нет, репорт надо отправлять, если чувствуешь себя полноценным участником движения Open Source. Не существует софта без багов.
> Нет, репорт надо отправлять, если чувствуешь себя полноценным участником движения Open
> Source.это туда где поццеринг и ко на всех забивает и шлёт вместе с патчами?)) Чувствуйте сами себя полноценными, а мне для этого не надо в багзиллу к поттерингу в гости заходить.
> Не существует софта без багов.
Чтобы воздухом дышать нужно воздухом дышать.
>> Нет, репорт надо отправлять, если чувствуешь себя полноценным участником движения Open
>> Source.
> это туда где поццеринг и ко на всех забивает и шлёт вместе
> с патчами?)) Чувствуйте сами себя полноценными, а мне для этого не
> надо в багзиллу к поттерингу в гости заходить.
>> Не существует софта без багов.
> Чтобы воздухом дышать нужно воздухом дышать.Ну тады и не жалуйтесь ) А так - не один Леннарт прославился тем, что может посылать народ с патчами.
>>> Нет, репорт надо отправлять, ...
>> это туда где поццеринг и ко на всех забивает и шлёт ... ?
> Ну тады и не жалуйтесь )классный диалог :-D Поклонники системдэ рвут шаблоны сюрреалистической логикой)
> А так - не один Леннарт прославился тем, что может посылать народ с патчами.
Да, лёнчик прославился куда более подлыми делами.
> даже чтоб лог полностью посмотреть - нужно в багзиллу багрепорт отправлять?)))Прогресс, сэр.
> systemd позволяет решить проблему мониторинга сервисов и управления ресурсами унифицированным путём.ну почему эта поделка решает только уже решенные до неё проблемы? есть же monit?
> Где БЛЯ профит?!#cat /lib/systemd/system/nginx.service
[Unit]
Description=The nginx HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target......................................
#cat /etc/init.d/nginx
#!/bin/sh
#
# nginx - this script starts and stops the nginx daemon
#
# chkconfig: - 85 15
# description: Nginx is an HTTP(S) server, HTTP(S) reverse \
# proxy and IMAP/POP3 proxy server
# processname: nginx
# config: /etc/nginx/nginx.conf
# config: /etc/sysconfig/nginx
# pidfile: /var/run/nginx.pid# Source function library.
. /etc/rc.d/init.d/functions# Source networking configuration.
. /etc/sysconfig/network# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0nginx="/usr/sbin/nginx"
prog=$(basename $nginx)sysconfig="/etc/sysconfig/$prog"
lockfile="/var/lock/subsys/nginx"
pidfile="/var/run/${prog}.pid"NGINX_CONF_FILE="/etc/nginx/nginx.conf"
[ -f $sysconfig ] && . $sysconfig
start() {
[ -x $nginx ] || exit 5
[ -f $NGINX_CONF_FILE ] || exit 6
echo -n $"Starting $prog: "
daemon $nginx -c $NGINX_CONF_FILE
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}stop() {
echo -n $"Stopping $prog: "
killproc -p $pidfile $prog
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}restart() {
configtest_q || return 6
stop
start
}reload() {
configtest_q || return 6
echo -n $"Reloading $prog: "
killproc -p $pidfile $prog -HUP
echo
}configtest() {
$nginx -t -c $NGINX_CONF_FILE
}configtest_q() {
$nginx -t -q -c $NGINX_CONF_FILE
}rh_status() {
status $prog
}rh_status_q() {
rh_status >/dev/null 2>&1
}# Upgrade the binary with no downtime.
upgrade() {
local oldbin_pidfile="${pidfile}.oldbin"configtest_q || return 6
echo -n $"Upgrading $prog: "
killproc -p $pidfile $prog -USR2
retval=$?
sleep 1
if [[ -f ${oldbin_pidfile} && -f ${pidfile} ]]; then
killproc -p $oldbin_pidfile $prog -QUIT
success $"$prog online upgrade"
echo
return 0
else
failure $"$prog online upgrade"
echo
return 1
fi
}# Tell nginx to reopen logs
reopen_logs() {
configtest_q || return 6
echo -n $"Reopening $prog logs: "
killproc -p $pidfile $prog -USR1
retval=$?
echo
return $retval
}case "$1" in
start)
rh_status_q && exit 0
$1
;;
stop)
rh_status_q || exit 0
$1
;;
restart|configtest|reopen_logs)
$1
;;
force-reload|upgrade)
rh_status_q || exit 7
upgrade
;;
reload)
rh_status_q || exit 7
$1
;;
status|status_q)
rh_$1
;;
condrestart|try-restart)
rh_status_q || exit 7
restart
;;
*)
echo $"Usage: $0 {start|stop|reload|configtest|status|force-reload|upgrade|restart|reopen_logs}"
exit 2
esac
ну зачем же так, а??? ну щас все плюсанувшие павлушу вешаться же пойдут...не переживут они...
Вспомнилось, как в fedora 16 /usr/libexec/iptables мог и restart, и save, а в iptables.service было прописано только start и stop.Дописывал, чтоб делать
systemctl save iptables.service.
> Вспомнилось, как в fedora 16 /usr/libexec/iptables мог и restart, и save, а
> в iptables.service было прописано только start и stop.Дописывал, чтоб делать
> systemctl save iptables.service.Может я немного олдскул, но по моему это всегда делалось так:
#iptables-save > $IPTABLES_CONFIG
(к тому же это достаточно дистрибутивонезависимый вариант)Или вы редактируете конфиг также часто, как и управляете демоном?
iptables-save-показ таблиц,а service iptables save-сохранение правил, заданных с iptables
в файл после чего делается service iptables restart, в терминологии init, для принятия
изменнений.В iptables.service было прописано только stop и start, и приходилось делать
/usr/libexec/iptables save, что было не красиво.Полез в iptables.service.
> iptables-save-показ таблиц,а service iptables save-сохранение правил, заданных с iptables
> в файл после чего делается service iptables restart, в терминологии init, для
> принятия
> изменнений.В iptables.service было прописано только stop и start, и приходилось делать
> /usr/libexec/iptables save, что было не красиво.Полез в iptables.service.#iptables-save > $IPTABLES_CONFIG
#systemctl reload iptablesP.S.: И зачем дергать iptables, если iptables-save вытаскивает текущие правила?
> Дописывал, чтоб делать systemctl save iptables.service.Ну так в .service это дописать попроще будет чем в портянку на баше, которая на три страницы у многих сервисов, да еще отборного г@внокода, где конфигурационные константы перемешаны с логикой.
>> Дописывал, чтоб делать systemctl save iptables.service.
> Ну так в .service это дописать попроще будет чем в портянку на
> баше, которая на три страницы у многих сервисов, да еще отборного
> г@внокода, где конфигурационные константы перемешаны с логикой.А это уж как вы, программистами себя мнящие, пишете. Т а щ е м т а, скрипты вполне можно структурненько написать. И это можно было задолго до исторического материализма, знаешь ли. То, что вы их за 30 лет ни@силили и вынуждены лепить горбатого^Wвсякие системы мудреной инициализации, сп.жженые с Соляровской SMF - это уже ваши проблемы, а не тех, кто писал. А вам даже ПРОЧИТАТЬ скрипт проблема. Что уж говорить о его написании...
ты забыл выложить для systemd юнита код на си, который будет это все парсить и запускать
> ты забыл выложить для systemd юнита код на си, который будет это
> все парсить и запускатьЭтот код на C будет написан один раз и поддерживаться командой, которая занимается своим делом, а не плодиться в виде bash-простынок для каждого дистрибутива майнтайнерами пакетов.
>Этот код на C будет написан один раз и поддерживаться командой, которая занимается своим делом, а не плодиться в виде bash-простынок для каждого дистрибутива майнтайнерами пакетов.ну так и shell-код будет написан один раз, причем любой админ может написать, для любых своих сервисов.
>>Этот код на C будет написан один раз и поддерживаться командой, которая занимается своим делом, а не плодиться в виде bash-простынок для каждого дистрибутива майнтайнерами пакетов.
> ну так и shell-код будет написан один раз, причем любой админ может
> написать, для любых своих сервисов.Любой админ может также (на|пере)писать и unit-файл, притом не вмешиваясь в пакетную базу и не беспокоясь об обновлении пакета. И вполне возможно, что в скором времени (в следствии унификации) unit-файлы будут поставляться вместе с исходным кодом и тогда вообще ничего писать\переписывать не потребуется.
> в скором времени (в следствии унификации) unit-файлы будут поставляться вместе с
> исходным кодом и тогда вообще ничего писать\переписывать не потребуется.хехе, ты наивный чукотский вьюноша
скорее в systemd lua приделают для разнообразия скриптов
>> в скором времени (в следствии унификации) unit-файлы будут поставляться вместе с
>> исходным кодом и тогда вообще ничего писать\переписывать не потребуется.
> хехе, ты наивный чукотский вьюноша
> скорее в systemd lua приделают для разнообразия скриптовВремя рассудит.
Скорее, wordbasic.
>Любой админ может также (на|пере)писать и unit-файл,Сомневаюсь я.
>притом не вмешиваясь в пакетную базу и не беспокоясь об обновлении пакета.
У людей своих пакетов навалом, у меня их больше сотни.
>И вполне возможно, что в скором времени (в следствии унификации) unit-файлы будут поставляться вместе с исходным кодом и тогда вообще ничего писать\переписывать не потребуется.
Вот сейчас как раз всё унифицировано. А будет ли унификация на базе systemd большой вопрос.
передай свою "унифицированную" систему другому человеку, узнаешь много нового.
> передай свою "унифицированную" систему другому человеку, узнаешь много нового.Не унифицированных систем не бывает.
>> передай свою "унифицированную" систему другому человеку, узнаешь много нового.
> Не унифицированных систем не бывает.А каким либо образом обосновать свою позицию вы можете?
> А каким либо образом обосновать свою позицию вы можете?А разве очевидные вещи нуждаются в обосновании? В разных компаниях разные бизнес-процессы, разные предпочтения, разный уровень подготовки персонала, разный уровень дохода и инвестиций в ИТ.
Или вы считаете что на сталелитейном заводе и в банке одна и та же инфраструктура?
>> А каким либо образом обосновать свою позицию вы можете?
> А разве очевидные вещи нуждаются в обосновании? В разных компаниях разные бизнес-процессы,
> разные предпочтения, разный уровень подготовки персонала, разный уровень дохода и инвестиций
> в ИТ.
> Или вы считаете что на сталелитейном заводе и в банке одна и
> та же инфраструктура?"Не унифицированных систем не бывает." - так сдесь потерялась запятая или пробел вкрался?
> "Не унифицированных систем не бывает." - так сдесь потерялась запятая или пробел
> вкрался?Ну если судить по "сдесь", то для вас возможно.
>> "Не унифицированных систем не бывает." - так сдесь потерялась запятая или пробел
>> вкрался?
> Ну если судить по "сдесь", то для вас возможно.Ну так вот вышло, что поделаешь? А по существу есть что сказать?
>> передай свою "унифицированную" систему другому человеку, узнаешь много нового.
> Не унифицированных систем не бывает.На дистровотче это напиши, ага? На глагне.
>>Любой админ может также (на|пере)писать и unit-файл,
> Сомневаюсь я.А вы попробуйте )
>>притом не вмешиваясь в пакетную базу и не беспокоясь об обновлении пакета.
> У людей своих пакетов навалом, у меня их больше сотни.А если необходимо поправить стандартный init-файл? (Из чисто обывательского интереса, можно ли ознакомиться со списком "больше сотни"?)
>>И вполне возможно, что в скором времени (в следствии унификации) unit-файлы будут поставляться вместе с исходным кодом и тогда вообще ничего писать\переписывать не потребуется.
> Вот сейчас как раз всё унифицировано. А будет ли унификация на базе
> systemd большой вопрос.Т.е вот так легко я беру init-файл с Debian и использую его в RHEL и SLES? Это по-вашему "унификация"?
>>>Любой админ может также (на|пере)писать и unit-файл,
>> Сомневаюсь я.
> А вы попробуйте )А зачем?
>>>притом не вмешиваясь в пакетную базу и не беспокоясь об обновлении пакета.
>> У людей своих пакетов навалом, у меня их больше сотни.
> А если необходимо поправить стандартный init-файл?И что? Какие-то сложности? Стандартный bash, где 50% комментариев и код в виде switch/case.
>>>И вполне возможно, что в скором времени (в следствии унификации) unit-файлы будут поставляться вместе с исходным кодом и тогда вообще ничего писать\переписывать не потребуется.
>> Вот сейчас как раз всё унифицировано. А будет ли унификация на базе
>> systemd большой вопрос.
> Т.е вот так легко я беру init-файл с Debian и использую его
> в RHEL и SLES? Это по-вашему "унификация"?Ну для начала, давайте не будем называть загрузочные скрипты init-файлами. А во-вторых вернемся к нашим баранам, systemd это надуманную проблему не решает. При переезде с одной системы на другую возникают совсем иного рода сложности. И таки да, загрузочный скрипт с дебина после небольшой доработки будет работать везде.
>>>>Любой админ может также (на|пере)писать и unit-файл,
>>> Сомневаюсь я.
>> А вы попробуйте )
> А зачем?Сомнения обычно можно подтвердить, либо опровергнуть опытом.
>>>>притом не вмешиваясь в пакетную базу и не беспокоясь об обновлении пакета.
>>> У людей своих пакетов навалом, у меня их больше сотни.
>> А если необходимо поправить стандартный init-файл?
> И что? Какие-то сложности? Стандартный bash, где 50% комментариев и код в
> виде switch/case.Затем, что после обновления пакета все ваши изменения улетят в трубу.
>>>>И вполне возможно, что в скором времени (в следствии унификации) unit-файлы будут поставляться вместе с исходным кодом и тогда вообще ничего писать\переписывать не потребуется.
>>> Вот сейчас как раз всё унифицировано. А будет ли унификация на базе
>>> systemd большой вопрос.
>> Т.е вот так легко я беру init-файл с Debian и использую его
>> в RHEL и SLES? Это по-вашему "унификация"?
> Ну для начала, давайте не будем называть загрузочные скрипты init-файлами. А во-вторых
> вернемся к нашим баранам, systemd это надуманную проблему не решает. При
> переезде с одной системы на другую возникают совсем иного рода сложности.
> И таки да, загрузочный скрипт с дебина после небольшой доработки будет
> работать везде."Загрузочные скрипты" именуют init-файлами, либо init-скриптами. А чтобы перенести unit-файл systemd на другую систему с systemd, мне достаточно его просто скопировать. И никаких "небольших доработок".
P.S.: Из чисто обывательского интереса, можно ли ознакомиться со списком "больше сотни"?
>>>>>Любой админ может также (на|пере)писать и unit-файл,
>>>> Сомневаюсь я.
>>> А вы попробуйте )
>> А зачем?
> Сомнения обычно можно подтвердить, либо опровергнуть опытом.Расскажи про свой опыт с мужиками и наркотиками.
>>>>>притом не вмешиваясь в пакетную базу и не беспокоясь об обновлении пакета.
>>>> У людей своих пакетов навалом, у меня их больше сотни.
>>> А если необходимо поправить стандартный init-файл?
>> И что? Какие-то сложности? Стандартный bash, где 50% комментариев и код в
>> виде switch/case.
> Затем, что после обновления пакета все ваши изменения улетят в трубу.Обновления какого пакета? Не сваливаете в абстракцию.
>[оверквотинг удален]
>>>> Вот сейчас как раз всё унифицировано. А будет ли унификация на базе
>>>> systemd большой вопрос.
>>> Т.е вот так легко я беру init-файл с Debian и использую его
>>> в RHEL и SLES? Это по-вашему "унификация"?
>> Ну для начала, давайте не будем называть загрузочные скрипты init-файлами. А во-вторых
>> вернемся к нашим баранам, systemd это надуманную проблему не решает. При
>> переезде с одной системы на другую возникают совсем иного рода сложности.
>> И таки да, загрузочный скрипт с дебина после небольшой доработки будет
>> работать везде.
> "Загрузочные скрипты" именуют init-файлами, либо init-скриптами."Загрузочные скрипты" именуют "загрузочными скриптами".
> А чтобы перенести unit-файл
> systemd на другую систему с systemd, мне достаточно его просто скопировать.
> И никаких "небольших доработок".Тут нужно описать процесс переноса, скажем на ubuntu.
> P.S.: Из чисто обывательского интереса, можно ли ознакомиться со списком "больше сотни"?
>>>>>>Любой админ может также (на|пере)писать и unit-файл,
>>>>> Сомневаюсь я.
>>>> А вы попробуйте )
>>> А зачем?
>> Сомнения обычно можно подтвердить, либо опровергнуть опытом.
> Расскажи про свой опыт с мужиками и наркотиками.
> "Загрузочные скрипты" именуют "загрузочными скриптами".А вот когда аргументы заканчиваются, начинается переход на личности и подобие буквоедства, причем в быдло-режиме. За сим раскланиваюсь, так как дальнешую беседу продолжать смысла не вижу.
Очень хорошо, что у тебя аргументы закончились, хотя их и не было. И наконец ты закончил свое буквоедство.
> Затем, что после обновления пакета все ваши изменения улетят в трубу.С systemd изменения аналогично улетают в трубу.
> "Загрузочные скрипты" именуют init-файлами, либо init-скриптами. А чтобы перенести unit-файл
> systemd на другую систему с systemd, мне достаточно его просто скопировать.
> И никаких "небольших доработок".че правда? И даже пути менять не будешь? аля /usr/sbin/nginx => /usr/bin/nginx
>> Затем, что после обновления пакета все ваши изменения улетят в трубу.
> С systemd изменения аналогично улетают в трубу.Вы точно в этом уверены? )
>> "Загрузочные скрипты" именуют init-файлами, либо init-скриптами. А чтобы перенести unit-файл
>> systemd на другую систему с systemd, мне достаточно его просто скопировать.
>> И никаких "небольших доработок".
> че правда? И даже пути менять не будешь? аля /usr/sbin/nginx => /usr/bin/nginxТут согласен. Но есть тенденция к переносу всех бинарников в /usr/bin
> Вы точно в этом уверены? )Абсолютно, ибо конфиг - часть пакета и новый пакет его перезапишет.
А если не перезапишет это особенность сборки а не заслуга systemd
>> Вы точно в этом уверены? )
> Абсолютно, ибо конфиг - часть пакета и новый пакет его перезапишет.
> А если не перезапишет это особенность сборки а не заслуга systemds/конфиг/юнит-файл/
Кастомные юниты кладутся в /etc/systemd/system/, а дистрибутивные - в /lib/systemd/system/, причем первые имеют приоритет и пакетным менеджером не трогаются.Более того, в случае необходимости внесения минимальных правок возможны такие вещи, как, например:
># cat /etc/systemd/system/jetty.service
>.include /usr/lib/systemd/system/jetty.service
>[Service]
>User=jetty
>Group=jetty
тебе что-то мешает положить сделать кастомный rc скрипт?
Вообще причем тут systemd, это вопрос к пакетному менеджеру.
> Вы точно в этом уверены? )absolutely
>> Вы точно в этом уверены? )
> absolutelyЕще один "спец" по systemd... Сколько же вас?
> че правда? И даже пути менять не будешь? аля /usr/sbin/nginx => /usr/bin/nginxЕсли вы про Арч, то нет - /usr/sbin/ теперь симлинк на /usr/bin, так что менять не нужно.
> P.S.: Из чисто обывательского интереса, можно ли ознакомиться со списком "больше сотни"?Звучит так: "про systemd сказать ничего хорошего не могу, но докопаться попробую".
Касательно пакетов, собственноручно разработанное ПО, собственноручно допиленное или собранное ПО, метапакеты, например для разворачивания полностью готового к эксплуатации почтового сервера за пару минут, или интернет-магазина, наборы для деплоя на все случаи жизни.
> ну так и shell-код будет написан один раз, причем любой админ может написать, для любых своих сервисов.Ну так мне как админу написать конфиг на 5 строк для любых моих сервисов - явно проще, да? :)
дык вынеси все функции из инит скрипта в отдельный файл и получи сравнимую длину, и отлаживать проще будет чем си код.
И почему никто этого так до сих пор и не сделал ?
> И почему никто этого так до сих пор и не сделал ?Отучаемся говорить за всех. Я так делаю ВСЕГДА.
> и отлаживать проще будет чем си код.Ага, ЩАЗ. Service файлы - не сишный код. Отлаживают сишный код разработчики systemd. А админ "отлаживает" конфиг на пять строк. Поэтому жизня админа становится сильно проще. Ему не надо ни выносить ничего в какие-то файлы, ни дописывать фреймворк логгирования обломов в каждой скриптопортянке, ни что там еще.
>> и отлаживать проще будет чем си код.
> Поэтому жизня админа становится сильно проще.Поэтому теперь админом Linux может стать каждая безграмотраня обезьяна, закончившая 32е пту на плотника, но потом решившая что там платят сильно мало и пошедшая на 3х месячные курсы. На рынке Windows-админов такие толпами по 10000 за 5 человек предлагаются.
>>> и отлаживать проще будет чем си код.
>> Поэтому жизня админа становится сильно проще.
> Поэтому теперь админом Linux может стать каждая безграмотраня обезьяна, закончившая 32е
> пту на плотника, но потом решившая что там платят сильно мало
> и пошедшая на 3х месячные курсы. На рынке Windows-админов такие толпами
> по 10000 за 5 человек предлагаются.То есть перед тем, как стать "админом Linux" надо ВО получить? И желательно в MIT, наверное?
> То есть перед тем, как стать "админом Linux" надо ВО получить? И
> желательно в MIT, наверное?Нет, но поболее поучиться, чем 3 месяца. Сейчас же это больше похоже на Windows-подход, дайте нам кучу блэк-боксов со скудными интерфейсами доступа к ним, но зато пусть будет удобно. Дело в том что понимание концепции Unix как бесконечно расширяемой за счет своих инструментов системы очень таки помогает в выборе этих самых инструментов.
>>> и отлаживать проще будет чем си код.
>> Поэтому жизня админа становится сильно проще.
> Поэтому теперь админом Linux может стать каждая безграмотраня обезьяна, закончившая 32е
> пту на плотника, но потом решившая что там платят сильно мало
> и пошедшая на 3х месячные курсы.Глупость. От того, что какие-то вещи стали легче, мир не рухнет. Эффективность меряется умением пользоваться целым, всей совокупностью компонентов. А не деталями по отдельности. И тут, если кто-то не умеет организовать нормально - не организует, а кто умеет - организует. И простота гораздо важнее для второго.
Или вы боитесь, что "аждая безграмотраня обезьяна, закончившая 32е пту на плотника, но потом решившая что там платят сильно мало и пошедшая на 3х месячные курсы" при этом всём будет лучше вас?
Уровень подготовки специалиста резко упадет. Снова же, уровень подготовки Microsoft-специалистов это подтверждает.
> Уровень подготовки специалиста резко упадет. Снова же, уровень подготовки Microsoft-специалистов
> это подтверждает.Есть реальные спецы по MS и есть эникеи. Есть реалтные спецы по Linux и есть те, которые поставили один раз user-friendly дистрибутив. При чем тут systemd - непонятно.
> Есть реальные спецы по MS и есть эникеи. Есть реалтные спецы по
> Linux и есть те, которые поставили один раз user-friendly дистрибутив. При
> чем тут systemd - непонятно.Эммм, скажите же мне, почему реальные спецы по Active Directory например зачастую не могут восстановить репликацию в этой самой Active Directory, восстановить репликацию Exchange и испытвают столько проблем с софтом MS вообще (ну например сталкивался в работе с тем, что у меня отваливались базы Excahnge)? Бинго, потому что благодаря Microsoft их программные продукты становятся black box-ами со скудными интерфейсами взаимодействия пользоателя с системой. А для Microsoft поддержка = дополнительная денежка. Впрочем как и для RH. Компаниям выгодно иметь технически неграмотный персонал, обслуживающий их системы, потому что тогда они получат больше денег. Вот так вот и с systemd.
>> Есть реальные спецы по MS и есть эникеи. Есть реалтные спецы по
>> Linux и есть те, которые поставили один раз user-friendly дистрибутив. При
>> чем тут systemd - непонятно.
> Эммм, скажите же мне, почему реальные спецы по Active Directory например зачастую
> не могут восстановить репликацию в этой самой Active Directory, восстановить репликацию
> Exchange и испытвают столько проблем с софтом MS вообще (ну например
> сталкивался в работе с тем, что у меня отваливались базы Excahnge)?Значит это не "реальные спецы". BlackBox в MS, присутсвует. Но systemd вроде как по GPL лицензирован - ваше сравнение в корне неверно.
>Значит это не "реальные спецы".Вы простите, но реальные, MS-сертифицированные. Но systemd вроде как по GPL лицензирован.
То, что открыты его исходники, еще не значит, что у вас вдруг внезапно появится новый функционал, будет такое же "кушайте что дают" как и у MS. Хотя чем черт не шутит, не исключено что в одной из версий в будущем Леннарт запилит какой-нибудь systembash для возможности неограниченного наращивания функционала у systemd-юнитов...
>>Значит это не "реальные спецы".
> Вы простите, но реальные, MS-сертифицированные. Но systemd вроде как по GPL лицензирован.Я могу получить 5 сертификатов по MS за 5 дней - но что дают эти бумажки?
> То, что открыты его исходники, еще не значит, что у вас вдруг
> внезапно появится новый функционал, будет такое же "кушайте что дают" как
> и у MS. Хотя чем черт не шутит, не исключено что
> в одной из версий в будущем Леннарт запилит какой-нибудь systembash для
> возможности неограниченного наращивания функционала у systemd-юнитов...А это уже домыслы. Время покажет. Как-бы в Arch, SuSe и Mandriva не насильно пропихивали его, да и не доплачивал "злостный RedHat". Почему бы ненавистникам, коих вроде много не собраться в кучу, да и не создать systemd-free дистрибутив? А потому, что даже пары человек на поддержку sysvinit в арче не нашлось...
>А потому, что даже пары человек на поддержку sysvinit в арче не нашлось...ну языком чесать - это ж не мешки ворочать...опеннет этому доказательство
Ну как бы мне по боку, я другими системами пользуюсь systemd-free.
> А это уже домыслы. Время покажет. Как-бы в Arch, SuSe и Mandriva
> не насильно пропихивали его, да и не доплачивал "злостный RedHat". Почему
> бы ненавистникам, коих вроде много не собраться в кучу, да и
> не создать systemd-free дистрибутив? А потому, что даже пары человек на
> поддержку sysvinit в арче не нашлось...У нас с вами разговор в ключе "В огороде бузина, а в киеве дядька" выходит. Я вам о том, что у systemd мало точек соприкосновения с пользователем, а вы мне "Зато его SuSe и Mandriva поддерживают". Естественно поддерживают, куда им деваться-то, приходится быть максимально совместимыми с лидером рынка.
> У нас с вами разговор в ключе "В огороде бузина, а в
> киеве дядька" выходит. Я вам о том, что у systemd мало
> точек соприкосновения с пользователем, а вы мне "Зато его SuSe и
> Mandriva поддерживают". Естественно поддерживают, куда им деваться-то, приходится быть
> максимально совместимыми с лидером рынка.Лидеры рынка linux-desktop - это Debian/Ubuntu.
>> А это уже домыслы. Время покажет. Как-бы в Arch, SuSe и Mandriva
>> не насильно пропихивали его, да и не доплачивал "злостный RedHat". Почему
>> бы ненавистникам, коих вроде много не собраться в кучу, да и
>> не создать systemd-free дистрибутив? А потому, что даже пары человек на
>> поддержку sysvinit в арче не нашлось...
> У нас с вами разговор в ключе "В огороде бузина, а в
> киеве дядька" выходит. Я вам о том, что у systemd мало
> точек соприкосновения с пользователем, а вы мне "Зато его SuSe и
> Mandriva поддерживают". Естественно поддерживают, куда им деваться-то, приходится быть
> максимально совместимыми с лидером рынка.Простите, а что вы имеете ввиду под "мало точек соприкосновения с пользователем"?
Имею в виду ограниченный механизм его расширения в отличии от скриптов и ограниченные возможности управления юнитами, нету функции reload например, которая делает gracefull reload сервиса.
> Имею в виду ограниченный механизм его расширения в отличии от скриптов
> и ограниченные возможности управления юнитами, нету функции reload например, которая делает
> gracefull reload сервиса.reload как раз-таки есть ) а расширять возможности теми-же sh-скриптами вам никто не мешает.
>>>Значит это не "реальные спецы".
>> Вы простите, но реальные, MS-сертифицированные. Но systemd вроде как по GPL лицензирован.
> Я могу получить 5 сертификатов по MS за 5 дней - но
> что дают эти бумажки?Что доказывает мое утверждение о том, что виндовые админы имеют низкую кваллификацию в массе своей, что собственно грозит Linux-админам в будущем с запиливанием нанотехнологий института имени Поттеринга.
>>>>Значит это не "реальные спецы".
>>> Вы простите, но реальные, MS-сертифицированные. Но systemd вроде как по GPL лицензирован.
>> Я могу получить 5 сертификатов по MS за 5 дней - но
>> что дают эти бумажки?
> Что доказывает мое утверждение о том, что виндовые админы имеют низкую кваллификацию
> в массе своей, что собственно грозит Linux-админам в будущем с запиливанием
> нанотехнологий института имени Поттеринга.Это подтверждает только то, что бумажки ничего не стоят. А квалифицированные MS-админы встречаются. Правда редко. Также редко, как и квалифицированные Linux-админы )
> Или вы боитесь, что "аждая безграмотраня обезьяна, закончившая 32е пту на плотника,
> но потом решившая что там платят сильно мало и пошедшая на
> 3х месячные курсы" при этом всём будет лучше вас?А давайте вы не будете так толсто троллить переключаясь на личности? Мы все таки не на ЛОРе.
>> Или вы боитесь, что "аждая безграмотраня обезьяна, закончившая 32е пту на плотника,
>> но потом решившая что там платят сильно мало и пошедшая на
>> 3х месячные курсы" при этом всём будет лучше вас?
> А давайте вы не будете так толсто троллить переключаясь на личности? Мы все таки не на ЛОРе.Давайте. Начинайте.
>админом Linux может стать каждая безграмотраня обезьянаЕсть такая штука, прогресс называется. Раньше бельё постирать люди прачек нанимали или сами прачками были, потом появились огромные стиральные машины-автоматы, не все могли их купить. А сейчас и не шибко богатые могут купить такую машину, небольшую, такую что поместится в скромных размеров туалете. Хим.чистки остались, но теперь они именно хим.чистки. Прачек в Советском Союзе ликвидировали "как класс", остались ли они в странах Запада я не знаю. Такая же судьба постигла кухарок, портных, я уж не говорю о писарях. Зато десятая часть потомков прачек, портных, кухарок и писарей теперь производит в десять раз больше полезной продукции, соответственно на нос в десять раз больше материальных благ достаётся. В цивилизованных странах, разумеется. Впрочем, в России их (материальных благ) на нос тоже сейчас существенно больше, чем сто лет назад было. Ну вот теперь костлявая рука прогресса и до linux-админов дотянулась.
Поэтому жизня админа становится сильно проще.Я бы так не сказал, хотя бы потому что systemd новая сущность, которая пришла на смену хорошо изученной sysvinit и в новой системе инициализации новые глюки типа "не поднялся сетевой интерфейс после 101 загрузки", или каждую 15 загрузку диски меняются именами "sda/sdb" - это реальные ситуации из реальной жизни (не моей).
Далее следует секс с поиском решения чтобы сетевой интерфейс поднимался всегда,костыли вида добавить файл в /etc/modules-load.d/ - этого хватит еще на 30-40 загрузка, потом проблема поднятия интерфейса вернется, будет найден совет добавить "таймаут в юнит-файл", но и это не поможет - вот тут и наступит безисходность :)
> Поэтому жизня админа становится сильно проще.
> Я бы так не сказал, хотя бы потому что systemd новая сущность,
> которая пришла на смену хорошо изученной sysvinit и в новой системе
> инициализации новые глюки типа "не поднялся сетевой интерфейс после 101 загрузки",
> или каждую 15 загрузку диски меняются именами "sda/sdb" - это реальные
> ситуации из реальной жизни (не моей).Посоветую поинтересоваться принципами именования блочных устройств в GNU/Linux.
> Далее следует секс с поиском решения чтобы сетевой интерфейс поднимался всегда,костыли
> вида добавить файл в /etc/modules-load.d/ - этого хватит еще на 30-40
> загрузка, потом проблема поднятия интерфейса вернется, будет найден совет добавить "таймаут
> в юнит-файл", но и это не поможет - вот тут и
> наступит безисходность :)А всего-лишь поправить /etc/udev/rules.d/70-persistent-net.rules .
P.S.: И systemd тут вообще не причем. udev существовал задолго до него.
>P.S.: И systemd тут вообще не причем. udev существовал задолго до него.Ну да, а udev уже перестал быть частью systemd?
>>P.S.: И systemd тут вообще не причем. udev существовал задолго до него.
> Ну да, а udev уже перестал быть частью systemd?Повторюсь. udev существовал задолго до него. И конфигурился точно также как и сейчас.
А я еще раз повторюсь что udev является частью systemd, и все изменения в udev это изменения в systemd. Ну и как должны сойтись звезды чтобы systemd тут был не причем?
А если понадобятся нестандартные действия/реакция?
A ежели дождь во время усушки ?
> А если понадобятся нестандартные действия/реакция?Вот тогда можно пнуть скрипт или какую-то другую программу для этого.
P.S. "А если ядерная война? Или метеорит на дом упадет?!" - вы же нам, надеюсь, писали все это из укрепленного бункера на километровой глубине, с системой жизнеобеспечения и все такое, правда? :)
> Вот тогда можно пнуть скрипт или какую-то другую программу для этого.а зачем тогда столько сущностей (systemd+скрипт), если в случае с init она была всего одна?
Бункер на такой глубине не только от метеоритов защитит, но и ещё много от чего, но обустроить его в Москве для себя его неподъёмно по цене, а вот без systemd вполне можно и обойтись, для этого много тратиться не надо.
> ты забыл выложить для systemd юнита код на си, который будет это все парсить и запускатьСистемный администратор с компонентами systemd дела не имеет - это проблемы разработчиков systemd.
Прошу заметить что функциональность хромает.
unit имеет acton: start,reload,stop
а инит скрипт: start,stop,reload,configtest,upgrade, status,а теперь запили мне юнит для systemd с аналогичной функциональностью
Последователей Поттеринга это не волнует, что сказали жрать, то и будут. Подумаешь, юниты не могут ничего кроме start/stop/restart(reload), зато "это открывает множество дополнительных способов использования" и "в то же время гибкий интерфейс - снаружи".
> Последователей Поттеринга это не волнует, что сказали жрать, то и будут.Большинство людей система иницализации их компьютера волнует примерно так же, как внешний вид байтов.
Это дистрибутивы выбирают себе ядра, системы инициализации, и прочее по, чтобы решать задачи, которые они наметили. И Debian - один из лидеров дистибутивостроения. И 90% его пользователей абсолютно наплевать, какая там система инициализации, они оценивают всё в комплексе, как это работает всё вместе, а не разбирают детали по отдельности.
При этом, разработчики Debian, в отличие от безвестных крикунов (которые могут предлагать самые сумасбродные идеи без риска быть обсмеяными при их практической реализации) несут ответственность за своих пользователей, и от их решений зависит очень многое, они не могут сделать просто "прикольно, мне нравится", иначе они всех этих пользователей потеряют. И им приходится решать сложные задачи, и постоянно искать компромиссы.
Если бы безвестный горлопан обладал бы такой же степенью публичности при выборе своих решений, он бы понял цену словам.
> Прошу заметить что функциональность хромает.
> unit имеет acton: start,reload,stop
> а инит скрипт: start,stop,reload,configtest,upgrade, status,
> а теперь запили мне юнит для systemd с аналогичной функциональностьюДа зачем ? Разве итак не понятно что крутое супер админы _требужшие_ сысЪтемд даже разницы не уловили. Проффесионалы, не чета нам :)
А вы - это кто такое, чтобы ваше мнение кого-то вообще интересовало? :)
> Прошу заметить что функциональность хромает.
> unit имеет acton: start,reload,stop
> а инит скрипт: start,stop,reload,configtest,upgrade, status,
> а теперь запили мне юнит для systemd с аналогичной функциональностьюЕсли бы вы хоть раз прочитали документацию или попробовали запустить systemctl, вы бы поняли, что этот unit в systemd умеет start,stop,reload,configtest и status ("искаропки"). А кроме того еще и reload-or-restart,dump,enable,disable,try-restart и.т.д. Единственный пункт мимо - это upgrade, но это достаточно сомнительный функционал.
.
>enable,disableАналог внесения в строку DAEMONS в rc.conf, не более
Кроме тогда - в строке всегда сразу видно какие демоны запускаются, а какие нет.
А как это сделать в systemd ?
>>enable,disable
> Аналог внесения в строку DAEMONS в rc.conf, не более
> Кроме тогда - в строке всегда сразу видно какие демоны запускаются, а
> какие нет.
> А как это сделать в systemd ?Во-первых в systemd вводится понятие зависимостей.
А во-вторых: ls /etc/systemd/system/*.wants/ , причем по полочкам.
>>>enable,disable
>> Аналог внесения в строку DAEMONS в rc.conf, не более
>> Кроме тогда - в строке всегда сразу видно какие демоны запускаются, а
>> какие нет.
>> А как это сделать в systemd ?
> Во-первых в systemd вводится понятие зависимостей.в sysv init оно тоже есть...
> этот unit в systemd умеет start,stop,reload,configtest и status
> ("искаропки"). А кроме того еще и reload-or-restart,dump,enable,disable,try-restart
> и.т.д.Подскажите, как посмотреть эти команды?
>> этот unit в systemd умеет start,stop,reload,configtest и status
>> ("искаропки"). А кроме того еще и reload-or-restart,dump,enable,disable,try-restart
>> и.т.д.
> Подскажите, как посмотреть эти команды?man systemctl
Тоесть кроме юнит файла еще по куче мест раскидано что может делать сервис?
Офигенная прозрачность просто.
>> Где БЛЯ профит?!
> #cat /lib/systemd/system/nginx.service
> ......................................
> #cat /etc/init.d/nginx[Позёвывая]
... очередной придурок сравнил мопед с БелАЗом и пришёл к генеальному выводу что тервый меньше и легче? :)Прочитать _что_ умеет второй вариант не судьба? Таким - да нужен сысынит. Или винда. Всё одно - reinstall system often, reinstall system early(С) :-)
>>> Где БЛЯ профит?!
>> #cat /lib/systemd/system/nginx.service
>> ......................................
>> #cat /etc/init.d/nginx
> [Позёвывая]
> ... очередной придурок сравнил мопед с БелАЗом и пришёл к генеальному выводу
> что тервый меньше и легче? :)
> Прочитать _что_ умеет второй вариант не судьба? Таким - да нужен сысынит.
> Или винда. Всё одно - reinstall system often, reinstall system early(С)
> :-)http://www.opennet.ru/openforum/vsluhforumID3/90371.html#182
"Многабукафф, ниасилил, низачед, кг/ам" да ?Я вот например прекрасно понимаю что значит строчка
. /etc/rc.d/init.d/functions
прекрасно понимаю чем является конструкция
reload() {
configtest_q || return 6
echo -n $"Reloading $prog: "
killproc -p $pidfile $prog -HUP
echo
}Зачем тут скобочки фигурные идут ?
А вашем системд:
ExecReload=/bin/kill -s HUP $MAINPID
Начнем с того, что kill по абсолютному пути вызвается, а не через переменную путей окружения.
Далее - /bin/kill -s HUP такая конструкция позволит перезапустить процесс, а не просто прихлопнуть ?
Кроме того, в sysvinit в функции перезагрузки демона, вызывается configtest_qconfigtest_q() {
$nginx -t -q -c $NGINX_CONF_FILE
}Я тут вижу проверку конфиг-файла на правильность, или что-то еще, а где это в вашем системД ?
Может все-таки экономия строк кода "щутковины", которая запускает/перезапускает демон - это не всегда гуд ?
Вот как запускается nginx в системД:
ExecStart=/usr/sbin/nginx
Никаких проверок, нах нужно - если процесс есть, то новый не запуститься, так как порт/сокет будет уже занят, да :) ?
Типа пусть ядро на себя берет проверки все.Какие вы все...я с вас фигею просто.ExecStart=/usr/sbin/nginx
В случае с баш-портянкой я царь-и-бог в своей системе, если что-то нужно будет поменять в баш-скрипте, типа сделать доп проверку наличия файла в директории, или еще чего-то что мне может мне понадобиться - я это сделать смогу, а в случае с системД -нет.
Вы, глупые собеседники, приводящие аргумент что чем меньше строк кода в сущности ( которая управляет демоном ) - тем лучше, вы и в правду глупые, вы из тех людей что покупают в магазине телевизор, из-за характеристик указанных на ценнике, в рекламе.
> #cat /lib/systemd/system/nginx.serviceА теперь grep USR2 /lib/systemd/system/nginx.service сделайте.
> # Upgrade the binary with no downtime.
>[оверквотинг удален]
> [Service]
> Type=forking
> PIDFile=/run/nginx.pid
> ExecStartPre=/usr/sbin/nginx -t
> ExecStart=/usr/sbin/nginx
> ExecReload=/bin/kill -s HUP $MAINPID
> ExecStop=/bin/kill -s QUIT $MAINPID
> PrivateTmp=true
> [Install]
> WantedBy=multi-user.targetДавайте сравнивать корректно и не лезть в код, Вы же не лезете в программный код systemD.
> Где БЛЯ профит?!Проясните, пожалуйста, некоторые пункты:
1) Какая цель преследуется монтированием tmpfs в /media ?
2) Как выглядит ваш unit-файл с десятью параметрами получившийся в итоге, если не стыдно.
3) Является ли правильным решением, редактирование файла поставляемого с пакетом, который при этом не является файлом конфигурации?
>> Где БЛЯ профит?!
> Проясните, пожалуйста, некоторые пункты:
> 1) Какая цель преследуется монтированием tmpfs в /media ?Православный костыль для быстрой работы.
> 3) Является ли правильным решением, редактирование файла поставляемого с пакетом, который
> при этом не является файлом конфигурации?Да. Процесс кастомизации никто не отменял.
>>> Где БЛЯ профит?!
>> Проясните, пожалуйста, некоторые пункты:
>> 1) Какая цель преследуется монтированием tmpfs в /media ?
> Православный костыль для быстрой работы.Каким образом этот "православный костыль" ускоряет работу? И чью работу он ускоряет? Не могу представить, что смонтировав tmpfs в /media я уйду с работы пораньше )
>> 3) Является ли правильным решением, редактирование файла поставляемого с пакетом, который
>> при этом не является файлом конфигурации?
> Да. Процесс кастомизации никто не отменял.И что будет при обновлении пакета?
>>>> Где БЛЯ профит?!
>>> Проясните, пожалуйста, некоторые пункты:
>>> 1) Какая цель преследуется монтированием tmpfs в /media ?
>> Православный костыль для быстрой работы.
> Каким образом этот "православный костыль" ускоряет работу? И чью работу он ускоряет?
> Не могу представить, что смонтировав tmpfs в /media я уйду с
> работы пораньше )Если ваша работа напрямую зависит от вычислений связанных с активным использованием диска, то уйдете домой еще до обеда.
>>> 3) Является ли правильным решением, редактирование файла поставляемого с пакетом, который
>>> при этом не является файлом конфигурации?
>> Да. Процесс кастомизации никто не отменял.
> И что будет при обновлении пакета?Ничего.
#aptitude hold name_packed
>>>>> Где БЛЯ профит?!
>>>> Проясните, пожалуйста, некоторые пункты:
>>>> 1) Какая цель преследуется монтированием tmpfs в /media ?
>>> Православный костыль для быстрой работы.
>> Каким образом этот "православный костыль" ускоряет работу? И чью работу он ускоряет?
>> Не могу представить, что смонтировав tmpfs в /media я уйду с
>> работы пораньше )
> Если ваша работа напрямую зависит от вычислений связанных с активным использованием диска,
> то уйдете домой еще до обеда.А можно какой-либо пруф в подтверждение?
>>>> 3) Является ли правильным решением, редактирование файла поставляемого с пакетом, который
>>>> при этом не является файлом конфигурации?
>>> Да. Процесс кастомизации никто не отменял.
>> И что будет при обновлении пакета?
> Ничего.
> #aptitude hold name_packedТогда уж проще так:
#rm -rf /etc/apt
> А можно какой-либо пруф в подтверждение?gooole// насколько порядков работа оперативной памяти быстрее работы диска.
> Тогда уж проще так:
> #rm -rf /etc/aptИ чего видно, что вы не поняли смысл команды "заморозки" пакета.
>И чего видно, что вы не поняли смысл команды "заморозки" пакета.мне пакет обновлённый надо, с фиксами и фичами а не замороденное старьё - из-за вашего метода редактирования того что по логике должно редактироваться мантейнером (и патчами мантейнеру) а не админом
>> Где БЛЯ профит?!
> Проясните, пожалуйста, некоторые пункты:
> 1) Какая цель преследуется монтированием tmpfs в /media ?Никогда не останутся "левые" каталоги-точки для автомонтирования, если, например, система внезапно перезагрузилась.
>>> Где БЛЯ профит?!
>> Проясните, пожалуйста, некоторые пункты:
>> 1) Какая цель преследуется монтированием tmpfs в /media ?
> Никогда не останутся "левые" каталоги-точки для автомонтирования, если, например, система
> внезапно перезагрузилась.Вот тут могу согласиться ) Но сейчас это и так все в виртуальной фс /run.
>> Где БЛЯ профит?!
> Проясните, пожалуйста, некоторые пункты:
> 1) Какая цель преследуется монтированием tmpfs в /media ?тут как раз таки все понятно - что бы не подчищать за собой созданые каталоги от какого нить automount и не мучать ssd - проще иметь в tmpfs - и там создавать каталоги для точек монтирования.
Единственная проблема что кто-то статический mount из fstab не посмотрел.
>>> Где БЛЯ профит?!
>> Проясните, пожалуйста, некоторые пункты:
>> 1) Какая цель преследуется монтированием tmpfs в /media ?
> тут как раз таки все понятно - что бы не подчищать за
> собой созданые каталоги от какого нить automount и не мучать ssd
> - проще иметь в tmpfs - и там создавать каталоги для
> точек монтирования.
> Единственная проблема что кто-то статический mount из fstab не посмотрел.Вроде как все, кто не из криокамеры давно на /run перешли, не?
>>>> Где БЛЯ профит?!
>>> Проясните, пожалуйста, некоторые пункты:
>>> 1) Какая цель преследуется монтированием tmpfs в /media ?
>> тут как раз таки все понятно - что бы не подчищать за
>> собой созданые каталоги от какого нить automount и не мучать ssd
>> - проще иметь в tmpfs - и там создавать каталоги для
>> точек монтирования.
>> Единственная проблема что кто-то статический mount из fstab не посмотрел.
> Вроде как все, кто не из криокамеры давно на /run перешли, не?для mount points ?! в /run кладут вроде как содержимое старого /var/run. не ?
ps. я видимо еще в криокамеры - у меня ничего новее RHEL6 нету. а туда эти ново введения еще не дошли.
> для mount points ?!В арче уже давно /run/media
>[оверквотинг удален]
>>> тут как раз таки все понятно - что бы не подчищать за
>>> собой созданые каталоги от какого нить automount и не мучать ssd
>>> - проще иметь в tmpfs - и там создавать каталоги для
>>> точек монтирования.
>>> Единственная проблема что кто-то статический mount из fstab не посмотрел.
>> Вроде как все, кто не из криокамеры давно на /run перешли, не?
> для mount points ?! в /run кладут вроде как содержимое старого /var/run.
> не ?
> ps. я видимо еще в криокамеры - у меня ничего новее RHEL6
> нету. а туда эти ново введения еще не дошли.И часто в RHEL вы используете автомонтирование в /media? И часто ли там что остается после отмонтирования, чтобы костыли с tmpfs городить?
> И часто в RHEL вы используете автомонтирование в /media? И часто ли там что остается после отмонтирования, чтобы костыли с tmpfs городить?При использовании десктопа - оно постоянно туда. и регулярно там остается мусор.
Но вы правды - я это использую крайне редко..Но скорее всего тут больше вопрос о том что на ssd лишние записи убивают его, а эти каталоги никому не нужны.
>> И часто в RHEL вы используете автомонтирование в /media? И часто ли там что остается после отмонтирования, чтобы костыли с tmpfs городить?
> При использовании десктопа - оно постоянно туда. и регулярно там остается мусор.
> Но вы правды - я это использую крайне редко..
> Но скорее всего тут больше вопрос о том что на ssd лишние
> записи убивают его, а эти каталоги никому не нужны.Наверное у вас и журнал отключен, чтобы жизнь SSD продлить? )
>>> И часто в RHEL вы используете автомонтирование в /media? И часто ли там что остается после отмонтирования, чтобы костыли с tmpfs городить?
>> При использовании десктопа - оно постоянно туда. и регулярно там остается мусор.
>> Но вы правды - я это использую крайне редко..
>> Но скорее всего тут больше вопрос о том что на ssd лишние
>> записи убивают его, а эти каталоги никому не нужны.
> Наверное у вас и журнал отключен, чтобы жизнь SSD продлить? )у меня нет SSD. меня вполне устраивает обычный HDD. Нет таких задач где seek time мне испортил бы все.
PS. SSD используемый под журнал у ext4 умирает через пол года серьезной нагрузки на эту FS. Проходили на практике. после чего поставили туда зеркало из 2х hdd и скорость операций не сильно упала.
Зачем так сложно? Я на openSUSE банально редактирую fstab, а systemd сам его парсит
У RedHat богатый опыт сопровождения линукса на ответственных местах, где за сбой могут хорошо попасть на деньги или даже на человеческие жизни. Со временем накопилась статистика, что все эти портянки инициализации слишком геморное дело, особенно при обновлении на новые версии, особенно если автор предыдущей портянки давно уволился. Админам конечно это нравится - создает клан "назаменимой элиты", потому как чуть что - будете разбираться сами в том как этот код работает. Ведь писали его 2 поколения админов, строка за строкой, год за годом, отдаляясь от оригинальных общепринятых скриптов.Что то с этим всем делать надо, иначе у каждой более менее большой конторы с > 2000 узлов будет практически свой линукс, и мало кто поможет из саппорта, ибо простота и прозрачность километров баш кода проста только для ее автора и то в течении месяца а то и меньше.
Были разные идеи, остановились на systemd. Похоже, RHEL 7 будет на нем основан. Собственно это и есть главная интрига - если попадет в 7 как дефолтная то значит прошла кучу проверок на знаменитых редхатовских тестах, и будет сопровождаться очень серьезно настроенными парнями которым не фкантактик пускать а биржу бесперебойно обеспечивать и прочие авианосцы. Выяснится это скоро, так как бета выйдет примерно в момент выпуска Fedora 19 (месяц-два).
>[оверквотинг удален]
> большой конторы с > 2000 узлов будет практически свой линукс, и
> мало кто поможет из саппорта, ибо простота и прозрачность километров баш
> кода проста только для ее автора и то в течении месяца
> а то и меньше.
> Были разные идеи, остановились на systemd. Похоже, RHEL 7 будет на нем
> основан. Собственно это и есть главная интрига - если попадет в
> 7 как дефолтная то значит прошла кучу проверок на знаменитых редхатовских
> тестах, и будет сопровождаться очень серьезно настроенными парнями которым не фкантактик
> пускать а биржу бесперебойно обеспечивать и прочие авианосцы. Выяснится это скоро,
> так как бета выйдет примерно в момент выпуска Fedora 19 (месяц-два).какого тогда они на upstart неостановились?
>Что то с этим всем делать надо, иначе у каждой более менее большой конторы с > 2000 узлов будет практически свой линуксОн и сейчас есть и после будет. Задачи у всех разные.
> Админам конечно это нравится - создает клан "назаменимой элиты"В смысле, умение прочитать полсотни строк на стандартном языке оболочки, поправить при необходимости наживую и при необходимости же обратиться к съевшему на sh-программировании собаку более крупной породы за консультацией для придания правке элегантности уже считается "элитарностью"?
Серьезно, там где "за сбой могут хорошо попасть на деньги или даже на человеческие жизни" к администрированию систем подпускают того, кто это не умеет?
Во жесть. Использование обычного инструмента админа (shell) уже считается элитарностью? У вас, системдшников, скорость умение скопировать файл в консоли станет элитарностью.
> У RedHat богатый опыт сопровождения линукса на ответственных местах,
> где за сбой могут хорошо попасть на деньги или даже на человеческие жизни.Я тут уже как-то показывал фото упавшего по сегфолту при отвалившемся (вытащенном) корне со словами "sysvinit себе такого у меня не позволяет".
Шляпники от mission critical отходят как раз со всеми этими MSDN-образными наворотами вдесятеро более сложного кода ради "упрощения для пользователя" вдвое.
а на фига в gentoo пиарят тупой open.rc? юзаю xxxx - потребности не вижу
пруфы на пиар (множество новостных постов) и на двухсотую версию дайте пожалыста.
Никак. Udev теперь
часть systemd. А consolekit умер. Единственный его продолжатель (по функциям) - systemd-logind. Который, кстати, будет использоваться в новых релизах убунты.
> этот сыстемд? неужто на нём свет таким серьёзным клином сошёлся,Объясняем: как бы не ворчали старперы, а systemd умеет работать с фичами линуха. И таки натуорально ими управлять. Нет, спору нет, какой-нибудь LXC контейнер при сильном желании можно слепить и без него. Или там KVM виртуалку запустить. Но будет хорошо, если менеджер системной инициализации будет в курсе актуальных фич системы и будет в состоянии это пнуть без подстановки ему двух килограммов отборных костылей.
>И таки натуорально ими управлять.Вот с этим предложением я полностью согласен! :)
Старик Фрейд - кстате тоже :)
Что вы вообще делаете в Линуксе, если после целой статьи объяснений задаёте такие тупые вопросы??
в дебиан уже systemd ?
в 8 точно будет
в wheezy набери apt-get install systemd
да почитай http://wiki.debian.org/systemd
у меня для доступа к клиентам создано порядка 20 openvpn подключений.
Когда мне они нужны. раньше я запускал их просто
sudo /etc/init.d/openvpn start vpn1
sudo /etc/init.d/openvpn start vpnN
в любой комбинации
с systemd этот процесс стал ммммм непрозрачным - я теперь помимо конфига еще должен и unit файл делать 8-(
> sudo /etc/init.d/openvpn start vpn1
> sudo /etc/init.d/openvpn start vpnN
> в любой комбинации
> с systemd этот процесс стал ммммм непрозрачным - я теперь помимо конфига
> еще должен и unit файл делать 8-(А /etc/init.d/openvpn исключительно силой мысли возник? :)
ps. openvpn@vpn1 openvpn@vpnN
> в wheezy набери apt-get install systemd
> да почитай http://wiki.debian.org/systemdМожет сперва почитать? ;-)
зачем мне его к wheezy прикручивать? Мне как пользователю он нафиг не сдался. Если в дебиане его запилят за 2 года,то буду юзать
А есть ли разница для хомячкового пользователя десктопного Линя, системд там или что-то другое?
Есть. Тк компьютер запустится быстрее. И упавшие демоны перезапустятся
с чем комп запустится быстрее, и с чем демоны перезапустятся? с systemd?
> с чем комп запустится быстрее, и с чем демоны перезапустятся? с systemd?Юзер не должен знать, что такое демоны. Просто быстрее :)
Быстрее! Выше! Сильнее!
> Быстрее! Выше! Сильнее![trolling]
И в унитаз
[/trolling]
...А комп все запускался и запускался, а демоны перезапускались все быстрее и быстрее, а Путин все играл на пианино...
> Есть. Тк компьютер запустится быстрее.Сынку, инициализация RAID контроллера занимает больше времени чем загрузка ОС. Перестанешь быть админом локалхоста, убедишься сам
> И упавшие демоны перезапустятся
Перезапустятся и снова отвалятся из за например неконсистентной бд? А может дополнительно её порушат? Упавший сервис это уже повод для беспокойства, как чрезвычайная ситуация. Я такие могу за 12 лет по пальцам одной руки пересчитать
> Сынку, инициализация RAID контроллера занимает больше времени чем загрузка ОС.Расскажи мне еще про скорость инициализации RAID-контроллера на виртуальных машинах.
>> Сынку, инициализация RAID контроллера занимает больше времени чем загрузка ОС.
> Расскажи мне еще про скорость инициализации RAID-контроллера на виртуальных машинах. Если я запускаю 10 виртуальных машин RAID-контроллер будет в каждой инициализироваться или только в первой?
>>> Сынку, инициализация RAID контроллера занимает больше времени чем загрузка ОС.
>> Расскажи мне еще про скорость инициализации RAID-контроллера на виртуальных машинах. Если я запускаю 10 виртуальных машин RAID-контроллер будет в каждой инициализироваться или только в первой?А вас 3 секунды увеличения скорости загрузки виртуалок спасут от чего-то? Интересно от чего же? Я их обычно запускаю и просто забываю о них.
> А вас 3 секунды увеличения скорости загрузки виртуалок спасут от чего-то? Интересно
> от чего же? Я их обычно запускаю и просто забываю о
> них.Бывает, что каждая секунда простоя дорога. Или, например, распределенное приложение крутится на виртуалках и при необходимости стратует дополнительная виртуалка, которая берёт часть нагрузки на себя, а при снижении нагрузки выключается. В этом случае время загрузки тоже важно.
>Бывает, что каждая секунда простоя дорога.В каких именно отраслях так бывает? Почту шеф не получит? Почта сама по себе не instant, секундой больше, секундой меньше - пофиг. Ваш корпоративный сайт не откроется? Тому, кому нужно будет на него прити, придет в любом случае. Сервисное обслуживание дата-центра слоуд-провайдера? Дык о таких вот случаях обычно клауд-провайдеры предупреждают заранее и делают себе временную вилку как минимум в 30 минут. Ну давайте, расскажите же в каких таких случаях 3 секунды - критичны.
> каких таких случаях 3 секунды - критичны.На атомных электростанциях например, в системе навигации истребителя.
Может туда поставить systemd ?
> На атомных электростанциях например, в системе навигации истребителя.
> Может туда поставить systemd ?Ставь скорее?? </зачем спрашиваешь, да>
>> каких таких случаях 3 секунды - критичны.
> На атомных электростанциях например, в системе навигации истребителя.Там критично не время загрузки, а время реакции системы. Не подменяйте понятия. Да и сомневаюсь я что в таких отраслях используют систему общего назначения. Насколько помню лет пять назад там что-то типа QNX работало в основном (как сейчас дела - не в курсе)
> Там критично не время загрузки, а время реакции системы.Время *гарантированной* реакции системы, точнее. Хотя отдельные уникумы и J2ME пихали.
>> каких таких случаях 3 секунды - критичны.
> На атомных электростанциях например, в системе навигации истребителя.При тепловой постоянной времени ТВЭЛов порядка десяти секунд или на скорости в мах-другой?
> Может туда поставить systemd ?
Скотчем примотать только не забыть. Всё-таки критично...
>> Сынку, инициализация RAID контроллера занимает больше времени чем загрузка ОС.
> Расскажи мне еще про скорость инициализации RAID-контроллера на виртуальных машинах.Вас, г@вновиртуальщиков что, как икру уже мечут? Прикинь - есть ВАЛОМ систем, где виртуализация В ПЕНЬ НЕ НУЖНА И ОСЬ РАБОТАЕТ НА ГОЛОМ ЖЕЛЕЗЕ. Называют их еще bare metal. Погугли - удивишься. И, кстати, как ты думаешь, на чем крутится твоя система ВИРТУАЛИЗАЦИИ, м?
>>> Сынку, инициализация RAID контроллера занимает больше времени чем загрузка ОС.
>> Расскажи мне еще про скорость инициализации RAID-контроллера на виртуальных машинах.
> Вас, г@вновиртуальщиков что, как икру уже мечут? Прикинь - есть ВАЛОМ систем,
> где виртуализация В ПЕНЬ НЕ НУЖНА И ОСЬ РАБОТАЕТ НА ГОЛОМ
> ЖЕЛЕЗЕ. Называют их еще bare metal. Погугли - удивишься. И, кстати,
> как ты думаешь, на чем крутится твоя система ВИРТУАЛИЗАЦИИ, м?Ты главное не нервничай. Ну и конечно же никто не будет с тобой спорить, что ты умный, а в RedHat одни идиоты сидят.
> Есть. Тк компьютер запустится быстрее.С этого места поподробнее. За счет чего?
> И упавшие демоны перезапустятся
Разбор причины падения, алгоритм расскажи.
> Есть. Тк компьютер запустится быстрее. И упавшие демоны перезапустятсяНе запустится и не перезапустится. Те же мифы о системд, только в профиль.
Никакой разницы никто не увидит пока не начнет че-то настраивать или писать свои скрипты.
>компьютер запустится быстрее.брехня, разница если и есть - то минимальная(обычно системдшные гетзефакс приводят данных с ssd и кучей отключенных сервисов)
В реале же будем иметь загрузившийся рабочий стол, которым ещё некоторое время пользоваться нельзя (привет, шиндовс!)
>И упавшие демоны перезапустятся
если демон падает - это баг
> брехня, разница если и есть - то минимальная(обычно системдшные гетзефакс приводят
> данных с ssd и кучей отключенных сервисов)У меня sysvinit на быстром ssd грузит нужное примерно за ту же секунду. Складывается дольше, чем недавние systemd, факт (правда, это в основном в тестовых виртуалках наблюдаю).
А есть ли разница, что хорошо/плохо хомячковому пользователю? Он по определению балласт.
> А есть ли разница, что хорошо/плохо хомячковому пользователю? Он по определению балласт.Тебе балласты уже три минуса набалластили :)
> Тебе балласты уже три минуса набалластили :)И кому с этих минусов/плюсов холодно или жарко? Ну, кроме поставивших их деточек. :-)
Кроме деточек есть и другая крайность. Старперы которые не признают ничего нового, полагая что рассекать по скоростному автобану на привычной кляче - сойдет, типа.
> Кроме деточек есть и другая крайность. Старперы которые не признают ничего нового,
> полагая что рассекать по скоростному автобану на привычной кляче - сойдет, типа.Ты прав. Только розовые пони спасут ваши афтобаны!
PS: "Писец планете :(" (С)Космические яйца
> Кроме деточек есть и другая крайность. Старперы которые не признают ничего нового,
> полагая что рассекать по скоростному автобану на привычной кляче - сойдет,
> типа.Милый друг, если ты по-поводу Х vs остальное, так проблема в том, что "привычная кляча" - это все остальные оконные системы. :-) Извини, но, блин, ни одна, кроме Х, не осилила замену WM без переписывания кода. А про возможность смены тулкита без перекомпиляции тут и речи нет. :-)
А что Хы тормозят - так железо подрастёт, всё и наладится.
> А что Хы тормозят - так железо подрастёт, всё и наладится.И так последние двадчать лет.
>> А что Хы тормозят - так железо подрастёт, всё и наладится.
> И так последние двадчать лет.Дайте же мне ещё этих тормозящих иксов!
/usr/bin/X
> /usr/bin/Xчо жать, чтобы тормозило?
>> /usr/bin/X
> чо жать, чтобы тормозило?Спусковой крючок.
>> Кроме деточек есть и другая крайность. Старперы которые не признают ничего нового,
>> полагая что рассекать по скоростному автобану на привычной кляче - сойдет,
>> типа.
> Милый друг, если ты по-поводу Х vs остальное, так проблема в том,
> что "привычная кляча" - это все остальные оконные системы. :-) Извини,
> но, блин, ни одна, кроме Х, не осилила замену WM без
> переписывания кода. А про возможность смены тулкита без перекомпиляции тут и
> речи нет. :-)
> А что Хы тормозят - так железо подрастёт, всё и наладится.7 лет использую иксы - что-либо тормозило только 2D на легаси версиях проприетарных нвидиашных дров, в остальном всё ок
> Кроме деточек есть и другая крайность. Старперы которые не признают ничего нового,
> полагая что рассекать по скоростному автобану на привычной кляче - сойдет,
> типа.Ой, да хватит мольиться на НОВОЕ как на идол, не учитывая других важных факторов - стабильности и архитектурной зрелости решения. Кроме того, не нужно превращать стремление к новизне в фетиш, тем более если необходимость в этой новизне сомнительна.
Как ни странно - есть. Смотри количество пользователей fedora и android.
А пользователи - это чистые баблосы. Galaxy S4 - 10 млн на старте продаж.
Как ты думаешь если бы на Galaxy S4 была fedora - сколько их бы продали?
>> Как ты думаешь если бы на Galaxy S4 была fedora - сколько их бы продали?если бы samsung поставил бы fedora на Galaxy - столько же. покупателю пофиг что стоит на работающем девайсе
> если бы samsung поставил бы fedora на Galaxy - столько же. покупателю
> пофиг что стоит на работающем девайсеСтранно тогда, что Red Hat сейчас не рулит и даже не педалит. Наверное они забыли заключить договор с Samsung на этот год. А может Samsung, из своего опыта опродаж, знает чего делает?
Добавлю, если покупателю пофиг, почему не гребут виндовс фоны. Похоже, что не пофиг.
> Добавлю, если покупателю пофиг, почему не гребут виндовс фоны. Похоже, что не
> пофиг.Все очень просто. Еслть неофициальная договоренность о разделе рынка. А стоять должно то, что вчера видел в рекламе.
> Все очень просто. Еслть неофициальная договоренность о разделе рынка.Да-да, и пакт Молотова-Риббентропа. Помним, скорбим.
Совершенно никакой разницы. Собственно как и какое ядро в его системе, даже все равно какой дистрибутив он использует. Главное это что он может в ней делать, какие пользовательские приложения есть и на сколько просто их получить и т.п.В общем надеюсь мысль понятна.
Да,а что вы спрашиваете?
Код действительно хорош
так хорош что можно с дебиана спрыгивать на "Ubuntu Server 13.10"
> так хорош что можно с дебиана спрыгивать на "Ubuntu Server 13.10"Именно 13.10? Он же не LTS? Или ненависть к поттерингу сильнее здравого смысла? Во что с людьми стадный инстинкт делает :)
Ага, даже на скобочках экономят, просто чудесный код:
if (prctl(PR_GET_SECUREBITS) != sb)
if (prctl(PR_SET_SECUREBITS, sb) < 0)
return -errno;
Не понял - что не так в этом коде. Вполне нормальный сишный код, вроде все при нем. Чего не нравится то? oO
> Не понял - что не так в этом коде. Вполне нормальный сишный
> код, вроде все при нем. Чего не нравится то? oOТак-то однако понятнее будет
if (prctl(PR_GET_SECUREBITS) != sb) {
if (prctl(PR_SET_SECUREBITS, sb) < 0) {
return -errno;
}
}или вот эдак
if (prctl(PR_GET_SECUREBITS) != sb)
{
if (prctl(PR_SET_SECUREBITS, sb) < 0)
{
return -errno;
}
}Мониторы-то чай не из конца семидесятых у писателей этого кода, на них теперь поболе чем 25х80 умещается.
А ты уверен что тот синтаксис только из-за монитров придумали?
> А ты уверен что тот синтаксис только из-за монитров придумали?От убогости мониторов, для экономии строчек - их всего-то 25 было.
> Мониторы-то чай не из конца семидесятых у писателей этого кода, на них
> теперь поболе чем 25х80 умещается.Фокус зрения у человека особо не изменился с конца семидесятых.
ps.
if prctl(PR_GET_SECUREBITS) != sb:
if prctl(PR_SET_SECUREBITS, sb) < 0:
return -errno:)
Мило, но не собирается (изменено для простоты, влиять вроде не должно). Или и не планировалось?
$ echo '
> int main (void)
> {
> if sizeof(int) != 3:
> if sizeof(int) < 0:
> return 1
>
> return 0;
> }
> ' | gcc -x c -<stdin>: In function ‘main’:
<stdin>:4:8: error: expected ‘(’ before ‘sizeof’
> Мило, но не собирается (изменено для простоты, влиять вроде не должно). Или
> и не планировалось?. . .
> <stdin>: In function ‘main’:
> <stdin>:4:8: error: expected ‘(’ before ‘sizeof’
Буратино шагнул далеко вперёд по пути прогресса - сделал необязательными не только фигурные, но и круглые скобки. Респект за находчивость !
:-))))))))))
> Мило, но не собирается (изменено для простоты, влиять вроде не должно). Или и не планировалось?Это были рассусоливания насчёт сравнения C-синтаксиса и python-синтаксиса, и вечная проблема первого - куда замастерячить эти (ненужные) { } :)
Я думал, что очевидно, что это python. :)
> или вот эдак
>
> if (prctl(PR_GET_SECUREBITS) != sb)
> {
> if (prctl(PR_SET_SECUREBITS, sb) < 0)
> {
> return -errno;
> }
> }
>или даже так:
/*
* @var int getSecureBits secure bits
*/
int getSecureBits = prctl(PR_GET_SECUREBITS);if (getSecureBits != sb)
{
/*
* @var int getSecureBits secure bits to set
*/
int setSecureBits = prctl(PR_SET_SECUREBITS, sb);if (setSecureBits < 0)
{
/*
* @var int errorCode error code
*/
int errorCode = errno;return errorCode;
}
}
> ... systemd потребляет больше ресурсов, чем sysvinit, компенсируется задействованием данных ресурсов для учёта большей информации о сервисах, а более детализированный контроль состояния позволяет администратору более глубоко контролировать работу служб.Читать как мантру: «Больше, большей, более»... в связке с абстрактными словами.
/lib/systemd/system/nginx.serviceникого путь не смущает?
по моему за такое надо бить, и очень больно до реанимации
как люди раскидывающие конфиги где попало могут заявлять что делают лучше?
В /lib лежат тупо все конфиги, которые ставятся с пакетами. При systemctl enable my.service создается симлинк в /etc. Такие дела,Разобраться бы не мешало, прежде чем слюной брызгать.
> Разобраться бы не мешало, прежде чем слюной брызгать.Откуда такая агрессия? Человек запостил (допустим) ошибочное утверждение, ты мог его просто поправить. Вместо этого ты начал брызгать слюной как обычный фанатик, чей фетиш поругали "неверные"
> фетиш поругали "неверные"Да просто ругателей дофига развелось. Утомили ругаться вообще не по делу. Нашли себе пугало в виде Поттеринга и им пугают. А пока ругают - пульс например превратился в мощную и фичастую звуковую подсистему, которая в нормальных дистрах проблем не создает и к тому же предлагает ряд интересных/уникальных фич, типа индивидуальных уровней громкости для разных программ, возможность заткнуть одни источники звука в пользу других (так что например плеер на мобильном девайсе может заткнуться при входящем звонке и продолжить играть когда звонок завершен, etc).
> Да просто ругателей дофига развелось. Утомили ругаться вообще не по делу. Нашли
> себе пугало в виде Поттеринга и им пугают.Это не их мысли. Они их в интернете скачали. Если они не будут говорить такими шаблонами, то им вообще не о чём будет говорить.
Это внутреняя потеря гармонии. Они не видят всей картины, видят только всё, что им показывают, они видят только то, что хотят видеть, чтобы оправдывать себя. Они недовольны, всегда и всем. Послушай их, так вообще в жизни нет ничего хорошего.
На самом деле, это в их жизни нет ничего хорошего. Они просто показывают, как в их глазах выглядит мир. Этим людям сочувствовать надо, это же инвалиды без самого жизненно важного органа.
>пульс например превратился в мощную и фичастую звуковую подсистему.Дождались таки..сколько лет ждали ? 5 или 7 ?
>>пульс например превратился в мощную и фичастую звуковую подсистему.
> Дождались таки..сколько лет ждали ? 5 или 7 ?От алсы этого так и не дождались, сколько не ждали. Хотел раньше - надо было впрягаться и слать коды или нанимать кодеров за свои кровные. Суть в том, что фичи пилятся, прогресс идёт. Что-то не устраивает - вперёд клепать код с единомышленниками. Форки никто не мешает делать. Попеноффис вон, форкнули и отлично живут, ГПЛный код куют, фичи добавляют.
>пульс например превратился в мощную и фичастую звуковую подсистемуне прошло и 10 лет, да.
>интересных/уникальных фич
которые зачастую нафиг никому не сдались
//обладатель десктопа с несколькими звуковыми/миди девайсами и нетбука, нигде пульсы нет и не нужна
> /lib/systemd/system/nginx.service
> никого путь не смущает?
> по моему за такое надо бить, и очень больно до реанимации
> как люди раскидывающие конфиги где попало могут заявлять что делают лучше?Люди, выражающие неприязнь к systemd, обычно не имеют представление о том, как он работает.
> Люди, выражающие неприязнь к systemd, обычно не имеют представление о том, как
> он работает.Люди выражающие приязнь к systemd, обычно не имеют представление о том как работает система инициализации.
>> Люди, выражающие неприязнь к systemd, обычно не имеют представление о том, как
>> он работает.
> Люди выражающие приязнь к systemd, обычно не имеют представление о том как
> работает система инициализации.Есть примеры в этом треде?
> Есть примеры в этом треде?Да. Какой-то ноним.
+ вянду в анамнезе.
> Люди, выражающие неприязнь к systemd, обычно не имеют представление о том,
> как он работает.А когда имеют представление о том, как он не работает -- то ничего по существу сказать не можете. Странное дело...
Меняем Xorg на Wayland - ведь Xorg слишком усложнён! Меняем sysvinit на systemd, ведь systemd слишком усложнён!Меняем ALSA на PulseAudio, ведь в ALSA нет сетевой прозрачности! Меняем Xorg на Wayland, ведь в Wayland нет сетевой прозрачности!
Меняем Xorg на Wayland за сложность разработки под Xorg! Меняем sysvinit на systemd несмотря на сложность разработки (отладки) под systemd, ведь конечного пользователя не волнует!
Основной плюс systemd - простота разработки, короткие скрипты! Основной минус systemd - сложность разработки, трудная отладка! Под systemd простая сложная разработка!
зеня ты опять все перепутал.
Великолепно описано! Спасибо!
Systemd os когда уже?
Тсссс, не подсказывайте ему
Инициализация -- это та вещь, которую можно чинить без компилятора...И ещё: "не клади все запуски в один systemd".
> Автор утверждает, что большинство библиотек уже активно используются такими программами, как DBus, Udev, SELinux, libcap, pcre и т.п., поэтому установка пакета приведёт к установке лишь небольшого числа этих библиотек на обычной системе (всего около 10 пакетов).Да Господи, у каждого ПО РАЗНОМУ. К примеру, у меня, на моей Slackware, нет ни DBus (только на ноуте из-за NetworkManager), SELinux, pcre вроде тоже нет. Мне гораздо более удобнее и информативнее использовать bash/tcsh скрипты для инициализации системы, а про обычные текстовые логи и говорить ничего не нужно, их можно прочитать хоть с Dos.
> скрипты для инициализации системы,Вот ты и будешь теперь себе выписывать портянки на три страницы. А остальным хватит конфига на пять строк, который проямо в комплекте с программой в лучшем случае будет. А в хучщем - пять строк я и сам накатаю. А вот то что отладка сложных частей будет чужим головняком - так это плюс. Разработчик дебиана имеет тут вполне валидный пойнт.
Вы хоть раз прочитайте "портянку". Может внезапно откроется, что функциональность пяти строк конфига реализуется в "портянке" тоже по сути пятью строками. Остальное это оформление для удобства чтения и отсутствующие в юнитах systemd возможности.
Вот смотрите, молодоц человек. Вам ниже, уже ответили, что длинные портянки это просто комменты в скриптах, отступы и т.д. для удобства чтения. Еще портянки могут вырасти из-за различных проверок существования pid-файлов перед запуском демонов и т.д. Дак я уже прям вижу твое утверждение, что в unit-файлах нету никаких проверок сущ-я pid`ов и systemd всё сам умеет. Но посмотри на это с другой стороны: при запуске sh-скрипта запускается копия /bin/sh, она выполняет скрипт и shell заверщает свою работу. Всё! Память, к-ю он занимал, освободилась. Systemd же висит в памяти всё время. Ты посмотри в top`е сколько твой init весит.
> Вот смотрите, молодоц человек. Вам ниже, уже ответили, что длинные портянки это
> просто комменты в скриптах, отступы и т.д. для удобства чтения. Еще
> портянки могут вырасти из-за различных проверок существования pid-файлов перед запуском
> демонов и т.д. Дак я уже прям вижу твое утверждение, что
> в unit-файлах нету никаких проверок сущ-я pid`ов и systemd всё сам
> умеет. Но посмотри на это с другой стороны: при запуске sh-скрипта
> запускается копия /bin/sh, она выполняет скрипт и shell заверщает свою работу.
> Всё! Память, к-ю он занимал, освободилась. Systemd же висит в памяти
> всё время. Ты посмотри в top`е сколько твой init весит.да лана :-) память сейчас дешевая - и надо же продавать роутеры с большим объемом памяти..
Это "память сейчас дешёвая" уже начинает немного доставать. На каждый возглас "у меня линукс тормозит!" слышится "купи ещё памяти". Только вот слотов для этой памяти никто не продаёт :(
> Это "память сейчас дешёвая" уже начинает немного доставать. На каждый возглас "у
> меня линукс тормозит!" слышится "купи ещё памяти". Только вот слотов для
> этой памяти никто не продаёт :(и вы тоже это заметили? что linux + KDE/GNOME уже жрут столько же сколько Windows 7/8..
Что-то DDRII нифига не дешевеет.
"Для опровержения этого аргумента был приведён отдельный документ, включающий в себя список зависимостей пакета systemd и его исполняемого файла."
потому как в стандартный объем текста, публикуемого в блоге, перечисление зависимостей не помещалось
Внимание, аналитеГи опеннета!
ну коль вы уж так ненавидете systemd, то опишите плюсы sysv?аргументы типа "100 лет работает" катят
*не катят
http://www.opennet.ru/openforum/vsluhforumID3/90371.html#107
Зачем... Есть rc. Неплохой баланс между.
> systemd слишком усложнён.
> Здесь Майкл предлагает сравнить монолитное ядро Linux с systemdС головой в порядке?
Меня не покидает смутное ощущение того, что кто-то обчитался литературой про архитектуру Windows. Может быть, даже получил на руки часть исходных кодов.
Этот "кто-то" заразился реализацией тупиковых идей MS в среде Linux. Дяде Билли это понравилось и он решил профинансировать черезжопоизацию экосистемы Linux.
Бинарные логи, бинарные конфиги, намертво приколоченная подсистема звука, шурупами привинченный композитинг... Ничего не напоминает?
Я почти уверен, что у этой истории может быть три концовки:
* поматросит и бросит
* залу^W обидится и уйдёт
* развалит экосистему Linux и, обидевшись, уйдёт.
> намертво приколоченная подсистема звукаЭэээ, это какая? И в какой ОС?
> * развалит экосистему Linux и, обидевшись, уйдёт.С людьми, которые зациклены на "свободная ОС это linux" - может быть, так и надо. Потому что они повторяют ту же самую ошибку. Не должно быть никакой linux-завязанности.
Ну по-моему после того как Linux-сообщество начало почесывать свое ЧСВ и купаться в лучах народной славы, с той же самой минуты все активные деятели подзабили на проектирование по и на его архитектуру как таковую, хотя меня терзают смутные подозрения что в виду базарного подхода архитектуры там не было с самого начала.
> Ну по-моему после того как Linux-сообщество начало почесывать свое ЧСВ и купаться
> в лучах народной славы, с той же самой минуты все активные
> деятели подзабили на проектирование по и на его архитектуру как таковую,
> хотя меня терзают смутные подозрения что в виду базарного подхода архитектуры
> там не было с самого начала.Скорее с того момента как шапка нашла путь монетизации Линукса. После чего они начали проталкивать решения выгодные им и только им. Так они больше могут контролировать..
> * развалит экосистему Linux и, обидевшись, уйдёт.Не просто развалит, а целенаправлено развалит, чтобы как можно большее число админов метнулось обратно на винды.
> Этот "кто-то" заразился реализацией тупиковых идей MS в среде Linux.Похоже, в очередной набор шляпных сотрупников попросту попал излишне богатый улов. Некоторые имена даже могу назвать, порывшись (насчёт беспарольной установки пакетов в федоре двух- или трёхлетней давности).
> чем sysvinit и занимает памяти всего на 1 мБ большеАж на целый милибайт?!1
А сможет ли кто-либо из стана "нинужно" аргументированно и по пунктам опровергнуть эту статью: http://0pointer.de/blog/projects/the-biggest-myths ?
Это опровержение по большей части декларативно.В: системд сложный
О: системд не сложныйВ: системд монолит
О: системд не монолитВ: главная задача системд скорость
О: скорость никогда не была главной задачей системди все в том же духе. Аргументов либо нет, либо они притянуты не к месту.
> Это опровержение по большей части декларативно.
> В: системд сложный
> О: системд не сложный
> В: системд монолит
> О: системд не монолит
> В: главная задача системд скорость
> О: скорость никогда не была главной задачей системд
> и все в том же духе. Аргументов либо нет, либо они притянуты
> не к месту.Понятно )
> "Весь мир прогнется под нас"... ведь так?А в чем собственно...
Не нравится systemd, не проблема:
формат service файлов известен (не нравится, можете свой придумать),
начинайте пилить свой system-init-d, под этот формат (или свой),
для всех ОС (начиная с CP-M) и заканчивая Вашей TRUE OSЗаодно и нам хорошо будет, будем иметь альтернативу (и потролить, конечно же ;)
Удачи!
Судя по аргументации - Ленарт. Их что, клонируют?
Троллинг:Вконтакте есть группа systemd
Открытая группа
Описание:Ниже выписаны названия музыкальной группы. Набравшее больше лайков станет новым. Сейчас группа называется "Мудаки и бутылка "Хаски".
Местоположение:Россия
про "понятный код"Ю он документирован это плюс. но ...
int exec_spawn(ExecCommand *command,
char **argv,
ExecContext *context,
int fds[], unsigned n_fds,
char **environment,
bool apply_permissions,
bool apply_chroot,
bool apply_tty_stdin,
bool confirm_spawn,
CGroupBonding *cgroup_bondings,
CGroupAttribute *cgroup_attributes,
const char *cgroup_suffix,
const char *unit_id,
int idle_pipe[2],
pid_t *ret)здравствуй вындовс???
Вот и я того-же побаиваюсь...
Они бы еще "язык" 1С для своего systemd использовать решили для пущей важности_))