[LOR] Wiki с описанием параметров компиляции ядра. Новый подход.

[rssbot]

В обычных сборниках по параметрам ядра (при компиляции) опции пытаются разделить по пунктам и разделам. Но так как разработка Linux ведётся очень быстро, то просто невозможно поддерживать актуальным такое "дерево". Пункты перемещаются из ветки в ветку, переименовываются, приходят новые и уходят старые. Например, по мануалам ядра 2.6.18 ужасно трудно ориентироваться в ядре 2.6.26 и уж тем более, в 2.6.32. Так родилась идея — воспользоваться уникальностью имен параметров в .config-файле. Файлик "плоский", никакие перипетии ему не страшны: нельзя поломать вложенность пунктов, если их нету :-) Так же не страшно устаревание информации и легко добавляются любые новые данные. На базе этой идеи на хосте Открытого Клуба поднята wiki, ориентированная именно на .config-файл. Естественно, wiki рассчитана не только на то, что люди будут вручную править .config при компиляции — это слишком. Любые другие методы работы с параметрами всё-равно могут опираться на представленную в "плоской" Wiki информацию. В данный момент Wiki только-только начала заполняться, но уже может быть полезна при незнании тех или иных нюансов конфигурирования. Естественно, любой желающий может дополнять Wiki даже без регистрации. Но чтобы избавиться от КАПЧИ придётся регистрироваться. По ходу работ, были добавлены ещё и дополнительные разделы: конфигурирование sysctl и дополнительный раздел с расширенными сведениями (например, рассказ о времени отклика). Синтаксис DocuWiki чрезвычайно прост и понятен с первого взгляда. Заинтересованные линуксоиды и переводчики приглашаются принять участие в проекте. Обсуждение ведётся на сайте Open-Club.ru .

оригинал на linux.org.ru

[sash-kan]

подробности.

[serzh-z]

Меня до сих пор скручивает от слов "вбивайте" - по привычке убегаю без оглядки от таких людей/проектов, ибо сразу начинаю представлять чего же они там ещё могут написать. )

[Bluetooth]

Из текста новости не понял, зачем компилить 2.6.32 с маном от 2.6.18 (:

[serzh-z]

Пока я не понял из новости преимущества подобного подхода перед чем-то ещё... Просто *дословный и КРИВОЙ перевод* описания опций из конфигов kbuild ядра. Причём вики - пустая. Сначала надо было её хотя бы наполнить чем-то, а потом пиарить. А так - люди зайдут, посмотрят на эти жалкие 10 абзацев с кривым переводом описания, пожмут плечами и уйдут. И вся попытка раскрутки окажется пустой.

Там, как вижу, и описание опций /proc уже пошло в ход.