Приложений не будет. Будут модули, каждый из которых реализует конкретный API, лежащий в репозитории ОС и разрабатываемый совместно разработчиками ПО и разработчиками ОС. В итоге, все модули могут взаимодействовать со всеми из-за общности API. У модулей нет своих потоков и процессов, они лишь обрабатывают входящие вызовы и не являются полноценными приложениями. В этом смысле данная разработка — нечто среднее между ОС и средой выполнения.
По поводу отпугивания разработчиков — если такая система окажется жизнеспособной и удобной для пользователей, разработчики придут, т. к. есть пользователи. Если это никому окажется не надо — туда и дорога. Если сама разработка загнётся, но какие-то идеи окажутся привлекательными и пойдут дальше — я буду только рад.
Я также упоминал о том, что (по крайней мере, на первых порах) эту ОС можно будет запускать в виде агента под другой ОС, не ставя пользователя в ситуацию «всё или ничего» — думаю, таким образом можно будет смягчить переход.
С ютюбом — по той же схеме. В ранних статьях я писал, что в данной ОС нет такого понятия, как «приложение Ютюба». Есть отдельно канал видео с ютюба, который в точке входа в ОС конвертится в простой видеопоток. Есть видеоплейер, который с ним работает (который может быть, в том числе, и с интерфейсом ютюба). Вместо видеоплейера, естественно, может быть какой-то другой компонент (программа захвата видео, или та, что мультяшные ушки рисует блоггеру, которого мы сейчас смотрим).
Если вызывающий контекст допустил (явным заданием параметров при открытии потока) переключение разрешения при нехватке скорости — оно произойдёт, т. к. он сам на это подписался. Точно так же он может выбрать и другую политику — например, ждать (полезно при запуске видео) или съедать выпавшие фрагменты (полезно при прямой трансляции или звонке). Все такие параметры должны задаваться явно, наша ОС как раз и задумана как спасение от произвола приложений (когда вместо того, чтобы подождать, мой поток самовольно переключается на 240p).
С обрывом загрузки — необходимость попробовать снова будет определять компонент, глобально установленный в ОС для обработки данного случая (так же, как глобален, к примеру, компонент HTTP). Тот, который пишется один раз, но хорошо. Тот, который понимает, что не надо дёргаться десять раз и жрать понапрасну батарею, набивая запрос, который никуда не уйдёт, если отвалился вайфай — толку всё равно не будет. Тот, который подпишется на восстановление интернет-соединения и оповестит все подвисшие вкладки (а не заставит жать F5 в каждом конкретном случае). Тот, который на основе всей имеющейся информации выдаст адекватное сообщение («компьютер mycomp сейчас не в сети», «провайдер зелёный, но интернета в нём нет», «сетевая карта отключилась от USB») вместо игры в непонятные термины.
От ГУИ к физическому хранилищу изображений. Кодек не сможет провести вызовы в ГУИ, если тот сам на них не подпишется — у него просто коллбэков не будет.
Как минимум, это можно сделать через асинхронные операции. Отправить запрос на полное изображение и, если ответ не приходит за некий таймаут, — отправить запрос «отрендери то, что есть» (последний может быть регулярным для последовательного улучшения на узком канале).
Хотя я бы обратил в данном случае направление вызовов. Параллельно с методом «Рендерить до полной отрисовки» можно ввести подписку на событие «Изменение отрисованного изображения по мере чтения» (например, с порогом на количество изменённых пикселей и тайм-аутом).
Unix-way почему-то закончился на утилитах командной строки — действительно лучшей на сегодняшний день. Всё упирается в простые типы для общения между компонентами (потоки, строки, строковое представление аргументов командной строки). У меня же речь идёт о том, чтобы полностью отказаться от синтетических (не относящихся к предметной области) типов в пользу тех, которые адекватно передают именно то, с чем производится работа, отделяя, скажем, формат от данных.
Спасибо за пояснение. Похоже, данный проект прошёл мимо нас уже потому, что поддержка C# и Java была добавлена в 2012 году, т. е. через 5 лет после выхода наших первых продуктов на Java (которые, в свою очередь, отставали на несколько лет от таковых для .Net). Нужно будет познакомиться с ним поподробнее.
С ходу я вижу следующие риски при использовании Haxe, которых нет в текущей нашей парадигме:
Сложности с сохранением структуры типов. Поскольку речь идёт о библиотеках, API после портирования C# > Haxe > C# должен оставаться тем же самым с точностью до всех библиотечных типов и интерфейсов. В противном случае это повлечёт необходимость изменения кода клиентов, чего, естественно, требуется избегать всеми возможными способами. Это относится не только к .Net, но и к API уже вышедших продуктов для других языков.
Миграция с C# на Haxe должна быть выполнена идеально с первого раза (сейчас проблемы с портированным кодом никак не влияют на релизы для .Net), и до её завершения возможности начинать покрытие других языков нет.
Утрата истории изменений кода, насчитывающего десятки миллионов строк и сотни человеколет разработки.
Все подсистемы должны работать в точности одинаково на всех языках и в точности как в исходном коде .Net. Например, наши юзкейзы требуют, чтобы генерация XML или графики в портированном коде была полностью аналогична таковой в .Net.
Непонятно, что будет при переезде с дотнетоспецифическими вещами вроде встраиваемых ресурсов, работы со сборками или кодом, завязанным на рефлексию.
Кроме того, я с ходу не нашёл ответа на вопрос о том, возможно ли портировать тесты на все поддерживаемые языки, что, естественно, тоже важно.
Спасибо за комментарий. Ещё можно Skia/SkiaSharp вспомнить из этой серии.
К сожалению, изначально у нас весь код разрабатывается на C#, потому что это дешевле (и в плане оплаты труда программистов, и в плане количества проблем с управляемым кодом). Кроме того, вариант с оборачиванием библиотек C++ хорошо работает только в простых случаях (передача базовых типов, синхронность операций), а вот для работы с большими количествами объектов, передачи интерфейсов и делегатов придётся писать достаточно сложные обёртки.
Набор библиотек для работы с различными форматами файлов (офисные документы, графика и т. п.). Библиотек, правильно читающих все поля и нюансы форматов MS Office, не так много, а Automation Tools стоят дорого.
Нет. В наших библиотеках они не используются, а мы поддерживаем, в первую очередь, те аспекты .Net, которые нужны непосредственно для портирования кода продуктов.
Несколько факторов. В случае с регулярками — да, дело было чисто в оптимизации библиотек. Это только один случай, в .Net много специфических оптимизаций, на которые нужно наступить, чтобы о них узнать.
В случае с портированным кодом — проседания могут быть из-за разницы в механизмах работы с памятью. В C++ нет сжатия кучи, зато есть оверхед при копировании указателей (конструкторы-деструкторы, подсчёт ссылок) — из-за этого код, который часто создаёт много мелких объектов, будет работать медленнее после портирования. Насколько — полностью определяется соотношением рабочей нагрузки и операций по созданию объектов и работе с указателями. Счётные алгоритмы выглядят примерно одинаково на обоих языках, и с ними особой разницы мы не замечали — в основном всё упирается или в библиотеки, или в структуру языка.
Да, разумеется. Как правило, сначала портируется «как есть», а потом начинаются оптимизации (как библиотеки, так и генерированного кода). Поскольку код изначально оптимизирован для C#, порты, как правило, работают медленнее (очень сложно подобрать адекватные тесты, но на том, что мы видели, замедление может происходить в разы, вплоть до одного порядка). Когда это становится критичным, происходит оптимизация — так, нам пришлось отказаться от boostовских регулярок из-за того, что в .Net всё работает намного быстрее.
Здравствуйте. Речь шла о том, чтобы предоставить продукт «чисто Java» или «чисто C++», который позволял бы пользоваться всей функциональностью решения без необходимости зависеть от сервера. Серверные версии с SDK под разные языки у нас, разумеется, и так продаются в виде отдельных продуктов (как self-hosted, так и cloud). Не все хотят ими пользоваться, не все готовы для решения задачи вида «записать pdfку» поднимать сервер — некоторые хотят просто подключить библиотеку к своему продукту и пользоваться ею.
Добрый день. Да, планируется поддержка, в том числе, и самостоятельного режима запуска. В то же время, фокуса именно на конкурировании с существующими ОС нет (по крайней мере, на начальном этапе), так как для полноценной конкуренции нужно наполнение софтом, а это небыстрый процесс. Режим запуска в качестве агента, напротив, позволяет пользователям начать получать пользу от новой системы без необходимости отказываться от всего существующего софта. По поводу desktop vs embedded — изначально прицел делается на покрытие и того, и другого, в частности — на улучшение их взаимодейтсвия (доступ с ПК к данным со смарт-часов по цепочке Часы > Bluetooth > Телефон > WiFi > ПК, перенос окон с компьютера на телефон и обратно, общие системы контактов/уведомлений/аккаунтов, и так далее). На какие платформы будет акцент сделан в итоге — пока сложно сказать, сначала нужно концепцию протестировать.
Кратко и понятно? Забыть о границах приложений как о страшном сне: о запертых внутри конкретной системы данных, о необходимости использовать неудобный интерфейс конкретного окна без возможности сменить его, о необходимости заботиться о том, поддерживает ли конкретное приложение перевод задач (окон, звонков, уведомлений, управляющих элементов) между устройствами, и так далее.
Полная конкретика решаемых проблем дана здесь, эти части я ещё буду публиковать отдельно.
Именно так. О том, почему концепция приложений устарела, я уже писал и ещё буду писать. О том, что данную ОС можно будет запускать и как агент в том числе и под Linux, я тоже писал.
По поводу отпугивания разработчиков — если такая система окажется жизнеспособной и удобной для пользователей, разработчики придут, т. к. есть пользователи. Если это никому окажется не надо — туда и дорога. Если сама разработка загнётся, но какие-то идеи окажутся привлекательными и пойдут дальше — я буду только рад.
Я также упоминал о том, что (по крайней мере, на первых порах) эту ОС можно будет запускать в виде агента под другой ОС, не ставя пользователя в ситуацию «всё или ничего» — думаю, таким образом можно будет смягчить переход.
Если вызывающий контекст допустил (явным заданием параметров при открытии потока) переключение разрешения при нехватке скорости — оно произойдёт, т. к. он сам на это подписался. Точно так же он может выбрать и другую политику — например, ждать (полезно при запуске видео) или съедать выпавшие фрагменты (полезно при прямой трансляции или звонке). Все такие параметры должны задаваться явно, наша ОС как раз и задумана как спасение от произвола приложений (когда вместо того, чтобы подождать, мой поток самовольно переключается на 240p).
С обрывом загрузки — необходимость попробовать снова будет определять компонент, глобально установленный в ОС для обработки данного случая (так же, как глобален, к примеру, компонент HTTP). Тот, который пишется один раз, но хорошо. Тот, который понимает, что не надо дёргаться десять раз и жрать понапрасну батарею, набивая запрос, который никуда не уйдёт, если отвалился вайфай — толку всё равно не будет. Тот, который подпишется на восстановление интернет-соединения и оповестит все подвисшие вкладки (а не заставит жать F5 в каждом конкретном случае). Тот, который на основе всей имеющейся информации выдаст адекватное сообщение («компьютер mycomp сейчас не в сети», «провайдер зелёный, но интернета в нём нет», «сетевая карта отключилась от USB») вместо игры в непонятные термины.
Как минимум, это можно сделать через асинхронные операции. Отправить запрос на полное изображение и, если ответ не приходит за некий таймаут, — отправить запрос «отрендери то, что есть» (последний может быть регулярным для последовательного улучшения на узком канале).
Хотя я бы обратил в данном случае направление вызовов. Параллельно с методом «Рендерить до полной отрисовки» можно ввести подписку на событие «Изменение отрисованного изображения по мере чтения» (например, с порогом на количество изменённых пикселей и тайм-аутом).
Unix-way почему-то закончился на утилитах командной строки — действительно лучшей на сегодняшний день. Всё упирается в простые типы для общения между компонентами (потоки, строки, строковое представление аргументов командной строки). У меня же речь идёт о том, чтобы полностью отказаться от синтетических (не относящихся к предметной области) типов в пользу тех, которые адекватно передают именно то, с чем производится работа, отделяя, скажем, формат от данных.
С ходу я вижу следующие риски при использовании Haxe, которых нет в текущей нашей парадигме:
Кроме того, я с ходу не нашёл ответа на вопрос о том, возможно ли портировать тесты на все поддерживаемые языки, что, естественно, тоже важно.
К сожалению, изначально у нас весь код разрабатывается на C#, потому что это дешевле (и в плане оплаты труда программистов, и в плане количества проблем с управляемым кодом). Кроме того, вариант с оборачиванием библиотек C++ хорошо работает только в простых случаях (передача базовых типов, синхронность операций), а вот для работы с большими количествами объектов, передачи интерфейсов и делегатов придётся писать достаточно сложные обёртки.
В случае с портированным кодом — проседания могут быть из-за разницы в механизмах работы с памятью. В C++ нет сжатия кучи, зато есть оверхед при копировании указателей (конструкторы-деструкторы, подсчёт ссылок) — из-за этого код, который часто создаёт много мелких объектов, будет работать медленнее после портирования. Насколько — полностью определяется соотношением рабочей нагрузки и операций по созданию объектов и работе с указателями. Счётные алгоритмы выглядят примерно одинаково на обоих языках, и с ними особой разницы мы не замечали — в основном всё упирается или в библиотеки, или в структуру языка.
Полная конкретика решаемых проблем дана здесь, эти части я ещё буду публиковать отдельно.