В целях эффективности арбитр должен выполнять все действия автоматически. Человеческий контроль за его работой может быть выполнен по логам. Впрочем, возможность контроля в реальном времени это не исключает.
То есть захостить сервер фанат может, а захостить арбитра он не может? В принципе, дизайн не запрещает совмещать сервер с арбитром. Это вопрос распределения уязвимостей: если верить арбитру, то можно и совместить его с сервером. Тогда если арбитр решит пожульничать, ему будет это проще сделать (предполагается, что сервер имеет больше информации, чем клиенты, и не все действия сервера клиенты смогут потом проверить). Если же сделать их раздельными, то секьюрность сервера напрямую зависит от секьюрности всей системы, но у арбитра будет меньше возможностей для неблагоприятной активности. Возможны также трудности в техническом плане (код сервера отличен от кода клиента, за ним приглядывать нужно особым образом — дополнительные расходы на реализацию и поддержку контрольного модуля для сервера).
К сожалению мои познания в области реверс-инжиниринга бинарников и взлома компьютерных программ чрезвычайно ограничены. Поэтому есть вероятность того, что нижеизложенное основано на неверных предпосылках.
Проведём параллель с играми в реальном мире. Кто присутствует на каждом футбольном матче? Арбитр. Третье лицо, которое знает правила и следит за тем, чтобы все игроки эти правила соблюдали, причём все игроки должны соблюдать одни и те же правила. Игроки (и зрители) также могут наблюдать за процессом игры и, в принципе, могут поймать арбитра на жульничестве (если арбитр начинает рандомно показывать красные карточки, то он либо дебил, либо куплен, либо сошёл с ума). Арбитр (как правило?) дорожит своей репутацией. Игроки доверяют арбитру по умолчанию.
С компьютерными играми можно сделать то же самое: взять некое третье лицо (не обязательно сервер, принадлежащий разработчикам игры) и сделать его арбитром. Арбитр следит, за тем, чтобы ПО всех игроков было одной версии, а также мониторит отчёты, которые ему в реальном времени посылает контрольный модуль, присобаченный к клиенту. Контрольный модуль будет реагировать на попытки модификации исполняемого кода игры на лету и другие распространённые методы взлома.
Как это стыкуется с СПО? Вот тут, в общем-то, и содержится основное слабое место этой схемы.
Контрольный модуль — это бинарник, причём крепко зашитый. Предпочтительно — зашитый каким-то очень случайным образом (я хз, как вообще это делается). Плюс, его код также может содержать случайные последовательности. В общем, любые методы, которые предотвращают автоматический взлом. Бинарник этот посылается арбитром одновременно всем игрокам. Возможно потребуется некая синхронизация передачи данных, чтобы все игроки закончили скачивать бинарник примерно в один и тот же момент. В этот момент бинарник активируется на каждом из клиентов и в течение N секунд должен законнэктиться (PSK, ключ вшит в бинарник) к арбитру и подтвердить свою подлинность и целостность. После чего он запускает игру, проверяет версию её модулей, и начинает следить за её процессами, предотвращая их изменение. Периодически (раз в M минут) арбитр генерирует новую версию бинарника и отсылает её игрокам вместе с исходниками предыдущей версии (таким образом игроки получают действительно свободное ПО — только с некоторой задержкой) и информацией о том, как расшифровать данные, которые передавал бинарник всё это время.
ПО игроков знает, как генерируются исходники контрольного модуля и что контрольный модуль может делать. Поэтому работающий параллельно с клиентом модуль контроля и наблюдения за модулем контроля может не позволять модулю контроля делать что-то, что ему делать не полагается (например пропатчить ядро). После получения очередной порции исходников и ключей для декодирования потока модуль контроля и наблюдения за модулем контроля может декодировать информацию (не обязательно в реальном времени, это можно делать параллельно, или вообще отложить декодирование на потом), которая была отослана ранее, чтобы удостовериться, что модуль контроля не посылал ничего инкриминирующего (в случае, если ему удалось обойти модуль контроля и наблюдения и всё-таки нарыть какую-то информацию), а также что арбитр не давал модулю контроля никаких читерских команд. Также игра записывает и шифрует риплэй (записывает и шифрует сама, ключ для шифрования получает от модуля контроля, этот ключ также раскрывается каждые M минут), после игры он может быть проанализирован для определения честности арбитра и игроков (поскольку система позволяет избежать модификаций клиента и шифровать передачи, можно позволить клиентам иметь исчерпывающую информацию о ходе игры — всё равно игроки не смогут ею воспользоваться в реальном времени).
То есть система основана на предположении, что можно генерировать бинарники, которые не могут быть взломаны игроками (и в которых зашитые ключи не могут быть найдены) быстрее чем за N секунд. Также предполагается, что игроки не могут модифицировать код модуля контроля после его запуска (или могут, но неспособны вычислить и внести все нужные изменения быстро и атомарно). Также предполагается, что игроки доверяют арбитру, то есть арбитры — не случайно выбранные компьютеры в Интернете, а вполне известные (имеют закрытый ключ для подтверждения) личности. Конечно, это не даёт 100% гарантию того, что они никогда не воспользуются получаемой властью в неправедных целях, но и в реальном мире никто этого не гарантирует. Кроме того возможности, которые дают им модули контроля, довольно ограничены.
Игра разбивается на несколько кусков, все важные для игрового процесса данные пересылаются через модуль контроля и поэтому передаются в зашифрованном виде. Куски, не содержащие влияющих на игровой процесс частей, могут модифицироваться свободно, модуль контроля не будет возражать. Куски, которые влияют на игровой процесс, в своей совокупности должны быть совместимы друг с другом и совместимы с клиентским кодом других игроков («совместимы» означает, что они поддерживают одну и ту же версию протокола и правил игры, они не обязательно должны быть идентичны с точностью до бита, т.к. могут быть на разных платформах), арбитр это проверяет по хэшам этих кусков (хэши считает и передаёт модуль контроля). Арбитр хранит у себя большой набор таблиц совместимости кусков по их хэшу, этот набор он также показывает игрокам перед началом игры (чтобы игроки знали, какие версии клиента поддерживаются). Одобренные как «чистые» версии происходят прежде всего из центрального репозитория сообщества разработчиков игры (подписываются релиз-инженером; списки одобренных версий регулярно обновляются), но арбитр волен поддерживать и модифицированные версии на своё усмотрение (главное, чтобы все игроки имели совместимые модификации).
Модуль контроля может посылать скриншоты (скриншоты делает игра) и данные о состоянии игры на момент снятия скриншота арбитру и другим игрокам, впоследствии их можно дешифровать (для игроков; арбитр может дешифровать в реальном времени) и проверить, что рэндэринг был проведён правильно. Это не очень красиво, но зато позволяет игрокам иметь любые версии драйверов, отвечающих за отрисовку (модифицируя рэндэрер можно, в принципе, добиваться прозрачности стен и других интересных и не совсем честных эффектов). Арбитр может сверять скриншоты с их ожидаемыми версиями (зная состояние игры, арбитр может сам отрэндэрить соответствующую сцену и автоматически проверить, что разница между изображениями не превышает погрешность).
Я тебя понимаю. Сам на дэльфе писал когда-то. Изучение GTK+ было для меня просто озарением :) С тех пор терпеть не могу тулкиты, в которых нет понятия контэйнеров для виджетов.
P.S. Про статью ничего не скажу, т.к. не читал (этот этап для меня вроде как уже пройден). Замечу только, что в некоторых случаях создавать виджеты в рантайме всё-таки надо. Лучшим решением в таких случаях является комбинирование Glade (для статических виджетов) и рантайма (для динамических).
А может просто «Office»? Можно будет постить туда всё, что вообще относится к офисному ПО.
Вопрос скорее в собственно цели существования отдельных блогов такого вида. Это для категоризации (чтобы посты о разных вещах были сложены в разные кучки)? Или для подписки (чтобы люди, подписавшиеся на апдэйты с блога, автоматом получали интересующие их посты)? Если да, то для чего тогда тэги?
LRN как всегда вылез невпопад:
Вспоминается выступление Моглена — «Freedom in the Cloud: Software Freedom, Privacy and Security for Web 2.0 and Cloud Computing». Там, в частности, было и про FB. EM указал на отсутствие необходимости в централизации социальных сетей и предложил перейти к распределённой модели, в которой каждый участник сам публикует свои данные (а сообщество СПО ему в этом помогает путём сборки соответствующего софта с соответствующим функционалом).
А, ясно. Просто Эрланг и Го — это единственные из известных мне языков, у которых многопоточнось вшита в сам язык. Поэтому подумал, что если Эрланг — значит будет мощный индустриального класса сервак с поддержкой хот-сваппинга, кластеризации и массовой многопоточностью.
В плане изучения функциональных языков я бы на твоём месте начал с Хаскелла, ибо он чист.
Что интересно: LibreOffice 3.3 вышел вчера (по словам очевидцев — гораздо раньше намченного срока). Сегодня вышел OpenOffice 3.3. А ещё то ли вчера, то ли сегодня вышла 30-дневная трайал-версия MS Office 2011…
Совпадение?
Речь идёт о создании движка для игрушки -> нужен высокопроизводительный язык. Python и Java отпадают сразу. C# — хз насчёт производительности.
Так что остаются исключительно компилируемые в нативный код языки, а это — C/C++/ObjC/D (ну, про Delphi мы вообще молчим).
Есть ещё Fortran (???), Go (уже упоминался)...Haskell… это всё довольно-таки специфичные языки (ну, Фортран я тупо не знаю, так что не бейте ногами).
Не хочу превращать это в холивар, но:
1) На самом деле очень немногие ДЕЙСТВИТЕЛЬНО знают C++ и умеют программировать на нём и при этом не наступать на грабли. Что касается изучения D, то либо ты программист, и в принципе можешь начинать писать на любом языке после прочтения туториала, либо ты не программист, и тогда тебе как-то пофиг, что изучать — C++ или D.
2) Решаемая проблема. Ещё год назад то же говорили про gcc под винду — а сейчас есть mingw-get, который всё устанавливает сам, и всё просто работает.
3) Нафига мешать C++ с D — неясно. Мешать D с C — это как раз понятно, но проблем тут быть не должно (C мешается вообще с чем угодно).
P.S. Вообще я не знаю D, только глянул описание языка :) Но когда встаёт вопрос о выборе языка, я КАТЕГОРИЧЕСКИ не могу рекоммендовать C++. C рекоммендовать я тоже не могу, хотя язык хороший — просто всё делается либо руками, либо через библиотеки, что для неподготовленного ума заканчивается летальным исходом. ObjC — это опять же C с объектной моделью (как C++, но другой), то есть проблемы те же самые — слишком много придётся делать руками (просто руки чуть более гибкие). Ну и, в общем-то, всё, по мэйнстримовым языкам.
Для начала определись с игровым движком. Наилучший вариант — использовать готовый движок. Я в них особо не разбираюсь, но Crystalspace вроде ничего. Ещё есть Ogre.
Если игра не 3D, а 2D, и найти 2D-движок не удаётся (и не удаётся использовать 3D-движок для тех же целей) — что ж, пиши свой. SDL тебе в помощь.
Движок и другие критические части пишутся на C. В зависимости от особенностей движка и AI можно заменять или дополнять C другими языками:
1) ObjC — если нужна симуляция (т.е. наилучшим образом подходит объектный метод)
2) Go — если нужен широкий параллелизм
3) D — если сильно не хватает функциональности стандартной библиотеки C
4) Haskell — если есть обширные математические вычисления
К движку прикручивается скриптование, делаются биндинги — и дальше игра пишется на скриптовом языке (на самом деле доработка движка и скриптование игры идут параллельно).
Скриптовый язык могу посоветовать только один — Python, для простоты, ясности и удобной манипуляции данными и объектами. В принципе, других языков и не понадобится (разве что будут какие-то совсем специфические задачи, для которых может понадобиться, к примеру, логическое программирование).
Никакой среды не выбирай.
Используй текстовый редактор, хорошо интегрированный с файловым менеджером. Я использую Far Manager с плагином colorer, но это скорее дело привычки.
Используй вменяемую систему сборки. В зависимости от твоих предпочтений — autotools, scons, cmake.
Используй систему контроля версий — git или mercurial. В крайнем случае — svn. Коммить часто.
Используй систему для генерации документации. Для движка — одна, для скриптов — другая (с Питоном обычно используют Sphinx; с C и иже с ним — Doxygen или gtk-doc)
Кстати о тулкитах — подумай, на чём будешь делать GUI. SDL вроде поддерживает какое-то GUI, насчёт готовых движков — не знаю. Возможно придётся прибегнуть к GTK/Qt (смотри по обстоятельствам — насколько богатый UI тебе нужен для игры и её окружения).
Вопрос в существовании не-GNUтых ОС, или ОС, которые только слегка поGNUты.
Скорее всего сборка самой ОС и её компонентов с помощью GCC не делает ОС GNUтой. Подвопрос — в том, делает ли ОС GNUтой включение в неё GCC в виде части системы. Наверное да (вот ты можешь представить Gentoo без компилятора? И я не могу. Значит компилятор — часть ОС, и влияет на её GNUтость).
Если ПО для сборки не входит в ОС, то оно не может становиться GNUтой частью ОС, потому что не является частью ОС, потому что не входит в неё.
С другой стороны, в свободных ОС сборка ПО из сырцов не является чем-то из ряда вон выходящим, поэтому комплектный набор ПО для сборки ПО можно считать нормальной частью ОС, и если это GCC — то это GNUтая часть ОС. Как-то так.
OP имел ввиду и то и другое (там в скобках написано «вообще или почти»). Использование GCC можно трактовать как «почти».
Встраиваемость в принципе не является проблемой — я понимаю, что чем более универсальная ОС, тем больше шансов, что там будет использоваться что-то из GNU, в то время как в минимальных конфигурациях заменить GNU проще.
Проведём параллель с играми в реальном мире. Кто присутствует на каждом футбольном матче? Арбитр. Третье лицо, которое знает правила и следит за тем, чтобы все игроки эти правила соблюдали, причём все игроки должны соблюдать одни и те же правила. Игроки (и зрители) также могут наблюдать за процессом игры и, в принципе, могут поймать арбитра на жульничестве (если арбитр начинает рандомно показывать красные карточки, то он либо дебил, либо куплен, либо сошёл с ума). Арбитр (как правило?) дорожит своей репутацией. Игроки доверяют арбитру по умолчанию.
С компьютерными играми можно сделать то же самое: взять некое третье лицо (не обязательно сервер, принадлежащий разработчикам игры) и сделать его арбитром. Арбитр следит, за тем, чтобы ПО всех игроков было одной версии, а также мониторит отчёты, которые ему в реальном времени посылает контрольный модуль, присобаченный к клиенту. Контрольный модуль будет реагировать на попытки модификации исполняемого кода игры на лету и другие распространённые методы взлома.
Как это стыкуется с СПО? Вот тут, в общем-то, и содержится основное слабое место этой схемы.
Контрольный модуль — это бинарник, причём крепко зашитый. Предпочтительно — зашитый каким-то очень случайным образом (я хз, как вообще это делается). Плюс, его код также может содержать случайные последовательности. В общем, любые методы, которые предотвращают автоматический взлом. Бинарник этот посылается арбитром одновременно всем игрокам. Возможно потребуется некая синхронизация передачи данных, чтобы все игроки закончили скачивать бинарник примерно в один и тот же момент. В этот момент бинарник активируется на каждом из клиентов и в течение N секунд должен законнэктиться (PSK, ключ вшит в бинарник) к арбитру и подтвердить свою подлинность и целостность. После чего он запускает игру, проверяет версию её модулей, и начинает следить за её процессами, предотвращая их изменение. Периодически (раз в M минут) арбитр генерирует новую версию бинарника и отсылает её игрокам вместе с исходниками предыдущей версии (таким образом игроки получают действительно свободное ПО — только с некоторой задержкой) и информацией о том, как расшифровать данные, которые передавал бинарник всё это время.
ПО игроков знает, как генерируются исходники контрольного модуля и что контрольный модуль может делать. Поэтому работающий параллельно с клиентом модуль контроля и наблюдения за модулем контроля может не позволять модулю контроля делать что-то, что ему делать не полагается (например пропатчить ядро). После получения очередной порции исходников и ключей для декодирования потока модуль контроля и наблюдения за модулем контроля может декодировать информацию (не обязательно в реальном времени, это можно делать параллельно, или вообще отложить декодирование на потом), которая была отослана ранее, чтобы удостовериться, что модуль контроля не посылал ничего инкриминирующего (в случае, если ему удалось обойти модуль контроля и наблюдения и всё-таки нарыть какую-то информацию), а также что арбитр не давал модулю контроля никаких читерских команд. Также игра записывает и шифрует риплэй (записывает и шифрует сама, ключ для шифрования получает от модуля контроля, этот ключ также раскрывается каждые M минут), после игры он может быть проанализирован для определения честности арбитра и игроков (поскольку система позволяет избежать модификаций клиента и шифровать передачи, можно позволить клиентам иметь исчерпывающую информацию о ходе игры — всё равно игроки не смогут ею воспользоваться в реальном времени).
То есть система основана на предположении, что можно генерировать бинарники, которые не могут быть взломаны игроками (и в которых зашитые ключи не могут быть найдены) быстрее чем за N секунд. Также предполагается, что игроки не могут модифицировать код модуля контроля после его запуска (или могут, но неспособны вычислить и внести все нужные изменения быстро и атомарно). Также предполагается, что игроки доверяют арбитру, то есть арбитры — не случайно выбранные компьютеры в Интернете, а вполне известные (имеют закрытый ключ для подтверждения) личности. Конечно, это не даёт 100% гарантию того, что они никогда не воспользуются получаемой властью в неправедных целях, но и в реальном мире никто этого не гарантирует. Кроме того возможности, которые дают им модули контроля, довольно ограничены.
Игра разбивается на несколько кусков, все важные для игрового процесса данные пересылаются через модуль контроля и поэтому передаются в зашифрованном виде. Куски, не содержащие влияющих на игровой процесс частей, могут модифицироваться свободно, модуль контроля не будет возражать. Куски, которые влияют на игровой процесс, в своей совокупности должны быть совместимы друг с другом и совместимы с клиентским кодом других игроков («совместимы» означает, что они поддерживают одну и ту же версию протокола и правил игры, они не обязательно должны быть идентичны с точностью до бита, т.к. могут быть на разных платформах), арбитр это проверяет по хэшам этих кусков (хэши считает и передаёт модуль контроля). Арбитр хранит у себя большой набор таблиц совместимости кусков по их хэшу, этот набор он также показывает игрокам перед началом игры (чтобы игроки знали, какие версии клиента поддерживаются). Одобренные как «чистые» версии происходят прежде всего из центрального репозитория сообщества разработчиков игры (подписываются релиз-инженером; списки одобренных версий регулярно обновляются), но арбитр волен поддерживать и модифицированные версии на своё усмотрение (главное, чтобы все игроки имели совместимые модификации).
Модуль контроля может посылать скриншоты (скриншоты делает игра) и данные о состоянии игры на момент снятия скриншота арбитру и другим игрокам, впоследствии их можно дешифровать (для игроков; арбитр может дешифровать в реальном времени) и проверить, что рэндэринг был проведён правильно. Это не очень красиво, но зато позволяет игрокам иметь любые версии драйверов, отвечающих за отрисовку (модифицируя рэндэрер можно, в принципе, добиваться прозрачности стен и других интересных и не совсем честных эффектов). Арбитр может сверять скриншоты с их ожидаемыми версиями (зная состояние игры, арбитр может сам отрэндэрить соответствующую сцену и автоматически проверить, что разница между изображениями не превышает погрешность).
Что-то типа того.
P.S. Про статью ничего не скажу, т.к. не читал (этот этап для меня вроде как уже пройден). Замечу только, что в некоторых случаях создавать виджеты в рантайме всё-таки надо. Лучшим решением в таких случаях является комбинирование Glade (для статических виджетов) и рантайма (для динамических).
Вопрос скорее в собственно цели существования отдельных блогов такого вида. Это для категоризации (чтобы посты о разных вещах были сложены в разные кучки)? Или для подписки (чтобы люди, подписавшиеся на апдэйты с блога, автоматом получали интересующие их посты)? Если да, то для чего тогда тэги?
Вспоминается выступление Моглена — «Freedom in the Cloud: Software Freedom, Privacy and Security for Web 2.0 and Cloud Computing». Там, в частности, было и про FB. EM указал на отсутствие необходимости в централизации социальных сетей и предложил перейти к распределённой модели, в которой каждый участник сам публикует свои данные (а сообщество СПО ему в этом помогает путём сборки соответствующего софта с соответствующим функционалом).
В плане изучения функциональных языков я бы на твоём месте начал с Хаскелла, ибо он чист.
Совпадение?
Так что остаются исключительно компилируемые в нативный код языки, а это — C/C++/ObjC/D (ну, про Delphi мы вообще молчим).
Есть ещё Fortran (???), Go (уже упоминался)...Haskell… это всё довольно-таки специфичные языки (ну, Фортран я тупо не знаю, так что не бейте ногами).
1) На самом деле очень немногие ДЕЙСТВИТЕЛЬНО знают C++ и умеют программировать на нём и при этом не наступать на грабли. Что касается изучения D, то либо ты программист, и в принципе можешь начинать писать на любом языке после прочтения туториала, либо ты не программист, и тогда тебе как-то пофиг, что изучать — C++ или D.
2) Решаемая проблема. Ещё год назад то же говорили про gcc под винду — а сейчас есть mingw-get, который всё устанавливает сам, и всё просто работает.
3) Нафига мешать C++ с D — неясно. Мешать D с C — это как раз понятно, но проблем тут быть не должно (C мешается вообще с чем угодно).
P.S. Вообще я не знаю D, только глянул описание языка :) Но когда встаёт вопрос о выборе языка, я КАТЕГОРИЧЕСКИ не могу рекоммендовать C++. C рекоммендовать я тоже не могу, хотя язык хороший — просто всё делается либо руками, либо через библиотеки, что для неподготовленного ума заканчивается летальным исходом. ObjC — это опять же C с объектной моделью (как C++, но другой), то есть проблемы те же самые — слишком много придётся делать руками (просто руки чуть более гибкие). Ну и, в общем-то, всё, по мэйнстримовым языкам.
Если игра не 3D, а 2D, и найти 2D-движок не удаётся (и не удаётся использовать 3D-движок для тех же целей) — что ж, пиши свой. SDL тебе в помощь.
Движок и другие критические части пишутся на C. В зависимости от особенностей движка и AI можно заменять или дополнять C другими языками:
1) ObjC — если нужна симуляция (т.е. наилучшим образом подходит объектный метод)
2) Go — если нужен широкий параллелизм
3) D — если сильно не хватает функциональности стандартной библиотеки C
4) Haskell — если есть обширные математические вычисления
К движку прикручивается скриптование, делаются биндинги — и дальше игра пишется на скриптовом языке (на самом деле доработка движка и скриптование игры идут параллельно).
Скриптовый язык могу посоветовать только один — Python, для простоты, ясности и удобной манипуляции данными и объектами. В принципе, других языков и не понадобится (разве что будут какие-то совсем специфические задачи, для которых может понадобиться, к примеру, логическое программирование).
Никакой среды не выбирай.
Используй текстовый редактор, хорошо интегрированный с файловым менеджером. Я использую Far Manager с плагином colorer, но это скорее дело привычки.
Используй вменяемую систему сборки. В зависимости от твоих предпочтений — autotools, scons, cmake.
Используй систему контроля версий — git или mercurial. В крайнем случае — svn. Коммить часто.
Используй систему для генерации документации. Для движка — одна, для скриптов — другая (с Питоном обычно используют Sphinx; с C и иже с ним — Doxygen или gtk-doc)
Кстати о тулкитах — подумай, на чём будешь делать GUI. SDL вроде поддерживает какое-то GUI, насчёт готовых движков — не знаю. Возможно придётся прибегнуть к GTK/Qt (смотри по обстоятельствам — насколько богатый UI тебе нужен для игры и её окружения).
Скорее всего сборка самой ОС и её компонентов с помощью GCC не делает ОС GNUтой. Подвопрос — в том, делает ли ОС GNUтой включение в неё GCC в виде части системы. Наверное да (вот ты можешь представить Gentoo без компилятора? И я не могу. Значит компилятор — часть ОС, и влияет на её GNUтость).
Если ПО для сборки не входит в ОС, то оно не может становиться GNUтой частью ОС, потому что не является частью ОС, потому что не входит в неё.
Встраиваемость в принципе не является проблемой — я понимаю, что чем более универсальная ОС, тем больше шансов, что там будет использоваться что-то из GNU, в то время как в минимальных конфигурациях заменить GNU проще.