LiveStreet

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

Конфигурация: i7 + Z68 + видяшка nVidia + дофига памяти + дофига sata дисков  (в т.ч. и с SRT), привод так же sata

Удачной установки. На моей машине инсталлятор даже запуститься не может (и LiveCD туда же).

«на чем вы собираетесь продолжать разрабатывать высокопроизводительные системы, компиляторы и ваши любимые побрякушки»
Все это продукт прямых рук, что не имеет никакого отношения к поросшему мхом и лишайником C++. Компилируемые языки одним C++ не ограничиваются. А то, что в итоге приложение на C++ может получиться немного более производительным, чем на каком-то другом языке, обычно связано с недостаточной оптимизацией в компиляторах этих языков (из-за их «молодости» или лени компаний разработчиков).

Phone 7 не видел живьем, но скриншоты мне напомнили множество обыкновенных «аппаратных» мультимедиа плееров.

Честно говоря, чтобы сделать какие-то конкретные вещи, не только СПО не поможет, но и куча коммерческого софта, поэтому многие крупные киностудии держат штат разработчиков и исследователей в области компьютерной графики.
P.S. Удачи вашей студии. Сами когда-то начинали с создания фильмов «подручными средствами» :)

У меня FF5 сам установился под линуксом в качестве обновления, и в нем firebug как работал, так и работает. Сейчас специально проверил.

Может я вообще по меркам правительства пират какой?

Скорее диверсант или террорист :) Как минимум ставил под угрозу безопасность и работоспособность госучреждений. А то ведь мог бэкдоры и ботнеты сделать для своих и не только своих нужд :)
Шутки шутками, но на практике желающие могут в своих целях любые действия представить в каком угодно свете. Потом попробуй докажи.

Меня в юнити еще раздражает отсутствие аналога меню, которое открывалось по правому клику на кнопке окна в панели (там были всякие пункты типа переместить, изменить размер и т.п.). Ну вот не знаю/не помню я сочетание клавиш, которое вызывает, например, включение перемещения окна, и что теперь? Смириться с тем, что убежавшее заголовком за край экрана окно навсегда потеряно?

Почему не стыкуется?
Поток синхронно вызывает flexsc_wait, когда ему надо выполнить все накопленные вызовы, в данном случае это делает библиотека FlexSC-Threads ровно для одного сискола, но сами вызовы flexsc_wait из разных потоков никак не взаимосвязаны, за счет этого и получается увеличение производительности, правда, при условии, что сисколы от всех потоков валятся прямо лавиной.

А ответ на вопрос «когда же реально произойдут сисколы?» кроется в этой фразе: «Приложение, пожелавшее использовать механизм FlexSC, делает системный вызов (классический) flexsc_register(), в результате которого ядро выделяет нескольких страниц памяти и создает новый внутриядерный поток, который в будущем будет обслуживать интерфейс FlexSC для этого приложения.»
Вот когда этот самый внутриядерный поток получит квант времени, тогда и выполнятся.

Хотя может все и не совсем так. Без деталей реализации трудно рассуждать.

Однако для многопоточных приложений выигрыш оказывается значительным, так как FlexSC позволяет группировать исполнение системных вызовов многих потоков (которые просто по определению не могут быть взаимосвязанными).

Вот даже как… «по определению». «А мужики то не знают!» :)

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

Судя по всему, никак. Дергает каждый раз. Если повезет, и в очереди окажутся вызовы из других потоков, то станет немного быстрее.

А при чем тут кинопроизводство? В кинопроизводстве свои очень специфические задачи и условия. Софт (или какие-то алгоритмы) часто пишутся под конкретный проект. В кино главное быть первым, а кто там дальше будет пользоваться наработками уже никого не волнует, тем более, что стоимость разработки включена в бюджет фильма. Именно по этой причине киношники так легко «разбрасываются» своими достижениями в софте. А Линукс выбирается в качестве платформы исключительно из-за своей дешевизны ибо для рендеринга всяких штук нужно очень много машин.

В фотосфере ничего такого нет, поэтому присутствует злая конкуренция. Да и кому поддерживать то? Производителям фотокамер оно совершенно не нужно, т.к. у них есть свой софт (зачастую платный) + сторонние компании вроде Adobe, которым свой кусок тоже терять не хочется. В общем, я себе слабо представляю, кому реально бы было выгодно поддерживать подобные проекты финансово. Разве что какие-то общественные организации фотографов, но там обычно тусят профи, а им проще купить коммерческий софт, денег у них хватает.

А жить то людям на что? Разве что гранты какие, да и то сомнительно.

Странно как-то… Там расписаны нововведения OpenOffice, которых вроде как нет в LibreOffice, а в конце утверждается, что у LibreOffice больше функций.

Это называется красиво? Не спорю, что шрифты M$ качественнее, но отключать сглаживание… Тем более, что в Ubuntu (и многих других дистрибутивах) применяется сглаживание подобное маковскому, а не виндовому.

Интерфейс и модули обработки в лайтруме далеко не самое главное. Сомневаюсь, что дарктейбл способен дорасти до уровня лайтрума. Беда в том, что закодить нечто бесплатно народ еще может, а вот проводить сложные научные исследования, чтобы получить алгоритмы обработки и коррекции на уровне коммерческих, никто не будет. Это совсем другой уровень деятельности, и подобных специалистов не так много, чтобы они могли тратить свое время на открытые проекты.

Разве ДубльГИС свободное ПО? Но это так, к слову пришлось.

Кто-нибудь знает кроссплатформенный ГИС, который имеет поддержку мониторинга (как минимум такую возможность на уровне api)?

Бота можно сделать вообще не трогая код игры. Сложнее, но можно. Поэтому анализ на сервере все равно придется делать. Либо сделать архитектуру модифицируемой (не защищаемой) части игры такой, что читерского бота в ней сделать нельзя.

Шифрование обмена с сервером на основе загруженного в память кода ядра игры, которое не должно быть подвержено изменениям со стороны моддеров.

Бинарное содержимое ядер всех версий известно (и алгоритм использования этого содержимого в процессе шифрования), поэтому если ядро не затронуто, то на стороне сервера данные будут расшифрованы без проблем. Если ядро изменено, то хендшейк просто не пройдет (или в процессе передачи данных что-то нарушится, если код незначительно изменен). Главное, во-первых, чтобы код ядра был использован в шифровании максимально широко. Например, хэши от большого количества ячеек, выбранных в псевдослучайной последовательности, ну и, во-вторых, чтобы код самого взаимодействия с сервером так же входил в ядро.

При таком раскладе даже наличие исходников клиента и сервера ничем не поможет.