Я старался брать наиболее простые и универсальные символы. Та же стрелка - вообще древнейший символ, понятный всему человечеству, и достаточно простой чтобы использовать его в рукописном тексте.
Не все символы одинаково востребованы. Например, есть вот такие "изысканные скобки" ﴾ ﴿ U+FD3E U+FD3F (в моем шрифте они отображаются как круглые) - я не знаю откуда они взялись, не удивлюсь если это лишь продукт фантазии кого-то в комитете Unicode. А вот угловые скобки по своей простоте вполне конкурируют с квадратными и фигурными, и полно примеров их применения в математике. Правда, в Unicode почему-то две пары таких скобок: 〈 〉 U+2329 U+232A и ⟨ ⟩ U+27E8 U+27E9. Иначе как бардаком такое положение дел назвать трудно, но что есть то есть)))
ü это символ какого-то языка, и он наверняка есть на клавиатурах тех стран, где этот язык используется. Я же говорю об универсальных символах, не зависящих от языка. Прежде всего научных и технических (хотя может есть и какие-то востребованные лингвистические и прочие символы, не попавшие в ASCII). Можно конечно вспомнить и эмодзи, но это не совсем то направление, которое лично меня интересует:) (да и пользователи эмодзи скорее всего имеют достаточно малое пересечение с пользователями физических клавиатур)
Потому и не использовали, что их нет на клавиатуре. Я вот ради интереса загуглил некоторые символы - Гугл показывает количество результатов: → примерно 3 500 000 000 , ← примерно 1 080 000 000 и т.д. Вообще было бы интересно собрать такую статистику по всем символам.
Хайподелы. Лучше бы подумали, какие юникодные символы из отсутствующих в ASCII наиболее востребованы, да добавили бы их дополнительными символами на буквенно-цифровые клавиши. Как минимум, стрелки, дополнительные скобки (чтобы отказаться уже от знаков "больше" и "меньше" в качестве шаблонных скобок в программировании) и некоторые математические символы.
Разумеется, хранить ресурсы можно и в виде обычных массивов констант (как в линуксе и делается, в частности в Qt из-за этого все ресурсы компилируются именно в сишный код). Дело в стандартизации (стандартное место для иконки приложения, информации об авторе, компании и т.п.), а также в структуризации (в том числе упрощении декомпиляции, понимаю что авторам проприетарщины это нафиг не нужно, но тем ни менее всякие виртуальные форматы из Java и .NET именно так и устроены, они имеют более высокоуровневую внутреннюю структуру).
А есть в формате ELF аналог виндовских ресурсов и метаданных? А то я смотрю, в Линуксе иконки программ обычно хранятся отдельно, а не внутри исполняемого модуля.
Так в любом случае, для того чтобы провести предлагаемую автором реформу, сначала нужно получить власть над всем миром и объединить его в единое сверхгосударство или хотя-бы конфедерацию. А в этом случае, код "свой-чужой" уже не будет нужен.
Я бы добавил, что в английском (в латинице как первом кандидате на универсальный алфавит) маловато букв для представления всех звуков. Всякие умлауты нежелательны, людям лень писать все эти точечки (вот даже в русском букву "ё" во многих случаях заменяют на "е", что нелогично, а иногда и неоднозначно). Поэтому дополнительные буквы должны быть самостоятельными, и достаточно простыми в написании.
По количеству букв - даже из чисто технических соображений в английском явно не хватает одной буквы для однозначного представления кодировки base64. Ну а если довести число букв до 32, то для base64 и цифры не понадобятся, и опять же степень двойки - это всегда хорошо, мало ли где пригодится.
Я не сомневаюсь что все уже давно придумано:) И вряд ли именно в торрентах будут такое делать. А вот если начнут появляться универсальные клиенты, объединяющие несколько (в идеале как можно больше) p2p сетей, то torrent v2 с его хешами к каждому файлу очень неплохо впишется в эту концепцию, гораздо лучше чем v1.
Воистину гениальный хакер! Искренне восхищаюсь такими людьми и по-хорошему им завидую. Для того чтобы обладать такой продуктивностью, нужно ну очень хорошо уметь полностью погружаться в задачу, причем не от случая к случаю, а стабильно каждый день.
Есть минимум несколько десятков децентрализованных файлообменных сетей. Само собой напрашивается мысль их все микснуть, причем на разных уровнях(к примеру обмен не только файлами но и пирами). Дальше возникает мысль о декомпозиции децентрализованных протоколов таким образом, чтобы любая сеть представлялась чем-то вроде множества "компонентов" разного уровня (сетевые, криптографические, прикладные...) со своими правилами и настройками. Между компонентами должны быть некие универсальные интерфейсы взаимодействия. Т.е. это серьезная работа по стандартизации самих концепций децентрализованных сетей, с тем чтобы любую сеть можно было разложить на простые унифицированные составляющие.
Совершенно верно. Можно было бы просто указать торрент-клиенту некий путь к "файлопомойке" и сказать: вот тебе место где хранятся всякие скачанные отовсюду файлы, проиндексируй и раздавай оттуда все что запросят по хешам". Преимущество - можно было бы не заботиться о постоянном размещении раздачи после скачивания, свободно перемещать ее по файловой системе, сортировать раздачи по смыслу и т.п., и торрент-клиент все равно бы их автоматически находил и раздавал.
Следующий шаг - это просто децентрализованный доступ к файловой системе, как (наверное) в RetroShare.
qBittorrent поддерживает v2, но нужно скачивать не то что предлагается по умолчанию, а то в названии которого есть "_lt20_" . Вроде есть еще несколько клиентов.
С передачей аргументов интересная тема. Исторически передача без квалификаторов означала передачу по значению через стек, хотя на самом деле передача по ссылке или еще как-то ничуть не хуже. Ваша идея отказа от неявного синтаксиса передачи сложных объектов и явного требования указания квалификаторов довольно интересна. Кстати, а почему "copy" а не какой-нибудь спецсимвол типа "@" ? Можно вообще составить список возможных способов передачи и проанализировать, что там есть.
Отличная новость, надеюсь рутрекер и прочие перейдут на новый протокол.
Из разряда мыслей на тему: хорошо бы еще в торрент-файлы вставляли человекоориентированную метаинформацию о самой раздаче (все то что на рутрекере и прочих трекерах требуется так старательно заполнять при создании раздачи). Название, автор, год издания, жанр и прочее. Это же словарь "ключ-значение", а формат Bencode как раз предназначен для такой информации (но нужен общепринятый список ключей). Был бы неплохой задел на децентрализованную сеть будущего.
Я старался брать наиболее простые и универсальные символы. Та же стрелка - вообще древнейший символ, понятный всему человечеству, и достаточно простой чтобы использовать его в рукописном тексте.
Не все символы одинаково востребованы. Например, есть вот такие "изысканные скобки" ﴾ ﴿ U+FD3E U+FD3F (в моем шрифте они отображаются как круглые) - я не знаю откуда они взялись, не удивлюсь если это лишь продукт фантазии кого-то в комитете Unicode. А вот угловые скобки по своей простоте вполне конкурируют с квадратными и фигурными, и полно примеров их применения в математике. Правда, в Unicode почему-то две пары таких скобок: 〈 〉 U+2329 U+232A и ⟨ ⟩ U+27E8 U+27E9. Иначе как бардаком такое положение дел назвать трудно, но что есть то есть)))
У азиатов математика, физика, computer science отличаются от европейских?
ü это символ какого-то языка, и он наверняка есть на клавиатурах тех стран, где этот язык используется. Я же говорю об универсальных символах, не зависящих от языка. Прежде всего научных и технических (хотя может есть и какие-то востребованные лингвистические и прочие символы, не попавшие в ASCII). Можно конечно вспомнить и эмодзи, но это не совсем то направление, которое лично меня интересует:) (да и пользователи эмодзи скорее всего имеют достаточно малое пересечение с пользователями физических клавиатур)
Как только символы появятся на клавиатурах, сразу и языки программирования подтянутся. А применения найдутся, особенно скобкам.
Потому и не использовали, что их нет на клавиатуре. Я вот ради интереса загуглил некоторые символы - Гугл показывает количество результатов: → примерно 3 500 000 000 , ← примерно 1 080 000 000 и т.д. Вообще было бы интересно собрать такую статистику по всем символам.
А как в MacOs ?
Хайподелы. Лучше бы подумали, какие юникодные символы из отсутствующих в ASCII наиболее востребованы, да добавили бы их дополнительными символами на буквенно-цифровые клавиши. Как минимум, стрелки, дополнительные скобки (чтобы отказаться уже от знаков "больше" и "меньше" в качестве шаблонных скобок в программировании) и некоторые математические символы.
Навскидку: → ← ↑ ↓ ▷ ◁ △ ▽ 〈 〉 ⟦ ⟧ ∀ ∃ ⊕ ⊗ ∅ ∈ ∋ ∞ ✅
Разумеется, хранить ресурсы можно и в виде обычных массивов констант (как в линуксе и делается, в частности в Qt из-за этого все ресурсы компилируются именно в сишный код). Дело в стандартизации (стандартное место для иконки приложения, информации об авторе, компании и т.п.), а также в структуризации (в том числе упрощении декомпиляции, понимаю что авторам проприетарщины это нафиг не нужно, но тем ни менее всякие виртуальные форматы из Java и .NET именно так и устроены, они имеют более высокоуровневую внутреннюю структуру).
А есть в формате ELF аналог виндовских ресурсов и метаданных? А то я смотрю, в Линуксе иконки программ обычно хранятся отдельно, а не внутри исполняемого модуля.
Так в любом случае, для того чтобы провести предлагаемую автором реформу, сначала нужно получить власть над всем миром и объединить его в единое сверхгосударство или хотя-бы конфедерацию. А в этом случае, код "свой-чужой" уже не будет нужен.
Я бы добавил, что в английском (в латинице как первом кандидате на универсальный алфавит) маловато букв для представления всех звуков. Всякие умлауты нежелательны, людям лень писать все эти точечки (вот даже в русском букву "ё" во многих случаях заменяют на "е", что нелогично, а иногда и неоднозначно). Поэтому дополнительные буквы должны быть самостоятельными, и достаточно простыми в написании.
По количеству букв - даже из чисто технических соображений в английском явно не хватает одной буквы для однозначного представления кодировки base64. Ну а если довести число букв до 32, то для base64 и цифры не понадобятся, и опять же степень двойки - это всегда хорошо, мало ли где пригодится.
У меня обе версии (x32 и x64) упали сразу при запуске :)
Я не сомневаюсь что все уже давно придумано:) И вряд ли именно в торрентах будут такое делать. А вот если начнут появляться универсальные клиенты, объединяющие несколько (в идеале как можно больше) p2p сетей, то torrent v2 с его хешами к каждому файлу очень неплохо впишется в эту концепцию, гораздо лучше чем v1.
Воистину гениальный хакер! Искренне восхищаюсь такими людьми и по-хорошему им завидую. Для того чтобы обладать такой продуктивностью, нужно ну очень хорошо уметь полностью погружаться в задачу, причем не от случая к случаю, а стабильно каждый день.
Есть минимум несколько десятков децентрализованных файлообменных сетей. Само собой напрашивается мысль их все микснуть, причем на разных уровнях(к примеру обмен не только файлами но и пирами). Дальше возникает мысль о декомпозиции децентрализованных протоколов таким образом, чтобы любая сеть представлялась чем-то вроде множества "компонентов" разного уровня (сетевые, криптографические, прикладные...) со своими правилами и настройками. Между компонентами должны быть некие универсальные интерфейсы взаимодействия. Т.е. это серьезная работа по стандартизации самих концепций децентрализованных сетей, с тем чтобы любую сеть можно было разложить на простые унифицированные составляющие.
Совершенно верно. Можно было бы просто указать торрент-клиенту некий путь к "файлопомойке" и сказать: вот тебе место где хранятся всякие скачанные отовсюду файлы, проиндексируй и раздавай оттуда все что запросят по хешам". Преимущество - можно было бы не заботиться о постоянном размещении раздачи после скачивания, свободно перемещать ее по файловой системе, сортировать раздачи по смыслу и т.п., и торрент-клиент все равно бы их автоматически находил и раздавал.
Следующий шаг - это просто децентрализованный доступ к файловой системе, как (наверное) в RetroShare.
qBittorrent поддерживает v2, но нужно скачивать не то что предлагается по умолчанию, а то в названии которого есть "_lt20_" . Вроде есть еще несколько клиентов.
С передачей аргументов интересная тема. Исторически передача без квалификаторов означала передачу по значению через стек, хотя на самом деле передача по ссылке или еще как-то ничуть не хуже. Ваша идея отказа от неявного синтаксиса передачи сложных объектов и явного требования указания квалификаторов довольно интересна. Кстати, а почему "copy" а не какой-нибудь спецсимвол типа "@" ? Можно вообще составить список возможных способов передачи и проанализировать, что там есть.
Отличная новость, надеюсь рутрекер и прочие перейдут на новый протокол.
Из разряда мыслей на тему: хорошо бы еще в торрент-файлы вставляли человекоориентированную метаинформацию о самой раздаче (все то что на рутрекере и прочих трекерах требуется так старательно заполнять при создании раздачи). Название, автор, год издания, жанр и прочее. Это же словарь "ключ-значение", а формат Bencode как раз предназначен для такой информации (но нужен общепринятый список ключей). Был бы неплохой задел на децентрализованную сеть будущего.
Очевидно, готовятся к тому, чтобы блокировать каналы, неугодные правящему режиму.