> systemd вдохновлен launchd из Mac OS, которая пришла там в своё время
> на замену SysVinitИ солярис тоже. Но их покусала оверинженерия в неправильном месте, с этим их XML. Соляра с горя аж кеш в скулайт сделала. Вот это костыль!
> Вы там обнаружите, что:
> 1. Linux использует initramfs. RAM-диск с отдельной копией загрузочных драйверов и их
> конфигурацию. В то время как Windows имеет единый OS Image
FYI использование initramfs опционально. Можно вкомпилить все нужные дрова для блочных устройств и фс в ядро как вариант. И тогда для запуска системы хватает только ядра, которое все сделает само. Также, даже если в какой-то ситуации нужно или желательно использовать initrd (и даже DTB) может быть приаттачен к 1 файлу и 1 файла хватит для загрузки.
Такая структура загрузки позволяет грузить Linux с вообще чего угодно. С минимумом допущений. Можно загрузиться даже с бельевых веревок, если дрова ядра или юзермод в initrd знает как данные по ним получать. Последнее заодно избавляет от кодинга ядерного драйвера в обязаловку.
> в котором все служебные файлы учтены и внесены в базу DISM, а
> конфигурация в реестр.
И все это в результате мучительно в конфигурации, не слишком гибко и работает либо так как MS это себе представил - либо никак. И леденящий душу INACCESSIBLE_BOOT_DEVICE...
> Выбор ядра, разновидности HAL и набора non-PnP стартовых драйверов (контроллеры,
> сетевые карты) определяется иначе. BSD в этом смысле такая же.
Поэтому то линух и используют в конфмгурациях где нужно именно кастомное загрузочное окружение. В его случае загрузиться можно откуда угодно. Как угодно. Допущений минимум.
> Ей не нужно по 2 раза по 2 раза грузить драйверы грузить драйверы.
Linux не грузит 2 раза драйверы - если модуль вкомпилен в ядро или уже загружен с initrd, нет никакого смысла грузить его еще раз. Кернел не будет запрашивать загрузку модуля дважды.
> 2. Session Manager Subsystem - это нифига не systemd.
Примерным аналогом системды является SCM. Хотя системд делает и нечто отдаленно напоминающее вон то - он может менеджить пользовательские сеансы, в том числе запуская себя "в юзерском режиме". Это все правда опционально, в отличие от виндов.
> Причем тут нужно понять, что само понятие сессий Windows NT отличается от
> того что этим словом называется в UNIX.
В случае системды они некоторые идеи позаимствовали и сессия пользователя в понимании системды имеет что-то общее с вон тем. Хотя и отличия наверняка имеет. Потому что системы сильно разные.
> В отличии от systemd инициализация Windows модульная:
Это все булшит бинго. На практике винда некастомизабельный монолит где все прибито на гвозди, а если какой-то кастом понадобился... ну вот поэтому все линух в эмбедовку и используют. А винды там как бельмо на глазу. Даже в банкоматах то лужайкой светит, то скринсейвер пашет, то вообще антивирус прям на десктопе вкалывает в графическом режиме - с перехватом сеанса с точскрина, где можно в "проводнике" шарахаться минут пять в недрах такой "эмбедовки" до того как морда вышибет в .
> lsass.exe - управление ключами и политиками безопасности отдельно
Это винде не помогло. А в lsass еще и вулнов исторически десятками было. Msblast и его многочисленные потомки это дело одобряют. В линуксе такой класс уязвимостей отсутствует.
> Причем в тот момент когда Linux движется к монолитности, Windows наоборот увеличивает
> мелкость разбиения.
Вообще-то системд тоже достаточно модульная штука. Скажем дебиан всякие NTP, запуск виртуалок и проч - в опциональные пакеты порезал. И в отличие от виндов это, таки, реально заменить на свои компоненты. Если не нравится journald можно и свой логгер нарулить. Journald даже умеет форвард того что в него валится в других, а можно и совсем его отключить. От винды такой благодати разумеется не дождешься. Там логгер 1 - правильный по версии мс. И довольно хреновый как по мне.
> 3. WinLogon и морда его LogonUI - это вам не LinuxPAM с
> GDM/KDM и тем более не systemd-logind
PAM в линуксе вообще ортогонален GDM/KDM а systemd-logind разве что пользуется им. Это отдельная подсистема аутентификации юзерей, то что софт открывающий сессию пользователя пользуется этой подсистемой логично. Но оно живет себе даже если и никаких *DM нет. Может жить даже в полностью "неинтерактивной" системе, в отличие от виндов не привязано к гую, сеансам и проч как таковое. И "P" в PAM означает "pluggable". Это значит что пользаков можно авторизовать через что угодно. Хоть AD. Хоть бельевые веревки. Даже если изначально и не было предусмотрено.
> - WinLogon понимает разницу между сессиями пользователей и видит что есть удаленные,
> интерактивные, консольные, батч-сессии, сервисные и прочее. В Linux PAM сессии локальные.
В результате винды сильно делают мозг аспектами которые вообще делать мозг не должны. А у удаленных сессий вылезает более 9000 грабель на ровном месте. Линух от этого булшита избавлен и логин рута по ssh ничем не хуже чем локальный. Что избавляет от массы танцев с бубном.
> - WinLogon поддерживает Kerberos в отличии от PAM
Линух 100500 лет поддерживает Kerberos. В том числе и в PAM если оно надо. В этом пойнт PAM и состоит - он расширяемый, его под что угодно можно расширить и дополнить. А в винде если потребовалась кастомная авторизация пользователей, в виде отличном от того что там себе майкрософт возомнил... вот это да, боль. Я видел пару таких систем. И они имели множество технических проблем. В отличие от линуха. Вы смеете утверждать что это - фича?!
> - Он поддерживает сторонние модули не хуже чем UNIX PAM.
Вообще-то намного хуже. Я видел как это работает - и это как правило являет собой кусок проблем. Особенно если хотели что-то заметно отличающееся от MS'овских идей как это делать.
> Windows там целая схема взаимодействия с LSA, как откуда берутся учетные
> данные, какие модули можно подключить, в каком порядке все это работает
> и это еще и настраиваемое не меньше чем UNIX PAM.
На практике однако решений умеющих это полторы штуки, все дико переусложненное, крайне глючное и имеющее проблемы с секурити. Я таким способом апгрейдил птичьи права до SYSTEM - спасибо майкрософту за переклин на GUI. Кодеры в результате лажают предусмотреть более 9000 незапланированных взаимодействий софта. А имеючи SYSTEM я в системе бог. Даже админов могу повынести и они так сразу не сообразят как вообще DENY с себя снять, для этого им самим надо будет себя до SYSTEM в правах подкинуть сперва, а умеют так далеко не все виндоадмины, это больше R&D'шникам актуально.
> 4. Userinit - он существует в отличии от systemd
Системда умеет в юзерском режиме работать, --user. Видимо поттеринг таки посмотрел как другие делают в своих системах до того как кодить. И это удачная идея.
> - разделение на систему инициализации пользователя и системную
> - оболочки запускаются только в пользовательских сессиях
systemd --user тоже менеджит исключительно сервисы пользователя. Но в отличие от виндов это все опционально. Если я хочу другой дизайн ситемы, системд не стоит на этом пути. Актуально для всякой эмбедовки где "мультиюзерность" как таковая весьма условная и вон то скорее мешается чем помогает, создавая много дурных технических проблем где их быть не должно.
> том, что в Windows система инициализации она инициализирует Win32 и сессии
> в пространстве пользователя, в то время как в Linux у нас
> есть процесс 1, от которого всё форкаются и все процессы являются
> дочками PID 1.
И это хорошо, потому что позволяет имплементить РАЗНЫЕ системы. Под РАЗНЫЕ требования. Вон тот сервак, этот десктоп и одноплатник в эмбедовки - они пересекаются только местами. А местами хотят очень сильно разного. В винде так нельзя. Это делает винду довольно мучительной на серверах и малопригодной для эмбедовки с глубокой кастомизацией. Исключение всякие кастомные извраты типа WinCE но это вообще другая винда и в целом оно отмирает. А линух напротив набирает обороты как решение для встраиваемых систем.
Если я как имплементер хотел рисовать веб-фэйс, мне вообще весь вон то даром не упало. Сие однако не мешает авторизовать логин с веба в PAM как системного юзеря. Так что пароль административного юзера в вебе, и его же логин в ssh каком - одинаковые. И это просто имплементить. В винде же что-то такое убьешься делать. И это все не подразумевает какой-нибудь AD в обязаловку, может и самодостаточный юнит быть, с 0 допущениями.
> используется несколько шин межпроцессного взаимодействия, главная из которых COM+DCE/RPC
> = DCOM. Все аббревиатуры гуглятся.
И этот DCOM получился весьма отдельной болью для девелоперс, девелоперс...
> зависимости процессов друг от друга с общей памятью. Вместо этого там
> нормальное API.
А в результате в лине я могу прописать запуск вон того скрипта тюнящего параметры системы на автомате за 2 минуты. Что в системду что в классический инит. И система будет делать что надо. В винде же - апи же - так что сервис должен быть DLLкой с характерным апи. А если у меня не оно я вообще в пролете. И получается что автоматизировать и кастомизировать что-то в винде это боль. И нихрена это не фича как только захочется что-то отличное от десктопника.
> 1. Windows имеет модульный Init
И в чем это проявляется? SCM например не особо кастомизабельная штука и как максимум ему донавесили фееричнейшие костыли. А в целом система инициализации виндов это лоскутное одеяло. И когда что-то отваливается, все становится довольно тухло. Аналога systectl который покажет общесистемный статус и что отвалилось - в винде нет. А SCM с гибкостью чугунной гири приводит к тому что имплементеры вооон там на банкомате запустили антивирус из autorun вместо этого. Правда в результате пользователь может 5 минут после ребута делать в системе что хочет, но кого это волнует, право? :)
> 3. Win32 это не POSIX, и там разное понимание межпроцессного взаимодействия.
И тем не менее, операционки в чем-то друг на друга похожи. А кроме POSIX у линуха есть и свои собственные идеи насчет некоторых вещей. Скажем clone() вообще скорее из Plan9 перекочевал.
> 5. systemd свистит и пердит так, что он внутри себя реализует юзерспейсное
> API для абстракции оборудования (udev),
Это апи... интерактива с оборудованием, скажем так. Нечто типа гибрда плагнплея с автоматизацией.
> в Windows работа с устройствами одна и она сразу доступна, ее не надо костылить в юзерспейсе.
А в результате я вот udev'ом могу вот этому непривилегированому пользователю дать права поработать с вот этим девайсом а остальным фигу. И назначить одупляемое имя - /dev/mcuboard0 как-то сильно понятнее чем абстрактные блабла. И сразу нет вопросов почему эта прога лезет вон туда - у одноплатника расширение на UART в виде микроконтроллера, и хорошо когда ему можно в системе нормальное имя дать. И пустить в него только пару нужных процессов. А остальных куда подальше послать от греха. И это все просто в реализации. В винде такое убьешься делать. Кроме всего прочего это и при R&D удобно, система сразу пускает меня R&Dшного с чисто-юзерскими правами флешануть воон тот МК. А других пользаков/сервисы/... - да сейчас.
> опять же, в Windows такого нет, там все это есть, но
> отдельными службами без привязки именно к Init.
А еще у системды есть например нормальное апи вачдога. И сам он умеет вачдог обслуживать, подтверждая что он живой. Получается иерархическая верификация системы. А при сбое юнита возможна интеллектуальная обработка этого - скажем другой юнит запустить. Как handler того что у нас тут системапроблемы. В винде ничего сравнимого не припоминаю, SCM вообще относительно пофиг на участь сервисов. Не говоря про вачдог и общий health check системы. Это очень удобно и круто для автоматических систем где некому нажать "any key" или что там еще.
