Комментарии 20
Unix-way почему-то закончился на утилитах командной строки — действительно лучшей на сегодняшний день. Всё упирается в простые типы для общения между компонентами (потоки, строки, строковое представление аргументов командной строки). У меня же речь идёт о том, чтобы полностью отказаться от синтетических (не относящихся к предметной области) типов в пользу тех, которые адекватно передают именно то, с чем производится работа, отделяя, скажем, формат от данных.
www.youtube.com/playlist?list=PL6601A198DF14788D
Каким образом в этой схеме реализуется, например, частичная загрузка изображения? progressive jpg позволяет начинать показывать его до окончания загрузки.
Кто принимает решение о том, что нужно показывать low quality картинку пока картинка (высокого качества) продолжает грузиться по каналу в 10 килобит? Если это делает модуль отображения на экране, как он сигнализирует модулю ниже о том, что "дай мне картинку из неполных данных"? Как модуль рендеринга jpg может узнает, что ему надо отдать неполную картину данных?
Если же превью из начальных байт будет делаться для всех картинок, то будет мигание и торможение, потому что на локальных дисках лучше 1мс подождать, а потом выдать полную картинку, чем её 3 раза перерисовывать. А на канале с 10кбит лучше перерисовывать картинку каждый раз, как мы можем поднять качество изображения (ибо пользователь ждёт).
Как минимум, это можно сделать через асинхронные операции. Отправить запрос на полное изображение и, если ответ не приходит за некий таймаут, — отправить запрос «отрендери то, что есть» (последний может быть регулярным для последовательного улучшения на узком канале).
Хотя я бы обратил в данном случае направление вызовов. Параллельно с методом «Рендерить до полной отрисовки» можно ввести подписку на событие «Изменение отрисованного изображения по мере чтения» (например, с порогом на количество изменённых пикселей и тайм-аутом).
Я вижу абстрацию, которая уже поплыла. Главное, не понятно, в каком направлении дерево контроля идёт.
Хорошо. Теперь, предположим, что мы пишем ютуб.
Теперь у нас следующая ситуация: состояние буфферизирования должно определять разрешение чанка, которое мы подгружаем. Т.е. низкоуровневая компонента определяет параметры для вышестоящей компоненты. Как?
Теперь, ещё интересный момент. Предположим, что у нас происходит ошибка загрузки файла. Кто определяет, что надо попробовать снова и почему?
Если вызывающий контекст допустил (явным заданием параметров при открытии потока) переключение разрешения при нехватке скорости — оно произойдёт, т. к. он сам на это подписался. Точно так же он может выбрать и другую политику — например, ждать (полезно при запуске видео) или съедать выпавшие фрагменты (полезно при прямой трансляции или звонке). Все такие параметры должны задаваться явно, наша ОС как раз и задумана как спасение от произвола приложений (когда вместо того, чтобы подождать, мой поток самовольно переключается на 240p).
С обрывом загрузки — необходимость попробовать снова будет определять компонент, глобально установленный в ОС для обработки данного случая (так же, как глобален, к примеру, компонент HTTP). Тот, который пишется один раз, но хорошо. Тот, который понимает, что не надо дёргаться десять раз и жрать понапрасну батарею, набивая запрос, который никуда не уйдёт, если отвалился вайфай — толку всё равно не будет. Тот, который подпишется на восстановление интернет-соединения и оповестит все подвисшие вкладки (а не заставит жать F5 в каждом конкретном случае). Тот, который на основе всей имеющейся информации выдаст адекватное сообщение («компьютер mycomp сейчас не в сети», «провайдер зелёный, но интернета в нём нет», «сетевая карта отключилась от USB») вместо игры в непонятные термины.
Я вижу, что у вас в голове ясная картинка. К сожалению, у меня нет доступа в вашу голову и я потерял ход мысли.
Вы не можете на уровне ОС защищаться от "произвола приложений". Приложение — код, код пишут люди. Как человек написал, так и будет. Если ОС будет мешать писать приложения, приложения под эту ОС писать не будут.
По поводу отпугивания разработчиков — если такая система окажется жизнеспособной и удобной для пользователей, разработчики придут, т. к. есть пользователи. Если это никому окажется не надо — туда и дорога. Если сама разработка загнётся, но какие-то идеи окажутся привлекательными и пойдут дальше — я буду только рад.
Я также упоминал о том, что (по крайней мере, на первых порах) эту ОС можно будет запускать в виде агента под другой ОС, не ставя пользователя в ситуацию «всё или ничего» — думаю, таким образом можно будет смягчить переход.
Что мешает кому-то написать "модуль", который реализует свой собственный udp-стек для передачи видео, его декодирование, показ на экране и UI? А ещё и показ комментариев и подгрузку live-chat'а. И отправку статистики просмотра на сервер, и показ рекламы, и управление лентой подписки.
Я понимаю, что у вас одно видение ситуации, но почему-то кто-то (если решит писать под эту ОС) должен его поддерживать, а не перекомпилировать существующий код под новые (странные) API?
- С юридической стороны — соглашение о струдничестве, которое написано вокруг того, чтобы не тянуть одеяло на себя, а вместе строить удобную для пользователя, прозрачную, насквозь совместимую инфраструктуру (пример такого подхода с возможными санкциями и исключением из магазина даёт Apple).
- С технической стороны — то, что ядро ОС отслеживает, откуда пришёл вызов, и не даёт произвольному модулю использовать произвольный API. Например, GUI-компонент видеоплейера не имеет доступа к сетевому стеку. Плюс, в данной ОС нет скозного API, который бы мог вызвать кто угодно — всё строится вокруг вызова API модулей, ссылки на которые есть у контекста, а кому попало они, опять же, не передаются, т. к. весь API утверждается на уровне ОС.
- В-третьих — несоразмерность усилий. П. 2 показывает, что ОС заточена для другого, а то, что Вы описали, куда проще и легетимнее реализовать на Windows или Android.
Поддерживать никто никого не должен, в т. ч. наша ОС — тех разработчиков, которые используют её не в тех целях, для которых она создаётся.
То есть вы запрещаете пользователям писать программы под ОС, так? Или вы запрещаете распространять написанными ими программы под ОС? Звучит как забор эпических масштабов, ещё больше, чем у Apple.
Российский метод "запрещать и непущать" в IT не работает. На пункте №1 всё закончено для вашей ОС. А пункт №2 не выполним, потому что тьюринг-машины невозможно анализировать без их выполнения.
Короче, закапывайте.
В итоге, все модули могут взаимодействовать со всеми из-за общности API.
ядро ОС отслеживает, откуда пришёл вызов, и не даёт произвольному модулю использовать произвольный API
Вы либо крестик снимите, либо штаны наденьте.
Так можно или нельзя использовать произвольное API?
Например, модуль, потребляющий видеопоток (окно видеоплейера, программа захвата видео, отрисовщик стикеров с ушами животных), может работать с любым источником (файл, видеохостинг, видеозвонок, web-камера и т. д.), не зная, откуда пришло видео. При этом доступ к произвольному API (сеть, сканирование диска, перехват данных других программ и т. п.) для него закрыт.
ОС «Сивелькирия»: пример построения программы