ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Fedor Zuev                           2:5070/156.89  17 May 2003  15:27:45
 To : Alexei Dets
 Subject : Re: apt
 -------------------------------------------------------------------------------- 
 

 
 AD>>>> apt-get -b source на стороне ftp-сервера, а не на локальной машине?
 AD>>
 AD>> AD>Далеко не на каждой локальной машине это можно сделать. Кроме
 AD>> AD>того, раз дистрибутив стоит старой версии, то, вероятно, и железо
 AD>> AD>такое же - даже если и можно собрать, то замучаешься ждать...
 AD>>
 AD>> Если у тебя такая машина одна - то подождешь, перебьешься.
 
 AD>Вот для того, чтобы не перебиваться, поддержка и нужна. Или я
 AD>должен ждать пока меня хакнут/выпускать апдейты своими силами? Да
 AD>уж проще дистрибутив сменить...
 
   Видишшш ли в чем дело. Все твои рассуждения чисто
 умозрительны. Ты исходишь из ложного предположения, что это тебе
 будет нужно в дебиане так же, как это нужно в редхатойдах.
 Это не так.
 
 Критерий истины, как известно, практика. Дебиан - это не фирма, и не
 воинское подразделение со строгой дисциплиной. Все сервисы в дебиане
 предосталяют volunteers на добровольных началах. Если никто не
 предоставляет apt-source для бинарных секьюрити-апдейтов
 ancient-дистрибутивов - значит этот гондурас никого не беспокоит.
 AD>> AD>И чего? Это ему на системе с glibc-2.0 + egcs + kernel-2.0.x
 AD>> AD>позволит собирать программы, ориентированные на gcc > 3.2 + glibc
 AD>> AD>> 2.3 + kernel >= 2.4? Hе позволит. А менять кучу _ключевых_ для
 AD>> AD>функционирования системы компонент чтобы закрыть пару дыр в
 AD>> AD>секьюрити с риском обвалить все... Для этого нужны _старые_
 AD>> AD>версии софтин, пересобранные с нужными патчами. И это кто-то
 AD>> AD>должен делать. Т.е. как сами эти патчи, так и пересборку. Плюс
 AD>> AD>отслеживание дыр и прочих проблем с софтом в старой ветке.
 AD>>
 AD>> Hикогда не видел "_ключевых_ для функционирования
 AD>> компонент", которые с такой силой закладывались бы на последнюю
 AD>> версию glibc и gcc. Все серьезные серверные программы обычно
 
 AD>Hе, это уже _собранные_ и _работающие_ программы могут быть как раз
 AD>ориентированы только на старые версии ключевых компонент - glibc, ядра и
 AD>т.п.
 
 AD>> кросплатформенны далеко за пределы линукса и gcc. И,
 AD>> соответственно, прекрасно соберутся где угодно. Кстати, kernel 2.0 в
 
 AD>Да-да, ЩАЗ! Особо хорошо между разными версиями glibc,
 AD>компилятора, ядра и ОС переносятся всякие чисто
 AD>линукс-специфичные системные вещи. И программы на C++. А еще в
 AD>новых версиях пакеты могут быть специально оптимизированы под
 AD>новые возможности конкретной системы (например, наложены патчи),
 AD>эта оптимизация может всю эту кроссплатформенность отменить, даже
 AD>если была. Hе, эти патчи/настройки, если такие будут, можно на
 AD>старой платформе при компиляции выкинут или включить другие, HО
 AD>ведь кто-то это должен сделать... В т.ч. и вообще саму компиляцию
 AD>- см. выше.
   Я тебя не понимаю. Ты имеешь в виду что-то конкретное? Или
 просто растекаешься мыслию по древу. Я охотно соглашусь, что
 _теоретически_ - возможны ситуации, когда описанная мной схема не
 работает. Какова вероятность таких ситуаций? Хотя бы раз в год они
 происходят? Городить черт-те знает что, ради ситуации, которая
 происходит в 0.1% случаев на 0.1% машин - неумно, мягко говоря.
 
 --- ifmail v.2.15os7
  * Origin: Это так просто - быть дураком (2:5070/156.89@fidonet)
 
 

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