Комментарии 100
Все это конечно хорошо, но мне кажется что вы сейчас все мешает в одну кучу.
Может пора уже перейти к конкретной реализации.
ABI, загрузчик, управление памятью, ядро, работа с файловой системой? На каком языке будет разработка? Будет ли какая либо бинарная совместимость с nix? Posix?
#include <iostream>
using namespace std;
int main() { cout << "hi"; }
Я как бы обеими руками поддерживаю идею создавать что-то новое, но у меня стойкая уверенность, что автор зашёл к задаче не с той стороны. Подобный проект надо начинать с идеи и её проверки на простых действующих концептах, а не со здорового околотехнического описания, которое пока непонятно как реализовывать. Потому что это само по себе отнимает кучу времени на работу, результат которой вполне вероятно придётся просто выбросить, когда дело дойдёт до вопросов реализации. А потом ещё больше времени будет отнимать, когда потребуется это актуализировать в соответствии с реальным ходом проектирования. И боюсь даже автору этим заниматься надоест ещё задолго до получения какого-то полезного результата.
Владельцы денег технических тонкостей все-равно не поймут
Ну здрасьте, как это не поймут? Любой венчурный инвестор по мелким крупицам разбирает проекты, и на предмет осуществимости, и на предмет спроса на рынке. Инвестор же — это не толстый мужик на мешке с деньгами с образованием четыре класса школы, после которых он пошёл на рынок, где заработал первый миллион. Любой инвестор — это в первую очередь организация, с массой профильных экспертов, технических, юридических, маркетинговых. Которые проект проверяют, и в случае их положительного заключения толстый мужик на мешке с деньгами его открывает и даёт вам пачку денег. В обмен этак на 90% долю участия в проекте.
ABI специфический, ориентированный на взаимодействие в объектно-ориентированной среде (возможно, что-то близкое к CLR). Хотя непосредственно термин Application Binary Interface применять не совсем корректно из-за отсутствия чего-либо, что можно было бы называть приложением в этой среде.
Загрузчик на данный момент не выбран.
Управление памятью зависит от режима запуска — например, при работе в качестве агента под другой OS управлением памятью занимается она.
Ядро — гибридное, с заточкой под модульность.
Файловая система — специфическая, объектно-ориентированная.
Язык — C++.
Nix, Posix — нет.
Собственно, сам поворот — в расширении понятия SDK, в выносе в него всех предметных концепций, а не только низкоуровневых. Запуск модулей в общей среде — распространённая практика, тот же CLR это позволяет. Когда запускается модуль с известным API, контролировать, что именно он вызывает, становится легко.
Все данные, доступные через интерфейсы, определённые в операционной системе, могут быть сериализованы и переданы по этому протоколу. В этом случае на втором конце линии операционной системой создаётся объект-прокси, все манипуляции с которым передаются на породившую оригинальный объект машину и там обрабатываются. Данная операция абсолютно прозрачна для потребителя объекта и не требует создания отдельных протоколов под каждую задачу.
Я уже сбился со счету, сколько раз это обещали, и сколько раз это не взлетело.
Использование дополнительной информации (коллекции именованных свойств, расширения и т. п.) не допускается.
Вот, например, возьмем заголовки в HTTP-протоколе или куки в нем же… Как их, бишь, реализовывать без коллекции именованных свойств?
Таким образом, создание проприетарных платформ обмена данными внутри операционной системы невозможно
Что, и массивы байт тоже передавать нельзя?
Что, и массивы байт тоже передавать нельзя?Зависит от контекста. В большинстве API просто не будет методов, котрорые их принимают. В сценариях вроде передачи данных в сокет — да, можно, только сокеты доступны лишь тем модулям, которым это надо для работы.
Вот, например, возьмем заголовки в HTTP-протоколе или куки в нем же… Как их, бишь, реализовывать без коллекции именованных свойств?В данном случае речь не о дополнительной информации, а об основной. Дальше собственно интерфейса «HTTP-ответ» она в таком виде всё равно не пойдёт.
В большинстве API просто не будет методов, котрорые их принимают.
А с картинками как работать? А их оооочень много в современной жизни?
А еще, кстати, вот текст. Массивы символов передавать можно?
В данном случае речь не о дополнительной информации, а об основной.
А как вы одно от другого отделяете? Для меня заголовки — это основная информация в HTTP-ответе (особенно в 202
, 204
или 302
).
Дальше собственно интерфейса «HTTP-ответ» она в таком виде всё равно не пойдёт.
А какая разница? Написано же "не допускается", значит везде не допускается. Или нет?
А с картинками как работать?Как с картинками. Через интерфейс «Картинка». Не делая предположений о том, что у неё внутри — вдруг там вектор или анимация?
Массивы символов передавать можно?Только как строки.
Для меня заголовки — это основная информация в HTTP-ответе (особенно в 202, 204 или 302).Для меня тоже.
А как вы одно от другого отделяете?Отвечая на вопрос о том, для чего предназначен данный интерфейс.
А какая разница? Написано же «не допускается», значит везде не допускается. Или нет?Не допускается в качестве дополнительной информации. Например, интерфейс «Стиль текста», содержащий флаги IsBold, IsItalic и перечисление StrikeStyle (None, Underline, Overline, Strikethrough) не содержит коллекции, куда можно было бы воткнуть строки с цветом и размером шрифта: если эти данные ещё не поддерживаются в оригинальном интерфейсе, нужно расширять его соответствующими общедоступными членами, а не прикручивать x-foobar-extensions.
Через интерфейс «Картинка».
А реализация-то откуда возьмется? Где-то ее надо сделать.
Что веселее, я хочу эту картинку в своем приложении обработать, его алгоритмами — и это значит, что мне нужно ее исходное тело, а не какая-то абстрация поверх.
Только как строки.
Вы же понимаете, что где строка, там и структурированное представление, а где структурированное представление, там и произвольная информация?
Для меня тоже.
… но при этом передать их без словаря ключ-значение не получится. И что делать?
если эти данные ещё не поддерживаются в оригинальном интерфейсе, нужно расширять его соответствующими общедоступными членами
Вот только приложению это невыгодно, это слишком долго.
А реализация-то откуда возьмется? Где-то ее надо сделать.В месте возникновения картинки.
Что веселее, я хочу эту картинку в своем приложении обработать, его алгоритмами — и это значит, что мне нужно ее исходное тело, а не какая-то абстрация поверх.«Своих приложений» в данной системе нет. Модуль либо предоставляет общедоступные сервисы общепонятным способом, либо не существует. Систем, позволяющих писать несовместимые чёрные ящики, и так хватает.
Вы же понимаете, что где строка, там и структурированное представление, а где структурированное представление, там и произвольная информация?Попытка использовать поля интерфейса для передачи не предусмотренной интерфейсом информации является нарушением условий сотрудничества.
… но при этом передать их без словаря ключ-значение не получится. И что делать?Вы не поверите =)
Вот только приложению это невыгодно, это слишком долго.Никакого принуждения. Разрабатывайте под платформы, под которые выгодно.
В месте возникновения картинки.
Где и нужен байт-массив. И, заметим, это должен быть общедоступный интерфейс, потому что есть больше одного способа преобразовать байт-массив в картинку.
«Своих приложений» в данной системе нет.
Есть, просто вы их модулями называете.
Модуль либо предоставляет общедоступные сервисы общепонятным способом, либо не существует.
Ну так сервис "обработать картинку, представленную в виде байт-массива, и вернуть байт-массив" — общедоступен и общепонятен как раз.
Попытка использовать поля интерфейса для передачи не предусмотренной интерфейсом информации является нарушением условий сотрудничества.
Ну так интерфейсом это как раз предусмотрено. Интерфейс вполне может явно написать "здесь — JSON".
Вы не поверите
Ну так расскажите.
Разрабатывайте под платформы, под которые выгодно.
А это именно то, про что я вам, кажется, уже говорил раньше: с принимаемыми вами решениями ваша платформа не будет интересна разработчикам, а если она не интересна разработчикам, то она не интересна пользователям, а дальше, собственно… все.
Если я не ошибаюсь, это та самая печальная судьба, которая постигла Windows Phone.
Ну так сервис «обработать картинку, представленную в виде байт-массива, и вернуть байт-массив» — общедоступен и общепонятен как раз.Нет, потому что он не решает никакую конкретную прикладную задачу, подменяя её абстрактной системной. Как, например, и фраза «запустить приложение».
Ну так интерфейсом это как раз предусмотрено. Интерфейс вполне может явно написать «здесь — JSON».Если речь идёт о передаче внешнего JSON-кода — пожалуйста. Аналогично, для передачи внешних HTTP-хедеров, интерфейс может содержать коллекции именованных свойств (хотя основные/стандартные заголовки, несомненно, пойдут в основной интерфейс). Вопрос в том, что подобное представление не может возникнуть спонтанно, без нужды к тому, как в примере с описанием стиля текста.
А это именно то, про что я вам, кажется, уже говорил раньшеДа, говорили. Я в прошлой статье как раз писал, как это предполагается обойти.
Нет, потому что он не решает никакую конкретную прикладную задачу, подменяя её абстрактной системной.
Да нет, это конкретная прикладная задача. Если быть точным, это преобразование камерного RAW в общепринятый формат.
Вопрос в том, что подобное представление не может возникнуть спонтанно,
Никакой спонтанности, все заранее запланировано. И сразу запланировано с пропьетарностью, с которой вы ничего не сможете сделать.
Да нет, это конкретная прикладная задача. Если быть точным, это преобразование камерного RAW в общепринятый формат.Значит, интерфейс «Изображение» будет и на входе, и на выходе, и у данного модуля будет необходимый доступ к байтовому представлению данного изображения.
Значит, туда можно запихнуть любую пропьетарную информацию, и вы ничего не сможете с этим сделать. Как было черным ящиком, так и останется.
В любом случае, такое нецелевое использование содержимого приведёт к потере совместимости с другими модулями, а также будет являться нарушением условий сотрудничества.
У модуля, который вставляет изображение в сообщение, доступа к его байтовому представлению не будет.
Если не будет — он не сможет его послать получателю сообщения.
В любом случае, такое нецелевое использование содержимого приведёт к потере совместимости с другими модулями
Ну так это не волнует людей, у которых есть их собственные модули, которые между собой остались совместимы.
Если не будет — он не сможет его послать получателю сообщения.Он — не сможет. За формирование сообщения в GUI и за его передачу отвечают различные модули.
Ну так это не волнует людей, у которых есть их собственные модули, которые между собой остались совместимы.Вы об этом уже писали. Я Вам уже отвечал.
За формирование сообщения в GUI и за его передачу отвечают различные модули.
Если мессенджер так декомпонован. Чего он вам, прямо сказан, не обязан.
Вы об этом уже писали. Я Вам уже отвечал.
А это прекрасная иллюстрация к тому, как будут согласовываться общепринятые API.
Вот только дальше передать эту информацию можно будет из модуля, загрузившего камерный RAW из файла, в модуль, который распаковывает её в RGB, а дальше — в тот, который рендерит RGB. Собственно, всё. У модуля, который вставляет изображение в сообщение, доступа к его байтовому представлению не будетОчень плохо. Это значит, я не смогу сохранить себе RAW для архивных целей или кому-то отправить (через мессенджер, например).
О, кстати, навели на интересную мысль.
Предположим, я решил сделать для такой операционной системы "модуль", который будет делать бэкап всего в облако (как это делает Backblaze или IDrive или еще кто-нибудь) или просто на некое сетевое хранилище.
С какой частью операционной системы он вообще будет взаимодействовать?
Вкратце: вы не можете. Но если очень хочется, нужно написать заявку в централизованный комитет, и там её рассмотрят и включат в ОС интерфейсы для такой функциональности.
Поэтому, эта ОСь очень недружелюбна к разработчикам. Но, по замыслу создателя, это будет компенсироваться дружелюбностью к пользователям. Т.к. все бекап-программы будут унифицированы, а значит, взаимозаменяемы, не будет зоопарка форматов и стандартов.
включат в ОС интерфейсы для такой функциональности.
Мне любопытно, как будет выглядеть такой интерфейс.
Т.к. все бекап-программы будут унифицированы, а значит, взаимозаменяемы, не будет зоопарка форматов и стандартов.
Ну это, прямо скажем, никак не гарантируется. То, что бэкап-программа одинаково взаимодействует с системой, никак не значит, что бэкап, созданный одной программой, прочитает другая.
Мне любопытно, как будет выглядеть такой интерфейс.Никак. Вся концепция — просто фантазии, это было понятно ещё с первой публикации. Можно будет ещё раз убедиться, когда автор предложит (или не предложит) своё видение интерфейса IPicture.
никак не значит, что бэкап, созданный одной программой, прочитает другаяДолжна прочитать. Иначе будет забанена за «нарушение условий сотрудничества».
Значит, интерфейс «Изображение» будет и на входе, и на выходе, и у данного модуля будет необходимый доступ к байтовому представлению данного изображения.Это как? Если в интерфейсе IPicture есть свойства Width и Height, и ничего более, как «у данного модуля будет необходимый доступ к байтовому представлению»? В обход методов интерфейса, что запрещено «условиями сотрудничества»?
Я предлагаю вместо стократного переливания из пустого в порожнее взять и показать нам этот IPicture в том виде, как вы его себе представляете, а мы посмотрим, как с ним работать. Если у вас нет никакого представления, как должен выглядеть этот интерфейс, то вся концепция — просто фантазии.
вся концепция — просто фантазииЯ не понимаю, почему в моих интересах должно быть доказывать Вам обратное.
Какая вероятность получить что то новое делая как всегда и как все или вы думаете, что все предыдущие что то упускали?
«Безумие — делать одно и то же, и каждый раз ожидать иного результата»
Думаю Вам стоит намеренно покинуть все «хоженые тропинки». Как только поиск в инете перестанет откликаться на Ваши «предположения», но при этом здравый смысл и логика показывают полезность нововведения, тогда и только тогда стоит что то делать в реальности. В остальных случаях получается аналог графоманства — писать красивым почерком уже научился, а что писать еще не знаешь.
Хотя усидеть на двух стульях (придумать что новое и реализовать его в реальном изделии) практически невозможно.
машинный код на C++
Я не настоящий программист, но всегда думал, что машинный код — он не на C++.
Спасибо за труды. Серьёзно. Когда я был маленьким, я тоже думал о своей модульной операционной системе с максимальной абстракцией всего от всего.
Тоже описывал её в длинных документах, в которых желал сделать "самую совершенную систему", "за всё хорошее, против всего плохого", только на Хабре не публиковал.
И только спустя годы, я понял, что абстракции имеют свойство течь, а операционные системы больше не пишутся на коленке.
Так вот, такими постами вы даёте мне лёгкое чувство ностальгии, когда компьютеры были проще, да и я был более наивным и менее опытным. За него и спасибо.
А по теме: сейчас эти статьи — бессмысленное теоритезирование. сначала сделайте прототип, хотя бы маленький, покажите свою способность реализовать проект. Покажите, что вам достаточно знаний.
Автоматически получаем например проблему с тем что власти конкретного государства могут потребовать какой то модуль запретить (возможно — на определенной территории, своей или чужой). И тоже самая может потребовать через суд частная лавочка.
Как это решать? Или это не считается проблемой?
Применительно к цензуре — в магазины всяких гуглов и эпплов тоже непросто попасть. Если магазин работает по коммерческой схеме, получает прибыль, он будет банить неугодные правительствам модули. Но это не значит, что центральном репозитории их не будет.
Текущее положение в софтостроительстве — дикий капитализм, где каждый тянет одеяло на себя и грызётся с конкурентами.
Предлагаемый подход — плановая экономика, где, чтобы сделать что-то новое, надо идти на поклон к Партии и Правительству, за одобрением. И если уж разрешили делать, то так, чтобы сделанное было доступно всем
Могут. Когда у них нет возможности запустить любимый мессенджер — это выигрыш?
Мне почему-то не кажется, что один одобренный партией мессенджер — это выигрыш для потребителя.
… просто нет форматирования в сообщениях — и все. И фотографии в лимит не пролезают. И обязательно нужно всем показать свой номер телефона. Одни профиты, да.
С фотографиями логично, публикуйте на фотохостинг и давайте ссылку. Ведь под мессенждер провайдер может резервировать полосу, а вы своим нецелевым использованием будете порядок нарушать и другим мешать пользоваться полосой по назначению.
Номер телефона от кого скрываете? Если боитесь, что хулиганы позвонят, обращайтесь в органы, их накажут.
С фотографиями логично, публикуйте на фотохостинг и давайте ссылку.
У меня нет фотохостинга, не могу опубликовать.
Номер телефона от кого скрываете?
Вот именно.
Нет. Просто — нет.
"Видимо". Но на самом деле, Партия считает, что телефон есть у каждого гражданина, поэтому будьте любезны предоставить номер. Нет телефона? Пишите заявление в органы на спецдоступ.
У меня нет фотохостинга, не могу опубликовать.Как нет? Заходите на единый бесплатный фотохостинг, одобренный Партией и Правительством, и загружайте туда свои фотографии.
А он не принимает мои фотографии — они слишком большие.
Но даже если удастся создать что-то похожее, в виде дополнения к уже существующей операционной системы (например linux). То так и не раскрыт вопрос с отсутствующем для ОC «Сивелькирия» прикладным ПО. Например каким образом под эту ОС будет запускаться Microsoft Office?
О том, чтобы насильственно перетаскивать Windows-пользователей, речи у меня не идёт.
Все, кто заинтересован в решении проблем, решаемых «Сивелькирией»
Каких конкретно? Не на уровне общих слов, а конкретно.
Эта часть статьи ещё не опубликована.
… хотя, казалось бы, при написании ТЗ принято решаемые проблемы озвучивать первыми.
Так вот, после краткого просмотра вашей ссылки хочу вам сказать, что бизнес в решении этих проблем заинтересован намного реже, чем вы думаете. А иногда он заинтересован в том, чтобы их создавать. Что, в свою очередь, наводит на мысли, что ваша целевая аудитория очень и очень мала, а та ее часть, которая относится к бизнесу, возможно, вообще близка к нулю.
www.sivelkiria.org/ru/about/issues/programs-isolation
Например, на смартфоне могут быть установлены мессенджеры SMS, Skype, вКонтакте, Viber, WhatsApp, Discord и другие. Все они позволяют пользователю добиться одной и той же цели — обмениваться сообщениями, однако для каждого корреспондента пользователю приходится держать в уме информацию о том, в какой системе производится диалог с ним.
То есть Вы хотите сделать операционную систему для смартфона?
Ранее Вы писали что
А вообще, ограничений на прикручивание офисного ПО нет.
Конкретно Microsoft Office — никак.
А если мне конкретно Microsoft Office нужен?(есть несколько эксель таблиц с макросами, и они обмениваются между собой информацией)
То есть Вы хотите сделать операционную систему для смартфона?Для любых типов устройств.
А если мне конкретно Microsoft Office нужен?Используйте Windows.
Операционная Система «Сивелькирия»: технологии