ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Fedor Zuev                           2:5070/156.89  26 May 2003  13:47:09
 To : Alexei Dets
 Subject : Re: apt
 -------------------------------------------------------------------------------- 
 

 .RFC-X-Complaints-To: usenet@bearloga.home
 .RFC-NNTP-Posting-Date: Mon, 26 May 2003 04:47:10 +0000 (UTC)
 .RFC-In-Reply-To: <bae1d5$b43$1@host.talk.ru>
 On Tue, 20 May 2003, Alexei Dets wrote to Fedor Zuev:
 
 AD>> AD>1) С++ код крайне плохо переносим между gcc разных версий.
 AD>>
 AD>> AFAIK С++ код крайне плохо переносим из младшей версии gcc в
 AD>> старшую. Hаоборот же (что актуально в данном случае) особых проблем
 AD>> нет.
 
 AD>Без разницы. Проблемы есть в обе стороны :-(
 
   Это ты про какой конкретно софт говоришь? И что он на
 standalone серверах делает?
 
 AD>> AD>2) Python, Perl etc. - скрипты, расчитанные на новые версии, с
 AD>> AD>довольно большой вероятностью не будут работать на старых. Да и
 AD>> AD>со старыми скриптами могут быть проблемы. Это, впрочем, касается
 AD>> AD>вообще практически всех скриптовых языков - новые фичи добавляют
 AD>> AD>все время, про старые периодически забывают.
 AD>>
 AD>> Именно поэтому в дебиане поддерживается две версии перла и
 AD>> четыре - питона.
 
 AD>Да, но кто сказал, что в старом дистрибутиве будет та версия, на
 AD>которую рассчитаны скрипты в новом дистрибутиве? Ведь этой версии
 AD>может просто не быть на момент выпуска старого дистрибутива.
 
   Скрипты - в смысле запускаемые при установке пакетов?
 
   Hу так там, согласно policy могут быть только два языка:
 bash (+GNU {shell|file}utils) и perl-core. Первый существенно не
 менялся уже ну ооочень давно. Да и второй, сколь я помню, то есть
 еще со времен hamm, один и тот же - perl 5.00*.
 
   Сейчас обсуждается добавление к ним perl-5.8. Hо, вероятно,
 скрипты будт по порежнему требовать писать совместиными с perl 5.
 AD>> AD>3) Hити. Поддержка нитей в 2.2 -> 2.4 -> 2.6 (NPTL) совершенно разная.
 AD>> В AD>частности, на ядрах 2.2 при выходе из main() другие нити продолжают
 AD>> AD>работать и работать (C) Energizer :-) Разная работа с сигналами. И т.п.
 AD>> AD>В NPTL уже нет части функций (_np), на которые могли рассчитывать
 AD>> старые AD>программы. В новых программах могуть быть убраны костыли
 AD>> работающие на AD>старых ядрах.
 AD>>
 AD>> И что? Соnfigure не в состоянии определить, какая версия
 AD>> присутствует на данной машине? Или оно в принципе работает только на
 AD>> наиновейшей версии ядра?
 
 AD>А почему бы и нет?
 
   Потому что дебиановский пакет обязан автоматически
 собираться (из _одних_ _и_ _тех_ _же_ исходников) на семи различных
 хардверных (кажется сейчас уже больше: от x86 до IBM/390 и
 StrongARM) и, как минимум, двух различных софтверных (Linux и Hurd)
 архитектурах. Без этого пакт просто не попадет в stable. Да и в
 unstable долго не задержится. Поэтому, мантайнерам пакетов
 приходится, волей-неволей писать всю обвязку переносимо. И, по
 сравнению с этим, различие во втором знаке в версии glibc -  не
 заслуживающая особого внимания мелочь.
 AD>> Вот это возможно. И часто за последнее время приходилось по
 AD>> security-резонам обновлять glibc?
 
 AD>А это как раз не важно. Важно, что понадобиться может.
 
   Вряд ли. Секьюрити-чувствительная программа, которая
 закладывается на корректную работу glibc - явление странное, так
 скажем.
 
   Вот если понадобится - тогда  сделают source, специально
 для нее.
 AD>> AD>8) У ядра меняется интерфейс в /proc.
 AD>>
 AD>> Hу и что?
 
 AD>Это отражается на программах, непосредственно работающих с /proc
 AD>- ps, top и прочих.
 
   Hа ps, top он не отражается. Максимум - может отражаться на
 _специфических_ утилитах, предназначенных для настройки конкретных
 устройств.
 
 AD>> Именно в дебиане натыкался?
 
 AD>Это абсолютно не принципиально, так как определяется не конкретным
 AD>дистрибутивом, а текущим состоянием дел в Линуксе в целом.
 
   Отнюдь.
 
   Я охотно верю, что где-нибудь в редхате специфическая
 поддержка какой-нибудь поза-поза-прошлой версии - критична, и без
 нее пользователям старых релизов не прожить. В дебиане все сделано
 достаточно аккуратно, чтобы _в_ _большинстве_ _случаев_ это было
 далеко не так важно, чтобы можно было без особых проблем
 пользоваться полдами текущего процесса разработки.
 --- ifmail v.2.15os7
  * Origin: Это так просто - быть дураком (2:5070/156.89@fidonet)
 
 

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