Devuan Excalibur 6

Имеют право, лицензия позволяет.

Так ведь и Гугл и все производители андроидов лицензию не нарушают. Речь ведь не о том, имеет ли право или нет. Играть против СПО можно вполне в легальном поле.

И повторюсь, нет никаких гарантий касательно будущей политики РХ и их существования вообще.

Иди перечитай еще раз пост на реддите.

Кстати, мы же совсем забыли про GNU Shepherd! А ведь он тоже поддерживается в Devuan. Всё никак руки не доходят потрогать.

Кто-нибудь пробовал?

As a system administrator or distro developer, you define services in a configuration file written in Scheme:

(define sshd
  (service
    '(sshd ssh-daemon)                ;the secure shell daemon
    #:start (make-inetd-constructor   ;start on demand
             '("/usr/sbin/sshd" "-D" "-i")
             (list (endpoint
                    (make-socket-address AF_INET INADDR_ANY 22))
                   (endpoint
                    (make-socket-address AF_INET6 IN6ADDR_ANY 22)))
             #:max-connections 10)
    #:stop (make-inetd-destructor)
    #:respawn? #t))

(register-services (list sshd))
(start-in-the-background '(sshd))

?%@№ая &?*та.

Вот это реально эталонное нинужно.

интереснее даже не openRC и runit продвигать, а сделать форк systemd

Нахрена?

С какими-то фичами, интересными, например, именно для десктопного применения GNU/Linux

Это прекрасно можно и прямо в systemd делать - они с удовольствием принимают качественный код.

какими именно сходу не скажу, но подумать на эту тему можно

Ожидаемо. Те, кто могут придумать интересные фичи, уже участвуют в разработке systemd. Те, кто не могут - рассуждают про бессмысленные форки. Иногда даже делают их. С предсказуемым:

хватило автора ненадолго

Это прекрасно можно и прямо в systemd делать - они с удовольствием принимают качественный код.

Более того, гном потому и завязался на systemd, потому что он решает проблемы десктопных окружений. Даже такая простая задача, как автозапуск чего-нибудь на фоне и чтение потом логов оттуда проще всего решается через systemd-run и journald. На самом деле, у десктопов полно мелкиз задач, касающихся более нижних слоев системы, и для которых десктопам приходится изобретать велосипед.

Минвайл, я реально устал от хейтеров, которые постоянно орут про блоатность и сложность systemd, но ни разу не открывали его код. Я открывал, и качество кода там - мое почтение. Всё очень понятно и хорошо структурировано. Вообще ни в какое сравнение не идет с дедовым кулхакерством, которое было популярно еще 20 лет назад. Кто знает, как выглядит код большинства древних проектов - тот знает. Кто не знает - объяснять разницу бесполезно.

Интересная англоязычная ветка по сабжу:

https://www.phoronix.com/forums/forum/software/distributions/1588830-devuan-6-0-released-for-debian-13-without-systemd?p=1588918#post1588918

...and as usual the people complaining about people daring to criticize systemd are always first to comment and the loudest. At least you've moved past the old straw man that people critical of stystemd can't see why it was actually needed. However you're still avoiding the actual issue people have with it. The messy implementation that has so many crisscrossing dependencies they may as well have written it as one big monolithic structure. Dependencies so strong it was what allowed attackers to leverage an attack on xz to compromise OpenSSH.

Lets not even get into the feature creep and how that spider's web of dependencies makes attacks like the one on xz utils a constant threat. 

Нахрена?

Чтобы оставить от systemd только инит без системного менеджера ?

Чтобы оставить от systemd только инит без системного менеджера ?

Вопрос всё тот же - нахрена? Кому это нужно кроме кучки упоротых фанатиков?

Вопрос всё тот же - нахрена?

А зачем системный менеджер для части узкоспециализированных решений типа гипервизор-оркестратор и т.п. ?

А зачем системный менеджер для части узкоспециализированных решений

То есть системный менеджер тебе не нужен и поэтому ты решил форкнуть системный менеджер… орёл! Который деревья долбит.

То есть системный менеджер тебе не нужен и поэтому ты решил форкнуть системный менеджер

Нет, если бы был уже готовый форк только инита systemd без системного менеджера, то возможно я бы его рассматривал в качестве варианта для своего кейса, а так приходится довольствоваться Alpine, там всё есть, и настоящий OpenRC без SysV лапши, и incus и готовый предкомпилированный ZFS под каждое ядро из репозитория.

Нет, если бы был уже готовый форк только инита

Ну вот если бы бабушка обзавелась яйцами…

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

Ну вот если бы бабушка обзавелась яйцами…

Как будто я прям сильно расстроился, что нет инита systemd без вот этого всего остального (что есть в обычном systemd), но в качестве идеи для форков, IMHO неплохой вариант ?

в качестве идеи для форков, IMHO неплохой вариант ?

Для нежизнеспособных форков вроде useless, eudev, elogin и прочей параши - само собой.

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

Хейтерские форки по принципу «лишь бы нагадить» a-priory нежизнеспособны. Просто потому что хейтерского запала хватает только на пук-среньк. В долгосрок они софт поддерживать не могут - вот в комментах срать, это завсегда, на это у хейтеров мотивации хватит.

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

Апстриму systemd приемлемо отключение его системного менеджера с сохранением функциональности только инита?

Вот такая «функциональность» свободы от системного менеджера systemd ? :)

Хейтерские форки по принципу «лишь бы нагадить» a-priory нежизнеспособны.

Если кому-то что-то ненужно, то отказ от ненужно считается подгаживанием?

Или использование systemd - это такая же обязанность для всех и каждого, как платить налоги ?

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

Был бы спонсор, легко бы нашлась и мотивация :)

Был бы спонсор, легко бы нашлась и мотивация :)

Попробуй на онлифанс поискать ;)

Попробуй на онлифанс поискать ;)

Поискать готовый форк инита systemd без его системного менеджера?

Я так и подозревал что иное использование этого сервиса тебе недоступно чисто физиологически :-D

Я так и подозревал что иное использование этого сервиса тебе недоступно чисто физиологически :-D

Это какое другое ?

CVE, связанные именно с linux были? Были. Аргумент невалиден. Отказать.

То есть, если в ядре были CVE, то теперь всем можно? :-)

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

Никто так не решил. Втащили совсем по другим причинам. А именно так решили в, например, KDE. Кто готов постоянно патчить KDE для отвязывания от systemd? Вроде с Gnome аналогичная история. И понеслось.

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

раздел «Service Templates» это просто шедевр! Особенно

Службы systemd могут принимать один аргумент с помощью синтаксиса «service@argument.service».
It is possible for systemd services to take a single argument via the «service@argument.service» syntax.

Это самое шикарное описание синтаксиса, которое я видел!

Synopsis

service.service, socket.socket, device.device, mount.mount, automount.automount, swap.swap, target.target, path.path, timer.timer, slice.slice, scope.scope

Хот нет, это круче... Это на другой странице, https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html , читаю дальше:

System Unit Search Path

Логично что тут надо объяснить что это за путь для поиска? Не, ну а вдруг кто то не угадает? Может там есть нюансы, это вроде очевидно что должны быть? Да не, зачем, просто давайте перечислим...

/etc/systemd/system.control/*
/run/systemd/system.control/*
/run/systemd/transient/*

Ой, очепятка, 2 раза один путь.

/run/systemd/generator/*
…
/usr/local/lib/systemd/system/*

Орфография соранена. Там есть ещё какие то пути, но им лениво было всё перечислять, как и в «User Unit Search Path»

Unit names can be parameterized by a single argument called the «instance name». The unit is then constructed based on a «template file» which serves as the definition of multiple services or other units. A template unit must have a single «@» at the end of the unit name prefix (right before the type suffix). The name of the full unit is formed by inserting the instance name between «@» and the unit type suffix. In the unit file itself, the instance parameter may be referred to using «%i» and other specifiers, see below.

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

• неизвестные параметры в юните вызывают сообщение в журнал и игнорируются
• в самих юнитах можно блокировать некоторые параметры тегом «Х-»
• эта возможность сделана для того, чтобы сторонние парсеры юнит-файлов могли добавлять комментарии... Да ЪТЬ, чем их не устроил стандартный способ через «#»?!

...после чего нужно перейти к описанию работы «псевдонимов», или симлинков на другие юниты...

Не, это не мануал, это свалка отдельно надёрганных фактов по теме. Чтобы что то извлечь из неё нужно провести дополнительный огромный объём работы и ты никогда не можешь быть уверенным что прочитал всё по теме.

Сторонние проекты завязались на systemd, а виноват systemd.

Тут надо ещё посмотреть, на сколько основные из них не зависят от RedHat.

Systemd не является комбайном, как многократно выяснено в это треде. Архитектурно он сделан иначе.

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

Нет, бардак - это объективное свойство базарного подхода в СПО.

Но в неСПО тоже бардак! Там тоже велосипеды, NIX-синдром и «и так сойдёт».

то теперь всем можно

Нет. Это я к тому, что существование в продукте CVE - не повод этим продуктом не пользоваться, и аргумент в целом несостоятелен.

Вот если бы их не фиксили - тогда можно было бы о чем-то говорить. Но их фиксят.

Я уже объяснял выше, как нужно отвязывать от systemd. Что-то непонятно?

Тут надо ещё посмотреть, на сколько основные из них не зависят от RedHat.

Посмотри. Когда закончишь - приходи с фактами.

Является

Не является, как мы ранее выяснили.

ненужного

Отучаемся говорить за всех. Если тебе на твоем локалхосте не нужно - это не значит, что не нужно всем.

перезапускаться ради чиха в любом из втянутых компонентов

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

Как многократно выяснено в этом треде.

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

Чего не выяснено в этом треде - так это почему люди, не разбирающиеся в разработке ОС, вроде Кирилла и тебя, зачем-то начинают учить других, как и правильно делать оси.

Но в неСПО тоже бардак!

И что?

NIX-синдром

NIH, вообще-то.

На вот, поизучай

забыть уадлить из документации заметку об отключенной функции - косяк

Я это где-то отрицал? Баги есть в любом софте, это не аргумент.

Это самое шикарное описание синтаксиса, которое я видел!

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

Ой, очепятка, 2 раза один путь.

Нет, ты долбишься в глаза. Один путь начинается с /usr, а второй - с /etc. Но ведь тебе поклоунадить важнее.

Довольно шизофреничная попытка объяснить что есть «instance name» и есть «шаблоны», в которой нет самого главного - а зачем есть шаблоны и чем они отличаются от файлов-юнитов.

Там буквально об этом написано, темплейт - это юнит с параметризацией.

Орфография соранена.

Попробуй подумать.

Не, это не мануал, это свалка отдельно надёрганных фактов по теме.

Это отличный мануал, просто при его чтении надо хоть немного включать мозг, чего ты делать категорически не желаешь.

Не, это не мануал, это свалка отдельно надёрганных фактов по теме. Чтобы что то извлечь из неё нужно провести дополнительный огромный объём работы и ты никогда не можешь быть уверенным что прочитал всё по теме.

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

https://www.anekdot.ru/i/caricatures/normal/25/11/13/1763059739.jpg

Я это где-то отрицал? Баги есть в любом софте, это не аргумент.

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

Надо быть совсем тупым, чтобы его не понять.

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

Нет, ты долбишься в глаза.

Видимо "..." или буквально «ХЗ, возможно какие то ещё пути, мы не знаем/нам лениво» мне тоже показалось.

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

темплейт - это юнит с параметризацией

Любой юнит - с параметризацией или по крайней мере потенциально может быть.

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

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

/usr/local/lib/systemd/system/*

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

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

Документация на systemd, кстати, одна из наиболее качественных технических документаций, которую я видел вообще в жизни.

Ой, очепятка, 2 раза один путь.

Это какой, кстати? Смотрю по твоей ссылке и не вижу.

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

Да. Это как-то отменяет вероятность наличия бага? Абсолютно любая документация содержит ошибки и неточности. Качество документации определяется их количеством и полнотой. Неточностей минимум.

Надо быть совсем тупым чтобы давать это с таком виде.

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

Видимо «…» или буквально

Эки ты удобно взял и вымарал тот факт, что я тебя ткнул носом в твою невнимательность по поводу /usr и /etc, и переадресовал один мой ответ к другому своему вопросу.

должно быть чётко объяснено

Там и написано.

И ещё, ты утверждал что «ну там 3 местоположения, и всё».

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

Любой юнит - с параметризацией

… Является темплейтом.

не нужно было «включать мозг»

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

Он в глаза долбится. Там два почти одинаковых путя, но один начинается с /etc, а второй - с /usr. А когда я его повозюкал мордой по этому факту, он просто это проигнорировал.

И вот так у него всё. Проблема не в systemd, а в днк этого эникейщика.

разработчики системд классифициовали юнит-файлы как разделяемые библиотеки

Давай почитаем старый добрый FHS вместе. Открываем главу /usr/lib : Libraries for programming and packages и видим следующее:

/usr/lib includes object files and libraries. [21] On some systems, it may also include internal binaries that are not intended to be executed directly by users or shell scripts. [22]

Хм, не наш случай. Читаем дальше:

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [23]

Вот, собственно, и всё. Юниты считаются архитектурно-зависимыми данными, так как могут содержать разнообразную конфигурацию, специфическую для конкретной инсталляции. В том числе, установленные из сторонних вендорских пакетов. А значит, место им - в /usr/lib. Даже по олдово-дидовому стандарту systemd не делает ничего странного.

Да любой man ffmpeg это просто небо и земля! Хотя даже он не сильно то прост в понимании без сторонних статей.

Качество документации определяется их количеством и полнотой. Неточностей минимум.

Для минимума как то многовато - на первой странице портянки и без углублённого изучения, просто плавало на поверхности.

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

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

что я тебя ткнул носом в твою невнимательность

Не отрицаю, но что там с пропущенным куском путей? А с описанием каждого из этих путей и их приоритетов?

Там и написано.

Нет, там буквально АБСОЛЮТНО ПУСТО. НОЛЬ информации кроме самих путей. Ну, некоторых из них...

которые нужно знать для размещения своих собственных.

А для других задач? Например чтения и модификации не своих юнитов?

… Является темплейтом.

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

ты очень последователен в нежелании включать голову

Я очень последователен в требованнии удобства и простоты от БАЗОВОГО системного инструмента, пользоваться которым должен любой юзер без квалификации. В противном случае нехрен было делать его монолитнм комбайном и запихивать его в каждую дырку. Это сраный молоток для забивания гвоздей, он должен просто забить гвоздь и не требовать диплома о высшем образовании и даже часового чтения мана - всё должно быть в 2-3 абзацах методички.

просто плавало на поверхности

Не плавало, ты просто не включаешь голову. Почему-то я всё понял.

Тогда посмотри на ситуацию с другой стороны: что этот абзац там вообще делает?

Объясняет, что такое темплейтовый юнит.

что там с пропущенным куском путей?

Очевидно, это означает, инсталляционно-зависимое. Как в твоем дистре сделают - так и будет.

А с описанием каждого из этих путей и их приоритетов?

https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#Unit%20File%20Load%20Path

АБСОЛЮТНО ПУСТО

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

Например чтения и модификации не своих юнитов?

Есть на этой же странице, только что проверил.

о чём следовало бы написать

Там и написано, просто ты не понял.

Я очень последователен

В неумении читать. Начни с букваря.

Да любой man ffmpeg это просто небо и земля!

Документация по ffmpeg очень хороша тоже. Но ffmpeg делает намного меньше, чем systemd.

Он в глаза долбится

А ты нет? /usr/local/lib/ и /usr/lib это ведь один путь!

4.6. /usr/lib : Библиотеки для программирования и пакеты
4.6.1. Назначение
/usr/lib содержит объектные файлы и библиотеки. [21] В некоторых системах он также может включать внутренние двоичные файлы, которые не предназначены для непосредственного выполнения пользователями или командными скриптами. [22]

Приложения могут использовать один подкаталог в каталоге /usr/lib. Если приложение использует подкаталог, все зависящие от архитектуры данные, используемые исключительно приложением, должны быть помещены в этот подкаталог. [23]

Причём тут ведь в явном виде написано - текстовые конфиги ложить сюда...

[21] Прочие статические файлы и подкаталоги, зависящие от архитектуры конкретного приложения, должны быть размещены в /usr/share.

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

[24] Некоторые исполняемые команды, такие как makewhatis и sendmail, также традиционно размещаются в /usr/lib. makewhatis является внутренним двоичным файлом и должен быть размещен в двоичном каталоге;

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

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [23]

Оказывается «приложения могут использовать один подкаталог» у нас стало раносильным «кидаем конфиги в место для библиотек»... Ну ОК...

Юниты считаются архитектурно-зависимыми данными,

find /usr/share/ | grep arm
...
/usr/share/libvirt/cpu_map/arm_FT-2000plus.xml
/usr/share/libvirt/cpu_map/arm_cortex-a53.xml
/usr/share/libvirt/cpu_map/arm_Falkor.xml
/usr/share/libvirt/cpu_map/arm_cortex-a72.xml

Не хочу рыться в стандарте на /usr/share, потому что очевидно там нет никакого запрета размещать архиитектурно-специфические конфиги.

/usr/local/lib/ и /usr/lib это ведь один путь!

Пятница удалась?

текстовые конфиги ложить сюда

- Что стало причиной вашего расставания?
- Ложь.
- А именно?
- Я его спросила: "Тебе сахар в кофе положить?", а он ответил: "Ложь".

/usr/local/lib/ и /usr/lib это ведь один путь!

Сфига ли?

Причём тут ведь в явном виде написано - текстовые конфиги ложить сюда…

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

Прочие статические файлы и подкаталоги, зависящие от архитектуры конкретного приложения, должны быть размещены в /usr/share.

Я уже тебе говорил, чтобы ты читал оригинал, а не троекратно переваренный нейронкой кал. Вот что написано в оригинале: Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share. Архитектурно-НЕзависимые должны лежать в /usr/share, а зависимые - в /usr/lib.

что тоже не относится к юнитам, потому что они как раз НЕ ЯВЛЯЮТСЯ исполняемыми файлами!

В стандарте нет запрета на размещение неисполняемых файлах в /usr/lib, наобороот, там написано architecture-dependent data exclusively used by the application must be placed within that subdirectory. Data - это любые данные, вообще. И лежат они в подкаталоге внутри /usr/lib. Всё по стандарту.

кидаем конфиги в место для библиотек

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

/usr/share/libvirt/cpu_map/arm_FT-2000plus.xml

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

очевидно там нет никакого запрета

Для /usr/share стандарт предусматривает только размещение архитектурно-независимых данных. Единственное исключение сделано для архитектурно-зависимых мануалов.

Сувать конфиги в lib это идиотизм и не надо пытаться его оправдывать.