Адреса! Запутался!

можно попытаться разобраться, в чем причина
не все ошибки фатальны и требуют остановки системы

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

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

1. здесь можно много и долго спорить о преимуществах и недостатках микроядерных и немикроядерных архитектур
2. вы всерьез считаете, что на ассемблере можно написать микроядро за несколько недель?
не буду дальше спорить, я просто не согласен

версия 2.6.17
не скажу точно, когда был релиз, но не так давно

для меня лично это не так
хотя ассемблер я знаю на должном уровне
мое мнения, высокоуровневые абстракции проще модифицировать и проще в них разобраться
короче, у вас свое имхо, у меня свое

мы говорим про IA-32

нам то всего-навсего нужно перехватить модификацию кода записью инструкции SIDT
для того, чтобы избежать этого

 

rei3er

Но это может установить только человек, который разберётся в причинах ошибки. Сама система судить о фатальности не в состоянии, а продолжать работу после возникновения сбоя в модуле ядра чревато ещё большими проблемами, чем если сразу выдать BSOD (или рестарт системы).

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

Абсолютно согласен. Но у асма здесь есть одно существенное достоинство: он поднимает "порог вхождения". На Си кодировать, пускай и криво, сможет и обезьяна, на асме -- уже нет. Уже по одной этой причине уровень среднестатистического программиста, постоянно пишущего на асме, будет выше, чем такого же среднестатистического, работающего на ЯВУ.

Ага, только представьте, сколько этих предупреждений будет в программе в десятки тысяч строк. Вот и получается, что необходимо вручную приводить все типы, кроме самым что ни на есть явных преобразований (грубо говоря, байт можно вручную в слово не приводить -- эта операция безопасна, но вот наоборот -- обязательно вручную, иначе компилятор обязан ругнуться, а в потоке ругани легко утонуть). Кроме того, в Си из-за отсутствия нормального контроля типов есть целый ряд потенциальных возможностей для ошибок, которые никак отловить невозможно. Простейший пример:

Код (Text):

1. a = b = c;
2. a = b == c;

Синтаксически обе конструкции абсолютно корректны, и компилятор скромно промолчит, встретив их. Однако что будет, если программист ошибся (ну или просто клава сбойнула) и вместо одного = поставил два или наоборот?

Насчёт возможности сделать абсолютно безопасным 10 строк кода на ЛЮБОМ сколько-нибудь вменяемом языке -- согласен. А вот насчёт пропорционального роста -- нет. Знаете метод "разделяй и властвуй"? Если грамотно делить программу на модули, а модули -- на подпрограммы, сложность взаимосвязей будет расти намного медленнее, чем объём исходного текста. Собственно, этому должно и ООП способствовать (а что на практике часто получается наоборот, так это уже не вина ООП).

Стопудово. Поэтому лучше спорить не здесь

Микроядро -- за несколько дней или даже часов в зависимости от степени "микроядерности". Полноценное монолитное ядро -- за несколько недель. Но, напоминаю, при двух условиях: а) уже есть проект системы (определены архитектура, системные вызовы, алгоритмы работы различных компонентов и т.п. вещи); б) ввод-вывод сюда не входит (потому что там море заморочек с аппаратурой, на борьбу с которыми времени уйдёт больше, чем на всё остальное, вместе взятое), т.е. в ядре реализована лишь базовая поддержка соответствующих функций, но никакой конкретики, связанной с конфигурированием и работой с устройствами, там нет.

Тогда два вопроса. а) Что за функции были добавлены? б) Когда до этого последний раз что-то подобное добавлялось и, если возможно, что именно? (Я не линуксоид, поэтому самому искать ответы влом)

Ну, что ассемблер знаете не ниже, чем на 4, я уже убедился. А на 5 -- дистанционно оценить проблематично, но вполне возможно, что так и есть

А что до высокоуровневых абстракций, то я тоже согласен, но с одной поправкой: в ОС-то обычно они очень даже не высокоуровневые (на то она и ОС). Объявить процесс и поток абстрактными классами вполне можно, только вот придётся обслуживать эти абстракции на уровне "абстракций", с которыми процессор работает -- т.е. с битами, байтами, адресами и прочей низменной материей. Никакого, понимаешь, тебе полёта духа

Ну а если серьёзно, использование высокоуровневых и даже "среднеуровневых" конструкциях на системых задачах зачастую вредно для системы и ничего не даёт для улучшения качества кода. Например, практически в каждой структуре данных (блоке управления процессом, потоком и т.д. и т.п.) имеется куча логических значений. В ЯВУ для этого обычно используется либо тип Boolean (где он есть), либо, например, Byte или вообще Integer, хотя реально достаточно одного бита. В результате -- большой расход памяти впустую, что приводит не только к повышению потребностей в ОЗУ (с нынешними объёмами это не критично), но и к снижению скорости работы (кэш забит нулями, грубо говоря, и приходится постоянно гонять данные между ним и ОЗУ). Понятное дело, что это отнюдь не неизбежное зло ЯВУ, это лишь пример того, как "поднятие на уровень вверх" автоматически приводит к ухудшению качества программы.

Угу, ну а трассируя всё время, мы в несколько раз снижаем скорость работы программы. В то время как без трассировки, путём реального выполнения на реальном железе, скорость была бы близка к таковой на настоящем компьютере, а не на виртуальной машине.

 

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

фигово будет (потом)
ну и в ассемблере можно случайно вместо jz написать jnz
еще неизвестно, где (в коде С или на ассемблере) потом проще будет отыскать ошибку

splice, tee, vmsplice

splice - moves data between two file descriptors without copying between kernel address space and user address space.

tee - duplicates up to len bytes of data from the pipe referred to by the file descriptor fd_in to the pipe
referred to by the file descriptor fd_out.

vmsplice - maps nr_segs ranges of user memory described by iov into a pipe.

это только те, про которые я точно знаю

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

вы не правы
в большинстве случаев используются битовые маски для хранения различных флагов
один int = 32 флага

правильное использование С в купе с возможностями современных оптимизаторов в компиляторах не намного ухудшают качество кода
а читаемость, модифицируемость и переносимость только возрастают
опять же имхо

 

rei3er

Наивный чукотский юноша (с)

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

На самом-то деле проблема с квалификацией кодировщиков была уже давно. Например, над OS/360 трудилось несколько тысяч человек, и анализ её кода показывает, что квалификация порой различалась очень существенно (есть превосходно написанные модули, где ни добавить, ни убавить, а есть полный отстой). Это, естественно, сказалось и на общем качестве системы: после RSX-11 я долго называл различными последними словами OS/360, которая умудрялась вешаться иногда по нескольку раз в день, и это при выполнении совершенно безобидных задач вроде расчёта зарплаты. Правда, после знакомства с первыми мелкомягкими осями я понял, что OS/360 -- очень даже ничего себе по надёжности

Насчёт случайно jz вместо jnz -- согласен. Однако вероятность, ИМХО, меньше, поскольку исключено случайное двойное нажатие одной и той же клавиши, как в случае с = (а также + и -).

Но сравнивать прямо ЯВУ с асмом не совсем корректно. Уместнее было бы сравнить в этом плане Си с Паскалем или Адой -- тогда сравнение будет и вовсе разгромным. Думаю, не надо доказывать, что в Паскале целый ряд ошибок, вполне возможных в Си, невозможен в принципе, и при этом нет других возможностей, отсутствующих в Си? Недаром Пентагон Аду разработал, причём на основе Паскаля: всё ж не все военные -- дубы

Странные какие-то функции, или я чего-то не понимаю. Зачем они нужны? Какую реальную выгоду дают? Почему они должны быть реализованы в ядре?

Нет, я прекрасно понимаю, что если надо переслать данные из области A в область B, то желательно это сделать напрямую, а не использовать промежуточную область C. Но я не понимаю, что такое пересылка данных между двумя файловыми дескрипторами. Это то же, что между двумя файлами, т.е. просто копирование файлов? Если да, то это вообще не задача ядра, это задача соответствующих обслуживающих программ (команда cp вроде как в линухе?), сводящаяся к повторению в цикле двух системных вызовов: прочитать блок данных -- записать блок данных (естественно, нормальная система при этом будет выполнять операции ввода-вывода прямо с указанными буферами, а не использовать промежуточный буфер). Или же речь идёт о копировании управляющей информации между структурами данных, описывающими дескрипторы? Тогда мне остаётся удивляться, что раньше в линухе это реализовывалось через промежуточный буфер в ядре.

Всё это я говорю не к тому, чтобы доказать, что Линух или там Винда -- полный масдай, а к тому, что дополнения, особенно серьёзные, в ядре любой системы нередко связаны с тем, что разработчики ОС первоначально либо на что-то не рассчитывали вообще (например, на многопроцессорность), либо игнорировали или попросту были не знакомы с предыдущим опытом, а поэтому заново вынуждены были изобретать велосипед. Вспомните, например, рекламную шумиху, связанную с появлением многоядерных процессоров: типа, революция, новая эра начинается... А ведь абсолютно ничего нового придумано не было: многопроцессорные машины точно уже существовали в 1960-х (насчёт 1950-х не уверен), и связанные с параллельным программированием проблемы к нашему времени были прекрасно известны и неоднократно успешно решались. Однако, насколько знаю, в ядро Линух пришлось вносить чуть ли не кардинальные переделки, чтобы оно достаточно эффективно заработало на многопроцессорных машинах (только не знаю, делали это лишь после выхода многоядерников или раньше -- подозреваю, что второе, потому что многопроцессорные серверы уже давно используются). О чём это говорит? Да о том, что создатели ядра Линуха просто не думали, что эта система будет использоваться для серьёзных задач, а потому и не задумывались о поддержке многопроцессорности (что и неудивительно: г-н Торвальдс, насколько знаю, систему "для себя" делал, никак не ожидая её громадной популярности в дальнейшем, поэтому в вину поставить это ему нельзя).

Бывают, конечно, и исключения. Так, появление PNP заставило разработчиков осей озаботиться динамическим обнаружением и конфигурированием устройств -- а это, естественно, потребовало внесения определённых изменений в ОС. Однако можно заметить, что эти изменения никоим образом не затрагивали управление процессами, потоками и синхронизацию и лишь частично -- управление памятью (фактически необходимо было уметь изменять объём доступной для системы физической памяти -- на случай горячего подключения и отключения модулей ОЗУ).

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

Я прав :-P Я был бы не прав, если б стал утверждать, что в программе такой-то делается так-то, а там это на самом деле делается вовсе не так.

Я вполне допускаю, что в Линухе логические данные действительно представлены битами: в конце концов, эту систему не полные кретины писали. Однако практика использования под хранение логических величин целых переменных на Си или логических -- в Паскале (в Дельфи занимают байт, хотя язык это никак не ограничивает: просто Дельфи -- неэффективный компилятор, к моему глубокому сожалению) очень широко распространена. Сам видел некую структуру данных (в какой-то прикладной программе) длиной сотни в три байт, из которых 80% занимали такие логические переменные, причём четырёхбайтовые (гениТальный автор использовал тип int). Причём эта структура являлась записью базы данных, и этих записей были миллионы. Какая скорость работы была, сами понимаете. Думаю, простой перевод логических данных из int в биты позволил бы поднять скорость сильней, чем перевод подобной базы с MS Access на Oracle

Но есть тут и вторая сторона. Для ассемблера манипуляции с битами -- родная стихия, для ЯВУ -- нет, даже если в языке и присутствуют все необходимые операции. Пара команд BT - JC сразу говорит, что программист хочет сделать, а вот if ((a && 0x...) != 0) -- не сразу. Читабельность сишного текста окажется всё же меньше. Вот какой-нить a = sqrt(sin(b) + cos(d)) -- другое дело. На асме программа будет не очень вразумительная даже в том случае, если все необходимые операции реализуются прямо соответствующими ассемблерными командами (ну а если подпрограммами, то ещё хуже).

В некоторых случаях качество оказывается многократно хуже ручного, но в целом согласен. Более того, вручную оптимизировать большую программу очень сложно и вряд ли выгодно, хотя при наличии большого опыта программирования на ассемблере эффективная программа будет получаться "сама собой" по вполне понятным причинам Тем не менее, зарплату надо писать на ЯВУ (хотя видал я творение извращенцев в этой области, написанное на ассемблере).

Если речь о Паскале и асме -- соглашусь. Если о Си и асме -- нет. Точней, очень сильно будет зависеть от стиля программирования (в Паскале тоже, но в меньшей степени, поскольку сам язык имеет более внятный синтаксис и не допускает кучи вольностей типа извращённых операторов for, которые даже с поллитрой не поймёшь). Есно, тоже имхо


Пы.Сы. Ну и зафлудили же мы тему, однако )))

 

еще раз говорю, человек - не машина
ошибки бывают всегда
и чем важнее софт - тем они становятся более вопиющими и фатальными

а на монитор уже совсем смотреть не надо?

да
но почему то паскалеобразны языки меньше востребованы в системном ПО
парадокс?

может быть и копирование, и перемещение
splice только лишь в частном случае можно реализовать через read/write
(менее эффективно за счет 2-х обращений к ядру + см. ниже)
если же файловые дескрипторы представлены каналами, без splice достичь требуемой функциональности невозможно
это раз
во-вторых, в Linux есть такое понятие как кэш физических страниц памяти (структура address_space) для открываемых файлов
так вот, splice для перемещения работает не по принципу копирования в промежуточную область
он манипулирует с физическими страницами кэша файла
т. е грубо говоря перемещает элементы (страницы) одного объекта address_space в другой и наоборот
эффективность в разы выше

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

в ядрах 2.0.* (1996+ года) появилась поддержка SMP, правда не очень эффективная (до 2.6.*)

любой серьезный менеджер памяти должен априорно поддерживать возможность выделять N-ое количество страниц физической памяти
имхо

согласен
в Linux, к примеру (для x86-64), всего лишь 279 системных вызовов
остальное - пользовательский уровень
unix-way в этом плане вам должен быть по душе

имелось в виду if (a & 0x...)?
по мне так одинаково
первый вариант - для тех кто знаком с ассемблером (хотя BT я бы применял только если номер бита не константа)
но они не могут не знать про применение масок, поэтому не думаю, что им будет не очевидна эта конструкция

эээ
вы еще флуда не видели
здесь вполне конструктивный разговор, правда отошедший от изначальной темы топика

 

rei3er

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

Глаз замыливается. Можно и проглядеть. Тем более что конструкция допустимая...

Уних и Си оказались универам доступны на хавляву, да ещё в исходниках, да ещё на каком-никаком, но ЯВУ, в то время как подавляющая масса осей были платными и в исходниках не предоставлялись. ИМХО, вот и причина, почему Уних сильно распространился в университетской среде. Ну а дальше всё просто: к чему ты привык в универе, то ты пытаешься использовать и на практике. В начале 1980-х это было проблематично (машины были слишком маломощными, чтобы нормально тянуть тяжеловесный Уних), но затем "процесс пошёл". Что же касается Паскаля, то у него была ещё и репутация "учебного языка", ну а Си... Никогда не слышали мнение "Если ты пишешь не на Си, то ты -- не профессионал"? Я неоднократно с таким отношением к Паскалю сталкивался. Но если лично мне на мнение других о моём профессионализме глубоко плевать, то это не означает, что и всем остальным -- тоже. Вот и получается, что паскалеподобные языки используются только там, где начальство велит, а для этого само начальство должно понимать, зачем и почему ему это нужно. Вот, к примеру, на последнем "общеевропейском" (а на деле -- англо-германо-испано-итальянском) истребителе EF2000 ПО написано на Аде (встречалась инфа, что более миллиона строк), а на шведском "Грипене" -- на Паскале. Если покопаться, то окажется, что и в других военных системах эти языки употребляются отнюдь не редко. Вероятно, как раз потому, что военным надо, чтобы бортовые системы работали нормально, а не БСОДы выдавали

В общем, возвращась к вопросу, почему в системном ПО востребован Си, а не Паскаль и его наследники, подведу итог своему ИМХО: потому что людей с школьной/университетской скамьи готовят именно на Си, да и окружающая обстановка приучает думать, что Си -- форева, а остальное -- масдай. Т.е. причина, если угодно, социальная, а отнюдь не техническая. Точно так же как среди 16-разрядных микропроцессоров оказался в конечном счёте никудышный 8086, а не по всем статьям превосходящие его кристаллы от Моторолы и Зайлога. Или что на рынке ПК абсолютным монополистом в конце концов стала модель "от IBM" (хотя сама IBM давным-давно их не производит), а не более передовые в техническом плане разработки.

Спасибо за пояснение. Мне казалось, что если уж есть кэш, то сразу надо именно целыми страницами манипулировать -- т.е. эта функция для меня как бы самоочевидной была А что не сделали раньше -- удивлён, если честно. Ведь без подобного механизма кэширование данных, хранящихся в файлах, становится малоэффективным: нужно будет без конца гонять информацию из одного места в ОЗУ и обратно, что впустую занимает процессор.

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

Ну, если отсутствие такой поддержки в версии 1 вполне оправданно (Торвальдс для себя систему делал), то "не очень эффективная" реализация SMP в версиях до 2.6 уже ничем оправдана быть не может: линухоиды отнюдь не первопроходцы в этой области, могли б изучить уже имевшийся опыт, подумать головой да сразу сделать нормальную поддержку (надеюсь, что в 2.6 она именно нормальная). Почему ж не сделали, а?

Но отнюдь не любой менеждер памяти должен априорно поддерживать возможность добавлять и удалять страницы из системы вообще. Когда ты просишь у него выделить память, то адреса страниц он вообще-то определяет сам. А тут ему приказывают добавить или изъять определённое количество страниц по определённым адресам. Это всё-таки не совсем рядовая функция (хотя реализация её особых проблем не вызывает).

"Всего лишь" На кой ляд столько вызовов-то? Впрочем, это тяжкое наследие униха, так что вопрос риторический У MS DOS, кстати, вызовов тоже выше крыши

Есно. Писать в сонном виде -- противопоказано Но заодно мы с Вами убедились, что в Си ещё один источник потенциальных ошибок есть -- логические операции. && и & -- две большие разницы, но синтаксически всё корректно (а временами и правильно работать может, что ещё более затруднит отладку).

Кроме BT-JC можно использовать и TEST-JZ, что полностью эквивалентно Сишному варианту, однако читается всё же легче (сразу видишь, что за операция и с какими операндами выполняется, а в Си надо ещё вычленить это из текста -- "плотность упаковки" исходного текста на Си существенно выше, чем на асме, что затрудняет восприятие, пускай и на доли секунды).

Видел, видел. Просто мы -- флудерасты "в теме", а не злобнофлудящие ради флуда

 

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

кэш создавался для того, чтобы лишний раз не обращаться к внешним устройствам
т. е применение кэша по типу splice - это прежде всего надстройка над основной задачей, а не основная задача

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

не знаю
вот ссылка, может будет интересно
http://www.ibm.com/developerworks/ru/library/l-linux-smp/

разве это много для немикроядерной ОС?
заметьте, тут и память, и сеть, и IPC, и файлы, и управление русурсами, и сигналы, и трассировка, и процессы, и до фига чего еще
интересно, для сравнения каков объем API у NT?

 

rei3er
Эмм... чайник встрянет, если не возражаете...

XP SP2: 283 системных вызова, если не ошибаюсь. Так что от линукса не так далеко ушли. А у w2k и того меньше: 248.

 

rei3er

Знаете поговорку: самая короткая дорога -- которую знаешь? Она же неплохо подходит и для программирования.

Здравый смысл, увы, далеко не всегда прежде всего. Например, лично я абсолютно убеждён, что Си -- масдай, что программы надо писать на паскалеподобных языках и т.д., и даже могу это обосновать на примерах (собсвенно, некоторые примеры опасности Си как языка уже были показаны в нашей беседе). Однако если я работаю в коллективе, я вынужден играть по правилам, в нём установленном. Если начальник говорит, что пишем на Си, у меня просто нет выбора. А если вдруг начальник захочет проект делать на Паскале или Аде, то ему сначала надо найти достаточно специалистов (коих намного меньше в силу нетехнических причин), а затем ещё и инструментарий (с которым тоже проблемы имеются -- и опять-таки в силу нетехнических причин).

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

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

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

В общем не соглашусь. При использовании ассемблера тоже принципы и алгоритмы -- важнейшее, и реализация почти всегда "ложится" на них автоматически. Конечно, бывают случаи, когда использование каких-нибудь ассемблерных трюков затрудняет понимание программы, но такое встречается не очень часто и обычно без проблем решается комментированием подобных мест

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

 

SII
закончим на этом
а то дискуссия уйдет очень далеко