Цитата:
Лично я вижу обьяснение даже fork()/exec(), не то что более адекватным вещам
Если вы умудрились подогнать объяснение под абсолютную кривоту и идиотизм в виде fork, это не делает fork разумным решением. Также как некоторые другие решения Unix.
[offtop]Как-то читал доку по LDM и немного офигел - так красочно описывать дебаг-возможности их системы ввода-вывода, всю эту драйверФС, а когда дошло до сути системы IO написать только одно предложение - "Когда приложение вызывает функцию IO, система просто вызывает соответствующий колбек драйвера". Тихонько задал себе вопрос - "и чего там тогда дебажить?"[/offtop]
Цитата:
Мы не собираемся претендовать на совместимость с чем-либо.
Юниксоиды сейчас имеют смысл исключительно из-за совместимости. Если выкинуть из него совместимость, у вас останется совершенно бесполезный, нелогичный, медленный и кривой блок полусвободного кода, не нужный абсолютно никому.
Да и адекватность с т.н. "KISS" частенько расходятся. Примером может послужить тот оффтоп, что я написал выше. Да, сделали самое простое, только из-за этого получилось убожество.
Что касается си - язык как язык. Кривой, как и юникс, со своими недоработками, но писать на нем околосистемные вещи вполне можно. Для этого правда приходится поставить самому себе ограничения, взять за правило никогда не использовать потенциально двусмысленные конструкции (коих там хватает) и не пользоваться N-ным количеством его "фишек". Другое дело, что си расслабляет, и начинаешь грабастать память метрами и такты миллиардами просто потому, что лень немного подумать.
Цитата:
вы предлагаете пользоваться ассемблером лишь потому что он сложен
SII не писал, что ассемблер сложен. Скажу из своего опыта написания под разные архитектуры и реверса программ - ассемблер элементарен. Это самый простой язык из всего, что только можно придумать. Это написание буквальных распоряжений процессору. Только вот много памяти программиста отнимает. Зная один ассемблер, можно без проблем быстро понять любой другой - я учился на х86, потом AVR а далее за пару месяцев научился читать программы на ассемблере ARM, байт-кодах JAVA, Dalvik, .NET.
Непонимание ассемблера говорит о плохом понимании работы процессора. Любого. Это приводит к тому, что можно начать плавать в абстракциях и далеко уйти в своих мечтаниях, не понимая, СКОЛЬКО совершенно бесполезной работы придется выполнить процессору ради выполнения нескольких строк вашего кода и на сколько упадет производительность из-за небольшого недосмотра.
[offtop]В итоге вместо качественной и быстрой ОС может получиться обсасывание человечных идей на околочеловечном языке, с попыткой заставить процессор эти идеи выполнять. Но процессор не с проста называют камнем - это ведь действительно
камень. И он никогда не поймет ваших
++*++p++ идей, если эта идея будет какой-то облачной мечтой про Dao (путь) и "адекватность", если ее не перевести буквально в набор команд, которые этот камень знает.[/offtop]
Ассемблер не сложен, но он громоздок. Писать на нем гигантские программы или высокоуровневую логику - гиблое дело, руки отвалятся. Но когда речь идет о ядре ОС, где основная работа - отдача прямых команд процессору и оборудованию, не разумно использовать высокоуровневый язык с пачкой костылей в придачу, вместо использования языка, сделанного именно для этого.
Что касается концепта - конечно, идея про путь и адекватность звучит красиво, но хотелось бы увидеть что-то осмысленное. Как, где и кем она может применяться, почему она будет интересна, в чем конкретно будут заключаться эти самые адекватность и путь. Как она будет работать, взаимодействовать с железяками и т.д. А то пока что получается примерно так:
- берем исходники UNIX;
- находим блоки кода про POSIX;
- вырезаем;
- получаем ODEANIX.
(т.к. в юниксе и так N-ное количество вещей сделаны по принципу "первое, что пришло в голову", он же "KISS")