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

Ядро может быть harmful

тогда МК61 и мк36

квантовые комплюхтеры будущее?если да, то смысла под текущие архитектуры нет. Лучше наверно заплатки делать для существующих ОС

Ядро может быть harmful

Вредным?

квантовые комплюхтеры будущее?

Профессор Ожигов на ВМК уже лет 15 пробует реализовать функцию извлечения квадратного корня на оптических процессорах. А ты - про квантовые...

работа и семья позволяют мне иметь 2-4 часа свободного времени.

Это в неделю?
Если в сутки, то ты счастливчик.

По существу. ОС — конечно, пиши, не слушай насмешников. К конкретным архитектурам не прибивайся, одна Колибри у нас уже есть, пусть твоя будет максимально переносимой.

Вои идея отказа от ФС меня как-то не особо вдохновляет…

Увольняешься и чилишь. Я так 2 года отдыхал. Самые лучшие года в моей жизни. Потом деньги начали заканчиваться.

Да, счастливчик, с работой повезло, тут не жалуюсь. Правда в связи с этими санкциями всё может измениться.

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

Вои идея отказа от ФС меня как-то не особо вдохновляет…

А зачем она нужна по существу? Задача сериализации - настолько бестолкова, но её приходится делать, а потом ещё и обратно десериализовать. И всё из-за того что кто-то придумал что всё должно храниться в плоских файлах. Но почему бы не рассматривать жёсткий диск просто как персистентное хранилище, точно такое же как оперативку, где всё хранится объектами, но персистентное?

А, и это… тут выше предлагали присоединиться к разработке Hurd — хороший вариант, на мой взгляд. Мне кажется, Linux нуждается в микроядерном конкуренте с похожей лицензией.

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

Я давно пишу, что основная проблема современных компов — это железо, а не ОС. Это замкнутый цикл: ОС пишут на Си, железо оптимизируют под Си, ОС продолжают писать на Си, и по итогу мы имеем уязвимые падающие ОС ориентированные на одноядерное выполнение, даже если это SMP система — на текущий момент из мейнстрима только Linux претендует на более-менее эффективную реализацию многоядерности, у остальных блокировки в ядре на спинлоках. Про кооперативность лучше и не вспоминать, она не поддерживается вообще ни одной осью, из-за чего все серваки стараются выполнять воркеров не больше, чем ядер в системе. А из оков Си ты не вырвешься, потому что только он позволяет эфективно использовать железо — замкнутый круг, как я уже написал.

Почему однозадачность не прокатывает в 2022? Она уже в 2010 не прокатывала, с тех пор ЦП во сколько раз ускорились? В 2 раза? Закон Мура, ага. Современные ЦП чудовищно неэффективны, единственный способ сделать их эффективными — это утилизировать больше ядер. Это и только это является настоящей причиной эпидемии машинного обучения и микросервисов — сами по себе эти технологии убоги.

Для затравки по направлениям развития возьмем проблему переключений контекстов. L4 уже в конце девяностых была реализована, она сделала полшага в правильном направлении, а именно — не переключать контекст. Разделяемая память, турбореактивные межпроцессовые вызовы. Почему всё встало? По той же причине, что никак не развивается GNU Hurd — писать реализацию такой оси на сишке очень, очень тяжело, долго, а результат безбожно глючит. Нужен ЯП, на котором кооперативную многозадачность можно было бы писать так же легко, как hello world на сишке — последнее, между прочим, является ни разу не простой программой, там куча ввода-вывода с осью, и даже есть кэширование.

Но в рамках классических процессоров ты просто не сможешь создать достаточно эффективного ЯП в такой парадигме. Вся проблема из-за того, что основной интерфейс межъядерного взаимодейтсвия (подчеркиваю, интерфейс, аппаратная реализация там другая) — это разделяемая память. Что подразумевает lock-free алгоритмы, а значит недетерминированность, из которой очень тяжело вылазить, а еще сложнее потом дать гарантии, что выполнение не сваливатся обратно в недетерминированность при неожиданных параметрах. Я писал об этом в статье: https://habr.com/post/587750/

Хорошее решение должно решить фундаментальный изъян процессоров, который на самом деле вызван совместимостью с совместимостью — так уж получилось, что IT является инертной индустрией и не приемлит нововведений. Потому индустрия работает на железе минимум 20-летней древности и софте минимум 10-летней давности — просто потому, что разработать и изготовить процессор сложнее, чем софт.

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

Хе-хе, я не видел этого сообщения. Но писал так, будто видел.

А зацените кто-нибудь идею.

Как насчёт системы код которой можно было бы редактировать на лету? Т.е. можно открыть любой процесс, увидеть его код и редактирование его запускает автоматический процесс «патченья» его в памяти, в том числе редактирование всех объектов.

Более того редактировать можно только код непосредственно перед его исполнением. Если создаёшь ветвление, то поток входит в одну из веток и ты пишешь код там. Нужно написать другую ветку? Жди данных которые введут поток в эту ветку или создай их. В конце каждой недописанной ветки стоит команда «стоп», которая переводит поток в режим ожидания редактирования кода. Как результат получаем код который гарантированно был запущен хотя бы однажды. Т.е. 100% покрытие кода тестированием.

Мешает. Вот представь себе что я теперь с 8 до 18 работаю фултайм и хожу на работу ножками (а ещё денег мало платят, но выбирать не приходится, тем более есть перспективы года на 3 в текущей ситуации хорошие). Куда мне ещё код писать в оставшееся время? По 15 минут перед сном? Спасает что личной жизни нет, да и не планируется.

Да это я понимаю. Имел такую работу, и хотя там было супер, с радостью согласился на текущее предложение с 6-тичасовым рабочим днём.

bolgenOS