«Современные» десктопные ОС раздуты
Возьмём 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.
Комментарии (109)
izzholtik
05.09.2017 18:50+7> Raspberry Pi 3 будет отличным вариантом.
Это тот самый одноплатник, у которого драйвер OpenGL брикает систему, если включить поворот экрана на 90°? Отличный выбор стартовой точки.
nerudo
05.09.2017 19:08+22Первую половину текста автор плачется что системы стали слишком сложные и многослойные, вторую — призывает добавить еще слоев и сложности…
Nikobraz
06.09.2017 08:23+2А мне кажется он предлагает не наращивать слои, а интегрировать функционал в нижние слои.
viklequick
06.09.2017 20:26+1Даже лучше. Он сначала плачется что они были слишком сложными, а теперь стали менее сложными (пример про несуществующий в природе X Windows это наглядно показывает). Затем они стали проще, и теперь их снова пора усложнить. ;-)
Ну, как вариант.
bromzh
05.09.2017 19:38+5всесистемная шина сообщений в реальном времени
D-Bus. Ну да, не совсем всесистемная, но тем не менее, если разработчик озаботился о его поддержки в своём приложении, им можно будет управлять.
Если разделить стандартный почтовый клиент на GUI и сетевые модули, которые общаются исключительно через сообщения по шине, то разработка программы станет намного проще.
В юниксах давно практикуется с разной степенью успеха
всесистемная версионированная база данных в реальном времени
В macos файлы вполне нормально индексируются, можно искать по всей системе по содержимому. Старые версии файлов можно откопать в TimeMachine
Сервисы доступны во всей системе. Это означает, что мы можем запустить единый сервис, где пользователь может назначать сочетания клавиш (keybindings). Это также означает, что у сочетаний клавиш появится более глубокий смысл.
И снова macos. С помощью автоматора и редактора скриптов можно создать сервис, можно управлять любым GUI-шным приложением, и всё это можно привязать к любому сочетанию клавиш. Более того, в любой программе любую команду из его меню можно привязать к хоткею (если даже в самой программе такого биндинга не предусмотрено)
Ещё там можно, например, замутить свою голосовую команду и др
evnuh
05.09.2017 21:19+1Хочу подчеркнуть, что абсолютно ничего из того, о чём я рассказывал, не является новым.
Статья о том, что всё это уже есть, но по отдельности. Автор призывает переписать всё с нуля, правильно скомпоновав уже реализованные идеи.
Гораздо удобнее расширять существующую систему, чем создать нечто новое; но расширение также означает, что вы ограничены выбором, сделанным в прошлом.
В этом и тезис статьи.
tronix286
05.09.2017 19:51+1Автору (не переводчику) — не нравится — не ешь. Возьми да напиши свою с нуля с картами и поэтессами. Только, боюсь, один он все равно не напишет, а даже если с командой, то к моменту когда у него по экрану начнет мышка бегать, придется весь код выбросить в дев нулл, потому что «обрастет костылями и слоями за давностью» и начать заного.
NeoCode
06.09.2017 09:07Значит здесь тоже есть некий недостаток — избыточный порог сложности при написании ОС. Может быть и имеет смысл начать с его устранения. Продумать и создать новый язык программирования вместо Си, максимально поддерживающий модульную композицию и изоляцию; далее написать аспектно-ориентированные модули, образующие ядро ОС, драйверы периферийных устройств — таким образом, чтобы эти модули были предельно простыми и не связанными друг с другом, а умный компилятор интегрировал бы их в единое быстрое ядро.
Аналогично — с пользовательским слоем ОС. Там тоже нужна фундаментальная декомпозиция сущностей, формирование предельно простых абстракций и их аспектное связывание на уровне компиляции, а не путем порождения новых и новых рантайм-слоев.
Это все большая работа. И для этого действительно нужны новые идеи и новые инструменты.DrZlodberg
06.09.2017 09:56+1Вроде как в Plan-9 и Inferno это и сделали. Не знаю, как там с производительностью, однако структурно оно выглядит достаточно интересно. Правда на данный момент они существуют только в виде надстроек над обычной ОС.
MacIn
08.09.2017 13:57драйверы периферийных устройств — таким образом, чтобы эти модули были предельно простыми и не связанными друг с другом, а умный компилятор интегрировал бы их в единое быстрое ядро.
Ведь именно на таких идеях базировались, емнип, GNU и Minix. Только оказалось, что отладить независимые модули сложнее.
DrZlodberg
05.09.2017 20:13+3Нативные приложения слишком тяжеловесны, их долго разрабатывать и они живут в бункерах
Это проблема разработчиков, а не системы. Хрень можно писать на чём угодно и в каком угодно окружении. Как и нормальный софт. При чём тут ОС?
Не только «файлы» существуют более чем в одном месте и становятся легко доступны для поиска, но гарантированное наличие высокопроизводительной БД намного облегчает создание приложений.
Есть плюсы, есть минусы. Пихать в базу файлы по несколько терабайт — бессмысленный перебор. И мир не ограничивается кучкой легко теггируемых файлов. По большей части это тысячи разных заточенных под конкретные задачи файлов. Вопрос производительности бд так-же не столь прост. Сколько ресурсов системы мы готовы отдать на работу этой бд?
Шина сообщений станет единым способом межпроцессных взаимодействий. Мы избавляемся от сокетов, файлов, каналов, ioctrl, общей памяти, семафоров и всего остального
Бред. «Всё остальное» появилось не на пустом месте и избавление от него только добавит геморроя разработчикам. Ах да, мы же выкинули нативные программы и перешли на скриптовые обёртки…
Ниже показана схема Wayland — компоновщика, который когда-нибудь станет работать по умолчанию в Linux
И если я правильно понял — игровые движки и всё, требовательное к графике в него не входит.
Завершив вывод графики и при необходимости обновления они просто отправляют сообщения: пожалуйста, перерисуй меня.
Эмм… А сейчас не так? И что делать системе, если это ей понадобилось, чтобы приложение себя перерисовало? Или храним в текстурах все окна пока приложение работает (ну да, сейчас вроде так и делают на самом деле. Но как быть если нам нужна вся видеопамять под более насущные задачи?)
Разделение почтового клиента на компоненты значительно облегчает замену отдельных его частей.
Упомянутые в прошлой статье OLE, COM и прочие — не? К сожалению сейчас как раз всё скатывается к сваливанию в одно приложение всего-всего.
В нашей новой ОС любое окно стыкуется как вкладка к другому окну. Или к боковой панели. Или к чем-нибудь ещё. Независимо от приложения.
В вынде это можно легко сделать и так (правда второе приложение может немного упасть при закрытии родительского окна). Однако в чём смысл? Некоторые программы наоборот, ушли в сторону «один документ — одно окно». А к панелям и чему-нибудь ещё в современных ос они и так умеют цепляться вроде как.
На скриншоте внизу пользователь приподымает границу окна, чтобы посмотреть, что там внизу. Это очень круто!
Это при желании реализуется вообще элементарно. Была для вынды прога, которая по сочетанию клавиш сворачивала/разворачивала окно в заголовок. Функция на поиграться.
У приложения неизвестного происхождения — чёрная рамка, или оно вообще не выводится на экран.
Т.е. юзер даже не узнает, что у него работает какая-то подозрительная программа? Логично, зачем его пугать лишний раз.
Но зачем ограничивать себя этим. Сделаем буфер обмена, который вмещает больше одного элемента. У нас гигабайты памяти.
Вот с фразы «у нас гигабайты памяти» обычно начинается быстрое её исчезновение. А буфер с кучей кусков делали программно много раз. Вот честно, часто ли оно требуется? Ставил себе такую прогу ради интереса. Как поставил, так и забыл. Максимум эта полка превратится в табы браузера, когда вместо сохранения инфы по делу мы используем корзину для хранения временных (год-другой) документов.
Обычно я разделяю личные и рабочие файлы. Это отдельные папки, аккаунты, иногда разные компьютеры. В Идеальной ОС мои файлы могут разделяться средствами самой ОС. У меня может быть один экран с домашней почтой, а другой экран — с рабочей. Это одно и то же приложение, просто инициализированное с разными настройками запросов.
Многие программы (браузеры, почты..) позволяют указывать профиль, с которым работаешь, и в котором все настройки. Можно создать несколько юзеров (В ллинухе) и запускать программы от них. Соответственно по умолчанию они имеют окружение конкретного пользователя и имеют индивидуальные ограничения и права на уровне системы.
Почему у нас этого нет?
Потому, что это не нужно? ХромОС (и где она сейчас?) которая основана на андроиде. В котором как раз всё это и стараются реализовать. Вот только не все хотят превращать компьютер в телефон.
Am0ralist
05.09.2017 22:30Есть плюсы, есть минусы. Пихать в базу файлы по несколько терабайт — бессмысленный перебор. И мир не ограничивается кучкой легко теггируемых файлов. По большей части это тысячи разных заточенных под конкретные задачи файлов. Вопрос производительности бд так-же не столь прост. Сколько ресурсов системы мы готовы отдать на работу этой бд?
в винде уже давно работает служба индексирования дисков, ничего нового.
Не имеет смысла теггировать служебные файлы приложений. Для любых файлов с пользовательскими данными смысл теггирования появляется автоматом. Просто иногда для этого хватает пары слов и иерархической структуры хранения, а иногда иерархическая система ничем не поможет, а требуется экран текста.
sumanai
05.09.2017 23:11+1Можно создать несколько юзеров (В ллинухе) и запускать программы от них.
Windows тоже позволяет это делать.
Nikobraz
06.09.2017 07:52А разве файловая система не есть БД?
DrZlodberg
06.09.2017 09:51Формально — очень примитивная и с ручным поиском и индексацией. Всё-таки под БД обычно подразумевают более продвинутые решения.
inv2004
05.09.2017 20:39+3Маниловщина.
В комментариях большую часть описали: «всё очень сложно… а я тут вот так придумал (ещё сложнее).
Рассмотрим следующие задачи:
Я хочу использовать ноутбук как усиленный микрофон. Я говорю в него, а голос звучит из колонок Bluetooth в другом конце комнаты.
Отдельное и универсальное решение точно есть, но зачем это стандартным средством в OS?
Как только я публикую твит с хештегом #mom, его копия должна отправляться по электронной почте моей маме.
В чём вообще проблема и причём тут OS?
Я хочу использовать iPhone в качестве микроскопа, закреплённого на стойке из конструктора «Лего». Он транслирует картинку на ноутбук, где у меня управление — кнопки для записи, паузы, приближения и ретрансляции прямого эфира на YouTube.
Таких приложений — десятки, зачем это в OS?
Я хочу сделать простой байесовский фильтр, который реагирует на почтовые сообщения от «Энергосбыта», добавляет тег «коммунальные услуги», делает запись на веб-сайте, извлекает из письма сумму и дату платежа и добавляет запись в мой календарь.
Опять же — тут всё в руках, причём тут всё всего несколько строчек.
int33h
05.09.2017 22:10Я был бы рад поучаствовать в этом, но сначала хочу выразить свою позицию по этому поводу…
Во-первых, с чего начались почти все(может вообще все) современные ОС? Правильным ответом на это будет Unix(или я не прав?). С чего начинался Unix? С языка программирования C. То есть все современное ПО держится сейчас по сути на одном языке(даже Python в него транслируется). Но этот язык был написан 40 с лишком лет назад, и, следовательно, безбожно устарел под требования современных задач(ведь сейчас 3 идиом, включая кроссплатформенность уже не хватает; им параллелизм подавай)… Поэтому, по-моему сугубо личному мнению, прежде чем писать ОС нужно написать компилятор языка программирования, который будет лучше С под современные задачи, при этом полностью транслирующийся в код ассемблера, и еще поддерживающий ассемблерные вставки(вспомните молодость и TurboC30, хотя я и не застал те времена, но предпочту работу с ним, чем с современной IDE по типу codeblocks)
Во-вторых, написание OC требует времени и денег, если ты, конечно, не работаешь на энтузиазме. Но уже довольно давно появился механизм «Pay what you want», который, возможно, сделает, в теории, твой энтузиазм поощряемым и будет стимулировать тебя на написание хорошего кода.(Но как известно это не очень распространенный метод, да и современный мир погряз в получении «выгоды», поэтому время и затраты на написание продукта стараются по максимуму сократить, что приводит к некачественному(небыстрому) коду)
В-третьих, насколько я понял эмпирическим путем, твоя ОС сможет «просуществовать» до новой ветки устаревающих технологий не более 20 лет, при умном проектрировании, поэтому ее разработка должна быть достаточно быстрой, что повлечет работу в огромной команде людей, что вновь приводит нас к предыдущим пунктам, но также создаст кучу ошибок совмещения, что, в свою очередь, будет влиять на доверие пользователей к ОС из-за проблем безопасности...(может этот пункт и не возникнет, если остановиться на системе уровня MS-Dos c небольшими дополнениями)
В-общем(еще я мог что-нибудь забыть, но это уже потом), я готов помочь, но мне важно выполнение первого пункта(над которым я работаю, но пока не хватает знаний в реализации компиляторов и потребностей современного рынка).int33h
05.09.2017 22:16Ах да, совсем забыл. Еще было бы полезно сделать общую систему и для ПК, и для смартфонов.
geher
06.09.2017 00:00+2Уже было и есть. Называется линукс.
На смартфонах это представлено вариантами Maemo, Meego, Mer, Sailfish. Особенно Maemo была хороша.
Если же речь об идентичном интерфейсе, то в морг. Работа на экранах разных размеров с разными устройствами ввода порождает очень разные требования к интерфейсу…
Мелкомягкие уже попытались продвинуть идею унифицированного рабочего пространства на основе общего интерфейса для всех устройств. Получилось ожидаемо убого.int33h
06.09.2017 23:40Я готов поверить, что линукс 90-х был «той самой» системой, но сейчас я больше даже поверю винде… Половина пакетов написана на python, потребление памяти выше, никаких пояснений.
Разве можно назвать сейчас этого бесповоротного монстра хорошей системой?geher
07.09.2017 09:13+2Линукс просто достиг некоторого баланса между обратной совместимостью и наличием более-менее эффективных современных инструментов. Отсюда и монстрообразность и неповоротливость.
При этом линукс сохранил возможность выбирать альтернативы.
Например, монстрообразный DE вроде гнома или KDE легко заменяется на что-то более легкое вроде LXDE.
Насчет питона не совсем соглашусь. Питоньи программы в репозитариях широко представлены, это да. Но я не припомню, чтобы для чего-то с высокими требованиями к поизводительности не имелось не скриптового варианта.
А аппарат на Maemo5 (легендарный Nokia N900) при весьма ограниченном железе шустрил лучше аппаратов на других ОС с более серьезным железом.
Причем там крутился полноценный линукс с иксами и всем остальным. И это были уже давно не 90-е.
С виндой же все обстоит намного хуже.
Монстрообразность такая же, как у линукса по тем же причинам (достигнутый баланс между обратной совместимостью и новшествами). Но все это осложнено полным отсутствием легковесных альтернатив (в системе, естественно, не на уровне пользовательских приложений). А пользовательские приложения все чаще писаны на .NET, что во многих случаях никак не способствует повышенной производительности.
Пока что актуальный линукс способен эффективно работать на существенно более слабых машинах, чем актуальная винда. Во многом, кстати, благодаря наличию легковесных альтернативных версий реализации графического интерфейса.
geher
06.09.2017 00:09+1Язык программирования не определяет в ОС на самом деле почти ничего. Он может в лучшем случае облегчить разработку и сделать работу ОС эффективнее (за счет более эффективной компиляции в команды процессора). Архитектура ОС же будет определяться исключительно логикой написанной программы. Если мы опишем хоть на C, хоть на неведомом языке архитектуру существующей ОС, то она вне зависимости от выбранного языка останется архитектурой существующей ОС.
maxpsyhos
06.09.2017 10:47+2Да ладно язык программирования C. Буквы!!! Исходные коды OC написаны с помощью букв, а их придумали ещё чёрт знает когда, они давно устарели. Поэтому прежде чем писать новый язык программирования нужно придумать новые буквы.
Ded_Banzai
06.09.2017 13:44+1Это старые и ненужные пережитки древности. Зачем буквы? Они нас ограничивают. Голый поток мыслеобразов!
MacIn
08.09.2017 14:02Во-первых, с чего начались почти все(может вообще все) современные ОС? Правильным ответом на это будет Unix(или я не прав?). С чего начинался Unix? С языка программирования C
Windows семейства NT скорее базируется на идеях VMS и других DECовских, вроде RSX.
algotrader2013
05.09.2017 23:43-1Если абстрагироваться от вопросов безопасности, то все написанное в статье не особо то и приносит ценности.
Касательно единой БД, никто не мешает поставлять с приложением свою базку данных (тот же SQLite), оптимизированную именно под задачи приложения. Где-то нужна документарная, где-то SQL, а всем хорошо (да еще и на десятилетия вперед) не сделаешь. Да, лишние мегабайты, ноу нас ведь гигабайты памяти
Касательно единой шины, сейчас не особо то и надо межпроцессное взаимодействие. Для редких задач есть куча средств и так. В основном запросы к серверу надо (либо сокет), вот и все.
Он просто ищет в БД документы с указанным типом «email». Когда GUI хочет отправить сообщение, то назначает ему свойство outgoing=true. Простой модуль составит список всех исходящих почтовых сообщений и отправит их по STMP.
Вспоминаю, как дважды в жизни работал с smtp программно (раз на C#, раз на питоне), за 5 минут на стековерфлоу находилась ссылка на бесплатные опенсорс либы, и писалось приложение в 10 строк кода. В чем проблема? Лишние библиотеки на n килобайт?
geekmetwice
06.09.2017 00:01+1Я согласен почти полностью с автором, но есть слишком весомые «против», чтобы реально сесть и начать писать:
1. Legacy. Тяжёлое, тухлое, ненавистное, но оно везде — я про венду и всё, что с ней связано, от курсов для яслей до сложных программных комплексов. Есть десятки уже написанных ОС с интересными концепциями — почему они не победили? Legacy. Самый яйцеголовый гений бессилен перед секретаршей, у которой «икспишечка» и «флэшечка» — твои «файлы в базе» ничего не стoят, если их нельзя записать на флешку в формате ворда-95 (уверен, до сих пор есть такие юзеры). Поэтому как бы ты ни рвался в своём идеальном мире воплотить лучшие идеи человечества, все они махом разбиваются о тысячи хомячковых систем и привычек.
Отступление: давно облизываюсь на QNX. Прекрасная система, микроядро,
сеть, GUI… но опаршивились ребята за своей жадностью — вместо «своё и качественно»,
купились на FOSS — «дёшево и сердито», причём больше сердито, чем дёшево. Вместо нормальной IDE (которая у них была!) — безобразный Эклипс. Вместо того, чтобы взять какой-нибудь D (как прикладной язык) — похабная «сишечка» от gcc. Писать на «этом», с позволения сказать, «инструменте» нет ни малейшего желания. Вот так эти клоуны и сидят как слива в своём embedded рынке последние 20 лет. А бизнес, который не развивается — мёртвый бизнес. Ждём, когда им прилетит граблями «банкрот» и они наконец очухаются.
2. ОС — это хоть и адская затея в плане затрат, но всё же преодолимая. Что делать с драйверами? Что ты скажешь тому же HP — «смотрите, мы сваяли лучшую ОСь на свете»? Они и линукс-то поддерживают через пень-колоду, зачем миру коммерции тратить усилия на ОСь, которая не занимает даже тысячной доли процента? Хуже того — мрази из того же MS могут спокойно подкупить (как они это всегда и делали) производителей на «windows only» драйвера и тогда ты вообще не увидишь кода! И это наша проблема, не их.
3. Патенты. Из России с её «мы им покажем кузькину мать!» всё выглядит легко как у подростка, читающего «кунфу». Но попробуй напиши хоть что-то, напоминающее окна/двери/скруглённые углы, тут же получишь уведомление из самой крутой адвокатской конторы. Это нам смешно видеть «патенты на ковыряние в носу» — там это тупой, но действенный метод держать монополию. Или плати. Причём непонятно кому и непонятно за что.
4. Форматы файлов придуманы не от глупости великой, а наживы ради. Поэтому-то и смешит этот автор-идеалист, который тут вышел весь в белом и предлагает компаниям «давайте житьдружночестно!» — кому это надо? Мелкософт потому и монополист, что годами сидел на своих закрытых форматах! Открытый формат — убийца посредственностей, они просто не выживут. Поэтому никто не будет использовать «единые файлы с тегами» — вот что надо рассматривать, прежде чем публиковать мечтания.
5. Я бы не торопился с идеями «файлы как база» (ввиду бессмысленности) и единой шины. Шину можно склепать за неделю, как ею пользоваться?? Ну послал ты в шину «save» — и чо? :) «Всем сохраниться»? Вот-вот, тут же вылезает проблема адресации, переполнения самой шины, то, сё… непродуманная идея мечтателя. Надо ещё очень много продумать, прежде чем бросаться в бой — концепции закладываются в фундамент, а после первого этажа фундамент не меняют, извини.
В целом, с автором согласен — мир ИТ, несмотря на суету, изрядно протух и некому (и нечем) пнуть всяких микрософтов и гуглов, чтобы шевелили булками. И конкурирующую ОСь тоже неплохо бы создать. Но её перспективы… они не просто туманны — они уже обросли венками. Самому жалко, но это мёртвый проект. Подобные вещи должна двигать средняя компания с хорошим запасом финансов, которая хотя бы выкатит юзабельное ядро и драйвера, а уж программы потихоньку допишутся. И конечно, никакого тухлого POSIX.
geher
06.09.2017 00:19+9Почему я не могу иметь файл в двух местах одновременно в своей файловой системе?
Почему не можете?
Это придумали в UNIX очень давно. И до сих пор оно так. И даже в винде оно вроде сделано (естественно не в FAT).
И механизм называется "ссылки".
Есть символические, в которых просто написано, где реально расположен файл в иерархии подкаталогов.
А есть "жесткие", которые реально размещают один и тот же файл в нескольких подкаталогах.
bro-dev
06.09.2017 03:40Замедление выпуска новых осей как раз следствие того что спрос удовлетворен уже. Меня всё устраивало еще в хрюше, я переходил на 7 и 10, просто чтоб не отставать, и игры начали уже некоторые не запускаться на XP.
godlin
06.09.2017 05:06+3Я так понимаю, автор видит идеальность в максимальном упрощении протоколов взаимодействия приложений между собой и с ОС, а так же в реализации в рамках ОС большого количества универсальных модулей, предназначенных для решения стандартных задач пользователя. И третья идея в том, чтобы приложения тоже были более модульными и более зависимыми от ОС. В принципе, в этом есть рациональное зерно.
И мне, кстати, кажется, что база данных, встроенная прямо в ОС — это очень крутая тема.
Я даже больше скажу: у меня есть предположение, что хранение данных в виде файлов, возможно, — не лучшая парадигма. И хранение данных в виде нереляционной БД было бы куда как интереснее и удобнее.
Ведь что такое обычный файл? Это имя-размер-несколько простых атрибутов и всё. Чтобы корректно прочитать данные из файла, вам надо сначала разобраться (или знать заранее), а что, собсно, за данные в нём находятся, потом, зная его структуру, распарсить, выделить необходимые данные и т.д.
А теперь представьте, что файл хранится сразу как объект в NoSQL-базе. Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы. А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования. Опять же на уровне самой БД можно было бы сделать, чтобы она сама следила, чтобы дублирующие файлы удалялись, оставаясь физически в одном экземпляре.
Допустим, есть у меня сайт с большим количеством статических html-страниц, у которых у всех одинаковые шапки и подвалы. В обычном режиме я просто буду хранить в каждом файле свои копии шапок и подвалов, но имея под рукой вышеописанную систему, я мог бы выделить их в два отдельных файла и подключить к другим файлам через ссылки. А затем я мог бы и эти html-страницы отдавать не собранными, а прямо в виде подграфа объектов, выдранного из БД, и браузер бы уже сам собирал эти страницы.
Конечно, здесь у нас вылазят сразу все проблемы, связанные с синхронностью, дэдлоками и общим усложнением системы хранения, но это же решаемые вещи — все базы данных так или иначе их решают.hungry_ewok
06.09.2017 11:17+1>А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования.
Еще один новый способ послать клиенту вместо файла ярлык на него? О да, его так не хватало!godlin
06.09.2017 14:36Не понял, при чем тут «ярлык» вообще. Высылаться должны данные, а ссылки живут только в рамках передаваемого или хранимого блока. Т.е. просто необходимо подобные связные файлы передавать единым блоком данных, а не разрозненными частями. Т.е. такие ссылки имеют смысл только в рамках БД или пересылаемого дампа.
hungry_ewok
06.09.2017 18:07+1> Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы. А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой
Если «мы можем иметь доступ» — то такая нетривиальная вещь обязательно приведет к ситуациям когда пользователи будут передавать не то что надо.
А если всё это работает под капотом и нам наружу не показывается — это уже есть, зовется дедупликацией, предъявляет требования к оборудованию и производительности, и рядовому пользователю десктопной системы в общем не сдалось.
И вот так везде в этих хотелках.
lair
06.09.2017 12:03А теперь представьте, что файл хранится сразу как объект в NoSQL-базе. Т.е. вы можете иметь доступ к его структуре средствами ОС безо всякой дополнительной работы
Один формат сериализации to rule them all? Спасибо, нет.
А отсюда можно, например, делать такие нетривиальные вещи, как ссылка из одного файла на другой, что позволило бы хранить повторяющийся в разных объектах-файлах кусок данных в одном месте вместо дублирования.
Циклические ссылки в масштабе все системы?
Опять же на уровне самой БД можно было бы сделать, чтобы она сама следила, чтобы дублирующие файлы удалялись, оставаясь физически в одном экземпляре.
Встроенная дедупликация уже давно есть в ряде файловых систем. Как обычно, ценой производительности.
godlin
06.09.2017 14:58+1Один формат сериализации to rule them all? Спасибо, нет.
Во-первых. У вас один формат хранения информации о файле в файловой системе.
Во-вторых, с точки зрения приложения взаимодействие с файлом не требует его «сериализации» и «десериализации» — это всё будет делать ОС, а вам надо только запросить/сохранить нужные данные в объекте. Как именно будут сериализованны эти данные и как они будут храниться в БД — это отдельный вообще вопрос.
В-третьих, хранить предлагается стандартную информацию + ту, которую захочет программист. Скажем, письмо можно хранить сразу в виде полей «тип файла», «кому», «от кого», «тема», ", «текст» (и т.д.), а сериализацию-десериализацию при его пересылке оставить на ответственность ОС. Опять же никто не мешает сделать свой сериализатор для произвольного объекта.
Циклические ссылки в масштабе все системы?
В базах данных эти вещи решаются. А в сборщиках мусора вообще в реальном времени решаются. И живут как-то)
Встроенная дедупликация уже давно есть в ряде файловых систем. Как обычно, ценой производительности.
Ясное дело, что усложнение систем обычно приводит к уменьшению производительности, но во-первых, мы же говорим о десктопе, который как правило имеет периодический график использования «то пусто, то густо». Операционные системы и так многие вещи стараются делать, когда система не нагружена — таким же образом можно производить и дедупликацию, поскольку это вообще говоря такая вещь, которая на целостность системы вообще не должна влиять. Т.е. система в фоне ищет дубликаты, лишние — удаляет. Если какие-то дубликаты сохранились, то ничего страшного — пусть подождут своей очереди. Хотя… я понял, на производительность это может повлиять, когда нам надо изменить данные в файле, на который уже есть несколько ссылок. Тогда с него надо сначала сделать копию, и её уже править… Теоретически такую проблему можно решить разбиением файла на небольшие чанки (по размеру кластера, например) и копировать только кластер, например… В общем, да, это вопрос для обдумывания. :)
lair
06.09.2017 15:09Во-первых. У вас один формат хранения информации о файле в файловой системе.
И что? Это не моя прикладная информация.
Во-вторых, с точки зрения приложения взаимодействие с файлом не требует его «сериализации» и «десериализации» — это всё будет делать ОС, а вам надо только запросить/сохранить нужные данные в объекте. Как именно будут сериализованны эти данные и как они будут храниться в БД — это отдельный вообще вопрос.
Ну так это и плохо: я как программист теряю контроль за тем, что меня волнует (а меня волнует эффективность хранения "объектов" — это если у меня вообще объекты).
В-третьих, хранить предлагается стандартную информацию + ту, которую захочет программист.
Вот на месте "ту, которую захочет программист" и проблема.
Опять же никто не мешает сделать свой сериализатор для произвольного объекта.
… системный?
В базах данных эти вещи решаются.
В реляционных не решаются. В объектных и графовых — возможно, но сколько это стоит?
А в сборщиках мусора вообще в реальном времени решаются.
В сборщиках мусора немного другие задачи решаются.
Ясное дело, что усложнение систем обычно приводит к уменьшению производительности, но во-первых, мы же говорим о десктопе, который как правило имеет периодический график использования «то пусто, то густо».
"То густо, то выключено", вы хотели сказать?
Хотя… я понял, на производительность это может повлиять, когда нам надо изменить данные в файле, на который уже есть несколько ссылок. Тогда с него надо сначала сделать копию, и её уже править… Теоретически такую проблему можно решить разбиением файла на небольшие чанки (по размеру кластера, например) и копировать только кластер, например… В общем, да, это вопрос для обдумывания.
Это типичный copy-on-write, давно реализованный. Просто дорого.
godlin
06.09.2017 16:24И что? Это не моя прикладная информация.
Вы это информацией пользуетесь, значит это и ваша информация тоже.
Опять же, никто не мешает вам точно так же работать со своими форматами, а в системной базе хранить только базовые атрибуты. Т.е. никто ж не мешает хранить произвольные данные в блоке данных. У вас просто появляется возможность хранить части файла сразу в виде разных полей объекта базы данных, а не хотите — можете всё единым бинарным блоком засунуть в единственное кастомное поле, и тогда это будет практически ничем не отличаться от обычного файла.
Ну так это и плохо: я как программист теряю контроль за тем, что меня волнует (а меня волнует эффективность хранения «объектов» — это если у меня вообще объекты).
См. предыдущий пункт. Программист волен выбрать, что ему важнее. Эффективность сжатия данных? Храни блобы. Удобство доступа? Храни объекты. В чем проблема-то? Мы не теряем то, что имели, а только добавляем новые возможности.
Вот на месте «ту, которую захочет программист» и проблема.
Не понимаю, где проблема. Программист в любом случае хранит в файле ту информацию, которую считает нужным, а проблема обмена такими файлами решается (по жизни) стандартизацией и спецификацией формата.
В реляционных не решаются. В объектных и графовых — возможно, но сколько это стоит?
Я, вроде, изначально говорил о нереляционных. Насчёт «сколько стоит» — не знаю, надо смотреть уже в алгоритмы. В некоторых случаях нереляционные БД эффективнее реляционных. Я не углублялся в рассчёты — мне показалась интересной сама идея :)
В сборщиках мусора немного другие задачи решаются.
В сборщиках мусора в том числе решаются проблемы циклических ссылок.
«То густо, то выключено», вы хотели сказать?
Не знаю, как у вас, но лично у меня компьютер выключается максимум раз в два-три месяца, когда я больше, чем на день, куда-то уезжаю :)
Это типичный copy-on-write, давно реализованный. Просто дорого.
Ну, да, мы тут всё время говорим о том, что всё это уже где-то реализовано, но не собрано в одну кучу. И, собсно, с чего вообще начался разговор — с того, что современные ОС слишком неэффективны и неудобны, т.е. если бы мы смогли при сохранении той же эффективности на несколько порядков увеличить удобство, то потомки нам только спасибо сказали бы :) Опять же, мы ведем речь конкретно о десктопах, а не о высоконагруженных серверах, а на десктопах вполне, я считаю, допустимо пожертвовать частью производительности в пользу удобства.
lair
06.09.2017 16:30Вы это информацией пользуетесь, значит это и ваша информация тоже.
Нет — я не несу за нее ответственности. Это очень важное разделение.
Опять же, никто не мешает вам точно так же работать со своими форматами, а в системной базе хранить только базовые атрибуты.
Это ничем не будет отличаться от того, что есть сейчас — и, как следствие, не будет униформности.
В чем проблема-то?
В отсутствии униформности. Без униформности вся эта идея с "БД вместо ФС" не имеет смысла.
Программист в любом случае хранит в файле ту информацию, которую считает нужным, а проблема обмена такими файлами решается (по жизни) стандартизацией и спецификацией формата.
Правильнее было бы сказать "не решается".
Насчёт «сколько стоит» — не знаю, надо смотреть уже в алгоритмы.
Так может надо сначала посмотреть, чтобы понять, осмысленно ли это предлагать?
В сборщиках мусора в том числе решаются проблемы циклических ссылок.
Между "у нас между объектами циклическая ссылка, их можно удалить" и "у нас между объектами циклическая ссылка, их надо вернуть… гм, как?" есть фундаментальная разница.
Не знаю, как у вас, но лично у меня компьютер выключается максимум раз в два-три месяца, когда я больше, чем на день, куда-то уезжаю
А у меня все десктопы (рабочие станции, ноутбук) включаются только тогда, когда мне от них что-то надо — например, поработать. Для постоянной работы есть сервер.
Опять же, мы ведем речь конкретно о десктопах, а не о высоконагруженных серверах, а на десктопах вполне, я считаю, допустимо пожертвовать частью производительности в пользу удобства.
Вот только не "удобства", а "экономии места". И диски сейчас дешевле, чем мое время, поэтому спасибо, нет.
godlin
06.09.2017 19:38Это ничем не будет отличаться от того, что есть сейчас — и, как следствие, не будет униформности.
Униформность — это вопрос стандартов/спецификаций. Так же, как есть спецификация структуры jpg или png, и вообще любого файла, с которым вы работаете, кроме, может быть, чистых текстовых файлов. Ну, или я не понимаю, что Вы пытаетесь сказать.
Так может надо сначала посмотреть, чтобы понять, осмысленно ли это предлагать?
Ну, это Вы, батенька, совсем расшалились. Во-первых, я сюда, в комменты к довольно абстрактной статье на Хабре, не устраиваться к вам на работу пришел, и я никому не обязан «показывать результат» и что-то там просчитывать. Я зашёл, увидел зацепившую меня идею и немного высказался по этому поводу. Во-вторых, может надо сначала посмотреть, чтобы понять, осмысленно ли это отвергать? Как-то Вы уж больно агрессивно ведёте себя, вам не кажется?
Между «у нас между объектами циклическая ссылка, их можно удалить» и «у нас между объектами циклическая ссылка, их надо вернуть… гм, как?» есть фундаментальная разница.
И в чем же эта фундаментальность, простите?
А у меня все десктопы (рабочие станции, ноутбук) включаются только тогда, когда мне от них что-то надо — например, поработать. Для постоянной работы есть сервер.
Ну, видите, у всех по-разному. А Вы, когда работаете, прям нагружаете свой компьютер по полной, гоняете все время бэнчмарки, игры и майните биткоин? Или, скажем, есть время, когда Вы просто сидите стрОчите комментарии в Хабр, а компьютер в это время по большей части отдыхает? ;)
Вот только не «удобства», а «экономии места». И диски сейчас дешевле, чем мое время, поэтому спасибо, нет.
Да нет же, дедупликация — это только как потенциальная возможность, в целом-то речь идёт не о дедупликации, а об устройстве ФС в виде БД. Ну, и, кроме того, дедупликация — это не только экономия места, но так же и экономия ресурса (количества чтений) диска (один раз объект закэшировали — сто раз отдаём), и экономия сетевого трафика (отдаём повторяющийся кусок один раз, а не десять). Так что, тут главный вопрос в сценарии использования. Например, при большом количестве записи по отношению к количеству чтений, пожалуй, дедупликация вредна, но если у тебя 99% данных (как у меня на десктопе, например), никогда не меняется, то это вполне может оказаться выигрышной стратегией.
поэтому спасибо, нет.
Да никто ж Вас не заставляет)) Как говорится, голосуйте ногами. Не нравится идея и не хочется с ней разбираться — проходите мимо — пусть разбираются те, кому хочется. У нас тут простой «кухонный» разговор на уровне идей, а Вы каких-то цифр уже требуете и доказательств. Не бывает доказательств без эксперимента или по крайней мере строгой математической модели, о чем тут вообще пререкаться?viklequick
06.09.2017 20:20+1У вас просто появляется возможность хранить части файла сразу в виде разных полей объекта базы данных,
Шо, опять привет из VMS?
Ох жива идея-то, со внешней структуризацией файлов-то…
Или это уже речь о кошерном формате копибуков, который натягивает структуру на поток битов? Типа кто хочет тот работает структурировано через копибуковую трансляцию, а кто не хочет так тому битики, хмм…
Ох щи… а сейчас-то кто мешает? Я вот пользуюсь там где надо.
Или тут ключ к пониманию — «нереляционная БД»? Так запихать «метаданные» в одну известную не-ACID БД на букву «Монга» я могу и сейчас. И даже бывают случаи, когда там реально «все» хранится, включая двоичные артефакты в виде к примеру PDF (не, я с ума не сошел, просто вот такой вот способ забивания гвоздей микроскопом).
Так где вы говорите, будет added value от того что «НеРСУБД» будет в kernel space?
А то нам инженерам идеи очень нравятся, просто хотелось бы понимания — какую задачу решают.
lair
06.09.2017 23:00Так же, как есть спецификация структуры jpg или png, и вообще любого файла, с которым вы работаете
Угу, расскажите мне об этом. Почему-то до сих пор нет унифицированного стандарта на файл на выходе с цифровой камеры, и бедные производители софта, начиная от Adobe и заканчивая dcraw, вынуждены постоянно добавлять поддержку новых камер.
И в чем же эта фундаментальность, простите?
В том, что GC достаточно увидеть цикл, определить, что внешних ссылок в него нет, и выкинуть все объекты (я упрощаю, конечно). А маркирующие GC и вовсе трактуют циклы как "а, мы сюда уже приходили, дальше не надо". А вот когда мы используем ссылки для "а давайте включим один файл в другой", то что делать веб-серверу из примера где-то тут в комментариях, когда тот рисует страницу (ок), в нее включен заголовок (ок, его отрисовали тоже), в заголовок включено меню (ок, его отрисовали тоже), в него включен заголовок (ой, что?).
Или, скажем, есть время, когда Вы просто сидите стрОчите комментарии в Хабр, а компьютер в это время по большей части отдыхает? ;)
Обычно я строчу комментарии на хабр, когда компьютер чем-то занят полезным, типа сборки билда или тестов. А еще планшеты есть, с них тоже ничего так писать на хабр.
Ну, и, кроме того, дедупликация — это не только экономия места, но так же и экономия ресурса (количества чтений) диска (один раз объект закэшировали — сто раз отдаём), и экономия сетевого трафика (отдаём повторяющийся кусок один раз, а не десять).
Чтобы было выгодно кэшировать объект, нужно чтобы он запрашивался много раз (а чтобы включилась дедупликация — чтобы запрашивались разные объекты, которые дедуплицировались в один).
А чтобы экономился сетевой трафик, нужно, чтобы сетевой протокол поддерживал дедупликацию и ссылки, и устройство ФС тут мало поможет.
mike_y_k
06.09.2017 20:01А SSI? Именно это и делают операции include. Ну и остаётся CGI для генерации по шаблонам и вставкам. Ничего сложного и дополнительного особо не потребуется. Если посмотреть глубже в Apache — ещё варианты можно нарисовать…
godlin
06.09.2017 20:12Да, есть тысячи способов это сделать. Речь о том, чтобы это можно было сделать на уровне ФС. Но вообще, это просто первый пример, который пришел в голову. Возможно, он не очень удачный)
Nikobraz
06.09.2017 07:50Солидарен со многими вещами, но не со всеми.
Десктопные ОС и правда замерли в середине 90-х.
Нововведения хороши, но они должны делать работу прозрачнее, интуитивнее. А не увеличивать количество абстракций.
Я уже пару лет периодически задумываюсь над заменой Active Directory(как правило после глубокого копания). Такая архаичная и неудобная система, но каких-либо вменяемых аналогов нет, и MS ничего менять не собирается.
NeoCode
06.09.2017 09:22+2По поводу ФС как БД с тегами и прочей метаинформацией всецело поддерживаю. Это реально нужная вещь.
Конечно в основе должна быть иерархическая модель — так удобно и привычно, зачем ломать то что хорошо себя зарекомендовало. В распространенных ФС под все основные ОС есть хардлинки и симлинки, а также области для метаатрибутов; но работа с ними очень плохо интегрирована с GUI. В линуксе симлинки и хардлинки еще более-менее используются, а в винде — почти никак. В тот же Total Commander никак не хотят добавить кнопки «создать симлинк» и «создать хардлинк» — причем люди просят, но у авторов есть официальная позиция, и знаете какая? «Большинство не осилит». И вот по таким причинам «большинство» вообще не знает о том, что файл может физически находиться в нескольких местах ФС одновременно. Да и зачем это большинству, если оно тупо хранит свои файлы на «рабочем столе»?
Но для хардлинков нужно как минимум максимально удобное отображение счетчика ссылок на файл — чтобы при удалении было понятно, удаляем ли мы его вообще или просто удаляем одну из ссылок. Симлинки же в NTFS вообще странно сделаны, в двух вариантах.
Я уж не говорю о том, что крайне необходимо иметь продуманную и интегрированную в ФС систему пользовательских атрибутов/тегов. Поиск, сортировку по ним, конвертацию одних тегов в другие и т.д. Мне вот приходится исхитряться и придумывать собственную условную нотацию для именования файлов и папок, добавлять в начало имен всякие "_", "-", "@", "!" и прочие чтобы хоть как-то внести дополнительную информацию.Nikobraz
06.09.2017 10:00Эмм, разве обычный ярлык не является симлинком? Хардлинки в системе тоже широко используются, взять хотя бы ту же горячо любимую папку WinSxS.
Другое дело, что пользователи часто не знают об этом функционале и его реализация не заложена в GUI Windows. Вообще Майкрософт любят делать никому не нужные ограничения. Например в Проводнике длина пути ограничена 255 символами, когда NTFS поддерживает 32767. Исправили сию «фичу, а не багу» только в Windows 10, и то поддержку длинных имен надо ручками включать.
domix32
06.09.2017 10:32+1Виндовый ярлык — нет. Симлинк позволяет программам общаться с линком на папку как с папкой. Ярлык будет восприниматься как файл с расширением .ink, а не как папка.
sumanai
06.09.2017 15:32В тот же Total Commander никак не хотят добавить кнопки «создать симлинк» и «создать хардлинк»
Используйте Link Shell Extension, он и в ТС работает.
ArcherX
06.09.2017 10:15-2Я с удовольствием прочел статью, отдельно улыбнулся над футуристической картинкой, где проектор создает рабочие экраны для удобно лежащего человека. Вспомнил Тони Старка с его Джарвисом — кто бы ни хотел себе настолько умную систему(не ИИ), которую можно обучать своим привычкам, и она будет запоминать, в каком порядке вы просматриваете сайты, проснувшись или придя с работы, например, какие сообщения из мессенджеров более важные и их следует показывать поверх всего вашего «рабочего пространства». Если уж исходить из идеи проектора, который через камеру и другие датчики определяет куда вы тыкаете, то эти же устройства могут использоваться для оценивания состояния самого пользователя, степени его усталости, например. Сама концепция идеальной ОС, представленная в этой статье, уже сама по себе настолько футуристично выглядит, что несмотря на то, что «здесь нет ничего нового», на проверку окажется, что для работы подобной системы придется придумывать, именно придумывать, новое железо, и если не начинку, то хотя бы все HID-устройства, поскольку мышкоклавой будет банально неудобно пользоваться.
И, собственно, почему всего этого еще нет? Да потому, что автор (я лишь предполагаю) еще не полностью утратил потенциал воображения, а вот все те, кто придумывает новшества в таких больших компаниях-производителях ОСей, своей фантазии уже давно лишились, и могут улучшить (или нет) лишь то, что уже есть и работает. И не потому, что начинать с нуля опасно по многим причинам, в т.ч. и по расходам — а потому, что пойди найди штат программистов, которые захотят и будут во время разработки думать именно так, как тот самый будущий пользователь идеальной ОСи. Потому что узкая специализация и, как следствие, полное остутствие возможности вообразить и претворить фантазии в реальность, в наши дни — норма для общества. Конечно, это лишь мое мнение, и исключения из правил есть всегда. И проще сказать что таки да — никому эта идеальная ОСь не нужна из пользователей, а что уж говорить про разработчиков.hungry_ewok
06.09.2017 13:46+2>Я с удовольствием прочел статью, отдельно улыбнулся над футуристической картинкой, где проектор создает рабочие экраны для удобно лежащего человека.
Картинка хорошо иллюстрирует статью, да.
«Давайте сделаем чего-то эдакое чтобы ново, круто, футуристично и чтобы УХ!» — а при попытке реализовать на практике или хотя бы нарисовать как они это видят получается та еще лютая хрень. Как вот с этим креслом. Без нормального подголовника под затылок в таком положении экранов голова через пару часов отвалится, как и руки, которыми предлагают тыкать в экранчики на уровне выше головы, при этом не имея подлокотников. Про то что икры будут затекать без опоры под пятки дизайнер тоже забыл потому что не рисовать не мешки ворочать, зато экранчики на основании прилепить — это святое, это необходимо. Ну и полупрозрачные экраны, конечно, это же так удобно и полезно для глаз — видеть комнату сквозь текст…
Vjatcheslav3345
07.09.2017 12:22+1Потому что узкая специализация и, как следствие, полное остутствие возможности вообразить и претворить фантазии в реальность, в наши дни — норма для общества. Конечно, это лишь мое мнение, и исключения из правил есть всегда. И проще сказать что таки да — никому эта идеальная ОСь не нужна из пользователей, а что уж говорить про разработчиков.
Тогда эту ОС нужно создавать энтузиастам в Майнкрафт — и сообщество там большое — в том числе и "образцовых" пользователей, которые считают что компьютер — это его дисплей и с фантазией всё в порядке и игру можно использовать как среду для тестирования в условиях, близких к реальным.
alexr64
06.09.2017 10:15Как только появится массовый двусторонний нейроинтерфейс — можно будет говорить о «перенаправить видео из скайпика куда то там» и всякое такое. Сейчас же — это все не нужно, неудобно и вредно.
sibnick
06.09.2017 10:15+2Статья из разряда
Раньше трава была зеленее
а по фактам
Требовались огромные усилия, чтобы запустить Doom с 3D-ускорением в X Windows в середине 2000-х, тривиальная задача для середины 1990-х в Microsoft Windows.
В 1995 году Doom не использовал 3Д ускорителей поскольку их просто не было у большинства. И под Windows в 1995 году он не работал (не под 95, не под 3.11 и не под NT) а только под DOS.
Zakyann
06.09.2017 10:15+1По поводу быстрого поиска файлов по названию, может кто-то не видел:
Everything
Не совсем то, что хочется автору (поиск по мета-тэгам), но по названию ищет очень быстро на больших списках. Индексирование работает на уровне NTFS.
maxzh83
06.09.2017 10:42+2Многое из того, что хочет автор (таскание вкладок между разными приложениями, ноутбук как усилитель голоса и т.д.), нужно
только авторунебольшому количеству пользователей. Обычно учитывается интересы большого числа пользователей и то не всегда. И если есть какая-то острая потребность, то она будет удовлетворена. Как пример, можно вспомнить браузер IE и потребность в нормальном браузере.Manul81
06.09.2017 13:54Не совсем с вами согласен. Конкретно, применимо ко мне, с перетаскиваниями страниц из браузера в браузер я бы сильно подружился. Объясню почему: всеми любимый Хром жрёт память как хомяк. А мне часто нужно что-то открыть быстро (не в силу того, что таймер бомбы тикает, а просто потому, что открыто и так слишком много вкладок, и общая работы системы замедляется. А я человек спокойный, но только до определённого момента). К тому же использую разные браузеры для разных целей, в силу того, что в каждом много вкладок (опять же память кушает), а открытие разных экземпляров одного браузера, как вы понимаете, ни к чему хорошему не приводит, опять же, в силу потребления памяти. И частенько нужно посмотреть что-то не по теме открытого браузера (это мое ОКР или СНС, не знаю) :). Простым перетаскиванием я бы решил много проблем…
geher
06.09.2017 14:23Сейчас поэкспериментировал с ff и ie
Ссылки и закладки перетаскиваются в обе стороны, но есть неудобство — открывается в текущей вкладке.
Содержимое строки адреса только из ff в ie. Обратно никак.
Вкладки не перетаскиваются совсем. Задумался о плагинах для ff: реализующем перетаскивание вкладок как ссылок и обеспечивающем открытие новой вкладки при заносе ссылки извне.
maxzh83
06.09.2017 16:36+2Насколько я понял из статьи, автор хочет чтоб вкладки браузера можно было перетаскивать не только в другой браузер, а куда угодно. К сожалению, как именно должны реагировать другие приложения, он не описал, там же «растровые прямоугольники из битов», так что все очевидно. А я бы хотел посмотреть на то, что должен делать, например, блокнот, если в него перетащить окно с фильмом и т.д.
Manul81
06.09.2017 17:27Здесь то на уровне фантазии пока, иначе бы это было бизнес-планом :) Я тоже могу много чего придумать без конкретной реализации. Касательно того, что будет делать блокнот, если в окно перетащить окно с фильмом, можно сделать так, что блокнот распишет все диалоги по именам, со ссылками на музыку по времени :) Как вы сами понимаете, пока это недостижимо.
geher
06.09.2017 18:49Насколько я понимаю, у автора статьи речь о перетаскивании вкладки не в смысле интеграции содержимого в другое приложение, а в смысле тупой состыковки окон.
Примерно как в каком-нибудь IDE (том же Delphi). Там часто можно пристыковывать друг к другу окна с разным содержимым (например, редактор кода к свойствам объекта), что никак не влияет на взаимозависимость и функциональность окон.
Как по мне, было бы удобно. Пристыковал к тому же IDE вкладку браузера. Она висит себе, функционируя все еще в браузере и будучи никак не связано функционально с IDE, но при этом находясь связанным с окном IDE,
MacIn
08.09.2017 14:11+1Когда слышу это, сразу вспоминается презентация OLE, DDE. И аналогичных механизмов в OS/2.
Точно такие же футуристические заявления, примеры с прикреплением видео или таблиц в текстовый документ и тому подобное.
Это. Уже. Было.
amarao
06.09.2017 11:47+1Простите, кто не готов? Wayland? Готовее готовых. У меня на столе лежит Dell XPS13, на нём прекрасно работает Wayland в составе свежей бубунты (17.10). Единственное, что меня останавливает — это отсутствие primary buffer, но и его фиксят.
Manul81
06.09.2017 13:44Я не специалист, но всё написанное, конкретно для меня, очень интересно. И да, я бы поучаствовал в разработке, если бы было больше знаний.
P.S. Всегда хотел буфер обмена хотя бы с 3-мя ячейками (запас). Значительно удобней копировать имя пользователя и пароль из хранителя паролей было бы :)Soulveig
06.09.2017 13:58Для буфера из 5 ячеек есть AutoIt. Для копирования логин\пароля есть куча менеджеров даже с автовходом на страницу и заполнением, типа 1password и др.
Manul81
06.09.2017 15:12-1Безопасность, к самой системе, как-то больше доверия.
Soulveig
06.09.2017 15:23Не, ну так то да, если половина прог будет изначально в системе будет круто…
lair
06.09.2017 15:30+1… особенно будет круто, если они будут безальтернативными. Правда же?
Soulveig
06.09.2017 15:37Без жесткой стандартизации сам смысл такой ОС пропадает (: 99% народа использует стандартый проводник, или стадартный кнтлС+кнтрлв и не знает про другие буферы обмена, будут использовать новый встроенный в новую ОС. Другой вопрос что нужно собрать очень много народу чтобы в целом все обсудить и сразу добавить все нужные фишки, а не так, чтобы все еще на вин10 никак не могут допилить прогресс бар для перекидывания файлов по фтп (он как бы есть, но без скорости и оставшегося времени). Тут надо очень комплексно сначала думать обо всех аспектах сразу, при том, в совокупности.
lair
06.09.2017 15:39+1Другой вопрос что нужно собрать очень много народу чтобы в целом все обсудить и сразу добавить все нужные фишки
Вы это серьезно?
Manul81
06.09.2017 17:55Всё равно, главное, лишь бы были удобны настолько, чтобы альтернативы не хотелось.
lair
06.09.2017 17:56+1То, что у разных людей разные критерии удобства, вас не смущает?
Manul81
06.09.2017 18:00-1Если так подходить к вопросу, то каждому человеку следует написать свою собственную ОС, сообразно своему понятию удобства пользования :)
lair
06.09.2017 18:04+1Следует дать возможность выбора. Я бы предпочел, если у меня есть требования к менеджерам паролей, выбирать менеджер паролей, а не ОС.
Manul81
06.09.2017 18:09В этом-то удобство пользования и заключается (как понял смысл данной статьи). Чтобы ОС была одна(едина, или как еще это описать?..), но предоставляла настолько гибкий функционал, что ограничения казались бы невозможными.
lair
06.09.2017 18:09Максимально гибкий функционал предоставляет язык программирования.
Manul81
06.09.2017 18:12-1Это уже не про ОС. Язык реализации неважен. Функционал самих приложений. Для использования конечным потребителем.
lair
06.09.2017 18:17+1Я и говорю: максимально гибкий функционал приложений предоставляется языком программирования. Запрограммируй себе что хочешь.
Manul81
06.09.2017 18:21Я, честно говоря, сомневаюсь, что мы друг друга до конца поняли. Что делать в том случае, если человек не программист? Исключая очевидные ответы, пожалуйста :)
lair
06.09.2017 18:26+1А если человек не программист, он не получит "настолько гибкого функционала". И ему как раз проще выбирать между несколькими программами, нежели "настраивать" одну.
Manul81
06.09.2017 18:37Эти разные программы тоже надо будет настраивать, но без единого интерфейса настройки, что, как вы понимаете, менее удобно :)
lair
06.09.2017 18:39А вот не факт. Идеальная (для пользователя) программа — это та, которую настраивать не надо вовсе. Ну и да, что такое "единый интерфейс настройки" я тоже не понимаю.
Manul81
06.09.2017 19:00Идеальная программа, это утопия. А «единый интерфейс настройки» вполне реальная вещь. Примитивный пример: расставить «галки» сообразно своим нуждам в одном меню, которое позволит выбрать именно те функции, которые вам нужны (или будут нужны). Как показывает практика, в разных приложениях это реализовано по-разному(где-то Preferences в главном меню, где-то придётся покопаться). Но главное, опять же функционал самой программы, который позволит это делать (пример: калькулятор в винде — кому-то просто умножить 2 числа, кому-то постоянно инженерный нужен).
lair
06.09.2017 19:02+1Идеальная программа, это утопия
Как и "гибкий функционал".
Как показывает практика, в разных приложениях это реализовано по-разному(где-то Preferences в главном меню, где-то придётся покопаться).
Вы не задумывались, почему?
Manul81
06.09.2017 19:27Так как мы теоритизируем(по крайней мере, я, точно), гибкий функционал более достижим, нежели идеальная программа.
Вы не задумывались, почему?
Задумывался. И вариант «защиты от дурака» мне не кажется всеобъясняющим. Скорее всего не прав в этом вопросе. Если не жалко времени, просветите меня. Повторюсь, если вы не читали мой 1-й комментарий: я простой пользователь(потому и теоритизирую :) ), к разработке ПО не имею никакого отношения. Просто выражаю свою точку зрения, исходя из опыта пользования различными программами и ОС.lair
06.09.2017 19:28+1Так как мы теоритизируем(по крайней мере, я, точно), гибкий функционал более достижим
Ну да, достижим. В виде языка программирования. Все остальное недостаточно гибко (да и это — недостаточно гибко).
И вариант «защиты от дурака» мне не кажется всеобъясняющим.
И правильно. Правильный ответ — потому что разным людям так удобнее.
int33h
06.09.2017 23:55-2А если предположить, что ОС и язык программирования будут предоставлять такие возможности, что только совсем гуманитарий не сможет написать нужную ему программу с его функционалом...(В качестве совсем утрированного примера можно взять MS-Dos и Python.)
geher
06.09.2017 13:59Всегда хотел буфер обмена хотя бы с 3-мя ячейками (запас). Значительно удобней копировать имя пользователя и пароль из хранителя паролей было бы :)
Не скажу за маки, но под линукс и винду менеджеров буфера обмена разной, степени навороченности как у собаки блох.
Cheater
06.09.2017 14:29+2Начал писать подробный ответ, но при чтении про фантазии автора как устроен внутри email-клиент (Кстати, про какой именно клиент речь, он почему-то скромно умолчал), про единую базу документов и единую межпроцессную шину меня разобрал смех и я забил.
Автор банально некомпетентен и скорее всего по жизни занимается высокоуровневой разработкой (пишет glue code), проецируя свой опыт на работу ОС в целом. Кроме того, он путает функцинальность ОС с функциональностью прикладных приложений.Cheater
06.09.2017 14:50+4*функциональность
Ещё там перл про то, что вкладки это просто растр и поэтому легко реализовать перетаскивание вкладок. Т.е. отдаём например текстовому редактору вкладку из другого приложения растром и требуем от него перевести содержимое в текст)))
saibaneko
06.09.2017 18:06По-моему автор перечисляет то, о чем в свое время рассказывал Раскин, или пытались сделать в нашей отечественной ОС Фантом ru.wikipedia.org/wiki/Фантом_(операционная_система)
Arxitektor
06.09.2017 18:38-3А ведь совершенная ОС нужна. Но её сможет с разумные сроки сделать только… ИИ.
Как странно это бы не звучало. И ещё не известно что легче написать ОС игр ИИ.
По крайней мере в ИИ вбухивают $$. И сделают ИИ от и ОС напишет. По типу джарсиса с элементами ИИ
mike_y_k
06.09.2017 20:33+1Прочитал статью целых 3 раза. С первых двух не въехал полностью ;).
В итоге — очередная розовая мечта, с множеством перекосов в оценках и примерах.
И почему основой у автора RPi3 на Broadcom, а не продукция MTK или NXP? Сопоставимых и лучших по производительности и более богатых на пиреферию достаточно. А цена быстро нивелируется при росте производства.
Вопрос с базой данных к файловой системе (или наоборот) в Unix спокойно решается и самостоятельно, и за вменяемое время — код открытый и нужен только дополнительный функционал к существующей(им) FS. Даже в userspace ;) через fuse. Конечно тут сразу тезис о количестве прослоек будет аргументом, но это решение позволит уже в Unix сообществе оценить потребность и перспективы решения.
Об остальных мечтах тоже можно долго спорить, но мало смысла. Была бы минимум проработка концепции.
А почему enlightenment обошли стороной в обзоре? Тут бы сразу концепцию замены X и уменьшения количества прослоек предметно обсудить. Но у автора немного поверхностный взгляд на эту часть проблемы.
Новая система имеет некоторый шанс возникнуть как решение от одного/нескольких/консорциума из гигантов, или инициатива под OSF, или их совместная инициатива. Но таки никак не в результате эмоциональной и немного поверхностной статьи. Начало в OSF сильно предпочтительнее.
Wfladimir
07.09.2017 12:48-2Интересно было бы отправить перевод этой линии комментариев автору статьи. Кто-нибудь возьмется перевести их? Дайте ссылку на файл, а я от своего имени любезно поделюсь вашим мнением.
Все таки это не мечты, а натуральная идея — создать Новую Операционную Систему.
В будущем мне представляется, что ОС будет наподобие робота. Робота-добровольца. Робота-раба. Робота-служанки. Друга, товрища, брата, сестры и так далее. Будет зависеть уже от выдумки программиста.
Дальше. Изначально было сказано, на мой взгляд, верное сопостовление — Язык — Операционная Система. Что вы хотите от Си? Максимум Линукс. Ну если бы вся промышленность по производству чипов была на него заточена со своими драйверами и архитетурой вычислительных блоков, то тогда вы бы получили все равно Совершенный Идеальный Линукс и не более того.
Итак — Новый Язык — Новая ОС. Что мы имеем. Язык разрабатывается под определенные задачи. ОС — это не самоцель, а инструмент владения и управления.
Нужно что-то такое подо что ставить цель и под нее задачи. А дальше будут варианты достижения.
То что проблема новой ОС зреет это понятно. То что общество к ней еще не готово, тоже ясно. Поэтому говорить здесь можно только оторвавшись от сегодняшних насущных проблем, помечтав.
Самое выгодное положение для человека — лежа. Под это кто-нибудь делал интерфейс?
В ванне-бассейне теплой воды лежать-плавать — состояние наподобие невесомости. Это идеальная платформа, фон на котором можно делать игровые приложение или как они там будут потом называться. Датчики давления и другие приспособления будут связывать с Реальностью. Тогда будет только одна реальность — как сейчас говорят — дополненная. Тогда она будет называться иначе, наверняка.
«Самое гибкое приложение — это когда ты его сам программируешь» — это из этой линнии комментариев. — Да? Но тогда язык должен быть таким, чтоб любая домохозяйка могла на нем программировать. Это положение входит в систему — ОС — язык.
Программистов единицы. Это глубоко специфическая специальность. Вы, как иностранцы — говорите на своем языке с машиной — программисты. И не требуйте от нас повторения прохождения вашего пути. У нас своя дорога. Так вот — все сводится к тому, что скоро программировать, или как это будет называться потом, сможет каждый. То есть — выше языков высокого уровня. Появятся Житейские языки программирования — это еще более обособленные инструменты от «железа». И на основе их то и можно будет попробовать, что-то строить. Типа, какую-нибудь ОС или приложения.
Автор делает замечание производителям — почему столь сложные системы, как слежение за движением глаз вы делаете на относительно слабых мобильных приборах и не развиваете их сколько-либо приемлемо на мощных и сверхмощных настольных системах и рабочих станциях. Кроме слежения за яблоком глаз есть масса других систем и приспособлений, которые пригодились бы многим. Они же думают только о деньгах, о прибыли, в первую очередь. Это уже всем понятно.
Теперь о Билле Гейтце. Этот парень бизнесмен капиталлистического общества. Что вы от него хотите? Кстати, его миллиардики с него уже сдернули. Это так называемые быстрые деньги.
А теперь главное.
Никто не будет и не сможет у нас финансировать разработку Новой ОС. Только Государство. Только ему сегодня под силу эта задача. В Китае примерно так и поступили — для внутреннего рынка выпустили свои системники и запустили на них Линукс. Ума не хватает свою ОС создать.
А Русские это смогут. Но какой урон потерпит, не просто Майкрософт, а весь англо-саксонский капиталистический мир! Поэтому никто это не позволит. Особенно на фоне нашей, откровенно, слабой страны с ее дурным правительством.
Так что отсутствие Новой ОС — это вопрос философский. Вопрос идеологии и монополии. То есть власти и денег. И отдавать приоритет кому бы то ни было им опасно.
Но США не вечно. Земной шар круглый. Земной мир замкнутый. И придет такое время, когда это будет норма — разработка операционной системы! А не как сейчас, когда монополия давит все в ещё зачатке. И когда есть целые отделы слежки и, как это у них называется — собственной безопасности — не пущать, авторское право, лицензия и информационная, патентная война.
А ещё есть стереотипы, инерционность сознания, привычки, — мы с вами, которые так или иначе задерживаем приход нового! И ему этому Новому надо прилагать неимоверные усилия, чтоб прорваться в наш мир.lair
07.09.2017 13:15Самое выгодное положение для человека — лежа.
Разве? Почему?
Wfladimir
07.09.2017 13:27-1Может быть потому, что самое невыгодное, с энергетической точки зрения — это положение стоя? Когда человек постоянно падает и постоянно поддерживает своё состояние. Хождение иногда называют — поддержкой от падения!
lair
07.09.2017 13:29+1Между "стоя — самое невыгодное" и "лежа — самое выгодное" нет никакой логической связи.
(Это не говоря о том, что утверждение "стоя — самое невыгодное" тоже еще надо доказать)
serbod
08.09.2017 14:10Всё, описанное автором, давно имеется, но не используется. Почему не используется? Вероятно, потому что мало доступных и понятных примеров использования. Многие слышали, что можно обмениваться данными через пайпы, управлять контролами через сигналы, что в файловой системе есть метаданные. Но как это правильно использовать — знают немногие. А вот описаний и примеров использования громоздких коммерческих решений и их опенсорсных аналогов — очень много.
Wedmer
Дежавю:
habrahabr.ru/post/337010
m1rko Автор
Виноват, не заметил :(
Но там только половина переведена.