LINUX.ORG.RU

Модель разработки ядра с помощью мейнтейнеров, возможно, неэффективна

 ,


3

5

Мейнтейнеры подсистем ядра Линуса могут в будущем оказаться в ситуации, когда они не смогут выполнять свою работу по перенаправлению потока патчей Линусу Торвальдсу. Это может произойти, если они не переработают этот процесс с тем, чтобы сделать его более распределенным — утверждает разработчик ядра Дэниэл Веттер (Daniel Vetter).

Любой человек может присоединиться к процессу разработки ядра, но только избранные разработчики имеют право направлять наборы патчей Линусу. Эти т.н. мейнтейнеры должны обеспечивать качество патчей. Однако система не всегда работает так хорошо, как об этом часто говорится. По словам Дэниэла мейнтейнеры всё меньше и меньше пишут свой собственный код, и т.о. становятся бюрократическим узким местом. Кроме этого, их собственный код проверяется гораздо менее внимательно, чем код третьих лиц, что является наглядным примером двойных стандартов в разработке ядра.

Веттер, сам являясь мейнтейнером ядра i915, пришёл к этим заключениям, проанализировав запросы на включение в ядро. Как он сам заявляет, этот метод позволяет лишь поверхностно оценить тенденции в разработке. Тем не менее, со стороны подсистемы графики ситуация улучшилась, благодаря стараниям его и его коллег: для решения проблемы масштабирования он предлагает поделить работу на большее количество людей и он также предлагает обучать младших мейнтейнеров.

Ситуация особенно плоха в сетевой подсистеме, где только 9% кода на включение в ядро проверяется более, чем одним мейнтейнером. В противовес этому, 83% патчей в графической подсистеме проверяется как минимум двумя людьми.

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

В своём блоге Веттер приводит множество графиков и заключений на основе проведенного им анализа.

>>> Подробности



Проверено: jollheef ()
Последнее исправление: CYB3R (всего исправлений: 3)

Ответ на: комментарий от Harald

Мейнтейнер без скриптов - не мейнтейнер.

slapin ★★★★★
()

Нейросеть пусть пилят

Deleted
()
Ответ на: комментарий от mandala

2025 год всего через 7 лет. Прогноз не такой долгосрочный как по коням был.

AndreyKl ★★★★★
()
Ответ на: комментарий от Deleted

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

darkenshvein ★★★★★
()

Придётся делать иерархию, подобную BSDшной.
Один «Линус»(будь он хоть трижды Торвальдсом в кубе) не сможет контролировать весь процесс.
Надо создавать нечто вроде BSDшной Core-Team(главное что бы не пересрались между собой), и пусть эта core-team берёт на сбя часть «бумажных» функций мейнтейнеров, освобождая их время для разработки.
А вот прослойку «коммитеров» в БСДшном понимании перенимать, наверное не стоит, их функции пусть делят core и maintainers между собой...

Всё это чистое IMXO, и просто «размышлизмы вслух», ни на что не претендующие

drfaust ★★★★★
()
Ответ на: комментарий от Harald

конкретно этот мейнтейнер уже много чужих патчей завернул по левым причинам

в какой подсистеме ядра, если не секрет ?

потому что ему, кмк, влом чего-то менять и напрягаться

это норамльно, меняет и присылает новую версию автор патча

anonymous
()
Ответ на: комментарий от kto_tama

корпорации типа интела перестанут вносить вклад в open source

и сдохнут, потому что их конкуренты типа ARM вытеснят, а майнстрим какой был такой и останется. Отдельное ядро интеля нахер никому не нужно - там куча подсистем и их надо развивать постоянно.

anonymous
()

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

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

anonymous
()

И че придумал в итоге? Как бороться?

xDShot ★★★★★
()
Ответ на: комментарий от Deleted

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

WitcherGeralt ★★
()
Ответ на: комментарий от Deleted

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

WitcherGeralt ★★
()

Новость ни о чём ради бетховенов.

anonymous
()

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

matumba ★★★★★
()
Ответ на: комментарий от matumba

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

Говорят, только машинно-зависимая часть Mach в 1991 году была больше всего Linux. Так что будь Linux микроядерным, его бы просто не было.

Линуксокапец пришёл к своему логичному финалу

Спалился пришелец.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от mandala

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

Собственно, к этому гражданин и призывает, — поменять модель разработки.

AlexM ★★★★★
()
Ответ на: комментарий от Deleted

К сожалению, обязательно.

Третий год не подпускают к кодированию, и без того небольшой навык существенно просел.

AlexM ★★★★★
()

Выход, видимо, в том, чтобы сделать ядро меньше, а всякие там драйверы вынести в юзерспейс. Танненбаум довольне!

anonymous
()
Ответ на: комментарий от WitcherGeralt

глубоко в контексте быть нужно

Насколько глубоко? Проверять патчи намного проще, чем их писать.

Deleted
()
Ответ на: комментарий от matumba

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

Микроядра хороши только в терьятических измышлениях академиков-кукаретиков. А товарищу Линусу не до терьятических фантазий — Он ядро операционной системы пилит.

Конкретно тебя не волнуют проблемы микроядра. Для тебя это просто удобный повод швырнуть говно в огород Линуса.

anonymous
()
Ответ на: комментарий от drfaust

Надо создавать нечто вроде BSDшной Core-Team(главное что бы не пересрались между собой)

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

kto_tama ★★★★★
()
Ответ на: комментарий от Deleted

А они точно менеджеры, а не техногики?

muon ★★★★
()
Ответ на: комментарий от Deleted

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

WitcherGeralt ★★
()
Ответ на: комментарий от anonymous

А вот интерсно, почему фемскам с разноцветными волосами всё время к программистам лезет? Че они там забыли? Код не пишут ни строчки, но разводят мерщость в багтрекерах.

anonymous
()
Ответ на: комментарий от anonymous

Для начала, можно бы повыкидывать всякое легаси и ненужно, выделив его в отдельный пакет типа linux-firmware.

Deleted
()
Ответ на: комментарий от WitcherGeralt

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

Deleted
()
Ответ на: комментарий от Deleted

Необязательно быть программистом, чтобы разбираться в программировании.

ну все, кухарки правят страной...

mandala ★★★★★
()

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

Napilnik ★★★★★
()
Ответ на: комментарий от Deleted

Кажется, что для мэйнтейнера, сидящего на потоке ченджсетов, умение читать код, видеть его неочевидные недостатки: как недостатки общего свойства, так и в конкретной прикладной области, — и советовать методы их исправления — критический навык. Он как раз и требует погружения в «мясо» и собственное кодирование.

Это тоже «управление», а не только рисование духоподъемных графиков и чартов в презентациях.

AlexM ★★★★★
()
Ответ на: комментарий от Deleted

Ты знаешь, как RCU реализован?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.