Разработчики Arch Linux начали обсуждение возможности перехода от SysV к systemd в ближайшем будущем

Объясните, что будет с K.I.S.S.?

Финита. Отныне арчег будет только вперде.

Пока я вижу что только привычки мешают

Ладно, мне тут Питер Габриэль настойчиво советует как поступить. Пощупаю этот ваш systemd на переносной системе. Вдруг, с ним, и правда, жить можно?

Вы сами сделали работу, которую systemd мог бы сделать за вас. В чём преимущество такого подхода? Плюс стоит помнить, что не фоновые сервисы будут грузится(как вы метко заметили) в нужном порядке(ваши слова). То есть линейно, по очереди. Нехорошо как-то. А systemd может запускать сразу несколько сервисов паралелльно, учитывая при этом тот факт, что некоторые из них не запустятся, если перед этим не загрузить другие сервисы. Если у вас мультипроцессорная система, или многоядерная - вы извлечёте из этого дополнительный бонус в виде радикального сокращения времени загрузки. Вы выиграете больше, чем потеряете от того, что systemd создаёт вначале план загрузки.

Сравните вес и функционал данных тулз, вместе с System V init. И systemd. И задумайтесь над тем, зачем столько инструментов задействовать для такого простого процесса, как инициализация системы. Тем более, дёргать данные приложения десятки раз на короткий промежуток времени. Если сравнить подход System V init с systemd, их можно сравнить с PHP против Node.js. Нода отрабатывает запросы асинхронно, а PHP-приложение запускается много раз для того, что-бы отработать скрипт, отдать выхлоп серверу и рипнуться. Естественно, производительность ноды будет выше, а нагрузка на ЦП, оперативу и HDD ниже. Ниже износ оборудования, больше прослужит сервачёк. Выгода для тех кто ценит своё время и деньги...

Arch - маргинальный дистр... Инсталлера нет, glibc обновляется путем камлания с бубном, теперь вот пионэры рассуждают о повышенном износе оборудования при многократнм обращении к диску вовремя выполнения инит-скриптов. В топку.

Ололо. Выключаю комп никогда, когда отхожу ненадолго - сон, надолго гибернация, если пришло новое ядро ребут. Скорость загрузки из гибернации и уж тем более сна такая что системд нервно докуривает последнюю сигарету перед суицидом.

Чувак, сообщаю страшную тайну (меня могут выследить по айпи и убить!111) существуют виртуалки для таких целей

Прочитай уже хелп к свой виртуалке и удивись…

Скорее Леннарт раскается и начнет призывать к выпиливанию systemd и pulseaudio из всех дистров. Чем школота начнет читать маны.

Вы сами сделали работу, которую systemd мог бы сделать за вас. В чём преимущество такого подхода?

Да прочитайте вы уже вики, блин!

Сравните вес и функционал данных тулз, вместе с System V init. И systemd. И задумайтесь над тем, зачем столько инструментов задействовать для такого простого процесса, как инициализация системы. Тем более, дёргать данные приложения десятки раз на короткий промежуток времени.

Опять двадцать пять... Давайте, расскажите мне, как мои процессор и жёсткий диск устареют и сломаются от того, что пару десятков раз в неделю будут гонять sed и awk. Нормальные доводы, не скопипащенные с леннартовских агитлистовок, у вас есть?

асинхронно

Ты еще скажи, что в systemd это было впервые реализовано. Городские легенды, том 2.

Да прочитайте вы уже вики, блин!

Ты это мейнтейнерам скажи.

Ты это мейнтейнерам скажи.

Вот да, кстати. Уверен, что не поможет, но попробовать надо бы.

можно, разрешаю)

Я почитал рассылку, позиция разработчиков вполне однозначна — переходить на systemd надо, потому что всё больше софта завязывается исключительно на него, а не потому что он такой крутой и весь из себя kiss — тупо по-другому не получится.

Очень интересно теперь послушать леннортобоев, которые вещали «не хотите — не используйте, кто вам мешает». Пример нагляднейший.

systemdец какой-то

Нет, пионером в данной области был upstart. А задолго до этого такую фичу запилили в Sun OS. Ну и в MacOS X.

Вики читал. Там не слова о преимуществах BSD-style init.

Использование связки велосипедов вместо одной нормальной программы - это не нормально. И не может служить премуществом. Те, кто отстаивают такой подход, просто пытаются затормозить прогрес. Зачем нужно это ретроградство?

Вот дедушка systemd. Первая реализация подобной системы init. Имеет немало плющек, характерных для его потомков launchd и systemd.

Использование связки велосипедов вместо одной нормальной программы - это не нормально. И не может служить премуществом.

Facepalm.jpg... С таким подходом вам самое место среди виндузятников.

Когда программа получает данные, изменяет их и передаёт по конвееру другой программе - это нормально. Но когда программа занимается тем, чем не должна - это не нормально. Для инициализации системы не нужен Bash. Не нужны awk, sed, gprep и прочие программы, нужные для решения многих других задач. Нужен список сервисов, файлы описывающие действия для запуска и остановки сервиса, и зависимости сервисов. Всё. Больше там ничего не нужно. Городить огромный велосипед с десятком программ нужных для его работы в зависимостях - это не нормально. Не нужно делать что-то более сложным, чем оно должно быть.

когда программа занимается тем, чем не должна - это не нормально. Для инициализации системы не нужен Bash. Не нужны awk, sed, gprep и прочие программы, нужные для решения многих других задач.

Ну давайте, приведите нам область применимости этих программ. И расскажите нам, почему их нельзя использовать для всего остального.

Данные программы работают с текстом, и текстовой информацией. Конечно, выхлоп консольных программ тоже является такой информацией. В принципе, принцип конвейера применим к любой задаче, если нужно связать много консольных программ в одну связку. Так можно систему инициализации, и продвинутый редактор текстов, да что угодно сделать просто связывая работу многих простых консольных приложений. Вот только когда такой подход уместен, а когда не очень практичен?
Но что мы в праве ожидать от системы инициализации? Удобства и простоты. Управлять сервисами при помощи одной хорошо написанной программы проще, чем при помощи кучи конфигов и скриптов. Также мы вправе ожидать минимального количества зависимостей. Задача запуска сервисов крайне проста, не нужно объединить десяток приложений и сотню скриптов, не нужно сотню раз дёргать Bash и десятки раз grep, ps и прочие приложения. Там где проще написать ворох корявых скриптов в дёрганием кучи консольных приложений(потому что производительность не важна, архитектура данного ПО нестабильна и постоянно меняется и т.п.) - надо так делать. Где важно удобство и производительность, или где есть одна чётко очерченная сфера задач, которую проще решить одним качественным приложением - ворох скриптов там не нужен. Зато поверх такого остро заточенного приложения пожно использовать скрипты для решения своих узкоспециализированных задач. Философия Unix - одна задача одно приложение. Запуск сервисов - systemd. А нужно связать своё приложение с systemd - пожалуйста, используйте скрипты и конвеер консольных приложений. Или, если скрипт пишете на приличном ЯП вроде python и Ruby, есть D-Bus. Это современный и правильный способ связи приложений. Вполне в духе философии Unix. Только сделано всё с умом, в соответсвии с реалиями 21 века.

Всвязи с появлением нового SSD заменил Arch на Chakra.

Добило конечно отсутствие инсталлера (мне жаль времени на тупые операции).
Но главное - это полная отмороженность и непредсказуемость пакейджеров Arch последние полгода.. Из прогрессивного и простого дистрибутива они упорно делают непонятное, неудобное и несовместимое ни с чем гавно.

Данные программы работают с текстом, и текстовой информацией.

Забыл мантру «вшё ешть текшт» что ли? :}

Управлять сервисами при помощи одной хорошо написанной программы проще, чем при помощи кучи конфигов и скриптов.

Сложно не согласиться. Но вот с хорошо написанными программами напряженка только. Поттеринг — это типичный админ локалоста, судя по его статьям.

А если долго его там использовать, LFS не превратится в Арч?

Не знаю. Вряд ли, если все собирать из ABS/AUR.

Я под соляркой использовал pacman, вроде от этого она арчем не стала. :)

из прогрессивного и простого дистрибутива

Поперхнулся газировкой.

Не проблема самому написать, или нагуглить pkgbild.

А кто сказал, что проблема?

Просто часто ощущаешь себя писающим против ветра.

есть D-Bus. Это современный и правильный способ связи приложений. Вполне в духе философии Unix.

Заменить гибкость в выборе транспорта на прибитый к десктопу недопротокол? Да тебя поттеринг совсем упорол, я погляжу.

переходить на systemd надо, потому что всё больше софта завязывается исключительно на него

Очень часто приходится слышать эту странную мантру. Есть ли реальные примеры прикладного софта или сервисов, которым абсолютно необходимо наличие systemd?

В рассылке упоминался gnome и его отказ от consolekit в пользу logind.

А куча софта завязана на X сервер. Это же УЖАСНО!!!11 Нужно рисовать в видеопамять, это KISS. Еще куча софта завязано на PAM. О БОЖЕ!! Это же комбайн! А сколько скриптов зависит от баша - просто страшно подумать. Мы все умрем, однозначно.

Ожидаемый пример :) Это может быть аргументом разве что для gnome-ориентированного дистрибутива. Конечно, KDE тоже подтянется, но даже так это не потянет на аргумент для смены системы инициализации.

Вообще говоря, некоторые демоны (lighttpd, mpd, syslog-ng) уже линкуются с libsystemd-daemon, но это никак не мешает им работать без поделия. На деле никакого принуждения нет, всё зависит лишь от разработчиков дистрибутива и их навыков.

А куча софта завязана на X сервер.

На иксовый протокол. И есть несколько реализаций серверов и клиентских библиотек. Это как раз хороший, годный пример как делать надо.

Еще куча софта завязано на PAM

Еще один прекрасный стандарт.

Пойнт в том, что сраный logind прикручен к конкретному сраному init'у. Но ты можешь дальше восхищаться этим чудом инженерной мысли одного криворукого карлы.

На деле никакого принуждения нет, всё зависит лишь от разработчиков дистрибутива и их навыков.

Посмотрим сколько продержится Патрег. Хе-хе. Ставлю на два года.

Я не понимаю, что запрещает сделать реиплементацию интерфейса (кроме здравого смысла). Патентных монстров там не наблюдается.

Я не понимаю, что запрещает сделать реиплементацию интерфейса

Отсутствие оного интерфейса?

Там вообще есть интерфейс и соглашения. Посмотри внимательно.

Там вообще есть интерфейс и соглашения

Да, только где пропозал FDO на эти соглашения? Это исключительно поттеровысер.

Тебе какая разница, кто конкретно создал соглашения? Интерфейс от этого лучше или хуже не становится.

То есть, комитеты по стандартизации не нужны? Мило.

А кто говорил о стандартах? Ты жаловался, что интерфейса нет.

Ну да, есть два способа решать проблемы, работающий и правильный. А где соглашение на rc, openrc, sysvinit-от-suse, sysvinit-от-бебиана, sysvinit-от-RH, upstart итд?

Станет стандартом де-факто, будет пропозал, вероятно. А может и не будет. Лучше стандарт де-факто, чем де-факто помойка.

Ты жаловался, что интерфейса нет.

По факту - нет.

ЛП его походу создает. В процессе выписывания, так сказать.

Пользователям одной операционной системы, весьма схожий подход в разработке одной достаточно важной комопоненты вроде как и не мешает. Они даже ей гордятся, вроде

А без загадок? (Туплю я в понедельник после воскресного пива ;-) ).

К ЛП одна из основных претензий - безальтернативность модулей его паравозокомбаина.

А вот написал-бы сначала графы взаимодействия модулей и интерфейсы. Пусть хоть вчерне. Тогда-бы претензий было-бы на порядки меньше.

А так - школоло-поделка наколенная. Без царя в голове - «Ален Делон, Бельмондо... Чё получится, то и получится».

Это везапно ядро линакса, да.

Графы взаимодействия? Между модулями? Но зачем? Может быть вам графы взаимодействия ПО с этим когломератом?

Это везапно ядро линакса, да.

Шутник. Или речь о «Stable API non sense»?

Графы взаимодействия? Между модулями? Но зачем? Может быть вам графы взаимодействия ПО с этим когломератом?

Чтобы выпилить бинарный лог, например. Или написать альтернативный logind без дебильных ограничений, но с гейшами и маджонгом.

Да, речь о «Stable API non sense»

Бинарый лог можно выпилить опцией в конфиге. Для того, что бы написать альтернативный logind, нужно реализовать его интерфейс. systemd не завязан на logind.

Вообще-то D-bus давно уже не прибитый к десктопу. Это системная шина. Которую можно использовать в том числе и для консольных приложений. Да и некто не предлагает убрать пайпы. Просто параллельно мы запускаем более универсальное решение. Можно даже сделать библиотеку-бридж для вводы-вывода данных в человекопонятном виде в консоль автоматически на основе данных из объектов приложения. Тогда при вызове приложения из консоли работа автоматически будет идти в привычном для каждого пользователя Unix режиме. А при работе приложений в одной упряжке через D-Bus мы сразу задействуем более быструю и удобную для связи приложений объектную модель передачи данных. Конечно объекты нужно будет приспособить к такому стилю работы, желательно что-бы они были похожи на объекты Smalltalk. Зато какой профит мы получим в итоге?

гнома там нет, так что может и обойдется. Хотелось бы почитать отзыв Пата о поцеринге, Линус вроде высказывался негативно.