Классификация дистрибутивов (Опубликована статья "Периодическая ...)

[zenwolf]

прочитал ! Хорошая статья получилась !
правда наверно ,если бы я писал ,то вначале описал бы разделение по категориям дистрибутивов
на http://www.linux.org/dist/list.html ,а так не в ушерб vicos -у сказанно будет ,классификация получилась долее чёткая
спасиб !

[alv]

прочитал !  Хорошая статья получилась !
правда наверно ,если бы я писал ,то вначале описал бы разделение по категориям дистрибутивов
на  http://www.linux.org/dist/list.html

↑

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

[ddc]

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

[zenwolf]

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

↑

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

[vikos]

Классифицировать Linux и разложить его по полочкам - это пожалуй дело гиблое полностью.
..........
Остаётся единственное - наполнение дистрибутива драйверами под различное оборудование. Вот тут да, отличия от дистрибутива к дистрибутиву имеются. И зачастую довольно серьёзные. Очень часто можно услышать:
- У меня win-модем(принтер, сканер, и т.д.) на **** заработал прямо из коробки!
А другой, с тем-же самым "железом", но с другим дистрибутивом, прыгает с бубном и ничего с ним сделать не может. Или, в конце концов сделает, но времени на это затратит - уйму!

↑

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

[alv]

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

↑

Ага, Шура, не слабо сочинить? Вы же теснее всех с этим по службе связаны

[Shurik]

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

↑

Ага, Шура, не слабо сочинить? Вы же теснее всех с этим по службе связаны

↑

Особо углублённого анализа специально не проводил, но что самое первое бросается в глаза - работа с MTR, IRQ и DMA-каналами. Т.е. в большой степени зависит от того, как именно собрано ядро и с какими параметрами. Скажем такой пример:
- Я уже писал о работе чипсета для материнской платы на основе NForce2. Вроде как никакого интереса он представлять не может - всё уже изучено и всё работает. Однако есть маленькое НО, точнее 3 маленьких НО - AGPGART, каскадный DMA-Mode и Dual Mode. Мною чётко выведена зависимость самой быстрой работы всех трёх позиций:
AGPGART - модулем
Каскад DMA-Mode(поддержка чипсета NForce2) - модулем
MTR - вкомпилен в ядро
APIC(разрешение работы двух устройств на одном IRQ) - вкомпилен в ядро
Самое забавное - Dual Mode начинает работат только в одном случае - если из секции Character Device убраны вообще все модули, кроме естественно, NForce2.
В любых других случаях и комбинациях начинается потеря производительности как хардов, так и всей системы в целом.
Соответственно, работа всей истемы, именно на NForce2, при прочих равных условиях, будет лучше и стабильнее, т.е. заработает всё из коробки, где ядро скомпилено именно с такими параметрам, ну, или хотя-бы достаточно близкими к этому. К примеру - будум присутствовать модули для других чипсетов. На производительность системы это не особо повлияет, при запуске уже скомпиленных программ, но вот при компиляции - очень даже влияет.
Парадокс заключается в том, что для чипсета Intel, исходники на драйвер для которого открыты, требования практически с точностью до наоборот - желательна поддержка AGPGART и чипсета на уровне ядра, а не модулем. Соответственно точно так-же зависит и работа мостов(северного и южного), всякие HUB-USB, IEE1394, IrDA и пр. приблуды. Распределились чётко IRQ, раскинулись на первые 18, управляемые BIOS - чёткая работа всяких звуковух, сетевух, модемов(в особенности - WIN-модемов) гарантирована. Не распределились - тащи шаман огромный бубен.
Естественно, что кроме этого могут быть ещё и специфические сборки и патчи - как то драйвера для видеокарт, или WIN-модемов на чипсете Lusent. или драйверов для сканера-принтера и пр. Но в любом учае работа AGPGART, DMA(UDMA) режимов и мостов - это основное!

[alv]

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

↑

Ага, Шура, не слабо сочинить? Вы же теснее всех с этим по службе связаны

↑

Особо углублённого анализа специально не проводил

↑

Ничего себе "не проводил" - ИМХО совершенно исчерпывающее описание. Собрал бы вместе все свои "маленькие хитрости"?

И пара ведер воды на мою мельницу - о дистрибутивах для всех и дистрах для себя:
первые неизбежно должны давать некое усредненное ядро, которое не будет идеально работать на всех железяках, пример с nforce и intel очень показателен.
Во вторых же ядро будет, скорее всего, вообще без всяких таких фич (лишь бы машина загрузилась) плюс исчерпывающая (вроде приведенной:-)) инструкция, как его пересобрать под свое железо
alv добавил в 14.02.2005 09:33

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

↑

Ага, Шура, не слабо сочинить? Вы же теснее всех с этим по службе связаны

↑

Особо углублённого анализа специально не проводил

↑

Ничего себе "не проводил" - ИМХО совершенно исчерпывающее описание. Собрал бы вместе все свои "маленькие хитрости"?

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

[Shurik]

2 alv

Алексей, ОЧЕНЬ плохой работай с DMA-каскадами и мостами, именно на NForce2, грешат ядра версии 2.4.ххх Там, при первичной установке, вообще клоунада полная - к примеру у меня "садились" на 11 IRQ одновременно клавиатура, мышь и сетевая карта. Совершенно определённо, при старте системы после установки, не работало ни первое, ни второе, ни третье. Это было при установке ASPLinux9.2, ALTLinux2.4 и приснопамятного LinuxXP. По ASPLinux9.2 написал небольшой мануал по установке: http://linux.alhimia.ru/projects/doc/asplinux-install/
В то-же время народ из проекта Fedora Core-2 собрал инсталлируемое(дефолтное) ядро с включённой опцией APIC, что тут-же дало свой результат - практически ни одной жалобы на невозможность пользоваться клавиатурой и мышью после старта системы у них небыло. НО! Там был свой косяк - вкомпиленные AGPGART и DMA-cascade в ядро. Резульат - садились на один и тот-же IRQ DMA-cascade и серверный мост. Соответственно "отлетал" контроллер памяти и приходилось при старте прописывать в параметрах загрузки ядра mem=256M (при 512MBt оперативки, включённой в Dual Mode). Т.е. вручную указывать уменьшенный вдвое объём оперативной памяти. Асповцы-же в своём ядре, равно как и LinuxXP(впрочем эти меньше, по привычке сдирать содрали и включённый APIC, там вою было меньше), влепили ОБЕ этих ошибки в своём ядре. Результат - достаточно почитать форумы ASPLinux и LinuxXP. Страниц по 40 - это 100%. И практически все - не устанавливается, виснет, не работает и т.п.
Распределение IRQ-же напрямую зависит от реализации ACPI-менеджера и таблицы реализации виртуальных IRQ, т.е. которые выходят за 18-ый IRQ (19. 20. 21. и т.д.) При правильном распределении IRQ аппаратные устройства, т.е. которые выполнены в виде отдельно вставляемых модулей, как то звуковые, видео и пр. карты, а так-же всевозможные контроллеры должны "садится" на распределение по таблице BIOS материнской платы. Исключение - програмно реализуемый WIN-модем. WIN-модем это виртуальный модем, который должен "садится" на виртуальный IRQ, назначаемый ACPI-менеджером. Равно как и виртуальные устройства, подключённые к USB-HUB_у. Сам USB-HUB - вполне "материален", и должен занимать "реальный" IRQ. Устройства-же, которые подключены к нему - виртуальные и соответственно должны иметь IRQ из виртуальной части. Но, если таблица IRQ в Intel открыта, то в NForce2 она закрыта и распределение IRQ происходит по по принципу - как Бог подаст. А подаёт он не всегда корректно. И вот тут-то можно пойти двумя путями:
- Первый, и наиболее результативный, очень хорошо описан на http://mcmcc.bat.ru/ в статье "Решение проблемы с IRQ на nForce2 материнках в Linux'е.". Да, он совсем не прост, и требует как внимательности, так и повторной работы(изменения) при перепрошивке BIOS, а так-же при смене ядра. НО! Если устанавливать Linux на сервер, то тут он нужен и должен быть реализован, вне зависимости от производителя чипсета. Ядра на сервере меняют крайне редко. Ещё реже кто-либо производит перепрошивку BIOS сервера, которая, кстати, в отличии от BIOS обычной материнской платы, состоит из трёх совершенно независимых друг от друга прошивок и прошивается либо отдельный блок из трёх, либо 2 из трёх, либо все 3 из 3-ёх. Короче - что нужно, то и прошивается. В этом случае таблица IRQ берётся непосредственно из BIOS материнской платы и подходит идеально. Но возни с ней... ...б-р-р-р-р...
-А вот второй способ - он более прост. Но требует экспериментов конкретно для железа, установленного в компьютере. Этот способ - вкомпиленный драйвер-модульный драйвер. Дело в том, что вкомпиленный драйвер и модульный драйвер по разному распределяют IRQ для одного и того-же устройства. Да и за примером далеко ходить не надо - моя звуковая карта Aureal Vortex2. Хоть она и стерео, но звук у неё - мягкий, чистый, насыщенный, всякие там Creative - отдыхают, далеко-далеко! Так вот - ещё в 1998 году сваяли драйвер под неё. И по тогдашней традиции присвоили ей IRQ5, как и положено для звуковой карты. Если драйвера вкомпилены в ядро, то именно IRQ5 этой карте и назначается и работает она, как Т-34. НО! Стоит собрать те-же драйвера в виде модуля, как начинается...
1. Может вообще не работать. Никак. Модули подгружены, всё вроде нормально, но вот висит она на IRQ19(виртуальном). Вот и нет звука. Куда рыть? Ладно, берём более старшую ветку ядра - 2.6.ххх. То-же самое - модулем. IRQ вообще "улетает" на IRQ22. Класс... Результат:
- ALSA - "тянет" звук.
- eSound - наоборот, как пластинка на 33 оборота, проигрывается на 66 оборотов.
- OSS - "квакает" и идёт рывками.
Вопрос - как и куда "рыть", скажем, начинающему? Да и не только начинающему - с таким может столкнуться любой. Что искать и как спросить? И какие рекомендации кто-либо может дать в этом случае человеку? Кривые руки? Или ...а у меня всё работает...?
Или драйвера для моей сетевой - Intel Exress PRO 100+ Там вообще имеются 2 драйвера - производителя(Intel) и свободный драйвер. свободный драйвер можно как вкомпилить в ядро, так и подгрузить модулем, драйвер Intel - только модулем. И комбинация модуль-вкомпиленный даёт 3!!! совершенно разных распределения IRQ! Но дело в том, что в свободном драйвере нет возможности чётко задать IRQ, в отличии от драйвера Intel, в котором, при загрузке модулем, я могу не только установить IRQ, но и задать дополнительные параметры, как-то Full Duplex, Half Duplex и т.д. С одной стороны свободный драйвер работает хорошо(если IRQ распределился хорошо), с другой стороны менять его параметры и IRQ нельзя. Ставится он в любом дистрибутиве "по умолчанию". С другой стороны драйвер Intel - подгружать можно только модулём, но зато с любыми параметрами, включая принудительный IRQ.
Вот так вот, комбинируя и подгоняя IRQ под свою систему, можно добится как увеличения общей производительности, так и чёткой работы всех компонентов компьютера.
В любом случае персборка ядра именно под свою систему и именно под своё железо необходима. Во всяком случае для платформы NForce2.
А сейчас пошла идиотская, на мой взгляд, мода - не давать исходников ядра - мол это совсем не нужно ...и так всё хорошо работает...! Ок! Я совершенно не возражаю, НО! только в одном случае - если ядра будут собраны под NForce-Athlon; VIA-Athlon и i686-Pentium; VIA-Pentium; SIS-Pentium. Так ведь нет-же такого!
Вот и получается, что у одного ...всё пашет из коробки..., а другой "шаманит" с бубном, явно не понимая - ...а почему?...

[ddc]

Для Shurik:
Про ядра из коробки: видимо считается, что на момент окончаняи тестирования FC (и, особенно, "захоронения" его в ASPLinux и LinuxXP) ядро становится не самым новым, так что правильный пользователь должен пойти на kernel.org и утянуть то ядро, которое ему нужно...

[Shurik]

Для Shurik:
Про ядра из коробки: видимо считается, что на момент окончаняи тестирования FC (и, особенно, "захоронения" его в ASPLinux и LinuxXP) ядро становится не самым новым, так что правильный пользователь должен пойти на kernel.org и утянуть то ядро, которое ему нужно...

↑

Хе...
Не так всё просто... тот-же ASPLinux, в своём дефолтном ядре, на ASPLinux10.0 наложил 26 патчей, которые затрагивают такие вещи, как iptables, Win4Lin. Lirc и т.д. Установка ядра с kernel.org вполне может привести как к нестабильной работе всей системы в целом, так и отдельных модулей-компонентов-программ.

[ddc]

Интересно... А патчи где берутся? Т.е. они в свободном доступе ведь где-то лежат?

[alv]

2Shurik
Повторяю свое предложение - собрать все написанное воедино и поместить здесь или на unix.ginras.ru. Думал было - сам справлюсь, сделать попурри из Ваших сочинений, но после последнего поста понял - слабо. Но причесать с точки зрения формальной редактуры - обещаю твердо.

[Shurik]

Интересно... А патчи где берутся? Т.е. они в свободном доступе ведь где-то лежат?

↑

Может где-то и лежат. Но вот не видел (или не нашел?) я их на официальном сервере. Для пересборки ядра пришлось разбирать kernelxxxxx.src.rpm и потом пересобирать ядро. В RPM_ке как раз эти все патчи имеются. Только вот дело в том, что *.src.rpm выложены на дефолтное ядро, а сейчас уже как минимум 4 ядра сменилось, а вот на них-то ВООБЩЕ нет *.src.rpm. Только на самое первое, дефолтное.

[alv]

Интересно... А патчи где берутся? Т.е. они в свободном доступе ведь где-то лежат?

↑

Может где-то и лежат. Но вот не видел (или не нашел?) я их на официальном сервере. Для пересборки ядра пришлось разбирать kernelxxxxx.src.rpm и потом пересобирать ядро. В RPM_ке как раз эти все патчи имеются. Только вот дело в том, что *.src.rpm выложены на дефолтное ядро, а сейчас уже как минимум 4 ядра сменилось, а вот на них-то ВООБЩЕ нет *.src.rpm. Только на самое первое, дефолтное.

↑

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

[Shurik]

2Shurik
Повторяю свое предложение - собрать все написанное воедино и поместить здесь или на unix.ginras.ru. Думал было - сам справлюсь, сделать попурри из Ваших сочинений, но после последнего поста понял - слабо. Но причесать с точки зрения формальной редактуры - обещаю твердо.

↑

Хорошо.
Как сваяю - вышлю на критику и редактирование по мылу. Писать на какое?