Привет, Хабр.
Это — вторая статья из серии публикаций о проектируемой на данный момент ОС «Сивелькирия». Первая статья доступна здесь, следующая — здесь. Поскольку в комментариях к ней многократно задавались вопросы о цели всей затеи, а также о количестве труда, которое придётся вложить в разработку, чтобы она «взлетела», в данной публикации основное внимание будет сосредоточено именно на них.
Во-первых, будет описана миссия данной разработки (в следующих статьях к тезисному изложению добавится подробный обзор тех систематических проблем существующего ПО, которые предлагается решить в рамках данной разработки). Во-вторых, на примере возможных способов запуска предложенной ОС будет показано, что начать получать пользу от разработки можно будет ещё до набора критической массы доступного ПО или полной миграции под новую систему.
Технические и организационные моменты, упомянутые в данной статье, будут подробно раскрыты в следующих публикациях.
Миссия операционной системы «Сивелькирия» состоит в объединении разрозненных цифровых продуктов в гармоничное целое на базе платформы, гарантирующей совместимость любых программных решений.
Данный принцип лучше всего сформулировать в виде перечня базовых прав заинтересованных лиц, реализация которых в рамках ОС «Сивелькирия» гарантируется организацией взаимодействия и структурой самой операционной системы. Ниже приводится полный список таких положений с некоторыми пояснениями о том, как именно ОС «Сивелькирия» способствует реализации данного права.
Операционная система «Сивелькирия» проектируется для запуска в следующих режимах:
Ниже будет показано, зачем нужны такие возможности.
Запуск в качестве основной операционной системы обеспечивает «Сивелькирии» возможность прямого контроля доступных устройств. С одной стороны, это позволяет оптимальным образом контролировать расходование системных ресурсов, например, процессорного времени и оперативной памяти. С другой — ставит пользователя перед жёстким выбором: полностью переключиться на новую операционную систему, под которой на начальном этапе может не хватать ПО для комфортной работы, или не пользоваться ею вообще. Вряд ли будет ошибкой сказать, что многие молодые операционные системы так и не смогли преодолеть этот рубеж: отсутствие программ отпугивает пользователей, а отсутствие пользователей отпугивает разработчиков.
Чтобы разрешить эту неприятную ситуацию, ОС «Сивелькирия» предлагает второй способ запуска — в качестве набора приложений, собранных под некоторую основную операционную систему (например, Windows, Linux или Android). С точки зрения модулей, запускаемых в ней, разницы с первым вариантом нет, так как они по-прежнему взаимодействуют с другими модулями и ядром системы через тот же API. С точки зрения пользователя разница состоит в том, что теперь он продолжает работать со своей основной операционной системой, используя «Сивелькирию» лишь для решения тех задач, которые на данный момент удобнее решаются именно в ней.
Наконец, третий вариант сборки «Сивелькирии» состоит в том, чтобы объектные интерфейсы, существующие в ней, становились видимы некоторому внешнему контексту. В итоге стороннее ПО сможет использовать модули «Сивелькирии» так же, как оно использует обычные общие библиотеки и, хотя внутренняя реализация может подразумевать взаимодействие модулей и разнесение их по разным библиотекам или процессам, эти детали окажутся скрыты от вызывающего контекста. С точки зрения функционирования самой «Сивелькирии» разница между вторым и третьим вариантами запуска состоит лишь в том, что во втором случае пользователь взаимодействует с её графическим интерфейсом, тогда как в третьем случае API вызывается другими системами.
Предложенный вариант позволяет сделать период наполнения новой операционной системы программами максимально полезным, поскольку решение о полной миграции можно будет отсрочить или вовсе отклонить, продолжая использовать лишь те возможности, которые требуются конкретному пользователю. Таким образом, основные цели, стоящие перед «Сивелькирией» — обеспечение совместимости и доступности — окажутся выполнены с минимальными затратами.
Вопрос о том, следует ли называть «Сивелькирию» операционной системой при запуске под некоторой другой ОС, оставляем теоретикам, поскольку для наших целей он не является принципиальным.
Первая публикация цикла доступна здесь, следующая — здесь. Полный текст статьи доступен на сайте проекта.
Это — вторая статья из серии публикаций о проектируемой на данный момент ОС «Сивелькирия». Первая статья доступна здесь, следующая — здесь. Поскольку в комментариях к ней многократно задавались вопросы о цели всей затеи, а также о количестве труда, которое придётся вложить в разработку, чтобы она «взлетела», в данной публикации основное внимание будет сосредоточено именно на них.
Во-первых, будет описана миссия данной разработки (в следующих статьях к тезисному изложению добавится подробный обзор тех систематических проблем существующего ПО, которые предлагается решить в рамках данной разработки). Во-вторых, на примере возможных способов запуска предложенной ОС будет показано, что начать получать пользу от разработки можно будет ещё до набора критической массы доступного ПО или полной миграции под новую систему.
Технические и организационные моменты, упомянутые в данной статье, будут подробно раскрыты в следующих публикациях.
Миссия ОС «Сивелькирия»
Миссия операционной системы «Сивелькирия» состоит в объединении разрозненных цифровых продуктов в гармоничное целое на базе платформы, гарантирующей совместимость любых программных решений.
Данный принцип лучше всего сформулировать в виде перечня базовых прав заинтересованных лиц, реализация которых в рамках ОС «Сивелькирия» гарантируется организацией взаимодействия и структурой самой операционной системы. Ниже приводится полный список таких положений с некоторыми пояснениями о том, как именно ОС «Сивелькирия» способствует реализации данного права.
- Пользователь имеет право на выбор программного решения, наилучшим образом удовлетворяющего его потребностям.
- Любой из используемых модулей может быть заменён другим, более подходящим, без перестройки или потери общей функциональности решения.
- Информация о функциях, предоставляемых модулем, легко доступна (на уровне API и описаний его предназначения, понятных конечному пользователю).
- Тестирование функциональности и производительности, осуществляемое на уровне репозитория (магазина), позволяет разработчикам и пользователям отслеживать качество представленных решений. Обычные системы отзывов также доступны.
- Пользователь имеет право выбирать способ оплаты каждой из используемых услуг.
- Модуль или содержимое может предоставляться либо безвозмездно, либо за плату (единовременную или по подписке), либо в обмен на просмотр рекламы.
- Для модуля или содержимого, предоставление которого подразумевает показ рекламы, должен существовать альтернативный способ предоставления (платный или бесплатный), исключающий рекламу. Предоставление любого контента, содержащего рекламу, не отключаемую ни бесплатно, ни платно, запрещено.
- Пользователь имеет право на получение контента наиболее удобным для него способом.
- Установка и обновление программ производятся прозрачно и просто — через центральный и сторонние репозитории. При этом в центральном репозитории также доступна информация о программах, размещённых в сторонних репозиториях (кроме закрытых корпоративных).
- Центральный репозиторий поддерживается для предоставления максимально полной и актуальной информации о каждом из доступных продуктов. Команда поддержки центрального репозитория блюдёт нейтралитет по отношению к доступным программным продуктам, предоставляя некоммерческую сравнительную информацию.
- Способ, которым осуществляется доступ к некоторому содержимому (музыке, видео, тексту), не влияет на способы, которыми содержимое может быть использовано. Любая программа работает с поддерживаемым содержимым независимо от его происхождения (web, магазин, физический носитель, локальный диск, закрытый протокол).
- Закрытые корпоративные репозитории работают по тому же принципу, что и общедоступные. Контроль за установкой и использованием ПО на оборудовании фирмы требует минимальных дополнительных усилий и не подразумевает обязательного использования дополнительного ПО.
- Пользователь имеет право на использование устройства по назначению.
- Реакции модулей на действия пользователя обязаны быть адекватными. Любые формы отвлечения пользователя от работы, назойливых предложений или рекламы вне отведённых для неё места и времени запрещены.
- Смешивание рекламного содержимого с целевым считается нарушением правил разработки под ОС. Любые уведомления должны быть классифицированы в соответствии с их содержимым; например, запрос оценить программу попадает в очередь других запросов на обслуживание и не может быть модальным.
- Существует система обратной связи для отправки и отслеживания жалоб на неэтичное поведение программ и источников содержимого. Случаи нарушения установленных правил взаимодействия рассматриваются и могут приводить к блокировке нарушителей до устранения нарушений.
- Владелец устройства имеет право на полный контроль над ним.
- Владелец устройства может определять, какие модули установлены на устройство и выполняются на нём.
- Владелец устройства может определять назначение каждого из установленных модулей. Модуль не может брать на себя несвойственные ему функции и не имеет доступа к данным, не требующимся для выполнения его работы. Назначение каждого модуля прописано чётко и однозначно.
- Использование некоторого модуля не влечёт за собой обязательств по использованию другого модуля, поставляемого вместе с ним.
- Владелец устройств имеет право на их совместимость между собой.
- Возможность обмена любыми данными без дополнительных усилий со стороны разработчиков ПО гарантируется архитектурой операционной системы.
- Задачи интеграции, переноса данных и представлений (программ, задач, окон, мультимедиа) между доступными устройствами решаются элементарно на уровне операционной системы.
- Разработчик ПО имеет право на продуманную архитектуру.
- Интерфейсы данных и прототипы модулей позволяют организовать код для повторного использования.
- Совместная разработка интерфейсов данных и прототипов модулей разработчиками ОС и разработчиками ПО позволяет выработать оптимальное решение в каждом конкретном случае.
- Разработчик ПО имеет право на использование функциональности, предоставляемой сторонним ПО.
- Разбиение на модули избавляет разработчика от необходимости самому имплементировать все аспекты, позволяя сосредоточиться на решении конкретной задачи.
- Разбиение на модули позволяет разработчику использовать лучшее решение в составе собственного ПО.
- Независимость структуры модулей от языка и формы распространения позволяет использовать сторонние решения во всех контекстах, в том числе и тогда, когда неизвестно, какое конкретное решение будет использоваться.
- Тесты и списки поддерживаемых функций, доступные на уровне центрального репозитория, позволяют модулям предъявлять требования касательно того, с какими модулями они могут компоноваться, а с какими — нет, избегая ситуации, когда нужная модулю функциональность отсутствует в связанном модуле.
- Разработчик ПО имеет право на совместимость с чужим ПО.
- Унификация интерфейсов обмена данными гарантирует, что данные, созданные одной системой, будут доступны любой другой системе, работающей с тем же типом данных.
- Максимальная прямая и обратная совместимость интерфейсов данных позволяет комбинировать ПО, написанное разными людьми в разное время.
- Попытки создания замкнутой инфраструктуры внутри «Сивелькирии» (например, путём подгонки интерфейсов обмена данными под конкретную реализацию или неполной либо нестандартной реализации интерфейсов для потери совместимости со сторонним ПО) являются нарушением условий сотрудничества и пресекаются.
- Издатель ПО имеет право на получение оплаты за использование ПО и/или показ рекламы.
- Возможность показа рекламы в удобном для пользователя месте встроена в операционную систему.
- Команда поддержки центрального репозитория имеет компетенцию борьбы с нарушениями условий сотрудничества, в том числе с пиратством, и оказывает издателям ПО поддержку, в том числе, через блокировку содержимого и сторонних репозиториев, нарушающих правила.
- Пользователь может влиять на то, когда именно реклама будет показана, однако не может отменять её показ полностью, если условия предоставления используемого им содержимого подразумевают такой способ оплаты.
- Издатель ПО имеет право на экономию ресурсов и повторное использование удачных решений.
- Модульная архитектура позволяет использовать сторонние компоненты в любом контексте. Это даёт возможность сосредоточиться на предоставлении того решения, ради которого затевается разработка, и взять лучшее от уже существующего ПО.
- Издатель ПО имеет право на продвижение разрабатываемого решения в максимальном количестве контекстов.
- Модульность позволяет издателю и пользователю применять ПО везде, где есть такая необходимость, в том числе и в составе другого ПО, и для решения задач, не закладывавшихся в продукт изначально.
- Способ распространения ПО способствует соблюдению условий лицензирования и оплаты, в том числе, если модуль используется как часть сторонней системы.
- Унификация интерфейсов позволяет использовать сервисные модули, решающие мелкие задачи (аналог плаг-инов), в рамках любых совместимых программ, не ограничиваясь одной.
- Перенос решений между различными аппаратными и программными (см. далее) платформами поддерживается на уровне операционной системы.
- Поставщик содержимого имеет право на предоставление содержимого максимально широкой аудитории.
- Унификация способов доступа к некоторому типу содержимого гарантирует, что пользователи смогут получить к нему доступ независимо от типа устройства или контекста использования.
- Поставщик содержимого имеет право сосредоточиться на предоставлении содержимого.
- Необходимая программная поддержка поставщика содержимого ограничивается транспортным уровнем, поскольку после попадания содержимого в операционную систему «Сивелькирия» оно может использоваться в любом контексте. Написание специализированного ПО для просмотра содержимого на данной платформе не требуется (но возможно).
- Поставщик содержимого имеет право на получение платы за свои услуги.
- Как и в случае с ПО, содержимое может предоставляться либо бесплатно, либо за деньги, либо в обмен на просмотр рекламы.
- Как и в случае с ПО, команда поддержки центрального репозитория оказывает владельцам и поставщикам интеллектуальной собственности поддержку, включая блокировку пиратов.
- Корпоративные пользователи имеют право на разработку ПО в закрытом режиме.
- Возможно формирование закрытых репозиториев, ПО из которых не может передаваться за пределы инфраструктуры.
- Корпорации, разрабатывающие ПО для собственных нужд, имеют возможность при необходимости отходить от регламентированной командой разработки ОС структуры интерфейсов и модулей, однако доступность такого ПО ограничивается рамками их организации.
Покрытие платформ
Операционная система «Сивелькирия» проектируется для запуска в следующих режимах:
- В качестве основной операционной системы на платформах x86 и ARM;
- В качестве набора графических приложений под основной операционной системой;
- В качестве набора библиотек и/или процессов в составе другого приложения под основной операционной системой.
Ниже будет показано, зачем нужны такие возможности.
Запуск в качестве основной операционной системы обеспечивает «Сивелькирии» возможность прямого контроля доступных устройств. С одной стороны, это позволяет оптимальным образом контролировать расходование системных ресурсов, например, процессорного времени и оперативной памяти. С другой — ставит пользователя перед жёстким выбором: полностью переключиться на новую операционную систему, под которой на начальном этапе может не хватать ПО для комфортной работы, или не пользоваться ею вообще. Вряд ли будет ошибкой сказать, что многие молодые операционные системы так и не смогли преодолеть этот рубеж: отсутствие программ отпугивает пользователей, а отсутствие пользователей отпугивает разработчиков.
Чтобы разрешить эту неприятную ситуацию, ОС «Сивелькирия» предлагает второй способ запуска — в качестве набора приложений, собранных под некоторую основную операционную систему (например, Windows, Linux или Android). С точки зрения модулей, запускаемых в ней, разницы с первым вариантом нет, так как они по-прежнему взаимодействуют с другими модулями и ядром системы через тот же API. С точки зрения пользователя разница состоит в том, что теперь он продолжает работать со своей основной операционной системой, используя «Сивелькирию» лишь для решения тех задач, которые на данный момент удобнее решаются именно в ней.
Наконец, третий вариант сборки «Сивелькирии» состоит в том, чтобы объектные интерфейсы, существующие в ней, становились видимы некоторому внешнему контексту. В итоге стороннее ПО сможет использовать модули «Сивелькирии» так же, как оно использует обычные общие библиотеки и, хотя внутренняя реализация может подразумевать взаимодействие модулей и разнесение их по разным библиотекам или процессам, эти детали окажутся скрыты от вызывающего контекста. С точки зрения функционирования самой «Сивелькирии» разница между вторым и третьим вариантами запуска состоит лишь в том, что во втором случае пользователь взаимодействует с её графическим интерфейсом, тогда как в третьем случае API вызывается другими системами.
Предложенный вариант позволяет сделать период наполнения новой операционной системы программами максимально полезным, поскольку решение о полной миграции можно будет отсрочить или вовсе отклонить, продолжая использовать лишь те возможности, которые требуются конкретному пользователю. Таким образом, основные цели, стоящие перед «Сивелькирией» — обеспечение совместимости и доступности — окажутся выполнены с минимальными затратами.
Вопрос о том, следует ли называть «Сивелькирию» операционной системой при запуске под некоторой другой ОС, оставляем теоретикам, поскольку для наших целей он не является принципиальным.
Первая публикация цикла доступна здесь, следующая — здесь. Полный текст статьи доступен на сайте проекта.