года два назад yggdrasil работал и работал отлично, сейчас же ситуация изменилась... трафик замедляется/блокируется и сеть стала непредсказуемой на многих провайдерах, появились длинны пинги, обрывы и т.д. НО! несмотря на это замены в простоте настройки и функционала практически нет. Незаменимая штука для настройки OpenWRT роутеров, всегда можно законнектиться к самым закрытым рутерам ну или к серверам.
Но комментарий я пишу, что бы познакомить с еще более прекрасной технологией mesh сетей. Она заслуживает отдельной статьи (автору на заметку). Это Reticulum. Технология схожа с Yggdrasil в плане mesh маршрутизации, но работает поверх любых транспортов. Можно даже поверх почтовых голубей построить mesh, это будет работать... сеть уже работает по радио протоколам, через обычный интернет, через i2p и даже через yggdrasil. Технология не новомодная, а уже довольно широко известная, рабочая. Но если ygg работает как tun интерфейс на машине, reticulum создает свой тоннель без интерфейса, есть и другие отличия само собой. Пакет reticulum пролетит часть пути по радиомосту, часть по мобильной сети, часть по i2p, часть по yggdrasil и в итоде достигнет точки назначения. Кстати генерация адресов в yggdrasil и reticulum так же схожа и гипотетически обратно заменяема. Это значит что те же ключи на основе которых полуачется адрес yggdrasil подойдут и для адреса reticulum.
окей, что то похожее на битмесседж... но добавлена отправка раз в N секунд, что еще сильнее создает флуд в сети
не совсем понятно, как устроена доставка если пользователь которому адресовано сообщение был оффлайн, есть какое то подтверждение доставки или иной механизм?
не понятно что делать если ключ скомпроментирован, обычно делается основной ключ и ключ представляющий тебя в сети, и смена ключа происходит безболезненно, а в этом проекте как?
понятно что есть бутстрап сети, но дальше как это работает? таблица узлов с постоянным обновлением?
У меня только два вопроса. Первый это где взять последнюю рабочую версию QNX (почему бы кстати не запилить статью с историей этой интереснейшей ОС) И второй, где взять программы для QNX наподобии такого эмулятора.
потенциально можно, но не нужно... эта штука может работать просто в терминале, а mpv захочет либо продвинутый терминал, либо отдельные gui... про плюсы libcaca я писал в двух статьях, просто перечислю (отсутствуе зависимостей, кодека, минимальный трафик, скорость рендера)
а может кто то подскажет, можно ли системный курсор текста менать на свой? например цвет ему разный давать, синий например это английская раскладка... а красная например русская? или например если цвет нельзя, то хотя бы заменить курсор на E для английского и R для русского? Такое было в ZX Spectrum и это было довольно удобно
Смотри, картинки были конвертированы в webp, вес большой я убрал... оставил только одну тяжелую картинку. Опечатку поправил, спасибо Y, Cb, Cr конечно же 😁 Утилита работает на базе ffmpeg, она отдает nut, который дальше уже конвертируется в jpg/png + base64, если мы рендерим с ключом -super Если рендер обычнтый, то рендерим в глифы и выводим через tcell Историю создания кодека можно почитать в статье https://habr.com/ru/articles/973868/, а oil painting возникает за счет того что технология вывода на экран не позволит выдать что т олучше чем сейчас Да webp почему то не читает 😁 но создает 100%
а, отсылку понял и нет, это не может использоваться для обхода кзкиа либо ограничений РКН, во первых это не законно, во вторых это не поможет, белые списки это белые списки 😁
ygg не поможет заниматься обходами ограничений, но поможет с проблемами NAT и как я написал ниже со всем сишным стеком который бы тянулся в либу
Честно говоря отсылки не понял... все протоколы и кодеки (кроме видео кодека) это зрелые открытые технологии.
Тоннель ygg выбран как отличное решение для отказа от stun серверов, в отличое от WebRTC и других подобных решений, плюс я из коробки получил гарантированное восстановления связи при обрыве, а это меньше кода и логики внутри.
Если бы я например использовал что то другое, мне пришлось бы использовать весь тот стек который сделал бы утилиту сильно жирнее. Пришлось бы делать какие то сертификаты и шифрования, двойные рукопожатия и весь тот геморой которого хотелось избежать... опять же, NAT, пробросы портов и т.д.
Ну и вес выходной получился бы сложнее, плюс в go пришлось бы тащить кучу сишного хлама, каких то зависимостей и прочего прочего... размер утилиты вырос бы до 500 Мб примерно, а сложность сборки проекта улетела бы в космос.
Сейчас утилита в районе 10 Мб, и собирается без каких либо проблем под любую ОС, хоть под винду, хоть под фряху. Едиснтвенное под что я ее еще не портировал это plan9. И экзотика типа QNX, Haiku и т.д.. Причем сейчас это выглядит как весьма легкое занятие, в отличии от реализации на WebRTC, сертификатах и т.д.
Я уже думал, на счет этого, но, есть несколько нерешенных проблем,
1. нужно решить проблему с уведомлением о входящем звонке, т.е. клиент должен что то где то сделать (куда то что то послать) что бы у того кому ты звонишь появилось уведомление о входящем звонке… надо ресерчить как такое делается
2. нужно подумать делать просто звонки, или звонки с видео, если просто звонки, то тут вообще все просто, а вот если с видео, то нужно будет добавить другой кодек. Возможно прямо на стороне приложения, т.е. статическая либа будет транспортом, для передачи кодека… и если мы идем вторым путем, но можно будет использовать не g722 а что то пободрее, наприемр codec2 или opus или еще что то для звука, и какой то hevc для видео и в таком случае потеряется обратная совместимость с оригинальной утилитой
3. для добавления контакта нужно передать адрес френда, а адрес можно передать только как то отдельно, сообщением например или контактом (этот момент тоже надо продумать)
я не знаю пока как это сделать... но я бы с удовольствием добавил обе свои утилиты кстати я вроде как релиз запилил, более стабильный и быстрый, ну а если запустить в iterm с ключом -super то вообще классныей спецэффект 😁
reticulum гоняет пакеты по любым транспортам, при желании можно сделать и тоннель (я видел в гите такие решения)
года два назад yggdrasil работал и работал отлично, сейчас же ситуация изменилась... трафик замедляется/блокируется и сеть стала непредсказуемой на многих провайдерах, появились длинны пинги, обрывы и т.д. НО! несмотря на это замены в простоте настройки и функционала практически нет. Незаменимая штука для настройки OpenWRT роутеров, всегда можно законнектиться к самым закрытым рутерам ну или к серверам.
в свое время я даже сделал реализацию свой звонилки на базе ygg: https://habr.com/ru/articles/976430/
Но комментарий я пишу, что бы познакомить с еще более прекрасной технологией mesh сетей. Она заслуживает отдельной статьи (автору на заметку). Это Reticulum. Технология схожа с Yggdrasil в плане mesh маршрутизации, но работает поверх любых транспортов. Можно даже поверх почтовых голубей построить mesh, это будет работать... сеть уже работает по радио протоколам, через обычный интернет, через i2p и даже через yggdrasil. Технология не новомодная, а уже довольно широко известная, рабочая. Но если ygg работает как tun интерфейс на машине, reticulum создает свой тоннель без интерфейса, есть и другие отличия само собой.
Пакет reticulum пролетит часть пути по радиомосту, часть по мобильной сети, часть по i2p, часть по yggdrasil и в итоде достигнет точки назначения.
Кстати генерация адресов в yggdrasil и reticulum так же схожа и гипотетически обратно заменяема. Это значит что те же ключи на основе которых полуачется адрес yggdrasil подойдут и для адреса reticulum.
зачем отдельную заону? можно просто как wan назначить и все
окей, что то похожее на битмесседж... но добавлена отправка раз в N секунд, что еще сильнее создает флуд в сети
не совсем понятно, как устроена доставка если пользователь которому адресовано сообщение был оффлайн, есть какое то подтверждение доставки или иной механизм?
не понятно что делать если ключ скомпроментирован, обычно делается основной ключ и ключ представляющий тебя в сети, и смена ключа происходит безболезненно, а в этом проекте как?
понятно что есть бутстрап сети, но дальше как это работает? таблица узлов с постоянным обновлением?
У меня только два вопроса. Первый это где взять последнюю рабочую версию QNX (почему бы кстати не запилить статью с историей этой интереснейшей ОС) И второй, где взять программы для QNX наподобии такого эмулятора.
для мака сделал https://github.com/svanichkin/zxcaret
для мака сделал https://github.com/svanichkin/zxcaret
потенциально можно, но не нужно... эта штука может работать просто в терминале, а mpv захочет либо продвинутый терминал, либо отдельные gui... про плюсы libcaca я писал в двух статьях, просто перечислю (отсутствуе зависимостей, кодека, минимальный трафик, скорость рендера)
получается надо патч в GTK/QT делать? а есть вариант сделать какой то оверлей поверх всех окон, и рисовать поверх?
а может кто то подскажет, можно ли системный курсор текста менать на свой? например цвет ему разный давать, синий например это английская раскладка... а красная например русская? или например если цвет нельзя, то хотя бы заменить курсор на E для английского и R для русского? Такое было в ZX Spectrum и это было довольно удобно
вообще я думаю можно... смотри, плагин помоему умеет в файл писать, а раз так то утилита может это файл проигрывать
я хочу попробовать линукс телефон, меня немного достали ограничения Android/iOS 😁
Смотри, картинки были конвертированы в webp, вес большой я убрал... оставил только одну тяжелую картинку.
Опечатку поправил, спасибо Y, Cb, Cr конечно же 😁
Утилита работает на базе ffmpeg, она отдает nut, который дальше уже конвертируется в jpg/png + base64, если мы рендерим с ключом -super
Если рендер обычнтый, то рендерим в глифы и выводим через tcell
Историю создания кодека можно почитать в статье https://habr.com/ru/articles/973868/, а oil painting возникает за счет того что технология вывода на экран не позволит выдать что т олучше чем сейчас
Да webp почему то не читает 😁 но создает 100%
Добавил в статью целый абзац... просто на всякий случай, во избежание недопониманий
а, отсылку понял и нет, это не может использоваться для обхода кзкиа либо ограничений РКН, во первых это не законно, во вторых это не поможет, белые списки это белые списки 😁
ygg не поможет заниматься обходами ограничений, но поможет с проблемами NAT и как я написал ниже со всем сишным стеком который бы тянулся в либу
Честно говоря отсылки не понял... все протоколы и кодеки (кроме видео кодека) это зрелые открытые технологии.
Тоннель ygg выбран как отличное решение для отказа от stun серверов, в отличое от WebRTC и других подобных решений, плюс я из коробки получил гарантированное восстановления связи при обрыве, а это меньше кода и логики внутри.
Если бы я например использовал что то другое, мне пришлось бы использовать весь тот стек который сделал бы утилиту сильно жирнее. Пришлось бы делать какие то сертификаты и шифрования, двойные рукопожатия и весь тот геморой которого хотелось избежать... опять же, NAT, пробросы портов и т.д.
Ну и вес выходной получился бы сложнее, плюс в go пришлось бы тащить кучу сишного хлама, каких то зависимостей и прочего прочего... размер утилиты вырос бы до 500 Мб примерно, а сложность сборки проекта улетела бы в космос.
Сейчас утилита в районе 10 Мб, и собирается без каких либо проблем под любую ОС, хоть под винду, хоть под фряху. Едиснтвенное под что я ее еще не портировал это plan9. И экзотика типа QNX, Haiku и т.д.. Причем сейчас это выглядит как весьма легкое занятие, в отличии от реализации на WebRTC, сертификатах и т.д.
Я уже думал, на счет этого, но, есть несколько нерешенных проблем,
1. нужно решить проблему с уведомлением о входящем звонке, т.е. клиент должен что то где то сделать (куда то что то послать) что бы у того кому ты звонишь появилось уведомление о входящем звонке… надо ресерчить как такое делается
2. нужно подумать делать просто звонки, или звонки с видео, если просто звонки, то тут вообще все просто, а вот если с видео, то нужно будет добавить другой кодек. Возможно прямо на стороне приложения, т.е. статическая либа будет транспортом, для передачи кодека… и если мы идем вторым путем, но можно будет использовать не g722 а что то пободрее, наприемр codec2 или opus или еще что то для звука, и какой то hevc для видео и в таком случае потеряется обратная совместимость с оригинальной утилитой
3. для добавления контакта нужно передать адрес френда, а адрес можно передать только как то отдельно, сообщением например или контактом (этот момент тоже надо продумать)
просто в статье много букафф, а вообще поддежриваются по возможности вобще все треминалы
Да, есть на Reddit где встретили довольно тепло и есть на некоторых других ресурсах, где пост прошел не замеченым.
я не знаю пока как это сделать... но я бы с удовольствием добавил обе свои утилиты
кстати я вроде как релиз запилил, более стабильный и быстрый, ну а если запустить в iterm с ключом -super то вообще классныей спецэффект 😁