Концепции и размышления о новой современной операционной системе

Задумывались ли вы о том, насколько архаичен дизайн операционных систем, которыми мы пользуемся в настоящее время?

Например, почему в Windows (включая 11-тую версию) основной диск с операционной системой называется C?

Или почему Microsoft открыто не публикует исчерпывающий список отличий в ядре Windows от версии к версии с точки зрения разработки приложений, т.е. различий в WinAPI. Может быть потому, что тогда все увидят, что начиная с Windows XP вообще ничего значимого в WinAPI не появилось? Навскидку, более 99% используемых в приложениях системных вызовов, вроде CreateFile имеют приписочку ‘Minimum supported Windows XP’ или ‘Minimum supported Windows 2000’, а в оставшемся <1% указано ‘Minimum supported Windows Vista’. Попробуйте найти хотя бы штук 5 новых полезных возможностей ядра Windows 11 относительно Windows 7, например. Речь не про новый отвратительный (по сравнению с Windows 7/8) калькулятор и не про обновлённый Блокнот или MS Paint, а об изменениях, которые видны программисту, пишущему полноценные (т.е. Desktop) приложения, т.е. изменений в WinAPI, ну или хотя бы о тех, которые не затрагивают WinAPI, но относятся именно к ядру ОС. Все те новшества, о которых Microsoft говорит на презентациях, легко реализуются на пользовательском уровне, либо в драйверах, вообще никак не требуя доработок ядра ОС. Если бы такой список изменений ядра ОС Windows был опубликован, то я уверен, что многих бы поразило, насколько незначительно ядро Windows 11 отличается от Windows 7 или даже Windows XP, которая вышла 23 года назад.

С другой стороны, у нас есть Unix, которая вообще разрабатывалась для мейнфреймов и "мини-компьютеров" размером с современный серверный шкаф для ЦОД, к которым подключалось множество терминалов и которые обслуживали большое количество инженеров.
О тех временах красноречиво говорит такое высказывание, приписываемое министру радиопромышленности СССР Николаю Горшкову:

Персонального компьютера не может быть. Могут быть персональный автомобиль, персональная пенсия, персональная дача. Вы вообще знаете, что такое ЭВМ? ЭВМ — это 100 квадратных метров площади, 25 человек обслуживающего персонала и 30 литров спирта ежемесячно!

Но времена поменялись. И теперь уже не один компьютер на 10-100 человек обслуживающего персонала, а один человек может обслуживать 10-100 компьютеров. А вот принципиальный дизайн ОС семейства Unix остался по сути прежним. Вот только современные дистрибутивы Unix/Linux всеми силами пытаются его скрыть от пользователя под красивыми обёртками (включая новые более удобные версии утилит командной строки и графический интерфейс, если говорить про desktop). Но что скрывается под этими обёртками?

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

Я вот честно не помню даже такую простую команду, т.к. взаимодействую с Linux крайне редко. Но что нам выдаёт Google? Первый результат поиска по строке ‘linux command line free disk space’ ведёт на статью ‘5 Linux commands to check free disk space’. Что? 5 способов узнать свободное место на диске? Зачем мне 5 способов, когда у меня всего лишь один диск. :)(:
Ну ладно. df -h выглядит как то, что нужно.

О-г-о. Ну надо же, сколько полезной информации выдала эта команда!

Напомню: у меня в системе всего один диск. А вот это вот всё к чему всё это?? Или предполагается, что продвинутые пользователи должны знать, что обозначает каждый "девайс"/‘точка монтирования’ в этом списке?

Или взять тот же Android. Зачем там внутренний storage разбит на такую кучу разделов? Если это упрощает жизнь разработчикам, то с дизайном операционной системы явно что-то не так.

В этом отношении дизайн Windows гораздо лучше ориентирован на пользователя: вместо непонятных точек монтирования используются логические диски. И в новой ОС я бы взял за основу эту же идею, только вместо буквенного названия дисков я предлагаю числовое, при этом диск 0 — это системный диск (аналог диска C в Windows).

Название для новой ОС я также предлагаю взять цифровое: 9os или просто 9.
[Почему именно 9? Ну, когда говорят 10-ка или 8-ка, то обычно подразумевают Windows. Но если Windows 8 и Windows 10 есть, то Windows 9 нету, так почему бы не использовать именно эту цифру.]

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

До сих пор существует нездоровая ситуация, когда операционную систему очень просто убить одной неверной командой, выполненной от имени администратора/суперпользователя. (Даже без дополнительного подтверждения и без ввода пароля.) Да, простого rm -rf / уже не достаточно, но с такой задачей справляется команда чуть подлиннее.
Более того, практически любая современная ОС без дополнительной настройки защищает только свои системные файлы, а не файлы пользователя, которые можно модифицировать или вообще удалить любой программой без прав администратора.

Как-то лет 10 назад я получив [бесплатно и навсегда] 100 Гб в Облаке Mail.ru решил обезопасить все свои файлы в облаке. (Одной из причин, вероятно, была возникшая как раз в то время ситуация, когда автоматическое обновление Яндекс.Диска с версии 1.1.5 на 1.1.6 или 1.1.7 частично убивало раздел с операционной системой.)
Т.к. я не использовал веб-интерфейс для заливки новых файлов в облако и использовал клиентское приложение только на одном компьютере, я решил вообще запретить клиентскому приложению mail.ru-облака изменять/удалять какие-либо файлы на моём компьютере [точнее, ноутбуке], а разрешить только читать [чтобы получить одностороннюю синхронизацию]. Я попробовал два способа [я опущу детали этой настройки, например, необходимо было оставить доступ к служебным файлам .cloud.db, .cloud_ss, .cloud_temp_* в каталоге с облаком], используя встроенные в Windows 7 возможности настройки прав доступа для каталогов и файлов (вкладка ‘Безопасность’ в свойствах каталога):

1. Сперва я установил разрешение изменять/удалять любые файлы в каталоге C:\Cloud@Mail.Ru только от имени администратора. Тогда не только Облако Mail.ru, но и любая программа без привилегий не могла ничего испортить в этом каталоге. Но такое решение оказалось не удобным: загрузить например новые фотографии в папку было можно, а вот изменить (например, применить ‘поворот JPEG без потерь’) уже нет. С документами работать также было очень затруднительно.
2. Тогда я решил добавить в систему специального пользователя, у которого нет прав, кроме чтения каталога C:\Cloud@Mail.Ru, и запускать Облако Mail.ru только от имени этого пользователя (используя команду runas). Но в итоге, я так и не смог заставить надёжно работать это решение так, как задумывалось: клиент mail.ru-облака не мог изменять/удалять мои файлы, но мог добавить новую папку в C:\Cloud@Mail.Ru, к которой он впоследствии имел уже полный доступ. Постоянно возникали какие-то мелкие проблемы при работе с этой папкой, о которых я сейчас уже не могу вспомнить, увы, но сейчас на другом ноутбуке после установки Облака Mail.ru я решил больше не заморачиваться с такой настройкой и оставить всё как есть, в надежде, что история, аналогичная произошедшей с ЯДом, никогда не повторится.

Вообще, я считаю, что если ОС спроектирована и настроена правильно, то какими бы не были криворукими [не имею в виду никого конкретно, это гипотетически] разработчики приложения синхронизатора, оно [это приложение] в принципе не должно иметь возможность причинить вред ни операционной системе, ни пользовательским файлам (ну, за исключением тех файлов, с которыми это приложение непосредственно работает). Ещё лучше, если безопасная работа ОС не потребует настройки, а будет по умолчанию.

Как это может выглядеть?
Что если все приложения будут запускаться по умолчанию в sandbox-контейнере, при этом контейнером будет являться… просто директория на диске. Т.е. при запуске любого приложения оно может делать что угодно только в пределах его директории (в том числе обновлять себя и синхронизировать файлы в данной директории, для чего приложению открыт [возможно, ограниченный] доступ к локальной сети и Интернет).
Если приложение — это онлайн-игра, то ей в общем-то ничего больше и не нужно — достаточно возможности обновлять свои файлы с данными/ресурсами и хранить локальные настройки игрового клиента (настройки игровые разумнее хранить на сервере).
Если приложение — это текстовый или графический и какой угодно редактор, то для возможности редактирования какого-либо файла вне своей директории приложение обязано вызвать системную функцию (аналог OpenFileDialog() или SHBrowseForFolder() в Windows), которая посредством системной службы отобразит окно выбора файла, где пользователь выберет тот файл, который он хочет отредактировать и после выбора файла приложение будет иметь возможность читать и писать только этот выбранный пользователем файл. Если редактор был открыт путём клика мышью на иконке файла соответствующего типа, то редактор также может читать и писать только этот файл. Операционная система будет хранить список последних открытых файлов и давать возможность читать/писать их редактору без подтверждения со стороны пользователя.
С утилитами командной строки можно поступить аналогично: предоставлять доступ на чтение и запись всем файлам, присутствующим в списке аргументов командной строки.

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

Есть ещё и такая идея: расширение файла должно определять не просто ‘программу, которая открывает файлы данного типа’, а ‘набор/множество программ, которые в принципе имеют право изменять файлы с таким расширением’. К примеру, изменять файлы с расширением .docx или .xlsx должно быть разрешено только ограниченному набору программ (офисных пакетов). Структура .docx или .xlsx файла достаточно сложная, это не plain text, и будет очень странно, если такой файл вдруг захочет модифицировать, скажем, программа-видеопроигрыватель [а такое может произойти, если пользователь ненароком установил расширение/плагин, содержащий, например, вирус-шифровальщик (ну или злоумышленник подменил плагин, встроив в него вредоносный код)]. Причём, если какая-то программа захочет модифицировать файл не своего типа, то нужно не выдавать окошко с ОК/Отмена, т.к. пользователи не всегда внимательно читают текст в таких окошках, а просто показывать информационное окно о том, что программа пыталась выполнить несанкционированную операцию и операция была отклонена, но если такую операцию действительно необходимо разрешить, тогда, уважаемый пользователь, соблаговолите залезть в настройки системы и руками добавить необходимое разрешающее правило.
Также должна быть возможность установить разрешение на модификацию некоторых файлов только для некоторой программы или программ. К примеру, я веду свои записи в небольшом количестве текстовых файлов, с которыми я работаю исключительно в Sublime Text. И я бы хотел иметь возможность добавить правило, работающее на уровне операционной системы, которое бы запрещало открывать соответствующий файл на запись (т.е. вызывать функцию CreateFile() с dwDesiredAccess установленным в GENERIC_WRITE) для всех процессов, кроме sublime_text.exe, который имеет определённую хэш-сумму и который лежит в определённой директории. Последнее нужно для того, чтобы злоумышленник не мог выполнить вредоносный плагин к Sublime Text, т.к. Sublime Text при запуске загружает плагины из своей директории и можно скопировать доверенный sublime_text.exe в отдельную директорию с вредоносным плагином. Но все нужные мне плагины к Sublime Text я пишу сам используя тот же Sublime Text, поэтому все файлы в директории с Sublime Text разумно разрешить [опять же на уровне операционной системы] редактировать только через Sublime Text.

Существует мнение, что на системном разделе не нужно хранить важные данные, чтобы в случае чего всегда можно было его отформатировать и легко переустановить систему. Я с таким мнением категорически не согласен. Во-первых, разделение физического диска на логические приводит к тому, что часть места остаётся недоступной для пользовательских данных с одной стороны [если на одном разделе свободно 20 Гб и на другом 20 Гб, то игрушку на 30 Гб поставить уже не получится], и с другой стороны есть риск нехватки места под систему в системном разделе, что приводит к серьёзной проблеме, т.к. свободно менять размеры непустых логических разделов [забирая место у одних и отдавая его другим] как правило нельзя. Во-вторых, я считаю, что операционной системе достаточно одной директории на диске. Зачем ей отдельный раздел? И в-третьих, переустановка системы потеряет все системные настройки и систему придётся настраивать заново, а то и переустанавливать программы. Все пользовательские настройки системы, как я считаю, должны лежать в понятном месте (в одной поддиректории внутри системной директории, к примеру), легко сохраняться/восстанавливаться (например переноситься со старого ноутбука на новый) и иметь поддержку версионирования "из коробки" — для этого настройки должны храниться в текстовом формате, дружественном для систем управления версиями (типа Git), чтобы можно было легко посмотреть какие конкретно изменения в настройках системы были сделаны за последнюю неделю например (и какая именно программа сделала эти изменения — это должно быть указано в commit message).

Неломающиеся символические ссылки

Жёсткие ссылки используют вместо "мягких"\soft из-за того, что последние ломаются. А что если сделать их неломающимися?
Концептуально символические ссылки в новой ОС я предлагаю реализовать в виде простого текстового файлика с расширением .~ [я думал использовать юникодный символ