Забавный шыз

Ляснулся на работе дебиан. Грузится, нормально, запускает иксы - бабах, виснет, на мониторе жабы, сети не видит и на клавиатуру не реагирует никак.
Ну ладно, загрузили в single-user, убрали запуск иксов, сижу вкуриваю логи.

Обнаруживаю такую картину:
Все работает как и работало
Подключается и обнаруживается носимый usb-винт.
Через 2 минуты - от кого-то коннект к acpid и через минуту гамон всему.

Дальше - по кругу: перегрузка, запуск иксов, коннект к acpid, гамон всему. При этом еще появилось из ниоткуда новое устройство типа "pci_8086_2562_drm_i915_card0", обращение к которому там же, в районе коннекта к acpid и гамона.

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

По мотивам

Навеяно жабо-ООП-срачем:
Куда конь с копытом, туда и рак с клешней — І жук, і жаба, і чорт, і баба = Каваль каня куе - і жаба нагу дае = Як каня куюць, то й жаба нагу настаўляе

Границы применимости решений

Вот тут и тут идут практически идентичные срачи на тему "Зачем юзать (дорогую, энтерпрайзную, сложную) технологию А, если можно воспользоваться (простой, дешевой, десктопно-наколенной) технологией Б?".

А я, честно говоря, совсем уже потерял нить рассуждений, и не могу толком ответить на этот вопрос. Т.е. для меня вещи типа "бухгалтерию на dbf файлах в 2009 году не делают" и "mysql не является базой подходящей для систем со сложными расчетами и высокой нагрузкой" являются как бы самоочевидными, поэтому поиском аргументов на эту тему я себя никогда не утруждал.

Ну вот всегда, когда сталкивался с решениями на основе dbf (клариона, фокспро, клиппера, access, итд) - всегда очевидно, что разработчики блядь говно тупые уроды ебаные троечники по которым агрогородки плачут отстали от современных технологий, неважно по какой причине, соотвественно, они не способны принимать участие в современных разработках, у них нет для этого мыслительных категорий.
То же самое mysql, который в старых версиях, насколько я помню, вообще толком никакой логики на стороне сервера не содержал и транзакции умел только с одним типом хранилища. Для меня самоочевидно, что транзакции - это благо. И самоочевидно, зачем нужны вещи типа Software Transactional Memory и зачем нужны проверки целостности на стороне БД. Но большому количеству разработчиков это просто непонятно - я уже писал когда-то про попавшуюся под руки базу, в которой FK не было вообще.

С другой стороны - у меня в проекте Firebird молотит данные сотнями записей в секунду на обычном железе, с одновременными массовыми перерасчетами, и ничего. Хотя как бэ и СУБД тоже из разряда тех, на которые тупые линуксоиды наезжают в стиле "это же говно, потому что я так считаю".

И вот получается, что границы применимости решений (в данном случае СУБД) становятся совершенно непонятными. Очевидно, что при желании все недостатки отдельной СУБД можно обойти в программном коде. В экстремальных случаях это получится полное повторение функционала, уже существующего в другой СУБД, и это не всегда плохо - некоторые вещи настолько сделаны чрезмерно сложно и методом постепенного добавления фич, что переписывание с нуля их только улучшит.
Но вот где граница - "берем Postgresql, программиста и линуксоида на обслуживание" vs "покупаем Oracle, покупаем DBA, покупаем страшный софт за бешеные бабки и считаем что мы круты" - непонятно. Исключая, конечно, момент откатов за софт, тогда второй случай безальтернативен.