Комментарии 84
Создать новую операционную систему вполне подъемно команде из нескольких десятков человек. Основная проблема в другом - надо как-то заставить производителей железа выпускать для нее драйверы и производителей софта портировать на неё свои программы. Это никому не интересно, т.к. не сулит никакой прибыли, а без выгоды в это никто не будет вкладываться.
Согласен. Тем не менее, можно было бы начать с ОС в которой есть поддержка какой-нибудь виртуальной машины, типа джавы или дотнета. Они не слишком сложны, есть некоторое количество софта которое будет работать.
Даже попытки такие были, жалко что медленно развивается COSMOS - COSMOS (gocosmos.org)
Если отнять у MS заметную долю рынка, процентов 20, она моментально забудет про открытость дотнета, и очень жёстко покусает…
С железом интересный нюанс. Если делать логично, то каждая железяка должна содержать в себе весь функционал. Наличие драйвера в системе это не мудро. Правильный подход архитектуры и системы, что б любой "черный ящик" мог быть подключаться к системе универсальным способом реализуя любые хотелки пользователя от способностей этого черного ящика.
Да. Мне тоже понравились идеи Java. Я не знаю почему они не додумались. Наверное, они привязались к императивной парадигме и существующей архитектуре. И бизнес. Надо ж бабло рубить. Я практически 20 лет из жизни выбросил и начал с чистого листа считая что компьютер тоже могу сочинять. Не до фанатизма, конечно. А имея планы что это можно реализовать в железе. Вот 11 лет сюда на заходил. Выложил вчера или позавчера публикацию со своей работой. А ее не опубликовали, наверное. Короче, нет ее.
Самые вкусности там по синтаксису. Они заметили общую часть при создании свойств, методов и классов. Я развил эту дело до почти полного совершенства)) У меня весь синтаксис начинается с имени класса. И фактически весь синтаксис языка в одной формуле)) На странице вся формализация грамматики помещается. Правде не ФБН и не регулярные выражения. Пришлось все пересочинять.
С железом интересный нюанс. Если делать логично, то каждая железяка должна содержать в себе весь функционал. Наличие драйвера в системе это не мудро. Правильный подход архитектуры и системы, что б любой «черный ящик» мог быть подключаться к системе универсальным способом реализуя любые хотелки пользователя от способностей этого черного ящика.
Вот есть, например, принтер, который умеет печатать на термобумаге. И есть второй принтер, который умеет печатать четырьмя цветами на бумаге от А5 до А2, с регулируемой плотностью заполнения, переменным DPI и вставкой номеров страниц.
И вы хотите на них распечатать картинку. Откуда возьмется окно настроек принтера без драйвера? Откуда программа узнает, что принтер умеет печатать так, сяк и эдак?
А через год придумают новый принтер, который будет не только печатать, но и сшивать листы.
Собственно, драйверы для того и придумали, чтобы можно было менять функционал программно. Плохо, что производители не хотят пользоваться готовыми или хотя бы поддерживать с ними совместимость. Казалось бы, всего-то нужно распечатать страницу без извращений — нет, будь добр установить графическую конфигурялку для принтера, которая весит сотни памяти и болтается в трее.
Вот именно, по этой причине все параметры настроек логично размещать в самом принтере. Это даже естественно. А система должна их вкусно визуализировать и подать на редактирование.
Вот есть у принтера десяток целочисленных параметров, пусть даже к каждому прилагается текстовая строка с описанием. Дальше что?
Не все так печально)) Есть такая метода. И, уверен, ты их десяток и сам способен придумать. Я в систему построил именно с такой логикой.
Ты хочешь что б я рассказал за систему? Я с удовольствием. Сказал же что введение только попробовал опубликовать и не одобрил модератор. А что мало-мальски сложные устройства не работают, так и есть проблема. Могу только добавить что и простые устройства не работают. Простой выключатель попробуй добавить. Кстати, это главная фишка моей системы. В области автоматизации и ИИ это прорыв.
Ты хочешь что б я рассказал за систему?Что ж у вас за система такая, что может сама рассказать, но вам приходится делать это вместо нее?
Сказал же что введение только попробовал опубликовать и не одобрил модератор.То есть вы попытались опубликовать огрызок текста, не несущий смысловой нагрузки? Ну тогда не удивительно, что его не одобрили.
А что мало-мальски сложные устройства не работают, так и есть проблема.И как я понимаю из ваших слов, вы знаете решение. Возможно, требующее специального «универсального драйвера» и соглашения на разработку устройств.
Вот про это хотелось бы поподробнее. Грубо говоря, я хочу сделать принципиально новое устройство определения настроения хомячка — как оно должно объяснить операционке свой функционал?
Простой выключатель попробуй добавить.Что вы имеете в виду под «простым выключателем»?
Внешнюю кнопку, на которую можно повесить выполнение скрипта? Это делается довольно просто.
Или наоборот, выходной проводок, на котором будет 0 или 1 в зависимости от программы? Да тоже подобное делал — CustomHID и простой код передачи запросов. Можно и более универсальное через CDC и передачу текстовых команд. А в отдельных случаях можно и напрямую через GPIO материнки управлять.
И как я понимаю из ваших слов, вы знаете решение. Возможно, требующее специального «универсального драйвера» и соглашения на разработку устройств.
Да. Конечно, без соглашения никак. Скорее не "универсальный драйвер" а универсальный механизм взаимодействия. Кроме того событийная архитектура процессора. Ведь классическая архитектура это часть соглашения. Не объявленная, но подразумевающаяся.
Помнится, разработчики USB пытались подобное сделать — там ведь устройство тоже обязано «представиться», передать свои дескрипторы. Но и они не сумели предусмотреть всего, в результате пришлось добавлять всякие vendor-specific. А вендоры соответственно этим злоупотреблять.
Но на вопрос вы все еще не ответили: как именно вы хотите унифицировать бесконечное разнообразие устройств включая все, которые будут изобретены в будущем?
Ну, если говорить про существующие системы, то проще не в ядро изменения вносить, а написать универсальный драйвер, с которым будут работать все устройства, поддерживающие ваше соглашение.
Не получается так. Именно это я и хочу сказать. Императивная парадигма не позволяет.
Но на вопрос вы все еще не ответили: как именно вы хотите унифицировать бесконечное разнообразие устройств включая все, которые будут изобретены в будущем?
Ты очень правильно сформулировал проблему насчет будущих. Проблема почти Воланда. Не, только работать с будущими устройствами, но и так как захочется в будущем. А человек сейчас хочет так, а завтра по другому. К сожалению, не имею хрустального шара что б за пару фраз сказать и все станет понятно. И так кручусь как жук на сковородке подбирая слова, что б было близко к тому, чем занимаюсь. Надо полностью изучить основы. Документ я могу прислать, но лучше в общении. Это часа 3 минимум. Потом что б прошло пару дней что б улеглось и еще побеседовать. И только потом есть смысл показывать примеры. Я не выпендриваюсь. Просто по опыту. Не первый семинар уже провел.
Не получается так. Именно это я и хочу сказать. Императивная парадигма не позволяет.При чем здесь парадигма? Данные это всего лишь данные, способ обработки вы вольны выбирать сами.
Если вашу идею невозможно интегрировать в существующую экосистему, у нее почти нет шансов. Революции в компьютерных техниках уже прошли, сейчас время эволюций.
И что еще хуже, вам придется заинтересовать не меня, а производителей железа — что им придется городить свои кривульки не так, как хотят они, а так как считаете правильным вы.
К сожалению, не имею хрустального шара что б за пару фраз сказать и все станет понятно. И так кручусь как жук на сковородке подбирая слова, что б было близко к тому, чем занимаюсь. Надо полностью изучить основы.Если эта информация не секретная, лучше выложить именно документ. Мало ли кто заинтересуется.
Но пока что у меня большие сомнения что вы верно оценили саму сложность проблемы и что решили именно ее, а не какие-то частные случаи.
Повторюсь, авторы USB тоже пытались сделать универсальную шину. Но не преуспели — уж слишком велико разнообразие устройств. Хотя видя, что они предусмотрели даже джойстик для танка, подводной лодки и космического корабля (да, каждый из них прописан в стандарте!) — попытка была весьма неплохой.
Революции в компьютерных техниках уже прошли, сейчас время эволюций.
А я думаю что назрело и перезрело. Дальнейшее развитие в распараллеливании. А предложений принципиальных нет.
При чем здесь парадигма? Данные это всего лишь данные, способ обработки вы вольны выбирать сами.
Оно то так, но трудно складывать кубик из шаров.
Дальнейшее развитие в распараллеливании. А предложений принципиальных нет.Потому что и запроса нет. Бытовые задачи решены лет десять назад, а увеличение скорости только чтобы крутить говнокод не самый эффективный двигатель прогресса.
Оно то так, но трудно складывать кубик из шаров.А особенно сложно когда непонятно куб складывать, шар, тетраэдр или статую русалки.
Почему бы устройству со встроенным драйвером не предоставлять компьютеру лишь интерфейс?
Мой роутер отдаёт лишь веб-страницу со своими настройками.
Пример с роутером даже обсуждать не стоит — у него интерфейс предельно примитивный.
Не знаю как у других роутеров, но у моего Netgear jwnr2000v2 веб-интерфейс предельно подробный, можно настроить абсолютно всё.
И сравните с заменой хотя бы мышки — она передает вполне определенные данные в драйвер, тот в ОС, она распределяет между приложениями. И замена скажем USB мышки на COM-портовую ведет в лучшем случае к переключению драйвера, в худшем — к неработоспособности. И это стандартное устройство.
А если говорить об экзотике — система может вообще не знать что это за устройство и как им управлять.
Но никакие программы на компьютере о нем знать не знают
А зачем им знать? Я уже давно с этим роутером и что-то не испытываю каких-то проблем, что сторонние программы не могут подключиться к нему.
Так же и с Wi-Fi — зачем чужим программам лезть в него? От драйвера получаем лишь интернет-данные, а могли бы получать напрямую из драйвера внутри устройства.
С мышки почему бы не получать только координаты, да нажатия по стандартным портам/адресам?
COM-ещё используются где-то?
С мышки почему бы не получать только координаты, да нажатия по стандартным портам/адресам?А сколько у мышки координат? А сколько кнопок? А какова частота опроса, разрешение, другие параметры?
Нет, авторы USB эту проблемы попытались решить, но до конца не преуспели.
COM-ещё используются где-то?Очвидно, речь не просто о COM-порту, которым, очевидно, пользуются, а именно о мышках.
А о мышках — вы готовы гарантировать, что кроме USB не будет других интерфейсов?
Проблема ведь именно в этом: устройств бесконечно много, мы сейчас даже представить не можем что изобретут через пять лет.
Анекдотизм ситуации состоял в том, что школьник из Нижнего Тагила скопировал Ubuntu, но был искренне убеждён в уникальности своего проекта
Ещё бОльшая комичность заключалась в том, что так же считали его преподаватели и местные журналисты, состряпавшие репортаж. Без их участия об этой истории никто бы даже не узнал
В статье незаслуженно обошли стороной SerenityOS:
https://github.com/SerenityOS/serenity
https://www.youtube.com/c/AndreasKling/featured
Мне кажется это хороший пример, как может развиваться написанная с нуля система, которой всего 2 года.
Если смотреть глубже, то разницы между этими ОС практически нет. Принципиально новое должно появиться вместе с философией и архитектурой процессора. А что может поменяться если принцип тот же? Команды, выполняющиеся последовательно, адреса, связывание, выделение памяти, загрузка, файловая система и прерывания. Все это уже обсосано и сделано миллион раз. Думаю новая система будет представлять собой единое целое с архитектурой процессора. Должна быть такой. Потому не вижу практического смысла в осестроении без реальных прорывных идей.
Думаю новая система будет представлять собой единое целое с архитектурой процессора
Ага, и иметь над этим десять слоёв абстракций, чтобы выполнять софт из старых операционных систем.
Зачем? Может это и смысла иметь не будет. Сколько там того софта? Редактирование, текст, видео, базы данных, браузер как часть системы. А что-то личное легко интегрироваться должно. От сайтов до.. не знаю чего..
Софта там как раз немало. Редактирование текста и электронных таблиц, совместимое с MS Office. Подготовка презентаций. Аудио/видео плейеры. Куча разных мессенджеров плюс электронная почта. А браузер - отдельная песня. Это такая хитрая компонента ОС, которая сама по сложности не уступает некоторым ОС.
Это только если мы говорим про ОС для печатных машинок и планшетов (хотя зачем для них в принципе могла бы понадобиться новая ОС?)
А если мы говорим про ОС для компьютера в качестве рабочего инструмента, то тут приходит огромное количество разнообразного профессионального софта - ERP системы, CRM системы, бухгалтерский софт, CADы всякие, IDE, электронный документооборот и так далее. И всё это работает обычно на Windows и реже на Linux. И нифига не будет портироваться на новую ещё не распространённую ось, для которой нет из коробки слоя совместимости.
И это мы не коснулись ещё одного мира в ИТ - компьютерных игр. Которые тоже должны откуда-то взяться на новой ОС.
Могу только повторить сказанное. Все должно стать частью системы. Портирование будет заключаться в переформатировании файлов.
Я, если честно, не понимаю, что вы пытаетесь сказать. Как посторонний софт может стать частью новой системы без его полного переписывания с колоссальными трудозатратами? И что такое "переформатирование файлов"? Каких файлов, исполняемых, что ли? Так они наполовину состоят из вызовов API текущих систем, которые тоже надо будет как-то реализовать в новой ОС.
Спасибо за ответ. Я давно не понятный. И не знаю как объясниться. Пробую объяснить базовые понятия. Никому не интересно. Не хочу выглядеть идиотом. В двух словах это приблизительно так, как мы общаемся и понимаем друг друга и обходимся без софта. Вот где-то такая машина. И событийная и немного на Пролог похожа.
Я бы что-то другое хотел услышать. Не в двух словах абстрактный принцип, а совсем наоборот - подробнее что вы имеете в виду, для чего это нужно, чем это лучше современного подхода, и как оно будет способно решать текущие задачи пользователей. Последнее - немаловажно, т.к. пользователю компьютера от него нужна не внутренняя архитектура ОС, а прикладной софт. И в 99.9% случаев взаимодействие пользователя с ОС сводится к двум действиям - "запустить нужную программу", "выключить компьютер"
Если очень коротко, то я предлагаю даже исключить пункт "запустить нужную программу".
Вы не поняли мой вопрос (хотя для меня странно, я ведь открытым текстом попросил - "не в двух словах", "подробнее", а вы наоборот, ещё больше сократить решили :-). Абсолютно неважно, как это называется. Суть в том, что компьютер должен делать какие-то задачи. Мы называем это программой или приложением, можно назвать это не программой, а функцией, или там зюзиком каким-нибудь в новой альтернативной терминологии, суть ведь не поменяется. Пользователь каким-то образом доносит до компьютера, что ему нужно, компьютер это делает. Сейчас это сделано так: пользователь мышкой нажимает на картинку, программа, которая формирует такую абстракцию, как "рабочий стол пользователя", запускает другую программу, которая соответствует задаче пользователя.
Способ этот не единственный, есть куча других вариантов, как добиться решения задач пользователя на компьютере. Можно, например, уйти от концепции крупных специализированных программ, разбить их на мелкие функции, которые между собой будут общаться по каким-то унифицированным протоколам (первое что пришло в голову). Но у этого нашего способа есть одна киллер-фича: он повсеместно применяемый. Соответственно, он выверенный десятилетиями, опробован на миллионах программистов и миллиардах пользователей, совершенствовался и оттачивался всё это время.
Поэтому, предлагая какой-то новый способ, надо ответить и на вопрос "что это", и "зачем это".
Я понял твой вопрос. Я думаю как отвечать. Вот берем пример программы. Если выпадет снег, нужно его убрать. Программа? Ты гарантируешь что снег будет убран? (Т.е. в привычной терминологии выполнить программу) Вроде да.. А в жизни кто-то должен выглядывать в окно. Т.е. должно еще что-то произойти что б программа запустилась. И вот это что-то произошло. Что называть выполнением? Уборку снега или действия по обнаружению снега? В привычной архитектуре когда ты пишешь программу, интуитивно подразумевается что эта программа запустится и будет выполняться в том, порядке оператор за оператором в котором записана. А это не разумно хотя бы с точки зрения сохранения энергии. Вот в моей архитектуре не выполняются операторы как написано в тексте. Я даже программой это не могу назвать. Это скорее описание концептов (пусть объектов) и взаимодействия между ними. И процессор начинает работать с адресации (выглядывает в окно), анализирует события на которые есть подписка и потом осуществляет переход по истинности события, на которые (их может быть много) есть подписки. И все это параллельно! Фух, надо отдохнуть. По моему доступно описал работу процессора)) Вот получаем граф. Или нейронную сеть. Следующая порция позжее..
А это не разумно хотя бы с точки зрения сохранения энергии.
Хм. Почему не разумно?
Это скорее описание концептов (пусть объектов) и взаимодействия между ними
Ну, хорошо. Идею на "верхнем уровне" я понял. А реализация какова должна быть? Мы и сейчас точно так же можем делать, тоже на некотором уровне абстракций. Но такое поведение софта, видимое для прикладного программиста, складывается из крохотных последовательных операций на уровне процессора, которые сами по себе состоят из групп микроопераций, но уже внутри процессора. Естественно, можно такой "событийный" уровень перенести и из прикладного софта на уровень взаимодействия "процессор-ОС", но мы-то все равно никуда не денемся от атомарных микроопераций.
И все равно останется нерешённым вопрос, с которого вся эта ветка началась: зачем это надо? Вы от него всё убегаете и убегаете. Ответьте же наконец :) Пользователю от компьютера не нужны ни операторы, ни события, ни подписки. Ему нужно смотреть сайты, рисовать в Фотошопе/Иллюстраторе, создавать документы в Word/Excel, вести бухучёт в 1С:Бухгалтерии, играть в игры, трепаться в скайпе/вайбере/вацапе/телеге и т.д. Это в вашей системе предполагается? Там будет запускаться, например 1С:Бухгалтерия, мессенджер, совместимый со скайпом/вайбером/телеграмом и т.д.? Причём я неспроста указал эти программы поимённо - пользователям нужны не просто программы, а программы, совместимые с тем, что уже используется.
Мы и сейчас точно так же можем делать, тоже на некотором уровне абстракций.
Несомненно. Я уже говорил что даже реализовал на STM32
Естественно, можно такой "событийный" уровень перенести и из прикладного софта на уровень взаимодействия "процессор-ОС", но мы-то все равно никуда не денемся от атомарных микроопераций.
Конечно. Отличие только в том, что атомарные мирооперации можно распараллелить по нескольким шинам доступа и процессорам. Анализ на истинность событий и переход по подпискам можно выполнять тоже параллельно. При такой логике работы прерывания вообще не нужны, если есть свободная шина доступа и процессор, если есть необходимость в выполнении команд.
И все равно останется нерешённым вопрос, с которого вся эта ветка началась: зачем это надо?
Это только та часть что касается работы с устройствами, и отличие в логике работы. Ибо с этого начался разговор. Т.е. для работы в области автоматизации это реальная бомба. Работы с приложениями, файлами и редактор я только коснулся. Пока не готов обсуждать за подробности, ибо надо усвоить, еще некоторые нюансы работы, потом структуры концепта (важно), затем языка и потом будут понятны плюшки для обычного применения. Я просто скопирую итоговое курсивом.
Управление системой универсально и предлагает:
a.) Визуализацию. Легко визуализируется в виде текста, элементов управления, таблиц или в любом другом виде удобном для пользователя. Фактически браузер. С любым наполнением и «оживлением» в виде создания собственных событий и реакций.
b.) Добавление новых подписок изменяя функционал.
c.) Добавление новых классов концептов и концептов.
d.) Обеспечивает универсальный протокола обмена так как представляет собой обмен концептами, классы которых описаны в приемнике и передатчике (если описание класса отсутствует, то его можно запросить у передатчика), потому универсален и прост так, как структура каждой транзакции сформулирована в описании класса передаваемого концепта. По этой причине система легко интегрируется и фактически является распределенной. Причем распределенными автоматически являются и сервера и устройства управления и браузеры построенные на предлагаемых принципах. Облачный сервис предлагается как часть общего принципа работы системы.
e.) Универсальна структура документов, потому нет необходимости в расширениях файла. Обмен и загрузка данных (и визуальное представление) универсальны. Как и и процесс их редактирования, представляющих данные в различных видах представления. Одним из которых является текстовый и одновременно транслятор. Табличная форма получается автоматически как Exel, графика и прочее просто виды представления. По этой причине среда является одновременно и транслятором и редактором и браузером и сервером.
Конечно. Отличие только в том, что атомарные мирооперации можно распараллелить по нескольким шинам доступа и процессорам
А вот нельзя. Макрооперации - можно. Но чтобы их распараллеливать, должен быть какой-то планировщик, должны быть какие-то атрибуты у операций и так далее, т.е. как минимум, они не могут быть атомарными, ниже них должно быть что-то ещё. Собственно, как раз так оно и сейчас работает.
Пока не готов обсуждать за подробности, ибо надо усвоить, еще некоторые нюансы работы, потом структуры концепта (важно), затем языка и потом будут понятны плюшки для обычного применения.
Как по мне, вы зашли не с той стороны. Сначала надо определить плюшки для обычного применения, а потом под них подгонять ваш концепт, а не наоборот. Плюшки - первичны. Если их нет, идея не взлетит.
Добавление новых подписок, добавление новых классов/концептов, универсальные протоколы - всё это штуки, которые... по сути, не делают ничего. А значит, сами по себе не нужны. Вот вы пишите, например, "универсальная структура документов". Как это сделает мне удобнее/проще/понятнее набор текста или работу с электронными таблицами, чем сейчас?
А вот нельзя. Макрооперации - можно. Но чтобы их распараллеливать, должен быть какой-то планировщик, должны быть какие-то атрибуты у операций и так далее, т.е. как минимум, они не могут быть атомарными, ниже них должно быть что-то ещё.
Ты за классическую архитектуру. А в моей можно. Поговорить что считать атомарными. А зачем?
Поговорить что считать атомарными. А зачем?
Ну да, говорить тут особо не о чем. Это общеизвестное понятие, атомарный = неделимый.
Но так или иначе, я сильно сомневаюсь, что в вашей так можно, по крайней мере, в реальной реализации, а не на бумаге. Или оно не атомарное, или нельзя :)
И опять же таки, а есть ли смысл в такой гибкости? Какую проблему она решает, из тех, которые ещё не решены в современных процессорах? Они ведь тоже максимально параллельны, стараются утилизировать все доступные исполнительные блоки, насколько это возможно.
Извини, но мы разговариваем ни о чем. И ты критикуешь неизвестно что. Я говорю что можно. Ты говоришь что нельзя. Аргументом что все уже решено. Мне еще раз повторить что не решено? Еще раз повторить что это совсем другая архитектура?
Я критикую с позиции своего опыта. Понятное дело, что критиковать нечто, которое даже на словах толком не могут объяснить, не говоря уже про "продемонстрировать", затея так себе. Но я в чудеса уже давно не верю. Если существующая на словах идея кажется несостоятельной, значит, с вероятностью 99.999% так оно и есть. А то, что вам она кажется работающей, ну так все авторы любят свои детища :) Впрочем, меня-то переубедить несложно - просто покажите, как оно работает, раз как вы говорите, у вас там модели на STM32 имеются.
Вот в моей архитектуре не выполняются операторы как написано в тексте. Я даже программой это не могу назвать. Это скорее описание концептов (пусть объектов) и взаимодействия между ними. И процессор начинает работать с адресации (выглядывает в окно), анализирует события на которые есть подписка и потом осуществляет переход по истинности события, на которые (их может быть много) есть подписки. И все это параллельно!Похоже на описание функционального программирования «сверху вниз», где вместо описания последовательности действий используются условия. Что-то вроде такого:
1. Для того чтобы было чисто, надо чтобы на улице не было снега и пыли.
2а. Для того чтобы не было снега, надо посмотреть в окно — если снег есть, его нужно убрать.
2б. Для того чтобы не было пыли, надо выглянуть в окно — если пыль есть, ее нужно убрать.
3а. Чтобы убрать снег нужно взять лопату и убрать снег.
3б. Чтобы убрать пыль надо взять метлу и подмести.
и так далее.
В общем-то известный подход, с которым знаком любой программист (в makefile'ах такое используется).
Ориентация на событиях вместо опроса тоже широко распространена — прерывания, сигналы, сообщения.
Похоже на описание функционального программирования «сверху вниз», где вместо описания последовательности действий используются условия.
Ты имеешь в виду декларативное программирование. Частично похоже. Только не на функциональное а на логическое. Типа Пролога. Этому есть объяснение.
Ориентация на событиях вместо опроса тоже широко распространена — прерывания, сигналы, сообщения.
Реактивное программирование называется. В этой теме. Только значительно продвинутое.
Но слышал достаточно чтобы понять что ничего нового вы пока не описываете
Думаю недостаточно даже с ООП. Вот буква это объект или значение? ) Уверен, что не сможешь сформулировать.)
Насколько я помню, в хардкорном ООП объектом считается вообще все.
.
Но вы уходите от темы. Возможно, потому что недостаточно глубоко продумали свою архитектуру. А достаточно глубоко ее можно продумать только реализовав и описав хотя бы ее модель.
А достаточно глубоко ее можно продумать только реализовав и описав хотя бы ее модель.
Как бы я математик. Именно формализовано все. Причем базовых понятий всего 3. Правда, это не противоречит что надо думать еще глубже.
А что, объект у вас не может быть значением?
Строго говоря не может. Но, в слова и в понятия каждый может вкладывать свой смысл. У меня все строго. И все типы и события все формализовано. Кстати, что такое события?
А что, объект у вас не может быть значением?
Строго говоря не может.
class SomeClass{
SomeClass field;
};
SomeClass obj;
obj.field = obj;
в этом примере obj это объект или значение?
Объект. https://habr.com/ru/post/275599/
Можно, например, уйти от концепции крупных специализированных программ, разбить их на мелкие функции, которые между собой будут общаться по каким-то унифицированным протоколам (первое что пришло в голову).Кажется, вы изобрели UNIX и его конвейеры…
Ну, не совсем. Юникс и его конвейеры - это очень уж простая штука, основанная на механике 1970-х. И там нет никакого унифицированного протокола, просто одно приложение льёт свои результаты сплошняком в поток вывода, другое это подхватывает в поток ввода. Это хорошо работает, когда приложения не особо переборчивы во входных данных, всякие там grep или tar сожрут всё, что в них зальёшь. Но фигово работает, если входные данные надо всё-таки как-то парсить и по-умному на них реагировать, тут уж надо, чтобы оба приложения использовали согласованный протокол обмена.
И там нет никакого унифицированного протоколаВы можете придумать более унифицированный протокол, чем текст?! Его читают программы, его даже человек читает.
То, что такой способ неэффективен для всякой гуйни — другой вопрос. Собственно, иначе бы не придумывали всякие dbus'ы.
ls -la выводит содержимое каталога в разных форматах, и следующая программа в конвеере просто не может унифицированно выделить оттуда имя файла, размер.Какие-то подвижки есть в Microsoft Powershell, там в конвеере между программами передаётся поток объектов. Там
ls отдаёт список объектов — описаний файлов, и через методы/свойства этих объектов можно достать любые данные. Минус в том, что принимающая сторона должна знать тип объекта.Ну и сомнительно что писать утилиты для ps будет проще. Все-таки для текста функций полно, а вот для хитрых структур их нужно отдельно изучать. Плюс смотреть куда направлен выход — в конвейер или в терминал.
Хм. Лучше, чем в никсах? Могу, конечно. Сделать в 2021-м лучше, чем сделали в 1971-м, это не бог весть какое упражнение для программиста. Протокол подразумевает какое-то согласование структур данных, хороший протокол - контроль типов, очень хороший протокол - ещё и самоописание. То, что в никсах, это пригодно только для простейших кейсов.
Любое изменение выходных данных ломает входные. Обновление формата с сохранением совместимости невозможно. Поддержка нескольких форматов на входе - если возможно, то с костыльной логикой. И всё это лишь ради человекочитабельности? Ну, так себе. Кто может прочитать вывод ls, тот и JSON или XML прочитает без проблем.
Хм. Лучше, чем в никсах? Могу, конечно.Многие так говорят, вот только до сих пор никто не сделал.
Ну, то дело вкуса. Я, как уже писал, не вижу ничего интересного в механике взаимодействия нескольких дюжин утилит. Это всего лишь простейший способ решения простейших задач. Вот только мы давно уже эти самые простейшие задачи переросли. Как бы вы через unix-way организовывали бы редактирование насыщенного текстового документа с диаграммами, причём диаграммы редактируются в другом приложении? А между прочим, эту задачу пусть и изначально костыльно, но решили лет 30 назад.
А хотите, например, получать актуальные курсы акций в свою электронную таблицу? А хотя бы прогноз погоды на десктоп? Ну не решаются эти задачи тем же способом, которым grep вам строчки в файлах ищет :)
Можно и на старых процессорах сделать ОС как я говорил с поддержкой виртуальных машин дотнет и джава. Убрать 100500 слоев совместимости. Сделать встроенные контейнеры и вуаля - уже вполне рабочая ОС
А не вот это вот все - давайте сэмулируем винапи из 2000
Согласно полноты МТ можно и старых процессорах. Только какой смысл старое копировать. Есть новая парадигма. Прототип на STM32 сделали. Только команда по любому должна быть. Что б имело коммерческий смысл. Я не справлюсь. Работоспособность уже не та.
Мне кажется Вы практически описали Android, там вам и виртуальная машина, и контейнеры, и отсутствие классического подхода в написании приложений.
Я общался с ними лет 25 назад. Они там продавались, реорганизовывались. Еще Эльбрусами были. Насколько я понял они ориентировались на функциональную парадигму. Ну, тогда было сложно делать что-то свое. Времена были только от бандитов начали отходить. Ну, потом привязались к IBM. С их ассемблером даже.. Позже не знаю. Не общался.
а почему никто не вспоминает Дмитрия Завалишина с его Фантомом, вот действительно уникальня идея.. жаль, но кажись померла, ничего лет 100 уже о ней не слышно
ФантомОС был действительно интересным проектом. С уникальной базой. Но стоит отметить, что ДЗ не совсем ее с нуля писал. Насколько помню, он все же взял Линукс и весьма удачно натянул пингвина на глобус. Предположу, что проект остается интересным для академических кругов, но вот с монетизацией у него - слабовато.
- Сперва надо разработать бесконечно зацикленный командный интерфейс — то что по сути является ядром системы и позволяет переводить внешние команды в некое полезное вычисление на процессоре, через хранение данных в памяти и возвращать результат так же в памяти. (прерывания уровня ОС)
- Надо разработать модули ввода-вывода, которые будут взаимодействовать с этим ядром и обеспечивать API для подключения различных портов ввода-вывода в качестве источников данных для ядра и получателей результата (прерывания уровня пользователя)
- Надо разработать загрузчик, который считает всё это дело с диска, загрузит в память и запустит в работу, который по сути сам такая себе мини ОС и должен быть вшит в оборудование в какую нибудь микруху (базовая система ввода вывода) который в зависимости от задач сможет запускать Вашу ОС с диска, или из сети
- имея сие API начинать допиливать модули под всё что должна уметь Ваша ОС поддерживать, начиная с драйверов разных железок (обнаружение что подключена, назначение прерываний, или получение данных об имеющихся аппаратных прерываниях, назначение, или дискавери портов ввода-вывода) и заканчивая интерфейсом пользователя
- На каждом шаге надо тщательно взвешивать и продумывать все при все пути обеспечения безопасности системы, проводить постоянные пентесты, дебажиться аки Боженька, отвечая на сакральные вопросы, «что сожрало память?», «почему цикл не кончается», «всё работает вроде, но пачему результат совсем не тот что ожидалось?» и тд
В целом то, при знаниях (именно при понимании) ассемблера и архитектуры оборудования, дурное дело не хитрое, однако какие цели сей заморочки — вот это реально важный вопрос.
Если кому то понадобилось написать свою ОС, значит (если не считать случаи чисто for fun) чем то не устраивают имеющиеся проверенные временем решения? Давайте попробуем их перечислить:
- А вот мы придумали оборудование с троичной/четверичной/квантовой/… логикой в основе и туда ниче из имеющегося не втыкается
- Патриотическая мотивация, звучит примерно так: А че это англицкий алфавит в основе? давайте сделаем систему в которой будет свой аналог ASCII и в первой половине кодовой таблицы будет безоговорочно властвовать кирилица! (не удивляйтесь — я такое рвение несколько раз встречал)
- Не всё прям при всё виртуализовано — надо что бы не java в ОС была, а ОС как java (отсылка к одному из каментов здесь, а так то такие ОС есть на самом то деле, symbian например:) )
- Ваш вариант
Мне кажется из всех этих мотивов только у первого есть реальное обоснование зачем это нужно и если Вы задумали озадачить себя таким вопросом, но у Вас любой другой вариант, кроме первого, мой Вам совет, забудьте об этой затее и возьмите Linux from scratch, а ещё лучше Gentoo и на этом замечательном базисе создавайте своё решение.
Насколько сложно написать свою операционную систему?