LINUX.ORG.RU
решено ФорумTalks

Какую ОС стоит писать в 2022-м году?

 


0

1

Не ради результата, но ради процесса хочу поизучать вопрос создания новой ОС.

В первую очередь хотелось бы обсудить вопрос об архитектуре процессора под которую писать. Я почти уже было решил, что ARM явно побеждает в этой борьбе - все мобильные устройства ARM, и рабочие станции на ARM подтягиваются. Но Raspberry PI как-то внезапно исчез из магазинов (хотя вроде новостей об уходе с российского рынка нет), да и Байкалу своих процессоров теперь не видать как своих ушей. А писать чисто под эмулятор совсем уж странное удовольствие.

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

Мне приходит в голову в первую очередь персистентная память (как заявлено у ОС Фантом), но я хочу пойти дальше - чтобы любое приложение могло легко переносится между устройствами прямо на лету и использовать ресурсы сразу нескольких устройств находящихся в сети.

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

Ещё идеи?

★★★★★

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

много денег и доступ ко всем рынкам

vaddd ★☆
()

Не ради результата, но ради процесса хочу поизучать вопрос создания новой ОС.

Один уже затевал такое. :) И вот результат на лице, мы собрались на этом сайте :)

anc ★★★★★
()

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

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

Я бы скорее предложил смотреть в сторону фич связанных с безопасностью/формальной верификации. У мелкомягких было несколько проектов на эту тему:

https://en.wikipedia.org/wiki/Midori_(operating_system)

https://en.wikipedia.org/wiki/Verve_(operating_system)

И нет, суть этих проектов вовсе не в том, чтобы писать всё на C#, там уклон именно на совершенно другой подход к безопасности (а также производительности). Я, конечно, дилетант в этом вопросе, но, насколько понимаю, тот же Midori потенциально позволил бы организовывать защиту от всяких Spectre/Meltdown банально подкручивая транслятор IL в ASM, не дожидаясь патчей к микрокоду. И, возможно, с меньшими потерями в производительности.

runtime ★★★★
()

Мне приходит в голову в первую очередь персистентная память (как заявлено у ОС Фантом), но я хочу пойти дальше - чтобы любое приложение могло легко переносится между устройствами прямо на лету и использовать ресурсы сразу нескольких устройств находящихся в сети.

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

Можно прикрутить к существующим ос

goingUp ★★★★★
()

думаю для абака

На тренировку самое то

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 2)

Начни с разработки своего загрузчика вместо использования готового. На пол пути надоест и ты забросишь это дело. Тру штори.

ox55ff ★★★★★
()

Начни с маленькой встраиваемой.

aiqu6Ait ★★★★
()

Под ту, которая готова для гетерогенных ядер и множества узкоспециализированных хардварных вычислителей.

pon4ik ★★★★★
()

Архитектура — чем больше поддерживать, тем лучше. Но для начала ARM.

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

И чтоб архитектура была не важна. Чтобы перед переносом на другое устройство (в том числе во время работы) происходила трансляция программы под другую систему команд и её памяти (порядок байтов в слове, организация памяти). И многопоточные приложения могли работать на разных архитектурах одновременно нативно (т.е. никаких байткодов или интерпретаторов).

А ещё возможность исполнения некоторого кода или программ целиком (изначально так их оптимизировать) на процессорах без MMU.

Со всем этим будет совсем пушка.

Slavik763
()

Ещё идеи?

Найди нормальную работу, устрой личную жизнь. Или лучше вместо этого запилить очередной велосипед?

baobab
()
Ответ на: комментарий от ox55ff

Сначала надо разработать свой язык программирования. А то что за ОС без специально сделанного для неё языка?

rupert ★★★★★
()

Напиши ОС под Эльбрус с учётом тегирования. Актуальнее некуда.

А может ещё медаль ударника труда дадут! И пенсию.

Я серьёзно.

vasya_pupkin ★★★★★
()
Последнее исправление: vasya_pupkin (всего исправлений: 2)

В первую очередь хотелось бы обсудить вопрос об архитектуре процессора под которую писать.

RISC-V. Как раз, пока пилишь, уже будет всё завалено ими.

th3m3 ★★★★★
()

Максимально совместимую с существующими популярными OS на уровне драйверов. Без поддержки максимального количества железа новая ОС - не нужна.

eternal_sorrow ★★★★★
()
Последнее исправление: eternal_sorrow (всего исправлений: 1)
Ответ на: комментарий от anc

Один уже затевал такое. :) И вот результат на лице, мы собрались на этом сайте :)

неправда, я здесь вовсе не из-за дениса!

crypt ★★★★★
()
Ответ на: комментарий от baobab

Найди нормальную работу, устрой личную жизнь. Или лучше вместо этого запилить очередной велосипед?

Так одно другому не мешает.. Разве нет?

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от rupert

Сначала надо разработать свой язык программирования. А то что за ОС без специально сделанного для неё языка?

Это в планах есть кстати.

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от Slavik763

Это сильно, согласен.. Осталось придумать как реализовать :-)

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от ox55ff

Да я и не питаю особо иллюзий, но из депрессии пора выбираться и надо что-то делать..

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от hhhhacker

Что Эльбрус, что Байкал остались теперь без процессоров. Не понятно что с ними будет в перспективе.

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от runtime

Не, я понимаю предусматривать портирование существующего ПО в новую ОС, но об обратном же обычно не заботятся..

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от chenbr0

Не знал про ТемплОС. Реально крутая вещь, спасибо.

unDEFER ★★★★★
() автор топика

Потом хотелось бы упразднить файловую систему как таковую.

Лавры PalmOS спать не дают?

tiinn ★★★★★
()
Ответ на: комментарий от ox55ff

Начни с разработки своего загрузчика вместо использования готового. На пол пути надоест

Пусть пишет под BIOS, в реальном режиме. Там всё элементарно: 512-байтный загрузчик для загрузочного сектора, который грузит что-то более продвинутое, а более продвинутое может уже делать всё, что угодно. Все нужные функции: вывод текста, примитивной графики, есть в BIOS, на худой конец в VESA BIOS, а к винту, опять же, можно напрямую обращаться.

tiinn ★★★★★
()
Ответ на: комментарий от anc

It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks

Собственно, вот рецепт успеха.

sislochka
()
Ответ на: комментарий от baobab

Я знаю о чём вы говорите, но пока работа и семья позволяют мне иметь 2-4 часа свободного времени. Буду его утилизировать.

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от unDEFER

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

vaddd ★☆
()
Ответ на: комментарий от vaddd

А есть истории успеха в подобном повороте деятельности?

Успеха в том смысле чтобы действительно переключиться на семью, получать от этого удовольствие и не испытывать фрустрации по поводу того что не делаешь ничего «полезного»?

unDEFER ★★★★★
() автор топика
Ответ на: комментарий от unDEFER

Не, я понимаю предусматривать портирование существующего ПО в новую ОС, но об обратном же обычно не заботятся..

Мелкософт тоже не заботился, разрабатывая первые версии .NET и намертво прибивая его гвоздями к Windows. А потом оказалось, что надо делать Silverlight и запускать его в песочнице, в том числе и на Mac. А потом оказалось, что рынок мобильных ОС они просрали и надо делать Xamarin и запускать его на Android/iOS. А потом оказалось, что Docker это теперь стильно, модно и молодёжно, и надо как-то софт, написанный на .NET, паковать в контейнеры, при этом не запихивая внутрь десятки гигабайт вендозовых компонентов. А потом выяснилось, что много кто нынче в принципе работает на Mac, и им надо там как-то продавать свой собственный софт, написанный на .NET. А потом оказалось, что нужно делать Blazor, и запускать .NET через WebAssembly. И много чего ещё оказалось. В итоге они переписали .NET, так как поняли, что привязывать разработчиков только к одной платформе это значил стрелять себе в ногу.

runtime ★★★★
()
Ответ на: комментарий от unDEFER

Успеха в том смысле чтобы действительно переключиться на семью, получать от этого удовольствие и не испытывать фрустрации по поводу того что не делаешь ничего «полезного»?

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

vaddd ★☆
()
Ответ на: комментарий от vaddd

Я попробую. Спасибо, добрый человек.

unDEFER ★★★★★
() автор топика

Чтобы там были файлы и папки, поддержка длинных имён, и атрибутов. Многозадачную, многопользовательскую, с разограничением прав доступа. Если сможешь низкую латентность, жёсткий реалтайм и микроядерность - будет круто.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от unDEFER

А что там в PalmOS с ФС? Я не в курсе.

Её там не было :)

tiinn ★★★★★
()

Для учебных целей подходит любой ЦПУ любого доступного тебе устройства.

sparkie ★★★★★
()
Ответ на: комментарий от cvs-255

что-то эти эльбрусы так и не продают обычным людям

так ведь продавали, бракованные на сувениры

vaddd ★☆
()

Любую.

2012: Линус Торвальдс выразил опасения в связи со стремительным усложнением ядра Linux

Mirage1_
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.