TL;DR: К концу этого эссе я надеюсь убедить вас в следующих фактах. Во-первых, что современные десктопные операционные системы никуда не годятся. Они раздутые, тормознутые и напичканы легаси-хламом, а кое-как работают только благодаря закону Мура. Во-вторых, что инновации в десктопных ОС прекратились около 15 лет назад, а основные игроки вряд ли собираются много вкладывать в них снова. И наконец, я надеюсь убедить вас, что мы можем и должны начать с нуля, усвоив уроки прошлого.
«Современные» десктопные ОС раздуты
Возьмём 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, встроенных в одно приложение. Приложения Electron используют графические API браузера, которые обращаются к нативным API, которые затем обращаются к GPU (если повезёт) для реального вывода изображения на экран. Столько слоёв.
Долгое время Atom не мог открыть файл больше двух мегабайт, потому что прокрутка слишком тормозила. Проблему решили, написав реализацию буфера на C++, по сути удалив один лишний слой.
Даже самые простые приложения в наше время очень сложные. Почтовый клиент вроде такого, как на скриншоте вверху, концептуально прост. Там должгно быть несколько запросов к БД, текстовый редактор и модуль для коммуникации с серверами IMAP и SMTP. Но создание нового почтового клиента — сложная задача, и он занимает много мегабайт на диске, так что немногие берутся за это. И если вы хотите модифицировать свой почтовый клиент или хотя бы тот, что на скриншоте (Mail.app, клиент по умолчанию для Mac), то не существует ясного способа, как расширить его функциональность. Нет плагинов. Нет расширений API. Это результат многослойного хлама и раздувания.
Нет инноваций
Инновации в десктопных операционных системах по существу остановились. Можно сказать, что они закончились где-то в середине 90-х или даже в 80-е с выходом Mac, но весь прогресс точно остановился после революции смартфонов.
Mac OS
Когда-то Mac OS X блистала фейерверком новых функций, в каждой новой версии наблюдался значительный прогресс и изобретения. Quartz 2D! Expose! Системная синхронизация устройств! Виджеты! Но сейчас Apple вкладывает минимум усилий в десктопную ОС, разве что меняет темы оформления и усиливает привязку к мобильным устройствам.
Последняя версия Mac OS X (сейчас она переименована в macOS в честь системы, которая была двадцать лет назад) называется High Sierra. Какие основные нововведения мы с нетерпением ожидаем этой осенью? Новую файловую систему и новый формат кодирования видео. Действительно, это всё? О, и ещё добавили функцию редактирования в Photos, которая уже была в iPhotos, но её удалили после апгрейда, а ещё они будут теперь блокировать автоматическое произведение видео в Safari.
Apple — самая дорогая компания в мире, и это самое лучшее, что она может придумать? Просто десктопный UX не является для них приоритетом.
Microsoft Windows
В лагере Windows наблюдалась суматошная активность, поскольку Microsoft пыталась заново изобрести десктоп в качестве операционной системы с поддержкой тачскрина для планшетов и телефонов. Это стало катастрофой, от которой они до сих пор восстанавливаются. В процессе этого перехода они не добавили никаких функций, действительно полезных десктопным пользователям, хотя потратили абсурдное количество денег на создание кастомного фонового изображения.
Вместо улучшения десктопного UX они сконцентрировались на добавлении новых моделей приложений со всё большим и большим количеством слоёв поверх старого кода. Между прочим, Windows по-прежнему может запускать приложения начала 90-х.
Терминальную программу CMD.exe, которая по сути позволяет вам запускать DOS-приложения, заменили только в 2016 году. А самая значительное нововведение в последней версии Windows 10? Они добавили подсистему Linux. Наложили сверху ещё больше слоёв.
X Windows
Улучшений в X Windows было даже меньше, чем в двух других десктопных ОС. На самом деле, эта модель олицетворяет собой отсутствие изменений. Люди жаловались на это ещё в начале 90-х. Я рад, что можно поменять скин в GUI, но что насчёт сквозного системного буфера, в который помещается больше одного элемента за раз? Это не изменилось с 80-х годов!
В середине 2000-х добавили компоновку оконных менеджеров, но из-за легаси-проблем его нельзя использовать ни для чего, кроме перемещения окошек туда-сюда.
Wayland должен был всё исправить, но спустя десять лет разработки он по-прежнему ещё не готов. Действительно трудно обеспечить совместимость со старым кодом. Думаю, что Apple приняла правильное решение, когда перенесла старую macOS в эмулятор под названием Classic, изолировав его от нового кода.
Рабочие станции?
В фундаментальном смысле с десктопными ОС стало проще работать, когда они вышли на массовый рынок, но затем этот массовый рынок перешёл на смартфоны и у компаний пропал какой-либо интерес к улучшению десктопных ОС.
Я не могу винить за это Apple и Microsoft (а сейчас и Google). Три миллиарда смартфонов, которые заменяются каждые два года — гораздо более крупный рынок, чем несколько сотен миллионов настольных компьютеров и ноутбуков, которые заменяются каждые пять лет.
Думаю, нам нужно вернуть ощущение от работы с десктопной операционной системой. Такие вещи называли рабочими станциями. Если десктоп освободился от уз массового рынка, то можно снова вернуть операционную систему для работы.
Чего у нас нет в 2017 году
Сейчас 2017 год. Давайте посмотрим, что должно существовать к настоящему времени, но по какой-то причине не существует.
Почему я могу переносить вкладки в браузере и файл-менеджере, но не могу сделать это между двумя разными приложениями? Здесь нет никаких технических ограничений. Окна приложений — это всего лишь растровые прямоугольники из битов, в конечном счёте, но разработчики ОС не реализовали функцию, потому что она не считается приоритетной.
Почему я не могу иметь файл в двух местах одновременно в своей файловой системе? Почему она фундаментально иерархическая? Почему я не могу сортировать файлы по тегам и метаданным? Файловые системы с базой данных существуют десятилетия. Microsoft пыталась внедрить эту функцию в WinFS, но из-за внутренних конфликтов удалила её из системы Vista ещё до её выхода. В BeOS такое сделали двадцать лет назад. Почему этой функции нет в современных ОС?
Любое веб-приложение можно зуммировать. Я просто нажимаю command + — и текст становится больше. Все элементы в окне автоматически масштабируются. Почему мои нативные приложения так не умеют? Почему я не могу сделать одно окно с увеличенным текстом, а другое с маленьким? Или даже масштабировать их автоматически по мере переключения между окнами? Всё это тривиальные вещи для оконного менеджера с компоновкой, тривиальной технологии уже более десяти лет.
Ограниченное взаимодействие
У моего компьютера есть мышь, клавиатура, датчики наклона, световые датчики, две камеры, три микрофона и масса Bluetooth-аксессуаров; но только первые два используются как общие устройства ввода. Почему я не могу подать голосом команды компьютеру или жестами в воздухе, а ещё лучше, чтобы он следил за моей работой и сообщил, когда я устал и лучше отдохнуть.
Почему мой компьютер не умеет следить за глазами и смотреть, что я читаю, или сканировать предметы, которые я держу в руках, используя какую-нибудь из этих крутых технологий дополненной реальности, которые скоро появятся на смартфонах. Некоторые из этих функций есть в отдельных приложениях, но они не общие для все системы и не программируемы.
Почему мой Macbook Pro не может по Bluetooth связаться с нужными HID-устройствами вместо синхронизации через Apple Watch. Погодите, а ведь Mac не может синхронизироваться с Apple Watch. Это ещё один пункт, где он уступает моему телефону.
Почему мой компьютер не может использовать ничего кроме дисплея для вывода информации? В новом ноутбуке Razor цветная подсветка под каждой клавишей, но она используется только для переливания цветными волнами. Что насчёт применения светодиодов для какой-нибудь полезной задачи! (идея Бьорна Шталя, я думаю).
Бункеры приложений
Практически каждое приложение на моём компьютере — это бункер. У каждого приложения есть своя часть файловой системы, своя система конфигурации, свои собственные настройки, база данных, форматы файлов и алгоритмы поиска. Даже свои собственные назначения клавиатурных сочетаний. Это невероятное количество продублированной работы.
Что более важно, отсутствие коммуникации между приложениями очень затрудняет координацию их работы. Основополагающим принципом Unix были маленькие инструменты, которые работают сообща, но в X Windows это вообще не реализовано.
Создано для 1984 года
Так почему наши компьютеры такие неуклюжие? Суть в том, что они созданы для 1984 года. Десктопный GUI был изобретён, когда большинство пользователей создавали документ с нуля, сохраняли его и печатали. Если вам повезёт, вы могли сохранить документ в общей файловой системе или отправить кому-нибудь по почте. Это всё. GUI создавался для работы с задачами, которые раньше выполнялись на бумаге.
Проблема в том, что мы живём в 2017 году. Мы уже не работаем так, как в 1984-м. В обычный день я получаю код с нескольких удалённых сайтов, создаю несколько тестов и генерирую структуру данных, которая выводит результат, он затем отправляется в интернет для использования другими людьми. Импорт, синтез, экспорт.
Я создаю контент VR. Обрабатываю изображения. Я отправляю сообщения в десятки социальных сетей. Мой идеальный плейлист составляется выбирается из 30 000 песен. Я обрабатываю на порядки больше данных из большего количества источников, чем это было всего 20 лет назад, а тем более 40 лет назад, когда эти концепции изобрели. Метафора рабочего стола просто не масштабируется на современные задачи. Мне нужен компьютер, который помогает выполнять современную работу.
Нам нужна современная рабочая станция
Итак, теперь мы выходим на теоретический уровень. Предположим, у нас действительно есть ресурсы и способ обеспечить (или игнорировать) обратную совместимость. Предположим, мы действительно можем создать нечто, чтобы по-другому спроектировать десктоп для современных методов работы. Как мы это сделаем?
Для начала нужно избавиться от всего, что не справляется со своими задачами.
- Традиционные файловые системы иерархические, с медленным поиском и не хранят по умолчанию все необходимые нам метаданные.
- Все межпроцессные взаимодействия. Существует слишком много способов коммуникации между программами. Каналы, сокеты, общая память, RPC, вызовы ядра, drag-and-drop, копипаст.
- Интерфейсы командной строки не соответствуют современному использованию приложений. Мы просто не можем всё делать в чистом тексте. Я бы хотел перенаправить свой видеозвонок по Skype в сервис видеоанализа во время разговора, но я реально не могу запустить видеопоток через awk или sed.
- Оконные менеджеры на традиционных десктопах не следят за контекстом или контентом и не контролируются другими программами.
- Нативные приложения слишком тяжеловесны, их долго разрабатывать и они живут в бункерах.
Так что у нас остаётся? Немного. У нас осталось ядро и драйверы устройств. Мы можем держать надёжную файловую систему, но она не будет доступна для конечных пользователей или приложений. Теперь давайте добавим обратно некоторые элементы.
База данных документов
Начнём с общей для системы базы данных документов. Не будет ли проще создать новый почтовый клиент, если база данных уже готова? UI будет состоять всего из нескольких строчек кода. В реальности, многие обычные приложения — это всего лишь текстовые редакторы в сочетании с запросами данных. Возьмите iTunes, адресную книгу, календарь, уведомления, сообщения, Evernote, список дел, закладки, историю браузера, базу паролей и менеджер фотографий. Каждая из этих программ оснащена собственным уникальным хранилищем данных. Столько впустую потраченных усилий и помех для взаимодействия!
BeOS доказала, что файловая система с базой данных действительно может работать и обеспечивает невероятные преимущества. Нам нужно её вернуть.
У файловой системы с БД документов много преимуществ перед традиционной файловой системой. Не только «файлы» существуют более чем в одном месте и становятся легко доступны для поиска, но гарантированное наличие высокопроизводительной БД намного облегчает создание приложений.
К примеру, возьмём iTunes. Он хранит mp3-файлы на диске, но все метаданные находятся в закрытой базе данных. Наличие двух «источников правды» создаёт массу проблем. Если вы добавляете на диск новую песню, то нужно вручную указать iTunes заново просканировать её. Если хотите разработать программу, которая работает с базой данных песен, то придётся осуществить реверс-инжиниринг формата iTunes DB и молиться, чтобы Apple не изменила его. Все эти проблемы исчезают при наличии единой системной базы данных.
Шина сообщений
Шина сообщений станет единым способом межпроцессных взаимодействий. Мы избавляемся от сокетов, файлов, каналов, ioctrl, общей памяти, семафоров и всего остального. Все коммуникации только через шину сообщений. Мы получаем единое место для управления безопасностью и создания множества интересных функций через грамотное проксирование.
В реальности некоторые из видов коммуникации всё-таки останутся как опции для приложений, которым они необходимы, вроде сокетов для браузера, но все коммуникации с системой и между приложениями идут через общую шину.
Компоновщик
Теперь мы можем добавить компоновщик — оконный менеджер, который по-настоящему работает с 3D-поверхностями, преобразует координаты и контролируется через сообщения по шине. Большую часть того, что делает типичный менеджер, вроде размещения окон, наложения уведомлений и определения, какое окно активно, на самом деле могут делать другие программы, которые просто присылают сообщения в компоновщик, а он уже выполняет реальную работу.
Это значит, что компоновщик будет тесно интегрирован с графическим драйвером, это важно для обеспечения высокой производительности. Ниже показана схема Wayland — компоновщика, который когда-нибудь станет работать по умолчанию в Linux.
Приложения выводят графику на экран, запрашивая поверхность у компоновщика. Завершив вывод графики и при необходимости обновления они просто отправляют сообщения: пожалуйста, перерисуй меня. На практике у нас, вероятно, будет несколько типов поверхностей для 2D- и 3D-графики, а может и для необработанного видеобуфера. Важно то, что в конечном счёте именно компоновщик контролирует всё, что появляется на экране, и когда. Если одно приложение сходит с ума, компоновщик может подавить его вывод на экран и гарантировать, что вся остальная система нормально работает.
Приложения становятся модулями
Все приложения превращаются в маленькие модули со всеми коммуникациями через шину сообщений. Полностью. Больше никакого доступа к файловой системе. Никакого доступа к аппаратному обеспечению. Всё только в виде сообщений.
Если хотите воспроизвести mp3-файл, то отправляете сообщение play в сервис mp3. Вывод графики на экран через компоновщик. Такое разделение обеспечивает безопасность системы. В терминологии Linux, каждое приложение станет полностью изолировано через разрешения пользователя и chroot, возможно, вплоть до контейнеров Docker или виртуальных машин. Здесь нужно проработать много деталей, но всё решаемо уже сегодня.
Модульные приложения будет гораздо легче разрабатывать. Если база данных — это единственный источник правды, то не нужно делать много работы по копированию данных в память и обратно. В примере с аудиоплеером поле поиска не будет загружать данные и проводить фильтрацию для отображения списка, оно просто опрелеляет запрос. Список затем привязан к этому запросу, а данные появляются автоматически. Если другое приложение добавляет в базу данных песню, которая соответствует поисковому запросу, то UI плеера автоматически обновляется. Это всё делается без каких-либо дополнительных усилий со стороны разработчика. «Живые» запросы с автообновлением сильно облегчают жизнь и они более надёжны.
Переделка приложений
На такой базе мы можем создать всё, что нам нужно. Однако это также означает, что нам придётся переделывать всё с нуля. Высокоуровневые конструкции поверх БД сильно упростят этот процесс. Посмотрим на несколько примеров.
Электронная почта. Если разделить стандартный почтовый клиент на GUI и сетевые модули, которые общаются исключительно через сообщения по шине, то разработка программы станет намного проще. GUI не должен ничего знать о почте Gmail или Yahoo, или как обрабатывать сообщения об ошибках SMTP. Он просто ищет в БД документы с указанным типом "email". Когда GUI хочет отправить сообщение, то назначает ему свойство outgoing=true. Простой модуль составит список всех исходящих почтовых сообщений и отправит их по STMP.
Разделение почтового клиента на компоненты значительно облегчает замену отдельных его частей. Вы можете разработать новый фронтенд за полдня, и не придётся переписывать сетевые модули. Вы можете разработать спам-фильтр вообще без пользовательского интерфейса, он просто сканирует входящие сообщения, обрабатывает их и помечает подозрительные сообщения тегом «спам». Он не знает и не заботится о том, как отображается спам в GUI. Он просто хорошо делает одну вещь.
Почтовые фильтры могут делать и другие интересные вещи. Например, вы отправили своему боту по почте команду play beatles. Крошечный модуль сканирует входящую почту и отправляет другое сообщение модулю mp3 для воспроизведения музыки, а затем помечает письмо как удалённое.
Когда всё превращается в запросы к БД, то вся система становится более гибкой и настраиваемой.
Командная строка
Знаю, я раньше говорил, что мы избавимся от командной строки. Беру свои слова обратно. Мне действительно иногда нравится командная строка как интерфейс, меня беспокоит только её чисто текстовая природа. Вместо выстраивания цепочек CLI-приложений с текстовыми потоками нужно нечто более функциональное, вроде сериализованных потоков объектов (как JSON, но более эффективных). Вот тогда у нас появится настоящая сила.
Рассмотрим следующие задачи:
- Я хочу использовать ноутбук как усиленный микрофон. Я говорю в него, а голос звучит из колонок Bluetooth в другом конце комнаты.
- Как только я публикую твит с хештегом #mom, его копия должна отправляться по электронной почте моей маме.
- Я хочу использовать iPhone в качестве микроскопа, закреплённого на стойке из конструктора «Лего». Он транслирует картинку на ноутбук, где у меня управление — кнопки для записи, паузы, приближения и ретрансляции прямого эфира на YouTube.
- Я хочу сделать простой байесовский фильтр, который реагирует на почтовые сообщения от «Энергосбыта», добавляет тег «коммунальные услуги», делает запись на веб-сайте, извлекает из письма сумму и дату платежа и добавляет запись в мой календарь.
Каждая из этих задач концептуально проста, но только подумайте, сколько кода придётся написать, чтобы реализовать это сегодня. С интерфейсом командной строки на потоках объектов каждый из этих примеров укладывается в скрипт из одной или двух строчек.
Мы можем осуществлять и более сложные операции, вроде «Найти все фотографии, сделанные за последние четыре года в радиусе 80 км от Йосемитского национального парка с рейтингом 3 звезды или выше, изменить их размер на 1000px по длинной стороне, закачать в альбом Flickr под названием «Лучшее из Йосемите» и поставить ссылку на альбом на Facebook. Это можно будет сделать встроенными инструментами, без дополнительного программирования, просто соединив несколько примитивов.
Вообще-то Apple создала подобную систему. Она называется Automator. Вы можете в графическом интерфейсе создавать мощные рабочие процессы. Система никогда не рекламировалась, а сейчас убирают привязку к Applescript, на которой всё работает. Недавно всех сотрудников группы Automator перевели в другие команды. Эх…
Семантические сочетания клавиш по всей системе
Теперь, после переделки мира, чем займёмся?
Сервисы доступны во всей системе. Это означает, что мы можем запустить единый сервис, где пользователь может назначать сочетания клавиш (keybindings). Это также означает, что у сочетаний клавиш появится более глубокий смысл. Вместо указания на функцию конкретной программы они указывают на сообщение о команде. Во всех приложениях, которые работают с документами, могут быть команды «Создать новый документ» или «Сохранить». Сервис сочетаний клавиш будет отвечать за превращение control-S в команду «Сохранить». Я называю это семантическими сочетаниями клавиш (semantic keybindings).
С помощью семантических сочетаний клавиш будет гораздо легче поддерживать альтернативные способы ввода. Скажем, вы разработали причудливую кнопку на Arduino, при нажатии на которую звучит какая-то фраза. Вам не нужно писать специальный код для неё. Просто укажите Arduino отправлять событие о нажатии кнопки, а затем привяжите к этому событию аудиофайл в редакторе сочетаний клавиш. Превратите цифровой горшок в кастомное колёсико прокрутки. UI теперь изменяется как угодно.
В этой области ещё необходимы некоторые исследования, но мне кажется, что семантические сочетания клавиш упростят разработку скринридеров и других программ для облегчения доступа.
Окна
В нашей новой ОС любое окно стыкуется как вкладка к другому окну. Или к боковой панели. Или к чем-нибудь ещё. Независимо от приложения. Здесь большая свобода для экспериментов.
В старой MacOS 8 была разновидность окон-вкладок, по крайней мере, в приложении Finder, которые можно было пристыковать к нижнему краю экрана для быстрого доступа. Ещё одна классная вещь, которую выбросили при переходе на Mac OS X.
На скриншоте внизу пользователь приподымает границу окна, чтобы посмотреть, что там внизу. Это очень круто!
Это был пример из научной статьи «Ametista: мини-набор для изучения новых способов управления окнами», автор Николас Руссель.
Поскольку система полностью контролирует окружение всех приложений, она может принудительно ввести ограничения безопасности и демонстрировать это пользователю. Например, у доверенных приложений могут быть зелёные рамки. У только что скачанного из интернета нового приложения будет красная рамка. У приложения неизвестного происхождения — чёрная рамка, или оно вообще не выводится на экран. Многие виды спуфинга станут невозможными.
Умный копипаст
Когда вы скопировали текст из одного окна и переключились в другое, компьютер знает, что вы что-то скопировали. Он может использовать это знание для осуществления каких-нибудь полезных действий, например, автоматически сдвинуть первое окно в сторону, оставив его в зоне видимости, и отобразить выделенный текст зелёным цветом. Это помогает пользователю сохранить концентрацию на текущей задаче. Когда пользователь вставляет текст в новом окне, можно показать, как зелёный фрагмент перепрыгивает из одного окна в другое.
Но зачем ограничивать себя этим. Сделаем буфер обмена, который вмещает больше одного элемента. У нас гигабайты памяти. Давайте использовать её. Когда я копирую что-то, почему я должен помнить, что конкретно я копировал перед тем, как вставить это в другом окне? Буфер обмена нигде не видим. Исправим это.
Буфер обмена должен отображаться на экране как некая полка, на которой хранятся все скопированные фрагменты. Я могу зайти на три веб-страницы, скопировать их адреса в буфер обмена, а затем вернуться в документ и вставить все три сразу.
Модуль просмотра буфера обмена позволяет прокручивать всю историю буфера. Я могу искать в ней и фильтровать по тегам. Могу «прикрепить» любимые экземпляры для последующего использования.
В классической macOS на самом деле был отличный встроенный инструмент под названием [name], но от него отказались при переходе на OS X. Десятилетия назад у нас было будущее! Вернём его обратно.
Рабочие наборы
И наконец-то мы переходим к тому, что я считаю самым мощным изменением парадигмы в нашей новой Идеальной ОС. В новой системе все приложения представляют собой крошечные изолированные модули, которые знают только то, что говорит им система. Если расценивать БД как единственный источник правды, а сама БД версионированная, а наш оконный менеджер настраивается на любой вкус… то становятся возможными по-настоящему интересные вещи.
Обычно я разделяю личные и рабочие файлы. Это отдельные папки, аккаунты, иногда разные компьютеры. В Идеальной ОС мои файлы могут разделяться средствами самой ОС. У меня может быть один экран с домашней почтой, а другой экран — с рабочей. Это одно и то же приложение, просто инициализированное с разными настройками запросов.
Когда я открываю файл-менеджер на домашнем экране, то он показывает только файлы, предназначенные для домашних проектов. Если я создаю документ на рабочем экране, то он автоматически помечается тегом как строго рабочий документ. Управление всем этим тривиально; просто несколько дополнительных полей в базе данных.
Исследователи из Технологического института Джорджии в реальности описали такую систему в своей научной работе «Giornata: пересмотр метафоры десктопа для содействия высококвалифицированной работе».
Теперь сделаем ещё один шаг. Если всё версионируется, даже настройки GUI и расположение окон (поскольку всё хранится в БД), я могу сохранить состояние экрана. Он будет хранить текущее состояние всех параметров, даже мои сочетания клавиш. Я могу продолжить работу, но всегда будет возможность вернуться к этому состоянию. Или я могу посмотреть старое состояние — и восстановить его на новом экране. Я по сути создал «шаблон», который можно использовать снова и снова, как только я начинаю новый проект. Этот шаблон содержит всё необходимое: настройки почтового клиента, историю чатов, списки дел, код, окна для описания багов или даже соответствующие страницы Github.
Теперь всё состояние компьютера в сущности рассматривается как репозиторий Github, с возможностью форкнуть состояние целой системы. Думаю, это будет просто волшебно. Люди станут обмениваться полезными рабочими пространствами в онлайне, как образами Docker. Можно настраивать свои рабочие процессы, добавлять полезные скрипты к рабочему пространству. Возможности здесь поистине восхитительные.
Ничего из этого не ново
Так что вот так. Мечта. Всё вышеописанное базируется на трёх принципах: всесистемная версионированная база данных в реальном времени, всесистемная шина сообщений в реальном времени и программируемый компоновщик.
Хочу подчеркнуть, что абсолютно ничего из того, о чём я рассказывал, не является новым. Я ничего не придумал. Всем этим идеям годы или десятилетия. Файловые базы данных впервые появились в BeOS. Единый механизм межпроцессных взаимодействий появился в Plan 9. Настройка окружения из редактируемого документа реализована в Oberon. И конечно ещё огромное множество научных статей с результатами исследований.
Почему у нас этого нет?
Здесь ничего нового. И у нас до сих пор этого нет? Почему так?
Подозреваю, что главная причина просто в сложности разработки успешной операционной системы. Гораздо удобнее расширять существующую систему, чем создать нечто новое; но расширение также означает, что вы ограничены выбором, сделанным в прошлом.
Можем ли мы в реальности создать Идеальную ОС? Подозреваю, что нет. Никто не сделал это до сих пор, потому что, если честно, здесь не заработаешь деньги. А без денег просто не найдёшь ресурсы для разработки.
Однако если кто-то всё-таки поставит цель создать такую ОС или хотя бы рабочий прототип, то я бы начал с конкретного ограниченного набора аппаратного обеспечения с существующими драйверами устройств. Недостаточная поддержка драйверов всегда была ахиллесовой пятой десктопного Linux. Например, Raspberry Pi 3 будет отличным вариантом.
Так что мой вопрос к вам: как вы думаете, идея стоит усилий на её реализацию, хотя бы для создания рабочего прототипа? Вы бы поучаствовали в таком проекте? Какая часть функциональности должна работать, чтобы вы согласились взять систему для тестирования? И конечно, как нам её назвать?
Если вам интересно обсуждение будущего десктопного UX, подписывайтесь на нашу новую группу Ideal OS Design.
Автор: m1rko
