А что было бы если ...

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

В Embedded системах, если не ошибаюсь, вместо штатного инита, может быть вообще любым, наверное даже на Python 3. Тупо свой примитивный скрипт, и не только на питоне, а может даже бинарный исполняемый файл

Собственно, в десктопе тоже можно, но не могу представить сколько всего не взлетит

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

Так цимес в декларативщине против императивщины.

Тогда почему бы не запилить инит-скрипты на Makefile-ах

Потому что Makefile лютое говно, придуманное какими-то инопланетянами.

Очередной неосилятор. На самом деле там всё просто и логично. Если хотя бы документацию почитать.

Я написал их достаточно. И ничто не изменит моего мнения: Почти все изначальные unix-технологии созданы олигофренами под веществами. При наличии здравых идей вместо того, чтобы сделать удобно, сделали выебонисто.

Я тут внезапно обнаружил, что теперь ЛОРовцев с тушёнкой на аватарке больше одного. Давай дружить, пофиг на те мейкфайлы :)

При наличии здравых идей вместо того, чтобы сделать удобно, сделали выебонисто.

Вот чёт не заметил такого.
Скорее сделано на коленке как сейчас писали/пишут эмбедщики на сях для микроконтроллеров. Максимально просто, без всякой архитектуры фабрик фабрик, а тупо простынки кода с какими-то массивами со всякой фигнёй. С дырами безопасности и переполнениями буферов и прочим таким.

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

Зачем писать инит-скрипты на тьюринг-полном языке? Systemd запилил туда простой конфиг. И это офигенно.

В чём офигенность?

Нет, потому что ты описываешь не ту проблему, которую пытаются решить с помощью systemd

Зачем писать инит-скрипты на тьюринг-полном языке?

Захотелось тебе вдруг запилить какую-нибудь фичу, которой нет в «простом конфиге» - взял и запилил. А с «простым конфигом» нужно:

1) взять исходники системды

2) редактировать код на языке С

3) сконпелировать

4) установить

5) ребутнуть комп, ибо init процесс, иначе никак

пункты 2-5 повторять многократно до победного конца

Зачем писать инит-скрипты на тьюринг-полном языке? Systemd запилил туда простой конфиг. И это офигенно

Потому что конфиги systemd — это не инит скрипт. Инит скрипт — это сам systemd.

Для init нужны не скрипты, а программа управления сервисами (обычно на C/C++) и конфиги-объявления сервисов. В Windows NT это было давно сделано (services.exe) и там вообще никаких скриптов нет. Сейчас во всех актуальных системах используется программа управления сервисами.

винда ни разу не эталон правильной или красивой архитектуры

В чём офигенность?

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

появление системд, как и вляеного, и подмана, и остального в том, что редхат активно лочит линукс на себя, а после покупки ИБМом думаю этот процесс только усилится

винда ни разу не эталон правильной или красивой архитектуры

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

А давай. :)

Вот чёт не заметил такого.

Здравая идея в декларативном функциональном описании. В идее, что вот цель, а вот способ её собрать. И если цели нет - она собирается.

А вот стоит копнуть в реализацию, как всё становится тухло. Одного механизма работы переменных хватает.

На самом деле там всё просто и логично.

Кто-то ещё пишет Makefile руками? Сейчас они обычно генерируются из более высокоуровневых скриптов сборки (cmake, meson). Для этого даже придумали специальный формат ninja специально для автоматической генерации.

Захотелось тебе вдруг запилить какую-нибудь фичу, которой нет в «простом конфиге» - взял и запилил.

А может сначала rtfm сделать? Там столько возможностей в этом простом конфиге, так и не поймёшь что ещё добавлять.

На лоре это означает заигнорить.

Самое смешное то, что таки в винде даже базовая функциональность systemd выполняется как минимум тремя процессами: smss.exe (Session Manager SubSystem), wininit.exe (Windows Initialization) и services.exe (Services and Controller app). Выглядит иерархия запуска как-то так:

smss.exe
└--smss.exe
   └--wininit.exe
      └--services.exe

А по вспомогательным: systemd-logind = winlogon.exe, systemd-networkd = служба «DHCP Service» (загружаемая в svchost.exe либа).

Справедливости ради, все-таки монолит работает шустрее, особенно на системах со слабым IPC, вроде Linux. Я понимаю, что его пытаются подтянуть, и D-Bus вводят, и собираются уже что-то на уровне ядра добавлять — но все равно это по большей части юниксовое говно мамонта, которое отстало от прогресса минимум на 30 лет. В винде есть ALPC (Advanced Local Procedure Call), которое скорее всего слизано с аналогичного механизма в L4, и было передовым на 1993 год, поскольку дает возможность общаться процессам с минимальными накладными расходами. Насколько мне известно, ни один юникс так и не осилил аналога.

Насколько мне известно, ни один юникс так и не осилил аналога.

В BeOS/Haiku есть аналогичный механизм: Ports. Через него работает графика и обмен сообщениями между процессами. Есть Unix Domain Sockets.

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

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

А вот винда которая по идее разработчиков должна быть десктопом и на которой пользователь недолжен управлять системой сподвигла меня на просмотр dll через браузер в разных кодировках, использование хешредакторов, знание дерева устройств и если бы меня не посадили на Linux тоя бы ещё выучил IDA Pro и ассемблер.
И как показывает практика при потребностях сидеть в интернете, иногда выпендриваться и играть в игрушки.

Тебе не кажется что с концепцией десктопа и "простого" управления что-то не так?
Почему на линуксе я веду себя как ультрадесктопный пользователь, а на винде превращаюсь в программиста на машинных кодах?

может не зря я говорю что твой sytemd и services.exe из винды коричневая жижа?

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

Теперь надо рассказывать, что десктопный Линукс для домохозяек, а Windows способствует развитию интеллекта и компьютерных технологий. А то обычно наоборот говорят…

Захотелось тебе вдруг запилить какую-нибудь фичу, которой нет в «простом конфиге» - взял и запилил.

Это круто, но в 99% случаев нужно запустить бинарник и проверить что он не сдох.

А с «простым конфигом» нужно:

Не нужно.

> Это круто, но в 99% случаев нужно запустить бинарник и проверить что он не сдох.

дак вроде и скрипты с этим справлялись

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

Так что Init на скриптах рулит.

переписали бы, скажем, на питоне

Тогда systemd все восприняли бы как божий дар и неистово любили бы.

дак вроде и скрипты с этим справлялись

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

Как твой скрипт будет трепать, что процесс не сдох, чтобы его перезапустить?

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

надо немного подправить работу системы

Не надо.

но если на Linux это сводится к поиску нужного файла

Что не тривиальная задача ибо нормальной документации нет. Это может поломаться при следующем обновлении.

то на винде это сверх квест с необходимостью бинарного хакинга.

You are doing it wrong. В Windows для расширения системы обычно нужно написать динамическую библиотеку на любом компилируемом языке. Интерфейсы документированы и стабильны. В UNIX изначально не было динамических библиотек и до сих пор осталась родовая травма с возможностью расширения с помощью динамических библиотек.

то надо его чинить

Исскуственный интеллект который умеет чинить процессы пока не изобрели.

перезапуск не поможет

Часто помогает. Процесс мог упасть от нехватки ресурсов, утечки памяти или нестабильного бага.

В Windows для расширения системы обычно нужно написать динамическую библиотеку на любом компилируемом языке.

А теперь сравни вставку строчки на bash без полного знания этого языка и полное изучение языка программирования и api в случае винды.
Тебе не жалко геймеров и домохозяек?

да хоть на жаваскрипте, толку от этого, если все равно работать будет или медленно или ненадежно, а конфигурироваться или неудобно или неудобно? любая система инициализации – говно, исключений нет и не будет

А теперь сравни вставку строчки на bash без полного знания этого языка и полное изучение языка программирования и api в случае винды.

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

полное изучение языка программирования и api

Зачем? Достаточно посмотреть документацию на интересующую часть.

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

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

а вдруг у нас встроенный девайс с 4 мегабайта флеша

а вдруг у нас встроенный девайс с 4 мегабайта флеша

Кросс-компиляция? Не, не слышали. Да и нативные программы лучше подходят для ограниченных ресурсов.

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

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

вим запустить

Подготовить

отдельный комп с развёрнутой средой разработки под рукой

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

Vim весит меньше, чем компилятор. И это я ещё забыл упомянуть, что нужен будет программатор, чтобы залить обновлённый бинарник. Или sd-карту выдёргивать. Или девайс уже установлен и работает в недоступном месте. И интернет до туда медленный и копировать новые бинарники долго.

И это я ещё забыл упомянуть, что нужен будет программатор, чтобы залить обновлённый бинарник. Или sd-карту выдёргивать.

Не нужен. Есть FTP/SFTP.

И интернет до туда медленный и копировать новые бинарники долго.

На «встроенный девайс с 4 мегабайта флеша»? Не думаю. Да и бинарники по отдельности могут быть довольно маленькие, особенно если активно использовать динамическую линковку.

Если и нужны скрипты, то лучше использовать Python или Lua, на них код читаемее.

Кросс-компиляция?

Бедная домохозяйка.

Бедная домохозяйка.

clang это умеет из коробки без особых усилий. Да и зачем домохозяйкам программировать «встроенный девайс с 4 мегабайта флеша»?

Не нужен. Есть FTP/SFTP.

Не все девайсы имеют сеть. Иногда только UART.

Если и нужны скрипты, то лучше использовать Python или Lua, на них код читаемее.

Интерпретатор питона слишком жырный. Lua не жирный, но зачем он, если баш и так уже есть из коробки

Действительно зачем?

Можно же просто подправить несколько строчек на Bash.