Ядро «раздутое и огромное» (bloated and huge)

Все это подарил нам солярис :-)

2,2M 2009-09-10 17:43 /boot/kernel-genkernel-x86_64-2.6.31-gentoo

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

...что как бы явно намекает, что API/ABI таки стоит замораживать (хотя бы на какое-то время), чтобы вынести драйверы устройств из самого ядра. Если, конечно, у разработчиков ядра хватит инженерной кольтуры, чтобы разработать вменяемый API/ABI...

> ...что как бы явно намекает, что API/ABI таки стоит замораживать (хотя бы на какое-то время), чтобы вынести драйверы устройств из самого ядра.

И чем же это поможет?

но ведь это закон всего мироздания: 1 1 2 3 5 8 13 21 34 55 и тд. (ряд Фибоначчи) всё рождается и расширяется, пока не умрёт.
только смерть может всё очистить... за что и спасибо ей.

Интересно, они feature freeze делать не пробовали, скажем, на месяц?

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

Скучно, зато ядру полегчает.

>В технологическом плане FreeBSD перегнала Linux. Linux не имеет технологий, которые есть во Фри.

Хватит уже трахать несчастную ZFS.

Трахайте top 100, нетбуки, смартфоны и роутеры.

>почему при таком зоопарке технологий виртуализации, линупсоиды начинают гневно плюватся на портирование в линупс ipfw и pf ? чтобы ядрэшко не пухло? :o)

Не нужно потому что.

Все делается iptables + другие утилиты.

> кроме kqueue какие ещё?

ВНЕЗАПНО epoll.

> Трахайте top 100

таки может top500?

То что ядро всё больше и больше - факт.
А вот скорость у меня только растёт (система новая).
Собственно иногда в некоторых подсистемах бывают регрессии которые выправляют но это эпизодические события которые потом исправляются.
Возможно ещё имелось ввиду, что если собрать все модули/драйвера то тогда банальный поиск по ним будет замедлять систему, но никто не заставляет вас собирать универсальные ядра. ^_^

> Так что решили-то?

Надо исправлять. "Нужен план."

\fat_mode{Это ядро системы}

>ах да, Фришка же идет по тому же пути...

Причем тут его пост и FreeBSD?

http://stoplinux.org.ru/wiki/index.php/FAQ#.E2.80.94_Linux_.D0.B8.D0.BC.D0.B5...

Неужели линец наступит раньше, чем вендец и бздец?

Конечно же будущее за Hurd. Надо Линусу податься в майнтейнеры этого правильного ядра.

> В технологическом плане FreeBSD перегнала Linux.
> Linux не имеет технологий, которые есть во Фри.

ололо!! это разве что zfs? а виртуализация? а поддержка железа? а кластерные решения?

Ну, а что вы хотели от студенческой поделки!

Откатываемся на 2.6.18?

>С этим надо чё-то делать. Надо решать.

Ничего ты с этим так просто не поделаешь... Лет 6 назад этот вопрос очень остро стал в мире СПО в ядрах Линукса и Фри, хакеры ядра тогда сказали что они уже не смогут самостоятельно развивать код монолитно-модульных ядер. Реально один человек может работать с ядром не более 500 000 строк! Ну с нятяжкой 1 000 000 строк. Были идеи выкидывать драйвера с ядра... GNU взялось за свой микроядерный Hurd.. Но Линус тогда сказал что драйверы должны быть в ядре иначе они вообще перестанут работать, также заявил что другой альтернативы монолитно-модульному ядру невидет. В итоге Линукс нефоркнули, а бсд пофоркали, особенно вышесказанное относится к DragonFlyBSD там изначально принято решение что любая часть системы включно с ядром должна бать подёмной для одного хакера... В итоге Диллана обзывали раскольником сообщества, и долго публично высмеивали его математическую модель ядра....... А тем временем http://www.dragonflybsd.org/release24/, пойду писать новость для главной......

>Но Линус тогда сказал что драйверы должны быть в ядре иначе они вообще перестанут работать

Где можно про это почитать?

>И чем же это поможет?

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

Идея хорошая. +41220

>> И чем же это поможет?

> Это поможет вынести все драйверы устройств из ядра

То есть ровно ничем это не поможет. Едиственное, что конкретно сказал Линус - это "our i-cache footprint is scary". А неиспользуемые драйверы не грузятся в память даже при отсуствии стабильного API,

Стабильный API для драйверов - это здорово, но от этой проблемы не поможет.

Ну дела были в 2003 году, на ЛОРе как всегда где то есть летопись...

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

Ха-ха!! :)) Об этом ещё 15 лет назад ему говорил Танненбаум, тогдашнему ещё троечнику Торвальдсу. НЕ ИЗБЕЖАТЬ тут можно только непроходимой тупости Пингвофила, который сделал поделку "фор фун", не выдерживающей ещё тогда никакой критики.
И дело даже не в микроядерности - сама идея тупого монолита была ущербна, зато проста в реализации. Об Обероне, надо понимать, Торвальдс вообще ничего не слышал.

Где сейчас эта "фор фун" поделка троечника, а где поделие великого и ужасного Танненбаума?

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

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

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

> Стабильный API

...замечательная вещь, но i-cache footprint не уменьшает ни на байт.

> сама идея тупого монолита была ущербна, зато проста в реализации. Об Обероне, надо понимать, Торвальдс вообще ничего не слышал.

Куда там этому Торвальдсу до Великого Матумбы...

А почему бы не глянуть в сторону микроядер? Взять например разработки того minix3 и использовать в linux? Думаю, что это избавить от многих проблем...имхо

Ну таки што вам мешает пересобрать едро? Читаем конфиг едра фрибзди. Прозразчно.

Хочу заметить, если сильно не выдрючиваться, то (при конфигурирования едра бзди) никакого мазохизма не предвидется.

> А почему бы не глянуть в сторону микроядер?

Потому что еще никому не удалось добиться нормальной производительности от микроядерной ОС.

> Взять например разработки того minix3

Там нечего брать.

> так он мало того, что подтвердил, еще и придумал какое-то 4.2 в моем сообщении, и кучу скора оттяпал %)

Скородрочество это такое кармадрочество по типу хабрахабра?

> Вообще, "линукс быстрее винды" - это сказки. Он распухает примерно так же. Примерно столько же жрёт памяти и сравнимое время загружается. Единственный выигрыш - не нужен антивирусь.

Он медленнее. Сравни опенофис и файрфокс в линуксе и в винде на какой-нибудь не очень новой машинке.

> Где сейчас эта "фор фун" поделка троечника, а где поделие великого и ужасного Танненбаума?

Как это где? Разве вы ещё не срифмовали? Тогда мы идём к вам! :)

Линупсоподелие находится в глубокой Ж. Это очевидно, даже не принюхиваясь. УЖЕ САМ АВТОР морщится от вида этого Г...ного колосса.

<A HREF="http://www.minix3.org/">Minix</A> Танненбаума успешно существует с той лишь разницей, что его система (как и всё гениальное) рынком проигнорированы - на рынке выигрывают тупые костылеобразные решения узколобых буржуев, решающих свои специфичные задачи. Примеры: Linux, Windows, Garmin, etc.

>> Взять например разработки того minix3

>Там нечего брать.

Там есть самое главное - АРХИТЕКТУРА! А у Торвальдса в своё время не хватило ума, т.к. был студентом реализовать микроядро, в итоге сейчас мы получили вторую винду, с костылями...

>>> Взять например разработки того minix3

>> Там нечего брать.

> Там есть самое главное - АРХИТЕКТУРА!

ДАААААА!!!!!!111

> А у Торвальдса в своё время не хватило ума, т.к. был студентом реализовать микроядро

Откуда вы такие беретесь? %)

Фигасе у вас вещества :) На самом деле, когда читаешь тексты, даже Торвальдса, надо включать мозг и понимать, о чём идёт речь. А речь идёт о том, что универсальность и фичастость ядра неизбежно ведёт к его усложнению и снижению скорости. Это оксиома такая, в нашей реальности. Хочется на слабом железе скорости - ради бога, вырезай всё лишнее. Можешь вообще взять ядро 2.2, если что не так. Собственно, так и делают. Моторола, нокиа, да и вообще андроид - ничего, на армах 500 Мгц обеспечивают нормальную подвижность систем. Ну и нетбуки те же, уже приводили видео пруфлинки, железо слабое, но линукс живёт и пахнет. Не надо только впадать в катастрофизм, надо просто иметь ввиду ситуацию и действовать сообразно ей, что и делают дистрибуторы.

Говорил Дилан Матвей упёртым баранам с бсд и линукс: http://itc.ua/node/17811/

для Ъ

"Наибольшую сложность при мо-дификациях кода классических Unix ядер разработчики практически всех ОС испытывают при реализации эффективной поддержки мультипроцессорных систем. В Linux и FreeBSD 5.x для этой цели в неоклассических ядрах применяется модель взаимного исключения (сокращенное общепринятое название -- mutex), позволяющая избежать главной проблемы параллельного программирования -- одновременного использования одних и тех же неразделяемых ресурсов разными фрагментами кода (такие потенциально опасные фрагменты называются критическими секциями). Под неразделяемыми ресурсами здесь понимаются разнообразные конструкции, использующиеся для взаимодействия между программами--обработчиками прерываний и "остальными программами", т. е. одни из ключевых ресурсов любой ОС. Для решения задачи синхронизации доступа к ним часто применяются программные флаги "блокировки", в которых захвативший доступ к ресурсу код оставляет предупреждение "занято" всем возможным претендентам. Очевидно, что чем меньшие фрагменты кода ядра ОС являются критическими секциями, тем большей степени "параллелизма" можно добиться при эксплуатации такой ОС на мультипроцессорной машине. И также очевидно, что решение подобной задачи далеко не простое... В отличие от неоклассических ядер Linux и FreeBSD 5.x в DragonflyBSD "блокировки" отсутствуют принципиально -- потому как система не базируется на модели взаимного исключения. Ее архитектурная основа -- легковесные потоки (нити) ядра, LWKT (потоки выполнения, не имеющие собственного контекста "тяжелого" процесса). При этом вместо одного общего планировщика задач (scheduler) в ОС для мультипроцессорных систем в Dragon-flyBSD применяется несколько -- по числу процессоров. Каждый scheduler каждого процессора отвечает только за то, что ему подвластно -- в данном случае остается единственная критическая секция кода, локальная по отношению к процессору, а не ко всей мультипроцессорной системе в целом (причем это действительно элементарный код -- увеличения/уменьшения на единицу значения одной переменной). Такая архитектура, естественно, предусматривает возможность передачи потока выполнения с одного процессора на другой -- но не автоматически, а исключительно по требованию потока, что справедливо только для потоков, выполняющихся в пользовательском режиме ОС. Не следует воспринимать это как ограничение -- в DragonflyBSD таким образом выводится максимум кода ядра (в первую очередь, драйверы устройств) в пользовательский режим. Данная трансформация одновременно обеспечивает и рост производительности системы (чем больше в ней "пользовательских драйверов", тем, грубо говоря, выше асинхронность всей системы в целом), и надежность -- падение драйвера, выполняющегося в пользовательском режиме, не приводит к фатальным для системы последствиям. И наконец, у этой медали есть и третья, архитектурная, сторона -- "драйверы пользовательского режима" дают как реальную возможность унифицировать их программные интерфейсы (что означает отсутствие необходимости модификаций кода ядра ОС при добавлении драйверов), так и применить принцип виртуализации физических устройств. Очевидно, что реализация всех этих технологических "вкусностей" была бы невозможна без фундаментальных изменений в архитектуре классического монолитного ядра Unix совместимой ОС. И таким фундаментальным изменением здесь является отказ от традиционных вызовов подпрограмм в пользу асинхронного механизма передачи сообщений, что сближает DragonflyBSD с микроядерными системами -- именно сближает, но не больше. В идеале, вся система -- до уровня эмуляции Unix API -- будет основана на механизме сообщений, что существенно упрощает, например, реализацию поддер-жки потоков пользовательского режима ядром ОС. Целостность концепции Dragon-flyBSD обеспечивается и радикальным изменением одного из самых сложных и важных механизмов ядра любой Unix совместимой ОС -- виртуальной файловой системы (VFS). Здесь в "стрекозе" изменяется практически все, что можно изменить -- VFS вместо сложнейшей реентерабельной (повторно входимой) программы превращается в сервер сообщений, полностью перестраиваются политики кэширования, значительная часть кода переводится в пользовательский режим. В общем, это уже совсем не та VFS, без существенных преобразований дошедшая до сегодняшнего дня."

А они его не слушали...

Дальше переходим все сюда http://www.linux.org.ru/view-message.jsp?msgid=4071750

Микроядро хотя бы не будет 'bloated and huge', как Линупс.

Dave Cutler, один из главных разработчиков VMS и OpenVMS, а также главный разработчик первых версий Windows NT.

ага. люблю обмазываться свежим скором и^W^W^W^W^W

Пруф ищи в книге 'Inside Windows NT' Элен Кастер. Вот вроде: http://www3.sympatico.ca/n.rieck/docs/Windows-NT_is_VMS_re-implemented.html#f...

Был бы minix хоть немного юзабельным - было бы о чем поспорить. А так и говорить нечего, это как было учебным пособием так и осталось.

>Был бы minix хоть немного юзабельным

А почему он не юзабельный? Вот портированный софт: http://www.minix3.org/software/ Х-ксы, mplayer, gcc, perl, tcl, links - уже юзабельный :)

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

Я говорю о принципиальном подходе, вы - о практике (где тоже ошибаетесь). Самая популярная нынче - ВыньИкспи. Принципиально правильная - Миникс или L4.

> Микроядро хотя бы не будет 'bloated and huge', как Линупс.

"Маленькое" ядро будет сопровождаться большим количеством userspace кода и все это тоже будет 'bloated and huge'. Проблема не в монолитном ядре, а в большом количестве различных устройств, для работы которых . Драйвера устройств идут сразу в ядре или вместе с ядром (в случае микроядра).

MS же не поставляет многих драйверов со своим ядром - производители железа сами их пишут и поддерживают.