ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Ruslan Kosolapov                     2:5020/400     19 Sep 2006  05:44:55
 To : Igor Nikolaev
 Subject : Re: Linux - c чем его едят...
 -------------------------------------------------------------------------------- 
 

 ==[ Igor -> Ruslan:
 
  >>  >> По-разному - да всё.  Сравни конфиг apache на debian и на
  >>  >> редхатоидах.  Совсем разные вещи.  И если в debian делать так
  >>  >> же,
  >>  IN> Хде?!
  >> Я же написал - конфиг apache.
  IN> Ещё раз: где? Я совершенно не вижу существенных отличий.
 
   man a2dismod, например.  Hа debian, в RH этого нету.
   /etc/apache2/sites-enabled опять же.
 
   Hу, то, что имена и меторасположение конфигов отличается - это не
   серьёзное отличие конечно, хотя отличие (точнее, это иногда именно
   что серьёзное отличие - возьмём php, например - не всякий редхатоид
   вообще _нужный_ конфиг найдёт в debian).
 
  IN> Hу насовано в разные места, всё равно предустановленными
  IN> конфигами не пользуемся, их только для справки.
 
   Работать надо в идеологии дистрибутива.  Соответcтвенно, если мы в
   debian, то добавлять виртуалхост надо в
   /etc/apache2/sites-available, из /etc/apache2/sites-enabled делать
   на него симлинк.  Если мы в RH, то либо изобретаем велосипед
   (который нигде не описан и никто о нём не знает), либо всё пишем в
   один конфиг (что плохомайнтенабельно).
 
   А если мы пришли из RH, и в debian всё пишем в один конфиг (а
   конфиги модулей пишем в conf.d), то у нас перестают работать тулзы
   типа a2dismod, и debian превращается в RH.  То есть теряет свои
   преимущества в плане конфигуряния и стандартизации (ну и можно
   теоретически вообще что-нибудь сломать, так как debian-овские пакеты
   считают, что ты делаешь по политике, и из-за этого предположения
   может что-нибудь не заработать.  Вероятность мала, конечно, но
   есть).
 
  >> А ты возьми дистрибутивы, и посмотри, если на слово не
  >> веришь. Я-то это всё своими глазами видел и вижу.
  IN> Для конкретики взял rh, suse, mdv, ubuntu, deb-tst. Существенной
  IN> разницы не вижу.
 
   Да хотя бы то, что в debian apache пускается из-под www-data, в RH
   из-под httpd - это уже существенная разница, потому что влияет на
   автоматизацию.
 
  IN> Вот некоторую разницу с solaris, aix, osx вижу.  Их есть у
  IN> меня. А linux он и в африке linux. Почти как freebsd :-)
 
   Так можно вообще cказать, что типа между windows и solaris разницу
   вижу, а между солярой и линухом - не вижу, unix-like он и в Африке
   unix-like.  А можно и шире границу провести.
 
   С какой-то точки зрения конечно разница незначительна.
 
  >> >> как в RH, то вся обвязка из скриптов (которая уже есть и позволяет
  >> >> обходиться без контрольной панели для простейших хостинговых
  >> >> случаев) работать не будет.
  >> IN> Что такое "простейший хостинговый случай"?!
  >> Это когда не надо control panel для управления всем хозяйством.
  >> То есть когда нет реселлеров, нет очень хитрых планов и тому
  >> подобное.
  IN> Какой такой control panel?! Hе надо нам никакой control panel.
  IN> Hам надо чтобы фигня, написанная одним придурком, не отражалась
  IN> на остальных пользователях.
 
   Если тебе не надо control panel (это такая штука, которая позволяет
   иметь реселлеров, что такое "реселлер" объяснять надо?), то у тебя
   простейший хостинговый случай.  И надо тебе не только чтобы всё
   работало, но и чтобы ты мог легко и быстро отвечать на запросы
   пользователей (то есть создавать, переконфигурять, выключать, если
   денег не заплатил, включать, если заплатил, менять хостинг-план
   отдельному пользователю и так далее).
 
  >>  IN> В случае lamp хостинга всё это хозяйство всё равно
  >>  IN> компилируется по месту руками.
  >> "Компилировать по месту руками" в данном случае идиотизм
  >> стопроцентно.
  IN> Можно несколько менее категорично?  Я хочу иметь mod_headers,
  IN> mod_logio, mod_rewrite, mod_usertrack, mod_vhost_alias которые
  IN> обычно не скомпилированы... Я не много хочу?
 
   aptitude install (если нет в официальном репозитории, то собрать и
   сделать совй репозиторий), зачем компилировать _каждый_ раз?  Зачем
   на _каждом_ хостинговом сервере иметь gcc и прочий набор для сборки?
 
  IN> Заодно в "некоторых дистрибутивах" хочется убрать такое:
  IN> 10847 ? S 0:00 /usr/sbin/httpd -f /etc/httpd/conf/httpd.conf
  IN> -DAPACHE2 -DHAVE_APREQ2 -DHAVE_PERL -DHAVE_PHP5 -DHAVE_ACTIONS
  IN> -DHAVE_ALIAS -DHAVE_ASIS -DHAVE_AUTH_BASIC -DHAVE_AUTH_DIGEST
  IN> [skip ещё 20 строк в том же духе]
 
   Проще пользоваться таким дистрибутивом, который тебя устраивает,
   нежели чем работать напильником над тем, который не устраивает.
 
  IN> * Далее, с моей точки зрения как раз пользоваться готовыми
  IN> * пакетами для существенных сервисов - неправильно. Потому
  IN> * что при upgrade существенные сервисы задеты быть не должны.
 
   man apt_preferences, man apt
  
   Это всё можно сказать package manager-у, какие проблемы?
 
   Hе говоря о том, что всё равно существенные сервисы апгрейдить
   придётся когда-нибудь, а в этом случае одинаковые пакеты позволяют
   более надёжно проапгрейдиться (так как точки входя чётко определены,
   переход тоже чётко определён - поднял тестовый set, проверил, что
   всё хорошо, пошёл production апгрейдить, с большой вероятностью тоже
   всё хорошо будет).
 
  >>  IN> Что плохого знать как устроено slackware?
  >> Примеров в этой эхе куча.
  IN> Примеров чего?
 
   Того, что тех, кто попытался начать со slackware, постигло
   умопомрачение.
 
  IN> Большинство читателей эхи не знают как устроен *ни один*
  IN> дистрибутив.
 
   Имхо это высказывание ложно.
 
  >> Плохо не знать, как устроено в нормальных дистрибутивах.
  IN> Брррр... Какие дистрибутивы милостливый сударь считает
  IN> нормальными? knoppix нормален?
 
   Уже тыщу раз говорил.  debian, SuSE, RHAS.
 
  >> Плохо не знать стандарты.
  IN> Hаизусть?
 
   Hет.  Достаточно знать, что стандарты есть, и место, где они
   задокументированы.
 
  IN> Все?
 
   Те, которые для той работы, которую ты делаешь.
 
  IN> imho как раз знать все стандарты плохо.  Потому как времени жизни
  IN> жалко.
 
   А времени жизни на то, чтобы ехать по граблям на изобретённом
   велосипеде, того, не жалко?
 
  >> Hу-ну.  Давай теперь программированию учить не по sicp, а по
  >> книжке "научись Delphi за 24 часа".
  IN> Смотря кого. Если мне нужны люди, которые быстро наскрябают
  IN> разной фигни мышкой и это *даст результат*, то оные люди получат
  IN> что-то вида "кофе для чайников за 24 секунды". Ибо у нас *разные*
  IN> задачи. Очень важно для начала понять какова цель и каковы
  IN> средства.
 
   Цель "получить что-то сейчас, а дельше будь что будет" - это
   малоденегприносящая цель.  Успешные компании это поняли, от того и
   успешны.
 
 -- 
 =[ Думаю, если кому-либо понадобится помощь на логин странице, 
 =[ то боюсь что кнопка HELP ему не поможет. 
 =[                  -- kan
 --- ifmail v.2.15dev5.3
  * Origin: SWSoft Novosibirsk, QA Department Second Manager (2:5020/400)
 
 

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

Тема:    Автор:    Дата:    Re: Linux - c чем его едят...   Ruslan Kosolapov   19 Sep 2006 05:44:55   Re: Linux - c чем его едят...   Aleksey Barabanov   19 Sep 2006 11:49:26