>> они, э-э-э-э... слегка подлягут на полчасика -- С ТЕХ ПОЛУТОРА СИСАДМИНОВ
>> НИКТО НИЧЕГО НЕ СПРОСИТ.
> Фокус в том то они слегка не подлягивали на полчасика почему-то.Вас, как я погляжу, на Google забанили. :)
http://www.google.ru/search?q=wikipedia+outage
И даже напобольше, чем на полчасика. Весьма вероятно, что замени они Линукс на FreeBSD, ничего бы не изменилось в случае их outage'й, а может быть, что и изменилось.
Но история сослагательного наклонения не терпит -- сервера Wikimedia ложатся, ложатся регулярно и надолго, и работают они на Линуксе. :)
> Зато примеров когда подлягнуло коммерческое решение за которое уплачено - да полно.
Согласен.
> Кхм, если иногда читать новости, можно обнаружить много случаев когда обещали
> но шикарно сфэйлили. Вплоть до серьезного завала амазоновского облака и сбоев
> затронувших толпу клиентуры. Но вики почему-то в этих новостях нет.
Потому, что Wikimedia НЕ ОБЕЩАЛА, а не потому, что она НЕ СБОИТ. Feel the difference.
> Капитан подсказывает: админить зоопарк из нескольких наименований - несколько сложнее
> и затратнее чем однотипные кофигурации.
Нет, это не так. Гетерогенную сеть админить, как правило, легче и проще, чем гомогенную, если, конечно, речь не идёт о вычислительном кластере-числодробилке.
Функции сетевых серверов неодинаковы, и если на каждый сервер поставить то программное обеспечение, которое разрабатывалось именно для решения тех задач, которые должен решать данный сервер, суммарные расходы на администрирование будут меньше, чем были бы, если заставлять программное обеспечение решать несвойственные ему задачи.
Взять, к примеру, задачу о 'light server partitioning': есть FreeBSD/Jail (технология, которой много лет), есть Linux Containers (экспериментальная).
Они обе в общем-то довольно прилично работают, но в Линуксе вылезают странные архитектурные проблемы, которых во FreeBSD почему-то нет: /dev в Jail'е работает великолепно, в LXC отсутствует, как класс, ибо ядро не умеет вызывать udev helper в пятнадцати виртуальных машинах. Нет, не то, чтобы это СИЛЬНО мешало -- mknod никто не отменял -- но неприятно.
Во FreeBSD есть разделение файловых иерархий на базовую систему и пакеты => базовую систему можно смонтировать по nullfs в сотню jail'ов и атомарно их патчить в случае проблем с безопасностью, просто перестроив мир в базовой системе. В Линуксе так сделать по очевидным причинам не получится.
И вот тут-то и вылезает overhead на системное администрирование: когда у вас на сервере чуть больше, чем LAMP крутится, всё становится очень и очень печально с Линуксом.
>> 1.6.2 есть неприятная бага, когда на SIP-абонентах, работающих по TCP, включён
>> qualify, Asterisk рушится. Как обычно, NULL pointer dereference. В багзилле эта
>> бага есть. И рушится Asterisk прямо при старте.
> И конечно виноваты в этом дебианщики?
В чём именно? В том, что в Asterisk'е бага, или в том, что бажная версия попала по каналу security update?
В первом -- разработчики Asterisk'а, конечно.
Во втором -- Debian'щики. А кто? Владимир Путин, что ли? Дистростроители -- это что, роботы, тупо упаковывающие софт в пакеты, да?
> Кстати по уму админ должен бы тестить апдейты в лично своей конфигурации на тестовой
> машине и только потом, если изменения успешны - апплаить на боевую.
Весьма распространённое заблуждение админов локалхоста.
На БОЛЬШИНСТВЕ современных серверов стоит уникальное оборудование, которое в машину админа поставить довольно накладно. FC SCSI, к примеру. Или TDM-мультиплексоры. Или криптоакселераторы.
>> история поддержки FreeBSD БЕЗ ИСКЛЮЧЕНИЙ показывает нам, что описанное ниже --
>> факт), что автоматическая установка Security Fix'ов НИЧЕГО мне не сломает.
> Рискнете расписаться за все программы и ядро, на 5 лет вперед?
Рискну на 50. Линуксоидам не понять. ;) Они читать не любят. И "Cathedral vs. Bazaar", как правило, не читали.
(Памятна одна моя полемика здесь же, когда человек в качестве аргумента ссылался на этот опус. Но на мою просьбу привести номер страницы, где написано то, что он говорит, так и не откликнулся. То ли арабских цифр не знает, то ли...)
> А если ставку до хотя-бы $100 поднять, рискнете? :)
Да хоть до $1 000.
Security fix'ы в RELENG_X_Y специально аудитятся так, чтобы ничего не ломать. Людьми. Неглупыми довольно. ;)
> Ага, поэтому наверное список рассылки нжинкса пестрит сообщениями о очень стабильной
> работ фряхи, которая норовит там и тут повиснуть или спаниковать.
Что касается вызова panic(), то не надо забывать, что если бы Линукс вызывал panic() всё время вместо OOPS(), тогда с системой вообще работать нельзя было бы. :)
Линуксоиды эпично зафейлили отладить ядро до работоспособного состояния, и отказались от концепции паники при ошибках ядра, пытаясь рестартануть подсистему. Получилось такое вот "ни два, ни полтора" -- и не микроядро, сервисы которого рестартуются очевидно, как, и не честный monolithic, который ОБЯЗАН считать, что ЛЮБОЙ OOPS() -- это ВОЗМОЖНОЕ повреждение управляющих структур ядра. Соответственно, всё, что не panic() -- то небезопасно.
А OOPS()'ится Линукс совершенно эпично. Просто большинство админов локалхоста не имеют возможности с этим проэкспериментрировать. А я имею такую возможность. У меня есть USB-хабы с десятком однотипных USB-модемов. Вот если его включить в машину с Линуксом... :))) Да ещё несколько раз "повтыкать-повытыкать"... :))) У меня Debian v6 зависал "вхолодную", до reset'а. :)
> Википедия почему-то не падает,
Да. Как и Plasma в KDE. Не знаю, что все так на KDE 4 ополчились... ;)
