А есть какие–нибудь смежные проекты, дружественные ReactOS?
Например, которые:
могли бы рассчитывать на то, что их библиотеки будут в стандартной поставке ReactOS
имели бы версию библиотек для Windows с поддержкой ReactOS, а также для Wine, с winelib библиотеками отдельно для каждой Solaris, Mac OS X, Linux
Что–то такое вам понадобится, чтобы перехватить инициативу и не догонять Microsoft в своём стремлении скопировать Win32 API во всей его полноте, а дать Windows разработчикам то, что, даже, если они продолжат использовать инфраструктуру для сборки под Windows, позволило бы разрабатывать кроссплатформенные приложения, а версии этих приложений под ReactOS просто меньше весили бы.
У меня сейчас в голове крутится такая схема: есть IBM SOM. На момент написания статьи я почти отчаялся его найти, но в декабре 2012го мне прислали версию для Windows, и мне удалось привести её в рабочее состояние и я теперь занимаюсь тем, что тщательно и пристально изучаю SOM. Это не считая того, что я сейчас жду ответа на некоторые вопросы от разработчика somFree.
И есть Wine с возможностью писать как бы .dll в родном для OS формате. А ещё есть набор кроссплатформенных библиотек, как GUI, так и прочих, которые по методу winelibs так просто отвязать от платформы не получится. Нынешние C++ компиляторы для Windows охренеют вызывать C++ метод библиотеки Mac OS X. Размеры объектов наверняка разные у wxWidget для Windows и Mac OS X. А вот если есть подходящая прослойка, то такое взаимодействие вполне возможно. И получается как бы бинарная Java.
Торренты содержат поблочные хеши, а не пофайловые.
При текущей реализации все файлы раздачи виртуально склеиваются в один массив байтов, этот массив разбивается на одинаковые по размеру блоки, хеши каждого блока пишутся в метафайл, в info/pieces. Выбор размера блока оставлен на усмотрение генератора метафайлов. info содержит имена файлов, размеры файлов, размер блока хеширования и pieces — те самые хеши каждого блока. Для идентификации торрентов используется хеш от info, поэтому BTIH, BitTorrent Info Hash. BTIH меняется при любом изменении info: перестановка файлов, переименование файлов, изменение размера блока хеширования. pieces внутри метафайла имеют смысл только для текущей раздачи. Для других раздач с совпадающими файлами установить факт идентичности файлов нет способа без пофайловых TTH.
Хешируемые блоки обычно не совпадают с границами файлов. Размер хешируемого блока произвольный, так что установить, принадлежит ли файл раздаче, можно только по косвенным признакам, сопоставляя размер файла и перебирая все места, куда бы этот файл мог подойти.
maggot является полной противоположностью гибкости упомянутых сетей
magnet есть нормальный (как в Shareaza и GreyLink), с dn, xl и хешами, специфичными для файлов, а не для раздачи.
А есть magnet ненормальный, плод продукта каких–то торренторазрабов, которые услышали звон, да не поняли, где он, не добавили пофайловый TTH в свои клиенты, не научились считать TTH директории, но тоже полезли в magnet URI.
Впрочем, magnet по стандарту помойка, в которой можно даже сослаться на результаты поиска в p2p по ключевым словам, так что рейдерство торренторазрабами magnet URI вписывается в общую картину.
Мне даже не вериться, что я когда-то верил, что у нас в стране что-то можно поменять. Хотя всего-то лет 5 прошло. Бил в себя в грудь и говорили «что я буду работать только в РФ», когда мне предлагали хорошую работу в штатах
Принципиальный вопрос не в том, где зарабатывать деньги, а где их тратить, если на то пошло.
Недостаток BTIH — зависимость от размера минимально проверяемого блока. Разные размеры блоков, разные имена файлов, разная метаинформация — всё это меняет BTIH. TTH для файла определён жёстко, но при этом в силу своей древесной структуры позволяет варьировать размер минимально проверяемого блока по степеням двойки, не изменяя корневой хеш. Размер зависит от того, какой слой Merkle Tree передаётся между пирами. У разных протоколов могут слегка отличаться требования к степени детализации, но в случае с TTH можно увеличивать детализацию на лету.
Gnutella2 умеет искать и по SHA1, и по MD5, и по TTH, и по ED2K. Если у Shareaza не хватает важных хешей, она пытается узнать их от других узлов сети (Shareaza хранит метаинформацию даже после удаления файлов), но этой информации она может верить только на слово (по принципу большинства)
А что толку от BTIH, если его каждый как хочет считает? BTIH как раз и старый. Надо было сделать proof of concept p2p, а какие через десять лет проблемы возникнут, было видно лишь смутно. В то время какое–то оправдание было, сейчас оправдания нет. RetroShare, maggot, Shareman, каждый со своими велосипедными хешами. Так нельзя.
Причина, по которой предпочтение отдаётся TTH — его технические особенности и его использование в двух независимых p2p протоколах. Собственно, в DC++ TTH появился как раз из–за того, что кто–то из разработчиков оценил TTH по достоинству. До этого NMDC был как FTP с поиском. Если копаться в старых клиентах, в каком–то консольном клиенте NMDC можно найти поддержку ED2K, то есть, такой однозначный выбор был хеша сделан не сразу.
Насчёт emule не знаю, но ED2K всяко полезней считать, чем MD5. Насколько я помню, Gnutella2 позволяет искать по ED2K
По-моему большинство уже давно в торрентах
Если в клиентах BitTorrent появится поддержка списка файлов, пофайловый TTH и поиск по TTH, я не против BitTorrent.
Пока этого нет, всё это большинство пусть сидит в торрентах хоть до посинения, количество не перейдёт в качество. Прогресс для пользователей этого протокола заблокирован.
И, насколько я помню, некоторые сайты предлагают использовать собственные даунлодеры, и почему бы не Shareaza? Shareaza умеет работать HTTP качалкой и встраиваться в браузер как FlashGet. При этом через расширения HTTP можно получить хеши. В общем, если у юзера чего–то не стоит, я бы не сказал, что это большая проблема.
Унификацию хешей я считаю прогрессом. Многие хорошие вещи не случились потому что Яндекс.Диск пишет один хеш, open source дистрибутивы для проверки целостности пишут в checksum.sfv другой хеш, а среди p2p–клиентописатели слишком велики доли двух групп: первая группа по наивности использует цельнофайловый хеш, приглашая тем самым недоброжелателей безнаказанно отравлять раздачи, как это было в Gnutella1 до введения TTH. Вторая группа учитывает эту проблему, но как решение, велосипедит пи–хеши и BTIHи. Вместо того, чтобы всем дружно использовать TTH.
Да, и DC, похоже, в России потихоньку региональные провайдеры прикрывают
DC есть и глобальные. DC вообще не в России зародился. Начиная со StrongDC++, есть DHT, хотя децентрализация пока не столь развита, как в Gnutella2. Как постоянный пользователь GreyLink, я могу сказать, что достойных альтернатив DC++ и Gnutella2 пока не состоялось. Чтобы они быстрее состоялись, хорошо бы, чтобы все использовали TTH. Даже там, где это не критично. Пусть программисты задумываются, а почему из всех хешей выбран именно TTH, обнаруживают, что, оказывается, без унификации хешей к TTH столько прогресса прошло стороной, запоминают и, может быть, на несколько велосипедов станет меньше, а прогресс станет ближе
Чтобы не устраивать Вавилонское столпотворение. Не для целостности, так для информации TTH крайне желательно, чтобы был, а если в виде магнитной ссылки — ещё лучше. А если HTTP сервер будет поддерживать расширения HTTP, которые позволяют Shareaza находить альтернативные источники в p2p сетях — вообще замечательно. Это поспособствует тому, чтобы эти расширения HTTP появились в других p2p–клиентах.
Например, которые:
Что–то такое вам понадобится, чтобы перехватить инициативу и не догонять Microsoft в своём стремлении скопировать Win32 API во всей его полноте, а дать Windows разработчикам то, что, даже, если они продолжат использовать инфраструктуру для сборки под Windows, позволило бы разрабатывать кроссплатформенные приложения, а версии этих приложений под ReactOS просто меньше весили бы.
У меня сейчас в голове крутится такая схема: есть IBM SOM. На момент написания статьи я почти отчаялся его найти, но в декабре 2012го мне прислали версию для Windows, и мне удалось привести её в рабочее состояние и я теперь занимаюсь тем, что тщательно и пристально изучаю SOM. Это не считая того, что я сейчас жду ответа на некоторые вопросы от разработчика somFree.
И есть Wine с возможностью писать как бы .dll в родном для OS формате. А ещё есть набор кроссплатформенных библиотек, как GUI, так и прочих, которые по методу winelibs так просто отвязать от платформы не получится. Нынешние C++ компиляторы для Windows охренеют вызывать C++ метод библиотеки Mac OS X. Размеры объектов наверняка разные у wxWidget для Windows и Mac OS X. А вот если есть подходящая прослойка, то такое взаимодействие вполне возможно. И получается как бы бинарная Java.
При текущей реализации все файлы раздачи виртуально склеиваются в один массив байтов, этот массив разбивается на одинаковые по размеру блоки, хеши каждого блока пишутся в метафайл, в info/pieces. Выбор размера блока оставлен на усмотрение генератора метафайлов. info содержит имена файлов, размеры файлов, размер блока хеширования и pieces — те самые хеши каждого блока. Для идентификации торрентов используется хеш от info, поэтому BTIH, BitTorrent Info Hash. BTIH меняется при любом изменении info: перестановка файлов, переименование файлов, изменение размера блока хеширования. pieces внутри метафайла имеют смысл только для текущей раздачи. Для других раздач с совпадающими файлами установить факт идентичности файлов нет способа без пофайловых TTH.
Хешируемые блоки обычно не совпадают с границами файлов. Размер хешируемого блока произвольный, так что установить, принадлежит ли файл раздаче, можно только по косвенным признакам, сопоставляя размер файла и перебирая все места, куда бы этот файл мог подойти.
Я когда–то писал про TTH в BT на форуме uTorrent. Не нашли мои мысли тогда понимания. А проблема как была, так и никуда и не уйдёт.
magnet есть нормальный (как в Shareaza и GreyLink), с dn, xl и хешами, специфичными для файлов, а не для раздачи.
А есть magnet ненормальный, плод продукта каких–то торренторазрабов, которые услышали звон, да не поняли, где он, не добавили пофайловый TTH в свои клиенты, не научились считать TTH директории, но тоже полезли в magnet URI.
Впрочем, magnet по стандарту помойка, в которой можно даже сослаться на результаты поиска в p2p по ключевым словам, так что рейдерство торренторазрабами magnet URI вписывается в общую картину.
Принципиальный вопрос не в том, где зарабатывать деньги, а где их тратить, если на то пошло.
Когда AES-NI станет достаточно устаревшей технологией, чтобы у большинства она появилась, вот это будет интереснее жить.
Amahi для домашнего медиа–, файл–, вики– и т. п. сервера
ClearOS для сервера и шлюза в Интернет предприятия
Project Byzantium для роутера–участника ячеистой сети
Недостаток BTIH — зависимость от размера минимально проверяемого блока. Разные размеры блоков, разные имена файлов, разная метаинформация — всё это меняет BTIH. TTH для файла определён жёстко, но при этом в силу своей древесной структуры позволяет варьировать размер минимально проверяемого блока по степеням двойки, не изменяя корневой хеш. Размер зависит от того, какой слой Merkle Tree передаётся между пирами. У разных протоколов могут слегка отличаться требования к степени детализации, но в случае с TTH можно увеличивать детализацию на лету.
Gnutella2 умеет искать и по SHA1, и по MD5, и по TTH, и по ED2K. Если у Shareaza не хватает важных хешей, она пытается узнать их от других узлов сети (Shareaza хранит метаинформацию даже после удаления файлов), но этой информации она может верить только на слово (по принципу большинства)
Причина, по которой предпочтение отдаётся TTH — его технические особенности и его использование в двух независимых p2p протоколах. Собственно, в DC++ TTH появился как раз из–за того, что кто–то из разработчиков оценил TTH по достоинству. До этого NMDC был как FTP с поиском. Если копаться в старых клиентах, в каком–то консольном клиенте NMDC можно найти поддержку ED2K, то есть, такой однозначный выбор был хеша сделан не сразу.
Насчёт emule не знаю, но ED2K всяко полезней считать, чем MD5. Насколько я помню, Gnutella2 позволяет искать по ED2K
Если в клиентах BitTorrent появится поддержка списка файлов, пофайловый TTH и поиск по TTH, я не против BitTorrent.
Пока этого нет, всё это большинство пусть сидит в торрентах хоть до посинения, количество не перейдёт в качество. Прогресс для пользователей этого протокола заблокирован.
И, насколько я помню, некоторые сайты предлагают использовать собственные даунлодеры, и почему бы не Shareaza? Shareaza умеет работать HTTP качалкой и встраиваться в браузер как FlashGet. При этом через расширения HTTP можно получить хеши. В общем, если у юзера чего–то не стоит, я бы не сказал, что это большая проблема.
Унификацию хешей я считаю прогрессом. Многие хорошие вещи не случились потому что Яндекс.Диск пишет один хеш, open source дистрибутивы для проверки целостности пишут в checksum.sfv другой хеш, а среди p2p–клиентописатели слишком велики доли двух групп: первая группа по наивности использует цельнофайловый хеш, приглашая тем самым недоброжелателей безнаказанно отравлять раздачи, как это было в Gnutella1 до введения TTH. Вторая группа учитывает эту проблему, но как решение, велосипедит пи–хеши и BTIHи. Вместо того, чтобы всем дружно использовать TTH.
DC есть и глобальные. DC вообще не в России зародился. Начиная со StrongDC++, есть DHT, хотя децентрализация пока не столь развита, как в Gnutella2. Как постоянный пользователь GreyLink, я могу сказать, что достойных альтернатив DC++ и Gnutella2 пока не состоялось. Чтобы они быстрее состоялись, хорошо бы, чтобы все использовали TTH. Даже там, где это не критично. Пусть программисты задумываются, а почему из всех хешей выбран именно TTH, обнаруживают, что, оказывается, без унификации хешей к TTH столько прогресса прошло стороной, запоминают и, может быть, на несколько велосипедов станет меньше, а прогресс станет ближе
Чтобы не устраивать Вавилонское столпотворение. Не для целостности, так для информации TTH крайне желательно, чтобы был, а если в виде магнитной ссылки — ещё лучше. А если HTTP сервер будет поддерживать расширения HTTP, которые позволяют Shareaza находить альтернативные источники в p2p сетях — вообще замечательно. Это поспособствует тому, чтобы эти расширения HTTP появились в других p2p–клиентах.
Ещё одна слабо документированная фича Delphi pre-2010 — это RTTI, который включает в себя published свойства, поля и методы, посредством которой можно сделать AsDynamic в том числе и на старых версиях Delphi
По поводу оверхеда — да, это действительно так. Смысл статьи — показать, что кое–какие фичи в Delphi реализуемы и показать, куда копать
Кстати, System.Rtti.TValue — это как раз интерфейс в записи