Devuan, форк Debian без systemd

[vorphalack]

что интересно, это же сообщество с радостью слопало и dbus, и pulse-audio, и bluez
при наличии более живых и unix-way, либо просто более удобных альтернатив. а systemd им почему-то не айс…

[J_o_k_e_R]

Что интересно многие никак не могут понять, что основная проблема тренда systemd — это его безальтернативность в масштабах конкретных дистрибутивов. Все три перечисленных Вами программных продукта вполне можно не использовать и не ставить по умолчанию.

[vorphalack]

а так, ну, посмотрите сами со стороны — сначала, когда можно было выбрать два блютус-стека, affix и bluez, победил наиболее кривой. потом, при наличии живого QCOP/DCOP, умеющего все то же, но удобнее и дружелюбнее — придумали и впихнули dbus, которым пнуть что-либо руками в общем случае как минимум неудобно. дальше получилось так, что даже банальное действие «прицепить bt телефон к компу» без dbus стало сделать нельзя (пин-то только через него запрашивается!). потом таким же образом прикрутили Pulse Audio, при наличии, например, JACK.
фактически, вместо того чтоб улучшать существующее или потратить силы на что-то более осмысленное — у разработчиков и сообщества случается приступ NIH и «мне не надо — никому не надо». вот systemd и получился, к тому же основная его проблема — это то что он кривой костыль, а не его безальтернативность в ближайшем будущем. дергаться надо было начинать примерно тогда, когда первое детище поттеринга, avahi, пошло в дистрибутивы.

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

[3al]

прикрутили Pulse Audio, при наличии, например, JACK.

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

при наличии живого QCOP/DCOP, умеющего все то же, но удобнее и дружелюбнее — придумали и впихнули dbus

Эмм. dbus — это стандартизованный + слегка усложнённый DCOP.

, которым пнуть что-либо руками в общем случае как минимум неудобно

Можно пример?

[vorphalack]

про энергопотребление интересно, это как?

пример -KDE3, Amarok. 'dcop amarok player nowPlaying' показывало что плеер играет в данный момент. вопрос: как это сделать на dbus, не ломая мозг запоминанием всех org.abyrvalg.etc и /org/omgwtf/here/lies, и на какую шину, системную или пользовательскую, мне надо писать?

все же dbus — шина общения программ с программами, не предусматривающая наличие человека.

[3al]

про энергопотребление интересно, это как?

0pointer.de/blog/projects/pulse-glitch-free.html

We minimize the overall number of interrupts, down to what the latency requirements of the connected clients allow us. i.e. we save power, don't show up in powertop anymore for normal music playback.

Этой ссылке 6 лет и все, кто более-менее касались темы звуковых систем в Linux, а не троллили на тему «Даёшь JACK каждой домохозяйке», давно в курсе.

вопрос: как это сделать на dbus, не ломая мозг запоминанием всех org.abyrvalg.etc и /org/omgwtf/here/lies

Написать обёртку над тем же qdbus хоть на баше, матчащую по последней/любой части пути, например? А как с DCOP вместить в один неймспейс все интерфейсы и не путаться в них?

на какую шину, системную или пользовательскую, мне надо писать

Странный вопрос. Разве amarok умеет в системную шину?

[vorphalack]

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

«все интерфейсы» чего?

==
амарок был самым часто используемым таким образом у меня, вот и запомнился.

[evocatus]

Патрик Лауэр (Gentoo) давеча начал разбираться с dbus и был маленько в шоке, если не сказать больше

gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt

[3al]

Из этого не следует, что DCOP был лучше. Ну и альтернатив как бы нет (ad-hoc костыли поверх низкоуровневых средств IPC (сокеты, пайпы) — не считаются).

[dion]

QCOP/DCOP как минимум не годился в качестве общесистемной шины из-за зависимости от Qt/KDE

[vorphalack]

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

[dion]

KDCOP был весьма сильно завязан на QObject и Qt-ные типы данных.

И да, dbus по сути и вышел не требущей реализации DCOP.

Другое дело, что кроме dbus аля DCOP появился еще системные dbus.

[vorphalack]

и вместе с Qt, оно лишилось самой главной особенности — возможности пинать его человеком без взрыва мозга.

[flyaway]

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

[googol]

Почему-то мне кажется что этот форк не взлетит.

[iborzenkov]

Не только вам…

[phoenixweiss]

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

[evocatus]

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

[phoenixweiss]

Mac OS X это утверждение не поддерживает.

[Revertis]

И не надо.

[dordzhiev]

Что не так с systemd?

[Indexator]

boycottsystemd.org

[Ununtrium]

Ресурс не найден. Зеркало есть?

[Indexator]

http://web.archive.org/web/20141129114501/http://boycottsystemd.org/

[QtRoS]

В статье ссылки на хорошие статьи, а в них ссылки на другие, информации тонны.

[anclrej]

Из многих дискуссий на эту тему (а тема холиварная) я понял, что многие люди мало знают о systemd, и на то есть причина. Думаю все попробовали с наскоку разобраться что это, пролистать доки и прикинуть как на него перестроиться за пол часика… но нет. Systemd сложный, с ним придется повозиться, потратить много времени на его изучение, чтобы понять что он делает и что может делать в системе (systemd перебрал на себя очень много задач, это уже не Init). Конфигурация не тривиальная а в манах можно заблудиться. Поэтому с наскоку получиться разве-что на десктопах где поставил и работает, но админам придется приложить определенные усилия для перехода. Разработчикам тем более.

Мне кажется это именно то, что не так с systemd и что порождает негатив (есть конечно и другие минусы). Не знаю почему об этом говорят намного меньше чем о «философии Unix». Если говорить о том, как systemd как софт справляется с возложенными на себя задачами, то справляется он отлично. Он быстрый, функциональный, надежный. Наверное потому его и впиливают во все дистрибутивы.

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

[Indexator]

В любом случае хорошо иметь выбор.

В том-то весь и прикол, что systemd лишает вас выбора) На это так же накладывается то, что мейнтейнеры постепенно откажутся от поддержки других систем инициализации, несмотря на нарушение принятых ими ранее принципов развития конкретных дистрибутивов. Это же касается некоторых разработчиков, так же не удивлюсь, что постепенно разработчики Debian начнут отказываться от поддержки не основных платформ и ядер… О каком выборе тут можно будет вообще говорить?

[anclrej]

Да, согласен. Я бы хотел иметь возможность выбирать систему инициализации при установке системы а в идеале накатывать на установленную систему по желанию. Технически это тяжело реализовать, это фактически скорее часть системы чем приложение.

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

[reji]

тем больше мне нравится как работает systemd и тем меньше нравится перспектива с ним работать.

Хорошая фраза :)

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

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

[dion]

systemd очень много чего ломает. Например, мой ноутбук с него не загружается если я пропишу второй HDD в /etc/crypttab с keyscript. Он тупо не умеет спросить к нему пароль у скрипта.

Еще ему просто сносит крышу от нескольких записей на одну точку монтирования в /etc/fstab.

Для бинарных логов, как оказалось, нужен fsck:
lists.freedesktop.org/archives/systemd-devel/2014-November/025203.html

[Indexator]

Я приветствую еще один островок адекватности в океане маразма! Ура! \(^-^)/
Теперь будет хотя бы один не прокаженный deb-based дистрибутив, которые я люблю, но не переношу эту раковую опухоль systemd… Правда, остается еще очень большая опасность распространения через черный ход — прибивание заразы в качестве прямой зависимости к различным пакетами, как это произошло с Gnome…

[z0rc]

ушли четыре разработчика

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

[atomlib]

Поправил, спасибо.

[e_asphyx]

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

[0lympian]

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

[niamster]

Тянуть форк дебиана? Нуну. Лучше бы сделали альтернативу и возможность бесшовного переключения систем инициализации и управления системой.
Идея systemd хороша — унификация системы управления. Как для разработчиков ПО, так и для «паковальщиков» онного это глобальное упрощение — не надо создавать отдельно скрипты инициализации под разные дистрибутивы и окружения.
С другой стороны — systemd ужасный геморрой. Его отладить практически невозможно. Это то же самое, что отлаживать X/Gnome/KDE/etc. Но в отличии от графической(звуковой, игровой, какой угодно) подсистемы — система инициализации более критична, особенно в секторе серверов.
Сказать ваша система говно — просто, а создать хорошую архитектуру — довольно сложно, и почему-то никто не берется. Все кричат и и машут вилками.
Старая система init.d имеет свои ограничений, потому был создан upstart, который по неясным мне причинам умер. Каким-то образом вирус systemd проник во множество дистрибутив, скорее всего потому, что был многообещающим. Сейчас г-н Poettering занимается инцестом, но вместо того, чтоб сделать форк systemd и показать многоуважаемому автору сего продукта какой должна быть архитектура сложной системы — пожалуйста, мы сделаем форк debian и будет заниматься своим инцестом.

[vorphalack]

а systemd уже нафоркали — uselessd называется, повыкидывали все, не относящееся к работе инита как такового. uselessd.darknedgy.net/

[customtema]

Все равно не понимаю принципа разделения. Почему этот пост не на хабре?

Объясните, кто в курсе. Спасибо!