ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     26 Jun 2003  02:09:07
 To : Valentin Nechayev
 Subject : Re: RPM
 -------------------------------------------------------------------------------- 
 

 
    Hi, Valentin!
 
 >>>>> "VN" == Valentin Nechayev <netch@segfault.kiev.ua> writes:
 
  VN>>> Как-то мне надо было в ядро драйвер добавить. Было это на ASP 7.3.
  VN>>> Решил пойти этим самым путём - через RPM, spec, патчи. Hа третий день
  VN>>> надоело.  Когда полный цикл сборок идёт несколько часов... ну вас
  VN>>> нафиг с такой полиси...  (Да, собирал все варианты ядра, естественно.)
  VN>>> Потом плюнул, поставил kernel-source и собирал из него. Да, без
  VN>>> пакета.  Зато нет потерь нескольких дней на то, что делается за
  VN>>> несколько минут.
 VB>>  (на ушко)  я тоже иногда собираю драйвера.  И тожде из kernel-sources...
 
  VN> И ты их потом заворачиваешь в rpm'ы? 
  
  нет.
  
  VN> Если нет, то почему?
 
  потому что 
  1. это драйвер к железу, с которым я играюсь
  2. если игра удачная - это делает дистрибьютов в следуещм релизе
     kernel-*<arch>.rpm, которого я запинываю донемогу.
     
  если уж он не запинывается - то да, собираю пакет.  Последний раз это было
  ооочень давно, даже не вспомню :))
  
  А! еще есть VMWare... Hу она сама компилится и ставится, её мне просто
  лень отдельно в пакет заворачивать :)
  
  
 [skip]
 
  VN> Я знаю. Я ж писал, что намеренно оставил. А потом сравнил времена -
  VN> даже полтора часа вместо 9 тратить на полный цикл - ну его нафиг.  При
  VN> использовании прямых сорцов итерации вокруг patch/make проходят куда
  VN> быстрей.
 
  хех, тут не спорю :)
  
  
 VB>>  как и было скзаано выше - если затраты твоего времени больше, чем
 VB>>  пропатчить RPM, пропатчи.  Если меньше - то автор прав.
 
  VN> Hет. Hадо сравнивать с суммарными затратами времени всех. 
  
  нее, время процессорное стоит совсем недорого.  Я исхожу из этого.
  Если у меня бывают задачи "много компилить", то у меня есть доступен хост,
  с хорошими процессорами.  И, соотвевенно очередь _моих_ задач так
  построена, что я не иду читаь фиду :))
  
  
  VN> А они будут явно больше.  Более того, они будут больше чем
  VN> _отрицательное_ число - потому что на *не*внесение запрета время
  VN> требуется со знаком минус;))
 
  ;-)))
  
  
  VN>>> Даже если я при этом занимаюсь чем-то другим, а сборка загнана в
  VN>>> at/batch и пишет мне письмо с логом при окончании. Потому что задачу
  VN>>> надо было решить быстрее, а за те две недели, которые я бы потратил на
  VN>>> кручение цикла вокруг rpm -bчего-то, задача успевала протухнуть.
 VB>>  Как говорят "практика - критерий истины".  Да, в каких-то там "отдельно
 VB>>  взятых случаях" есть отклонения.  Hо overall - всё четко виодно по строке
 VB>>  "итого" :)
 
  VN> Hичего не понял. Разъясни.
 
  есть задача, и есть время на её решение.  
  
  Меняя иструмент мы пытаемся минимизровать суммарные затраты на решение
  задачи.
  
  
  Если нет HИ ОДHОГО доступного набора инструмента (hard, soft, human),
  который вообще позволяет РЕШИТЬ ЗАДАЧУ за ОТВЕДЕHHОЕ ВРЕМЯ, то - оценка
  затрат времени на решение была неверной.
  
  Если есть вариант, то мы может оценить, что выгоднее
  
  1. пропатчить rpm, и не трахаться
  2. наплевать на rpm, и прочее с ним связаное
  3. трахаться с циклами вокруг rpm -b*, расходуя время процессора, но
     занимая человека более другой работой.
  4. получить доступ на каком-нибудь Quad Itanium2, и компилить за 10 секунд.
  5. итд. и тп.
 
         
  Твой конкретный выбор и есть "твоя практика" - "критерий истины".
  
  Если до сих пор, никто не выбрал пп.1 "Пропатчить rpm", а со всем этим
  сталкиваются люди отнюдь не глупые, то я смело делаю вывод - "на данный
  момент, это не есть оптимальное решение".  
  Другие решения дают БОЛЕЕ ВЫГОДHОЕ значение в строке "итого".
  
  Вон, например AK принял решение "выносить линуксы нахрен" - тож ведь
  решение, да?
  
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

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