Да всё просто, на самом деле.
1) Кто-то считает, что стыдно не знать
2) lmgtfy.com/?q=iddqd&l=1 — это было бы быстрей

хобровчане* поняли, что чтобы понять шутку, надо понять шутку не знать, что Doom 2D — клон, не имеющий отношения к ID Software, всего лишь перенявший** чит коды оригинала***

* по состоянию текущего грамматического воспитания

** т.е. вторичный

*** Doom и Doom 2, как написано комментарием выше

нэ?

DVD9 смотрелся лучше чем BDrip, ибо рипер был лох, и не смог сделать апскеил

если это именно BDrip, то там не было никакого апскейла. апскейл — это увелечение разрешения.
а зачем увеличивать разрешение у итак HD-шного видео?

вы в терминах путаетесь

упс, опоздал :)

вы не поверите, но это цитата как раз оттуда :D не первой давности.

Жаль, что мысля о том, что хабр — IT-ориентированный блог, а башорг — юмористический цитатник, не посещает мозг сотен и сотен.

friendfeed.com/13pm/5b7bcdc0
%)

Надпись об авторстве присутствовала с момента создания топика ;)

Если используете M2 и/или RSS-клиент оперы, то я бы поглядел в ту сторону. После внештатных завершений там, бывает, что-то портится.

Была аналогичная проблема, помог откат на какую-то версию постарей, потом снова обновление. Шаманство, конечно, но тем не менее — прецендент.

Mint 7 KDE (та же Kubuntu 9.04, вид сбоку). Qt4 билд.
Открыто семь вкладок, на двух из них — флэш. Открыто в течении вот уже 7 или 8 часов.
0-2% загрузки проца. Память тоже, кстати, не утекает.

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

Комментарий от 22 мая в посте от 17 июня оО. Круто попробовали.
Или был черновик, там комментарий, а потом черновик превратили в нормальный пост?

А, ну и самое главное я упустил. Для серверного решения безгранично важен синхронный доступ к данным. По этой теме надо гуглить и гуглить, читать и читать. До посинения. Один из самых сложных моментов в программировании серверов. Не знаю ни одной книжки или статьи, где это было бы раскрыто полностью.

Посоветуйте ссылки или литературу, если такая есть, для ознакомления и погружения в эту тематику.

Литературу вряд ли какую смогу посоветовать. Точно могу сказать только одно. Если идёт ориентация на realtime системы, то необходимо знать ассемблер, логику работы процессора, вариантность архитектур, на которых будет работать приложение. Нужно представлять в какой машинный код преобразуется та или иная команда высокоуровневого языка. Ну, то есть — знать ассемблер %)

существующие практики и/или инструменты (желательно open source) организации распределенных БД, распределение нагрузки, кэширование и т.д.

Open source не блещет выбором. PostgreSQL либо MySQL.

Также было очень интересно взглянуть на сравнительные характеристики производительности популярных БД (MySQL, MSSQL...)

Всё просто, как топор.
MySQL:
-очень быстрые запросы по простым таблицам
PostgreSQL:
-быстрые insert'ы
-быстрые сложные запросы
-язык PL
-медленее MySQL'я на простых запросах
MS SQL:
-невероятно медленные сложные запросы
-не очень сложные запросы быстрее MySQL
Oracle:
-быстро всё %) лучшая БД, имхо. но и цена…
BDB и DB2
-очень сходны с MySQL. в чём-то лучше, в чём-то хуже. тут, для выбора, уже нужны тесты на конкретных базах.

Про распределение и кэширование сложно написать в комментарии. Это темы для 3-4-х статей, минимум. Для кэширования сейчас, в частности, используем PostgreSQL с memcache плагином. Он ломает логику транзакционности, но главное — об этом не забывать и использовать только там, где нужно.

Этот ответ тоже будет очень субъективным. Не воспринимайте его как догму. Просто опыт.

В чем преемущества (может есть и недостатки) *nix систем перед серверными системами от Майкрософт?

По большому счёту, преимуществом я могу считать только одно — стабильность. Быть может виноваты кривые руки наших админов, быть может — железо. Не берусь утверждать. Но, тем не менее, факт. Есть сервер, к которому очень много обращений в сутки со всей страны. Изначально был Windows Server 2003 R2. Так исторически сложилось. Ещё до моего прихода. BSOD и его последствия случались раз в 3-4 дня. Причину не могли найти. Программа была чуть-чуть допилена под никсы. Поставлен дебиан. Седьмой месяц аптайма. Ну и плюсом — порой дичайшая логика API от MS. Сильно усложняет разработку. Возможно, в нелогичности этого же апи кроется причина наших былых багов.

Какие типы БД (реляционные, объектные, может другие вообще решения) лучше всего подходят под задачи с большой нагрузкой?

Всё очень сильно зависит от типа задач. Признаюсь, «нереляционных» БД использовать не приходилось. Просто не было случая, когда иерархическая модель или объектный подход могли явно дать какие-то большие плюсы. Да и вообще, мне достаточно сложно представить себе ситуацию, когда они могут пригодиться. Зачастую важнее именно сам способ работы базы. К примеру, PostgreSQL — это форкающаяся СУБД, а SQLite — последовательно выполняет всё в одном потоке. В случае, когда мне надо со скоростью 2000 раз в секунду читать однотипные данные из простой редко обновляемой таблицы, я использую SQLite, а когда таблица постоянно меняется и запросы сложны — Postgres.

БД Вы имеете в виду общие, или специализируетесь на чем-то конкретно?

У меня достаточно большой опыт работы с MySQL, MS SQL, Oracle, PostgreSQL, DB2, Berkley DB, SQLite, Firebird, и даже memcache, хотя это сложно назвать БД. Так что охват рынка — 99% :) Можно спрашивать почти обо всём.

А что такое «тролль»?

Не обещаю, что ответ будет полностью объективным. Лично я в этой технологии не разбираюсь совсем — не доводилось сталкиваться. Но могу привести факт из опыта:
У меня работает программист, который в определённый момент пришёл с докладом, что перевод одного из наших модулей на kqueue, вместо форков, увеличит эффективность. Дал ему переписать модуль в отдельной ветке. Получили приблизительно 15% потери скорости и 35% выигрыша памяти. Сейчас используем именно его модуль, потому что расход памяти критичен. Как там внутри всё устроено — не знаю. Возможно, можно было написать с меньшей потерей производительности, а то и вовсе быстрее оригинала.
Так что «ересью» точно называть не стоит.

Программирование высокопроизводительные серверных решений на C. В основном — под *nix системы.
Планирование БД для высокой нагрузки..
Служебных тайн раскрывать не буду, но на общие вопросы, а-ля, в каких случаях лучше форки, а в каких треды, отвечу :)