Я изначально отвечал на фразу о том, что systemd похож на инициализацию windows. И ответ прост: он не похож от слова "совсем".Слушай, у каждой задачи есть свой инструмент.
1. Использовать Linux на крупном развертывании с десктопами - это сущий ад и кромешная тьма рутинной работы прежде всего из-за проблем с PAM и отсутсвия стандартизации юзерспейса. То что ты считаешь достоинством (возможность настроить в систему под себя) - чудовищный недостаток в корпоративной среде, потому что в конечном итоге ты все сам и будешь настраивать. А я не хочу, я стар. И писать скрипты на питоне, которые меняют конфиги. И писать шаблоны конфигов под скрипты. Всех этих задач в Windows нет именно из-за того что в ней стандартизированное API и стандартизированный юзерспейс. И если лично ты не знаешь этого и тебе сложно - это проблемы твоей компетентности, а не самой ОС.
2. Не надо пихать Windows NT в эмбедовку. Она её исторически не умеет, потому что она не для этого. Microsoft пыталась выйти на этот рынок с переменным успехом и сейчас пытается (ныне покойная реалтаймовая и микроядерная Windows CE, сейчас Windows IoT). Но проблема всегда только в поддержке чипов. Система инициализации не имеет никакого значения. Была еще катастрофа под названием Windows XP Ebdedded в банкоматах, так она 100 лет как мертва, не выдержала конкуренции с QNX. Опять же это не про РФ, а про остальной мир. В РФ изначально экономили на банкоматах. Там всё плохо.
> Про PAM
Я пример привел, что взаимоотношение между Winlogon и LoginUI такое же, как между PAM и GDM/KDM, ну да ладно. Теперь развенчаем твои влажные мечты про PAM.
1. PAM предполагает что каждый вход в систему локальный и производится пользователем. То что к нему можно прикрутить модуль сетевой аутентификации не меняет этого факта. ОС не видит разницы. Это вопрос авторизации, а не аутентификации.
2. В PAM нет полноценной поддержки Kerberos, есть только возможность логинить пользователей относительно KDC, этого мало. Когда эта дура (подсистема PAM) сможет на системный TGT получить вторичный TGS без спрашивания паролей у пользователя по 10 раз, приходи снова со мной поспорить. Дальше было бы неплохо еще Claims научиться принимать и обрабатывать (для нужд авторизации), чтобы Kerberos 5 полноценно поддерживать.
3. PAM не поддерживает никакое корпоративное SSO и не будет, потому что эта дурацкая подсистема работает только в пределах логина и пароля локального пользователя. Примечательно, что в PAM можно напрямую заюзать разве что Oauth2, но это другое. Мне нужно вменять политики авторизации пользователям, а Oauth2 это про согласие пользователя дать доступ к данным из одного облачного сервиса в другой.
4. Я сейчас даже не буду расписывать, что там с маппингом и какие там костыли вылазят, потому что это зависит от конкретной реализации модуля PAM.
Ты мне объяснять тут пытаешься как PAM работает и что он pluggable, и что оно поддерживает AD... Оно само поддерживает FreeIPA? Не-а, cам он не способен. Ему нужен sssd как клиент, а для AD тот же sssd (не работает с федерированными лесами) или winbind (косячит маппинг, не удаляет кэш).
5. То что ты не осилил поставить Credentials Provider в WinLogon - это не проблема Windows. Это либо твоя некомпетентность, либо писателей самого провайдера, дай угадаю, криптопро вонючее пихали в WinLogon или очередной анало-говнетный криптопровайдер ГОСТ, или опять банкоматное барахло на XP?
> Это винде не помогло. А в lsass еще и вулнов исторически десятками было. Msblast и его многочисленные потомки это дело одобряют. В линуксе такой класс уязвимостей отсутствует.
Равно как и пользователи десктопов... Ой всё... начинается демагогия про безопасность.
SUID-биты на ФС, отсутствие нормальных ACL в ядре (то что есть опционально и не применимо к процессам), системы мандатного конроля, которые вынуждены переизобретать велосипеды вокруг отсутсвия ACL. Причем колеса настолько квадратные, что я мало знаю людей которые умеют жить с включенным SELinux (я один из тех кто умеет). Linux - это Неуловимый Джо. Вирусы пишут только тогда, когда есть глупые пользователи у которых можно массово воровать деньги. Таких в Linux отродясь не было вплоть до появления Android, а там-то вредоносных приложений нету, ага... пффф. При чем тут lsaas-то? Lsaas - это стандартизированная реализация keyring. В Linux они тоже есть, но как и всё что в нем есть из служебного ПО, оно прикручено криво и сбоку. А вменение политик, это да... lsaas просто ужасен, то ли дело Polkit, вот где истинная безопасность (это сарказм, если ты не догадался).
> ... А имеючи SYSTEM я в системе бог....
Я читаю этот абзац как очередное признание в некомпетентности, потому что на практике ты просто получил права root. Я в упор не понимаю, в чем проблема получить права LOCAL SYSTEM для локального администратора? Так в Windows называется root. То есть сделать "su" в Linux это тоже проблема безопасности? Вот-те раз, вот это новость. Или тебя беспокоит, что ты парольку не вводил? В чем проблема то? То что ты и твои друзья-двоечники Windows не знают - это ваши церебральные трудности.
> И леденящий душу INACCESSIBLE_BOOT_DEVICE...
Такое происходит при условной "замене матринской платы", когда диск от одного компа подсунили на другой, причем не разу не похожий, тупо не найден драйвер контроллера. На практике чаще всего происходит при конвертации виртуальной машины из одного формата виртуализации в другой, VMware c поддержкой HT на KVM с выключенным HT, например. Чинится через WinRE/WinPE парой команд. Собственно примерно то же самое происходит с машиной Linux при такой же конвертации, если в initramfs не нашлось драйвера контроллера, причем один в один. Никакой особенной проблемы в этом нет, что так "леденит душу", не понятно...
Использование initramfs это не хорошо и не плохо. То что теоретически в Linux можно вкомпилить статически и не использовать initramfs не значит, что это широко используется. Это просто такое решение, потому что в отличии от Windows, у которого нормально работает динамическое связывание драйверов с ядром разных версий из-за стабильного ABI у Linux приходится изголяться. Кроме того решение по восстановлению (recovery) в Linux накручено вокруг initramfs, в то время как Windows и всевозможные BSD строят эту систему отдельно, опять же через RAM-диск.
> Linux не грузит 2 раза драйверы - если модуль вкомпилен в ядро или уже загружен с initrd, нет никакого смысла грузить его еще раз. Кернел не будет запрашивать загрузку модуля дважды.
А если бы у бабушки были бы яйца, она была бы дедушкой. Пожалуйста, прекратите сочинять истории про то что можно теоретически и нельзя делать с initramfs. В большинстве дистрибутивов, кроме собранных лично вами LFS, initramfs управляется скриптами пакетного менеджера и включает необходимый минимум драйверов для загрузки. При этом выигрыша от его использования нет. Везде, где нужно перепнуть HAL венды в образе, чтобы система загрузилась, везде придется пересобрать initramfs.
> И это хорошо, потому что позволяет имплементить РАЗНЫЕ системы.
Нет, это ужасно. Я когда слышу про РАЗНЫЕ меня начинает тошнить. Мне нужно только стандартизированное API, стандартизированное ABI и предсказуемая ОС. То что конкретно NT не работает с эмбедовкой - это и не надо. Это ОС для домашних компов и корпоративного сегмента. Всё что связано с IoT для меня не интересно от слова совсем, пусть там будет Linux, хоть на что-то железное он годится, а то одна сплошная виртуализация. И да, для меня Windows предсказуем, а решение на Linux, который собрал васян поверх дистрибутива №146 версии 21.08 без грамма документации к своей работе, а потом уволился с психу, потому что фирма не возжелала перевести весь софт на Linux и вообще не признала его гениальности - это суровая реальность. Для меня фанатики Linux - враги, потому что увеличивают мне работу фактом существования на этой бренной земле.
Слушай, в Linux как и в любой ОС построенной архаичных технологиях из 70-х в юзерспейсе может быть только 1 процесс, PID_1, он же init, а все остальные - дочки его. Вся многопользовательская структура эмулируется поверх одного единственного экземпляра оболочки. В этом вся суть старого UNIX, также работали бесчисленные реализации DOS. Windows 3.11 делала также. Запускала DOS и в нем крутила оболочку. Ты пытаешься сравнивать понятие сессий Windows NT, которые в свою очередь появились изначально в VMS, с той эмуляцией, которая исторически присутствует в старых UNIX и была заботливо скопирована в Linux. Видимо ты не понимаешь, разницу в ОС.
> В винде ничего сравнимого не припоминаю, SCM вообще относительно пофиг на участь сервисов.
Вот всегда душно с такими как вы. Вы Windows не знаете настолько, что не умеет ни читать логи, ни понимать, что там написано. Видно там где, какой сервис куда упал. Вешайте фильтр на лог и кастуйте асинхронно любое событие в планировщике. В чем проблема то? Лог прекрасно сериализован в XML, пберите XPath-фильтр и при появлении сообщения кастуйте себе скрипты на здоровье.
> И тем не менее, операционки в чем-то друг на друга похожи.
Linux это весьма вольная интерпретация UNIX, а Windows NT - это такая вольная интерпертация VMS для x86. Они не похожи от слова "совсем".
> В винде же - апи же - так что сервис должен быть DLLкой с характерным апи. А если у меня не оно я вообще в пролете. И получается что автоматизировать и кастомизировать что-то в винде это боль.
А что такого страшного в использовании API? Ну кроме банальное неграмотности...
Взял ты значит PowerShell, подключился к объектам и всё сделал. Всё подробно задокументировано английским по белому.
Ну то есть смотри, в обычной оболочке ты работаешь со стандартным вводом-выводом и данными которые валятся туда же. В объектно ориентированных скриптовых средах вроде Python или PowerShell ты работаешь с объектами. Причем у PowerShell есть еще и то отличие, что вся оболочка объектно ориентированная, то есть терминал ея - суть текстовое отображение объектов из памяти, которые она получила в результате выполнения команды. Ну или питон тот же. Ну взял ты и постучался на REST API получил JSON в скрипте и десериализовал в словарь так понятнее? Просто ты пишешь всякое про эмбедовку, но что-то мне подсказывает что ты нифига не разработчик, раз у тебя на API алергия. Да у Windows омерзительный и архаичный cmd (ради обратной совместимости, энерпрайз же и там этого нету) и Windows Script Host ничем не лучще (Visual Basic Script и JScript - очередная ошибка MS), но PowerShell-то работает. Он может показаться поначалу непривычным тому человеку, который не знает ни одного объектно ориентированного языка, но тем кто хотя бы на питоне пишет там нет ничего сложного, ну разве что понять логику работы CLR, но это не рокет саенс.
Вот значит у тебя есть скрипт, который радостно автоматизирует тебе всё начиная от каждой вендовой софтины, которая посмела у тебя в системе COM-объект зарегистрировать до самого ядра ОС, которое доступно ненапрямую, но доступно через фреимворк P/Invoke прямо из скриптов.
Когда ты пишешь, что скриптовать венду это боль - ты сильно ошибаешься. Ты просто не знаешь как, но этому можно всему научиться, если хочется. А если не хочется, то и не учись, но не пиши всякие ошибочные глупости про нее на технических форумах.
Я из твоего комментария сделал вывод что ты интересуешься IoT и прочими R&D. Windows тебе не нужен, MS там всё просрала из-за балмера, его восьмерки и прочей дряни вокруг магазина (UWP кстати они закрыли лол, последнее балмеровское наследие) пытаются пилить Windows IoT для замены Windows CE, но они в отстающих.
P.S меня не хватило на модульность, но тут видимо очередное недопонимание. Для тебя модульность - это возможность заменить, а для всех остальных модульность - это модульность в смысле подхода к программированию. Немодульность systemd в том, что у тебя udev совмещен с systemd и они это сделали тупо, чтобы подвязать всех на свой systemd технических причин на это нет. В Windows наоборот, с программистской стороны разделяют инит. И вообще. Ты понимаешь, что в Windows инициализация полностью отдельна от SCM а в UNIX так быть не может из-за того что юзерспейс форкается от PID1? Хватит сравнивать теплое с мягким.
P.P.S Еще раз, мне плевать на IoT, умные дома и прочий булщит, как и большинству Enterprise-админов. Самая умная бытовая техника которая у меня есть дома - это принтер и то я держу при себе дубину, на случай если он выйдет из-под контроля. Но если ты собрался развиваться на этом поприще и что-то разрабатывать себе, чтобы не было так узко, научись всё же немножечко программировать, поймешь хоть, что наличие объектного API в 100500 раз лучше чем парсить текстики из stdout.
