BSD for morons.

GTFO to DragonFlyBSD

BSD

Нет уж.

Драйвера, я думаю.

Женщинам им надо больше внимания уделять

Самое главное на текущий момент(IMHO)
1. Наведение порядка в архитектуре
2. Избавление кода от «информационного шума», внесённого в исходники «проприентарщиками», то есть «отделить мясо от мух»
3. Создать удобный инструмент для настройки ядра перед компиляцией.
4. Создать «школу», ибо недалёк момент, когда процесс управления производством прийдётся передавать кому-то...

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

Я могу сказать, чему им надо уделять меньше всего внимания: наведению сферической красоты в коде, в процессе чего обязательно что-нибудь попутно ломается.

> 1. Наведение порядка в архитектуре

Зачем? Переломают опять всё к чёртовой матери. Пусть уж будет местами криво задизайненным, зато работающим.

Не только влупить.

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

Дело не только в том какие модули можно «влупить», но и в том как они разрабатываются. Stable API — nonsense. Но нынешний chaotic API, когда никто никому ничего не обещает, код драйверов нужно непрерывно поддерживать, иначе он не то что устареет, но будет немедленно выкинут из ядра, тоже не сахар. Вон, X.org разбили на отдельные пакеты, и стало лучше.

Писать драйвера устройств - задача производителей оборудования
Планировщики задач - боюсь, что Linux уже ничто в этом плане не поможет, только замена на код QNX вида s/^.+$/QNX code/gm
Графической инфраструктуре DRI - нет, это вообще должно быть в X.org целиком, я против огромных кусков графической подсистемы прямо в ядре
Процессорным архитектурам - чем их меньше, тем лучше
Файловым системам - их итак перебор, а научиться хотя бы ресайзу LVM'а в одну операцию Linux явно не светит и в отдалённом будущем
Сетевым протоколам - с этим у Linux лучше, чем где бы то ни было

ПОДСИСТЕМЕ ACPI - а вот это реально головная боль, потому что управление энергосбережением - это ахиллесова пята ядра Linux. Ну не умеет оно быть экономным, что уж тут поделаешь. А уж про Hibernate за 3-5 минут я вообще молчу: на..на он тогда вообще нужен, я компьютер быстрее полностью выключу так, а потом включу и все свои прложения открою снова. Ожидание, когда оно из свопа себя подберёт и загрузиться (во многих случах ещё и криво это сделает) способно выведести из себя кого угодно.

Да, а ещё бардак с Netfilter мне лично совсем не нравится: сегодня модуль в составе Netfilter'а есть, завтра его нет и заменить нечем, послезавтра ещё какая-нить фича появляется и тоже через 5 месяцев пропадает... Нельзя просто так включать в Netfilter модули сторонних разработчиков, которые не гарантируют целостности, обратной совместимости и постоянной поддержки своего кода.

МОНОЛИТНОЕ ЯДРО: в 0-м кольце защиты (процессы ядра) реализует КООПЕРАТИВНУЮ многозадачность, а в остальных - ВЫТЕСНЯЮЩУЮ

МИКРОЯДРО: во всех кольцах защиты многозадачность ВЫТЕСНЯЮЩАЯ

То, о чём вы говорите, вообще из другой оперы!

А ви таки разработчик?

>Stable API

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

Белки внезапно очень вменяемы, плюсую.

Проголосовал за баги. А вообще, выше уже все сказали.

Проголосовал за драйвера устройств. Никогда не думал, что установка линукса намой ноут вызовет столько проблем с оборудованием, некоторых дров просто нет до сих пор, некоторые только не официальные.

синим рамочкам

а где же так полюбившиеся народу «синие рамочки»?

> единственная действительно ценная вещь в компе - пользовательские данные

[fat]
У пользователей линукса украсть нечего, кроме исходников ядра (це) Касперский
[/fat]

:)

> всему сразу +1024

ИМХО, уже нет какой-либо очевидно слабой области, как было раньше например с драйверами и ACPI. Теперь уже нужно уделять внимание всему в целом.

Однозначно iowait

драйвера для видеокарт - вопрос исключительно вендоров, а не разрабочиков ядра. Со стороны постараться подлатать документацию, механизмы и всё остальное, что необходимо сторонним разработчикам драйверов. Я бы вообще текущую модель разработки ядра рекомендовал разделить на kernel и kernel-drivers

скорее не поиску, а исправлению багов. +1 к iowait

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

Можно сколько угодно обсуждать проблему драйверов но она никогда не решиться. Потому что нет стабильного API - нет драйверов. А стабильного API нет, не было и не будет.

Читали бы разработчики ЛОР...

12309 пофиксить, ибо несерьезно уже как-то.
Пока у тебя стандартная конфигурация, еще ничего.
Как только добавляешь LVM и шифрование, оно начинает заикаться (независимо от проца), ибо i/o операции усложняются.
Страшно подумать, как оно себя будет вести на SAS массиве из 4 и более дисков.

Планировщику задач, вестимо.

ACPI болит больше всех

Поиску багов. Естественно, не забывая про новый функционал.

ну и iowait починить

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

баян

Планировщику задач. может работать будет быстрее и ресурсов меньше жрать.

+ дохера.

> Ядро нужно выкинуть и переписать заново!
+1

Имо, драйверам устройств.

1. Поиску багов, особенно связанных с безопасностью
Иногда ядро таки падает, дыры находят довольно часто
2. Драйверам устройств
Драйвера есть почти под всё, но таки некоторые устройства не поддерживаются
3. Производительности.
То есть планировщику задач в основном

> Разработчикам ядра больше всего следует уделять внимание...

вариант: «архитектуре ядра»

Где планировщик ввода-вывода?

вариант: "архитектуре ядра"

http://www.linux.org.ru/polls/polls/4822454?lastmod=1272904075667#comment-4838468 (комментарий)

в ядре все худо-бедно работает - без нас разберутся. А вот уровнем пониже мрак и ужас. Имхо, дак DRI2 нужно доводить до ума, но здесь вобщем то разработчики ядра почти никак не задействованы.

По опыту сборки и тестирования: ЛАТАНИЮ багов ВОВРЕМЯ. Ибо патчи- то для большинства багов есть(http://userweb.kernel.org/~akpm/mmotm/broken-out/), но вот внедряют их не всегда вовремя.

>Ядро нужно выкинуть и переписать заново!

На mono!!!
Или на java!!!
Или НЕТ! На AJAX!!!!

Разработчикам ядра меньше всего следует прислушиваться к ЛОРовским аналитикам

собственно.

IO же

I/O подсистеме и ее шедулерам, конечно же

>Женщинам им надо больше внимания уделять

Слова не мальчика, но мужа!

можно подумать счас разрабы почитают и сразу же кинутся писать дрова ))

а где вариант «не давать глупых советов» или «не мешать» ? :)

драйверам устройств и багам.

ACPI, драйверам и багам. Остальное менее важно(имхо)

драйвера и поиску багов

iowait опять же, ну и API не нужно так часто теребить.

Архитектуре, ну и да - поиску багов.