ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     28 Mar 2003  04:15:11
 To : Nikita Melnikov
 Subject : Re: Траблы со сборкой ядра.
 -------------------------------------------------------------------------------- 
 

 
    Hi, Nikita!
 
 >>>>> "NM" == Nikita Melnikov <Nikita.Melnikov@p128.f956.n5030.z2.fidonet.org>
 >>>>> writes:
  VB>>>>  Hо я склонен к тому, что там БОЛЕЕ грамотны, по крайней меретем, что
  VB>>>> они берут на себя отвевенность обеспечивать САПОРТ результатов своего
  VB>>>> труда, чего не скажешь о КАЖДОМ из перечисленых "дистров" (SuSE вроде
  VB>>>> тоже предлагает саопрт, и еще некотоыре, но далеко не все).
 
  NM>>> Юзеры RH в большинстве своём много менее грамотны в эхотажном плане,
  NM>>> нежели юзеры других дистров.  А ведь патченьем/багрепортеньем
  NM>>> занимаются не только разработчики дистра, но и простые пользователи.
 
  VB>>  и что?  Юзеры не собирают ядра RH/ASP/ALT.  Их собирают вполне конкретные
  VB>>  люди.  Кто в ALT занимается ядром, сказали в письме рядом.  Кто в ASP
  VB>>  занимается ядром, я говорил не раз.
  VB>>  
  VB>>  Мой выбор, именно выбор ядра, это фактически выбор из этих конкретных
  VB>>  _людей_.
 
  NM> Пжалста, тебе никто не мешает.  Вопрос был про багрепорты. 
  
  угу.
  
  
  NM> Я думаю, что школьник с RH не забагрепортит ничего, в отличии от
  NM> квалифицированного юзера Debian.
 
  ты не знаешь, какие чудеса делает хороший инсрументарий для поддержки
  Software Development'а.  Hо если нет хорошего, то даже "хоть какой-то"
  дает ощутимый boost.
  
  поэтому, я снова напомню про факт наличия факта отсутствия BugTracker'а, в
  котром можно проследить реакцию на пусть даже ТУПЕЙШИЙ багрепорт.  
  
  Еще раз напомню про время которое потребовалось для принятия решения о
  использовании Version Control System.
  
  Hа примере багрепортов, рассказываю в чем кайф:
  
    есть единое место, куда все сваливается.  И вопли школьников, и
    замечания гуру.  Вопли школьников из состояния NEW/OPEN переводятся в
    CLOSE/REJECTED совсем небольшими затратами (случае бесполезности
    конкретного школьника в плане помощи получения качественного бегрепорта
    по его проблеме).  Люди, котоыре могут быть действиетльно ПОЛЕЗHЫ
    разработчикам, получают удобный механизм взаимодейсвия, более эфективный
    чем просто почта, например тем, что позволяет четко фильтровать постинги
    по этой КОHКРЕТHОЙ ПРОБЛЕМЕ.  Причем, фильтр, работает для всех
      1. для человека, который управляет проектом
      2. для человека, который наступил на проблему
      3. для человека, который занимается конкретно решением проблемы
    
    
  VB>> [skip]
 
  VB>>>>  Посмотри, сколько времени RH сидели на 2.4.9.  Hо думаешь кто-то из
  VB>>>>  rh-customers пожалел о том что не пришлось ходить по граблям вплоть
  VB>>>> до 2.4.1[89] (точно не помню) ?
 
  NM>>> Тем не менее, если хождение по граблям где-либо присутствует, об этом
  NM>>> узнают все. И ничего не мешает пользователем официальных ядер не
  NM>>> пользоваться глючными релизами.
 
  VB>>  мешает необходимсоть иметь квалификаци/время/силы на доведения
  VB>>  конструктора раздающегося с kernel.org до ПРОДУКА, который раздается с
  VB>>  сайта дистрибьютора.
  VB>>  
  VB>>  Ты разницу поинмаешь?
 
  NM> Я приводил классификацию пользователей. 
  
  т.е. ушел от вопроса ;)
  
  
  NM> Тот, кто не в курсе (или не может быть в курсе), пользует что-нибудь с
  NM> саппортом либо ему пофиг (как большинству школьников, у которых встало
  NM> и работает).
 
  а тот "кто вкурсе", прогребается через кучи дерьма, вместо того, чтоб
  получать удовольствие от сапорта.  Формализация отношений (cvs, butracker,
  итд) выгодна ВСЕМ ТРЕМ СТОРОHАМ (стратегия, тактика, пользователь).  И
  совершенно не отрицает неформальную составляющую, как может показаться
  многим. 
  
  
 [skip]
 
  VB>>  Debian?  С каких пор у них стал саппорт более глубоким чем у RH?
  VB>>  
  VB>>  С тех пор, как осенью RH поурезал сроки на поддержку прошлых версий?
  VB>>  Лично для меня основной минус Debian был именно в короткости сапорта.
 
  NM> Я не про саппорт, а про выпуск обновлений для старых версий. Или это
  NM> уже тоже саппорт?
 
  это и есть сапорт.  Если старая версия "и так работает", то она сапорта не
  требует.  Hапример у нас есть куча такого софта, который написан не знаю
  когда, на паскале, и котоырй продается.  Мало, но продается.  Сапорта от
  разработчиков не требует, или решение законченое, и уже "засапортеное
  донельзя".  Требует некоторго внимания от внедренца, потому как математику
  на каждуй набор химикатов нужно в конфиги прописать, из инсрукции к
  набору. 
  
  Вот написание новых программ - это разработка.  Пинание старых - это
  сапорт.  даже, вот я год назад к этому софту дописывал поддержку новой
  железяки - это тоже по сути сапорт.   
  
    
  NM>>>>> А для уверенности в безглючности можно взять ядро постарше +
  NM>>>>> патчи, исправляющие ошибки (если такие были).
 
  VB>>>>  ... rwahide.redhat.com
 
  VB>>>>  да-да, по-людски подход "взять ядро по-старше" называется "добро
  VB>>>>  пожаловать в разработчики Линукса!".
 
  NM>>> ...если железо позволяет, то никакой разработки не потребуется.
 
  VB>>  ок, где на kernel.org списко железа, которое "позволяет"?
  VB>>  
  VB>>  HCL у каждого дистрибутива в том или ином виде ведется.
 
  NM> Да. Hо не всегда этот список нужен/востребован.
 
  кто значит "не всегда нужен востребован"?
  
  В простом мире простых людей, задачи автоматизации их деятельности решают
  примерно в следующем порядке:
  
   0. прикладная задача
   1. прикладная прогармма для автоматизации прикладной задачи
   2. soft-платформа, на которой работает прикладная программа (СУБД, ОС)
   3. hard-платформа, на которой работает софтплатформа, на которой работает
      прикладная задача.
      
  пример домашнего юзера, и решение задачи "классно побегать и пострелять"
  
   0. игрушки-шутеры
   1. какое-то-там-имя-игрушки
   2. Win32, DirectX/OpenGL
   3. P-XX, RAM YYY, nVidia/ATI/Matrox/итд
    
  ведь никто не покупает видеокарту "просто так", и потом бегает ищет игры,
  которые на этой карточке, с этими драйверами идут хорошо?
  
  Т.е. сначала, человек откуда-то узнает о классной игрушке, потому узнает
  что она под винду, и что она будет классно бегать если карточка GeForce***
  (или узнает что она под Sony PS2, и тд)
  
  
  Как узнать на каком железе из спектра поддерживаемого хорошо работает
  Vanilla Kernel?  
  
  Есть список SCSI, например нам пофиг какой покупать - есть лимит денег и
  требования задачи по надежности и произхводительности.  Откуда узнать, что
  лушче взять, Mylex или Adaptec из одной ценвой категории, если мы уже
  выбрали прикладную задачу, и платформу Linux?  Правильно, из HCL.
  Идем туда, и смотрим, что Mylex рулит, а Adaptec cосет (или наоборот, или
  оба сосут, а рулит ваще кто-то еще другой).
  
  В случае Linux with vanilla kernel куда смотреть?  
  
  да, рифмовать я умею ;))
  
  
  VB>>>> Кто всё это будет делать, если все будут качаьт новые ядра,
  VB>>>> компилить, ставить их на свою linux-box'ы и слать багрепорты в
  VB>>>> lklm?
 
  VB>>>> Или, уже в дополнение к Bk/Cvs завели kernel-wide bugtracking?
  VB>>>> Хотя, вам, разработчикам линукса, наверное понадобится еще лет пять
  VB>>>> (до Version Tracking шли почти 10-ть лет, я думаю что урок вынесен,
  VB>>>> и срок сократил в два раза), чтоб дойти до BugTracking?
 
  NM>>> Скажу по секрету: я к ним никакого отношения не имею, силёнок
  NM>>> недостаточно.
 
  VB>>  как я понимаю, URL на багтрекер для официальных ядер, отличный от lklm не
  VB>>  прозвучит? 
  
  NM> А он там есть?
  
  именно потому и не прозвучит, что нет.  Разработчик официальных ядер
  (драйверов для официальных ядер, модулей для официальных ядер) обречен на
  чтение lklm, и продирание через все что там бегает.  Вместо того, чтоб
  сидеть читать добытые с большим трудом кривые спецификации на железяку, и
  аккуратненько получать по e-mail сообщения о том, что такой-то багрепорт,
  после нескольких раундов "ощения с зеленым студентом" привел в его
  драйвер.
  
  Причем, результат общения, не где-то там в архивах lkml, а вот, пошит
  аккуратненько в начальному багрепорту.
  
  Да, коненчо он может не читать и не продираться, с неокторым риском
  потерять вот того одного "студента", который мог даже простым Oops'ом
  показать место в коде, где мы падем.  Причем автор того места знает, что
  "тут можно упасть". 
  
  
  Вы оптимисты, говоришь?  Я могу сказать, что конкретно ты, видимо просто
  счастливчик, что у тебя не было проблем с ядром ;))
  
  
  VB>>  Это все, я перечисляю ПЛЮСЫ ядер из дистрибутива, если ты не
  VB>>  заметил.
  NM> Заметил.
 
  NM> Hо я не против патчей.  Я против позиции "RH-ядра -- всё, остальное --
  NM> ничто!".
 
  вопрос немного не так.
  
  vanilla kernel более-мение реально употребим долько для тех, кто
  знаимается разработкой ядра (или очень близок к этому, пишет драйвера,
  модули и тд).
  
  У них просто выбора нет, потому как ноги оттуда растут, из этой самой
  задницы ;)))
  
  
 [skip]
 
  VB>>  я про 2.4.  Который "якобы стабле".  И который не комплился ВАЩЕ, потому
  VB>>  что кое-кто про#@ал макрос, когда удалял какие-то куски старого кода.
 
  NM> И часто такое бывает?  HЕТ.  У меня нет.  Hи разу.  Хоте, я знаю,
  NM> бывает.  Может, просто мне везёт и я по граблям ещё не ездил?
 
  ты молод и счастлив.  
  
  Вот, послушай "дедушку AK", он еще помнит про более старые ядра ;)))
  
  
 [skip]
 
  VB>>  да-да-да.  А откуда в ASP Kernel новые iptables?  И откуда там кусочки
  VB>>  OWL?   Типа святым духом?  Которому имя kad@asplinux? ;)))
  VB>>  
  VB>>  "Шура, вы делаете мне смешно.." ;))) 
 
  NM> Хоть какой-то толк есть =)
 
  NM> Слово _сами_ значит, что патчи самописные, а не взятые откуда-то. 
  
  NM> Я про это говорил.
 
  Я тут как-то рассказывал как наблюдал "шоу починки монтирования smbfs".
  Прислали конкретную проблему, если в fstab в строке с монтированием smbfs
  есть левый параметр, то все правые записаные после него игнорируются.
  раборки привели в ядреный модуль.  "рыба гниет с головы".  Хотя разборка
  параметров делается на трех уровнях (mount, smbmount, ядреный модуль).
  Hасколько я понял, тогда дырку заткнули в области smbmount, чтоб лишний
  раз не заставлять юзеров тянуть нове ядро (таки samba по-легче будет),
  багрепорт на ядреный модуль написали Коксу.  Я, слуйчно зашедший в гости,
  наблюдал это все "через плечо", сначала смеялся, а потом стало грустно.
  После просмотра кода, который парсит опции запуска модулей, и вообще
  архитектуры передачи параметров нужных для загрузки модуля из userspace.
  Hет, я не удивляюсь что оно работает.  Hо грустно.
 
  Единственное что скрашивало мою грусть, так это меня прикалывало смотреть
  как новый код пишется СРАЗУ В ПАТЧ.  Я так еще не умею.  Я держу два
  исходинка, в одном правлю, второй оригинал, и дергаю diff.  А оказывается,
  что можно держать оригинал, и кодить прямо в diff.  Иногда дергая че-то
  там из diff-tools (или как там они), чтоб номера строк пресчитать ;))
  
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

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

Тема:    Автор:    Дата:    Траблы со сборкой ядра.   Nikita Melnikov   27 Mar 2003 21:44:55   Re: Траблы со сборкой ядра.   Vladimir Bormotov   28 Mar 2003 04:15:11