'У костра'

Флеймы "Windows vs Linux" в интернете не утихают уже много лет, но вот чего в них недостает так это знаний: зачастую обе стороны имеют лишь поверхностное представление о работе этих операционных систем.

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

И начнем мы с самого первого явления ОС компьютеру - загрузки.

Загрузка.

Любая операционная система (ОС) начинает свой путь с загрузки, по-английски называемой BOOTSTRAP, то есть "подъем самого себя за шнурки от ботинок" - в лучших традициях барона Мюнхгаузена  Происходит это так: BIOS считывает загрузочный сектор диска, в который ОС записывает свой первичный загрузчик. И уже он загружает основной загрузчик, который загружает саму ОС.

Windows

Как известно, для загрузки Windows требуется специальный загрузчик - ntldr, входящий в комплект. Он проделывает огромный объем работы - считывает реестр, выясняет какие использовать файлы ядра и драйверы, считывает их в память и размещает по нужным местам, подготавливает структуры данных для ядра, и только после всего этого запускает саму ОС. Хотя процесс загрузки и  не документирован, а единственно возможный загрузчик это только сам ntldr, но с деталями  можно ознакомиться в исходниках загрузчика ReactOS  - FreeLDR, он в том числе умеет загружать и Windows, хотя это умение далось совсем не просто.

Если же что-то пошло не так, то система либо зависнет при загрузке, либо вывалится в "синий экран смерти" (BSOD) на этапе инициализации. Список возможных ошибок разнообразен, но вся диагностика это 5 чисел - номер ошибки и некоторые данные. Что же  именно не понравилось системе можно выяснить только с использованием ядерного отладчика. Самые популярные ошибки - 7B (система не может получить доступа к загрузочному устройству), и 6D/6E/6F/71 (что-то пошло совсем не так), самая загадочная - 21a ("Неустранимая системная ошибка" - будто остальные так, устранимые несистемные правильности ) Причиной первой из них может послужить перенос системы на другое железо, смена типа загрузочного диска (базовый/динамический) и тому подобное, остальные же имеют практически неограниченный список причин, и не всегда удается их исправить.

Linux

Загрузка Linux представляет собой полную противоположность: ядро Linux самодостаточно, и для запуска системы нужно лишь считать ядро в нужное место памяти (когда-то оно самозагружалось с дискеты!), а в случае с позиционно-независимого ядра (собранного с опцией -fPIC) вообще в любое место памяти. Ядро Linux поддерживает спецификацию MultiBoot, документирующую требования к загрузчику, поэтому для загрузки могут быть использованы десятки разнообразных загрузчиков: от древнего и практически забытого lilo, старого доброго syslinux до наворочаного grub2 и примкнувшего к ним grub4dos.

Если же что-то пошло не так, то точка возникновения проблемы видна сразу: на консоли выводятся подробные диагностические сообщения о происходящем, и в случае Kernel Panic (аналог BSOD-a) можно увидеть последние происшедшие действия. Практически единственный способ получить Kernel Panic - физическая неисправность загрузочного устройства. Сам процесс  загрузки может быть изменен разнообразными способами - ядро поддерживает командную строку с кучей разнообразных параметров.

Но самое интересное отличие - это возможность загрузки с неподдерживаемого ядром устройства! Для этого помимо ядра загрузчик, поддерживающий MultiBoot, может загрузить в память заранее подготовленный образ диска, содержащего все необходимое - драйверы, скрипты инициализации и тому подобное.  И неважно, собрано ли ядро с поддержкой загрузочного устройства - если драйвер устройства есть на этом инициализационном диске то он будет установлен, и загрузка успешно завершится.

Помогут параметры ядра и в ситуации, если ошибка возникла уже после, при инициализации системы: параметр "init=" позволяет указать программу, запускаемую ядром, и в случае загрузки с "init=/bin/sh" получим голую консоль сразу после инициализации ядра. Из нее уже можно разбираться с ошибкой - редактировать файлы, запускать/останавливать программы и даже вручную продолжить инициализацию.

Итоги

Подход Windows к загрузке теоретически обеспечивает чуть бОльщую скорость оной: считываются только необходимые файлы, поэтому меньше загружаемый с диска объем, система раньше переключается в 32- или 64-разрядный режим. В реальности считать два больших, но последовательных файла Linux (ядро и диск инициализации) оказывается быстрее, чем множество файлов с разных мест диска.  Возможность изменить параметры загрузки Linux вместе с логами и консолью на ранних стадиях обеспечивают несравнимое удобство для устранения проблем с загрузкой, которые к тому же и возникают гораздо реже.

Инициализация, драйверы, сервисы

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

Windows

Инициализация размазана по модулям, порядок инициализации определяется реестром, в котором прописаны взаимозависимости драйверов и служб. Службы должны быть специально оформленными бинарными файлами, поддерживающими API управления службами (но есть специальная служба , предназначенная чтобы сделать службой любую программу). Драйверы работают через драйверный API, и совместимы зачастую не только в пределах минорной, но и для разных мажорных версий. Ошибка в работе устройства зачастую укладывает ОС в тот же "синий экран смерти". Например, BSOD FE - драйвер USB получил неверный ответ.  Вы только представьте: сбойная флешка может уложить сервер с тысячей клиентов!

И об одной службе стОит сказать особо. Это LSASS (Local Security Authority Subsystem Service - сервер проверки подлинности локальной системы безопасности). Именно эта служба отвечает за всю проверку прав! Поэтому до ее запуска в Windows вообще фактически не существует никаких проверок. Считается что это критическая служба - при ее сбое произойдет перезагрузка Windows, а если ее запретить то мы увидим только курсор на черном экране. Однако есть практически недокументированная возможность обойти ее запуск. Вспомните - установка/обновление Windows не спрашивает ни о каких паролях и правах! Так что установкой некоторых ключей реестра можно заставить Windows считать что идет установка, отключить этим запуск службы LSASS и полностью отменить все проверки.

Linux
Процедура инициализации зависит от дистрибутива Linux, и обычно задается обычным шелловским скриптом (вернее, набором скриптов). Зависимости инициализации драйверов находятся в самих драйверах, которые называются не драйверами а модулями ядра, но при возникновения ошибки устройства обычно принудительно выгружаются. Сервисы являются обычными программами, снабжаемыми скриптами для автоматического запуска/останова.

Проверка прав доступа в Linux не вынесено в службу а находится в самом ядре, однако при загрузке с "init=/bin/sh" мы получаем системную консоль со всеми полномочиями.

Итоги

Подход Windows позволяет производителям оборудования поставлять драйверы, совместимые с разными версиями, исключительно в бинарном виде. Драйверы Linuх обязаны (за некоторым исключением, ценой совместимости) быть в виде исходного кода, чтобы быть собранными для конкретной версии ядра.  В обеих системах физический доступ к компьютеру позволяет получить административные полномочия - от чего спасает шифрование критически важных данных, которое есть в обеих системах.

Также стОит отметить, что последнее время под давлением компании Red Hat вообще и Леннарта Поттеринга в частности, многие дистрибутивы Линукс строем идут в сторону решений, используемых в Windows и негативно себя зарекомендовавших: бинарный старт и бинарные логи. Аргументация, что дескать это обеспечивает уменьшение времени загрузки, представляется значимой только для десктопов, но никак не для серверов - которые зачастую пререгружаются раз в год. Да и не поздновато ли бороться за десктопы, после того как их почти повсеместно вытеснили планшеты с Андроидом?  Который, к слову, использует обычную скриптовую инициализацию

Совместимость

Основная аргуметнтация за использование windows - огромное количество программ, созданых для этой ОС к настоящему времени. Но не все так просто

Windows

Самая примечательная особенность системы Windows - это ее несовместимость с... самой собой :-8 Причина тут в истории: основой Windows NT 3.1, послужившей прародительницей всего современного семейства, была ОС, первоначально разрабатывавшаяся для другого процессора и под совершенно другой АПИ (после развода и раздела имущества с IBM ее увидели под названием OS/2 :) ) - а вовсе не родные windows 1.0...3.11...95!  Поэтому-то подсистема win32 в Windows является... эмулятором!  Равно как и в Linux'e - в первом случае это служба win32k, во втором - приложение Wine (Вайн). (И равно как эмуляторы - по М$-офтовски "подсистемы" - OS/2 и posix, к настоящему времени благополучно приконченные). Конечно, для компании Микрософт "заточить" эмулятор было много проще чем делать сообществу Вайн с нуля, но ведь каковы превратности судьбы - недавно вышел релиз Wine для... Windows! Исключительно потому, что новые версии Windows (вернее, встроенного в нее эмулятора) оказались менее совместимы со старым софтом, чем линуксовый Wine.

Так что имеем парадоксальную ситуацию: на ранних стадиях загрузки Windows ничего не знает про казалось бы родные виндовые программы!  То, что Windows поддерживает сама на уровне ядра, и может исполнять в минимально загруженном режиме (например проверка диска или конверсия носителя), мелкософтом скромно называется "Native API". Оно не документировано чуть более чем полностью, и хотя есть реализации некоторых программ для  этого НативАпи, но в целом недозагруженная винда это крайне грустно.

Linux

Традиционно - полная противоположность. Ядро после загрузки само может запустить выполнение как исполняемой программы нескольких форматов, так и скрипта. Обычно это программа инициализации (/sbin/init), но никто не мешает ее заменить. К тому же, если требуется запуск единственной программы навсегда, как например в платежных терминалах программа экрана, или в Андроиде его Ява-машина, то тут эта особенность становится крайне востребованной.

Если же рассматривать совместимость с программами для Windows, то последние годы подсистема Wine сделала огромный шаг вперед, и под ней запускаются очень и очень многие приложения Windows. Я например постоянно пользуюсь OziExplorer, VB6 с набором вспомогательных программ, EMule и некоторыми другими - все они отлично работают под Wine, и во многих случаях заметно быстрее чем в родном Windows!

Итоги

Это очень трудно выразить словами (приличными). Впечатление, что фирма Микрософт делает все для усложнения поиска возникающих при загрузке и работе проблем, равно как и для увеличения возникания оных. Просто чтоб жизнь медом не казалась, ну и вырабатывалось желание купить очередную, еще более замечательную версию Windows.

Файловые системы

На самом деле человек работает не с самим компьютером, а с программами для него. А эти программы, как и данные для них, надо где-то хранить. Для этого служат разные носители, на которых используются файловые системы (ФС).

Windows

Набор файловых систем в Windows не отличается особым разнообразием. Первая из них - это древняя FAT, к которой пластырем и проволокой примотали сначала длинные имена (VFAT), потом большие носители (FAT32)  и недавно даже транзакции и большие файлы (exFAT). Вторая - это традиционная NTFS ("самая лучшая и единственно правильная" (С) microsoft). Есть еще всякие UDF и прочие для CD/DVD дисков, но они не так интересны. 

Linux

Даже для краткого обзора файловых систем Linux нужна отдельная статья:  от разнообразия существующих ФС разбегаются глаза! От относительно простых, предназначенных до одного диска, хотя и несколько разных применений, и до систем для датацентров -  кластерных и многотомных.  Также поддерживаются и все ФС, которые есть в Windows. 

Есть несколько специальных файловых систем для флеш-памяти, есть специальная ФС для оперативной памяти - для временных файлов, есть даже реализация файловой системы в... SQL-сервере

Но "самая-самая родная" файловая система - это EXT4, 4-я переработка оригинальной файловой системы UNIX, соответственно вторая версия оригинальной системы Linux, EXT2. Если первая первая (EXT3) версия принесла журналирование, хоть и ценой некоторого снижения производительности, то эта, сохранив журнал и даже увеличив его надежность, повысила производительность во многих случаях даже выше исходной EXT2! Удалось этого добиться за счет максимальной отсрочки операций с устройством, так что EXT4 еще и крайне нежно обращается с флеш-памятью (несмотря на журнал!). Отчего и используется в качестве базовой во всех андроид-телефонах и планшетах с памятью более 512мб.

Кстати, по тестам скорость чтения  у EXT4 выше на 4%, а скорость записи - на 26% чем у NTFS

Итоги.

Можно конечно  попытаться понять позу Микрософт, утверждающей что имеющихся в Windows ФС хватает на все случаи жизни. Но почему тогда они проиграли и в серверном сегменте, и в устройствах, и в телефонах?

Символические ссылки

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

Linux

В Linux символические ссылки существуют с начала времен, поддерживаются в ядре и всеми утилитами, и широко применяются с разнообразными целями, например для версионирования динамических библиотек (далее) и многофункциональных программ (функция которой зависит от имени, под которым ее вызвали: во многих liveCD практически все консольные утилиты реализованы единственной программой BusyBox, т.е "тесно набитый ящик").  

Windows

В Windows есть аж два разных механизма символических ссылок, несовместимых между собой Первый из них - наследие Windows95, .lnk-файлы. Из всех программ для Windows их понимает только Explorer, да и то не до конца -  позволяя скопировать на флешку такую ссылку вместо самого файла.

Второй механизм - встроенные символические ссылки NTFS. Они существуют со времен Windows NT 3.1, вот только пользоваться ими до появления Windows Vista было невозможно! Создать их можно было только утилитой POSIX-подсистемы LN, хотя после создания они вели себя как полный аналог файла, на который ссылались.  Настолько полный, что при удалении такой ссылки удалялся и файл :)) Что естественно для ссылок недопустимо. И только Windows Vista  научилась нормально  обрабатывать символические ссылки.

Есть еще один забавный момент, связанный с символическими ссылками в Windows: они обрабатываются только драйвером NTFS, а вот загрузчик NTLDR про них ничего не знает! Так что если попробовать по образу и подобию Linux вынести с загрузочного диска некоторые файлы для освобождения места, заменив символическими ссылками, и по неопытности поступить так с одним из нужных при загрузке файлов, то проблемы с загрузкой просто гарантированы.

Итоги. 

В ранних Windows  работа символических ссылок вообще была сделано адово, да и в Vista трудно  назвать идеальной. Все как всегда

Динамические библиотеки

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

Windows

В Windows файлы динамических библиотек имеют расширение DLL - Dinamic Link Libaray, Библиотека Динамической Загрузки. И практически у всех кто в теме это название рефлекторно вызывает ассоциацию с "DLL HELL" - DLL Ад, DLL кошмар. А все оттого, что в системе нет какой-либо проверки версий, отчего системная библиотека может быть заменена библиотекой устанавливаемого приложения, и даже на более старую версию. Показательно, что одной из целей разработки платформы NET, наиболее громко озвучиваемой, был именно уход от DLL HELL. Только вот цена, которую за это пришлось заплатить, осталась практически не озвучена, а ведь это был фактически полный отказ от динамического связывания, за исключением ядра NET.

После того как проблема стала трудноконтролируемой, были разработаны два средства борьбы с ее последствиями (!): это во-первых система защиты родных системных файлов, и во-вторых так называемая система "Side by Side", позволяющая приложению заказывать конкретную версию библиотек. И как всегда, первая из них стала отличным местом для вирусов где можно спрятаться, а вторая привела к неудержимому росту занимаемого системой места.

Что забавно, в Windows библиотеки dll разделяемыми библиотеками не являются - с точки зрения мира Unix! Windows не поддерживает позиционно-независимый код, поэтому dll перед загрузкой в адресное пространство процесса должна быть скорректирована для работы на конкретном адресе - а этот адрес может и не совпадать с адресами, на которых она размещена в других процессах. И хотя Windows старается размещать все dll так, чтобы их можно было использовать несколькими процессами, реальность такова что каждая программа на этапе компиляции задает, какая библиотека где будет в ее адресном пространстве - здесь нет места позиционной независимости. Поэтому DLL  служат больше для экономии места на диске, а не памяти.

Linux

В Linux разделяемые библиотеки имеют обычно расширение .so - Shared Object, Разделяемый Объект. И они тоже могут быть причиной того, что носит здесь имя "dependency hell" - "ад зависимостей". 

 Хотя в Linux решение этого вопроса остается на совести разработчиков конкретного дистрибутива, но в некоторых дистрибутивах достаточно давно выработан способ преодоления. И это - версионирование плюс символические ссылки.

Вкратце это работает так: библиотека получает наименование, включающее ее полную версию: не liba.so, а liba.so.1.23. И создаются символические ссылки на нее с именами liba.so и liba.so.1.

Если программа требует конкретную версию библиотеки, то будет указывать в зависимостях именно  liba.so.1.23, соответственно будет связана именно с ней, и продолжит работу после установки liba.so.1.45. Если же попытаться библиотеку удалить, то благодаря зависимостям в пакетном менеджере он потребует удалить и программу.

Если программа менее требовательна, то может указать в зависимостях liba.so.1 - и продолжит работу после обновления библиотеки на liba.so.1.45

Если же программа совсем не требовательная, то укажет в зависимостях просто liba.so. В этом случае... нет, в этом случае при сборке ей явно будет прописана в зависимость опять же liba.so.1!  Просто по текущей "умолчальной" либе, коей и является liba.so1

Теперь наша liba.so обновилась до версии 2.34 - получив второй АПИ, не совсем совместимый.  В зависимости от пакетного менеджера она может быть либо спокойно установлена вместе с символическими ссылками liba.so.2 и liba.so (которая заменит ссылку первой версии, но все программы-то привязаны к сохранившейся liba.so.1!), либо потребует удалить предыдущую версию вместе со всеми зависимостями. В обоих случаях путаницы версий не произойдет. А так как программы доступны в виде исходных кодов, то их можно просто пересобрать под новую версию библиотеки.

К тому же, в Linux есть возможность собрать всю программу статически! Ну да, нечто подобное заявляется и у сред разработки для  Windows - вот только скромно умалчивается что статически собраны могут быть только родные библиотеки проекта, а системные DLL самой Винды так и останутся динамическими. В то время как в Линуксе можно собрать программу со статической glibc (основной системной библиотекой), после чего она будет спокойно работать на любом ядре, например на Андроиде.

Разделяемые библиотеки в Linux должны быть позиционно-независимыми и поэтому являются истинно разделяемыми: в память загружается единственная копия библиотеки, и отображается в адресное пространство всех процессов, в первое подходящее место. 

Итоги. 

Почему-то в конце каждого раздела итоги выглядят практически под копирку: в Linux сделано (или МОЖЕТ быть сделано) хорошо, в Windows - традиционное "извините, так получилось,  не нравится не берите" .

Разделение потоков чтения и записи.

Что это такое и для чего нужно? В первую очередь - для обеспечение кажущейся "записываемости" носителей "только на чтение", например при загрузке с компакт-диска или ДВД. Но этим  сфера применения далеко не ограничивается! Вот представьте - ваш маленький ребенок взял книжку и изрисовал ее карандашами. Вы берете и... снимаете тончайшую невидимую пленку с листов книги! Все каракули остаются на этой пленке, а книга возвращается в первозданный вид. Вот именно это и обеспечивают обсуждаемые средства! "Нижний" слой работает только на чтение, а "верхний" - на запись и чтение уже измененных файлов.  Такая слоеная файловая система позволяет работать, не задумываясь о физическом расположении файлов, а при необходимости можно вернуть "нижний" слой к исходному виду. 

Применений такая возможность может найти массу. Можно дать компьютер ребенку (а потом одним движением все починить), можно вести отладку на живых данных (при этом изменения видны только в отладке), можно работать с совершенно секретными документами или сайтами (и от этого не останется никаких следов) - вот лишь самые очевидные из них. 

Вот только есть одно НО: эта возможность требует приложения рук.

Windows

 Хотя в windows для десктопа никаких подобных средств нет, но они легко "выковыриваются" из "Windows Embedded XP": это драйверы EWF и EWFB. Первый из них обеспечивает перенаправление записи для всего тома, второй - для отдельных файлов,  на нормальный диск или на эмуляцию диска в памяти (RAMdisk).

Linux

 В Линуксе тоже ничего подобного нет Вернее так: в официальном ядре нет (пока нет). А вот в виде сторонних разработок есть аж несколько: UnionFS, AUFS и наконец OverlayFS. Которую уже анонсировали на включение в ядро 3.11, но в последний момент без объявления войны убрали.

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

Итоги.

Включить эту крайне интересную возможность можно в обеих ОС, но в реальности применимость решений от Микрософт ограничивается загрузочными CD/DVD дисками с WindowsPE, в то время как во многих дистрибутивах Линукс оно есть "из коробки".

Безопасность.

Windows

Linux

В линуксе же все совсем наоборот (как обычно ): говорят, где-то существует пара десятков вирусов под Линукс, но чтобы их запустить нужно их сначала собрать Большинство из них существует с образовательными целями, а те, что использовали реальные уязвимости, представляли опасность ровно несколько дней - до выхода исправлений безопасности.

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

• во-первых, Линукс просто не даст запустить файл, пришедший по почте или загруженный с сети. Даже если он окажется вдруг совместим с вашим дистрибутивом (что маловероятно) или собран статически (что сразу же дает размер в сотни килобайт для простейшей программы), то у него все равно нет права на исполнение. И это право надо сначала дать самостоятельно - либо в консоли, либо в свойствах файла. А это совсем не то, что не читая жамкнуть пробел на вылезший диалог с вопросом "Файлы, скачанные из интернета, могут нанести вред вашему компьютеру" (С) Windows. В Андроиде же этот момент решен как в Windows, именно диалогом с вопросом.
• во-вторых, Андроид после установки на телефон в подавляющем большинстве случаев не обновляется, соответственно не получает исправлений обнаруженых уязвимостей.
• в третих, квалификация пользователя. Средний пользователь Линукса это не то же самое что средний пользователь Андроида или Винды, он не будет даже пытаться запустить файл "картинка.jpg.exe" или делать другие подобные глупости.

 А для тех случаев, когда все же надо запустить неблагонадежную (или представляющую интерес для хакеров) программу, а поднимать виртуальную машину не хочется, в Линуксе есть помимо прочего такая возможность как CHROOT (CHange ROOT dir): выполнение программы в "персональной" файловой системе. Работает это так: перед запуском программы создается где-нибудь (обычно в каталоге временных файлов) каталог, в котором воспроизводятся (копированием или жесткими ссылками) те части файловой системы, которые нужны программе для работы. Затем программа запускается с подменой корневого каталога на вновь созданный. После этого даже если программа имеет зловредную составляющую, или вдруг окажется взломана, злоумышленник не сможет выбраться из этого специально созданного каталога, соответственно не сможет нанести вреда всей системе.

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

Есть в Линуксе и еще более изощренные системы защиты! Например, SELINUX: комплекс из программ и компонентов ядра, который предназначен для контроля обращений программ к файлам, анализа разрешений и блокировании неразрешенного доступа. И хотя для повседневной работы SELINUX скорее источник необъяснимых проблем (отчего все обычно начинают работу в Линуксе с его отключения :), но для критичного сервера его применение позволяет резко усилить уровень безопасности.

Вторая из таких систем, вернее - первая на пути проникновения заразы, это встроенный фаерволл IPTABLES. Он позволяет практически произвольно управлять получаемыми, передаваемыми и транзитными потоками данных, и при правильной настройке не оставляет злоумышленникам "щелей" для проникновения в систему.

Итоги.

Ориентация на серверные системы и уроки, полученные от "червя Морриса", сделали Линукс весьма безопасной системой, несравнимо более безопасной чем Windows. По факту, а не по заявлениям.

Конфигурация

Операционной системе надо хранить множество информации для функционирования: какие на компьютере устройства, куда монтировать диски, адреса-пароли сетевых сервисов, и прочая прочая.

Windows.

Начиная с Windows95 вся подобная информация хранится в едином хранилище - не раз уже упоминавшемся реестре. И хотя сохранились со времен windows1 функции работы с текстовыми конфигурационными файлами (и даже усовершенствовались, лишившись ограничения в 64кб) - но их употребление признано аморальным и недостойным. Хотя на мой вкус ReadPrivateProfileString сотоварищи обеспечивают 99% надобностей любого приложения.

Про преимущества такого подхода в Микрософте говорилось много и с чувством - но как всегда забыли упомянуть недостатки. А их набирается немало!

Во-первых, в нем хранится информация не только самой системы, но и всех програм, которые когда-либо были установлены, но не удалены дОлжным образом. И может даже тех программ, которые вроде как не требуют установки!  В результате размер реестра быстро достигает 50-70МБ и не собирается останавливать свой рост. Но ведь он должен быть всегда доступен - отчего находится в невыгружаемой памяти ядра. Задумайтесь: весь мусор, накопленный за годы, находится в невыгружаемой памяти!

Во-вторых, весь реестр должен быть считан в память при загрузке и выгружен при завершении работы. Вот Windows и гоняет 50+мб туда-сюда просто так, даже если там ничего не менялось. А учитывая отсутствие контрольных сумм для данных как в памяти, так и на диске в системе NTFS, реестр имеет привычку регулярно портиться: то сбой, то недозапишется, то еще какая беда. Вот периодически поведение Windows и меняется самопроизвольно - то сетевая карта отвалится, то панель с экрана исчезнет, то программы не так работают

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

Linux

В Linux все гораздо проще: все хранится в обычных текстовых файлах. С комментариями. Которые в подавляющем большинстве случаев только читаются, а записываются исключительно вручную. Если же приложению надо хранить информацию о состоянии, то оно делает это своими силами, и традиционно  - в совсем другом месте. Поэтому каталог конфигурационных файлов - /etc - может размещаться на разделе "только для чтения", окончательно защитив настройки от несанкционированных изменений.

Вот только подсистема совместимости с Win32 - приложение Wine - вынуждено для обеспечения совместимости поддерживать весь реестр Windows. Но делается это опять же гораздо проще - загружая его из обычного текстового файла

Итоги

Безусловно, в Windows все гораздо интересней, и реестр - первый шаг к реализации "настроения нет" и "голова болит" в компьютерном мире. Зато Linux можно один раз настроить и забыть.

Графический интерфейс

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

Windows

Первоначально, в стародавние времена, сама система Windows и была графическим интерфейсом для консольной ОС MS-DOS Потом, с выходом версии 3.0 Windows научился забирать у DOS управление (в так называемом расширенном режиме), а в версии 3.1 этот режим стал основным.  Потом были Windows 95, Windows 98 и (извините за это слово) Windows Millenium, на котором судьба этого семейства благополучно завершилась.

А параллельно с этими Windows, существовала еще Windows NT - "Новая технология". Как уже было упомянуто, компания Microsoft первоначально разрабатывала систему совместно с IBM, а после ссоры и раздела имущества выпустила (с незначительными правками - спешном припиливании эмулятора для исполнения приложений первой линейки Windows) под названием Windows NT 3.1, а после заметной переработки - Windows NT 3.5. Система была хорошая, надежная, и в некоторых местах она еще до сих пор трудится на серверах. Однако графическая подсистема в них была реализована отдельным системным приложением (CSRSS), что приводило к низкой производительности графики. Поэтому Микрософт выбрала направлением развития перенос всей графики в ядро, что и было выполнено в версии Windows NT 4. Но во-первых этот процесс и сам по себе не прост, а во-вторых делался в спешке - но возникшие при этом переносе баги были полностью побеждены только через много лет, с выпуском WindosXP (NT 5.1). Промежуточная версия - Windows 2000 (NT 5.0) была хоть и менее неудачной чем NT4, но все равно популярнось не обрела.

Интерфейс Windows постепенно меняется от верси к версии, кое-что можно изменить настройкой, но по бОльшей части все жестко зашито в систему, и не подлежит изменению пользователем.

Linux

В качестве графической подсистемы в Linux используется отельное приложение - X-windows system. А для предотвращения падения производительности общение с видеокартой идет (по возможности) через специальный модуль ядра. И хотя давно уже идут разговоры что дескать X-windows устарела и неэффективна, и срочно нужен переход на монолитную графику - но пока слава создателю ни wayland, ни другие программы пока не являются реальной альтернативой. Но даже буде это случится - никто не помешает выбрать при установке другую конфигурацию, или даже перейти на другой дистрибутив.

А вот интерфейсов разных - их есть! Gnome, KDE - два основных "кита", и множество других, менее известных, вплоть до супер-минималистичного запуска единственной программы под графической средой (Что кстати дает неплохой прирост скорости!). Некоторые позволяют настройку практически каждого аспекта, другие настроек практически не имеют, но у каждого есть свои сторонники. Но ведь хорошо же, когда можно выбрать внешний вид по своему вкусу!

 Итоги. 

В погоне за производительностью обе ОС выбрали движение в одном направлении, грозящем значительными трудностями переходного периода. Но если приверженцам Windows деваться некуда, то пользователи Linux имеют выбор и могут голосовать за это направление развития "ногами".

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

Обслуживание

Общая стоимость владения (TCO) основной своей составляющей имеет стоимость обслуживания. Это например расходы на своего либо приходящего эникейщика, или затраты собственного времени для поддержания системы в работоспособном состоянии.

windows

Микрософт однажды шокировал весь мир, заявив о том что Linux обходится потребителю аж в 10 раз дороже чем Windows. Это прозвучало настолько лживо, что даже Государственное агентство Великобритании по рекламе в 2004 г. предупредило Microsoft, о том что формулировка «стоимость владения Linux в 10 раз выше, чем стоимость владения Windows Server 2003» не соответствует истине. Подтасовка была простА: сравнивалась "голая" windows 2003  и Red Hat Enterprise Linux AS v.3, в "комплектации" Premium Subscription - то есть с круглосуточной живой поддержкой, предназначенной разработчикам приложений (а не обычным пользователям!).

И вряд ли в этот расчет был включен среднестатистический ущерб от вирусных атак, ущерб от вынужденного простоя для предотвращения этих атак (после обновления Windows практически всегда требует перезагрузки, то есть прекращения работы для клиентов), ущерб от простоя из-за необходимости восстановления системы после таких обновлений,  расходы на реанимацию системы после обновления оборудования (Windows в лучшем случае потребует повторной активации, в худшем - откажется загружаться), и прочие аналогичные расходы.

Как обстоят дела в реальности  наверное знают все - даже дома Windows периодически требует рукоприложения кого-либо более-менее разбирающегося, причем в случае "-менее" это будет регулярная переустановка с нуля.

linux

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

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

Итоги

Несколько лет назад мы полностью отказались от Windows на домашних компьютерах - сначала на десктопе, выполняющем также функции основного файлохранилища и сервера виртуальных машин, а потом и на ноутах. И сейчас времена Windows вспоминаются с ужасом - оказывается, это была постоянная, непрекращающаяся борьба. С багами, вирусами, интернет-жуликами, обновлениями от Микрософт, железом - всегда приходилось что-то делать для windows.  Сейчас же компьютеры просто используются - а операционная система работает для нас, тихо и незаметно. А всплывающие на некоторых сайтах окна, загримированные под антивирус, вызывают только усмешку.

Выводы.

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

Вот самый наглядный пример:

Перед нами два "Синих экрана смерти", один от WinXP (2001 год), другой от Win8 (2012 год). Фото из Интернета.

Весь прогресс за 11 лет развития - это... смайлик!!! Количество же полезной информации, и так скудное, даже еще уменьшилось.

А вот два Kernel Panic'а с Линукса одного дистрибутива, но соответственно 2002 и 2012 годов. Для получения скриншотов я специально заменил загрузочное устройство в строке параметров ядра на несуществующее.

 Но обратите внимание - если старая версия таки упала в Kernel Panic, то новая - нет! Вместо этого был предоставлен шелл с базовым набором утилит, чтобы можно было на месте разобраться с проблемой. Да, тут нет никаких красявостей - но какая из ошибок обработана лучше?

И в заключение - перевод главы «The Tale of Two Bridges» из книги "ØMQ - The Guide"

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

«Мы построили его через ущелье, на дне которого протекала река», - рассказывал он своему другу. «Оно было широким и глубоким. Мы потратили два года на одно только изучение рельефа, выбор архитектуры и материалов. Мы наняли лучших инженеров и спроектировали этот мост, на что ушло ещё пять лет. Мы заключили договор с самой большой строительной фирмой на изготовление опор, конструкций и постройку дорог, соединяющих будущий мост с близлежащими магистралями. Десятки людей погибли при постройке моста. Наш мост был многоуровневым - под основной трассой могли ходить поезда, и ещё у нас были отдельные дорожки для велосипедистов. Этот мост олицетворяет значительную часть моей жизни».

Второй инженер внимательно выслушал его рассказ, задумался немного, и заговорил. «Как-то вечерком мы с другом изрядно напились водки, и на спор перебросили верёвку через одно ущелье. Просто верёвку, привязали её к двум деревьям - на той и на этой сторонах. С каждой стороны ущелья было по деревне. Заметив нашу верёвку, жители придумали прицепить к ней шкив со шнурком, и теперь они могли перетаскивать туда-сюда небольшие грузы. Потом кто-то этим шкивом перетащил два толстых каната — и вот по этой конструкции уже можно было осторожно перебраться на другую сторону. Было немного опасно, но детям нравилось. Чуть позже группа мужчин собралась и переделала канатный мост полностью, снабдив его полом и перилами, сделав его таким образом безопасным, чем не преминули воспользоваться женщины обеих деревень, наладив торговые связи. Мало-помалу товарооборот рос, спрос рождал предложение, развивалось производство, росли новые дома и вот уже на обоих сторонах ущелья образовался настоящий город. Канатный мост был заменён деревянным, позволившим перебираться через ущелье лошадям и телегам. Но время шло, движение росло, и на этом месте был построен большой цельнометаллический мост. Этот мост и сегодня стоит над тем ущельем, и приносит пользу людям».

Первый  слушал молча, и долго молчал после. «Интересная штука», - сказал он наконец, «мой мост был снесён спустя 10 лет после постройки. Выяснилось, что он был построен не в том месте и по сути оказался никому не нужен. Кто-то перебросил верёвку через реку нескольким десятком миль выше по течению, где ущелье не такое широкое, и оказалось, что людям надо было перебираться именно там...»