линус о микроядрах (программистское)

[avva]

"I think microkernels are stupid. They push the problem space into *communication*, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix. They also lead to horrible extra complexity as you then have to fight the microkernel model, and make up new ways to avoid the extra communication latencies etc. Hurd is a great example of this kind of suckiness, where people made up whole new memory mapping models just because the normal "just make a quick system call within the same context" model had been broken by the microkernel model.

Btw, it's not just microkernels. Any time you have "one overriding idea", and push your idea as a superior ideology, you're going to be wrong. Microkernels had one such ideology, there have been others. It's all BS. The fact is, reality is complicated, and not amenable to the "one large idea" model of problem solving. The only way that problems get solved in real life is with a lot of hard work on getting the details right. Not by some over-arching ideology that somehow magically makes things work."

Comments

[mfi.livejournal.com]

raw devices Oracle - типичный пример неработоспособной архитектуры. Базе нефиг ходить на диск в обход FS, ибо (неуклюже и неумело) пытаясь решить локальную задачу скорости доступа, разработчики выпускают из вида все остальные проблемы, решаемые FS, в частности - maintanance, moving/backup data, dynamically increase/decrease space, отказываясь от всех наработанных десятилетиями разработчиками-профессионалами в FS плюшек. При этом еще и в скорости доступа особых успехов не наблюдается. Так что сегодня raw-device-ами в Оракле балуются лишь дикие китайцы, начитавшиеся старых мануалов.

(к слову - попытки написания железячными компаниями софта, оставляет тяжелое впечатление; не менее тяжелое впечатление оставляет попытки написания Ораклом утилит поддержки базы или любая другая попытка выйти за пределы сферы своей компетенции - создания реляционной engine).

[nec-p1us-u1tra.livejournal.com]

+2048 к обоим постулатам.

[edo-rus.livejournal.com]

а как без raw device решить проблему двойного кэширования?

[mfi.livejournal.com]

Просто следовать рекомендациям Оракла. И никаких проблем с двойным кешированием :-)

[edo-rus.livejournal.com]

гхм… а как быть пользователям остальных субд? ;)

afaik двойное кэширование в том же postgresql — неизбежное зло, с которым предлагается просто мириться

[mfi.livejournal.com]

Я вообще не понимаю, в чем проблема "двойного кеширования". Журнал или записан или нет. Если да - транзакция восстановится. Если нет - нет. За 15 лет работы с ораклом, у меня таких проблем просто не было. Сам факт прохождения данных через разные кеши меня не трогает. У жесткого диска тоже кеш есть и у EMC тоже. Т.е. не понял, что за беда?

Погуглил, нашел какие то странные левые варианты для писишек. И замечательный текст: "Некоторые трахнутые маньяки почему-то считают, что полное отсутствие дополнительного кэширования, особенно в сочетании с raw devices, имеет бешеное преимущество по скорости. Тут следует заметить, что, во-первых, не бешеное, а всего лишь 10-15%. Интересующихся, кто это сказал, отсылаю читать трахнутый оракловый мануал Performance Tuning Guide, особенно его приложения. Во-вторых, такие джентльмены волокут БД на raw devices, напрочь игнорируя тот факт, что даже эти 15% они могут получить лишь при адекватном тюнинге инстанса и, в особенности, при выставлении величины предвыборки Оракла в максимум, и, перед этим, такой же установки на уровне ОС и ее драйверов SCSI. В остальных случаях маньяки по заслугам получают усложнение администрирования до предела, холодный физический бэкап средствами dd а также отсутствие сверхзвукового выигрыша и, благодаря этому, проводят время не за пивом-ца-ца, а за консолью, в ожидании завершения процесса. :) Ах, обманули! Где быстрая работа баз данных? Где вообще скорость дисковой системы? Как посекторно? Ой, восстанавливать физический бэкап посекторно?! Нам не сказали! То есть как ASM и RMAN? Мама, роди-ка меня обратно!"