Fedora Core 6 test 1

>Так тогда вообще из любого дистрибутива можно сделать продакшн-грэйд, какая разница что тестировать, если баги все равное будут фиксится в сорцах?

В принципе, да. Даже из lfs. Но тут вмешиваются временные затраты.

Я говорю - попробуй к слаке привесить xen, ну или что попроще - kdump. Причем это не просто должен быть патч с собранным ядром - оно должно стабильно работать.

>Еще непонятно что такое "на базе"... а уж "не ломая" - выдергиваем HAL и D-BUS и еще немножко костылей, от коих на сервере толку мало... система разве не осыплется?

Нет. Система не осыпется. Просто посмотри. что вызывает к работе эти вещи. ;)

>Молодец! Самое важное в серверах - это не обкатанные решения, а весь дистр, собранный последним, только что вышедшим gcc на последних, только что вышедших glibc! ;-)

Это зависит. Судя по обновлениям, все вышедшее достаточно стабильно. К тому же не вижу разницы между тем, что ты на старые glibc навешиваешь свои патчи или коммитишь их в ветку glibc и меняешь ее номер, вставляя в дистриб.

А ты предлагаешь на новом хорошем железе работать с RHAS/ES 2.1,3?

>плюс надо еще ядро обновить, в дистрибутивном разрешены только GPL модули

Слушай, обновлений уже вышло на 500 метров. Это было одно неудачное ядро. Ядра обновлять надо - или ты сидишь на слаке без обновлений?

>с каналом все ок, хотя apt-get тоже иногда задумывается на 5-10 секунд, но ошибок не выдает

значит не ок. у меня и дома и на работе проблем с зеркалами нет. На 500 метров 2 сбоя.

>как? прописыванием сидюка с дистрибтивом в качестве репозитория?

Точно. Или у тебя cd, или у тебя инет. Если ты обновился с инета, то сидюк тебе уже точно не нужен.

>Причины? У нас определенный набор пакетов => зависимости обеспечиваются влегкую by-design

Тогда - только небольшой набор пакетов. И то - с обновлениями могут быть трудности. Пример: обновилась софтина, в новой версии она использует новую библиотеку, которую раньше не использовала; делаешь в системе "update" - долго думаешь "почему она работает не так, как надо или даже вобще не запускается?"; оно и понятно - эта библиотека по зависимостям не "update'ом" не установилась :(

>или возможности апгрейдить рабочий сервак полностью одной командой?

А это разве плохо? особенно если серван - не один... Меня всегда удивляли заявления слакварщиков о том, что тезис "машина должна работать, человек - думать", о том что разрешать зависимости нужно руками и деражть их все в голове - это хорошо, а когда это автоматизированно и это делает за тебя тупая машина - это плохо...

>Так сорцы везде одинаковые, разница в патчах, некоторые из которых на сервере нужны

Вы плохо представляете, что такое спеки/ебилды и чем оно отличается от просто сырцов и патчей. поэтому я даже спорить не хочу на эту тему:)

>во что выльется жесткий блок на установку пакета? ;)

В то, что пакет будет работать, а тебе не придётся гадать, что ещё нужно установить, чтобы он работал. Вы ещё не знаете, что 90% зависимостей в RPM-пакете получаются автоматиески при сборке 9в частности - зависимости на все используемые lib*.so.*)? Вы считаете, что все зависимости в пакетах жёстко прописаны "злыми мэйнтейнерами" чтоб вам усложнить жизнь?:)

>Например всякие системы индексации,

Не понял, о чём вы?

>Mono-надстройки и т.п., см. прессрелизы от RH прочих дистростроителей

а зачем их устанавливать, если они вам не нужны? Не ставте - система останется и без них целостной и рабочей.

>что в моих глазах "production" = бесперебойно и круглосуточно готовый сервак... для десктопов - другие требования -)

Не, вы неправильно понимаете:)

Если "сервак" - то это значит, что я могу установить быстро множество "серваков", с разным набором сервисов и "не забыть установить все нужные либы" и "не держать всё это в голове":)

Аналогично - с рабочими станциями. Вплоть до того, что у меня есть список необходимых для работы пакетов на рабочей станции, инсталлятор ставит мне только basesystem+apt, я делаю

apt-get install `cat список-пакетов`

и забываю до следующего обновления.

> И xen, наверно, не умеет умеет

Из коробки?

>в фак сукины дети! x86, x86_64, ppc и s/390

Прямо полностью? Я слышал, там были проблемы.

> Все нормальные крупные дистростроители фиксят софт, чтобы он работал, пока ментейнеры этого софта не исправят все правильно.

Патчи к Х11 какой-то древнеегипетской версии (чуть ли не xfree86 3.3.6 или 4.0.0) - почему-то не коммитились в проект разработчиками на протяжении _лет_, и аналогий сему довольно много... Ведь не дураки же в Х-консорциуме собрались?

> Естественно, оно после этого нормально работает.

Втыкание utf-8 везде где можно - сюда же? И что значит нормально - когда патченые на соответствие внешнему виду, плюс кое-что еще КДЕ, ОпенОфис и т.д. начинает жрать памяти в полтора раза больше нативного под платформу (например собранную под Генту) - это считается нормальным шагом в развитии дистрибутива?

> Они являются основным разработчиком gcc и могут себе это позволить.

Придраться не к чему, они также сами и говорят - "на свой страх и риск, с нас - никакой ответственности, да еще и потестим на вас же".

> Офтопик, чудо, года выпуска какого? А дистрибутив у тебя какого года выпуска? > Ты не сравниваешь же 98 и XP. Ну а тут-то чего полез?

С учетом, скажем, второго сервиспака к win-XP, разница в пару лет несущественна... и кто сказал что требования к ресурсам растут пропорционально времени и версиям? Это свойственно оффтопику, но вызывает изумление на linux-based дистрах.

>Как оно может продолжать компиляцию в саспенде?!

Оно не продолжает:) Но: утром включил, а оно продолжает кодить или компилить с того места, на котором остановилось:)

>вообще хотелось бы видеть гр_бузу майнтейнером lor-faq, он не такой инертный как ты с фаготом :)

Кстати, ты мог бы посмотреть в icq о том, что писал тебе gr_buza.

P.S. Мы фиксим фундаментальные баги...

>Но схема работы - да, медленная и тупая.

ИМХО из-за: 1) XML. 2) python :(

Неа, не шумит, не зря упоминался Залман... шепот прямо в ухо - горааздо громче :)

>Ну в некоторых случаях можно пересобрать пакет, чтобы изменить зависимости.

Так ото ж... А если требуется зависимость типа:

Requires: packageA || packageB

?

>если прервать компиляцию и просто продолжить, она тоже начинает с того места, где и закончилась

Ой-ли? Далеко не всегда:)

Дык будущий RHEL - на базе 6-й Федоры, и как раз к моменту выхода текущие свежие и даже завтрашние КДЕ с Гномом станут тогдашними проверенными и включенными в состав.

> Слушай, обновлений уже вышло на 500 метров. Это было одно неудачное ядро. Ядра обновлять надо - или ты сидишь на слаке без обновлений?

это сейчас уже вышло 500 метров обновлений

или ты предлагаешь после релиза ждать месяц и только потом ставить дистрибутив? ;)

> Точно. Или у тебя cd, или у тебя инет. Если ты обновился с инета, то сидюк тебе уже точно не нужен.

все равно криво

советую посмотреть на add/remove programs в ubuntu

>ЗАЧЕМ НА СЕРВЕРЕ "свежий KDE, GNOME и много чего прочего" ?

Наверное из-за привычки "ставлю всё, а то придётся в голове все зависимости держать":)

> Из коробки?

неа, но ставится без проблем

> Прямо полностью? Я слышал, там были проблемы.

полностью

насчет ppc незнаю, все застыло на уровне 9.1/10.0

> Кстати, ты мог бы посмотреть в icq о том, что писал тебе gr_buza.

он мне ничего не писал, сказал лишь что ты ему ничего не ответил

> Неа, не шумит, не зря упоминался Залман... шепот прямо в ухо - горааздо громче :)

все равно слышно, не может быть гробовой тишины при включенном компе

>не может быть гробовой тишины при включенном компе

Разве что полностью перейти на водяное охлажение...

> В принципе, да. Даже из lfs. Но тут вмешиваются временные затраты. > Я говорю - попробуй к слаке привесить xen, ну или что попроще - kdump. Причем это не просто должен быть патч с собранным ядром - оно должно стабильно работать.

Временные затраты... по сути в LFS нет только пакетного манагера... а бинарники выходят теми же самыми... и все упирается в тестирование, которое для слаки, lfs и федоры займет примерно одинаково... Я уже смотрел на размеры патча для XEN и число затрагиваемых файлов в сорцах ядра... ужоснах, извиняюсь за выражение :) ноги его не будет на продакшн серваке :)

> Нет. Система не осыпется. Просто посмотри. что вызывает к работе эти вещи. ;)

Консольно залогиниться будет можно, но когда либка слинкована относительно другой отсутствующей - и с учетом зависимостей оные пакеты более высокого уровня просто не поставятся. Много останется от десктопа? И в свое время было... OpenOffice+PAM, от которого было зависимостей - полторы строки где-то в сорцах...

> Разве что полностью перейти на водяное охлажение...

дешевле выключать комп на ночь ;)

И вообще, зачем тогда графические конфигурялки делают для серверов, если есть самая крутая графическая среда - ssh, требующая только PAM да OpenSSL? :) Юниксоиду от рождения оного достаточно, а посади виндового админа после курсов с сертификатом от RedHat... хорошо если сервак некритичный )

>советую посмотреть на add/remove programs в ubuntu

Лучше заскриншоть.

>или ты предлагаешь после релиза ждать месяц и только потом ставить дистрибутив? ;)

Ядро обновилось буквально через неделю. Ну а если смотреть на слаку - что, религия не позволяла ядро пересобрать? ;)

>если есть самая крутая графическая среда - ssh, требующая только PAM да OpenSSL

Верно. Вот только бывает ещё и

ssh -X

ААА! ssh поддерживает X'ы! На сервере ssh не место!

:)))

>Дык будущий RHEL - на базе 6-й Федоры

Будущий должен быть на базе пятерки, если не ошибаюсь.

> Лучше заскриншоть.

завтра утром выложу, дома debian sarge

>Requires: packageA || packageB

А ты мне покажи такую программу, где при сборке можно указать такую зависимость. Это раз.

Во-вторых, меняя зависимости, ты собираешь под себя. Ты не знаешь, какой пакет будет ставить?

> Ну а если смотреть на слаку - что, религия не позволяла ядро пересобрать? ;)

а rhgb не отвалится? оно вроде бы где то в initrd

Какок FC гогно, я понял спрыгнув на SUSE. Косяки тоже есть, но не как в этой вечной бете.

> Тогда - только небольшой набор пакетов. И то - с обновлениями могут быть трудности. Пример: обновилась софтина, в новой версии она использует новую библиотеку, которую раньше не использовала;

То major-апдейт, такие обновления (даже больше - такие софтины) на серваке недопустимы. Если совсем никак - это новый релиз дистра (или глобальный апдейт) с другими либками и механизмом подчистки старых.

> А это разве плохо? особенно если серван - не один... Меня всегда удивляли заявления слакварщиков о том, что тезис "машина должна работать, человек - думать", о том что разрешать зависимости нужно руками и деражть их все в голове - это хорошо, а когда это автоматизированно и это делает за тебя тупая машина - это плохо...

А зачем вообще часто и массово обновлять внутренние серверы предприятия, помимо секьюрити-фиксов в угоду безопасности, если они работают себе и работают? А если апдейт проверен на тестовых машинах и заведомо не нанесет ущерба, то пусть втыкается вообще автоматом с внутреннего сервера обновлений.

> Вы плохо представляете, что такое спеки/ебилды и чем оно отличается от просто сырцов и патчей. поэтому я даже спорить не хочу на эту тему :)

Скажем так - "ебилд = скрипту Bourne-shell, в котором есть ссылки (через переменные) на внешние функции-переменные", спек - та же самая фигня, только интерпретируется rpm-ом вместо шелла... принципиальных отличий, кроме requires/depend и тучи камментов в хвосте у спеков от слакбилдов нет в принципе :)

Задача одна - автоматизация сборки.

> Вы ещё не знаете, что 90% зависимостей в RPM-пакете получаются автоматиески при сборке 9в частности - зависимости на все используемые lib*.so.*)? Вы считаете, что все зависимости в пакетах жёстко прописаны "злыми мэйнтейнерами" чтоб вам усложнить жизнь?:)

Спеки генерятся почти автоматом? Если это так, то это круто :) А DSO может быть зависима как статически - через импорт в бинарнике, так и dlopen()'ом, такая зависимость сгенерится? Пример - ncurses+gpm.

А патчи и хаки - железно закладываются разработчиками, причем далеко не всегда по внятным причинам.

> Если "сервак" - то это значит, что я могу установить быстро множество "серваков", с разным набором сервисов и "не забыть установить все нужные либы" и "не держать всё это в голове":)

Так быстро = времени на tar cv | tar xf -, либо на мирроринг dd'ом, с установкой и настройкой только 1 машины, плюс потом пакетное изменение конфигов по ssh, если сильно такое нужно. "Быстро ставящийся сервер"? Зачем?

> Аналогично - с рабочими станциями. Вплоть до того, что у меня есть список необходимых для работы пакетов на рабочей станции, инсталлятор ставит мне только basesystem+apt, я делаю > apt-get install `cat список-пакетов` > и забываю до следующего обновления.

Так и у меня так - поставил, апдейтнул, клонировал, запустил-протестил, забыл. Причем очень возможно - вообще забыл, вплоть до полной замены железа.

В автоматическом отслеживании зависимостей конечно множество плюсов... но хочется, чтобы минусов не было вообще :)

> Вы ещё не знаете, что 90% зависимостей в RPM-пакете получаются автоматиески при сборке 9в частности - зависимости на все используемые lib*.so.*)? Вы считаете, что все зависимости в пакетах жёстко прописаны "злыми мэйнтейнерами" чтоб вам усложнить жизнь?:)
Не все конечно, но того что есть хватает чтобы испортить жизнь.
http://www.linux.org.ru/view-message.jsp?msgid=1161892#1162771
Ну почему в SuSE можно нормально собирать пакеты, а в FC через одно место?

> все равно слышно, не может быть гробовой тишины при включенном компе > Разве что полностью перейти на водяное охлажение...

Гробовая - это 0dB ? ;)

Фон в районе 19-20Дб обеспечить нет проблем (подразумевается режим низкого энергопотребления - я сразу упомянул), идеально гробовая - в районе 16-17Дб, его просто не будет заметно... при желании с моим домашним роутером можно спать в обнимку - там сплошь пассивное охлаждение, за исключением БП, который крутится на 500rpm максимум и точно также не слышен.

А водянка - это просто вода + низкооборотные вентиляторы, если нужно охлаждать штатно горячие (уже другая весовая категория) компоненты и не шуметь.

Таким макаром и OpenSLL и крипто-туннелям, которым вообще пофиг какой трафик шифровать, тоже не место -)

Часто приходится делать "ssh -X"? ;))

По аппроксимации таймлайна для GCC - могут не успеть дождаться 4.1.х, для х>=3,4. Хотя возможно... если сами и есть девелоперы GCC...

Какая лажа SuSE (для x86_64) - понятно сразу после установки :) Федора в разы круче ;)

В сюзе наверное процентов 70 софта пашет в режиме совместимости с х86-32, а памяти жрет и тормозит - покарай ее Аллах =)

А накоя мне *86_64 на моём 32битном атлонике?

10.1 пашет быстро жрать не просит. Работаю - кучу прог запущено, плюс апач и самба - занято всегда меньше 512 метров оперативки.

>ЗАЧЕМ НА СЕРВЕРЕ "свежий KDE, GNOME и много чего прочего" ?

Видишь ли, в RedHat apache зависит от XFonts, XFonts от XOrg сервера, а последний, очевидно, от KDE || GNOME.

> Молодец! Самое важное в серверах - это не обкатанные решения, а весь дистр, собранный последним, только что вышедшим gcc на последних, только что вышедших glibc! ;-)

Это ты на их сайте прочитал? последний gcc не собирает половину софта, так что что-то не верится, что они не используют gcc-3.4.

А в свопе сколько занято?

> Это зависит. Судя по обновлениям, все вышедшее достаточно стабильно. К тому же не вижу разницы между тем, что ты на старые glibc навешиваешь свои патчи или коммитишь их в ветку glibc и меняешь ее номер, вставляя в дистриб.

Ты немного подменяешь понятия. RH - мэйнтейнеры gcc и glibc. Они ЗАИНТЕРЕСОВАНЫ, чтобы новый продукт протестировало как можно бОльшее количество народу, чтобы устранить баги и выпустить подверсии без них. Чтобы стабильные программы и библиотеки вошли в коммерческий RHAS/ES. Я совсем не прочь потестировать, но только в том случае, когда у меня есть незанятые мощности и свободное время. Вот поэтому то я и говорю, что ставить bleeding edge, коим является FC, в production как минимум неразумно. Также неразумно, как и gentoo. Из этого вытекает:

> А ты предлагаешь на новом хорошем железе работать с RHAS/ES 2.1,3?

... что я предлагаю ставить RHAS/ES 4.3(или его бесплатные клоны aka Centos), если мы будем рассматривать RH-продукты.

> Это ты на их сайте прочитал? последний gcc не собирает половину софта, так что что-то не верится, что они не используют gcc-3.4.

Вообще-то ещё FC4 была ВСЯ собрана gcc4.

> затем, что: "чего не могу сказать о переходе с FC3 на FC4 (пришлось ставить начисто с перенастройкой из бэкапа)"

Да не, проапдейтил-то кое-как, но этому "кое-как" предпочёл заново поставить систему :)

>С учетом, скажем, второго сервиспака к win-XP, разница в пару лет несущественна...

Как показывают новые компы Apple - существенна.

В service pack два изменили firewall и исправили баги. Все.

Точно так же можем на rh 9 поставить свежие iptables и обновить багфикс.

Или может sp2 стал лучше поддерживать процессоры, у него улучшилось smp, появилась поддержка хардварного переключения между операционками?

Даже directx застыл - лишь добавляются dll-ки по месяцам (апрель, май и т.п.)

Смотрим на windows 2003 сервер. Рыдаем.

>Патчи к Х11 какой-то древнеегипетской версии (чуть ли не xfree86 3.3.6 или 4.0.0) - почему-то не коммитились в проект разработчиками на протяжении _лет_, и аналогий сему довольно много... Ведь не дураки же в Х-консорциуме собрались?

Дураки. Поэтому появился xorg, который за два года сделал больше, чем консорциум за много лет.

>Втыкание utf-8 везде где можно - сюда же? И что значит нормально - когда патченые на соответствие внешнему виду, плюс кое-что еще КДЕ, ОпенОфис и т.д. начинает жрать памяти в полтора раза больше нативного под платформу (например собранную под Генту) - это считается нормальным шагом в развитии дистрибутива?

Вы не любите китайцев и у вас не было трех-четырех язычных систем? А в курсе, что винды полностью внутри юникодные? И уж open office жрет ровно столько же, сколько и нативный, только работает быстрее.

Я ставил недавно русскую сборку.

>Придраться не к чему, они также сами и говорят - "на свой страх и риск, с нас - никакой ответственности, да еще и потестим на вас же".

Да. Это одна из целей этого дистриба. Кстати, хочу заметить, что gentoo пользуется наработками fc, как и debian. И обратный процесс тоже наблюдается.

А что, какие-то проблемы с тем, что дистриб, на основе которого потом делаются промышленные решения, раздается бесплатно, со всеми технологиями? Или может gentoo что-то гарантирует?

Или может быть microsoft предоставляет какие-то космические гарантии?

>он мне ничего не писал, сказал лишь что ты ему ничего не ответил

Думаю, стоит посмотреть еще раз.

> Я не говорил, что я пользователь yum. Я пользователь rpm+apt (пока что, потому что rpm своей "дубовостью" уже начал доставать)

Ну вот всё и прояснилось, не знаю в чём там у Вас, а если очень надо, можно и самому rpm-пакеты пересобрать с нужными параметрами, никаких особых проблем не возникало, только мне проще и быстрее было напрямую из нормальных сорцов собрать (если что-то некритичное).

А deb-based системы всегда мне нравились своим богатством пакетами. В общем-то Xubuntu меня не разочаровал, хотя мне FC5 больше нравится своей продуманностью и гибкостью возможностей, которые так-называемому "конечному пользователю" не понять.

>Временные затраты... по сути в LFS нет только пакетного манагера... а бинарники выходят теми же самыми... и все упирается в тестирование, которое для слаки, lfs и федоры займет примерно одинаково...

Ну rpm прикручивается туда за пять минут, если интересно.

И тестирование у FC уже есть. Оно спускается с предыдущих версий, с коммерческих релизов и т.п. У слаки оно тоже по идее должно спускаться с предыдущих версий. Насчет коммерческих релизов не уверен.

>Я уже смотрел на размеры патча для XEN и число затрагиваемых файлов в сорцах ядра... ужоснах, извиняюсь за выражение :) ноги его не будет на продакшн серваке :)

Это ты сейчас так говоришь. Будет другая задача - будет у тебя xen.

>Консольно залогиниться будет можно, но когда либка слинкована относительно другой отсутствующей - и с учетом зависимостей оные пакеты более высокого уровня просто не поставятся. Много останется от десктопа? И в свое время было... OpenOffice+PAM, от которого было зависимостей - полторы строки где-то в сорцах...

Значит на сервере тебе иксы не нужны. Там, где они нужны, можешь логиниться не в гном. Гном без hal тоже работает, но не все компоненты. А если не работают все компоненты - по кой черт выдирать его оттуда?

> ААА! ssh поддерживает X'ы! На сервере ssh не место!
> 
> :)))

Особенно когда на сервере UTM5 стоит? :/

>а rhgb не отвалится? оно вроде бы где то в initrd

С чего? У тебя там стоял патчик. Патчик убираешь - и собираешь. И еще же mkinitrd есть, если что.

P.S. А сильно был нужен rhgb?

>В автоматическом отслеживании зависимостей конечно множество плюсов... но хочется, чтобы минусов не было вообще :)

Хочется дом на Рублевке и что? ;)

>Ну почему в SuSE можно нормально собирать пакеты, а в FC через одно место?

А с каких пор kpdf работает без KDE?

Остальное да, собирается по максимуму.