> Слушай, у каждой задачи есть свой инструмент.Я предпочел линух потому что он - универсальный, мощный и гибкий инструмент. От фигни с SD карту до суперкомпа.
> 1. Использовать Linux на крупном развертывании с десктопами - это сущий ад
> и кромешная тьма рутинной работы прежде всего из-за проблем с PAM
> и отсутсвия стандартизации юзерспейса.
Решаемо, если с умом. Но да, AD делался под корпов и имеет сильные стороны там. Однако и грабель есть. О них отдел маркетинга не расскажет. Если разваливалась синхронизация DC или аж приходилось ЭТО из бэкапов, приключение такое что проблемы линя меркнут! Это надолго и все это время всю фирму или минимум филиал будет колбасить.
> То что ты считаешь достоинством (возможность настроить
> в систему под себя) - чудовищный недостаток в корпоративной среде,
В общем решаемо - оговариванием что будет вот такой дистр на всю толпу. Но это для взаимозаменимых винтиков. Более-менее мощным разработчикам, интеграторам, майнтайнерам и подобным продвинутым сие враг. Клинит эффективность. Поэтому лучшие, дерзкие и прорывные технологии меняющие мир часто делают стартапы, а не...
> потому что в конечном итоге ты все сам и будешь настраивать.
Это опять же делается 1 раз - в корпоративном или каком-то ином тиражируемом окружении нет проблем ограничиться 1 или несколькими "типовыми конфигами" железа, ролей/функциональности и проч. А R&D - он всегда кастомный. Заклинить его можно - но хуже от этого только вам.
> А я не хочу, я стар. И писать скрипты на питоне, которые меняют конфиги.
> И писать шаблоны конфигов под скрипты.
Я вообще ничего с питоном не делаю. Не мешает уметь нечто типа системной интеграции. И я потом тиражирую системы десятками-сотнями если надо. Как вы уже поняли, я отстрою образа под задачу где все ЗБС и потом будет литься за пару минут. В винде я такое даже пробовать не буду, слишом сложно и враждебно оно там и мне не нравится результат.
> тебе сложно - это проблемы твоей компетентности, а не самой ОС.
Я всего этого наелся досыта. Меня утомил корп-шит и стагнация. Я вырос из этих рамок. Настало время идти вперед. С виндой это невозможно.
> этот рынок с переменным успехом и сейчас пытается (ныне покойная реалтаймовая
> и микроядерная Windows CE, сейчас Windows IoT).
Для лично меня то что винда не масштабируется и контролируется 1 вендором - проблема. Это не позволяет реализовывать кастом и интересные идеи которые давно хотелось.
> Но проблема всегда только в поддержке чипов.
Linux для меня как системщика эпичнее, чтобы на его освоение время и силы потратить. И я такой не 1. Где будет лучше с дровами и вообще качеством и перфомансом кернела - угадайте ;)
> Система инициализации не имеет никакого значения.
Решительно не согласен. Для автономно работающих систем важна авторекавери на единичные upset, логирование для анализа, возможности по усилению безопасности системы, типа контейнеров и урезания доступов в части системы для сервиса которому оно явно ни к чему. В винде этого всего изначально вообще не ахти - так что и для серверов она не очень. У майков есть специфичные тулсы для групадминства, но и они - не очень.
> не про РФ, а про остальной мир. В РФ изначально экономили
> на банкоматах. Там всё плохо.
Эта проблема не уникальна для РФ. Хотя в РФ в целом культура инженерии похуже.
> 1. PAM предполагает что каждый вход в систему локальный и производится пользователем.
Если действо делается программой - оно таки локальный феномен. А сетевые кренделя таки навесная фикция.
> То что к нему можно прикрутить модуль сетевой аутентификации не меняет
> этого факта. ОС не видит разницы. Это вопрос авторизации, а не аутентификации.
И? В конечном итоге мало влияет на результат. Сетевые логины по своему красивы... и создают неожиданные проблемы. И с кешированием кренделей, и с суперктичностью DC, и с возможностью поиметь все и вся быстро и оптом. Многие виндовые админы даже не задумываются о таком. А напрасно.
> 2. В PAM нет полноценной поддержки Kerberos, есть только возможность логинить пользователей
> относительно KDC, этого мало.
В PAM есть плагины. И какими их там напишут - то и будет. Если вон то было никому не - да и хрен тогда с ним. Мне вообще керберос не нравится.
> Когда эта дура (подсистема PAM) сможет на системный TGT получить вторичный
> TGS без спрашивания паролей у пользователя по 10 раз, приходи снова со мной поспорить.
Мне оно вообще не надо. И (после долгих и плотных отношений с керберосом и АДом) я пришел к выводу что я не фанат этого. Излишне централизованное и весьма хрупкое нечто.
> 3. PAM не поддерживает никакое корпоративное SSO и не будет, потому что
> эта дурацкая подсистема работает только в пределах логина и пароля локального
> пользователя.
Я вообще считаю это все антипаттерном из соображений секурити компьютерных систем. И опять же ничего принципиально мешающего накодить модуль чекающий кренделя в SSO не вижу.
> Примечательно, что в PAM можно напрямую заюзать разве что Oauth2,
А с некоторыми костылями - почти что угодно. И это хотя-бы предусмотрено. В винде я вообще для такого видел лишь пару решений - и они были с кучей специфичной кривизны. Которую к тому же вон те проприетарщики не рвутся фиксить. А убедить майкрософт поменять апи... да их даже пофиксить баги убедить малореально.
> это про согласие пользователя дать доступ к данным из одного облачного
> сервиса в другой.
С другой стороны это более распределенная моделька. А что насчет согласия и проч - в эту игру могут играть двое. Я без особых проблем получу локаладмин на винде, а потом и систем. После этого я легко объясню энтерпрайз админам что думаю о их потугах полисовок. А если они еще и зайдут посмотреть - что я про кешированые крендели говорил? Врага надо знать в лицо...
> тот же sssd (не работает с федерированными лесами) или winbind (косячит
> маппинг, не удаляет кэш).
Да так то и AD иногда косячит. И майкрософт косячит. В либах, программах, решениях. И я как-то случайно обнаружил что можно полгода переписываться с саппортом от лица большой компании из фортуны 500 и проблема не будет решена. Ну а в лине у меня вообще для решения проблем другие тайминги. И еще не было системной проблемы мешавшей мне которую я бы не зарулил. Мне так больше понравилось.
> провайдера, дай угадаю, криптопро вонючее пихали в WinLogon или очередной анало-говнетный
> криптопровайдер ГОСТ, или опять банкоматное барахло на XP?
Не угадали. Но в силу специфики и у более приличных фирма с такими вещами грабли.
> Равно как и пользователи десктопов... Ой всё... начинается демагогия про безопасность.
У виндов с этим есть определенные проблемы. И у ада особенно. Недавние взломы ряда фирм с поимением АДа подтвердят. Свежачок - сам мс и их абажур, хихи :)
> SUID-биты на ФС, отсутствие нормальных ACL в ядре (то что есть опционально
> и не применимо к процессам), системы мандатного конроля,
В линухе внезапно есть системы мандатного контроля. Если надо. Если. Я могу такие права в NT нарисовать что ни 1 админ сразу не прочухает левак. И приколько когда даже энтерпрайз админу DENY и хрен снимешь под именно его кренделями. А как эскалировать до SYSTEM знает далеко не каждый первый. Последнее слово за именно _локальным_ пользователем SYSTEM :). ИМХО: я могу достичь сравнимах с MAC результатов с куда меньшей возней.
> знаю людей которые умеют жить с включенным SELinux (я один из тех кто умеет).
А я умею быть атакующим. И знаю что должно быть удобно легитимному админу и неудобно атакующему. Я знаю что ненавидел бы как атакующий. Вы с прописыванием SELinux вон той проге сколько будете возиться? А вырубает его каждый первый эксплойт. Мне такие соотношения не нравятся, лучше когда наоборот.
> Linux - это Неуловимый Джо.
Да вот мне прилетело не так давно. Но щиты звездного крейсера удержали, урон минимальный, можно продолжить. Конечно, пофиксив проблемный сервис и обновив систему. Все же партиционирование великая вещь. Списал мелкую виртуалку в утиль, зареспинил - и на этом последствия закончились. И весь "генератор щитов" сделать проще чем SELinux настроить. А защищает от всего - вплоть до выноса кернела (виртуалки) в хлам. Оно вообще не могло сисколы в хост напрямую и права у него юзермодовского процесса аж. Абстракции великая вещь.
> Вирусы пишут только тогда, когда есть глупые пользователи у которых можно
> массово воровать деньги.
Под винду по-моему сейчас пишут в основном винлокеры-вымогатели. Вирусы они весьма условные.
> Таких в Linux отродясь не было вплоть до появления Android,
А вон там на гитхабе Mirai лежит. Интересен в основном как делать супер-кроссплатфоменный софт с нулевыми допущениями о системе, в остальном ничего такого.
> ужасен, то ли дело Polkit, вот где истинная безопасность (это сарказм,
> если ты не догадался).
Polkit напоминает - внезапно - UAC. ИМХО в винде с этим всем еще кривее и секурити хуже.
> Я читаю этот абзац как очередное признание в некомпетентности, потому что на
> практике ты просто получил права root.
В винде SYSTEM мощнее любого админа. В ряде случаев DENY выставленный SYSTEM только он и может снять. И есть ситуации когда админу надо сперва эскалировать до SYSTEM и только потом он это сможет. В свое время я показывал ряд стебных фокусов виндоадминам, и оставлял себе дорожку к эскалированию прав которую они не нашли. Крутая, грите, система прав? Оок, только аудиту почти не подлежит из-за переусложненности :)
> в чем проблема получить права LOCAL SYSTEM для локального администратора?
Далеко не любой виндоадмин в курсе что это можно и (иногда) нужно. Я проверял :)
> Так в Windows называется root.
Root тоже понятие относительное... скажем root под ядром в режиме lockdown менее мощный чем рут в обычном случае. Теоретически корпы это сделали чтобы вас на права в андроидах обувать. Практически это не мешает мне использовать сие как секурити фичу для себя. Я то хозяин системы, вплоть до того что ключ подписи модулей - мой. Это мои системы, они служат мне.
> То есть сделать "su" в Linux это тоже проблема безопасности?
Просто довольно странно что у системы прав больше чем у ее хозяина (Administrator). Ему прозрачно намекают что хозяин не он. В линуксе нет прямого эквивалента этого соотношения, рут изначально всемогущ.
> ты и твои друзья-двоечники Windows не знают - это ваши церебральные трудности.
Да вообще я винды не так уж плохо знал. Примерно до 2008, где оно меня окончательно достало.
>> И леденящий душу INACCESSIBLE_BOOT_DEVICE...
> Такое происходит при условной "замене матринской платы", когда диск от одного компа
> подсунили на другой, причем не разу не похожий,
Происходит по более 9000 поводов, вплоть до апгрейда версии виртуализатора, типа диска, переключения AHCI vs RAID vs IDE-mode в биосе и проч. Де факто в винде это очень хрупкий и ломкий механизм. И весьма фатальный.
> KVM с выключенным HT, например. Чинится через WinRE/WinPE парой команд.
Кроме всего прочего, за время загрузки WinPE я линух нарулю три раза подряд и все завертится. Более того - я в лине могу себе загрузочный образ собрать в два счета. Прям из моего десктопа. И эта виртуалка - мой десктоп. Только минимизированый и - в виртуалке. С виндой я так вообще и пробовать не стал бы, сильно геморнее.
> конвертации, если в initramfs не нашлось драйвера контроллера, причем один в
> один. Никакой особенной проблемы в этом нет, что так "леденит душу", не понятно...
В принципе да. Но в лине в целом контроль над этим лучше. У меня есть ряд конфиг где для их контроллеров драйвер вообще compiled-in, и не может не прочитаться. Там такой отказ невозможен как категория. By design.
> Использование initramfs это не хорошо и не плохо.
Это круто и гибко. Так можно много чего околосистемного обыгрывать. Я так даже минимальный рутфс своего дистро так в RAM-only режиме цеплял. При этом сие как бы привычное окружение. С другой - с околонулевыми допущениями. Может как раз, образ на таргет задеплоить или что там, с минимумом причин развала. ИМХО круто уметь самому в супер-инсталлеры :P. Майки тоже к этому пришли, только как обычно - ограниченно и горбато.
> вкомпилить статически и не использовать initramfs не значит, что
> это широко используется.
Это используется лично мной на выводках одноплатников и виртуалок, особенно как часть моих "сервисных" тулкитов для создания виртуалок, деплоймента образов, флешевания пустых устройств и проч. А, да, в лине это достаточно просто для того чтобы я это все смог.
> разных версий из-за стабильного ABI у Linux приходится изголяться.
Вон то к ABI вообще мало отношения имеет. Больше к тому факту что - таки - драйвер блочного уровня, файлухи и проч - может быть недоступен, а чтобы прочитать ФС надо чтобы блочный драйвер и ФС уже были. У винды по этому поводу есть костыли когда часть early дров грузится бутлоадером. Бутлоадер становится очень сложной штукой в результате. И кста если хочется крутой бут, Linux умеет kexec(). Тогда "бутлоадер" умеет все что умеет линукс, можно и на тему сложных бутов мастеркласс дать, с более другими фичами :)
> Кроме того решение по восстановлению (recovery) в Linux накручено вокруг initramfs, в то
> время как Windows и всевозможные BSD строят эту систему отдельно, опять же через RAM-диск.
В общем то невелика разница. Линух умеет и RAM диски, с произвольной фс. Лив образа и т.п. так и сделаны - цепляется squashfs какой. В энных случах его может читать в рам и бутлоадер. Иногда оптимальнее, у squashfs отсутствует фаза распаковки, если он большой это аргумент. С другой стороны "рандомный" доступ медленнее.
> Пожалуйста, прекратите сочинять истории про то что можно теоретически и нельзя
> делать с initramfs. В большинстве дистрибутивов, кроме собранных лично вами LFS,
Я практикую кастомизацию систем под задачи, какое мне дело до "большинство дистров"?
> initramfs управляется скриптами пакетного менеджера и включает необходимый минимум драйверов
> для загрузки.
И опять же это все и кастомизируемо, и какая мне разница что там в большинстве? Меня волнует то у меня, в интересных мне задачах и как их решить с минимумом усилий и хорошим результатом. И как я сказал - если вгрузили модуль 1 раз, второй раз не грузят, это сказки.
>> И это хорошо, потому что позволяет имплементить РАЗНЫЕ системы.
> Нет, это ужасно. Я когда слышу про РАЗНЫЕ меня начинает тошнить.
А для меня это основа основ. Это позволяет имплементить варианты операционки под разные нестандартные задачи. А зачем тому одноплатнику поведение как у вашей винды? Чтобы фэйлить миссию более 9000 способов? Но deep deep down inside то же семейство технологий что на моем десктопе. Нехилый реюз знаний, скилов, технологий. Для меня это "компьютеры". Они отличаются "масштабом" и "желаемым поведением". И все.
> Мне нужно только стандартизированное API, стандартизированное ABI и предсказуемая ОС.
Мы хотим от компьютерных систем здорово разного, имхо.
> То что конкретно NT не работает с эмбедовкой - это и не надо.
Ну вот для вас оно оказывается недоступно. А для меня - я масштабирую мои технологии и реюзаю знания. Мне это нравится.
> Это ОС для домашних компов и корпоративного сегмента.
Мне надоел стагнирующий энтерпрайз + я вырос из эникеев чтобы довольствоваться тем уровнем эффективности man-machine.
> Всё что связано с IoT для меня не интересно от слова совсем, пусть там
> будет Linux, хоть на что-то железное он годится, а то одна
> сплошная виртуализация.
Замечательно, меньше конкурентов. А виртуализацию мы используем потому что это круто, быстро и эффективно. У тех кто понял это нет времянок характерных для вас. У нас деплой систем, откаты факапов и проч - минуты. Я и железками так же рулить стал - через снапшоты уровня ФС. По тем же причинам.
> - враги, потому что увеличивают мне работу фактом существования
Динозавр не может быть врагом капитана звездолета...
> Слушай, в Linux как и в любой ОС построенной архаичных технологиях из
> 70-х в юзерспейсе может быть только 1 процесс, PID_1, он же
> init, а все остальные - дочки его.
В лине еще PID=2 часто бывает. С интересными потомками. А PID=1 может быть и 1, некоторые фирмвари самодостаточны и им субпроцессы не требуются. У сони фотики так сделаны например. Так что инита может и не быть.
> Вся многопользовательская структура эмулируется поверх одного единственного
> экземпляра оболочки.
К многопользовательской структуре начальный процесс отношения не имеет. Вся идея *nix основана на fork() - когда 1 процесс становится 2. Это их основа основ. В винде нет прямого эквивалента fork(). А в лине еще очень эффективный copy-on-write при том. А на расширениях этой идеи основаны контейнеры. В конечном итоге процессов будет столько сколько нужно. С теми пользователями которые нужны. Сие кроме всего прочего позволяет очень эффективные фокусы. Т.к. изначально форк - "замороженная" копия предка, можно отпедалить долгую фоновую операцию, без заморочек характерных для тредов. А с COW (RCU) оно почти столь же легкое как тред по ресурсам. А чуть доразвитое оно аж контейнер. С типа-независимой копией системы аж. Там и пользователи свои могут быть (user namespace). Т.к. в изначальном дизайне не было, абстракция иногда рассыпается, но оно хотя-бы есть. В винде подобное вообще не предусмотрено.
> В этом вся суть старого UNIX, также работали бесчисленные реализации DOS.
В DOS в принципе нет fork(). Небольшая разница.
> Windows 3.11 делала также. Запускала DOS и в нем крутила оболочку.
А вот этот уже пытался многозадачность. Но фиговую, вытесняющую. И fork() в нем тоже нет.
> эмуляцией, которая исторически присутствует в старых UNIX и была заботливо скопирована
> в Linux. Видимо ты не понимаешь, разницу в ОС.
В конечном итоге есть процессы и наборы прав. Оно лишь маркеры для кернела что и кому с какими правами можно. Ядро либо умеет при этом понимать что пользователи и права разные, либо нет. Это и есть поддержка многопользовательности.
>> В винде ничего сравнимого не припоминаю, SCM вообще относительно пофиг на участь сервисов.
> Вот всегда душно с такими как вы. Вы Windows не знаете настолько,
> что не умеет ни читать логи, ни понимать, что там написано.
В его логах имеет свойство быть написано "Error 0x813495". Очень круто и удобно в траблшутинге. А теперь пример. Если я допустим девелопаю usb девайс, мне посмотреть траф на шине - пара команд. Вгрухить модуль usbmon да запустить вайршарк какой. Первый есть даже в дистрибном кернеле. Второй из пакетов за 2 минуты ставится. И вот я вижу как железка отвечает хосту и что из этого вышло. А теперь расскажите что сделать в винде чтобы увидеть "raw" USB I/O (включая перепосылки, CRC error, энумерацию, ...) и сколько времени это займет. А ну да, девайсы как булки на деревьях растут, а проблемы девов вас не волнуют. Зато они волнуют девов, от чего их драп с винды.
> Видно там где, какой сервис куда упал.
Там минимум деталей, часто только малоинформтивная ругань самого SCM что сервис отпал. В системде же может быть и человекочитаемое сообщение. И даже сервис выдал что-то в stdout/stderr, не нравится ему что-то в его конфиге допустим, или там что еще. В винде в таких случаях весьма душно. Сервис не стартует и гадай почему именно. У виндов фундаментальные проблемы с этим всем, с тем как они с консолью работают.
> Вешайте фильтр на лог и кастуйте асинхронно любое событие в планировщике.
Это гиморно. И не отвечает на вопрос почему тот сервис не стартует/вырубается. А вот системд довольно часто дает мне этот ответ. Очень упрощает запиливание своих сервисов в систему. Когда и прав может не хватить, и файл может не найтись, и более 9000 иных системных обломов.
> В чем проблема то?
В том что обычно там ничерта полезного. Толи это сложнее чем syslog() или printf() в stdout. А с дровами вообще швах, там какой-то свой вывод. Раньше dbgview его умел, потом MS скупил и прибил вьюшку. И хороших тулсов которые малой кровью такое кажут вообще не осталось.
> Лог прекрасно сериализован в XML, пберите XPath-фильтр и при появлении сообщения
> кастуйте себе скрипты на здоровье.
Я не фанат XML. Мне цепочку грепов как фильтр сильно проще нарисовать. Дешево, сердито и - решает задачу. А если мне надо много и более-мене в реальном времени, у системды внезапно АПИ есть для этого :)
> Linux это весьма вольная интерпретация UNIX, а Windows NT - это такая
> вольная интерпертация VMS для x86. Они не похожи от слова "совсем".
В первом приближении как-то так. И честно говоря я рад что вольная. Поэтому в лине у разных тредов могут быть разные приоритеты. А у вон тех мамонтов - фиг. Что нагибает ряд программ. И все же у операционок неизбежно есть и общие черты. В силу похожести абстракций и задач. Хотя отличий хватает.
> А что такого страшного в использовании API? Ну кроме банальное неграмотности...
То, что в линухе я в результате могу запустить "вот эту вот" программу или скрипт на автомате при загрузке, системдой. За пару минут. Будет удобно и круто. А в винде... эээ... услуги SCM им внезапно недоступны. А запилить вон то сервисом, чтобы система без моего участия что-то сделала - целая эпопея. И в винде еще дурь с console vs GUI subsystem, так что например поругаться дебагом в консоль по простому, но не получить при этом голимое черное окно в принудиловку - так нельзя. С точки зрения кодинга логинг в стиле трейса флоу делать гиморно. С точки зрения интеграции и администрирования - инфо почему сервис не взлетел не будет. И самих сервисов - сильно меньше. Гимор.
> Взял ты значит PowerShell, подключился к объектам и всё сделал. Всё подробно
> задокументировано английским по белому.
Шатал я греть мозг типизацией объектов в мелкой (порой одноразовой!) автоматизации и интерактиве. Я вообще не понимаю зачем оно такое. Там где я в лине 20 раз уже загрепаю вон то будет лечить на тему неправильного типа. Блин я вообще хотел список фильтрануть по бырому и отвалить в туман, мне класть какой у него тип. Если я захочу долговременный крутой Solution, быстрый, надежный, на годы - я его в IDE через апи буду, а не через шелл.
> Ну то есть смотри, в обычной оболочке ты работаешь со стандартным вводом-выводом
> и данными которые валятся туда же.
Да, и гениальность *никса в том что быстрые программы-кирпичики можно стыковать пайпами через высокоуровневый координатор-шелл. Интерактивно или легким скриптингом без заморочек. Это как раз разумное деление на быструю и медленную логику, высокий и низкий уровень. Одно шустрое, надежное, ошибки репортит. Другое делается на коленке за 2 минуты по месту, самое то для разовой/мелкой автоматизации и т.п.. А вот загрузка ОС таки не тот случай. Не разовый сценарий и не мелкий со всеми хотелками и софтом.
> В объектно ориентированных скриптовых средах вроде Python или PowerShell
> ты работаешь с объектами.
Питон и то мозги типами не делает. Впрочем я не фанат питона. Мне для системной автоматизации баша хватает. А если я решил похардкорить с дергами апей, мне как-то си или при большем замахе плюсы - нормуль. К тому же 90% кода я скорее всего смогу скопипастить вооон оттуда, останется только "дельту" накодить.
> Причем у PowerShell есть еще и то отличие, что вся оболочка объектно ориентированная, то
> есть терминал ея - суть текстовое отображение объектов из памяти,
Я не считаю это удачным решением для мелкой автоматизации по месту и интерактивщины. Я это видел и мне очень не понравилось. Еще и автодополнение никакое, в паре с тягой к путям с проблеами и километровыми командами - жесть. Мне такой инструмент даром не.
> Ну взял ты и постучался на REST API получил JSON в
> скрипте и десериализовал в словарь так понятнее?
В именно скрипте я такие навороты далеко не каждый первый раз хочу. И уж тем более при интерактиве. Тем более в принудиловку. Когда мне делают мозг что вот это нельзя отфильторвать вот так - по чисто номинальной причине.
Декларация намерений кодера это прекрасно. В более-менее крупном проекте где это будет долговременной, крупной, программой. В интерактивном шелле и мелкой автоматизации это неуместно.
> про эмбедовку, но что-то мне подсказывает что ты нифига не разработчик,
> раз у тебя на API алергия.
У меня нет аллергии на API. Я люблю системные апи. Там где они уместны.
> архаичный cmd (ради обратной совместимости, энерпрайз же и там этого нету)
У них и ps омерзительный на мой вкус. И терминалки такие же. Что-то отдаленно напоминающее нормальный терминал только в районе 10-11 винды появилось. И даже так - хуже чем дефолтная терминалка XFCE или LXQT мелких, тьфу.
> и Windows Script Host ничем не лучще (Visual Basic Script и
> JScript - очередная ошибка MS), но PowerShell-то работает.
Он так работает что лично мне - даром не сдался.
> ничего сложного, ну разве что понять логику работы CLR, но это не рокет саенс.
Не собираюсь этим заниматься в интерактивных шелах и мелкой автоматизации. А более масштабные, долговременные и критичные к скорости вещи - лучше не в шелле, ага.
> зарегистрировать до самого ядра ОС, которое доступно ненапрямую, но доступно через
> фреимворк P/Invoke прямо из скриптов.
Я считаю что мелкая автоматизация должна быть ненапряжной и быстрой прежде всего. Это не про ps.
> Когда ты пишешь, что скриптовать венду это боль - ты сильно ошибаешься.
Все познается в сравнении. После интерактива и скриптования в баше - ps с километровыми командами, деланием мозгов типами и тормозным что капец стартом - имхо позор какой-то.
> Ты просто не знаешь как, но этому можно всему научиться, если хочется.
Нет, не хочется. Потому что в Linux это делается в разы быстрее, проще, эффективнее. У меня нет цели "разучить CLR" или что еще. Так, по жизни. Я иначе формулирую задачи.
> Я из твоего комментария сделал вывод что ты интересуешься IoT и прочими R&D.
Однозначно. Всякая мелкая автоматика, околоэмбедовка и проч. Но линух делает меня универсальным. Core технологий одинаковое. Так что я могу мастерски нарулить себе удобный воркстейшн где я эффективен в этом самом. И порулить теми серверами не обломаюсь. Более того - "вот этот" сервис я могу отладить и на десктопе под мощной инструментацией, до того как на одноплатник отправить. В этом случае похожее окружение очень кстати. А виндузеры - инвалиды как только шаг в сторону требуется.
> лол, последнее балмеровское наследие) пытаются пилить Windows IoT для замены Windows
> CE, но они в отстающих.
Они своей политикой достали всех системщиков которых я знал. И теперь будут без дров. Ну что, stable api, довертелось?
> - это модульность в смысле подхода к программированию. Немодульность systemd в
> том, что у тебя udev совмещен с systemd
У меня есть системы где есть systemd но нет udev. Расскажите мне про отсутствие модульности, ога... а я и отвечу что отсутствие модульности - это например неотключаемый гуй, жрущий ресурсы даже если у системы из интерфейсов только вебморда допустим.
> и они это сделали тупо, чтобы подвязать всех на свой systemd технических причин на
> это нет.
Вообще, они достаточно удачно стыкуются, таки с интеграцией с sd появились ранее невозможные взаимодействия между ними. Но на самом деле это отдельные компоненты.
> В Windows наоборот, с программистской стороны разделяют инит.
Дает +9000 к граблям траблшутинга, имхо. Вообще траблшутить линя лично мне куда проще.
> И вообще. Ты понимаешь, что в Windows инициализация полностью отдельна от SCM
Не понимаю какой смысл отделять запуск процессов от запуска процессов. Напротив удобно когда управление и статусы сосредоточены в 1 центральном месте а не в 10 разных закоулках. Дада, .timers в системд лютый вин относительно ваших шедулеров, где чтобы общее состояние системы увидеть и понять что и откуда надо по 10 разным закоулкам лазить. К _сабжу_ + кронам, логротейтам и проч та же претензия.
> а в UNIX так быть не может из-за того что юзерспейс форкается от PID1?
В *nix fork() это часть базовой абстракции. Она должна с чего-то начинаться. В юзермоде это PID=1. Само по себе это не хорошо и не плохо. И не накладывает никаких ограничений.
> P.P.S Еще раз, мне плевать на IoT, умные дома и прочий булщит,
> как и большинству Enterprise-админов.
Ну а я вот экс-этсамое которому не наплевать. На самом деле даже не оно а более мощная версия, с уклоном в R&D. Только вот теперь - линуксный вариант уже. Так я оказался мощнее и смог реализовать то о чем давно мечтал.
> дубину, на случай если он выйдет из-под контроля.
А я не настолько питекантроп, у меня техника меня слушается и делает то что я скажу. Более того - я умею в МК и будучи любопытным даже смог частичную интеграцию "инопланетных" технологий в свои. Так намного прикольнее. В принципе я могу интерфейснуть что угодно к чему угодно. Мне это нравится.
> наличие объектного API в 100500 раз лучше чем парсить текстики из stdout.
Кроме случая когда это был интерактив или мелкая автоматизация где оно делает мозг а бенефиты которые оно дает - не актуальны, ибо актуально для больших проектов. Которые странно ваять в шелле.
