Олег, 31 годик, решил почитать что такое федеративное государство в википедии, чтобы ликвидировать безграмотность и лучше сраться в дискуссиях о федиверсе.

Решительно не понимаю нихера. Если рассматривать федерацию (абстрактную) как добровольное объединение с взаимной выгодой - почему сецессия / федиблок (ну или что там есть ещё пожёсче чем забанить пачку инстансов, вроде ничего) / сепаратизм - это что-то немыслимо плохое. Ну типа пусть выходят, попробуют чо как там, захотят - вернутся, двери открыты.

Но раз это что-то немыслимо плохое и подлежит радикальному упреждению, это ж не федеративное, а унитарное объединение, выходит?

Или этот термин - попытка усидеть на двух стульях, типа мы тут все друзяшки, друзяшки сука, вякнешь мимо - введём войска/будем анонсить как токсичный инстанс и рекомендуемый к бану?

В очередной раз думаю о том, что fediverse должен иметь несколько уровней иерархии, в которые инстансы могли бы объединяться во что-то похожее на государство, со своей общей внутренней политикой, с возможными особенностями поверх неё (региональным законодательством) в пределах инстанса, которое уже само граничит с другими государствами и выстраивает "международную политику".

Ага, дочитал до конфедерации и всё мне ясно стало теперь. Чюваки, нам нужен #confediverse.

С точки зрения законодательства, конечно любопытная штука получается. Если законы субъекта федерации сильно переопределяют базовые - это ж каково по ним путешествовать/инстахоппить? Унификация прям просится хотя бы ради устранения бардака.

Во наверное весело было бы в игру https://lor.sh/@strizhechenko/110605745001609013 добавить DLC "управление федерацией так, чтобы все субъекты не перерезали друг друга".

Дочитал до конституционных/договорных/мягких федераций и фиксации принципа территориальной целостности и все мои вопросы отпали.

Решил прибраться в своём блоге. Нашёл бриллиант - идею игры про "политику компании".

Игроку предлагается сформулировать политику компании, которая будет использоваться при принятии решений. Каким должен быть интерфейс для этого? Ну, например вопросник из 10-100 вопросов. После формулировки политики компании не остаётся больше никакого интерактива - все решения принимаются автоматически на основе данной политики, а с компанией начинают происходить СОБЫТИЯ.

Хардмод - сформулировать политику в свободной форме, без списка вопросов, все неопределённые вопросы будут решаться случайным образом.

Альтернативные варианты с той же механикой: управление государством, эксперименты с законодательной властью.

Целевая аудитория - молодые айтишники, мечтающие “заменить этих эффективных менеджеров одним скриптом”.

Недавно, пока стригся, как-то разговор не клеился с парикмахером (и слава богу) и я провалился в ностальгию.

Вспоминал чудное время игры в #WoW (#WotLK) на пиратском сервере, тот азарт рейдов, ротациях, одевании твинков, чудесные схемы ролла, начисление очков, за которые можно было забирать шмотки в гильдии и т.д.

Вспомнил, почему я забросил все MMORPG - я не владею своим персонажем. То есть прикрывает оунер свой сервер и весь мой прогресс коту под хвост. Казалось бы проблема может решаться федеративной архитектурой и интерконнектом между серверами. Но так невозможно доверять прогрессу других игроков - накрутит себе кто-нибудь .additem'ов и .addskill'ов вообще от других классов (мне особенно нравился ДК с пассивками frost-мага, shadow-priest, destro-варлока, воина, энха и роги, благодаря которым все нагибались буквально одной левой (урон левой рукой был выше урона правой раза в два, благодаря стакающимся талантам).

И даже хз что с этим делать. Строить федерацию на доверии между администраторами, разве что, но как сделать миграцию между серверами, takeout данных - хз.

Вспомнил и прелестное читерство, которым я развлекался в обход античита. Заходим в игру в два окна с разных аккаунтов. Кидаем своему же персонажу приглашение в группу, создаём рейд, ставим сложность 25 героик. Заходим обоими в ЦЛК. Дальше сложная пляска с бубном. Была такая прога - XYZ, которая позволяла "летать". Но античит её палил. Но если по чуть-чуть - не палил. Собственно - написал программу на autoit, которая позволяла двигаться в нужном направлении маааааааленькими шажочками. И сервер этого не видел. И этого было достаточно для того, чтобы сквозь текстуры прямо от входа в цитадель подняться к Саурфангу Смертоносному. НПС стоял на месте, бой можно было запустить. Итак - оба персонажа на месте. Нужен был один танк, один РДД, хорошо умеющий восстанавливать ману и имеющий много доток, которые стабильно наносили бы урон где-то раз в секунду. Дальше происходило следующее - танк уводится в текстуры за Саурфангом. Где-то в середину шпиля. РДД возвышается в воздухе метрах в 10 над землёй так, чтобы Саурфанг не задевал. Во время боя нужно постоянно накидывать доты, т.к. спустя несколько секунд без урона Саурфанг понимал бы, что боя-то нет и вышел бы из него, восстановив здоровье. А танк нужен, чтобы в короткие секунды между уроном Саурфанг на него агрился. Но при получении урона разворачивался и снова шёл к РДД. Варлоком фармить его было просто идеально - простая ротация, проклятия, порча, поджигание, манатап и высасывание жизни не давали Саурфангу отдохнуть. Таким образом он убивался в соло. С хорошей долей вероятности с него падала Воля Смертоносного - одна из лучших серёжек для МДД, за которую вечно были срачи. И с 100% долей вероятности с него падали "печеньки", которые можно было обменивать на сетовые шмотки, что тоже топчик.

В итоге твинка можно было одеть так, что его брали бы в рейды буквально за 2 недели. А помимо ЦЛК 25 гер ещё были 10 об, 10 гер, 25 об. В общем, прибарахлиться удавалось неплохо. А вот Халиона (да боже мой, вообще больше никого) таким образом завалить не удалось.

А сейчас... что сейчас, фармлю голду на показе баннеров в банке и прожимаю квест с ремонтом трёшки. Скучно-с.

#федичитальня #PostgreSQL #PostgreSQL15 #контрольные_точки #фоновая_запись

За полгода я прочитал треть книжки. За выходные на природе прочитал 30 страниц. Медленно.

Контрольная точка - это две метки в #wal с началом и концом. В начале фиксируется список грязных буферов, в конце - все зафиксированные на момент начала грязные буферы сдамплены на диск. По контрольной точке восстановливается согласованное состояние на момент её начала при восстановлении из резервных копий. Файлы wal, кроме предыдущей завершённой и текущей контрольной точки бесполезны. При достижении `max_wal_size` форсируется _внеплановая_ контрольная точка. Много внеплановых контрольных точек – плохо. С ними вообще любопытно: делаешь часто - лишние накладные расходы, плохо, делаешь редко – плохо, возрастает время восстановления, растёт объём хранимых wal-файлов. Это как менеджер, спрашивающий как дела по задаче. Подстраивать интервалы для checkpointer'а нужно по обратной связи из мониторинга, учитывая профиль нагрузки на систему. Такое себе, я ожидал больше динамики и автоматизации.

Мне понравился подход в сбросе грязных буферов на диск - трэкать скользящим окном время и объём IO на обработку предыдущих контрольных точек, если успеваем, то _замедляемся_, чтобы не создавать пиковую нагрузку в бутылочном горлышке системы (дисковой записи) на ровном месте. Это резервирует дополнительные ресурсы для штатного функционирования системы, которые могут _внезапно_ понадобиться.

#Журнал можно записывать синхронно и асинхронно.

Синхронный режим это медленная жопа, а много OLTP транзакций её насилуют. Поэтому для синхронного режима придумали батчинг записи коммитов в журнал, по дефолту он выключен, регулируется опцией commit_delay. Нравится метафора из книги с удерживаемой кнопкой дверью лифта, когда первая транзакция, которая готова закоммититься, ждёт немного, вдруг с ней за компанию ещё одна транзакция влетит записываться на диск.

Асинхронный режим допустим, если вы готовы потерять пару сотен последних транзакций, даже если нужно будет повторить их в ручном режиме или компенсировать убытки из своего кармана. Исправный ИБП, сигнал о потере питания от которого вызывает штатное завершение работы системы, снижает вероятность такой ситуации раз в десять.

У журнала несколько уровней записи - minimal, replica, logical. Как я понял, logical это для master, replica это для slave, minimal это для fucking slaves. Про logical надо бы подробнее почитать, в книжке он мимоходом упоминается. Синхронная репликация журнала, когда коммит записи на мастере означает гарантию чтения этой записи на реплике, звучит как головная боль для администратора БД и тормоза. Мастер-мастер репликация звучит ещё более сложной. Асинхронная репликация журнала _без_ гарантии чтения с реплики выглядит гораздо проще, кажется большинству систем этого за глаза хватать должно.

Видел в https://highload.guide милую схемку с:

- 1 master,
- 1-2 slaves, выделенных для снятия резервных копий,
- N-slaves для readonly OLAP-нагрузки.

Интересно, кстати, как с использованием этого у #mastodon обстоят дела, уж чего-чего, а readonly нагрузки тут достаточно.

Возникшие вопросы, которые пока остаются без ответа

- Как в PostgreSQL выглядит инициализация дополнительной реплики и какую нагрузку это создаёт на master?
- Возможна ли иерархическая репликация для распределения сетевой нагрузки на Master?
- Как себя в таком случае чувствуют промежуточные полумастер-реплики?

Нашёл я тут значит свои наработки 8-летней давности на #bash и немножко причесал.

Короче - схема резервного копирования с чем-то типа кольцевого буфера в файловой системе, сделанная поверх хардлинков.

Заточена под то, чтобы хранилось не больше 42 + лет эксплуатации резервных копий при ежедневном копировании и не больше 66 + лет эксплуатации - при ежечасном.

Найти #бэкап легко. Один и тот же бэкап может одновременно лежать в ежегодных, ежемесячных, ежедневных и ежечасных копиях, но, благодаря хардлинкам, это будет один файл. И создаваться он будет всего один раз. В итоге экономится дисковое I/O.

А самая прелесть - офигенно простая очистка лишнего. Просто ищем файлы с одной единственной ссылкой.

#бэкапы

https://github.com/strizhechenko/backup_scheme/tree/master

#ФедиЧитальня #PostgreSQL15 не совсем из книги, но по той же теме.

Глянул кусочек highload.guide, выцепил хорошую выжимку про классификацию репликаций:

- логическая - работает с кортежами; пример - row based binary log в MySQL; бутылочное горлышко - процессор slave.
- физическая - работает со страницами; примеры - pg_wal, innodb undo-redo; бутылочное горлышко - диск (не совсем понял master'а или slave'а, не совсем понял, а как же буферы; возможно дело в большей степени касается MySQL с несколькими журналами одновременно)
- statement based - сплошная боль, есть места где можно получить неконсистентные данные между master и slave, но в случае условной бигдаты - очень низкие накладные расходы на передачу данных по сети, большой update на всю таблицу прилетит практически одним запросом; разве что выполнять его придётся заново на slave, из-за этого может быть длинный лаг репликации.

Если slave может блокировать удаление журнала master'ом, чтобы догнаться в случае ребута, чем больше отставание, тем больше размер журнала. Если slave вообще не догоняет master в принципе и отставание только нарастает - со временем это закончится забитым дисковым хранилищем.

В PostgreSQL есть Logical Log Streaming Replication, который позволяет не миррорить часть таблиц на slave. Как это применять - я не придумал. В теории можно не хранить на слейвах для актуальных данных архивные данные, что позволит немного сэкономить на дисковом пространстве, особенно если slave'ов много.

P.S:
- Раньше жил в прекрасном мире, где БД находится на том же сервере, где и приложение, ни о какой репликации и не думал.
- Сейчас живу в прекрасном мире, где БД поддерживает отдельная команда, репликация уже готова, хоть и без гарантии синхронных записи на мастер и чтения со слэйва (а я и не против), бери да пользуйся.

У меня есть три "потерянные" вещи, которые я долго откладываю восстановить и отсутствие которых очень больно бьёт по качеству жизни.

1. Личный пользовательский десктопный компьютер, на который легко переключаться с рабочего ноутбука, которые находятся на одном и том же рабочем столе. Из-за этого часть личных дел "протекла" на рабочий ноутбук. Вряд ли на нём есть много чего для слежки за сотрудниками, тут базовые рабочие процессы-то на линуксах не особо поддерживают, на входе я пару часов ёбся с интранет SSL-сертификатами и сменой пароля к SSL-сертификату для VPN (в итоге сделал это внутри контейнера с предыдущей Ubuntu LTS). У всех маки. Возможно переключаться будет впадлу и здесь меня может спасти nextcloud. А может и не спасти.

Вообще переключение у меня устроено так - есть usb-свитч, есть два HDMI-провода, воткнутые в большой монитор. Для переключения надо нажать кнопочку на USB-свитче, а потом кнопочку на мониторе для переключения источника. Такое себе удобства. Так-то второй монитор есть, но я его чот не использую, хотя казалось бы - разберись уже с usb type-c -> displayport и будет тебе счастье. Глядишь, ещё и заряжаться от монитора можно будет. Или монитор питать. Но эт не точно. А пока блок питания ноута (гигантский, сука, весит больше чем макбук про 15' наверное) прикрутил стяжками к столу и мне норм.

2. Планировщик для того чтобы внятно и раздельно планировать краткосрочную рутину, среднесрочные дела и встречи и долгосрочные проекты. Постоянно всё проёбываю, календарь игнорирую по той причине что он гвоздями прибит к _датам_ вместо _последовательностей_.

У меня в целом есть где-то на 60% дописанный планировщик поддерживающий нужный мне подход, я бы кое-где поэкспериментировал ещё с подходом, но чтобы двигаться нормально нужно менять архитектуру, очень многое зависит от удобства интерфейса, а на формах, которые рендерятся на бэкенде далеко не уедешь. Наверное за день реально распилить проект на бэк, состоящий из API и фронт на реакте (заодно, глядишь, на работе смогу фронтам ТЗ мерж-реквестами ставить, пока я в режиме read-only там, потому что даже не ебу как это всё протестировать).

3. Дневник, чтобы спускать пар, поэтому у меня стала всё чаще взрываться жопа. Куда-то просрал свой контейнер с мастодоном, надо ещё раз порыться по /var/lib/lxc на трёх железках.

Попробую за майские праздники восстановиться, сегодняшний день я посвящаю комплютору.

Сходил вчера к нутрициологу. Теперь у меня в жизни появилась женщина, которая спрашивает как я покушал и как я покакал. Аж на слезу пробило, лол.

По её словам, в принципе если процентов на 5 скорректировать мои пищевые привычки и чуток дожать дисциплину, усвоение пищи и витаминов подрастут процентов на 15, можно будет меньше хавать, а я слегка схудну и её приёмы отобьются по баблу за счёт экономии на продуктах за 2-3 месяца :D

Самое сложное это, конечно, правильно жрать колёса. Те, которые я ем за полчаса до еды ещё ладно. Но тут она чот парочку ещё накинула, хотя у меня свои уже в таблетницу не влезают. Сейчас я иногда такой "бляяя колёса" и просто закидываю всю дневную пачку в себя. Плохо, но всяко лучше, чем не закинуть. А тут "это за полчаса до еды утром, после нельзя; это между приёмами пищи, но перекусы можно игнорировать, это через полчаса после еды, а это прямо с едой, но только если она достаточно жирная".

Ещё сейчас смотрю на результаты анализов и прям вижу, как дисциплина, в теории, позволяет сократить дозировку колёс. И это тоже, сука, экономит бабки! Вот думаю, стоит ли с этой идеей к эндокринологу идти (по ДМС, конечно, а то его приём 2к стоит почти уже, без ДМС я бы даже не сомневался) или развлекаться самолечением.

Смущает то, что мы проворачиваем три эксперимента одновременно - снижаем кислотность желудка, докидываем лёгкое желчегонное и меняем 10% сливки в кофе на 3.2% молоко. Из-за этого не можем точно определить, что было эффективно, а что нет.

#дед #кряхтит на #ЗОЖ

Подумал тут, а ведь корелляции в трафике можно выявлять через эдакое подобие производных функций, не держа вообще всё в памяти. Берём 1000 пакетов. Накладываем 128 байт payload ethernet фрейма первого пакета на 128 таких же байт второго, совпадающая битмаска будет хэш-ключиком счётчика. Читаем третий, забываем первый, сравниваем со вторым. Повторяем. Берём топ счётчика и если он больше 50% то что-то тут не так. Так #ддосы можно в 99% случаев вообще вслепую выявлять, вообще не парся пакеты.

При хайлоадах можно просто 5-10-50-500 пакетов/сек хватать и как-нибудь скользящее окно замутить, чтобы всегда актуальная инфа была. Или 2 счётчика иметь, заполнять сперва один, потом второй, сравнивать между собой, потом первый занулять, заполнять заново. Ух бля, статистикал лёрнинг, нахуй.

Записался на сдачу грейдов, но ощущаю это гиблым делом.

Вообще концепция довольно упоротая, поскольку текущая схема подразумевает взращивание эдакого универсального солдата, в то время как команда и проекты нуждаются в компетнциях дай боже процентам по 25, но, пожалуй, бутылочное горлышко - даже не идеи что сделать, чтобы стало хорошо, а банально время на то чтобы это сделать. И возникает конфликт - ради карьерного роста нужно задрачивать неважное в текущей практике, а это... внимание, энергия и время, которые мог бы потратить на развитие проекта.

Вот раньше просто было - вот тебе проект, вот тебе процент с ежемесячной подписки по хитрожопой функции, предполагающей рост проекта, ебашьте, сеньор джун. И сразу всё становится проще с приоретизацией, не ебёшь мозги себе вообще решительно ничем кроме максимизации прибыли и минимизации затрат.

Тут заметил упоминание ЧПУ.

Вспомнил, как я в 2012 мастерил "убийцу микротика" для провайдеров - дистрибутив Linux для небольших провайдеров, заточенный под работу 10гбит/сек, назвали его XGE, типа X Gigabit Ethernet. В неправильной раскладке получалось ЧПУ, за что меня коллеги прозвали оператором ЧПУ.

В целом колхоз-колхозом, но опыт интересный. Много ядерного программирования, не только ОБЫЧНЫЙ ЛИНУКС ВЗЯЛ И НАСТРОИЛ И ДЕНЕГ ХОЧЕТ, а прям побитый продакшном проект, вот прям из коробки хоба и взлетает многое. Единый конфиг опять же, копию развернуть - буквально _один_ файл скинуть на новую установку, IP-адреса поменять и погнали. Да и в целом после предыдущей версии нашего роутера без ipset - это был глоток свежего воздуха в вопросе масштабирования, раньше на дереве цепочек iptables что acl, что NAT, что шейперы работали и это была жопа где-то после 2000 абонентов.

Увы, проект не взлетел, потому что небольшие провайдеры зажимают любую копеечку, а большие хотят большой американский вендор аппаратного решения. В целом, если бы в проект вложили где-то в 6-7 раз больше денег (и наняли в 3-4 раза больше людей, а не одного человека на полставки, потому что появился ещё один более выгодный проект), может быть что-то из этого и получилось. Но вышло немного иначе.

Решение о том, чтобы его похоронить принимали слишком долго и откладывали на потом. Даже на то, чтобы внятно опубликовать наработки ресурсов не нашлось, это ж время, и по истории коммитов пробежаться, понять в каком виде вообще выкладывать - в виде отдельных патчей или целиком всё дерево ядра, брендинг опять же пришлось бы делать, да и просто публикации мало, надо было бы людям которые зачем-то в issues пришли отвечать, ну и статейки на хабр, опеннет и ЛОР прости-господи клепать. В итоге так и забили болт.

Такая вот грустная история импортозамещения.

#ФедиЧитальня
Предлагаю кому-нибудь присоединиться ко мне в чтении либо про кишочки постгреса (в открытом доступе легально): https://postgrespro.ru/education/books/internals
либо про высоконагруженные приложения, но мутите её где-нибудь сами (дорогобогато).
Я читаю такие вещи медленно и редко, поэтому предлагаю ритм для синхронизации – главу или 10-15 страниц в неделю (что меньше), но компания для чтения звучит как неплохой мотиватор не забить и дожать и мб в процессе ускориться.
О процессе: предлагаю просто раз в неделю под этим постом делать ветку дерева посвящённую прочитанной главе. Мне будет приятно послушать и поделиться мыслями как бы прочитанное применить в рабочем или пет-проекте.