Как стать автором
Обновить

Комментарии 100

Все это конечно хорошо, но мне кажется что вы сейчас все мешает в одну кучу.
Может пора уже перейти к конкретной реализации.
ABI, загрузчик, управление памятью, ядро, работа с файловой системой? На каком языке будет разработка? Будет ли какая либо бинарная совместимость с nix? Posix?

Ответы на эти и многие другие вопросы можно получить на сайте Сильверкирии. Там автор проделал весьма немалую работу по описанию концепций, в то же время ключевые моменты на тему «как всё это может быть реализовано» находятся в разделе «нерешённые вопросы», а код актуальной версии Сильверкирии выглядит пока вот так:
#include <iostream>
using namespace std;
int main() { cout << "hi"; }

Я как бы обеими руками поддерживаю идею создавать что-то новое, но у меня стойкая уверенность, что автор зашёл к задаче не с той стороны. Подобный проект надо начинать с идеи и её проверки на простых действующих концептах, а не со здорового околотехнического описания, которое пока непонятно как реализовывать. Потому что это само по себе отнимает кучу времени на работу, результат которой вполне вероятно придётся просто выбросить, когда дело дойдёт до вопросов реализации. А потом ещё больше времени будет отнимать, когда потребуется это актуализировать в соответствии с реальным ходом проектирования. И боюсь даже автору этим заниматься надоест ещё задолго до получения какого-то полезного результата.
Если кто-то вольет денег, то проблем с разработкой у них не будет.
Чтобы кто-то влил деньги, надо же что-то куда более осязаемое показать, кроме архитектурных идей.
Владельцы денег технических тонкостей все-равно не поймут, поэтому вначале можно идти об общего к частному.
Владельцы денег технических тонкостей все-равно не поймут

Ну здрасьте, как это не поймут? Любой венчурный инвестор по мелким крупицам разбирает проекты, и на предмет осуществимости, и на предмет спроса на рынке. Инвестор же — это не толстый мужик на мешке с деньгами с образованием четыре класса школы, после которых он пошёл на рынок, где заработал первый миллион. Любой инвестор — это в первую очередь организация, с массой профильных экспертов, технических, юридических, маркетинговых. Которые проект проверяют, и в случае их положительного заключения толстый мужик на мешке с деньгами его открывает и даёт вам пачку денег. В обмен этак на 90% долю участия в проекте.
Про проверку востребованности на рынке — да, это обязательно. Ну а техническую сторону как раз и можно потом с экспертами обсудить. Тем более, что используются и рисковые посевы — когда неважно сколько «не взлетит», «взлетевшие» окупят всё.
А что значит «обсудить»? Вот представьте себе, что вы богатый, к вам приходит чувак и говорит: «У меня есть такая вот идея, которая перевернёт мир, я правда ещё ничего в этом направлении не разработал, но это реально круто, дайте мне денег». Вы правда ему дадите денег, когда у него ничего за душой нет, даже если идея и стоящая? Зачем он вам нужен, если у него нет никаких наработок, и он собрался с вашими экспертами ещё что-то обсуждать? Ваши эксперты и без него не реализуют эту идею, что ли?
Это уже зависит от рискованности инвестора. Бывает по-разному. Если изобретатель сможет объяснить инвестору экономическую выгоду, а его экспертам осуществимость идеи, то почему бы и не начать без задела?
Да просто потому, что в этой схеме изобретатель совершенно лишний. Если у него нет задела, ему нечего предложить инвестору, тот может спокойно пожать ему руку, угостить кофе с печенькой, и начать реализовывать проект без необходимости какого-либо долевого участия чувака, подавшего идею. Ну, можно взять его к себе на зарплату.
Ну, на хорошую з/п тоже неплохо…
Добрый день.
ABI специфический, ориентированный на взаимодействие в объектно-ориентированной среде (возможно, что-то близкое к CLR). Хотя непосредственно термин Application Binary Interface применять не совсем корректно из-за отсутствия чего-либо, что можно было бы называть приложением в этой среде.
Загрузчик на данный момент не выбран.
Управление памятью зависит от режима запуска — например, при работе в качестве агента под другой OS управлением памятью занимается она.
Ядро — гибридное, с заточкой под модульность.
Файловая система — специфическая, объектно-ориентированная.
Язык — C++.
Nix, Posix — нет.
Пока что ваши статьи звучат как «за всё хорошее против всего плохого». Мне, например, дураку, вообще неясно, как это технически сильно реализовать. В случае с существующими системами всё понятно и логично: есть битики-байтики, они собираются в файлы, с файлами работают программы, ОС даёт программам возможности для такой работы. А у вас как? Где на этом пути от битиков-байтиков надо свернуть, чтобы попасть в ваше светлое будущее?
Добрый день. Пограммы работают с файлами через некоторый API, доступный, назовём это так, в SDK операционной системы. Этот SDK доступен любому языку программирования, который в принципе может нацеливаться на данную ОС.

Собственно, сам поворот — в расширении понятия SDK, в выносе в него всех предметных концепций, а не только низкоуровневых. Запуск модулей в общей среде — распространённая практика, тот же CLR это позволяет. Когда запускается модуль с известным API, контролировать, что именно он вызывает, становится легко.
Этот такой технотроллинг в предверии 1 апреля?
пока выглядит, как «грабить корованы». Тот же Алексей Брагин( reactos ) делал примерно так: был написан загрузчик с командной строкой а ля «ДОС», лишь после этого народ призывался к идее создать винду. При этом сам разработчик её и делал. Думаю пора бы ему статью про историю ReactOS написать.
Нет, это люди такие просто… посмотрите их репо… git.sivelkiria.org/explore/groups… cmake'ом они решили собирать…
У меня после прочтения возникло стойкое ощущение дежавю

Но Фантом по крайней мере существует как код.

Когда я вижу фразу «XXX — YYY (из) будущего», мне всегда её хочется переиначить: «XXX всегда будет в будущем»
Большое спасибо за ссылку.
Все данные, доступные через интерфейсы, определённые в операционной системе, могут быть сериализованы и переданы по этому протоколу. В этом случае на втором конце линии операционной системой создаётся объект-прокси, все манипуляции с которым передаются на породившую оригинальный объект машину и там обрабатываются. Данная операция абсолютно прозрачна для потребителя объекта и не требует создания отдельных протоколов под каждую задачу.

Я уже сбился со счету, сколько раз это обещали, и сколько раз это не взлетело.


Использование дополнительной информации (коллекции именованных свойств, расширения и т. п.) не допускается.

Вот, например, возьмем заголовки в 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 в общепринятый формат.
Значит, интерфейс «Изображение» будет и на входе, и на выходе, и у данного модуля будет необходимый доступ к байтовому представлению данного изображения.

Значит, туда можно запихнуть любую пропьетарную информацию, и вы ничего не сможете с этим сделать. Как было черным ящиком, так и останется.

Вот только дальше передать эту информацию можно будет из модуля, загрузившего камерный RAW из файла, в модуль, который распаковывает её в RGB, а дальше — в тот, который рендерит RGB. Собственно, всё. У модуля, который вставляет изображение в сообщение, доступа к его байтовому представлению не будет.

В любом случае, такое нецелевое использование содержимого приведёт к потере совместимости с другими модулями, а также будет являться нарушением условий сотрудничества.
У модуля, который вставляет изображение в сообщение, доступа к его байтовому представлению не будет.

Если не будет — он не сможет его послать получателю сообщения.


В любом случае, такое нецелевое использование содержимого приведёт к потере совместимости с другими модулями

Ну так это не волнует людей, у которых есть их собственные модули, которые между собой остались совместимы.

Если не будет — он не сможет его послать получателю сообщения.
Он — не сможет. За формирование сообщения в GUI и за его передачу отвечают различные модули.

Ну так это не волнует людей, у которых есть их собственные модули, которые между собой остались совместимы.
Вы об этом уже писали. Я Вам уже отвечал.
За формирование сообщения в GUI и за его передачу отвечают различные модули.

Если мессенджер так декомпонован. Чего он вам, прямо сказан, не обязан.


Вы об этом уже писали. Я Вам уже отвечал.

А это прекрасная иллюстрация к тому, как будут согласовываться общепринятые API.

Если мессенджер так декомпонован. Чего он вам, прямо сказан, не обязан.
В рамках данной системы — обязан.

В этот момент какой-нибудь случайный WhatsApp говорит вам "не, ничего я вам не обязан, я просто не буду поддерживать эту платформу".

Да.
С такой политикой партии дальше имеющегося ядра в репе на 4 строчки проект не пойдёт
Вот только дальше передать эту информацию можно будет из модуля, загрузившего камерный RAW из файла, в модуль, который распаковывает её в RGB, а дальше — в тот, который рендерит RGB. Собственно, всё. У модуля, который вставляет изображение в сообщение, доступа к его байтовому представлению не будет
Очень плохо. Это значит, я не смогу сохранить себе RAW для архивных целей или кому-то отправить (через мессенджер, например).

О, кстати, навели на интересную мысль.


Предположим, я решил сделать для такой операционной системы "модуль", который будет делать бэкап всего в облако (как это делает Backblaze или IDrive или еще кто-нибудь) или просто на некое сетевое хранилище.


С какой частью операционной системы он вообще будет взаимодействовать?

Вообще, ответ на этот вопрос уже был.
Вкратце: вы не можете. Но если очень хочется, нужно написать заявку в централизованный комитет, и там её рассмотрят и включат в ОС интерфейсы для такой функциональности.

Поэтому, эта ОСь очень недружелюбна к разработчикам. Но, по замыслу создателя, это будет компенсироваться дружелюбностью к пользователям. Т.к. все бекап-программы будут унифицированы, а значит, взаимозаменяемы, не будет зоопарка форматов и стандартов.
включат в ОС интерфейсы для такой функциональности.

Мне любопытно, как будет выглядеть такой интерфейс.


Т.к. все бекап-программы будут унифицированы, а значит, взаимозаменяемы, не будет зоопарка форматов и стандартов.

Ну это, прямо скажем, никак не гарантируется. То, что бэкап-программа одинаково взаимодействует с системой, никак не значит, что бэкап, созданный одной программой, прочитает другая.

Мне любопытно, как будет выглядеть такой интерфейс.
Никак. Вся концепция — просто фантазии, это было понятно ещё с первой публикации. Можно будет ещё раз убедиться, когда автор предложит (или не предложит) своё видение интерфейса IPicture.
никак не значит, что бэкап, созданный одной программой, прочитает другая
Должна прочитать. Иначе будет забанена за «нарушение условий сотрудничества».
Я не знаю, откуда Вы это взяли.
Модуль, который читает картинки с камеры, что у него на выходе? IPicture? Или «файл»? Если второе, рушится концепция, что всё работает с объектами известной структуры, а не с файлами.
Значит, интерфейс «Изображение» будет и на входе, и на выходе, и у данного модуля будет необходимый доступ к байтовому представлению данного изображения.
Это как? Если в интерфейсе IPicture есть свойства Width и Height, и ничего более, как «у данного модуля будет необходимый доступ к байтовому представлению»? В обход методов интерфейса, что запрещено «условиями сотрудничества»?

Я предлагаю вместо стократного переливания из пустого в порожнее взять и показать нам этот IPicture в том виде, как вы его себе представляете, а мы посмотрим, как с ним работать. Если у вас нет никакого представления, как должен выглядеть этот интерфейс, то вся концепция — просто фантазии.
вся концепция — просто фантазии
Я не понимаю, почему в моих интересах должно быть доказывать Вам обратное.
А что в ваших интересах? Появление разработчиков, желающих делать модули, в ваших интересах?

Вот представьте, заходит такой разработчик в эти комментарии, читает, как вы морозитесь от элементарных вопросов, и делает выводы, стоит ли ему вообще тратить время на эту систему.
Дмитрий, прошу ответить на один вопрос:
Какая вероятность получить что то новое делая как всегда и как все или вы думаете, что все предыдущие что то упускали?
«Безумие — делать одно и то же, и каждый раз ожидать иного результата»
Думаю Вам стоит намеренно покинуть все «хоженые тропинки». Как только поиск в инете перестанет откликаться на Ваши «предположения», но при этом здравый смысл и логика показывают полезность нововведения, тогда и только тогда стоит что то делать в реальности. В остальных случаях получается аналог графоманства — писать красивым почерком уже научился, а что писать еще не знаешь.
Хотя усидеть на двух стульях (придумать что новое и реализовать его в реальном изделии) практически невозможно.
машинный код на C++

Я не настоящий программист, но всегда думал, что машинный код — он не на C++.
Спасибо, неточность исправил.

Спасибо за труды. Серьёзно. Когда я был маленьким, я тоже думал о своей модульной операционной системе с максимальной абстракцией всего от всего.
Тоже описывал её в длинных документах, в которых желал сделать "самую совершенную систему", "за всё хорошее, против всего плохого", только на Хабре не публиковал.
И только спустя годы, я понял, что абстракции имеют свойство течь, а операционные системы больше не пишутся на коленке.
Так вот, такими постами вы даёте мне лёгкое чувство ностальгии, когда компьютеры были проще, да и я был более наивным и менее опытным. За него и спасибо.
А по теме: сейчас эти статьи — бессмысленное теоритезирование. сначала сделайте прототип, хотя бы маленький, покажите свою способность реализовать проект. Покажите, что вам достаточно знаний.

Когда я был маленький, у меня тоже были подобные фантазии. Только развивались они в сторону LISP-машины, и главной фичей было то, что приложение явно получает все API от запускающего его модуля в виде списка (словаря) функций. Таким образом, легко было делать песочницы без изоляции процессов: повесил фильтры на файловые функции, например, и передал дальше эти фильтры в запускаемое приложение.
Помню, как в начале 2000-х все хотели в геймдев, но вместо разработки прототипов строчили диздоки
«нарушение условий сотрудничества»… получается есть один центральный сервис который может сказать что такой то модуль работать НЕ должен. И выдрать этот сервис нельзя без потери работоспособности ОС?
Автоматически получаем например проблему с тем что власти конкретного государства могут потребовать какой то модуль запретить (возможно — на определенной территории, своей или чужой). И тоже самая может потребовать через суд частная лавочка.
Как это решать? Или это не считается проблемой?
Как раз это я не считаю проблемой. Линукс можно взять как пример. Есть централизованный диктатор (Торвальдс), при этом можно делать свои дистрибутивы, наплевав на его мнение, собирать коммерческие продукты, соответствующие законодетальствам разных стран (билды с вырезанным шифрованием, или ядра телефонов без поддержки тех или иных беспроводных протоколов).
У линукса нет «условий сотрудничества» а тут прямо заявлено что если разработчик себя ведет не правильно — может получить бан за нарушение этих условий.
Что значит «бан», если система с открытой лицензией и открытыми исходниками. Пилите в своём уголке что угодно в своё удовольствие. В линукс вы тоже не можете контрибутить что попало, там тоже жёсткие требования к модулям.

Применительно к цензуре — в магазины всяких гуглов и эпплов тоже непросто попасть. Если магазин работает по коммерческой схеме, получает прибыль, он будет банить неугодные правительствам модули. Но это не значит, что центральном репозитории их не будет.
Не считается.
Сейчас прочитал соседнюю статью с мемуарами Прохорова, и возникла очевидная аналогия, которая почему-то в голову сразу не пришла.

Текущее положение в софтостроительстве — дикий капитализм, где каждый тянет одеяло на себя и грызётся с конкурентами.

Предлагаемый подход — плановая экономика, где, чтобы сделать что-то новое, надо идти на поклон к Партии и Правительству, за одобрением. И если уж разрешили делать, то так, чтобы сделанное было доступно всем советским людям другим программам.
Как ни странно, но потребители от этого могут быть очень даже в большом выигрыше.
Ключевое слово «могут быть». Но могут и не быть. По всем теоретическим выкладкам, кооперация в долгосрочном плане выгодна. Но люди так воспитаны (или устроены?), что предпочитают собственную небольшую выгоду сейчас, чем большую общественную в будущем.

Могут. Когда у них нет возможности запустить любимый мессенджер — это выигрыш?

Если мессенджер ровно один, одобренный Партией, то такой ситуации не будет.

Мне почему-то не кажется, что один одобренный партией мессенджер — это выигрыш для потребителя.

Не надо тратить время на выбор, нет проблем с совместимостью, никто на уши не вешает маркетинговую лапшу из новых стикеров и новых смайликов, сообщения доставляются — одни профиты.

… просто нет форматирования в сообщениях — и все. И фотографии в лимит не пролезают. И обязательно нужно всем показать свой номер телефона. Одни профиты, да.

От форматирования глаза у некоторых вытекают. Это забота о юзерах, читающих вас.

С фотографиями логично, публикуйте на фотохостинг и давайте ссылку. Ведь под мессенждер провайдер может резервировать полосу, а вы своим нецелевым использованием будете порядок нарушать и другим мешать пользоваться полосой по назначению.

Номер телефона от кого скрываете? Если боитесь, что хулиганы позвонят, обращайтесь в органы, их накажут.
С фотографиями логично, публикуйте на фотохостинг и давайте ссылку.

У меня нет фотохостинга, не могу опубликовать.


Номер телефона от кого скрываете?

Вот именно.


Нет. Просто — нет.

Видимо, мессенджер, одобренный Партией и Правительством, не будет требовать номер телефона, если у каждого гражданина нет телефона. Так что — профит по сравнению с текущими мессенждерами, поголовно требующими номер.

"Видимо". Но на самом деле, Партия считает, что телефон есть у каждого гражданина, поэтому будьте любезны предоставить номер. Нет телефона? Пишите заявление в органы на спецдоступ.

Да не вопрос. Если у вас нет своего переносного телефона, можете в мессенджере указать телефон комендатуры своего общежития. При регистрации в мессенждере, через комендатуру вы подтвердите, что действительно там живёте, а при необходимости связаться с вами голосом, вас вызовут по этому телефону, лучше звонить вечером, вы же будете на месте после наступления комендантского часа.

Сплошной профит, да.

У меня нет фотохостинга, не могу опубликовать.
Как нет? Заходите на единый бесплатный фотохостинг, одобренный Партией и Правительством, и загружайте туда свои фотографии.

А он не принимает мои фотографии — они слишком большие.

Вы не сможете сделать слишком большие фотографии, потому что устройство, которое их производит, не сможет пройти сертификацию. Значит, устройство у вас нелегальное и должно быть конфисковано.

Еще больший профит, да.

High cohesion — всё со всем совместимо, работает в единой системе ГОСТов.
всё со всем совместимо

Кроме пользователя.


Но да, пользователь, не соответствующий ГОСТу, не пройдет сертификацию и должен быть конфискован.

Первое время будут неудобства. Зато потом, когда всех не вписавшихся изымут из оборота, оставшимся будут сплошные профиты.

Особенно для тех, кого изъяли.

Пока существует капитализм — коммунизм, социализм и прочая плановая экономика обречены. Так еще Маркс завещал. Поэтому Троцкий и бредил мировой революцией.
Про то, что для создания современной операционной системы, требуется затратить человеко-часы измеряемые миллиардами долларов, уже кто-то писал.
Но даже если удастся создать что-то похожее, в виде дополнения к уже существующей операционной системы (например linux). То так и не раскрыт вопрос с отсутствующем для ОC «Сивелькирия» прикладным ПО. Например каким образом под эту ОС будет запускаться Microsoft Office?
Конкретно Microsoft Office — никак. А вообще, ограничений на прикручивание офисного ПО нет.
Если никак, то кто тогда ваша целевая аудитория?
Все, кто заинтересован в решении проблем, решаемых «Сивелькирией», в том числе бизнес. Об этих проблемах я ещё буду много и подробно писать.

О том, чтобы насильственно перетаскивать Windows-пользователей, речи у меня не идёт.
Все, кто заинтересован в решении проблем, решаемых «Сивелькирией»

Каких конкретно? Не на уровне общих слов, а конкретно.

Эта часть статьи ещё не опубликована. Мне не остаётся ничего, кроме как послать Вас сюда.
Эта часть статьи ещё не опубликована.

… хотя, казалось бы, при написании ТЗ принято решаемые проблемы озвучивать первыми.


Так вот, после краткого просмотра вашей ссылки хочу вам сказать, что бизнес в решении этих проблем заинтересован намного реже, чем вы думаете. А иногда он заинтересован в том, чтобы их создавать. Что, в свою очередь, наводит на мысли, что ваша целевая аудитория очень и очень мала, а та ее часть, которая относится к бизнесу, возможно, вообще близка к нулю.

перешёл по ссылке
www.sivelkiria.org/ru/about/issues/programs-isolation
Например, на смартфоне могут быть установлены мессенджеры SMS, Skype, вКонтакте, Viber, WhatsApp, Discord и другие. Все они позволяют пользователю добиться одной и той же цели — обмениваться сообщениями, однако для каждого корреспондента пользователю приходится держать в уме информацию о том, в какой системе производится диалог с ним.

То есть Вы хотите сделать операционную систему для смартфона?
Ранее Вы писали что
А вообще, ограничений на прикручивание офисного ПО нет.
Конкретно Microsoft Office — никак.

А если мне конкретно Microsoft Office нужен?(есть несколько эксель таблиц с макросами, и они обмениваются между собой информацией)
Весь софт надо писать заново под эту систему. Подождите, когда-нибудь напишут офисный пакет, совместимый с Microsoft Office, и вы откроете свои таблицы с макросами.
То есть Вы хотите сделать операционную систему для смартфона?
Для любых типов устройств.

А если мне конкретно Microsoft Office нужен?
Используйте Windows.
Чтобы решить проблемы, надо сначала создать проблемы, и с этим, видимо, проблем не будет.
Бизнес заинтересован в том, чтобы квартальный отчёт сдать. И отгрузки провести по бухгалтерии. А у вас, я так понимаю, 1С тоже не будет работать, верно?
Не будет.
Зато честно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации