Что на этот раз?

> Что на этот раз?

тоже самое что и в прошлый, опять федора повисла

>Это у меня так, или у широкой общественности аналогично?

Аналогично.

http://www.linux.org.ru/jump-message.jsp?msgid=1026099#1030806

А кроме федоры дистров нет? Из основных хотя бы SUSE, Ubuntu, Debian, Slackware, Gentoo.

Гриныч вообще укурился? Десктопный дистр на сервер ставить.

>Гриныч вообще укурился? Десктопный дистр на сервер ставить

действительно, нафуя федору воткнули?

Не столько десктопный, сколько бета-тест Red Hat.

сначала бесплатно(для себя тоже ;)) тестят, потом за денги продают.

ЗЫ целый ЛОР бета тестеров.

Гы - я тут случайно толи трабл толи плохоработает с 3сом сетевухами, причем не со всеми, а выборочно :(

Есть мнение что фелора ни разу непричем. Проблема с большой долей вероятности находится в 2.6 ядре. А поскольку _современные_ дистры с 2.4 ядром мне как-то не вспоминаются, то те же проблемы наблюдались бы и на любом другом.

> А поскольку _современные_ дистры с 2.4 ядром мне как-то не вспоминаются

slackware?

Я не зря подчеркнул слово "современные"

есть тут в моём хозяйстве компик, ничего особенного: асус АИ сириес, пень4, сата хард + е1000 сетевухи интеловские. так вот федорин инсталер даже ядро не мог загрузить, дебиан не хотел поднимать е1000, хотя модуль грузился, а слака /недаделанная, убогая, где чёрт ногу сломит куда что, неадекватная, etc/ поднялась с полпинка и прекрасно работает, к чему бы это?.. ;)

> Я не зря подчеркнул слово "современные"

тоесть без второго апача, пятого пхп и селинукса уже никуда? причем все это, кроме селинукса, в ней есть

"Ты просто неумеешь их готовить" (c) ;)

Зато в ней нет rpm, в ней нет компании с деньгами чтобы обеспечивать саппорт, нет армии тестеров и армии хорошооплачиваемых дивелоперов. Фактически слака поднимает крошки с барского стола. А, и еще в слаке нету sysv-init style инит скриптов ;)

наверное :)

> Зато в ней нет rpm

есть

> А, и еще в слаке нету sysv-init style инит скриптов ;)

есть

вообщем вывод такой, ты захотел "современный" дистрибутив, вот и получи "совеременные" глюки ;)

Rpm там есть совсем не в том виде. (rpm --nodeps - это НЕ rpm, с тем же успехом можно ставить tar.gz)

В чем там заключается наличие sysv-style инит скриптов? Все стоковые пакеты которым это нужно их используют?

Глюков "современного" дистрибутива пока не замечено. Замечены глюки "современного" ядра.

>_современные_ дистры с 2.4 ядром мне как-то не вспоминаются

Debian

А это точно не железо? Точно?

Debian stable, как всем известно, это сборище древностей. unstable/testing полон глюков которые никто толком не отлавливает. Debian'овские маинтайнеры пакетов позволяют себе ответить на засабмиченные баги (с патчами) через год(!)...

> Rpm там есть совсем не в том виде. (rpm --nodeps - это НЕ rpm, с тем же успехом можно ставить tar.gz)

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

все кроме resin в слаке присутствует, секьюрити обновления в курренте есть

так что мешает использовать слаку, религия?

> В чем там заключается наличие sysv-style инит скриптов? Все стоковые пакеты которым это нужно их используют?

все пакеты собранные Патриком используют bsdinit

> Замечены глюки "современного" ядра.

попробуй откатится на федоре обратно на 2.4 ;) вот они "современные" дистрибутивы!

Проблемы начались сразу после переезда на 2.6 ядро. Я счас воткну то ядро что стояло раньше и после этого станет понятно кто виноват.

rpm - это удобно. И да, удобный паккетный менеджер является одним из критериев хорошего дистрибутива и играет немаловажную роль в выборе. Да, перечисленный софт используется, однако до того как он начал использоваться его нужно было установить, его нужно постоянно обновлять... Слака - поддерживется непонятно кем и непонятно как (И неизвестно зачем). И будет несмешно если они завтра скажут что "всем спасибо, все свободны, нам надоело". Опять же поскольку в RH работают девелоперы многих основных пакетов, там имеется возможность получать обновления вовремя и все такое.

Ну, все пакеты используют bsdinit, а ты мне говоришь что есть sysv-init. Или есть возможность его использовать, но его никто не использует? Это и называется "нетут sysv-style init scripts" ;)

А что ты думаешь, сейчас откачусь на 2.4, а ты мне за демонстрацию выставишь вина ;)

> однако до того как он начал использоваться его нужно было установить, его нужно постоянно обновлять...

swaret --update, swaret --upgrade

> Ну, все пакеты используют bsdinit, а ты мне говоришь что есть sysv-init.

его используют пакеты собранные _Патриком_

никто не мешает тебе использовать sysvinit для пакетов собранных тобой или кем то другим, например для установленных из rpm

> А что ты думаешь, сейчас откачусь на 2.4, а ты мне за демонстрацию выставишь вина ;)

только если почтой ;)

Слакварь реально самный неудобный дистрибутив на свете. Перестать кричать "Почему не Слака" религия не позволяет? Может ты приведешь хоть 1 ее приемущество? Недостатков-то у нее масса.

Ну. Пакеты собранные Патриком. То есть все которые идут с системой! То есть если я хочу апач через sysv-style init, то я сношу патриковский апач и ставлю апач, например, из федоры? То же самое проделывается со всеми остальными пакетами.... И что остается от слаквари? ;)

Чотбы пакеты обновлять так как ты сказал, нужно чтобы кто-то выпустил обновления. И сделал это вовремя, и успел их оттестировать к тому же.

> То есть если я хочу апач через sysv-style init, то я сношу патриковский апач и ставлю апач, например, из федоры?

а зачем? чем апач собранный Патриком хуже федориного? тем более федорин апач кривой, на него все плюются

> Чотбы пакеты обновлять так как ты сказал, нужно чтобы кто-то выпустил обновления.

Патрик их и выпускает, причем оперативно

http://slackware.com/changelog/current.php?cpu=i386

> Слакварь реально самный неудобный дистрибутив на свете

ты просто не умеешь его готовить

> Может ты приведешь хоть 1 ее приемущество?

полная прозрачность настройки, никаких лишний костылей и прокладок

> Недостатков-то у нее масса.

приведи хотя бы один

s/лишний/лишних

Апач собраный патриком не использует sysvstyle init, таким образом как ты поступишь если решишь что тебе не надо стартовать в системе? А потом что опять надо? Редактировать руками /etc/rc.d/rc.inet2? очень смешно. Как ты предлагаешь перейти в single user mode, а потом обратно и чтобы сервисы какие надо легли и потом встали обратно?

Кстати лично у меня к федориному апачу нареканий нет.

Выпускать то выпускает, а тестирует? ;)

Хочешь пример "лишнего костыля и прокладки" которого нету в федоре и есть в слаке? adduser ;)

>Выпускать то выпускает, а тестирует? ;)

Зато мы имеем честь созирцать по утрам процесс тестирования Федоры ;)

Не Федоры, а ядра ;)

ok, ладно, расфлеймились тута... :)

> таким образом как ты поступишь если решишь что тебе не надо стартовать в системе? А потом что опять надо? Редактировать руками /etc/rc.d/rc.inet2? очень смешно

chmod -x /etc/rc.d/rc.apache, и апач стартовать не будет

> Как ты предлагаешь перейти в single user mode, а потом обратно и чтобы сервисы какие надо легли и потом встали обратно?

слака и это умеет ;) при переходе из однопользовательского в многопользовательский rc.M загрузится снова

поковыряй на досуге слакины скрипты загрузки, от бзди там не так уж и много ;)

adduser не костыль, это фронтенд для useradd ;)

chmod -x это костыль. Знаешь почему? А как ты скажешь что в runlevel 3 его стартовать, а в runlevel 5 ненадо? Опять же кроме апача погляди там в rc.inet2...

rc.M грузится снова, однако а прибивать кто будет лишние процессы? Причем только лишние, а не все подряд?

А слакины скрипты я смотрел, когда на ней жил, с тех пор немногое изменилось. Возмодно ты не дорос еще до нормальной системы. У тебя одна-две-три машинки на попечении и тебе не жалко тратить на них все доступное время. Лично у меня есть чем занять мое время, и помимо того еще у меня есть работа, на которой нужно работать, а мне за это дают денег ;)

на серверах у меня бзд ;)

CentOS??? И что-то там говорилось про патчик badram - может, в этом трабл?! :-/

Ну если у тебя на серверях BSD, то тут я тебе ничем помочь не могу ;)

А всетаки, чем реально не подходит Debian? Я так ни одной резонной причины и не услышал. В стейбле второй апач есть, яву любую поставить можно, php4 имхо сейчас куда стабильней пятого... Помоему весь необходимый софт.

Ну если уж так сильно тянет на извращения, то можно и в testing перебраться... Туда только самые мелкие баги попадают, но обновлений безопасности под него нет.

Вобщем ИМХО дебиан было бы лучшее решение, хотя каждый ССЗБ

Чем плох Debian отлично расказывает Alex Korchmar (смотреть в fido7.ru.linux). Помимо моего примера с тем как мне ответили на багрепорт через год после собсвтенно посылки багрепорта, приведу другой пример. Когда я еще работал в NAMESYS, нам вдруг стало приходить много багрепортов на падения reiserfsck. От пользователей Debian testing. Послед длительных (реально длительных) разборов, выяснилось что в дебиановской версии запихнут патч для big-endian support (при том что в более новой версии доступной на тот момент reiserfsprogs это уже было), причем этот патч никто нам не показывал, и нашего совета про его правильность никто не спрашивал, ясное дело. Патч этот, помимо добавления bigendian support, напрочь ломал битопсы на всех архитектурах, а в результате reiserfsck тоже не работало, ясное дело. Несомненно как только мы нашли причину, мы об этом сказали маинтайнеру пакетов и он выкинул кривой патч (который маинтайнер пакета даже не потестил, ясное дело, когда впервые его принял). Однако когда я через две недели заинтересовался судьбой фикса, выяснилось, что обновленный пакет живет в unstable, в testing по прежнему живет кривой пакет, а в stable находится такое старье, которое и не работало толком никогда.

Так что продолжайте пользоваться Дебианом. Это без сомнения отличный дистрибутив с отличноотлаженной моделью разработки и трекинга ошибок, доставки багфиксов пользователям и прочее и прочее.

> А как ты скажешь что в runlevel 3 его стартовать, а в runlevel 5 ненадо?

А зачем 1000 и 1 ранлевел на одиноко стоящем сервере? :)) Тем более, что 2-й и 5-й ранлевел у слаки - не используется(вернее "unused (but configured the same as runlevel 3)"

> Опять же кроме апача погляди там в rc.inet2

Да всё там прозрачно :) Набор запусков /etc/rc.d/rc.name

> У тебя одна-две-три машинки на попечении и тебе не жалко тратить на них все доступное время

Нафиг всё время то тратить? Небольшой парк машинок стоит на слаке - кушать не просит пости совсем :)

Раелевелы нужны. Разные. Singleuser mode это тоже такой runlevel, можно сказать. Опять же при ребуте сервисы может понадобиться не только убивать, но возмождн ои сперва стартовать ;)

Набор запускаов /etc/rc.d/rc.name это конечно клево (а раньше оно напрямую все стартовало, кстати), но однако добавить новый сервис или убрать (вместе с инсталляцией/деинсталляцией пакета) - тот еще прикол получается. Нужно ж еще угадать в какое место скрипта себя воткнуть чтобы все что тебе нужно уже стартовало, а все чему нужен ты - еще нет.

Слака не просит времени только если она ничего особо и не делает ;)

> Нужно ж еще угадать в какое место скрипта себя воткнуть чтобы все что тебе нужно уже стартовал

проще всего воткнуть в rc.local запуск нужного rc.proga

> Singleuser mode это тоже такой runlevel, можно сказать.

Ты будешь смеяться, но он есть :) Называется rynlevel 1

> но однако добавить новый сервис или убрать (вместе с инсталляцией/деинсталляцией пакета) - тот еще прикол получается.

Добавляется - легко. Если сторонний пакет ставишь, то у тебя файл незапускной появляется, потом chmod +x и всё. Деинсталляция - тоже легко - при нормально собранном пакете при removepkg тебе сразу видно, какой файл у тебя остался(etc/rc.d/rc.name.new удалить не может).

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

Это как раз достаточно просто :) неужели, если ты собираешь и ставишь программу в rpm, которой нет ни в в официальном репозита(о)рии, ни в неофициальных, система тебе сама разрулит, ПЕРЕД ЧЕМ ей надо запуститься и ПОСЛЕ чего? Извини, но я не верю :)

Можно и так. но если у тебя стоит(ДОПУСТИМ!) апач, обращающийся в постгрес, то его запуск должен быть ДО апача, который запускается ДО rc.local

Очень, очень смешно. А теперь представь что тебе нужно установить к примеру named, несомненно в rc.local ему самое и место, а то что в /etc/resolv.conf написано 127.0.0.1 это неважно. (вместо named, который есть в поставке (да-да, я так и вижу ваши аргументы), можно вокнуть кастомный туннель на который будет defaultroute и без которого тоже ничего не будет резолвиться и никуда ходить, или spamassasin и clamav, которые неплохо было бы стартовать до сендмейла, который их использует и тд....). Опять де если все пихать в rc.local, то установочным скриптам прийдется там пытаться соблюдать очередность запуска так же как и в rc.inet2

достаточно самому прописать их в нужной последовательности в rc.local