Серия видеоуроков о systemd. Выпуск № 1

Ну не сказочный ли ... человек? Где логика? Лучше бы научился его вырезать из системы под корень, удалять зависимости, форкать и патчить софт, который на него завязан и показал остальным как это делается.. А вместо этого помог этой раковой опухоли сделать еще один шажок для поглощения ляликса..

О, перед нами типичный сопротивляст. И долго ты будешь так вырезать с каждым новым обновлением, болезный? Удачи, лол. И да, попробуй openrc, пока есть возможность :)

Господа любители systemd, прокомментируйте это. Это злобный навет, вызванный тем, что автор урока - ненавистник systemd... или это ПРАВДА?

ТС не играет никакой серьезной роли, простая говорящая квадратная голова(пруф). движуху мутят intelfx и PaulCarroty - давно известные системдфилы, активные участники каждого треда о systemd. это секрет полишинеля.

ахаха)) поцтеринг прям как путеншвайн, неужели внебрачный сын времен службы в штази?) он всегда придумает объяснение, не важно, что раньше он формулировал иначе, и неважно, что он и сам не знает что делает и куда идет, и неважно, что все ведет к коллапсу - быдлу всегда можно затереть, пипл хавает, чо.. :D без лоха и жизнь плоха)))

Remember, remember the fifth of November!

Это совершенно не то. Plumbing layer — это «кишки системы». Например, git commit — это porcelain, а git write-tree и git commit-tree — это plumbing. Первое реализовано через последнее.

Все эти «службы» не зависят одна от другой сверх необходимого. Более того, поскольку каждая из них имеет стабильный API, это всего лишь деталь реализации: никто не мешает зареимплементить так, чтобы совсем не зависело.

Поэтому нельзя говорить, что systemd «слишком много на себя замыкает».

Опять же, повторю уже неоднократно приводившийся аргумент: все компоненты systemd можно, например, раскидать по разным репозиториям. Это ничего не изменит по существу (только добавит сопровождающим головной боли), но удовлетворит все претензии про конгломерат и feature creep (т. к. формально это будут разные проекты, а то, что некоторые из них друг от друга в рантайме зависят — ну так имеют полное право).

Следовательно, все такие претензии — не что иное, как придирки.

А программы-то можно будет запускать в systemdOS? А то вдруг они все будут в виде расширений systemd.

А чего нельзя раскидать по разным репозиториям? Любой софт имеет внешние зависимости. Как-то ни о чём получается.

А программы-то можно будет запускать в systemdOS? А то вдруг они все будут в виде расширений systemd.

Ну а сейчас их с таким же успехом можно назвать расширениями линукса.

Отрывок из какого-то произведения, неизвестного мне :) А вообще на дворе 19 ноября.

ну а чем же тогда расширение линукса отличается от расширения системд. Зачем нужно было городить системд?

http://bit.ly/1Hh6mRg

Для прояснения ситуации кто-нибудь кто может английскою задайте вопрос Поцтерингу по каким конкретно критериям программа может попасть в расширения системд. Вот я прочитал 30 ответов поцтеринга и ответ на этот вопрос не нашел.

ну а чем же тогда расширение линукса отличается от расширения системд. Зачем нужно было городить системд?

Ты у меня спрашиваешь??? По мне так лучше бы они из линукса повыбрасывали тяжёлое юниксовое наследие, сделали бы нормальный АПИ по типу NT-шного хотя бы, ну так по мелочи переделали бы уже всё по-современному. А то если намазывать «кишки» (как там выше предложили термин) на это говно мамонта - то ничего приятного глазу пользователя не получится.

intelfx,

Может нам meetup организовать по systemd? Не агитационный, а именно такой ознакомительный: одну вводную обзорную лекцию и несколько интересных практических примеров, чего и как можно нахимичить если захотеть.

Можно FAQ по каким-нибудь частым use-case: 1) добавить swap, 2) добавить монтирование внешнего диска, 3) запуск чего-нибудь при логине... и какие-то экзотические примеры вживую продемонстрировать.

Я дальше написания базового юнита уже и не в курсе, что там нового. И мне кажется было бы интересно.

Ясно, фаны системд просто вантузоиты и линуксхейтеры в ондом флаконе. А чем отличается и чем ондо лучше другого просто объяснить не могут. Бывает, «не знаю», но линукс не навижу это тоже аргумент.

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

Вообще, мы хотели в следующих выпусках (помимо того, что написать-таки тезисы и следовать им, а не как сейчас) именно так и сделать: в самом начале выпуска ставить произвольную задачу и дальше уже рассказывать, как её достигать. Что-то вроде «а сейчас мы расскажем, как писать сокет-активирующиеся демоны» (например).

А организовать meetup будет вообще замечательно.

Можно FAQ по каким-нибудь частым use-case

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

Ясно, фаны системд просто вантузоиты и линуксхейтеры в ондом флаконе.

Как ты определил?

некоторые модули являются «специальными» что бы это ни значило.

Если прочитать их список, то вполне можно понять их «особенность».

Кстати сказать, хороший пункт для обзорной лекции.

что бы это ни значило

Это ничего не значит, поскольку ты указал не на модули, а на юниты. :]

Юниты из этого списка являются специальными настолько же, насколько специальны, скажем, классы и функции стандартной библиотеки языка программирования. Ничто не мешает определить свои, дополнительные.

Докладческий скилл - это мелочи, знание предмета решает. И у вас оно есть.

Я попробую узнать какие у нас есть варианты с местом и временем. И пожалуй надо будет ограничиться относительно небольшой аудиторией, не больше 50 человек, чтобы интересно получилось, вопросы было удобно задавать и т.п.

Если системе изначально требуются исключения - это не система, это непродуманная поделка. В практическом применении это значит, что такая система не позволит пользователям реализовать кастомный функционал поскольку его можно реализовать только как специальный модуль (например bluetooth.target - а если пользователь хочет свой аналог блютутха но для СиБи-шной радиостанции?). Ну и опять же - зачем тратить время своей жизни на попытки выискать смысл в горе костылей, наваленных каким-то неприкрытым п-сом в наш линупс?

Ничто не мешает определить свои, дополнительные.

Почти ничто... Если бы ты сходил по ссылке или просто сделал себе `man systemd.special', то тебе было бы явлено, что: «A few units are treated specially by systemd. They have special internal semantics and cannot be renamed» - т.е. они прибиты к системде гвоздями, по имени.

И пожалуй надо будет ограничиться относительно небольшой аудиторией, не больше 50 человек, чтобы интересно получилось

Да там от десяти человек и выше - разницы уже нет, всё равно в очередь придётся становиться чтобы отпинать докладчика.

Нельзя обобщить всё. Система спокойно позволит «реализовать дополнительный функционал», поскольку bluetooth.target не является каким-то особенным юнитом: он является частью API, поскольку на него ссылаются стандартные udev-правила.

Я вполне могу показать, как реализовать аналог bluetooth.target для произвольного класса устройств (там показывать-то нечего), но, поскольку

Ну и опять же - зачем тратить время своей жизни на попытки выискать смысл в горе костылей, наваленных каким-то неприкрытым п-сом в наш линупс?

, можно сделать вывод, что ты просто пришёл потроллить и ответ на твой вопрос тебя не интересует.

Нельзя обобщить всё.

Что именно в данном случае нельзя обобщить? Вместо того, чтобы обслуживать модули специальным образом по их имени нельзя просто забить в синтаксис параметров модулей возможность определения способа обработки?

ты просто пришёл потроллить и ответ на твой вопрос тебя не интересует.

Ну, как минимум ты прав в том, что твой ответ на риторический впрос меня не интересует.

Твои слова не имеют смысла, поскольку речь идёт не о модулях, а о юнитах (на что уже было указано).

на риторический впрос

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

Способ обработки у юнита типа target одинаковый. У него разный набор заранее заданных зависимостей. Ты можешь сколь угодно много кастомных target-юнитов насоздавать и они все будут точно так же обрабатываться.

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

Твои слова не имеют смысла, поскольку речь идёт не о модулях, а о юнитах (на что уже было указано).

Не вижу смысла в твоих словах. Поскольку в русском языке слово «юнит» как-то отсутствует, то я его перевёл как «модуль». Если это неправильный перевод, то он всё равно не лишает смысла сказанное. Просто вместо слова «модуль» подставь в текст то, что тебе больше нравится.

Неужели вопрос «а если пользователь хочет свой аналог блютутха но для СиБи-шной радиостанции?» является риторическим?

А как бы ты его охарактеризовал? Неужели ты думаешь кто-то из присутствующих в самомо деле планирует создать аналог блютутха но для СиБи-шной радиостанции?

Ты тоже не читал документацию?

В предыдущем ответе я отвечал на предыдущую версию твоего сообщения, соответственно пропустил вот это:

говорить что-либо дальше я не буду.

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

Этот перевод может быть сколь угодно правильным (в чём я сомневаюсь), но он не общеизвестен.

Впрочем, подставим «юнит» вместо «модуля».

Вместо того, чтобы обслуживать юниты специальным образом по их имени

От имени юнита способ его обработки не зависит. Документация гласит: «They have special internal semantics and cannot be renamed». Семантика ≠ способ обработки.

Неужели ты думаешь кто-то из присутствующих в самомо деле планирует создать аналог блютутха но для СиБи-шной радиостанции?

Я могу такое допустить. Например, задача может звучать как «выполнять произвольный набор действий при подключении любого устройства, классифицируемого как радиостанция».

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

На всякий случай:

Target units do not offer any additional functionality on top of the generic functionality provided by units. They exist merely to group units via dependencies (useful as boot targets), and to establish standardized names for synchronization points used in dependencies between units.

Только гомиксы!

Не-не-не, давайте тогда лучше лесбиксы.

От имени юнита способ его обработки не зависит.

А мы с Поттерингом думаем иначе, при том он это чётко написал в самом начале документа, на который я сослался :)

На всякий случай:

На всякий случай: "..treated specially by systemd. They have special internal semantics.."

Советую перестать шланговать и/или подучить английский. «To treat» = «рассматривать», «относиться», а не «обрабатывать».

Более того, вторым предложением в той же самой доке указано, в чём конкретно заключается «особое отношение»: оно заключается в заранее заданной семантике. Про способ обработки ничего не сказано.

Только гомиксы!

Не-не-не, давайте тогда лучше лесбиксы.

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

Советую перестать шланговать и/или подучить английский. «To treat» = «рассматривать», «относиться», а не «обрабатывать».

Советую перестать шланговать и хотя бы попытаться подумать о том, что означает «рассматривать», «относиться» в отношении системы, которая интерпретирует эти гомиксы.

Второй абзац моего сообщения ты проигнорировал. Ну что же.

Спокойной ночи.

Гадание по Google Translate как способ ведения технической дискуссии.

И тебе спокойной ночи.

Да какая же это техническая дискуссия. Техническая дискуссия в этом треде закончилась с первым комментарием.

Не планируете ли изучить в какой-нибудь мере OpenRC и сравнить с systemd?

как ты предлагаешь сравнивать систему инициализации с… этим…?

Советую перестать шланговать и/или подучить английский. «To treat» = «рассматривать», «относиться», а не «обрабатывать».

Уж не позорился бы, «учитель»...

treat
1. гл.
1) ...
2) обрабатывать, подвергать действию
3) ...
4) (treat smth. as) относиться (к чему-либо определённым образом), трактовать, рассматривать

Соответствующая статья на en.wiktionary.org не указывает данного значения. Только «treat as» в значении «рассматривать» или «treat with» в значении «обрабатывать чем-л.», что нерелевантно.

Так или иначе (спишем на несовершенство вики), второй абзац моего ответа остаётся в силе.

Сбылась мечта фидошников. Теперь фраза «Чтение манов с интонацией. Дорого!» не просто шутка.

С языка снял :) Демонически захохотал.

Ну чо решили то?

Есть такие кто досмотрел?