Привет.
Поскольку t.me/swarmsync стал англоязычным, создаю русскоязычную версию.
Поскольку t.me/swarmsync стал англоязычным, создаю русскоязычную версию.
Telegram
Swarm RON
Replicated object notation http://replicated.cc,
CRDTs, data synchronisation.
A low-traffic chat. Off-topic messages get deleted.
Russian twin channel: @RONrussian
CRDTs, data synchronisation.
A low-traffic chat. Off-topic messages get deleted.
Russian twin channel: @RONrussian
Является ли комбинаторный взрыв в конечном автомате техногенной катастрофой?
Anonymous Poll
31%
да
13%
нет
56%
шойгу
Local-first и децентрализация
Является ли комбинаторный взрыв в конечном автомате техногенной катастрофой?
Опрос имел вполне жизненную подоплёку, тем не менее. В C++ реализации RON используется ragel http://www.colm.net/open-source/ragel
С его помощью сделаны парсеры UTF8, RONt, JSON, RFC3986 URI, HTTP. Что, кстати, заняло не очень большое время. На подходе wikitext и CSV. Причём Ragel в ванильной конфигурации парсит только регулярные языки, поэтому для JSON он используется скорее как лексер.
В любом случае, ragel использует что-то вроде алгоритма Томпсона и потому всегда парсит за линейное время https://swtch.com/~rsc/regexp/regexp1.html
PCRE, которое используется везде (и в js), делает бэктрекинг, из-за чего может потребовать экспоненциального времени на выполнение. Я сталкивался с таким в проде, и не только я. То есть, Томпсон всяко круче?
Увы, обратная сторона Томпсона - комбинаторный взрыв в парсере из-за того, что возможно 2**n суперпозиций состояний.
Так вот, при написании парсера вики-разметки такая проблема и возникла. Ибо вики разметка не имеет чётких границ элементов, поэтому парсер держит в уме сложные суперпозиции.
Взрыв получался, если в парсер вики разметки включить парсер URI. Грамматика URI сложна и 2**n резко бабахает.
Такая вот занимательная химия.
С его помощью сделаны парсеры UTF8, RONt, JSON, RFC3986 URI, HTTP. Что, кстати, заняло не очень большое время. На подходе wikitext и CSV. Причём Ragel в ванильной конфигурации парсит только регулярные языки, поэтому для JSON он используется скорее как лексер.
В любом случае, ragel использует что-то вроде алгоритма Томпсона и потому всегда парсит за линейное время https://swtch.com/~rsc/regexp/regexp1.html
PCRE, которое используется везде (и в js), делает бэктрекинг, из-за чего может потребовать экспоненциального времени на выполнение. Я сталкивался с таким в проде, и не только я. То есть, Томпсон всяко круче?
Увы, обратная сторона Томпсона - комбинаторный взрыв в парсере из-за того, что возможно 2**n суперпозиций состояний.
Так вот, при написании парсера вики-разметки такая проблема и возникла. Ибо вики разметка не имеет чётких границ элементов, поэтому парсер держит в уме сложные суперпозиции.
Взрыв получался, если в парсер вики разметки включить парсер URI. Грамматика URI сложна и 2**n резко бабахает.
Такая вот занимательная химия.
Полный деплатформинг в 24 часа без каких либо судов и вообще бумаг!
Альтернатива децентрализации – цифровой тоталитаризм. Информационные супермонополии располагают невообразимым количеством информации и контролируют её циркуляцию. Каких-либо сдержек и противовесов не осталось.
Альтернатива децентрализации – цифровой тоталитаризм. Информационные супермонополии располагают невообразимым количеством информации и контролируют её циркуляцию. Каких-либо сдержек и противовесов не осталось.
👍1
Можно поздравить IPFS
https://brave.com/brave-integrates-ipfs/
https://brave.com/brave-integrates-ipfs/
Brave
Brave Integrates IPFS | Brave
IPFS, the peer-to-peer hypermedia protocol designed to make the Web faster, safer, and more open, has been integrated into Brave, the fast, privacy-oriented browser, reinventing the Web for users, publishers and advertisers.
IPFS в Brave работает возможно чуть медленней HTTP, но работает вполне себе децентрализовано, в peer-to-peer режиме.
Единственно, в сети неизбежно полная вакханалия, соединения на множество адресов для скачивания/раздачи и постоянные разговоры с DHT хостами. В строгой корпоративной сети это лучше не запускать.
Единственно, в сети неизбежно полная вакханалия, соединения на множество адресов для скачивания/раздачи и постоянные разговоры с DHT хостами. В строгой корпоративной сети это лучше не запускать.
Forwarded from Victor Grishchenko
bluesky работают потихоньку
выпустили обзор технологий дец веба
https://twitter.com/bluesky/status/1352302821140549632?s=20
выпустили обзор технологий дец веба
https://twitter.com/bluesky/status/1352302821140549632?s=20
Twitter
bluesky
Working virtually through the pandemic, this group self-organized, invited additional experts, and created a review of the ecosystem around protocols for social media. You can read it here: https://t.co/U5DczWX1qb
BitCoin это очень злая шутка над людьми. Демонически злая. Валюта устроена так, что её капитализация - это примерная оценка энергии, потраченной на "майнинг". Изначально заявленные цели - популярная криптовалюта, анонимизация и отсутствие посредников - оказались пшиком, и это было прекрасно понятно и 10 лет назад https://web.archive.org/web/20110724171749/http://www.pds.ewi.tudelft.nl/~victor/bitcoin.html. Зато инцентивизация и спекулятивный компонент удались на славу.
Уже раздаются голоса за насильственное уничтожение BitCoin https://medium.com/the-capital/green-hackers-around-the-world-lets-destroy-bitcoin-725700434a8f
В этой связи, инвестиция Tesla в BitCoin расставляет точки над i. Tesla - это про зелёное будущее или про силу интернет мемов? Конечно, второе.
Кстати, когда у основателя DeLorean пошатнулись дела, он занялся контрабандой кокаина, но был пойман (1982). Самая крутая тачка того периода, если кто помнит "Назад в будущее". Такая вот параллель.
Уже раздаются голоса за насильственное уничтожение BitCoin https://medium.com/the-capital/green-hackers-around-the-world-lets-destroy-bitcoin-725700434a8f
В этой связи, инвестиция Tesla в BitCoin расставляет точки над i. Tesla - это про зелёное будущее или про силу интернет мемов? Конечно, второе.
Кстати, когда у основателя DeLorean пошатнулись дела, он занялся контрабандой кокаина, но был пойман (1982). Самая крутая тачка того периода, если кто помнит "Назад в будущее". Такая вот параллель.
Medium
Green hackers around the world, let’s destroy Bitcoin
Bitcoin is the worst waste of resources and energy in human history. It is solely used for financial speculation, with no genuine utility…
На прошедшем в выходные FOSDEM был трек про распределенный Веб, были интересные докладчики https://fosdem.org/2021/schedule/track/beyond_blockchain_distributed_web/
Доклад от IPFS при этом шёл в треке "Open Research Tools and Technologies" https://fosdem.org/2021/schedule/event/open_research_filecoin_ipfs/ Видимо, IPFS интересна и другая аудитория, помимо энтузиастов крипты и децентрализации :) Что ж, это очень зрелый подход.
Доклад от IPFS при этом шёл в треке "Open Research Tools and Technologies" https://fosdem.org/2021/schedule/event/open_research_filecoin_ipfs/ Видимо, IPFS интересна и другая аудитория, помимо энтузиастов крипты и децентрализации :) Что ж, это очень зрелый подход.
archive.fosdem.org
FOSDEM 2021 - Beyond Blockchain - Distributed Web devroom
Теперь про RON. В системе PLS/DaRWiN добрый старый markdown в реализации commonmark.org был заменен на свой собственный минималистичный диалект *с формальной грамматикой*, названный StrictMark http://doc.replicated.cc/%5EWiki/strictmark.sm
Такой дерзкий подход был, тем не менее, с интересом принят сообществом CommonMark :)
Такой дерзкий подход был, тем не менее, с интересом принят сообществом CommonMark :)
RON, DaRWiN и diff'ы по Майерсу
Одно из демо-приложений RON это система контроля версий DaRWiN. На данный момент эта система хранит документацию RON, ну и понятно, работает подопытным кроликом. Мерж там, понятное дело, бесконфликтный, на основе CRDT (CT Chronofold).
Поскольку система реал-таймовая, то контроль версий, неизбежно, посимвольный. Исторические diff и patch, и всё что их использует (git, например), отслеживают изменения построчно (есть нюансы). Во многом это из-за того, что сложность алгоритма у diff это O(ND), где N размер текстов и D количество изменений. Понятно, что при посимвольном разборе N будет больше, да и D тоже. На глазок, раз в 60-70 :) Исторически, вероятно, компьютеры не тянули столько. Тем более, есть вероятность, что какой-нибудь маньяк засунет в систему не только Войну и Мир (все 2.5MB), но и какой-нибудь CSV файл с результатами всекитайской переписи.
Вторую проблему DaRWiN решает просто: CSV это другой тип данных и diff для него другой, не посимвольный. DaRWiN хранит структуры данных (текст, таблица), а не буковки.
А первую проблему интересно было проверить. Поэтому я взял Войну и Мир и все запятые там заменил на точки с запятой. Это максимально неприятный сценарий, 30тыс изменений и нельзя отрезать неизменные голову и хвост, упростив задачу. Что ж, некоторое время алгоритму пришлось подумать. Но не так долго.
Вывод? Нет причин не использовать посимвольные diff'ы в DaRWiN. Это сильно упрощает вычитку и коррекцию текста. Это позволяет показать нормальные diff-ы после re-wrap'а текста. И это работает в реальном времени.
Но если вам не нравятся запятые у Льва Толстого, то, конечно, придётся медленно вдохнуть и выдохнуть.
Одно из демо-приложений RON это система контроля версий DaRWiN. На данный момент эта система хранит документацию RON, ну и понятно, работает подопытным кроликом. Мерж там, понятное дело, бесконфликтный, на основе CRDT (CT Chronofold).
Поскольку система реал-таймовая, то контроль версий, неизбежно, посимвольный. Исторические diff и patch, и всё что их использует (git, например), отслеживают изменения построчно (есть нюансы). Во многом это из-за того, что сложность алгоритма у diff это O(ND), где N размер текстов и D количество изменений. Понятно, что при посимвольном разборе N будет больше, да и D тоже. На глазок, раз в 60-70 :) Исторически, вероятно, компьютеры не тянули столько. Тем более, есть вероятность, что какой-нибудь маньяк засунет в систему не только Войну и Мир (все 2.5MB), но и какой-нибудь CSV файл с результатами всекитайской переписи.
Вторую проблему DaRWiN решает просто: CSV это другой тип данных и diff для него другой, не посимвольный. DaRWiN хранит структуры данных (текст, таблица), а не буковки.
А первую проблему интересно было проверить. Поэтому я взял Войну и Мир и все запятые там заменил на точки с запятой. Это максимально неприятный сценарий, 30тыс изменений и нельзя отрезать неизменные голову и хвост, упростив задачу. Что ж, некоторое время алгоритму пришлось подумать. Но не так долго.
Вывод? Нет причин не использовать посимвольные diff'ы в DaRWiN. Это сильно упрощает вычитку и коррекцию текста. Это позволяет показать нормальные diff-ы после re-wrap'а текста. И это работает в реальном времени.
Но если вам не нравятся запятые у Льва Толстого, то, конечно, придётся медленно вдохнуть и выдохнуть.
Вчера было интересно. Меня немного занесло и я сделал скриптовый язык поверх RON. То есть, весь парсинг и типы RON'ом уже решены, так что добавить нужно было немного. Тем более что язык сам прорастал через асфальт, разные тулзы уже использовали свои маленькие микроязычки команд. А конкретно сейчас меня подтолкнул маленький случай кодогенерации на awk, который выглядел, как плевок. Все эти грязные сепараторы и липкая пунктуация... нехорошо.
За день работы язык научился выполнять заклинания вроде
Назвал Drone (произносится "дрын").
Для простой кодогенерации пока достаточно, развивать буду по мере необходимости.
За день работы язык научился выполнять заклинания вроде
for id string in 'ron/status.ron', write _1 _2;
где большая часть слов, технически, 128 битные UUID-ы в Base64 записи, но это станет заметно только тогда, когда мы попытаемся объявить переменную с именем длиннее 20 символов. Чем такой язык лучше awk и прочих? В первую очередь, типизацией. Все переменные это туплы RON из RON атомов (UUID, INT, STRING, FLOAT). Вся обычная возня с парсингом уходит, данные ощущаются скорее как Excel, чем как командная строка UNIX.Назвал Drone (произносится "дрын").
Для простой кодогенерации пока достаточно, развивать буду по мере необходимости.
