Что такое программы, системы и подсистемы unix?
Команды UNIX выполняются в интерфейсе командной строки, предоставляемом оболочкой. Эта оболочка является программой, которая будет читать введенные команды и либо выполнять их самостоятельно, либо передавать их ядру.
«Ядро ядра» — это то, вокруг чего построены системы UNIX, которые управляют системой и другими процессами. Это ядро операционной системы UNIX, которое напрямую взаимодействует с базовым оборудованием для предоставления набора стандартных сервисов. Подсистемы ядра могут включать управление процессами, управление файлами, управление памятью, управление сетью и другие.
Программы UNIX предназначены для разработки нескольких основных принципов, в том числе таких требований, как единственная цель, совместимость и работа со стандартизованным текстовым интерфейсом.
Когда дело доходит до функций UNIX, вот список нескольких выдающихся:
- Позволяет использовать одни и те же ресурсы для разных пользователей в одной системе.
- Обеспечивает многозадачность, при которой каждый пользователь может выполнять много процессов одновременно.
- Первая операционная система написана на языке высокого уровня, что позволяет легко переносить ее на другие машины с минимальными адаптациями.
- Иерархическая файловая структура, облегчающая доступ и обслуживание данных.
- Встроенные сетевые функции для легкого обмена информацией между пользователями.
Почему у нас этого нет?
Здесь ничего нового. И у нас до сих пор этого нет? Почему так?
Подозреваю, что главная причина просто в сложности разработки успешной операционной системы. Гораздо удобнее расширять существующую систему, чем создать нечто новое; но расширение также означает, что вы ограничены выбором, сделанным в прошлом.
Можем ли мы в реальности создать Идеальную ОС? Подозреваю, что нет. Никто не сделал это до сих пор, потому что, если честно, здесь не заработаешь деньги. А без денег просто не найдёшь ресурсы для разработки.
Однако если кто-то всё-таки поставит цель создать такую ОС или хотя бы рабочий прототип, то я бы начал с конкретного ограниченного набора аппаратного обеспечения с существующими драйверами устройств. Недостаточная поддержка драйверов всегда была ахиллесовой пятой десктопного Linux. Например, Raspberry Pi 3 будет отличным вариантом.
Так что мой вопрос к вам: как вы думаете, идея стоит усилий на её реализацию, хотя бы для создания рабочего прототипа? Вы бы поучаствовали в таком проекте? Какая часть функциональности должна работать, чтобы вы согласились взять систему для тестирования? И конечно, как нам её назвать?
«современные» десктопные ос раздуты
Возьмём Raspberry Pi. За 35 долларов я могу купить отличный компьютер с четырьмя процессорными ядрами, каждое на частоте более
гигагерца
. У него также есть 3D-ускоритель, гагабайт оперативки, встроенные WiFi с Bluetooth и Ethernet. За 35 баксов! И всё-таки для многих задач, которые я хочу на нём запустить, Raspberry Pi ничем не лучше компьютера на 66
мегагерц
, который был у меня в колледже.
На самом деле, в некоторых случаях он справляется даже хуже. Требовались огромные усилия, чтобы запустить Doom с 3D-ускорением в X Windows в середине 2000-х, тривиальная задача для середины 1990-х в Microsoft Windows.
Ниже показан скриншот среды Processing, впервые запущенной на Raspberry Pi с аппаратным ускорением, всего пару лет назад. И это стало возможным только благодаря совершенно особому видеодрайверу X Windows. Этот драйвер по прежнему остаётся экспериментальным и официально не выпущен, спустя пять лет после выхода Raspberry Pi.
Несмотря на проблемы с X Windows, у Raspberry Pi на удивление мощный GPU, который способен выдавать результат как на скриншоте внизу, но только если убрать с пути X Windows (реальный скриншот внизу сделан в OS X, но тот же код работает в Pi 3 на 60 fps).
Или другой пример. Сегодня Atom — один из самых популярных редакторов. Разработчики любят его за кучу плагинов, но давайте посмотрим, как он написан. Atom использует Electron, то есть по сути целый веб-браузер со средой выполнения NodeJS. Это два движка Javascript, встроенных в одно приложение.
Долгое время Atom не мог открыть файл больше двух мегабайт, потому что прокрутка слишком тормозила. Проблему решили, написав реализацию буфера на C , по сути удалив один лишний слой.
Даже самые простые приложения в наше время очень сложные. Почтовый клиент вроде такого, как на скриншоте вверху, концептуально прост. Там должгно быть несколько запросов к БД, текстовый редактор и модуль для коммуникации с серверами IMAP и SMTP. Но создание нового почтового клиента — сложная задача, и он занимает много мегабайт на диске, так что немногие берутся за это.
И если вы хотите модифицировать свой почтовый клиент или хотя бы тот, что на скриншоте (Mail.app, клиент по умолчанию для Mac), то не существует ясного способа, как расширить его функциональность. Нет плагинов. Нет расширений API. Это результат многослойного хлама и раздувания.
Beos linux =?
Выше мы уже говорили о попытках возродить перспективную BeOS. Здесь речь пойдет о том, как эта система повлияла на другие разработки. Если приглядеться, кое-какие новации от BeOS можно обнаружить даже в Linux. Например, в KDE для быстрого копирования или перенесения файлов применяется точно такой же элемент управления, как и в Tracker’е (аналог Проводника в Windows или Dolphin в Linux).
Проект AtheOS создавался норвежским программистом Куртом Скауеном первоначально как аналог операционной системы AmigaOS, работающей на платформах Amiga и PowerPC. Сам проект двигался очень медленно, потому что Скауен весьма недоверчиво относился к патчам и дополнениям от других разработчиков и старался выполнять сам весь объем работы.
В конце концов он махнул рукой и оставил проект. На тот момент уже были реализованы собственная файловая система, многозадачность и оригинальный объектно-ориентированный графический интерфейс, похожий на тот, который был применен в BeOS, а также достигнута совместимость на уровне POSIX.
Syllable Desktop: умеем немного — зато на совесть
В 2002 году один из разработчиков AtheOS Кристиан ван дер Влиет объявил о начале работы над новой операционной системой на основе AtheOS — Syllable. Эта система должна была соединить в себе лучшие черты Linux и BeOS, а также стать полноценной альтернативой не только на рынке домашних, но и корпоративных пользователей. Работа началась сразу в двух направлениях — десктопные системы и серверы.
Одним из основных требований была максимальная эффективность системы и способность использовать на пределе все возможности рабочей станции. Syllable была призвана реанимировать «старые» системы и вдохнуть новую жизнь в списанные компьютеры — именно в этом увидели потенциальную нишу для новой системы разработчики.
И это им во многом удалось. Минимум, на котором работает эта система, — процессор Pentium-класса и 64 Мб оперативной памяти. Для самой операционки необходимо 250 Мб на жестком диске, для приложений — больше. Разработчики рекомендуют разворачивать систему на дисках объемом около 1 Гб.
Использовав решения, до этого применявшиеся только в системах реального времени, Кристиан ван дер Влиет добился загрузки системы за 10 секунд даже на слабых компьютерах. Выключение системы занимает еще меньше времени — около 5 секунд. А при нагрузке система не виснет, а только ненамного увеличивает время отклика на команды пользователя.
Кроме того, распределяя функции по специальным разделяемым библиотекам (так, как это было сделано в AmigaOS), разработчики обеспечили поддержку многоядерности и многопроцессорности. Наконец, BeOS послужила для них примером построения программного интерфейса. А вскоре появился релиз.
Одной из интересных особенностей этой системы является… бинарная несовместимость между Syllable Desktop и Syllable Server. Объясняется это тем, что в серверной версии ядро AtheOS было заменено на ядро Linux. Это позволило легко портировать специальное программное обеспечение (такое как служба openSSH или веб-сервер Cheyenne).
Параллельно шла работа по созданию собственной серверной системы Syllable. Для ее реализации, а также в качестве встроенного языка системы был выбран язык REBOL. Обычно в качестве встроенного языка берется что-нибудь очень простое. Простыми скриптовыми языками являются командный процессор Bash в Linux или язык командных файлов в Windows.
REBOL — это иной случай: очень мощный язык, изначально включающий в себя средства для работы с сетью, мультимедиа, графическим интерфейсом и даже с базами данных. Впервые он был применен в AmigaOS и именно оттуда его позаимствовали разработчики Syllable.
О способностях этого языка можно судить уже по тому, что в декабре 2022 года полностью на REBOL была переписана встроенная в Syllable система управления веб-контентом (это позволило перенести ее с Syllable Server на Syllable Desktop). Вряд ли какой-нибудь другой командный процессор справился бы с подобной задачей.
На сегодняшний момент Syllable ни к домашнему, ни к корпоративному использованию не готова. Вопросы вызывает даже тривиальная установка системы: разработчики специально предусмотрели целый ряд разных сценариев, оптимизированных под разные варианты. И даже при их наличии система не всегда устанавливается гладко — у автора это вышло примерно на третий раз. Однако потенциал у системы большой, и ее будущие релизы заслуживают пристального внимания.
Linux
Бесплатная и открытая ОС, предназначенная для компьютеров и ноутбуков. Данная операционная система популярна в кругу небольшого количества пользователей. Трудно настраиваемый, не пригодный для игр вариант. Кроме того, игры в принципе редко разрабатываются для данной системы.
Имеется достаточно дистрибутивов Линукса, которые зачастую очень сильно различны между собой. Однако чаще всего пользователи делают выбор в сторону Ubuntu. Все дело в высокой скорости работы, приятном интерфейсе и удобстве при эксплуатации.

Отличительные характеристики:
- Открытая и бесплатная OC.
- Бесплатное программное обеспечение.
- Есть возможность выполнять программы от Windows при помощи эмулятора.
- Хороший уровень безопасности.
- Отличные показатели распределения ресурсов устройства.
- Не подойдет для игр.
- Отсутствие многообразия ПО.
- Трудности при настройке и использовании.
- Сложно найти информацию о решении проблем с системой.
- Ограниченная поддержка аппаратного обеспечения
Microsoft windows
В лагере Windows наблюдалась суматошная активность, поскольку Microsoft пыталась заново изобрести десктоп в качестве операционной системы с поддержкой тачскрина для планшетов и телефонов. Это стало катастрофой, от которой они до сих пор восстанавливаются.
Вместо улучшения десктопного UX они сконцентрировались на добавлении новых моделей приложений со всё большим и большим количеством слоёв поверх старого кода. Между прочим, Windows по-прежнему может запускать приложения начала 90-х.
Терминальную программу CMD.exe, которая по сути позволяет вам запускать DOS-приложения, заменили только в 2022 году. А самая значительное нововведение в последней версии Windows 10? Они добавили подсистему Linux. Наложили сверху ещё больше слоёв.
X windows

Улучшений в X Windows было даже меньше, чем в двух других десктопных ОС. На самом деле, эта модель олицетворяет собой отсутствие изменений. Люди жаловались на это ещё в начале 90-х. Я рад, что можно поменять скин в GUI, но что насчёт сквозного системного буфера, в который помещается больше одного элемента за раз? Это не изменилось с 80-х годов!
В середине 2000-х добавили компоновку оконных менеджеров, но из-за легаси-проблем его нельзя использовать ни для чего, кроме перемещения окошек туда-сюда.
Wayland должен был всё исправить, но спустя десять лет разработки он по-прежнему ещё не готов. Действительно трудно обеспечить совместимость со старым кодом. Думаю, что Apple приняла правильное решение, когда перенесла старую macOS в эмулятор под названием Classic, изолировав его от нового кода.
Абсолютно ненужная вещь
Рассказ об альтернативных операционных системах был бы неполон без Plan 9, которую иногда называют «самой ненужной системой».
Фильм Эдварда Вуда-младшего «План 9 из внешнего космоса» у нас широкой публике неизвестен, в то время как в Соединенных Штатах лента превратилась в своего рода символ провала и неудачи. Она даже получила приз «Золотая индюшка» как худшая кинопостановка всех времен и народов.
Задача была сверхамбициозная: двинуть дальше концепцию Unix и создать систему нового поколения. Но если создатели той же BeOS или QNX пошли по пути дальнейшей специализации и создания гибкой и легко расширяемой иерархии функций и библиотек, то Plan 9 пошла по пути унификации.
Все ресурсы в системе являются файлами, а все функции сводятся к действиям над ними — созданию, открытию, чтению и записи. Файлы расположены в единой файловой системе, причем безразлично, где физически расположены соответствующие им устройства — где-нибудь в сети или на локальной рабочей станции.
Проблема разделения ресурсов, таким образом, просто исчезает. Можно даже использовать звуковую карту другого компьютера — достаточно скопировать в свою файловую систему нужный файл (такой пример описывается в официальной документации как одна из штатных возможностей системы).
Даже доступ к Интернету осуществляется при помощи открытия сетевого адреса как файла. Все это отражало главную цель создания Plan 9 — превратить компьютер в часть огромной распределенной вычислительной системы (эдакого сверх-сверх-суперкомпьютера), в которой нашли бы себе место как дешевые и слабые машины, так и мощные многопроцессорные станции.
Однако этой мечте, увы, не суждено было сбыться. Как и предсказывали создатели Plan 9, все окончилось провалом. Работа, начавшаяся еще в середине 80-х, была полностью свернута на рубеже тысячелетия, а сама операционная система выпущена под свободной лицензией.
Странности Plan 9: достаточно выделить текст — и его можно выполнить как команду
Вполне вероятно, что именно так будут выглядеть операционные системы нашего будущего, а пока у нас есть «План 9», с помощью которого к нему можно прикоснуться. Или даже самому попробовать создать небольшую распределенную систему. Plan 9 хорошо относится к новичкам, а солидный пласт русскоязычной документации поможет им в работе.
В последующих статьях мы подробно расскажем о том, как совместить разные операционные системы на одном компьютере, в том числе установить несколько операционных систем или использовать их параллельно в режиме виртуализации.
Вячеслав Трухманов
База данных документов
Начнём с общей для системы базы данных документов. Не будет ли проще создать новый почтовый клиент, если база данных уже готова? UI будет состоять всего из нескольких строчек кода. В реальности, многие обычные приложения — это всего лишь текстовые редакторы в сочетании с запросами данных.
Возьмите iTunes, адресную книгу, календарь, уведомления, сообщения, Evernote, список дел, закладки, историю браузера, базу паролей и менеджер фотографий. Каждая из этих программ оснащена собственным уникальным хранилищем данных. Столько впустую потраченных усилий и помех для взаимодействия!
BeOS доказала, что файловая система с базой данных действительно может работать и обеспечивает невероятные преимущества. Нам нужно её вернуть.
У файловой системы с БД документов много преимуществ перед традиционной файловой системой. Не только «файлы» существуют более чем в одном месте и становятся легко доступны для поиска, но гарантированное наличие высокопроизводительной БД намного облегчает создание приложений.
К примеру, возьмём iTunes. Он хранит mp3-файлы на диске, но все метаданные находятся в закрытой базе данных. Наличие двух «источников правды» создаёт массу проблем. Если вы добавляете на диск новую песню, то нужно вручную указать iTunes заново просканировать её.
Выбор подходящей операционной системы для компьютера
Чтобы определиться с конкретной ОС необходимо знать задачи, которые она должна будет выполнять. В этом смысле можно выделить несколько целей взаимодействия с ПК:
Если вы собираетесь использовать свое устройство для игр, то лучше всего подойдет именно Windows. Данная ОС может запускать большинство современных игр и приложений. Отличный вариант для проведения времени в шутерах, стратегиях, квестах и т.д. В данной операционной системе наиболее актуальными магазинами игр будут: Steam, Оrigin, Battle. Net. Также при желании можно подключить к компьютеру игровую приставку.
В этой сфере самым оптимальным решением для вас станет LInux. В этой ОС очень удобно работать с интернетом, дизайном и утилитами, которые помогают осуществлять качественное программирование. В Linux существует огромное количество конфигураций, что позволит вам настроить OС под свои задачи.

Для работы с видео/аудио редакторами лучше всего подходит MacOS. Данная система сможет обеспечить высококачественную обработку звука, отличную скорость рендеринга видео и плавность выполнения задач. В особенности это касается iMAC или MacPRO. Кроме того, эта ОС выпускается с уже установленными программами для работы с медиаконтентом.
Теперь вы обладаете базовыми знаниями о видах операционных систем. С каждым годом технологический прогресс идет все дальше и дальше, а это значит, что ОС также будут идти в ногу со временем.
Зачем вашей компании гибкая операционная модель и как ее внедрить
Бизнес в условиях неопределенности требует изменений в структуре и процессах компании. Один из оптимальных шагов — переход к более гибкой модели управления. Сооснователь Stadik Алексей Ян рассказывает, что она собой представляет и как ее безболезненно внедрить в своей компании.
От конвейера — к командам
Для начала перечислим основные отличительные особенности гибкой операционной модели:
1. Кросс-функциональные команды как новая норма
Поэтапный производственный конвейер — не лучшее решение в эпоху перемен. Гибкая операционная модель предусматривает переход к небольшим кросс-функциональным командам с более плотной и прямой внутренней коммуникацией. Мультидисциплинарные знания участников и фокус на совместном принятии решений позволяют угадывать движение рынка быстрее и точнее.
2. Сквозное целеполагание: от стратегии компании до целей команд
Производственные команды формируются вокруг ценности для клиента, несут ответственность за бизнес-показатели и сами решают, как их достигать. Исполнители участвуют в обсуждении и формировании целей, добавляя реалистичный взгляд на ограничения технологий и возможности рынка. Это повышает точность планирования и долгосрочную производительность команд.
3. Планирование и отчетность: легковеснее, чаще и практичнее
Переход на итеративный подход к планированию с разной гранулярностью планов на разных уровнях бизнеса: стратегия на три-пять лет → годовой план компании → квартальные планы подразделений → одно- двухнедельные планы команд-исполнителей. Все уровни пересекаются на ежеквартальном обзоре результатов. По его итогам адаптируют как стратегию, так и краткосрочные планы производства.
5 шагов к гибкости
В России лидерами в применении гибкой модели являются банки, компании из IT-сектора и телекома. Среди них — «Сбер», Альфа-банк, ОТП Банк, X5, «Мегафон», «М.Видео». Но внедрить гибкую модель можете у себя и вы. Вот пять шагов, которые для этого нужно сделать:
Шаг 1. Знакомство с особенностями новой модели
Акционеры компании или ее первое лицо приходят к необходимости изменений и разбираются в новых подходах, чтобы понять, решат ли они проблемы. В этом помогают лекции, воркшопы, референс-визиты. Часто драйвером этапа становится сторонняя консалтинговая фирма.
Шаг 2. Аудит
Цель этого шага — оценить положение компании на рынке, ограничения IT-инфраструктуры, укомплектованность команд. Определяем свои слабые места и точки роста: что мешает добиться результата, какие факторы тормозят развитие?
Пример из практики: Крупный банк хочет перейти к кросс-функциональным командам в разработке всех цифровых продуктов — чтобы ускорить производство и улучшить качество. Аудит показывает, что монолитная архитектура core-систем ограничивает распределенную доработку и это будет сдерживать эффективность команд. Решение — «пилотировать» изменения в подразделении по разработке мобильного банка и создать поэтапный план перехода core-систем от монолита к микросервисам.
Шаг 3. Пилот
В течение двух-шести месяцев организация примеряет модель на части бизнеса и исследует свои ограничения. Это может быть несколько команд (от 20 до 50 человек), работающих над единым продуктом, или небольшое подразделение. Для этих сотрудников внедряют новые инструменты планирования, мониторинга и отчетности, меняют систему мотивации. Цель этапа — адаптировать модель к специфике организации и составить детальный план масштабирования.
Пример из практики: Для пилотирования выбрали подразделение, развивающее мобильный банк. Тестирование модели показало, что наем и обучение менеджеров продукта являются ключевыми ограничениями для масштабирования. Решено организовать внутреннюю продуктовую школу, которая станет поставщиком кадров для следующего этапа изменений.
Шаг 4. Масштабирование
Цель этапа — использовать весь потенциал гибкой модели для конкретной организации. Часто в результате пилота становится очевидно, что для этого требуется глубокое изменение оргструктуры, перераспределение ответственности между подразделениями, реструктуризация иерархии менеджмента. Такие изменения могут занять несколько месяцев и даже лет.
Пример из практики: После пилотирования на одном продукте российский банк решил перевести всю change-составляющую компании (от Change-Run-Disrupt) в гибкую модель. Для части организации размером в 600 человек процесс занял девять месяцев.
Шаг 5. Поддержка и мониторинг
Этап отличается от компании к компании и зависит от масштаба изменений, размера и типа организации, ее целей. Однако всегда важно сохранять фокус на анализе эффективности, развитии навыков и привычке постоянно оптимизировать модель. Ответственность за изменение и совершенствование системы переходит от топ-менеджмента и внешних консультантов в руки внутренних центров экспертизы и команд-исполнителей. Финальной точки в этом процессе не существует.
Ограничения гибкой модели
Как у любого другого инструмента, у гибкой модели есть ограничения, которые важно учитывать с самого начала. Мы выделили три основных, актуальных для большинства крупных компаний СНГ.
Инкунабула
MenuetOS десять лет назад произвела настоящий фурор среди разработчиков всего мира. Это была очень маленькая операционная система, занимавшая чуть меньше мегабайта. Для ее развертывания хватало одной трехдюймовой дискеты, но при этом пользователь мог работать в полноценном графическом интерфейсе, выполнять одновременно несколько задач и даже работать в сети.
Создали эту компьютерную миниатюру два программиста — финн Вилле Турьянмаа и эстонец Мадис Кальме. Они не хотели повторять успех Линуса Торвальдса, им просто захотелось написать операционную систему на чистом ассемблере. Турьянмаа интересовался границами применения ассемблера для создания быстрой и компактной системы, а Кальме увлекался построением графических интерфейсов.
Наиболее пристальный интерес эта операционная система вызвала у разработчиков на территории бывшего Советского Союза. Во-первых, она была маленькой. Во-вторых, ассемблер является одним из наиболее простых языков, а имея в своем распоряжении такой компактный и мощный программный интерфейс, который заложили в MenuetOS ее авторы, можно было при минимуме затрат получить прекрасный результат.
В-третьих, в отличие от Linux или иной альтернативной операционной системы, здесь не нужно было придерживаться жестких норм стандарта. В 2005 году благодаря русскому программисту Ивану Поддубному появился «форк» (то есть ответвление) MenuetOS под названием Kolibri, который вскоре сравнялся по возможностям с материнской системой, а потом и превзошел ее.
Кроме того, в 2005 году Вилле Турьянмаа увлекся 64-битной версией системы, а 32-битный вариант был им заброшен. Продолжение разработки Kolibri вызвало раскол в сообществе, и новосозданная группа KolibriOS Project Team отправилась в самостоятельное плавание.
Получив независимость, группа начала работать над поддержкой языков высокого уровня. Диктовалось это тем, что большая часть существующего пользовательского ПО написана именно на них. А поскольку новая система бинарно не совместима ни с Windows, ни с Linux, нужен иной вариант — на уровне исходников.
Были реализованы C/C , Pascal и Forth. Следующим этапом был отказ от минималистского ядра. Нынешний дистрибутив Kolibri остается очень маленьким, но почти вдвое крупнее исходного и занимает чуть больше 3 МБ. При этом систему все еще можно уместить на дискету, однако в таком случае она окажется «голой» — без пользовательских программ.
А их на сегодня существует уже более 250, включая игры, архиваторы и файловые менеджеры. Есть поддержка видеокарт, звуковых плат и различных файловых систем, а возможность загружаться прямо с USB делает ее одним из удобных средств «снятия» информации с компьютера после фатального сбоя операционной системы.
Мечта малыша: чего в Kolibri хватает с избытком — так это простых и понятных игр
Классификация операционных систем
Существует несколько классификаций ОС.
В зависимости от способа организации вычислений:
- Системы пакетной обработки – основной задачей является организация наибольшего количества вычислительных процессов за единицу времени. Определенные процессы объединяются в пакет, который затем обрабатывает ОС.
- Системы разделения времени – создание возможности единовременного взаимодействия с устройством сразу несколькими людьми. В порядке очереди каждый пользователь получает определенный промежуток процессорного времени.
- Системы реального времени – организация работы каждой задачи за определенный промежуток времени, присущий каждой конкретной задаче.

В зависимости от типа ядра:
- OС с монолитным ядром;
- OС с микроядром;
- OС с гибридным ядром.
В зависимости от количества единовременно решаемых задач:
- однозадачные;
- многозадачные;
В зависимости от количества пользователей:
- однопользовательские;
- многопользовательские.
В зависимости от количества поддерживаемых процессоров:
- однопроцессорные
- многопроцессорные
В зависимости от возможности работы в компьютерной сети:
- локальные – автономные ОС, которые не позволяют работать с компьютерными сетями;
- сетевые – ОС с поддержкой компьютерных сетей.
В зависимости от роли в сетевом взаимодействии:
- серверные – ОС, открывающие доступ к ресурсам сети и осуществляющие управление сетевой инфраструктурой;
- клиентские – ОС, которые имеют возможность получения доступа к ресурсам сети.
В зависимости от типа лицензии:
- открытые – ОС с открытым исходным кодом, который можно изучать и редактировать;
- проприетарные – ОС, связанные с определенным правообладателем и, как правило, имеющие закрытый исходный код.
В зависимости от сферы использования:
- ОС мэйнфреймов – больших компьютеров;
- ОС серверов;
- ОС персональных компьютеров;
- OC мобильных устройств;
- встроенные OC;
- OC маршрутизаторов.
Компоновщик
Теперь мы можем добавить компоновщик — оконный менеджер, который по-настоящему работает с 3D-поверхностями, преобразует координаты и контролируется через сообщения по шине. Большую часть того, что делает типичный менеджер, вроде размещения окон, наложения уведомлений и определения, какое окно активно, на самом деле могут делать другие программы, которые просто присылают сообщения в компоновщик, а он уже выполняет реальную работу.
Это значит, что компоновщик будет тесно интегрирован с графическим драйвером, это важно для обеспечения высокой производительности. Ниже показана схема Wayland — компоновщика, который когда-нибудь станет работать по умолчанию в Linux.
Приложения выводят графику на экран, запрашивая поверхность у компоновщика. Завершив вывод графики и при необходимости обновления они просто отправляют сообщения: пожалуйста, перерисуй меня. На практике у нас, вероятно, будет несколько типов поверхностей для 2D- и 3D-графики, а может и для необработанного видеобуфера.
Нам нужна современная рабочая станция

Итак, теперь мы выходим на теоретический уровень. Предположим, у нас действительно есть ресурсы и способ обеспечить (или игнорировать) обратную совместимость. Предположим, мы действительно можем создать нечто, чтобы по-другому спроектировать десктоп для современных методов работы. Как мы это сделаем?
Для начала нужно избавиться от всего, что не справляется со своими задачами.
- Традиционные файловые системы иерархические, с медленным поиском и не хранят по умолчанию все необходимые нам метаданные.
- Все межпроцессные взаимодействия. Существует слишком много способов коммуникации между программами. Каналы, сокеты, общая память, RPC, вызовы ядра, drag-and-drop, копипаст.
- Интерфейсы командной строки не соответствуют современному использованию приложений. Мы просто не можем всё делать в чистом тексте. Я бы хотел перенаправить свой видеозвонок по Skype в сервис видеоанализа во время разговора, но я реально не могу запустить видеопоток через awk или sed.
- Оконные менеджеры на традиционных десктопах не следят за контекстом или контентом и не контролируются другими программами.
- Нативные приложения слишком тяжеловесны, их долго разрабатывать и они живут в бункерах.
Так что у нас остаётся? Немного. У нас осталось ядро и драйверы устройств. Мы можем держать надёжную файловую систему, но она не будет доступна для конечных пользователей или приложений. Теперь давайте добавим обратно некоторые элементы.
Ограниченное взаимодействие
У моего компьютера есть мышь, клавиатура, датчики наклона, световые датчики, две камеры, три микрофона и масса Bluetooth-аксессуаров; но только первые два используются как общие устройства ввода. Почему я не могу подать голосом команды компьютеру или жестами в воздухе, а ещё лучше, чтобы он следил за моей работой и сообщил, когда я устал и лучше отдохнуть.
Почему мой компьютер не умеет следить за глазами и смотреть, что я читаю, или сканировать предметы, которые я держу в руках, используя какую-нибудь из этих крутых технологий дополненной реальности, которые скоро появятся на смартфонах. Некоторые из этих функций есть в отдельных приложениях, но они не общие для все системы и не программируемы.
Почему мой Macbook Pro не может по Bluetooth связаться с нужными HID-устройствами вместо синхронизации через Apple Watch. Погодите, а ведь Mac не может синхронизироваться с Apple Watch. Это ещё один пункт, где он уступает моему телефону.
Почему мой компьютер не может использовать ничего кроме дисплея для вывода информации? В новом ноутбуке Razor цветная подсветка под каждой клавишей, но она используется только для переливания цветными волнами. Что насчёт применения светодиодов для какой-нибудь полезной задачи! (идея Бьорна Шталя, я думаю).
Переделка приложений
На такой базе мы можем создать всё, что нам нужно. Однако это также означает, что нам придётся переделывать всё с нуля. Высокоуровневые конструкции поверх БД сильно упростят этот процесс. Посмотрим на несколько примеров.
Электронная почта. Если разделить стандартный почтовый клиент на GUI и сетевые модули, которые общаются исключительно через сообщения по шине, то разработка программы станет намного проще. GUI не должен ничего знать о почте Gmail или Yahoo, или как обрабатывать сообщения об ошибках SMTP.
Разделение почтового клиента на компоненты значительно облегчает замену отдельных его частей. Вы можете разработать новый фронтенд за полдня, и не придётся переписывать сетевые модули. Вы можете разработать спам-фильтр вообще без пользовательского интерфейса, он просто сканирует входящие сообщения, обрабатывает их и помечает подозрительные сообщения тегом «спам». Он не знает и не заботится о том, как отображается спам в GUI. Он просто хорошо делает одну вещь.
Почтовые фильтры могут делать и другие интересные вещи. Например, вы отправили своему боту по почте команду play beatles. Крошечный модуль сканирует входящую почту и отправляет другое сообщение модулю mp3 для воспроизведения музыки, а затем помечает письмо как удалённое.
Когда всё превращается в запросы к БД, то вся система становится более гибкой и настраиваемой.
Приложения становятся модулями
Все приложения превращаются в маленькие модули со всеми коммуникациями через шину сообщений.
Полностью
. Больше никакого доступа к файловой системе. Никакого доступа к аппаратному обеспечению. Всё только в виде сообщений.
Если хотите воспроизвести mp3-файл, то отправляете сообщение play в сервис mp3. Вывод графики на экран через компоновщик. Такое разделение обеспечивает безопасность системы. В терминологии Linux, каждое приложение станет полностью изолировано через разрешения пользователя и chroot, возможно, вплоть до контейнеров Docker или виртуальных машин. Здесь нужно проработать много деталей, но всё решаемо уже сегодня.
Модульные приложения будет гораздо легче разрабатывать. Если база данных — это единственный источник правды, то не нужно делать много работы по копированию данных в память и обратно. В примере с аудиоплеером поле поиска не будет загружать данные и проводить фильтрацию для отображения списка, оно просто определяет запрос.
Список затем привязан к этому запросу, а данные появляются автоматически. Если другое приложение добавляет в базу данных песню, которая соответствует поисковому запросу, то UI плеера автоматически обновляется. Это всё делается без каких-либо дополнительных усилий со стороны разработчика. «Живые» запросы с автообновлением сильно облегчают жизнь и они более надёжны.
Рабочие наборы
И наконец-то мы переходим к тому, что я считаю самым мощным изменением парадигмы в нашей новой Идеальной ОС. В новой системе все приложения представляют собой крошечные изолированные модули, которые знают только то, что говорит им система. Если расценивать БД как единственный источник правды, а сама БД версионированная, а наш оконный менеджер настраивается на любой вкус… то становятся возможными по-настоящему интересные вещи.
Обычно я разделяю личные и рабочие файлы. Это отдельные папки, аккаунты, иногда разные компьютеры. В Идеальной ОС мои файлы могут разделяться средствами самой ОС. У меня может быть один экран с домашней почтой, а другой экран — с рабочей. Это одно и то же приложение, просто инициализированное с разными настройками запросов.
Когда я открываю файл-менеджер на домашнем экране, то он показывает только файлы, предназначенные для домашних проектов. Если я создаю документ на рабочем экране, то он автоматически помечается тегом как строго рабочий документ. Управление всем этим тривиально; просто несколько дополнительных полей в базе данных.
Исследователи из Технологического института Джорджии в реальности описали такую систему в своей научной работе «Giornata: пересмотр метафоры десктопа для содействия высококвалифицированной работе».
Теперь сделаем ещё один шаг. Если всё версионируется, даже настройки GUI и расположение окон (поскольку всё хранится в БД), я могу сохранить состояние экрана. Он будет хранить текущее состояние всех параметров, даже мои сочетания клавиш. Я могу продолжить работу, но всегда будет возможность вернуться к этому состоянию.
Или я могу посмотреть старое состояние — и восстановить его на новом экране. Я по сути создал «шаблон», который можно использовать снова и снова, как только я начинаю новый проект. Этот шаблон содержит всё необходимое: настройки почтового клиента, историю чатов, списки дел, код, окна для описания багов или даже соответствующие страницы Github.
Теперь всё состояние компьютера в сущности рассматривается как репозиторий Github, с возможностью форкнуть состояние целой системы. Думаю, это будет просто волшебно. Люди станут обмениваться полезными рабочими пространствами в онлайне, как образами Docker.
Семантические сочетания клавиш по всей системе
Теперь, после переделки мира, чем займёмся?
Сервисы доступны во всей системе. Это означает, что мы можем запустить единый сервис, где пользователь может назначать сочетания клавиш (keybindings). Это также означает, что у сочетаний клавиш появится более глубокий смысл. Вместо указания на функцию конкретной программы они указывают на сообщение о команде.
Во всех приложениях, которые работают с документами, могут быть команды «Создать новый документ» или «Сохранить». Сервис сочетаний клавиш будет отвечать за превращение control-S в команду «Сохранить». Я называю это семантическими сочетаниями клавиш (semantic keybindings).
С помощью семантических сочетаний клавиш будет гораздо легче поддерживать альтернативные способы ввода. Скажем, вы разработали причудливую кнопку на Arduino, при нажатии на которую звучит какая-то фраза. Вам не нужно писать специальный код для неё. Просто укажите Arduino отправлять событие о нажатии кнопки, а затем привяжите к этому событию аудиофайл в редакторе сочетаний клавиш. Превратите цифровой горшок в кастомное колёсико прокрутки. UI теперь изменяется как угодно.
В этой области ещё необходимы некоторые исследования, но мне кажется, что семантические сочетания клавиш упростят разработку скринридеров и других программ для облегчения доступа.
Создано для 1984 года
Так почему наши компьютеры такие неуклюжие? Суть в том, что они созданы для 1984 года. Десктопный GUI был изобретён, когда большинство пользователей создавали документ с нуля, сохраняли его и печатали. Если вам повезёт, вы могли сохранить документ в общей файловой системе или отправить кому-нибудь по почте. Это всё. GUI создавался для работы с задачами, которые раньше выполнялись на бумаге.
Проблема в том, что мы живём в 2022 году. Мы уже не работаем так, как в 1984-м. В обычный день я получаю код с нескольких удалённых сайтов, создаю несколько тестов и генерирую структуру данных, которая выводит результат, он затем отправляется в интернет для использования другими людьми. Импорт, синтез, экспорт.
Я создаю контент VR. Обрабатываю изображения. Я отправляю сообщения в десятки социальных сетей. Мой идеальный плейлист составляется выбирается из 30 000 песен. Я обрабатываю на порядки больше данных из большего количества источников, чем это было всего 20 лет назад, а тем более 40 лет назад, когда эти концепции изобрели.
Специалист по реальному времени
Если Kolibri делает первые шаги по пути встроенных операционных систем, то QNX в данном сегменте рынка — уже патриарх. Это трудно себе представить, но она даже старше Windows и DOS. Самая первая версия этой операционной системы, выпущенная канадской фирмой Quantum Software Systems (ныне QNX Software Systems), появилась в далеком 1982 году и работала на платформе Intel 8088, которой было суждено войти в историю как IBM PC — первый массовый компьютер для домашнего использования.
Поскольку система оказалась необычайно удачной, она тут же попала под запрет комитета COCOM (более известного как «комитет технологического эмбарго») — как технология двойного назначения. Это и было тем судьбоносным решением, которое отдало пальму первенства продуктам фирмы Microsoft.
QNX завоевала своего пользователя малым размером ядра — оно составляло всего 44 Кб. Для тогдашних встроенных систем это было много, зато для настольных компьютеров открывало огромные возможности. Первой на нее обратило внимание Министерство образования Онтарио в Канаде.
Затем QNX нашла применение в крупных промышленных комплексах, а вторая версия, уже более оптимизированная для применения в производстве и более устойчивая к сбоям, даже стала стандартом отрасли. Она до сих пор широко применяется в канадской промышленности, в отличие от своей младшей «сестры» DOS.
В середине 1990-х, когда уже явно ощущался крен в сторону рабочих станций с графическим пользовательским интерфейсом, QNX Software Systems решила добавить такую функциональность и в свою систему. Поскольку в то время уже набирала популярность Linux, а POSIX-совместимость стала стандартом, разработчики фирмы приняли решение переписать систему с нуля.
Так появилась QNX4, полностью совместимая с Unix-системами. На этом специалисты QSS не остановились. Они добились полной совместимости с NetBSD и Linux, при этом сохранив все преимущества первых версий QNX — микроядерность и ориентированность на работу в реальном времени.
Это так называемая QNX6 — QNX Neutrino, которая стала такой же успешной, как и QNX2. Более того, она оказалась даже меньше четвертой версии — за счет более грамотной реализации стандарта POSIX и улучшенной системы модулей, которые позволили операционке эффективно настраиваться под архитектуру конкретной рабочей станции, а также легко надстраиваться и масштабироваться.
Инструментарий разработчика для QNX: все, что нужно, компактно и под рукой
Стандарт unix
Стандарт действительно появился, но не основанный ни на чем AT & T. Сегодня торговая марка UNIX принадлежит The Open Group . То же самое можно сказать и о Единой спецификации UNIX. Любая операционная система, использующая UNIX, должна была быть сертифицирована The Open Group и соответствовать Единой спецификации UNIX.
Как проиллюстрировано The Open Group:
Для тех, кто заинтересован в посещении ссылки на изображение, вот она.
POSIX, как упоминалось ранее, представляет собой семейство стандартов, определенных Институтом инженеров по электротехнике и электронике (IEEE). Они служат для уточнения и унификации интерфейсов прикладного программирования, предоставляемых UNIX-подобными операционными системами.
Это делает это так, когда вы пишете программу, основанную на стандартах POSIX, переносимость и функциональность упрощаются среди большого семейства производных UNIX, таких как Linux и Mac OS. Использование API или кода, не стандартизированного как часть POSIX для UNIX-подобных операционных систем, усложнит переносимость на другие UNIX-подобные системы.
Умный копипаст
Когда вы скопировали текст из одного окна и переключились в другое, компьютер знает, что вы что-то скопировали. Он может использовать это знание для осуществления каких-нибудь полезных действий, например, автоматически сдвинуть первое окно в сторону, оставив его в зоне видимости, и отобразить выделенный текст зелёным цветом.
Но зачем ограничивать себя этим. Сделаем буфер обмена, который вмещает больше одного элемента. У нас гигабайты памяти. Давайте использовать её. Когда я копирую что-то, почему я должен помнить, что конкретно я копировал перед тем, как вставить это в другом окне? Буфер обмена нигде не видим. Исправим это.
Буфер обмена должен отображаться на экране как некая полка, на которой хранятся все скопированные фрагменты. Я могу зайти на три веб-страницы, скопировать их адреса в буфер обмена, а затем вернуться в документ и вставить все три сразу.
Модуль просмотра буфера обмена позволяет прокручивать всю историю буфера. Я могу искать в ней и фильтровать по тегам. Могу «прикрепить» любимые экземпляры для последующего использования.
В классической macOS на самом деле был отличный встроенный инструмент под названием [name], но от него отказались при переходе на OS X. Десятилетия назад у нас было будущее! Вернём его обратно.
Чего у нас нет в 2022 году
Сейчас 2022 год. Давайте посмотрим, что должно существовать к настоящему времени, но по какой-то причине не существует.
Почему я могу переносить вкладки в браузере и файл-менеджере, но не могу сделать это между двумя разными приложениями? Здесь нет никаких технических ограничений. Окна приложений — это всего лишь растровые прямоугольники из битов, в конечном счёте, но разработчики ОС не реализовали функцию, потому что она не считается приоритетной.
Почему я не могу иметь файл в двух местах одновременно в своей файловой системе? Почему она фундаментально иерархическая? Почему я не могу сортировать файлы по тегам и метаданным? Файловые системы с базой данных существуют десятилетия. Microsoft пыталась внедрить эту функцию в WinFS, но из-за внутренних конфликтов удалила её из системы Vista ещё до её выхода. В BeOS такое сделали двадцать лет назад. Почему этой функции нет в современных ОС?
Любое веб-приложение можно зуммировать. Я просто нажимаю command — и текст становится больше. Все элементы в окне автоматически масштабируются. Почему мои нативные приложения так не умеют? Почему я не могу сделать одно окно с увеличенным текстом, а другое с маленьким?
Гибкий.ру