Разработчики, желающие добавить поддержку XP в свои продукты, я имею в виду Inkscape всякие, могли бы зарубить себе на носу, что если им так хочется полезть в msvcrt.dll за новыми функциями, пусть тащат с собой установщик msvcrt 12.0 и лезут в msvcrt120.dll.
За счёт расширения пространства свет снова получает возможность убегать из-под вычисленного размера радиуса, а какой там другой радиус с учётом расширения, это ещё надо пересчитать. Как мне кажется, чёрным дырам на космологических расстояниях приходится тягаться с (виртуальным) потенциалом тёмной энергии, пропорциональным r в какой-то степени (второй?).
Вообще, идею Большого Взрыва протолкнули, чтобы объяснить поразительную изотропность реликтового излучения: практически во всех направлениях 4 Кельвина, хотя удалённые друг от друга области не могли успеть провзаимодействовать друг с другом. А мне как программисту кажется, что Вселенную просто рандомно сгенерили.
В четырёхмерном пространстве, если я правильно понимаю, орбиты — логарифмические кривые. Либо планета сначала коснётся стенки потенциальной ямы, а потом по логарифмической кривой устремится к Солнцу.
Я б сказал, что она давно захвачена, но есть разные уровни эксплуатации, и иногда нужно сломать прежнюю колониальную систему, чтоб увеличить уровень эксплуатации. Так сломали горбачёвский СССР, не так давно Украину. То, что делает бюрократия сейчас, очень похоже на целенаправленное создание революционной ситуации. При управляемом ходе революции исполнители даже не сильно страдают. Вот на Украине, как говорит Анатолий Шарий, судьи, которые его осудили при Януковиче, так и сидят при Порошенко. В них бутылки со смесями не летели.
В этот момент нужно просто оказаться иностранцем. У нас же как запрещённую литературу распространят? Украинец печатает и продаёт запрещённую в России, но не на Украине, книгу, россиянин покупает. Гражданина другой страны на территории другой страны не может осудить российский суд, а россиянина российский суд может осудить только за распространение запрещённого в России, но не за приобретение. С тем, что запрещено на Украине, обратная схема.
Сфера вкладывается как в эллиптическое пространство, так и в Евклидово и Лобачевского. Евклидова плоскость вкладывается только в Евклидово и Лобачевского пространства. Плоскость Лобачевского можно вложить только в пространство Лобачевского.
Однако этот ряд можно продолжить тем способом, который я не видел. Плоскость Лобачевского можно вложить в псевдоевклидово пространство Минковского. В принципе, это известный факт, пространство скоростей в теории относительности является гиперболическим. 4-вектор скорости всегда по модулю равен 1 (скорость света) — и вот получается гиперболоид возможных скоростей. Только я не видел, чтобы эта особенность рассматривалась с позиции возможных замощений.
Если этот гиперболоид дополняется ещё одним гиперболоидом, но с пространственноподобным радиусом, вот, глядишь, и «выход за абсолют» нашёлся. Правда, как я понимаю, там не дополнение, а вообще все точки будут на таком гиперболоиде, а это уже, наверное, пространства де Ситтера и анти-де Ситтера должно называться.
Ведь взять, допустим, пространство Минковского (2е пространственных координаты, одно время). На обычной плоскости Лобачевского вершины с бесконечным количеством рёбер мог быть только в идеалах. А в пространство Минковского вложил гиперболоид, замостил его пространственноподобной гиберболической мозаикой, и ещё от центра гиперболоида провёл бесконечность времениподобных вершин. И всё это — не в идеале, а в любой точке пространства. И для более простых «плохих» символов Шлефли должно место найтись.
Заодно узнаем, какая у нас потенциально может быть решётка пространства-времени.
Посмотрел. Там протобуф. Значит, поле для TTH добавить везде можно. А ещё значит, механическое добавление TTH к списку других хешей не поможет в данном вопросе. Даже в Blob там будут добавки, сделающие содержимое слишком другим.
Поможет хакнутая функция, которая умеет парсить ProtoBuf для Blob и List и возвращать TTH для них.
Не надо бросать пыль в глаза. Любой хеш Меркля — на самом деле направленный ациклический граф. Если вдруг хеши соседних узлов сошлись, вот считай, уже не дерево, и можно было бы такие куски дедуплицировать. Другое дело, что в масштабах миллионов файлов держать индексы не только для корней, но и для внутренних узлов, и всё это в режиме реального времени обнаруживать, мне кажется, было бы убийственно для производительности.
Единственный полезный способ применять их произвольно гибкий граф, который я увидел, — это Jigdo для p2p. Но нормальный p2p стоит на прочном фундаменте хешей, всегда одинаковых для идентичных файлов. Я могу напихать файлов в Jigdo .iso, и эти файлы по TTH найдутся у тех, кто расшарил их, не координируясь со мной. Таким образом, из TTH+Jigdo можно сделать IPFS, а обратное, когда каждый хеширует файлы кто в лес, кто по дрова, не верно.
Получается, планы озвучены, а в деталях реализации ещё чистый лист. Пользуясь шансом, можно взять и синхронизироваться. Чтобы сохранить все хорошие свойства TTH, придётся натянуть алгоритм IPFS на особенности вычисления TTH, и в каком-то диапазоне размеров файлов будет совместимость, а где-то у IPFS могут возникнуть (решаемые) проблемы.
Так, нижние блоки совершенно аналогично TTH всегда имеют гранулярность 1024 байта. Они образуют объекты Blob, а из Blob образуются объекты List аналогично TTH узлам. Синтаксис List используется, как в IPFS. При этом все синтаксические навороты IPFS с точки зрения преемника TTH — это просто способ посолить хеши. В TTH базовая криптографическая функция Tiger солится нулевым или единичным байтом, а здесь это будет:
{
"data": ["blob", "list", "blob"],
// lists have an array of object types as data
"links": [
{ "hash": "XLYkgq61DYaQ8NhkcqyU7rLcnSa7dSHQ16x",
"size": 189458 },
{ "hash": "XLHBNmRQ5sJJrdMPuu48pzeyTtRo39tNDR5",
"size": 19441 },
{ "hash": "XLWVQDqxo9Km9zLyquoC9gAP8CL1gWnHZ7z",
"size": 5286 }
// lists have no names in links
]
}
Но только размеры здесь не могут быть произвольные. Всё должно быть повторяемо. Собственно, так же, как посоленная конкатенация Tiger хешей отправляется на вход Tiger и после вычисления исчезает, приведённая структура тоже существует только временно в памяти и не передаётся клиентами. Клиентами будет передаваться аналог gltth, то есть, тупо срез дерева хешей в максимально компактном виде.
И так же, как в TTH, с дерева при необходимости может сниматься не самый нижний уровень. Клиенты, поддерживающие TTH, не требуют от другой стороны более глубокой детализации блоков, а просто проверяют более крупными блоками, сами достраивая поддеревья до ближайшего известного узла. В IPFS — не знаю, наверное, это может вызвать проблемы. Но их оригинальные хеши слишком гибки для нас, а наши всегда совпадающие для идентичных файлов хеши могут оказаться неудобны для них, при этом на фундаменте наших хешей уже что-то работает, а можно было бы даже и Jigdo сделать, а на их хешах в общем случае — нет.
Ещё есть мысль добавить TTH рядом с этим новым, основанным на SHA3 хешем. Мне пока не понятно, возможно ли в Blob и List добавить ещё поле для TTH, но было бы здорово.
В общем случае взаимодействия между DC++ и независимо опубликованными в IPFS файлами всё равно не будет потому что кто в лес по дрова хеширует, но потом можно научиться публиковать файлы в IPFS так же, как это делает будущий гипотетический DC++, и тогда и с DC++ совместимость получится, и внутри IPFS разброд и шатания будут с меньшей амплитудой, владельцы идентичных файлов смогут находить друг друга. И TTH таким образом вплетённый, не «забудут» посчитать.
И этот «новый шаг» начался не с поддержки TTH. О чём они вообще думали, для кого они это делали. Крайне скептически я отношусь к таким «новым шагам». Ну как сделают TTH, так можно будет посмотреть.
Да, вот это кажется бредом, чахнуть как Кащей над BTIH, лишь бы сошёлся. Имя поменяли — всё, капец, не сходится. Ну что за стыд.
Вот я понимаю, многофайловые раздачи непросто будет пересекающиеся находить, но с однофайловыми-то всё понятно должно быть. Просто берём и используем TTH вместо BTIH. Ну не влезло маленько 4 байта разница, давайте в старом механизме обрубим, а в новом учтём.
Ну так и из TTH можно микроторренты генерить по той же спеке. В принципе, веб-сервер можно научить. Скрипт модифицировать, чтоб рядом с каждым файлом подрисовывал тоже торрент с теми же параметрами, что у магнитки, и пожалуйста. И на любой размер смасштабируется, и на малых размерах (<2Мб) проверка будет по 1Кб, а не по всему размеру. А MD5, между прочим, в RFC есть, Content-MD5 называется, и Apache2 его генерить умеет. Только файл нужно качать от начала и до конца, иначе Content-MD5 от куска будет. Что теперь, за каждую архаичность цепляться? Есть TTH, он хороший, проверенный и нечего вытрёпываться, велосипедить пи-хеш, а-бтих, будь здоров, и нечего вытрёпываться использовать недревовидные хеши, а среди древовидных нужно веское основание не вычислить TTH. Я так считаю.
Да, вот это и проблема, что только однофайловые. По оглашению мультипротокольная, а по умолчанию — все протоколы по-своему плохо. На базе DC++ гибридизация более перспективная, на мой взгляд.
Скрипты — это вынужденная мера. Обычная раздутая страница — 6.9Кб, а сжатая до той степени, насколько возможно не в ущерб SEO — 1.5Кб. А чем меньше размер, тем больше чужих шар влезет. С точки зрения SEO я больше хотел, чтобы TTH был искабельным через поисковики, поэтому он там текстом, а магнитки в явном виде нет, как и многого другого. Если же кому-то захочется в автоматическом режиме что-то обработать, так проще всю директорию слить в одном из предложенных форматах.
Это такой аналог HttpFileServer, только он не сами файлы и не директории скопом в .tar или .zip может давать скачать, а вместо файлов — магнитные ссылки, а вместо директорий для скачивания скопом — соответственно, описывающие их .dcls и ещё .torrent. Торренты тут не обычные. В идеале после того, как в 2006м опубликовали спеку, должен был начаться переходный период, когда были и TTH, и архаичный info.pieces, и сейчас, десять лет спустя клиенты были бы готовы к переходу на чистый TTH, но этого не произошло, поэтому мои чисто-TTH-ные торренты, скорее всего, застанут большинство из них врасплох. А вычислять архаичный info.pieces для трети петабайта чужих шар, понятное дело, не получится. И всякие пофайловые sha1 — туда же. Ну и, конечно, торренты тут ещё затем что их ищут чаще, чем DCLS и TTH. Ищете торренты — нате пожалуйста, но только с TTH. Тот же DCLS, вид сбоку.
uTorrent каждый раз после обновления хекс-редактором патчить надо, заменять private на provate. Лень. А в последних ещё и реклама появилась. Но можно подумать, спасибо.
Ну вообще есть спецификация на включение TTH в торренты от 2006го года, и если её поддержать, то это станет возможным. Учитывая, насколько устойчив пофайловый TTH к изменениям размера проверяемого блока, имени файла и прочему, и насколько хрупок BTIH, изменения должны делаться в более слабом звене. Генераторы торрентов должны вставлять TTH во все торренты, а для тех торрентов, которые пришли со стороны, если в них нет TTH, отображать восклицательный знак в треугольнике. Сайты торрентов, если залит торрент без TTH, должны отправлять переделывать. В результате присутствие TTH должно стать более массовым, и хотя прямая гибридизация файлообменных сетей удобным для людей способом, как показывает опыт Shareaza, часто затруднительна (если верить таблице по ссылке, скачивание многофайлового торрента в Shareaza реализовано таким костылём, что учесть TTH, даже если он есть, невозможно), но какие-нибудь умельцы бы смекнули, что к чему, запилили THEX в торрентах и поиск по TTH внутри сети BitTorrent. И уже потом потихоньку подтянулись бы гибриды.
Однако этот ряд можно продолжить тем способом, который я не видел. Плоскость Лобачевского можно вложить в псевдоевклидово пространство Минковского. В принципе, это известный факт, пространство скоростей в теории относительности является гиперболическим. 4-вектор скорости всегда по модулю равен 1 (скорость света) — и вот получается гиперболоид возможных скоростей. Только я не видел, чтобы эта особенность рассматривалась с позиции возможных замощений.
Если этот гиперболоид дополняется ещё одним гиперболоидом, но с пространственноподобным радиусом, вот, глядишь, и «выход за абсолют» нашёлся. Правда, как я понимаю, там не дополнение, а вообще все точки будут на таком гиперболоиде, а это уже, наверное, пространства де Ситтера и анти-де Ситтера должно называться.
Ведь взять, допустим, пространство Минковского (2е пространственных координаты, одно время). На обычной плоскости Лобачевского вершины с бесконечным количеством рёбер мог быть только в идеалах. А в пространство Минковского вложил гиперболоид, замостил его пространственноподобной гиберболической мозаикой, и ещё от центра гиперболоида провёл бесконечность времениподобных вершин. И всё это — не в идеале, а в любой точке пространства. И для более простых «плохих» символов Шлефли должно место найтись.
Заодно узнаем, какая у нас потенциально может быть решётка пространства-времени.
Поможет хакнутая функция, которая умеет парсить ProtoBuf для Blob и List и возвращать TTH для них.
Единственный полезный способ применять их произвольно гибкий граф, который я увидел, — это Jigdo для p2p. Но нормальный p2p стоит на прочном фундаменте хешей, всегда одинаковых для идентичных файлов. Я могу напихать файлов в Jigdo .iso, и эти файлы по TTH найдутся у тех, кто расшарил их, не координируясь со мной. Таким образом, из TTH+Jigdo можно сделать IPFS, а обратное, когда каждый хеширует файлы кто в лес, кто по дрова, не верно.
Я там прокомментировал, как технически можно было бы внедрить TTH с учётом тонкостей. Попутно мне пришла идея, а не запилить ли совместимый с IPFS хеш в DC++? Просто такие ребята, ну знаете, как-то раз три года назад собрались начать переход на новый древовидный хеш на основе SHA3, когда конкурс ещё только шёл, и вот до сих пор можно открыть список официальных расширений протокола, TIGR там есть, а SHA3 — нет.
Получается, планы озвучены, а в деталях реализации ещё чистый лист. Пользуясь шансом, можно взять и синхронизироваться. Чтобы сохранить все хорошие свойства TTH, придётся натянуть алгоритм IPFS на особенности вычисления TTH, и в каком-то диапазоне размеров файлов будет совместимость, а где-то у IPFS могут возникнуть (решаемые) проблемы.
Так, нижние блоки совершенно аналогично TTH всегда имеют гранулярность 1024 байта. Они образуют объекты Blob, а из Blob образуются объекты List аналогично TTH узлам. Синтаксис List используется, как в IPFS. При этом все синтаксические навороты IPFS с точки зрения преемника TTH — это просто способ посолить хеши. В TTH базовая криптографическая функция Tiger солится нулевым или единичным байтом, а здесь это будет:
Но только размеры здесь не могут быть произвольные. Всё должно быть повторяемо. Собственно, так же, как посоленная конкатенация Tiger хешей отправляется на вход Tiger и после вычисления исчезает, приведённая структура тоже существует только временно в памяти и не передаётся клиентами. Клиентами будет передаваться аналог gltth, то есть, тупо срез дерева хешей в максимально компактном виде.
И так же, как в TTH, с дерева при необходимости может сниматься не самый нижний уровень. Клиенты, поддерживающие TTH, не требуют от другой стороны более глубокой детализации блоков, а просто проверяют более крупными блоками, сами достраивая поддеревья до ближайшего известного узла. В IPFS — не знаю, наверное, это может вызвать проблемы. Но их оригинальные хеши слишком гибки для нас, а наши всегда совпадающие для идентичных файлов хеши могут оказаться неудобны для них, при этом на фундаменте наших хешей уже что-то работает, а можно было бы даже и Jigdo сделать, а на их хешах в общем случае — нет.
Ещё есть мысль добавить TTH рядом с этим новым, основанным на SHA3 хешем. Мне пока не понятно, возможно ли в Blob и List добавить ещё поле для TTH, но было бы здорово.
В общем случае взаимодействия между DC++ и независимо опубликованными в IPFS файлами всё равно не будет потому что кто в лес по дрова хеширует, но потом можно научиться публиковать файлы в IPFS так же, как это делает будущий гипотетический DC++, и тогда и с DC++ совместимость получится, и внутри IPFS разброд и шатания будут с меньшей амплитудой, владельцы идентичных файлов смогут находить друг друга. И TTH таким образом вплетённый, не «забудут» посчитать.
Вот я понимаю, многофайловые раздачи непросто будет пересекающиеся находить, но с однофайловыми-то всё понятно должно быть. Просто берём и используем TTH вместо BTIH. Ну не влезло маленько 4 байта разница, давайте в старом механизме обрубим, а в новом учтём.
Да, вот это и проблема, что только однофайловые. По оглашению мультипротокольная, а по умолчанию — все протоколы по-своему плохо. На базе DC++ гибридизация более перспективная, на мой взгляд.
Скрипты — это вынужденная мера. Обычная раздутая страница — 6.9Кб, а сжатая до той степени, насколько возможно не в ущерб SEO — 1.5Кб. А чем меньше размер, тем больше чужих шар влезет. С точки зрения SEO я больше хотел, чтобы TTH был искабельным через поисковики, поэтому он там текстом, а магнитки в явном виде нет, как и многого другого. Если же кому-то захочется в автоматическом режиме что-то обработать, так проще всю директорию слить в одном из предложенных форматах.
Это такой аналог HttpFileServer, только он не сами файлы и не директории скопом в .tar или .zip может давать скачать, а вместо файлов — магнитные ссылки, а вместо директорий для скачивания скопом — соответственно, описывающие их .dcls и ещё .torrent. Торренты тут не обычные. В идеале после того, как в 2006м опубликовали спеку, должен был начаться переходный период, когда были и TTH, и архаичный info.pieces, и сейчас, десять лет спустя клиенты были бы готовы к переходу на чистый TTH, но этого не произошло, поэтому мои чисто-TTH-ные торренты, скорее всего, застанут большинство из них врасплох. А вычислять архаичный info.pieces для трети петабайта чужих шар, понятное дело, не получится. И всякие пофайловые sha1 — туда же. Ну и, конечно, торренты тут ещё затем что их ищут чаще, чем DCLS и TTH. Ищете торренты — нате пожалуйста, но только с TTH. Тот же DCLS, вид сбоку.