Ubuntu продолжает интеграцию компонентов systemd

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

а поклонник «сильной личности», что ли

если бы я делал новую платформу, то поступал бы точно так же. Помойму Стив Джобс неукоснительно следовал этим путем, ровно как и его менеджеры (например, Гай Кавасаки - см. книгу The Macintosh Way, The Art Of The Start).

ИЧСХ все эти люди могут пойти и запилить свой собственный дистрибутив, со своей собственной системой инициализации, набором патчей, итп, как им будет угодно.

это такой троллинг

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

Ну так у них это всё уже есть, а герр Поттеринг всё не унимается и зачем-то пытается донести до них свои гениальные идеи. Зачем? У него есть федорка с неплохой пользовательской базой, это вполне достаточная песочница. Но нет же, он прямо на г*но исходит, когда другие разработчики используют решения, отличные от systemd :) Особенно это касается Ubuntu.

, а герр Поттеринг всё не унимается и зачем-то пытается донести до них свои гениальные идеи.

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

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

Но нет же, он прямо на г*но исходит, когда другие разработчики используют решения, отличные от systemd :) Особенно это касается Ubuntu.

пруфы, ссылки? Поцеринг врывается в офис Каноникла и заявляет: «с утра вы будете юзать мое поделие, склонитесь, жалкие рабы!»

Главные ненужные поделия Linux-сообщества объединились

Диванные теоретики на марше.

Отлично. Значит адекватность у тебя есть.

Какой у тебя удобный критерий адекватности - адекватен тот, кто соглашается с твоим мнением.

У тебя Consolekit для раздачи прав на устройства не используется, а разделение комплектов сделано вручную написанием конфигов для иксов - я прав?

да

Причем даже Canonical хотят портировать logind, несмотря на все связанные с этим проблемы, а не доделывать Consolekit - как думаешь, почему?

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

Впрочем, пример с journald и бинарными логами говорит о том, что если на Поттеринга серьезно надавить(со стороны RedHat к примеру), то его решения аннулируются. Так что у Canonical теоретически есть шансы...

Какой у тебя удобный критерий адекватности - адекватен тот, кто соглашается с твоим мнением.

Вовсе нет. Адекватен тот, кто может подкрепить свои аргументы доводами и в споре - согласится снять свои ошибочные доводы, когда ему указали на очевидное. Я так сделал в отношении поддержки embedded-like систем в systemd после предоставления адекватных пруфов из официальной документации.

Скажешь, хреновый критерий? :-)

«самое правильное решение» - пилить своего уродца, перетаскивая фичи со systemd, параллельно внедряя части этого самого systemd. Извращенцы оценят, я даже не сомневаюсь.

Но ведь systemd модульный. Леннарт тут какие-то пруфы даже давал.

да

Во-первых, это несекьюрно - пользователи имеют доступ к потокам ввода-вывода друг друга.
Во-вторых, пользователь не должен для настройки мультисита писать конфиг графического сервера. Разделение устройств должно происходить на уровне менеджера устройств - то есть udev. При этом оно должно быть удобоваримо для реализации пользовательского интерфейса - и однострочные правила /etc/udev/rules.d/72-*.rules этому требованию полностью удовлетворяют. Для минимально знакомого с консолью пользователя настройка командами loginctl attach <имя seat> <путь к устройству в базе udev> - это уже несложно, а там и GUI-фронтенд можно сделать.

Не имею ни малейшего понятия

Можно предположить, что logind написан лучше, раз проще переписать взаимодействующую с ним часть systemd, чем откапывать Consolekit.

Впрочем, пример с journald и бинарными логами говорит о том, что если на Поттеринга серьезно надавить(со стороны RedHat к примеру), то его решения аннулируются

Не знаю, о чем ты, но бинарные логи стоит использовать хотя бы ради отображения сообщений процессов сервиса в выводе systemctl status - это очень удобно и упрощает жизнь.

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

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

может подкрепить свои аргументы доводами и в споре

Это будет ппц.

А подкрепляющий аргумент это буква п или буква ц в «ппц»? :-)

Не знаю, о чем ты, но бинарные логи стоит использовать хотя бы ради отображения сообщений процессов сервиса в выводе systemctl status - это очень удобно и упрощает жизнь.

Как раз эту хрень можно было сделать и без бинарных логов

разницу в позиции улавливаешь?

ты сейчас понимаешь что ты предлагаешь тащить в другие системы udev, dbus, питон, glib итп? Оно надо? Даже если эта позиция Поттеринга и с какой-то точки зрения неправильная я не вижу особого ущерба.

хреновая у нас developer-документация на OpenRC.

у кого она хорошая? Поэтому для меня это не является критичным вопросом.

Пока суть да дело, systemd зарелизился. Пишите новость :D

То есть вы сидите в продакшене на системах типа 18 федоры?

это тут вообще ни при чём. Или ты думаешь что твои самопальные скрипты лучше чем systemd?

А если вам надо заспавнить что-то что не поддерживает системд

Написать скрипт/юнит, не? Запуск не сильно сложнее чем через rc.local. Но мы отвлеклись. Вопрос мой был «что именно ты пишешь». Если lxc то systemd уже из коробки умеет очень много, его изначально писали с оглядкой на использование внутри контейнеров. Т.е. системы с systemd на борту априори более адаптированы ко всяким контейнерам.

А если у вас vserver контейнеры... опенvz контейнеры? :D

Простые врапперы решают вопрос. Главное что запускалка и следилка за сервисами уже есть. Если нужен чрут я использую чрут.

так называемый «тру» админ. «Ненужно»

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

Ну и оно управляется утилитой, которую можно наваять на шелле при необходимости.

ну да, ну да, идеальная система. И зачем только придумали этот systemd (в нём, кстати, тоже симлинками сервисы рулятся. если ты об этом не знаешь... то ты не видел systemd вообще. в таком случае больше не пиши). Это помимо того что шелл-скрипты одно из самых печальных юникс-наследий, многим кажется что это полноценный ЯП на котором можно городить большие скрипты. Я бы сказал что C это тоже дурацкий выбор, но ничего лучше для системного программирования не придумали потому что на нём написана система.

не, ты не совсем прав нужно esocket-activation, elogind, esyslog (или как там они), при этом каждый элемент должен жить отдельно от системд/аналога + уметь старые ядра, плюс собираться компиляторами отличными от gcc, плюс работать на BSD. И уметь объединяться в Вольтрона^W e^Hsystemd, вот тогда будет всем счастье.

Боязнь dbus это твоя психологическая, а не техническая проблема.

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

А будет ли готов openrc интегрировать в себя logind?

ты очень сильно не понял, для того, чтобы использовать logind достаточно иметь в inittab не «c1:12345:respawn:/sbin/agetty 38400 tty1 linux», а logind, и иметь конфиг, всё. При чем тут openrc?

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

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

для того, чтобы использовать logind достаточно иметь в inittab не «c1:12345:respawn:/sbin/agetty 38400 tty1 linux»

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

Там этих «компонент» кот наплакал: журнал, сам системде и логинде. всьо

Там этих «компонент» кот наплакал: журнал, сам системде и логинде. всьо

Там же десятки бинарей на 16 метров.

Ну эти бинари то большей частью можно и по отдельности использовать. Я вот, например, systemd-ac-power во всяких скриптах часто использую )

Ну и сам системде все 4 метра. 16 то с ~зависимостями

это тут вообще ни при чём. Или ты думаешь что твои самопальные скрипты лучше чем systemd?

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

Написать скрипт/юнит, не?

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

Но мы отвлеклись. Вопрос мой был «что именно ты пишешь». Если lxc то systemd уже из коробки умеет очень много, его изначально писали с оглядкой на использование внутри контейнеров. Т.е. системы с systemd на борту априори более адаптированы ко всяким контейнерам.

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

Простые врапперы решают вопрос.

Дадада. Только что вы говорили про то что «А я делаю systemd-nspawn, и ничего писать не надо.»(С) Вы же только что говорили не надо. Почему вас надо было тыкать носом вот в такую простую вещь, что бы внезапно прозрели? Потому что вы реально обычный админ локалхоста плюс пары вебсерверов на гентушечке?

Главное что запускалка и следилка за сервисами уже есть.

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

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

когда нечего сказать начинают приставать к нику.

Брать себе пафосный ник при заявлениях вроде ваших - это фейспалм.

Про нужно/ненужно я уже писал, это всё субъективно.
я лучше буду админить один маленький нормальный проект чем большую «продакшн» систему

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

Ну и оно управляется утилитой, которую можно наваять на шелле при необходимости.

ну да, ну да, идеальная система.

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

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

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

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

Который мы заменяем языком конфигов юнитов системд выдуманным лично и кучей Си кода...понемаю :D

Опять вот кстати интересный момент - если глянуть в initab то вот там оно - пожалдйста. Предтеча юнитов системд. Все простое, понятное, никаких шеллскриптов хыхыхы. Но выяснилось что не очень нужное, хехе.

Я бы сказал что C это тоже дурацкий выбор, но ничего лучше для системного программирования не придумали потому что на нём написана система.

Ну вот я и говорю - как копнешь глубже, так контингент фанатов системд и обрисовывается. :D

при этом каждый элемент должен жить отдельно от системд/аналога + уметь старые ядра, плюс собираться компиляторами отличными от gcc, плюс работать на BSD

RTFM: http://0pointer.de/blog/projects/the-biggest-myths.html myths #13 and #15

Ну эти бинари то большей частью можно и по отдельности использовать

Кхм. Что вообще такое «компоненты systemd» и почему эти бинари ими не являются?

Но ведь systemd модульный. Леннарт тут какие-то пруфы даже давал.

Так «наш» леннарт потом сам же свои же пруфы и опроверг - сам же доказал что настоящий леннарт врет :D

а зачем растаскивать системд на компоненты, там полезных компонент не так и много?

Я совсем не понимаю твоей позиции в диалоге со мной, что ты пытаешься сказать или где показать что я не прав или что?

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

RTFM: http://0pointer.de/blog/projects/the-biggest-myths.html myth #24

Хотя после

И у меня *совершенно* нет желания разбиратся

я вовсе неудивлён - мало того что агрессивное невежество, так ещё и бравирует этим.

Кхм. Что вообще такое «компоненты systemd» и почему эти бинари ими не являются?

Да я и сам не знаю :D Скорее всего куски обеспечивающие основную функциональность )

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

Вся прелесть в том, что это именно «просто конфиг файлы»

RTFM: myths #13

Шикарный пример того что Леннарт болен. «системд не будет под бсд» - «это ниправда .... да, не будет, но ето ничего не и3менит1111»:

13 Myth: systemd being Linux-only is not nice to the BSDs.
Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, ...

Вся прелесть в том, что это именно «просто конфиг файлы»

Это не «просто» конфиг файлы - это очень тупые конфиг файлы, несоответствующие задаче. А потребная «непростота» достигается через добавление новых тонн си кода. ;D

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

несоответствующие задаче

Какой же задаче они не соответствуют?

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

Да, так же просто, как править инит скрипты на баше по 10 раз на дню. Скучать не будут!

пока не будет годной реализации dbus в кернел-спейсе

То есть dbus в pid 1 это ужас-ужас, а в ядре - фигня-вопрос. И после подобной когнитивной нестыковки ты ещё пытаешься утверждать, что это не твоя психологическая проблема? :-)

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

Из всех проектов, которые я видел, systemd документирован, наверное, лучше всего.

RTFM: http://0pointer.de/blog/projects/the-biggest-myths.html myth #24

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

При чем Леннарт либо дурак совсем и не знает об этом факте, любо знает и врет в стиле Микрософта :D

И у меня *совершенно* нет желания разбиратся

Договаривайте при цитировании, договаривайте. Так уже впали в истерику, что заврались вконец? :D

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

я вовсе неудивлён - мало того что агрессивное невежество, так ещё и бравирует этим.

То есть вы таки считаете что я должен ставить системд во все *мои* конфигурации и смотреть асилит или нет?

Я смотрю вы, фанаты, *реально* больные. Что характерно вы реально считаете что я должен убить кучу времени на ваше любимое говно? :D

Какой же задаче они не соответствуют?

«вот этой вот»(С)

Да, так же просто, как править инит скрипты на баше по 10 раз на дню. Скучать не будут!

Осталось системд в ядро внести. Будут не только править на Си, но и сразу в ядре. Вот заживем!

PS
Вообще говоря само то что целая толпа «админов» и «программистов» считает что Си блоб править примерно так же сложно как короткий шеллскрипт, заслуживает отдельного исследования. Какое то мрачно ужосающее сочетание ЧСВ пафоса, дремучести и желание победить в троллинге любой ценой. Вот оно похоже то самое - пребывание на ЛОР повреждает мозг :D

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

так же сложно как короткий шеллскрипт

Мне уже надоело постить инит скрипты из опенсузе в каждой теме про системде в ответ на этот аргумент ))

Вообще не понимаю, откуда эта странная идея с правкой инит скриптов берется. Будто бы кто-то этим _действительно_ занимается. Что там вообще можно править? Зачем? Ради чего?

Какое то мрачно ужосающее сочетание ЧСВ пафоса, дремучести и желание победить в троллинге любой ценой. Вот оно похоже то самое - пребывание на ЛОР повреждает мозг :D

как скажешь )

Будто бы кто-то этим _действительно_ занимается. Что там вообще можно править? Зачем? Ради чего?

Банальное исправление ошибок. Нерабочий init-скрипт tinyproxy в CentOS. Баги в инит-скрипте PowerMTA в Debian. Баги в инит-скрипте PMTA Management Console в CentOS. Баги в init-скрипте munin в Ubuntu под OpenVZ. Это то, с чем пришлось столкнуться буквально за последние три-четыре месяца.

Скрипты пишут люди, а людям свойственно ошибаться.

Баги в инитскриптах вообще не повод для обсуждения. Кстати, чем меньше простор для действий, тем меньше поводов для багов. Выделяя общее в один комплект костылей снижается простор для багоклепательства. Пример — skel, functions.sh, start-stop-daemon итп

Мне уже надоело постить инит скрипты из опенсузе в каждой теме про системде в ответ на этот аргумент ))

То есть типо в вашей сузе все ужасно .... по этому мы, так сказать, заменим длинные скрипты кодом на 4мегабайта бинарей? Так что ли? :D

Нет, по этому мы, так сказать, заменим длинные скрипты конфигурационными файлами на 10 строк, за счет выноса общей части в один из 4х мегабайт бинарей. Как-то так

Баги в инитскриптах вообще не повод для обсуждения.

И что вы этим 4.2 конкретно хотели сказать? :D

Я хотел сказать, что баги надо фиксить в апстриме, а не у себя на коленках, так что тут и говорить не о чем.

Кстати, чем меньше простор для действий, тем меньше поводов для багов

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

Да, многие вещи тривиальны, но вот например баги с разбором конфигов проще всё же исправлять, если разбор осуществляется в скрипте, а не в бинарнике.

Конечно, многое здесь зависит от QA.

Я хотел сказать, что баги надо фиксить в апстриме

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