А если написать систему инициализации на basic ?

что бы её стали устанавливать?

...надо вбросить, что старая система инициализации устарела

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

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

Главное настойчиво объяснять, что это круче. Доказывать необязательно. И вообще:

be happy with, at least in principle

Любишь много писать и велосипедить? Не только в том, что делаешь, но и в используемом языке (инструменте)? Тогда вперёд! Родина тебя не забудет.

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

Ты говоришь так как будто BASIC это что то плохое.

Замечательный вопрос. Я полагаю, что система инициализации на бейсике могла бы иметь право на существование, если бы та же Canonical начала продвигать её под видом «простой, как сам бейсик», и «подходящей для изучения Ubuntu» целевой аудиторией, при этом написать надо в лучших традициях ФП, чтобы у всех остальных случился ботфорт.

systemd написан на нормальном языке, но однако же...

Не взлетит, freebasic — x86 only, gambas вообще требует свой рантайм.

Давай сразу на JavaScript, это же модно и прогрессивно, чего уж там.

Что вообще должна уметь уникального система инициализации что бы её стали устанавливать?

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

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

У нас таких много

.

её тоже многие будут внедрять?

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

Реализуй все основные возможности systemD в нескольких небольших скриптах на bash. Такой проект имеет все шансы на успех.

Надо работать в редхате

Зачем ее писать на Basic, если можно уложиться в одном bash-скрипте? Кое-кто мне знакомый уже так делал. По его словам, systemd по скорости запуска курит в сторонке.

Чтобы быть успешной, должна быть написана на коболе, который недавно в слаку воткнули же!

gambas вообще требует свой рантайм.

И в чём сложность? Хотя да, если /usr в отдельном разделе то не взлетит.

желательно еврейское

А что должна уметь система инициализации кроме того что бы отдать последовательно несколько команд service, написать лог и принять команду типа init 1 ?

Это ты зря, мой куратор из ZOG не доволен этим постом.

Скрипты инициализации тоже на бейсике тогда. Вот это будет весело.

5 CLS
10 PRINT "SYSTEMB INIT V 1.0"
20 PRINT "STARTING SERVICES..."
30 RUN "/etc/systemb/rc.bas"
...

Тогда надо написать свой интерпретатор или использовать QEMU.

Вообще то нумерация строк уже давно не нужна и я так «goto» не разу в программах и не использовал. Зачем когда есть циклы DO LOOP ?

Так тебе на моднявеньких современных диалектах или на труЪ-бэйсике надо?

Тогда надо написать свой интерпретатор или использовать QEMU.

Можно урезанный gambas собрать не в /usr, а в /

Хотя будучи установленным gambas3-runtime занимает всего 614 килобайт.

/.
/usr
/usr/bin
/usr/bin/gbr3
/usr/bin/gbx3
/usr/lib
/usr/lib/gambas3
/usr/lib/gambas3/gb.component
/usr/lib/gambas3/gb.debug.component
/usr/lib/gambas3/gb.debug.so
/usr/lib/gambas3/gb.debug.so.0
/usr/lib/gambas3/gb.debug.so.0.0.0
/usr/lib/gambas3/gb.draw.so
/usr/lib/gambas3/gb.draw.so.0
/usr/lib/gambas3/gb.draw.so.0.0.0
/usr/lib/gambas3/gb.eval.component
/usr/lib/gambas3/gb.eval.so
/usr/lib/gambas3/gb.eval.so.0
/usr/lib/gambas3/gb.eval.so.0.0.0
/usr/lib/gambas3/gb.so
/usr/lib/gambas3/gb.so.0
/usr/lib/gambas3/gb.so.0.0.0
/usr/share
/usr/share/doc
/usr/share/doc/gambas3-runtime
/usr/share/doc/gambas3-runtime/changelog.Debian.gz
/usr/share/doc/gambas3-runtime/copyright
/usr/share/gambas3
/usr/share/gambas3/icons
/usr/share/gambas3/icons/application-x-gambas3.png
/usr/share/gambas3/info
/usr/share/gambas3/info/gb.debug.info
/usr/share/gambas3/info/gb.debug.list
/usr/share/gambas3/info/gb.eval.info
/usr/share/gambas3/info/gb.eval.list
/usr/share/gambas3/info/gb.info
/usr/share/gambas3/info/gb.list
/usr/share/gambas3/mime
/usr/share/gambas3/mime/application-x-gambas3.xml
/usr/share/icons
/usr/share/icons/hicolor
/usr/share/icons/hicolor/64x64
/usr/share/icons/hicolor/64x64/mimetypes
/usr/share/icons/hicolor/64x64/mimetypes/application-x-gambas3.png
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/gbr3.1.gz
/usr/share/man/man1/gbx3.1.gz
/usr/share/mime
/usr/share/mime/packages
/usr/share/mime/packages/gambas3-runtime.xml

Да на любом BASIC.

тогда уж на python, он итак во всех дистрах присутствует. Но, зачем? Есть openrc и он, вполне себе, KISS, в отличие от бинарной хренотени systemd.

Тонко... Я б еще mono предложил.

Не знаю, реализовано ли так уже. Но я сейчас придумал вот что:

У каждого сервиса скрипт запуска, после запуска скрипт подключается к специальной шине и ждёт сигналов. Все скрипты стартуют одновременно. Каждый скрипт при запуске, остановке, изменении конфигурации (service ServiceName reload) посылает по шине сигнал, а все скрипты его принимают и обрабатывают.

Предположим что серверу DHCP не имеет смысла запускаться до старта сети, следовательно скрипт запуска dhcpd будет ждать пока по шине пройдёт сообщение «network starting» и только после этого запустит сам dhcpd.

Ну как? Новация или баян? Нужно или закопать?

Окай. Почему многие считают BASIC недо-языком? Только от того что на нём нельзя реализовать все парадигмы программирования?

Почему многие считают BASIC недо-языком?

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

Кстати, а чё это господа лисперы ещё не написали свою собственную систему инициализации с поэтессами и преферансом?
Какого ... бал правит «быдляцкая имеративщина»?

Все скрипты стартуют одновременно

скрипт запуска dhcpd будет ждать пока по шине пройдёт сообщение «network starting»

А как быть с приоритетами?) Ну, т.е. запустить все сразу - это «дом2»-вопрос, но ты же понимаешь, что надо как-то выделять системные демоны(удавы, там всякие) и прочую ерунду иначе будет, что юзеровый демон отожрал дофигища процессороного времени и это скажется на скорости загрузки.
Но, как концепт - нужно) Осталось на proof-of-concept посмотреть:)

То есть запуск с пониженным или нормальным приоритетом?

ага, именно

Стоит ли позволить это определять самим скриптам, или вынести настройку из них в независимый конфиг?

Думаю, что отдельный конфиг будет удобнее.

У лисперов в своё время была целая лисп-машина, что им какая-то система инициализации... :)

Так это было давно в прошлом веке ;)
А вот поцчему лисперы так и не протянули свои ручки к системе инициализации, для меня вопрос.

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

Вот и я говорю, что на Ruby надо было писать.

systemd устарела! нужно написать новый клон init на java/haskell/clojure!

Зачем ее писать на Basic, если можно уложиться в одном bash-скрипте? Кое-кто мне знакомый уже так делал. По его словам, systemd по скорости запуска курит в сторонке.

Те, в одном баш-скрипте, или в /bin/sh + /bin/* + /sbin/* + /usr/bin/* + /usr/sbin/* + баш_скрипт?

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

Ты зачем тему выкопал, некрофил?

Ну где еще можно увидеть предложение написать init-систему на бейсике?

А вообще, да, что-то проглядел даты.

Лучше на питоне/пхп.