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_
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.