InitWare — форк systemd для Linux, BSD и MacOS

команды systemctl, loginctl и journalctl (svcctl, sessionctl и evlogctl соответственно)

Нескучные обои.

четко определенная область действия, <…> а также некоторыми вспомогательными вопросами

/0

Это уже не философия.

Нескучные обои.

Ну брендирование у проекта уже есть. Считай полдела сделано.

Вопрос «зачем?» Кому этот ненужнод, кроме как красно-шапке и другим лялих-лизунам сдался?

Это чисто лялих-подагра, зачем её тянуть ещё куда? Там везде уже своё есть.

некоторыми вспомогательными вопросами

Это я «matters ancillary to these» немного корявенько перевел. Не знаю даже как нормально смысл передать.

Чтоб системдешные юниты не переписывать, видимо.

Да всё так и есть, как ты перевёл. Если началась субъективщина «вот так уже комбайн, а вот так ещё не комбайн», то это уже не «философия», а вкусовщина. Моральный хайграунд провален, в общем.

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

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

systemd — это попытка (удачная или нет — судите сами) реализовать подобие launchd(8). Зачем нужен форк прибитого к Linux переизобретения прибитого к macOS системного менеджера?

Уже есть SVC (мало ли, вдруг кто-то любит BDSM ☺) и sysvinit (ну или OpenRC, если сильно хочется; причём GhostBSD, форк FreeBSD, использует именно OpenRC в качестве инита). Для маргиналов есть runit.

Я бы прикрутил себе OpenRC в FreeBSD в качестве инита, но мейнтейнить пачку (пусть даже не все из комплектных 166 мне нужны) инит-скриптов я не хочу. Из минусов rc scripts я вижу только последовательный запуск (загрузка может затянуться на несколько минут) и отсутствие ранлевелов (переключаться между multiuser и singleuser без перезагрузки — целый квест!). Но оно работало более двадцати лет, и проработает ещё столько же (потому что никто не станет ломать то что работает).

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

Подвох в том что подобное сабжу пытаются запилить те, кто открыл для себя *BSD уже после Linux/macOS. Причём большинство из пильщиков даже не знают почему всё так как оно есть.

systemd — это попытка (удачная или нет — судите сами) реализовать подобие launchd(8).

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

Например, в launchd хрен пропишешь зависимости сервисов, они прямым текстом говорят: пилите себе IPC. Роскошно, конечно, особенно если сервисы пишет кто-то другой.

В смысле не знают? Исторически сложилось

Исторически сложилось не знать? (%

видел новость с месяц назад. на лор приносить не стал. это как-то ни вашим, ни нашим. systemdешники не понимают, зачем это, а анти-systemdешники (лично я) считают, что если брать за основу что-то плохое, то ни к чему хорошему не приведет.

Я бы прикрутил себе OpenRC в FreeBSD

в ней повышения привилегий постоянно фиксят. некачественно пишут.

SVC (мало ли, вдруг кто-то любит BDSM

разве что xml уже не модно. освежить-обновить и нормально.

а вообще такие вещи должны разрабатываться, как и openssh, в OpenBSD под присмотром Тео.

Зачем нужен форк прибитого к Linux переизобретения прибитого к macOS системного менеджера?

они хотят отвязать от линукс, чтобы было легче переносить гном (и др. redhat-specific?) с линукса.

systemd — это попытка (удачная или нет — судите сами) реализовать подобие launchd(8).

А откуда вот этот стереотип пошёл? Что там подобного, кроме того что и то и то системы инициализации?

Я бы прикрутил себе OpenRC в FreeBSD

в ней повышения привилегий постоянно фиксят. некачественно пишут.

Это да, но переписывание некоторых вещей, требующих перезагрузки, меня напрягает тем что приходится по несколько минут ждать. // Когда завезли flua (вместо наркоманского Forth), я первым же делом расковырял код загрузчика и наметил вектор развития. ☺

SVC (мало ли, вдруг кто-то любит BDSM

разве что xml уже не модно. освежить-обновить и нормально.

Нужен какой-то простой формат декларирования (да пусть тот же Lua генерит обжекты, которые сишным "ядром" пережёвываются, я могу за вечер PoC накидать) "юнитов" и распараллеливание. Подтеринг смог, бздунам ничего не мешает (разве что чуть более прямые руки ☺).

а вообще такие вещи должны разрабатываться, как и openssh, в OpenBSD под присмотром Тео.

А вот тут одновременно и согласен, и не согласен. У них там даже PAM нет! Это не плохо, но это требует допиливания под другие *BSD. Но то что в итоге получится стабильно и надёжно — это да, тут я всеми шестью лапками за!

Зачем нужен форк прибитого к Linux переизобретения прибитого к macOS системного менеджера?

они хотят отвязать от линукс, чтобы было легче переносить гном (и др. redhat-specific?) с линукса.

Если так, то это благое дело. Хоть я и не пользователь GNOME, но не все же я, кому-то прикотится.

systemd — это попытка (удачная или нет — судите сами) реализовать подобие launchd(8).

А откуда вот этот стереотип пошёл? Что там подобного, кроме того что и то и то системы инициализации?

launchd не только система инициализации, это системный менеджер. Как и systemd.

но переписывание некоторых вещей, требующих перезагрузки, меня напрягает

не понял, что переписывать

Нужен какой-то простой формат декларирования

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

да пусть тот же Lua генерит обжекты, которые сишным «ядром» пережёвываются, я могу за вечер PoC накидать

че? какой луа? какой poc?

У них там даже PAM нет!

PAM - на самом деле это узаконенная помойка из модулей. настройка kerberos и ldap auth всегда выглядела двухседельным велосипедом. так что это не самое лучшее решение... плохо, что у них не PAM нету, а вообще, видимо, ничего нету.

Это не плохо, но это требует допиливания под другие *BSD

это уже мелочи

сама идея гнаться за теми, кто пишет софт с оговоркой «BSD не релевантна» напоминает мне, как линукс гнался за windows. так себе занятие. я всегда рассказываю пример, что у меня произошла одинаковая ситуация на systemd/Linux и BSD: проверка ФС не завершалась успешно, а приводила к падению или выходу с ошибкой fsck. в итоге обе ОС не могли загрузиться. в BSD я мог поправить bash скрипт (добавить отладчик, снять дамп), а в systemd/Linux мне пришлось сначала идти в гугл, чтобы узнать, что вызов fsck производится из C кода. сама идея портирования systemd вызывает вопросы.

А откуда вот этот стереотип пошёл?

это копипаста с интернета, я не стал переводить: Systemd is heavily influenced by launchd, the service manager that makes MacOS tick. They're very similar in design. IPC based, socket-activated, property-based, dependencies, parallel startup, unifying init and service management...

плюс об этом прямо говорит сам поттер http://0pointer.de/blog/projects/systemd.html «Unfortunately this idea never really took on outside of the Apple camp.» короче, нравится ему, как в мак ос.

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

не понял, что переписывать

Загрузчик. И не совсем переписать, только усовершенствовать.

че? какой луа?

В loader(8) завезли flua (огрызок Lua 5.4.2), и теперь весь текстовый и графический (да, завезли png 32bit truecolor в загрузчик) отдан на откуп файлам в /boot/lua/?.lua. С этим можно делать что хочешь, пока lua-код отдаёт загрузчику нужное нужного типа.

В юзерспейсе он доступен как /usr/libexec/flua, манов нет. ☺

какой poc?

PoC — Proof of Concept.

PAM - на самом деле это узаконенная помойка из модулей.

Не так он плох, как кажется. Лучше всё равно нет.

настройка kerberos и ldap auth всегда выглядела двухседельным велосипедом

На локальной машине это как из пушки по воробьям.

плохо, что у них не PAM нету, а вообще, видимо, ничего нету.

В OpenBSD есть BSD Auth. Своеобразная… штука.

Это не плохо, но это требует допиливания под другие *BSD

это уже мелочи

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

гнаться за теми, кто пишет софт с оговоркой «BSD не релевантна»

Так гонятся-то иммигранты с Linux.

в BSD я мог поправить bash скрипт (добавить отладчик, снять дамп)

Да, тут всё просто. Ну и не Bash, а POSIX Shell.

// Парадокс: GNU, так яро пропихивавшие POSIX как стандарт, сами на этот стандарт в итоге забили.

завезли flua

ох, усложнили. это типа ответ grub2. ну ладно. теперь понял, что за poc. считай, просто конфиг для загрузчика.

Своеобразная… штука.

не видел, но вроде типа тоже че-то модульное.

На локальной машине это как из пушки по воробьям.

ну мне не редкость использовать машины не только как root@localhost

аниматься портированием между бздями. Не первый раз происходит.

вот, кстати, ты не знаешь, откуда в DragonFly BSD взялся cryptsetup?

а POSIX Shell.

а, ну да

сами на этот стандарт в итоге забили.

зато документации на bash гораздо больше. я на этот posix sh так цельную доку и не нашел.

Если это InitWare умеет быть как supervisord/monit, но с systemd-совместимыми юнитами, то я щитаю, это лютейший win.

Без рута могет сервисами рулить или опять двадцать пять?

Да ладно стесняться, его мало тут хвалят, должен же кто-то восстанавливать баланс.

отдан на откуп файлам в /boot/lua/?.lua

и если уж ты хотел регексп, то /boot/lua/*.lua

ох, усложнили.

Нифига! В сравнении с Forth это глоток свежего воздуха! Они ничего нового же не ввели, просто выкинули (не выкинули, можно грузиться через loader_4th{,.efi}), но по умолчанию сейчас стал loader_lua{,.efi}.

это типа ответ grub2

Конечно нет.

теперь понял, что за poc

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

не видел, но вроде типа тоже че-то модульное.

Я видел лет надцать назад, уже не помню что к чему, но оно вещь в себе, со всеми вытекающими. Для PAM есть куча модулей, для BSD Auth только то что осталось от BSD/OS и что накидали в OpenBSD. Всё.

вот, кстати, ты не знаешь, откуда в DragonFly BSD взялся cryptsetup?

Дилдон старается. У него есть и крутые ништяки (HAMMER2), и полный бред. Но стрекозлам нравится. ☺

я на этот posix sh так цельную доку и не нашел.

Эээ?

А вот то что документации нет в базовых манах (builtin(1) — никакой) — это бида, да.

отдан на откуп файлам в /boot/lua/?.lua

и если уж ты хотел регексп, то /boot/lua/*.lua

* — это глоб, не регексп. ☺

? — это "один или больше", когда * — "ноль или больше". То есть *.lua включает файл /boot/lua/.lua, ?.lua требует какого-то имени файла (ибо require() в lua работает через имена, и там есть ряд ограничений, например в имени файла не должно быть точки: require("my.module") → ./my/module.lua).

* — это глоб, не регексп.

если быть точнее, то да

? — это «один или больше»

нет, это просто один.

man bash:

       Pattern Matching

       blablabla

       The special pattern characters have the following meanings:

              *      Matches any string, blalblabla
              ?      Matches any single character.

Дилон старается. У него есть и крутые ништяки (HAMMER2), и полный бред. Но стрекозлам нравится. ☺

да я уже в виртуалке поставил. вижу hammer2, нормально, пойдет. а вот драйверов для nvidia не вижу:( не собираются они под этим деривативом. так он что, полностью переписал cryptsetup под BSD лицензией? тогда почему в манах редхат. или он просто портировал GPL код? казалось бы до FreeBSD донести один шаг... а вот нет.:(

? — это «один или больше»

нет, это просто один.

А, ну да. Всё смешалось в головеществах.

Вот только в Lua объявление _G.package.path делается именно так, как я писал выше:

 % /usr/libexec/flua
Lua 5.4.2  Copyright (C) 1994-2020 Lua.org, PUC-Rio
> print(_G.package.path)
/usr/share/flua/?.lua;/usr/share/flua/?/init.lua;/usr/lib/flua/?.lua;/usr/lib/flua/?/init.lua;./?.lua;./?/init.lua

 % /usr/local/bin/lua52
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> print(_G.package.path)
/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.2/?/init.lua;/usr/local/lib/lua/5.2/?.lua;/usr/local/lib/lua/5.2/?/init.lua;./?.lua

 % /usr/local/bin/lua53
Lua 5.3.6  Copyright (C) 1994-2020 Lua.org, PUC-Rio
> print(_G.package.path)
/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;./?.lua;./?/init.lua

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

под этим деривативом

Тут фишка в том что DragonFly BSD форкнулось аж от FreeBSD 4.x (какой конкретно не помню) и кодовую базу особо не синхронизируют, так что не стоит рассчитывать на совместимость.

так он что, полностью переписал cryptsetup под BSD лицензией? тогда почему в манах редхат. или он просто портировал GPL код?

Вопрос явно не по адресу, я dfbsd вообще не видел, только с юзерами общался, и то немного. ☺

казалось бы до FreeBSD донести один шаг… а вот нет.:(

У них кодовая база очень разная! Читай первый абзац.

А зачем тебе лезть в lua-код? Ты разве лез в forth-код? ☺

Просто тем кто хочет ковырять загрузчик стало проще.

Ты разве лез в forth-код?

у меня был grub2 код((( :)

А зачем тебе лезть

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

Ты разве лез в forth-код?

у меня был grub2 код((( :)

Соболезную. (%

да уж надеюсь, что не придется хотя бы в это.

Оно работает и жрать не просит.

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

может, в итоге они и инит тоже на луа напишут)

InitWare — форк systemd для Linux, BSD и MacOS
Лицензия LGPL v2.1, так что на основную систему инициализации в BSD системах она не подойдёт.

В linux уже есть systemd и видимо на долго, про mac os смешно, там все больше ограничений взаимодействия пользователя и системы, а они предлаюат свой init туда! Остается freebsd, с которым по лицензии не совместим.

может, в итоге они и инит тоже на луа напишут)

У меня была такая мысль, но мне лениво. (%

То есть сам инит-то я накидаю за вечер, но я вращал на МПХ переписывание инит-скриптов. (%

Архитектурно rc scripts — говно. Раньше ничего лучше придумать не могли, но !@#$, XXI век, надо двигаться дальше! Уж распараллелить запуск демонов хоть немного уже давно пора.

ой нет, не раскачивай лодку. если все начнут свои иниты писать, так это же что?! анархия получится! вот один уже попытался... написал на сях... тоже говорил «21 век... надо двигаться...» ему поверили... и вот что вышло:( нет уж. такие проекты должны делать опытные системные разработчики. такие, как Тео или Линус, которые в принципе UNIX пишут. Один форкнул ОС - она стала успешнее начальной версии. Другой махнул лапкой - появился Linux kernel, махнул другой - появился git. Вот, как надо! Когда человек шарит, он скорее заложит хорошую базу.

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

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

Форкнули ненужное и надеются получить нужное, ну ну.

ой нет, не раскачивай лодку. если все начнут свои иниты писать

А никто не обещал попенсорц! =P Если я что-то и напишу, дальше моих машин оно не поедет. Я не жадный, просто зачем оно кому-то нужно, если я пишу софт под себя? ☺

такие проекты должны делать опытные системные разработчики.

У меня опыт есть. Практики, конечно, не так много как у Тео, но если я ничего не буду делать, то её и не прибавится. ^_~

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

Полтора. ☺ Из них меньше половины можно прикрутить к фряхе. (%

Как это зачем? У нас на FreeBSD, например, нет нормальной системы инициализации и управления сервисами от слова вообще. Есть говнишко на шелле, без какой-либо стандартизации, где чтобы запустить своё приложение нужно написать страницу кода и при этом вспомнить как оно там делается и какие подводные камни, и как лучше - вызвать приложение через daemon или его собственную демонизацию, как сделать чтобы пид файл нормально создался, и по нему сервис можно было прибить, как сделать чтобы лог попал куда надо и нормально ротировался и как вообще аргументы взять из rc.conf и передать сервису - под каждый завести переменную, или сделать одну foo_args, или и то и другое хотя бы на тот случай что аргументов слишком много, и в следующих релиза могут появиться новые, и как в таком случае выбирать для чего делать переменную а для чего нет. Потом вспомнить как работает rcorder, втыкатся перед или после DAEMON, LOGIN или NETWORKING, не забыть при этом проверить что не создал циклов. А уж если приложение таково что нужны несколько его инстансов, то вообще тушите свет.

При чём даже третьестороннего софта для этого нет. supervisord и daemon tools это, извините, конченое ублюдство.

systemd или хотя бы принятый в нём подход - это лучшее что случилось с линуксом в этом веке, и чем быстрее это случится c BSD тем лучше для них.

У нас на FreeBSD, например, нет нормальной системы инициализации и управления сервисами от слова вообще. Есть говнишко на шелле, без какой-либо стандартизации,

«Унас» говоришь? Вали на лялих, там всё есть.

нужно написать страницу кода и при этом

#!/bin/sh
#
# $OpenBSD$

daemon="/usr/local/bin/blog"
daemon_user=www

. /etc/rc.d/rc.subr

rc_bg=YES
rc_reload=NO

rc_cmd $1

Не позорься.

https://man.openbsd.org/rcctl.8

Что там у этих неумёх и wannabe-linux freebsd не знаю, правда.

Проблема переноса systemd - в cgroups и всяческих прибитых к ним logind

Не порвись.

Я писал об этом много раз, очень рад что кто-то мои хотелки воплощает в жизнь.

Ага, во фре все просто великолепно, пусть постарше меня самого, но работает же. И мне норм, но порой после центоси аж тошнит.