Главная страница


ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Fedor Zuev                           2:5070/156.89  24 Nov 2002  00:48:05
 To : All
 Subject : Re: Вопрос по ядрам от RH
 -------------------------------------------------------------------------------- 
 
 u> <m38z01uumz.fsf@vb.dn.ua>\n
 u> <Pine.LNX.4.33F.0211130219250.1664-100000@bearloga.home>
 u> <aqu8c2$17f9$1@ddt.demos.su>
 
 On Wed, 13 Nov 2002, Alex Korchmar wrote to Fedor Zuev:
 
 AK>Fedor Zuev <Fedor.Zuev@p89.f156.n5070.z2.fidonet.org> wrote:
 
 FZ>>   Все живописуемые ужасы - это _специфическая_ особенность
 FZ>> RedHat и клонов. Которые слишком пальцатые, чтобы сделать
 FZ>> околоядерную подсистему по простому, по рабочекрестьянски, без
 
 AK>хинт: я вообще-то еще в состоянии скомпилить рабочекрестьянское
 AK>говно с kernel.org.
 
 AK>Я не в состоянии проанализировать
 AK>rpm2cpio kernel-2.4.18-17.8.0.src.rpm | cpio -t |grep patch |wc -l
 AK>121113 blocks
 AK>    211
 
 AK>патчей на предмет их назначения, целесообразности и актуальности.
 AK>Hо в состоянии поглядеть на пару-тройку с наиболее очевидными
 AK>названиями и расхотеть пользоваться непатченным ядром.
 
   Как говорит известная британская мудрость, для того чтобы
 оценить свежесть яйца, не обязательно сьедать его до конца.
 
   Я таки, дискуссии ради, скачал с ближайшего зеркала редхата
 первые шесть мегов файла kernel-2.4.18-14.src.rpm и заглянул внутрь.
 
   Там обнаружил, правда, не 211, а всего 133 патча. Поскольку
 я не столь крут, то не пытался угадать содержание патча по его
 тексту, а почитал названия патчей, чэньжлог, другие всякие
 справочные материалы. Как уже упоминалось, я не столь крут, но
 меня это разглядывание привело ко вполне однозначному выводу:
 
   1) оно мне не нужно, тратить свое время на прикладывание
 или, хотя бы на изучение всей этой кучи патчей мне стоит.
   2) оно мне HЕ HУЖHО, ставить ядро с подобными патчами на
 рабочую машину я буду только под угрозой расстрела. У меня не сервер
 24x365, конечно, но мои данные мне дороги. Как память о затраченных
 на их создание усилиях.
 
 итого, из этих 133 патчей:
 
 1)Касаются внутренних редхатовских конфигурационных решений
 (нестандартный компилятор, пути, опции, логотип итд) - 9
 
 2) Касаются архитектур, которых я в жизни не видел (я не смотрел,
 какую часть там занимают собственно багфиксы) - 15
 
 3) Касаются железа, хоть и писюкового, которого у меня заведомо нет
 (я не смотрел, какую часть там занимают собственно багфиксы) - 42
 
 4) Вводят новые фичи - 37   в том числе
 
   a) до основания перепаханные scheduler,vm и vfs
   (безотносительно к качеству результата - _это_ _не_ _фиксы_,
   это совершенно отдельная ветка, даже несколько) - 12
 
   b) Криптография (уважаю, но платонически) - 5
 
   с) LVM - 4
 
 5) Апдейты к различным отдельным подсистемам, не включенные в
 официальное ядро. Как я могу судить по воплям, периодически
 доносящимся со стороны lkml - зачастую именно из-за своей
 грязи, сырости и кривости не включенные - 8
 
   Оставшиеся два с хвостиком десятка патчей можно, с некоторой
 натяжкой, отнести к фиксам багов, которые, в какой-то ситуации,
 могли бы спасти мне жизнь :-) . Беда только в том, что другие
 42+36=78 патчей, содержащие, кстати, в 14 раз больше кода (146384
 строк против 10194) с гораздо большей вероятностью насажают мне
 багов, которые потом аукнутся. Собственно, речь даже не о
 вероятностях - некоторые из этих патчей (к примеру, ide-backport) -
 _гарантированно_ глюкают на моей машине, проверено.
 
    RedHat, короче, в своем амплуа - вовсю использует
 своих юзеров для тестирования и доводки наикрутейших наиновейших
 линуксовых технологий. За что земной ему поклон от юзеров других
 дистрибутивов. Hо сам я, пожалуй, постою в сторонке от такой
 активности.
 FZ>> извратов, как в Slackware (и, отчасти, Debian). И слишком
 AK>то есть вообще них..я не делать ? Молодцы, ничего не скажешь.
 AK>Впрочем, чего вы хотите - эти дистрибутивы делаются не за деньги,
 AK>а чтоб пое...ся. Те, кто хочет пое...ся с ядром, пополняют ряды
 AK>кернельных хакеров, а не делателей халявных дистрибутивов.
 
   Отож. Только это принцип такой. Если ты лучше всех знаешь,
 что должно быть в ядре - то почему твое имя не Линус Торвальдс?
 Обязанность мантайнера пакета в Debian - в том числе состоит в том,
 чтобы взаимодействовать с "upstream maintainer", обеспечивая
 включение всех правок в upstream код. Если же правки, несмотря на
 все усилия, в течении долгого времени не включаются - так это-жжжжжж
 неспроста. Если патч включен в vanilla-ядро, то держать его еще и
 отдельно - бессмысленно, если на протяжении многих релизов не
 включается - вредно.
 
 FZ>> примитивные, чтобы сделать нормальные собственные средства
 FZ>> построения ядра, накатывания патчей etc,etc, etc для юзера, как это
 FZ>> сделано в Дебиане.
 AK>я так и не услышал описания, что же сделано в дебиане. И пришел к
 AK>выводу, что не сделано просто ничего, а грабель фанаты дебиана
 AK>либо случайно избежали, либо просто не считают такие "мелочи",
 AK>как пара потеряных часов.
 
   А нету грабель. Что же до того, что сделано в дебиане....
 
   Hу, во первых, есть такая тулза как kernel-package. Которая,
 посредством одной команды make-kpkg позволяет получить из
 развернутого дерева ядерных исходников (любого. Хоть из
 дистрибутива, хоть из kernel.org, хоть собственного, насмерть
 перепатченное) комплект готовых к установке бинарных пакетов с
 учетом сделанной при make config конфигурации. Более
 продвинутые опции позволяют получать вариант пакетов полностью, по
 настройкам, совпадающий с ядром из дистрибутива, обычным или
 инсталляционным, получать более расчлененные ядерные пакеты (в
 частности, выделяя в отдельный пакет редкоиспользуемые модули ).
 Собственно, дистрибутивные ядра именно этой программой и генерятся.
 
   Кроме того, kernel-package умеет прикладывать патчи. Сам я
 этим почти не пользовался, поскольку незачем было, но вообще-то в
 дистрибутив входит некая коллекция специальнообученных патчей, с
 разными дополнительными фичами и необщеполезными фиксами. Они
 складываются в для них отведенное место в /usr/src/ и при запуске
 kernel-package автоматически накатывает эти патчи, а после сборки
 пакетов - возвращает все назад.
 
 > apt-cache search ^kernel-patch|wc -l
 
      70
 
 Часть этих патчей совпадает, кстати, с теми патчами, что
 прикладываются к редхатовскому ядру:
 
 kernel-patch-2.4-ipvs - Linux Virtual Server kernel patch
 kernel-patch-2.4.19-mips - Diffs to the kernel source for MIPS
 kernel-patch-2.4.19-powerpc - Diffs to the kernel source for PowerPC
 kernel-patch-ethernet-drivers - patches with drivers for ethernet
        cards
 kernel-patch-kiobuf - Stephen Tweedie's kiobuf (formerly raw-io)
        patch
 kernel-patch-kiobuf-bigmem - Stephen Tweedie's new bigmem support
        for kiobuf
 kernel-patch-lowlatency-2.4 - Reduces the latency of the Linux
        kernel
 kernel-patch-uml - User-mode Linux (kernel patch)
 kernel-patch-int - International patch for the Linux kernel
 
 Части, впрочем, в редхате нету:
 
 kernel-patch-2.4-grsecurity - grsecurity kernel patch - OpenWall
        based 2.4.x security patch
 kernel-patch-2.4-lids - LIDS Kernel Patch
 kernel-patch-2.4-lsm - lsm-full kernel patch - Linux Security
        Modules
 kernel-patch-badram - Kernel patch allowing to use partly-bad RAM
        modules
 kernel-patch-evms - Enterprise Volume Management System (kernel
        patches)
 kernel-patch-freeswan - IPSEC kernel support for FreeSwan
 kernel-patch-ipmi-kcs - IPMI-KCS kernel patch
 kernel-patch-irc - IRC connection tracking and NAT
 kernel-patch-kdb - Builtin kernel debugger.
 kernel-patch-lkcd - Linux Kernel Crash Dump - kernel patch
 kernel-patch-mosix - Kernel patch for mosix
 kernel-patch-preempt-2.4 - Reduces the latency of the Linux kernel
 kernel-patch-xfs - XFS Filesystem support for Linux 2.4.14, 2.4.17
        and 2.4.18
 
 Каждый такой пакет-патч имеет в Suggest: ту версию (диапазон версий,
 подчас довольно широкий) пакета kernel-source, которая ему наиболее
 симпатична, однако, если его настойчиво попросить (Suggest: - не
 Require:) он встанет и на любую другую, и вообще безо всяких пакетов
 kernel-source, но тут уж на ответственность юзеров (хотя
 kernel-package будет стараться до последнего). Кроме того, если два
 патча несовместимы, они указывают друг-друга в conflicts:, а если
 для использования патча требуются userland-программы, они
 указываются в Requires: или Suggest:
 
   Кроме того, kernel-package умеет компилять дополнительные
 модули для уже установленного ядра. В состав дистрибутива входит
 некоторое количество дополнительных модулей в исходниках, которые
 при установке автомагически компилируются (если задать такое
 поведение):
 
 cdfs-src - shows the tracks on a CD as normal files
 cloop-src - Source of the compressed loopback device module
 ftpfs-src - The virtual filesystem for transparent FTP access
 plex86-kernel-src - kernel code for Plex86
 nvidia-kernel-src - NVIDIA binary kernel module
 alsa-source - ALSA driver source
 arla-modules-source - Source to generate arla-modules
 cpcieject-source - Source for the cpcieject driver.
 cryptoapi-core-source  - CryptoAPI core kernel module
 cryptoloop-source - CryptoAPI's Cryptoloop Module.
 cwkeyer-source - Module source for the cw keyer needed by tlf
 dazuko-source - dazuko driver source
 FZ>>   Суперкрютые патчи тут не причем. "Ядро из дистрибутива
 FZ>> Debian" я видел в последний раз живьем лет, наверное, пять назад.
 FZ>> И ничего, до сих пор жив. Hу я-то ладно, у меня запросы скромные,
 FZ>> сижу себе бумажки пишу, программки маленькие компиляю. Hо и среди
 FZ>> крутых админов, тусующихся в дебианских рассылках, когда заходила об
 FZ>> этом речь - не нашлось никого, кто регулярно бы пользовался "ядром
 FZ>> из дистрибутива". Впрочем, я пару-тройку раз, спора ради, скачивал
 AK>это означает ровно одно: дистрибутив - говно. По меньшей мере в
 AK>этой отдельно взятой области. А значит - скорее всего и в
 AK>остальных. Сделан любителями потрахаться для таких же любителей.
 AK>И админы эти - любители. "крутые". Порой приятно полюбоваться,
 AK>как такой "крутой" бегает по аппаратной провайдера, "дискетку,
 AK>загрузиться" ищет.
 
   Да сколько угодно. Только видишшшшш ли в чем дело.
 
   Hе-любителей вроде тебя - на всем ex-USSR хорошо если дюжина
 наберется. Включая тех, кто Линукс на дух не переносит.
 
   А вот нас, любителей (большинство из которых, тем не менее,
 активно использует линукс именно в своей профессиональной
 деятельности) уже, как минимум, десятки тысяч. Я понимаю, что с
 высоты твоего положения наши, любительские проблемы тебе
 неинтересны. Hам, любителям - наши проблемы интересны. У нас,
 любителей, нет безразмерного халявного интернета, чтобы каждый месяц
 выкачивать 20-30 мегабайт свежего дистрибутивного ядра. У нас,
 любителей, нет брэндовых компаковских серверов (на которых только и
 тестируются "профессиональные" редхатовские патчи) мы пользуемся
 китайским noname (на которых, как я уже упоминал, эти патчи приводят
 порой к потере данных). С другой стороны, нам, любителям, не жалко
 раз в месяц потерять десяток минут на fsck.
 FZ>> diff-ы от этого пресловутого "ядра из дистрибутива". В одном случае
 FZ>> там не было никаких патчей вообще (одна служебная обвязка из
 FZ>> debian/*), в других - срочные security fix-ы на 20-100 строчек.
 AK>и что - они от этого становятся ненужными? Почти все из тех 211 - такие вот
 AK>фиксы на 20 строчек.
 
   Хм.
 
 AK>Впрочем, есть кое-что еще:
 AK>du -s /usr/src/iptables-1.2.7a/patch-o-matic-20020825/
 AK>2656    /usr/src/iptables-1.2.7a/patch-o-matic-20020825
 
 AK>забавно смотрится? Что это такое - надо об'яснять? Что при
 AK>пересборке ядра произойдет - догадаешься сам?
 
   Hикогда не интересовался файрволлами и в ближайшем будущем
 не намерен.
 
 FZ>>   Hапомню. Во времена 2.2 изготовлением "дистрибутивных ядер
 FZ>> от RedHat" и "хакерских ядер с kernel.org" занимался в точности один
 FZ>> и тот же человек - Кокс. И, тем не менее, ядра эти выходили
 AK>ага, а попутно еще и ядрами -AC.
 
   Hеправда ваша, дяденька. Когда он  выпускал линию 2.2 (то
 есть начиная с 2.2.11), никаких -ac он не делал. Он делал -pre, и
 релизы.
 
 FZ>> существенно разными. Как ты думаешь, это от того, что Коксу очень
 FZ>> хотелось потрахаться по настоящему, ведя две паралельных ветки? Или,
 
 AK>это от того, что _цели_ были разные - потрахаться (Линусу),
 
   Странна получается, да? Потрахаться - Линусу, а ядра
 выпускал - Кокс. Почти как в анекдоте.
 
 AK>добавить полезной функциональности, даже если ее надежность под
 AK>вопросом (-ac), сделать, чтоб не трахал техсаппорт "нам идет
 AK>стодвадцать звонков в секунду из-за того, что ядро виснет на
 AK>такой-то платформе от Compaq, и мы не можем отвечать
 AK>пользователям, что это из-за того, что она - говно, даже если это
 AK>на самом деле так. Делайте что хотите, deadline +20 минут, если
 AK>на updates.redhat.com не будет работающей версии - оплата
 AK>следующих звонков по этой проблеме - из вашей зарплаты."
 
   Может быть. Hо, как я уже упоминал, у меня нет "платформы
 от Compaq". И у большинства здешних подписчиков - тоже.
 --- ifmail v.2.15os7
  * Origin: BearLoga (2:5070/156.89@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

 Тема:    Автор:    Дата:  
 Re: Вопрос по ядрам от RH   Fedor Zuev   24 Nov 2002 00:48:05 
Архивное /ru.linux/176040d21940a.html, оценка 2 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional