Ubuntu переходит на systemd

Расслабь булки

Не знаю, говорил ли я это тебе уже, но ПНХ.

ругать Поттеринга - просто модно

скорее «богоугодно» =)

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

Для пользователя ничего не меняется. В opensuse года два назад сразу после внедрения systemd система на моём ноутбуке не загружалась, если отсутствовал wifi — но загружалась в fallback режиме с sysvinit после явного выбора его в GRUB. Теперь systemd стал взрослее, а опыта в написании модулей у сообщества больше — таких косяков не должно быть.

выдающиеся способности к бредогенерированию

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

Пардон, а это тогда что такое?

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

это привычка разбивать рпмы по одному бинарю на пакет.

Это три проблемы Фелкера, а не systemd

Это таки проблемы systemd. Одно то, что он на отдельный /usr замахивается, уже бред - это не должно волновать init вообще. Сказанное Фелкером, например, полностью соотносится с тем, что думаю я, он просто словами это красиво написал.

При этом реализация весьма стабильна даже сейчас, несмотря на
интенсивную разработку. В то время как upstart весь в багах.

upstart не гребёт под себя всё подряд, с перспективой убить sysvinit совсем, даже на серверах.

ну так в ядре-то всё гораздо монолитнее.

Ну давайте, теперь, вообще всё закопаем из-за этого.

dbus один хрен уже в ядре.

Это с каких пор?

kdbus приблизительно с 2.6.35. Вспоминал сам, могу ошибиться. И системд такой dbus уже умеет.

это привычка разбивать рпмы по одному бинарю на пакет.

Я тебе про Фому, ты про Ерёму. Дело именно в количестве бинарей. От того, что ты их в один пакет сложишь, ничего не изменится - меньше их не станет. И при обновлении, скажем, udev надо будет обновлять компонет, который, собственно, сам init. НАХРЕНА это счастье ?

чушь. journald это отдельный демон

Поверь мне, список процессов в своей системе я смотрел. Я о том, что он не выключается.

Философия, точка зрения, вода, гипотетические риски

Так можно сказать, например, про криптографию и вообще ИБ (описание способов атак), вместе с тем, гипотетические риски воспринимаются там всерьёз. А для системы инициализации, которая становится стандартом де-факто, такие риски почему-то не воспринимаются. Пока. Выйдет вот RHEL 7, будет Ъ-enterprise на него переходить, тогда-то мы и похохочем. ;)

Что касается юниксвейности, то почему-то в systemd в настройках нельзя прописать параметры, например, для setfont, который он вызывает при загрузке.

Одно то, что он на отдельный /usr замахивается, уже бред

Разумеется бред - как и всё остальное что ты пишешь про systemd. Отдельный /usr отлично работает с systemd.

при обновлении, скажем, udev надо будет обновлять компонет, который, собственно, сам init

Зачем? Если совместимость в обновлении не поломана можно обновить только udev. За этим некоторые дистростроители так их и собирают.

Отдельный /usr отлично работает с systemd.

Потому, что пока отбили. Ты просто не в курсе.

kdbus приблизительно с 2.6.35

Запустил grep, ничего не нашел. Нет dbus в ядре пока. Когда-то давно предпринималась попытка протащить, но зафейлилась. Новая реализация гораздо более здравая, но, я надеюсь, тоже зафейлится. Потом ее переделают в нормальную ФС и примут %)

kdbus приблизительно с 2.6.35

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

Если совместимость в обновлении не поломана можно обновить только udev.
За этим некоторые дистростроители так их и собирают.

Только на сколько это всё усложняет ? И как убеждаться, что они там не поломали ? Кстати, а где собирают раздельно ?

во-во... хотя они там утверждают что все мол сначала обсуждается... на конференциях и т.п... но все равно веры нет)

Потому, что пока отбили. Ты просто не в курсе.

Ага, ты поди в первых рядах наступал с баттхёртом на перевес :-D :-D А твой героизм незамеченным остался... ничего, впереди новые битвы - неси и дальше бред во имя луны :)

Ага, ты поди в первых рядах наступал с баттхёртом на перевес

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

Повторюшы :P

Да, вру. Он на 3.10 только начал запускаться без патчей вроде как.

Поверь мне, список процессов в своей системе я смотрел. Я о том, что он не выключается.

$ps aux|grep journal
root       117  0.0  0.4 192968 15736 ?        Ds   10:02   0:00 /usr/lib/systemd/systemd-journald
$ systemctl status systemd-journald.service
systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
   Active: active (running) since Сб 2014-02-15 10:02:52 VLAT; 12h ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 117 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─117 /usr/lib/systemd/systemd-journald

Зачем глупость говорить?

При этом реализация весьма стабильна даже сейчас, несмотря на интенсивную разработку. В то время как upstart весь в багах.

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

Это таки проблемы systemd. Одно то, что он на отдельный /usr замахивается

Это известная байка, к счастью, только байка. На фридесктопе специально разъясняли.

ну так в ядре-то всё гораздо монолитнее.

Ну давайте, теперь, вообще всё закопаем из-за этого.

Вот я и говорю - это проблемы Фелкера.

А как же KISS? И кому нужен этот ваш Dragora, тем более с лютым велосипедом вместо системы инициализации?

причем тут редхат который что-то монополизирует?

Или он разработал systemd ?

Ха! Кто бы сомневался.

Это известная байка, к счастью, только байка.

Увы, нет:

--enable-split-usr      Assume that /bin, /sbin aren't symlinks into /usr

Или он разработал systemd?

Да. Леннарт Поттеринг работает в Red Hat.

Это таки проблемы systemd. Одно то, что он на отдельный /usr замахивается, уже бред - это не должно волновать init вообще.

Замахивается тем, что выдаёт предупреждение, что что-то, не связанное с системой инициализации, может не работать? Почитай наконец http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken и прекрати распространять слухи.

Тут возникает один очень интересный вопрос. Я вот пишу специализированный софт, очень дорогой, и уже давно. В ТЗ было написано, что он должен работать на системах с ядром Linux, в соответствии с posix. За чей счет будет адаптация под systemd?

Почитай наконец http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Этот бред ? Думаешь, я про него не в курсе ? :-)

/sbin/shutdown есть в любом вменяемом дистрибутиве. Зачем надо дублировать функциональность?

Затем, что shutdown работает через init.

А что, /sys/class/power_supply/AC/online уже отменили? Вполне себе стандартный интерфейс, который можно прочитать любым хелпером/скриптом/whatever. Я, скорее, предпочту полагаться на неизменяемый формат данных в /sys/, нежели на костыли очередного NIH-фанатика.

Во-первых, наличие этого helper'а не мешает читать эти файлы вручную, если тебе так хочется.

Во-вторых, твоя претензия, получается, вовсе не к systemd, ибо этот отдельный helper on_ac_power существует уже достаточно давно и к systemd отношения не имеет. Его авторы тоже «очередные NIH-фанатики»? Ну а то, почему systemd включил свою реализацию существующего helper'а, я уже объяснил.

В-третьих, с чего ты взял, что формат данных в /sys неизменяемый? Вперёд читать Documentation/ABI в дереве исходных кодов ядра.

Этот бред ? Думаешь, я про него не в курсе ? :-)

За этой фразой должен следовать набор аргументов, доказывающих, что это бред. Я почему-то их не вижу. Сообщение не догрузилось, наверное :).

Все правильно, это ведь systemd конфигурируется под систему, а не система под systemd

За этой фразой должен следовать набор аргументов

Cтатья сама себе аргумент - притянутое за уши оправдание. Про опцию у configure я уже написал.

Все правильно, это ведь systemd конфигурируется под систему, а не система под systemd

Да ? Сам-то понял, что написал ? :-) Любой линукс можно поставить по-разному. systemd пересобирать всегда ? :-)

Как интересно. Кажется, пора протолкнуть переход дебиана на вяленого. :)

Чтобы мне тут долго не рассусоливать, начиная с Systemd победил в третьем голосовании по выбору системы инициализации для Debian (комментарий) и далее.

Я прямо разбежался читать столько неотфильтрованных страниц.

Простите, dmesg теперь законодательно не протоколируется, вообще ни как (здесь у Вас есть шанс ещё раз подумать о выдвинутом Вами тезисе)?

Сообщения ранней стадии загрузки не ограничиваются dmesg.

Тут man logger && man I/O redirection.

И правда, не смешно. Реализовывать это всё каждый раз, вручную переписывая каждый init-скрипт - это, конечно, намного более грамотная архитектура, нежели выделить общую функциональность в init-систему, которая эти сервисы запускает. Не говоря уже об элементарной фильтрации и всякой дополнительной информации, которую даже syslog не сохраняет, не говоря уже про перенаправление.

Сомневаюсь, что дистрибутив, который называют «самым UNIX-овым» перейдет на это говно..

Cтатья сама себе аргумент - притянутое за уши оправдание. Про опцию у configure я уже написал.

Эта опция вообще про другое: поддержка Fedora, в которой бинарники из /{,{s,usr/s}bin перенесены в /usr/bin. И значение по умолчанию этой опции определяется автоматически при генерации configure.

В статье же написано совсем про другое, и ни одного аргумента в поддержку собственной позиции ты так и не привёл.

За чей счет будет адаптация под systemd?

За твой естественно - тупые проприетарщики должны страдать и сосать. Сосать и страдать. Так что не отвлекайся на болтовню на форуме - приступай.

Как интересно. Кажется, пора протолкнуть переход дебиана на вяленого. :)

Тонко :)

собирать сообщения ранней стадии загрузки, когда никакая реализация syslog ещё не запущена;

Это, в частности, делалось примитивным логгером bootlog, который ждёт, пока поднимется syslog и скармливает ему накопленные сообщения.

Нет же, без journald мы такую простую вещь никак не реализуем. Лол.

В статье же написано совсем про другое, и ни одного аргумента в поддержку собственной позиции ты так и не привёл.

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

Это Марк знает когда пришла пора ликвидировать баттхёрт волевым усилием. Потому он и миллионер, а аська - простой лох с лора.

А через какое-то время выбора не будет, ядро будет требовать от init'а systemd-специфичные вещи.

отключить в ядре эту опцию, требующую системде. Да и маловероятно что Линус согласится запилить в ядро зависимость от внешней поделки ленарта.

Всё, линух можно закапывать. Пойду напьюсь с горя.

И значение по умолчанию этой опции определяется автоматически при генерации configure.

И как оно может определяться автоматически при сборке пакета в изолированном окружении ? И, естественно, с общим разделом ? Уже догадался, да ? Так что автоматически оно правильно определяться не может. И так во всём systemd: «а мы думали...». Индюк тоже думал.

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

В статье просто написано «не виноватая я !!». И попытки отвертеться.