localhost_frssoft/frssoft-site
1
0
Fork 0
mirror of https://git.phreedom.club/localhost_frssoft/frssoft-site synced 2025-05-10 04:08:40 +00:00
Code Issues Projects Releases Packages Wiki Activity

init commit

Browse source
This commit is contained in:
localhost_frssoft 2023-08-08 14:15:17 +03:00
commit 8a766816dd
19 changed files with 12253 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
RU/articles/2022-03-08_data-files-formats.gmi Normal file
View file

@ -0,0 +1,21 @@
# Форматы файлов и сжатие
Ахтунг! Это тестовая статья, я не несу ответственности за прочтение этой статьи
Не так давно пришёл к тому, что люди далеко не всегда эффективно используют пространство на диске, скорее всего из-за лишней мороки с конвертированием файлов в более экономичные форматы с минимальными потерями качества.
Ну, вот к примеру, возьмем какую-нибудь коллекцию mp3 320kbps, условно весит 1 гб, но ведь довольно давно существует открытый формат ogg/vorbis, он жмёт лучше и при этом качество бывает выше, чем у mp3. По умолчанию ffmpeg конвертирует в ogg с битрейтом 128, но если у вас оборудование не hi-res, то разницу услышать будет весьма проблематично, а вот вес коллекции может поубавиться аж в 1.5-2 раза!
Конечно могут проявится ньюансы, в виде того, что ogg может просто напросто не поддерживаться вашим физическим mp3-плеером, но это скорее исключение чем правило. (Чаще всего это происходит если оборудование было создано до появления того или иного формата)
Для фоток аналогично, webp, хотя и название прямо намекает, что этот формат для веба, но если у Вас места на диске не особо много, то сие очень спасает.
Для видео не всё так одназначно, с одной стороны есть webm и ogv, но скорость перекодирования столь медленная, что одно видео длящееся 1 час можно перекодировать 2-3 часа подряд, и насколько я знаю, они не поддерживают аппаратное ускорение видеокарты, потому процессор вскипит.
А вот тексты, неплохо было бы сжимать и доставать необходимый из архива (да, ведь необязательно распаковывать весь архив, чтобы читать один из файлов). Причём, тексты именно чистые text/plain данные, потому что офисные форматы чаще всего уже сами себя архивируют внутрь, а жать архив в архиве бесполезно.
Хотя, я не исключаю то, что навело мысль о написании этой недостатьи наличие у самого малого пространства на диске, но это если сравнивать относительно террабайтников, я то живу на 128 гб, и где-то занимаю половину из этого.
### Replies
=> gemini://pub.phreedom.club/~kornilovnet/reply.gmi > 2023-03-25 14:15 MSK
=> .. Back

51
RU/articles/2023-01-14_64kbps.gmi Normal file
View file

@ -0,0 +1,51 @@
# "Замеры" жизни под 64 kbit/s интернетом основанные на личном опыте
Поправка: Скорость не постоянная. В среднем 5-6 Кбайт/с на самом деле.
Поправка 2: Отдача 32 kbit
В общем, шёл 14 день, как я выживаю на медленном интернете, в виду финансовых проблем (и не только). Такой интернет примерно симулирует олдовый средний интернет через dial-up модем.
=> gemini://gemi.dev/cgi-bin/wp.cgi/view/ru?Коммутируемый+доступ Немного о скоростях dial-up на Gemipedia
В целом, 64kbps в современном вебе просто уже с трудом справляется, вероятность что, что-то отвалится по таймауту довольно высока, особенно при активной параллельной загрузке, пожалуй просто приведу список, как ведет себя что-либо при такой скорости (возможно будет пополняться).
___
Обычные сайты "большого" веба - весьма всё плохо, если зайти на сайт с отключенными картинками, можно успеть выпить чашку чая пока он загружается... Если отключить вообще всё, кроме стилей, то уже намного лучше, но потребуется от 10 секунд. С сжимающими прокси загружаются гораздо лучше, у многих сайтов не минифицирован JS и CSS, так же редка поддержка сжатия brotli на серверах, да и на клиентских браузерах не всегда присутствует\запрашивается.
Сайты смолвеба (HTML) - открываются довольно шустро, даже в links они открываются быстрее (а, он умеет прямо на лету отображать загружаемый html).
RSS (XML) - same смолвеб, исключая длинные фиды
gemini/gopher/finger - открываются почти нативно без ожидания, ну оно и понятно, голый текст в основном, но думаю с сжатием они бы открывались вообще на скорости ракеты! Правда вот gemini из-за шифрования TLS открывается несколько дольше, но это в целом про любой обмен данными, где нужно дополнительно сделать секьюрити рупожатие и обменяться ключами.
I2P - Для работы необходимо поставить в конфигах самый минимальный bandwidth 32 kbps, иначе он съедаёт всю скорость канала и сам же отваливается. Первичная инициализация может быть _значительно_ дольше. Когда роутеров достаточно и i2pd уже проинициализован, не все ноды открываются сразу, нужно "пнуть" соединение с i2p сайтом несколько раз, предварительно подождав минуту-две. В целом, сайты могут открываться, но я очень рекомендую отключить вообще все плюшки и делать это через консольные браузеры. Стриминг (i2p радио) на такой скорости просто отваливается по таймауту или EOF. Проблема в основном с коннектом к outbound tunnels, многие из них failed. Так же, пользоваться клирнетом, пока I2P включен не выйдёт - будет отвал по таймауту.
Yggdrasil v4 - очень нестабильно, но относительно (значительно быстрее I2P) быстро работает. Довольно легко теряются соединения с пирами.
ssh -C - работает, иначе как бы я юзал пабникс? :) Но, есть парочка нюансов, если вдруг из output полезет гора текста в терминал, то можно довольно долго наблюдать, пока он его весь выведет. Ввод очень сильно лагает (сказывается скорость 32 кбита на аплинк), особенно если параллельно программа выводит какие-то изменяющиеся данные, буквально ~1 секунда на символ.
git clone; git push - работает вполне сносно, разве что git clone на больших репозиториях стоит выполнять с --depth 1. А коммиты посылать мелкими порциями, а не одним огромным, хотя git всё равно пакует в один архив при отправке\получении.
Pleroma/Mastodon и другие JSON API\ActivityPub (Get) - работает вполне неплохо (+ сжатие), но response довольно долгий, а вот их оригинальные вебни в основном не предусматривают использование такого медленного коннекта, но думаю, если сравнивать с тем, что есть у централизованных сервисов, эти вебни будут меньше
Matrix - работает, но сообщения долго отправляются иногда, так же вероятность словить "Матрикс момент" (с), связанный с тем, что сообщение пришло, а ключей к нему нет для расшифровки повышается в разы
Jabber/IRC/netcat chat/others text messengers - работают нативно, как раз были созданы в условиях низкоскоростных передач :)
Jitsi Meet - присоединяется к конференции (если это приложение, в случае вебни придётся ждать вечность), но не юзабельно: от собеседников слышно примерно часть от одного слова, а на отправку примерно так же. (Естественно, audio-only)
Mumble - Работает на самом низком пресете качества. Присоединяется к комнате, собеседников слышно через слово, возможно если попросить их убавить у себя качество, то будет нормально. Переодически возможны переподключения. Чат стабилен.
HedgeDoc - После ожидания минут 4-5 страница с колабаративным документом таки загрузится, в принципе работает, но довольно сильно пролагивает, быстро редактировать документ не получится вместе.
OpenStreetMap - Медленно, но работает, на такой случай лучше использовать оффлайн карты
Любая не сжатая медиа - долго, можно сразу поставить на загрузку и пережидать прогон мегабайтов по кбитному каналу в IRL (попить чай не спеша например)
Аудио пожатое (mono) - 8kbps, 16, 32 => fine, pretty good; 64 => работает, но с всё таки прерываясь на пределе в буферизацию
Видео пожатое - HEVC 128x96 с битрейтом в 64, 12 кадров в секунду, работает, но смотрибельность оставляет желать лучшего, если вы любитель высококачественного и владелец мониторов высокого разрешения.
У обоих пунктов выше, желательно при реалтаймовой передаче использовать mpegts с модифицированным размером пакета, например -ts_packetsize 1024, но я пока не уверен помогает ли это. Вот, для примера можете посмотреть скрипты [CGI], для перекодирования с помощью ffmpeg
=> https://gitea.phreedom.club/localhost_frssoft/transcoders_cgi.git [CGI]
___
=> .. back

1725
RU/articles/2023-01-19_clearnet_url_pack_share.gmi Normal file
View file

File diff suppressed because it is too large Load diff

21
RU/articles/2023-03-18_tut_vs_bloatfe.gmi Normal file
View file

@ -0,0 +1,21 @@
# tut vs bloat-fe
Дошли руки написать, ну что-то типа краткого сравнения фронтенда bloat и клиента tut. Оба достаточно минималистичны, bloat работает в любом браузере (что несколько жирновато, если это современный браузер), tut консольный. Оба юзают mastodon-like API. На данный момент пользуюсь чаще tut, вот он кстати
=> https://github.com/RasmusLindroth/tut
=> https://gh.phreedom.club/RasmusLindroth/tut
В нём есть всё необходимое, в том числе поддерживается реал-таймовое обновление лент, цветовые темы, умеет создавать опросы, добавлять описания к картинкам и проставлять локаль поста. Одного там только не хватает - поиска по постам, ну и иногда его сегфолтит, но редко. Попытка как-то приляпать в код поиск по постам не увенчалась успехом, код там несколько замудренней (ну или у меня лапы просто) чем у bloat'a. Картинки и аватарки заранее не подгружает, что очень хорошо, если трафик сильно лимитирован или скорость 64 кбит/с :)
Bloat тоже неплох, но например если нужно открыть несколько аккаунтов, то есть пару костылей - юзать профили\контейнеры браузера или поднимать по инстанции bloat на разные порты. Ещё, он не умеет прикреплять описание к картинкам и не имеет возможности получать ленты в реальном времени, скорее всего для реализации этих плюшек придётся таки обмазаться JavaScript'ом или делать костыль в виде "недозагруженной" страницы. Собственно, вот апстримная версия bloat
=> https://git.freesoftwareextremist.com/bloat
А вот мой форк, на ветке localhost-custom, там немного фич добавлено, в основном для плеромы (эмодзи-реакции), поиск по тегам, кастомная видимость репоста, а ещё добавил страницу для регистрации прямо из фронтенда (но, скорее всего оно не работает). Ну и по мелочи там всякий хлам. В целях безопасности рекомендую использовать только как локальный, а не публичный (расшаренный в WWW). Изредка синхронизирую изменения с апстримом, вручную исправляя конфликты слияний. К слову говоря, ранее параметры пользователя хранились на стороне самого bloat'а на диске, а сейчас не так давно автор отрефакторил код и теперь всё в куках.
=> https://git.phreedom.club/localhost_frssoft/bloat
Note: Сравнение клиента нативного с сетевым может выглядить несколько некорректно, пардон.
=> .. back

23
RU/articles/2023-04-03_proto_diff.gmi Normal file
View file

@ -0,0 +1,23 @@
# Сравнение протоколов в виде таблицы (условное ИМО)
```
1 - Есть много клиентов под протокол, или может быть открыт встроенными средствами системы (+)
2 - Легкое дружелюбное текстовое форматирование (+)
3 - Позволяет добавлять много заголовков (privacy -)
4 - Легко проксируется в оверлейные сети (+)
5 - Является спрятанным сокровищем на видном месте (+)
6 - Имеет большое комьюнити (+/-)
7 - Может быть использован для загрузки трекинга, рекламы и прочего блоата (-)
_________________________________________
||| Gemini | Gopher | Spartan | HTTP |
|1| да | да | ~ | да |
|2| да | 50/50 | да | нет |
|3| нет | нет | нет | да |
|4| 50/50 | да | да | да |
|5| да | да | ~ | нет |
|6| да | да | нет | all web |
|7| нет | нет | нет | да |
'''''''''''''''''''''''''''''''''''''''''
```

87
RU/articles/2023-04-05_i2p_federation_initiative.gmi Normal file
View file

@ -0,0 +1,87 @@
# Инициатива по федерации через i2p-only (deprecated; недоделано)
```
---------------------------------------------------------------+
|
x000O. |
x0000000O. |
'000000000o |
':;O00000000' |
,oooood,cO0000d;0x +------------------
'cooooo, .:co;dxk'oKKKO I2P
.,,,,,' clooool. .:::. :oo; l0KK0.
',,,,,,,;'lo. .:::. .ool lKKKO. +------------------
,,,,,,,,,.:xxxo:. .:::. loo. cKKK0. |
',,,,,,,,.xkkkkkkkl,:::.oxxo;. .. ;KKKl'ddo, |
',,,,..:l. ,:::.dkkkkkkkkkxkkkkkko;,oOkkkOOOd |
,,,..::::. '::: ...;ldxkkkkx;kkOOOOOOkc |
.;;' .::::..::; :od; c;kkOOOOOOk, |
.;;, ;;;;.. 'ooc .cooooo,dOOOOOk. |
,;;. ;::;. .ooo'ooool. .odd, |
';;. ,:;.;:::. .l'coo,:. .loo, |
.;;, ;::, ;::;..ooooo:'ooc .ooo' |
;;;. ,::, .:cloool. .loo. .ooo' |
','.,;:' .llooooc.'c, coo' .ooo. |
.,,,,,;.;loooo; ,:::, 'ooc 'ooo. |
.''''''''':; ,:::;.olc;ooo. |
''''''''''.:;;;;'.. ,:.;lllll, |
.'''''''' ..,,,,,,,,,,,;;,.lllllllll |
.''. ..'',lllllllll. |
clllllll: |
:lll; |
---------------------------------------------------------------+
```
## Замер плюсов и минусов
Плюсы:
* полная анонимность федерации (без разницы где оно будет находится)
* не нужен https (шифрование на транспортном уровне уже есть)
* независимость от DNS (по возможности без красивых доменов, чтобы не наводить сложности server side, base32 домены)
* каждый сможет поднять инстанс даже на своей домашней машине не имея статического IP и домена в клирнете
* более гиковское сообщество без возможности резкого наплыва
* участие в сети I2P и соответственно её ускорение и повышение устойчивости со связностью
* пока Fediblock не существует в I2P глобально
Минусы:
* мало кто станет использовать хэндлы вида @user@aaaaaaaaaaaкакмногабукавбубубуlksamdlfmfkjiewjflksxmd.b32.i2p (может стать причиной спама длинными упоминаниями)
* федерироваться нужно только внутри i2p, чтобы не наводить сложности смешивая с клирнетом
* федерация не будет работать пока i2p-роутер не пробудет в сети достаточно долго, чтобы собрать рисунок сети больших масштабов
* Довольно большое потребление оперативной памяти (в будущем), что не подойдёт для хостинга на одноплатнике
* скорее всего это не будет работать с многим уже существующим ПО Федивёрса, могут вылезти странные баги
* большие медиа аттачи не рекомендуются (опционально, кто-то ведь даже видео гоняет по i2p)
* неизвестные последствия при росте такой федерации
* очень шумная и трафико-нагрузочная сеть, при отдаче полной скорости канала в i2p
* I2P сообщество уже и так общается через ирку например и форумы, вряд ли им понравится AP реализация over i2p добавляющая только головную боль. Чем проще - тем лучше
* богатые возможности для троллинга и спама - нет сдерживающих факторов как оформление домена, покупка сервера и прочие этапы добавляющие финансовые сложности
Минусов довольно много, скорее всего инициатива будет мало полезна. Не рекомендуется к применению, проще всего реализовать в рамках yggdrasil туннеля (практически как в обычном клирнете).
## Техническая составляющая (относительно простыми словами)
### base32 или ааааааааапростите_но_будут_такие_адреса_вместо_нормальных_доменовsaldm.b32.i2p или DNS как заноза в одном месте
Так как будем опираться на base32 (ну или если точнее хэши от них) домены, то наличие конкретного адреса в адресной книжке не обязательно, однако можно в принципе сделать какой-то "центр" регистрации доменов для Феди I2P по аналогии с reg.i2p и им подобным, но это уже выходит какой-то DNS. Это если ещё не учесть конфликты, если кто-то решит вести несколько таких "центров" выдачи, будем иметь разные книги на разных хостах - всё поломается скорее всего.
В base32 доменах есть преимущество, если сервер A реквестирует какой-то домен такого вида, то он будет его тут же запрашивать у i2pd роутера, а тот будет опрашивать других, так скажем естественный процесс без вмешательств обёрток красивых DNS и адресных книг (аналог hosts), представьте федерацию на уровне IP адресов, тут примерно так же, но здесь будут использоваться эти псевдо-домены. Да, конечно некрасиво и не удобно, иметь хэндлы с овер большим доменом, но зато меньше думать о проблеме вида "вот у меня этот домен резолвится и всё работает", а у другого "у меня ничего не работает, this address not found in address book".
У федеративных сетей и так есть проблемы и в обычном Интернете без оверлеев, что уж говорить, о попытке завернуть их в оверлей.
В прочем, с base32 доменами могут возникнуть проблемы, когда I2P-роутер только-только появился в сети, он ещё "не разжился" известными роутерами другими, а значит его нужно держать в онлайне какое-то время, чтобы успешно подключаться к другим инстансам. Ну, день например вы просто включаете его и бродите по разным сайтами (чтобы увеличить эффективность), ну и должен быть стабильный коннект, а со статическим IP без NAT (например на VPS) вы сможете расширить рисунок сети I2P-роутера буквально за часов 10 при скорости в 256 KBps с включенным транзитом. А потом можете уже поднимать инстанс. Как альтернативу ожиданию, можно ещё обмениваться папками NetDb друг с другом, но это не очень безопасно, лучше дать роутеру найти свежие самому.
### Привязки ключей от инстанса к псевдо-домену
Тут не должно возникнуть сложностей, по крайней мере, до тех пор, пока не потеряете ключ от туннеля, иначе вам придётся пересоздать и туннель и инстанс, начав с нового листа (аналогично ситуации с обычным Интернетом, когда нужно переехать с домена на домен)
### Совместимость ПО
При желании можно прокинуть любой федеративный движок в i2p, но как минимум движок не должен требовать https шифрования, а значит придётся менять код. Клиенты должны поддерживать http прокси, иначе - строить клиентские туннели до инстанса. В Pleroma есть поддержка I2P (не нативно, а через fedproxy) и даже есть инструкция по поднятию (не без нюансов конечно)
=> https://docs-develop.pleroma.social/backend/configuration/i2p/ I2P Federation and Accessability
=> ../misc/external_articles/pleroma_I2P_Federation_and_Accessability.gmi (gemini copy)
При необходимости, можно заставить парсить заголовок "X-I2P-DestB32", для корректного определения входящих запросов на федерацию
### Что сейчас есть
В I2P я ещё не встречал инстансы, которые именно работают по i2p, в большинстве случаев это просто прокси веб-интерфейса из клирнета в i2p, вот некоторые из них:
=> http://fedi.vern.i2p Mastodon Vern
=> http://mastodon.chudo.i2p/ Mastodon Chudo
=> http://bloat.clubcyberia.i2p Bloat-FE (не инстанс)
=> http://diasporg.i2p/ Diaspora* (федерируется только с собой)
Это неплохо, но годится разве что, для того чтобы обойти блокировки, ну или анонимно полистать ленту (хотя, я не уверен, что с включенным JS это хорошая идея, но API должно работать). Так же такой вариант не позволяет общаться с инстансами, которые расположены внутри i2p (если когда-нибудь вообще будут)
UPD: 21-04-2023 23:53 UTC+0

6
RU/articles/README.md Normal file
View file

@ -0,0 +1,6 @@
[Инициатива по федерации через i2p-only (deprecated; Недоделано)](2023-04-05_i2p_federation_initiative.gmi)
[Сравнение протоколов в виде таблицы (условное ИМО)](2023-04-03_proto_diff.gmi)
[tut vs bloat-fe](2023-03-18_tut_vs_bloatfe.gmi)
[(Не совсем статья) Сборник всяких-разных ссылок найденный на https://based.coom.tech/](2023-01-19_clearnet_url_pack_share.gmi)
[Замеры жизни под 64 kbit/s интернетом основанные на личном опыте](2023-01-14_64kbps.gmi)
[Форматы файлов и сжатие (пробная статья)](2022-03-08_data-files-formats.gmi)