Why is there no registry in Linux unlike Windows OS?

 Источник :   https://www.quora.com/Why-is-there-no-registry-in-Linux-unlike-Windows-OS

Я бы начал с того, что перевернул вопрос: почему *в* Windows есть реестр, хотя многие операционные системы, как до, так и после, прекрасно обходятся без него?

Чтобы понять это, мы должны начать с истории. Реестр возник в Windows NT 3.1. В то время большинство потенциальных клиентов Windows NT уже работали с MS-DOS и имели диски в формате FAT. Большинство жестких дисков в то время использовали FAT 16, что ограничивало количество кластеров на диске. В терминах это означало, что большой диск (во всяком случае, большой по меркам того времени) часто имел довольно большие кластеры - 32 КБ и даже 64 КБ были довольно распространены. Это означало, что крошечные .ini-файлы, которые часто имели размер порядка десятков байт, по-прежнему занимали десятки килобайт дискового пространства каждый. Умножьте это на несколько тысяч (или около того), и вы получите *много* потраченного впустую дискового пространства (что в то время было довольно дорого).

Во-вторых, Windows 3.1 (и более ранние версии) довольно прямо использовали файлы .ini. То есть, когда вы читаете ключ из файла .ini, Windows открывает файл и линейно сканирует его, чтобы найти запрошенный раздел и ключ, а затем возвращает значение, которое вы связали с этим ключом. Когда файл .ini вообще был большим (а таких было много), это могло работать довольно медленно.

В-третьих, файлы .ini требовали большого количества преобразований. Даже самые тривиальные обычно включали такие вещи, как `foo = 1234`, которые требовали, чтобы `1234` читалось как текст и преобразовывалось в целое число для использования. Это тратит впустую как место для хранения, так и процессорное время.

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

Наконец, проблема курицы и яйца была решена. Изначально предполагалось, что Windows NT будет микроядром, то есть она будет иметь минимальную базовую ОС, обеспечиваемую микроядром. Затем микроядро будет предоставлять различные API-интерфейсы ОС в качестве «подсистем» пользовательского режима. Однако во время запуска микроядру требовался доступ к некоторым возможностям файловой системы, чтобы сообщать ему, например, какие подсистемы загружать и как их настраивать (потенциально включая такие вещи, как поддерживаемые каждой файловой системой). Итак, нам нужна файловая система, чтобы знать, как загружать и настраивать файловые системы.

По крайней мере, на первый взгляд, реестр решил все эти проблемы одним довольно простым махом. Он будет хранить множество мелких битов и фрагментов данных в нескольких больших файлах вместо огромного количества крошечных. Это была бы «правильная» база данных, поэтому она могла бы выполнять поиск быстрее, чем сканирование текстовых файлов. Он мог хранить любые дополнительные данные, необходимые для поддержки списков управления доступом, вместе с самими необработанными данными. Тип значения был назначен при сохранении этого значения, поэтому, если он хранил число, он преобразовывал текст в двоичный при его сохранении, и с этого момента он мог просто получить число в двоичном формате. И он будет (по крайней мере, вроде) встроен в ядро, поэтому он будет доступен даже до того, как будет загружена какая-либо подсистема ОС.

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

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

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

Во-вторых, в Windows реестр подтолкнул «проблему» в одном направлении. В Linux отсутствие реестра толкнуло его в другом направлении. В частности, под Windows хранение данных инициализации является проблемой, но сама инициализация в основном не является проблемой. В Linux хранение данных инициализации довольно простое, но сама инициализация гораздо менее проста - до такой степени, что некоторые разработчики Linux создали чудовище под названием «systemd» для запуска системы - но на самом деле это почти полная операционная система. Конечно, systemd - не единственный возможный способ инициализации системы Linux, но сделать это хорошо - головная боль для всех (? B.D.). Дело не только в том, что Microsoft изобрела проблему, которую весь остальной мир уже давно решил значительно более четко, или что-то в этом роде.

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

Здесь на самом деле коренится страх перед UNIX/LINUX  B.D.