Технологический Болт Генона
8.16K subscribers
3K photos
363 videos
214 files
3.87K links
До Декарта никогда не существовало рационализма.

Музыкальный Болт Генона: @mus_b0lt_Genona
Мемный Болт Генона: @mem_b0lt_Genona
Кадровый Болт Генона @kadr_b0lt_Genona

Обратная связь: @rusdacent
Download Telegram
Media is too big
VIEW IN TELEGRAM
ЛУЧШИЙ САВЕТ УСЕМ МАЛАДЫМ ОТРЫВВВЙОРСИРАМ КОТОРЫЙ МЫ ВИДЕЛИ.
РЫКОМЕНДУИТСО. (не думойти, проста бейте по ведру в исступлении, рана или поздна вы што-то откопайети)

у каждого человека есть как минимум один нолик. ВсТрОеНнЫй. думайте.
в целом, когда нас, аки умудрённых жопытом (ньед) спрашивают А КАК РЫВВВЙОРСЕТЬ - вот так. не сдавайтесь =)

//для самых маленьких мы крайне лениво перевели. не проклинайте благодарите


[Upd: по просьбам трудящихся текстовый разбор, исходники раз, два, видео доклада ]
💊33👍3🤡31
Тут Флант Prometheus форкнули переписали с кучей оптимизаций. Пост на Хабре большой с кучей подробностей + провели сравнение с VictoriaMetrics. Сам я ещё, естественно, не успел попробовать, но выглядит многообещающе

Если подобным образом проанализировать все лейблы на реальных данных, получится, что:

- 32,7 % из них имеют всего одно возможное значение, например true или 0;
- 60 % — от 2 до 255 значений, то есть укладываются в 1 байт;
- 7,3 % — от 256 до 5275 значений;
- 0 % — больше 65 535 значений.

Это значит, что все возможные значения укладываются в два байта.

Мы решили хранить все ID (#0, #1, #2 и т. д.) не в четырёхбайтных значениях, а как два бита, указывающие количество байт, в которые укладывается число, плюс значение.

Это дало нам очередной выигрыш по памяти — теперь весь labelset для 1 миллиона метрик стал занимать 30 МБ. Это в 30 раз лучше стартовых 762 МБ.
. . .
Оптимальное хранение строк дало приличный выигрыш и в индексе. Если раньше в нём были строки и хэш-таблицы, которые не особенно оптимально хранятся в памяти, то в нашей реализации есть ID, которые выдаются по порядку. Это позволяет хранить в кэше четырехбайтные числа uint32 и заменить хэш-таблицы на sparse-векторы и Bitset.

В итоге основным потребителем памяти у нас стали точки. Prometheus хранит их достаточно компактно: он использует Gorilla Encoding и битовые операции. Это не значит, что оптимизировать нечего, но для этого надо внимательно посмотреть на данные.
. . .
Оказалось, что уникальных последовательностей временных меток всего 10 % от миллиона. Эта оптимизация позволила выиграть 55,5 % по памяти просто за счёт дедупликации.
. . .
После всех преобразований мы получили выигрыш по хранению точек почти в три раза: изначальные 787,72 МБ превратились в 283,9 МБ. При этом чем больше данных и серий, тем лучше срабатывает наша оптимизация. Если на одном миллионе метрик мы выиграли по хранению точек в 2,7 раза, то на трёх миллионах это будет уже три с небольшим раза.
. . .
В процессе работы Prometheus пишет WAL. Мы оптимизировали журнал предзаписи примерно в 19 раз. Изначальные 6,2 ГБ без сжатия в Prometheus v2 для 1 миллиона метрик превратились в 153 МБ в Deckhouse Prom++.

Deckhouse Prom++: мы добавили плюсы к Prometheus и сократили потребление памяти в 7,8 раза
https://habr.com/ru/companies/flant/articles/878282/
+
Deckhouse Prom++
https://github.com/deckhouse/prompp/

Чат: @prom_plus_plus
🔥54👍19🤡4🥱2
Олимпиадники не перестают удивлять

Иконку сделали вместо круглой квадратную (охуенно, спасибо, как раз не хватало этого), при этом при попытке открыть чью-то "сторис" стала падать сама Телега в 100% случаев

QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter
qt.gui.imageio.jpeg: ./lib/jpegli/decode_scan.cc:535: Incomplete scan detected.
qt.gui.imageio.jpeg: ./lib/jpegli/decode_scan.cc:535: Incomplete scan detected.
Ошибка сегментирования (стек памяти сброшен на диск)


Обновление на 12 из 10

UPD: Фиксанули в 5.13.1
😁71🌭10💯61🤡1
Не перевелись импортозаместители!

Если что, то никакие власти там ничего не прорабатывают, как написано в заголовке на Хабре, это частная инициатива.

EU OS — это Proof‑of‑Concept для развёртывания операционной системы Linux на основе Fedora с рабочей средой KDE Plasma в типичной организации государственного сектора. Другие организации с похожими или менее строгими требованиями также могут извлечь пользу из этого Proof‑of‑Concept. Несмотря на название, EU OS технически не является новой операционной системой», — уточнено на сайте проекта

Власти Евросоюза прорабатывают концепцию отказа от ОС Windows с переходом на EU OS на базе Linux (Fedora KDE Plasma)
https://habr.com/ru/news/894820/

Оригинал новости
EU OS drafts a locked-down Linux blueprint for Eurocrats
https://www.theregister.com/2025/03/25/eu_os_free_govt_desktop/

Я сразу задумался, почему не OpenSUSE, но оказалась, что она недостаточно зрелая для автора

> The proposed base OS – Fedora – is what gave us pause, though. In these times of heightened tensions between the US and – well, frankly, everyone, including large parts of the US itself – why pick the Red Hat-backed Fedora, an American distro, rather than one of European origin such as openSUSE? To be fair, the immutable Fedora KDE version, Kinoite, is among the most mature immutable distros out there.

Цели проекта
https://eu-os.gitlab.io/goals
+
Борда
https://gitlab.com/eu-os/eu-os.gitlab.io/-/boards/9013559

ЗЫ А это мог быть ваш четверговый проект, но в этот четверг никто не пришёл 🌝
https://xn--r1a.website/tech_b0lt_Genona/4983
😁15🤡9
Forwarded from RutheniumOS
Google прикрывает лавочку AOSP?

Поступок Google в марте 2025-го шокировал: вся разработка Android уходит за закрытые двери. Больше никаких открытых коммитов в AOSP (Android Open Source Project) в реальном времени — теперь только готовый код после релиза. Зачем это Гуглу, что это значит для нас и как теперь жить?

AOSP: Открытость на паузе

AOSP — это сердце Android, открытый код, который любой может взять и крутить. Samsung делает One UI, Xiaomi — MIUI, а гики пилят LineageOS. Google рулит проектом, но раньше часть работы велась публично через AOSP Gerrit — там можно было подсмотреть, что готовится в новой версии. Теперь — всё. С 31 марта 2025-го разработка уходит в секретные внутренние ветки, доступные только партнёрам с лицензией GMS (Google Mobile Services). Код в AOSP выложат только после финального релиза — типа Android 16 или патчей.

Зачем?

Google говорит: так проще. Публичная ветка отставала от внутренней — сравни AOSP и бету Android 16: функции и API вечно запаздывали. Синхронизация веток ханимала время, патчи конфликтовали (вспомни настройку экранной лупы — гемор ещё тот). Теперь всё в одном месте, без лишней возни. Но есть нюанс: открытость AOSP была фишкой Android 16+ лет. Это шаг назад?

Как это работает

Google всегда держал две ветки: публичную AOSP и внутреннюю для своих и OEM’ов (Samsung, Qualcomm и ко). Код всё ещё выложат под Apache 2.0, но не в процессе, а постфактум. Для юзеров и девелоперов — ноль изменений. Pixel’ы и Galaxy обновятся как обычно, Play Store не тронут. Но для следящих за коммитами в поисаках интересного (типа упоминания Pixel 10), и контрибьюторов — ад. Отслеживать прогресс разработки станет сложнее.

Плюсы и минусы

Google обещает ускорение разработки — меньше багов, быстрее релизы. OEM’ы с GMS-доступом тоже в шоколаде: они и так видят черновики. Но кастомщики вроде LineageOS или GrapheneOS в пролёте — им ждать финального кода, а не смотреть исходники. Меньше спойлеров о новых фишках (прощай, ранний слив через Gerrit). И главное: внешние патчи в AOSP могут устареть, пока Google пилит своё втихую.

Что дальше?

Android не становится закрытым — код всё ещё открыт после релиза. Но процесс теперь больше похож на iOS: разработка в бункере, а не на виду. Для бизнеса и юзеров — пофиг, для энтузиастов — удар. Google хочет упростить себе жизнь, но теряет дух открытости, который тянул Android вверх. В 2025-м это уже не "Linux для телефонов", а продукт под замком.
Делаем ставки, что будет дальше и ждем реакции разработчиков отечественных форков AOSP

Источник
🫡22😭7🤡2👍1🔥1🎉1🍾1💋1
#kubernetes #azure #troubleshooting
Материал уровень крепкий джун(на который я тут не потянул, лол, самоуверенное овно)

Никого не трогаю, прилетает алёрт.
"Лаг между репликами на Patroni кластере в кубере".
А я дежурный, блин. Ладно.

Сам алёрт вида
- alert: PostgreSQLlaggingbehind
expr: pg_replication_lag_seconds{} > 7200
for: 5m
labels:
severity: warning
annotations:
summary: "PSQLDB `{{ $labels.pod }}`/`{{ $labels.cluster }}`/`{{ $labels.namespace }}` has lag of `{{ $value }}`"

Делаю свич на кластер кубера, NS, вижу поды.
Никаких рестартов, никаких ООМираний.
Лезу внутрь пода, смотрю
patronictl list

0 - мастер, 1 и 2 - реплики. Лаг в 900 мегабайт на каждой реплике.
Пытаюсь сделать реинит для 1 реплики.
patronictl reinit clustername instancename

Впервые в жизни вижу ошибку - нет соединения, спустя минут 15 ретраев всё отваливается питоновскими ошибками.
Ок, пытаюсь повторить со второй репликой, через 15 минут тот же ответ.
Ладно, семь бед - один ресет.
Мастер трогать нельзя, ребутаю POD-ы c репликами.
После рестарта снова попытка реинициализации - таймаут.

Хм. Просто так делать failover с 0 инстанса на 1 или 2 нельзя в данном случае - у нас везде лаг и мы может грохнуть то, что не надо.
Мастер так же не хочется рестартовать, я уже с этой ложки ел.
Окунаемся в логи: да, прям внутри каждого пода смотрю журналы, ошибки, файлики.
Нет ничего. Таймаут. Да как так-то.
Ныряю выше, на уровень кластера: ивенты кубера, состояние нод, на каких нодах данные поды запустились.
Смотрим нетворк полиси и прочие типичные радости кубера. Нет ничего, что мешало бы.
Да все ок, ивенты пустые, все поды патрони кластера с БД на одной нод группе.
Проверял даже наличие свободных IP адресов в кластере AKS. Всё есть.
Посидел ещё минут 20 с логами и пошёл писать в общий чат "спасити памагити".

Спустя время коллега пишет "сорри аймсорри, это я".

Оказалось вот что у нас было разделение на нод группы. Часть прожорливого перенесли на отдельные нод группы (Trino, AirFlow etc).
По стечению обстоятельств туда, на эту "edge" нод группу, по аффинити прилетел тот кластер Patroni.

Делаем быстро исправление типа такого(это внутренний модуль террагранта)
# Allow Security rule in NSG (allows communication between pods on edge node pool)
resource "azurerm_network_security_rule" "edge_asg_allow_pod_to_pod_rule" {
count = local.edge_node_pool_exists ? 1 : 0
name = "allow-pod-to-pod-edge-asg"
priority = 960
direction = "Outbound"
access = "Allow"
protocol = "*"
source_address_prefixes = azurerm_subnet.edge.address_prefixes
source_port_range = "*"
destination_address_prefixes = azurerm_subnet.edge.address_prefixes
destination_port_range = "*"
resource_group_name = "${var.kubernetes_cluster.name}-nrg"
network_security_group_name = data.azurerm_resources.nsg[0].resources.0.name
}

План, апплай(а что вы мне сделаете?), МР, аппрув, мерж.

Трафик начал ходить между подами внутри нод группы, лаг мгновенно пропадает, проверяем через
patronictl list

Алёрт через минуту окрашивается зеленым resolved.

Итог:
- не стоит быть самоуверенным "синёром", если мне белым по чёрному пишут, что нет сетевой связности между подами - ну проверь, блин, дебаг контейнер кто-то отменял? Ну кто виноват, что я селюк и не знал про существование asg rules между подами в одной нод группе AKS, только я сам и виноват.
- девопс это не всегда про пайплайны, иногда это про общение. Надо общаться с коллегами и знать про подобные изменения.


* Да, у нас 99% баз данных в кубере и мы с этим живём хорошо.
👍15🤡73🥱32
🧠 Как 3 вечера анализа и оптимизаций дали минус 1 CPU и +40% к скорости ответов API

👀 Всё началось с того, что я случайно (ну как случайно, проблема была всегда, просто я первый задался вопросом - "почему?") заметил, что один Python-сервис на staging потребляет до 2.5 CPU.
Для сравнения — весь namespace потребляет около 6 CPU. То есть один сервис ест почти половину ресурсов. И это при том, что это не какой-то нагруженные сервис, это синхронный API-сервис, да еще и без нагрузки, это же staging.

Стало интересно — а что там внутри вообще так жрёт?

📦 Запустил профайлинг CPU через Pyroscope и… понеслось.

UI у Pyroscope меня не устроил — флеймграфы красивые, но неудобные для глубокого анализа.
📥 Поэтому я выгрузил дамп как pprof файл и открыл его через go tool pprof.
Так мне удобнее, быстрее и информативнее.

📊 Профилирование показало несколько важных узких мест:

🧱 Проблема №1: конвертация данных из MySQL

Самое "жирное" место — conversion.pyMySQLConverter.row_to_python.
Это код, который конвертирует строки из БД в Python-объекты на каждый запрос.

Наиболее затратные конвертации:
- _DECIMAL_to_python
- _INT_to_python
- _JSON_to_python
- _DATETIME_to_python
- _STRING_to_python

Решение:

📌 Использовал C extension у mysql-connector-python
Официальная документация: https://dev.mysql.com/doc/connector-python/en/connector-python-cext.html

📉 Результат:
- Минус 1 CPU
- До +40% ускорение некоторых endpoint’ов

🧠 Проблема №2: неэффективный Python-код

Пример: функция change_type, которая:
- делает кучу проверок в логике
- использует неэффективные структуры данных, например, list для поиска вместо set / dict
- обрабатывает сразу множество возможных вариантов логики, в зависимости от входных данных

Решение:

📌 Переписал участок без изменения бизнес-логики:
- заменил структуры данных
- добавил ранние выходы
- убрал дублирующиеся проверки

📌 Cognitive complexity снизилась, временная сложность — тоже. Производительность выросла.

⚠️ Проблема №3: код, который не нужен, но работает

Профайлинг показал, что куча ресурсов уходит на код, который вообще не должен уже как год использоваться. Но код активно выполняется. WTF!?

🤷‍♂️ Функции вызываются, результат — пустой, но код исполняется. Причём часто и тяжело.

Решение:

📌 Удалил мёртвый код, обновил импорты, подчистил зависимости.
📌 Поднял вопрос о полной деактивации этого кода и мы таки это сделали — ресурсы можно использовать лучше.

🐘 Проблема №4: Импорты. Много. Дорого.

Во время анализа я наткнулся на ещё одну тихую, но дорогую проблему — огромные ресурсы уходят на фазу импорта модулей в Python.

Конкретно — на _find_and_load, часть механизма импорта, который занимается поиском, загрузкой и инициализацией модулей.

📌 Почему это важно?
- Импорты выполняются на каждый старт сервиса.
- Чем жирнее и зависимее ваши модули, тем дольше и тяжелее проходит импорт.
- Это не всегда очевидно, но можно видеть в профайлинге: _find_and_load, _find_and_load_unlocked, _load_unlocked – вот это всё.

📊 У нас в сервисе модулей реально много.
Многое из них – просто "свалены в кучу", где-то грузятся тяжёлые зависимости. Да и сложная структура проекта вынуждает иметь большое количество импортов.
И, как итог, CPU тратится на то, что можно было бы стремиться избежать.

Что с этим делать:
- Разделять модули по функциональности.
- Отложенные импорты (lazy import) – практика может применяться (но есть нюансы), если модуль нужен только в конкретной функции.
- Минимизировать зависимости и импорт только того, что действительно нужно.
- Следить за импортами в __init__.py — именно они могут тянуть за собой пол кодовой базы.

Следующий шаг: memory профайлинг. Pyroscope в нашей инфрастуктуре такое не умеет и нужно приседать, но надеюсь дойдут руки и до RAM.
👍36🤡71👎1
Forwarded from Об ЭП и УЦ
Уязвимость Яндекс Браузера

25 марта 2025 года Google выпустила обновление, исправляющее уязвимость нулевого дня в браузере Google Chrome. Эксплойт, кстати, был обнаружен Лабораторией Касперского.

Спустя всего 2 дня выходит обновление Chromium ГОСТ👍.
А как там самый популярный браузер из реестра отечественного ПО? А там всё печально. Для актуальной версии Яндекс Браузера соответствует двухмесячная версия Chromium 132.0.6834.955.

Не тот браузер добавили в реестр отечественного ПО.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁41👍6🤡6🤷‍♂1🫡1
Forwarded from I’m CTO, bitch
Помните, в прошлом году делали софт для умного дома Дилдок.Лайф. Там у них мега-навороченные умные унитазы с голосовым ассистентом. Мы их предупреждали, что такое случится, но они не слушали и требовали делать всё по их ТЗ.

И вот итог:
1. Дата-центр лежит уже 3 часа.
2. Их умные унитазы из-за отсутствия соединения отказываются смывать. Ручной кнопки смыва в них не предусмотрено, всё только через голосового помощника или с телефона управляется.
3. Вся их умная бытовая техника тоже не работает или заглючила. Даже чайники не работают. А роботы-пылесосы активировали режим «skynet».
4. Техдир из Лайфа просит нас срочно что-то сделать, любые деньги предлагает.

Я ему посоветовал смывать в унитазе пока из ведра. Но у него дома умные краны, и они тоже не работают.

#стояделали
🤣708🔥5🤡4👍2🥱1
I’m CTO, bitch
Помните, в прошлом году делали софт для умного дома Дилдок.Лайф. Там у них мега-навороченные умные унитазы с голосовым ассистентом. Мы их предупреждали, что такое случится, но они не слушали и требовали делать всё по их ТЗ. И вот итог: 1. Дата-центр лежит…
И этот пост понятно к чему. Сегодня 12 часов валялась обоссавшись и обосравшись зона ru-central1-b в Яндекс.Облаке и вроде как сейчас приходит в более или менее живое состояние. Всем кто в ночи будет чинить свои сервисы мои соболезнования и лучи поддержки.

Но проблема в том, что современные "хипсторы" решили почему-то что облака (не только AWS, GCP и т.д., а в более широком смысле) круто и надёжно, поэтому всё теперь привязывается и создаётся в них. Всё конечно же ради вашего удобства (нет)

И если пост выше это типа юмор (тоже нет), то вот почитайте реальную историю о том как человек не может воспользоваться нормально посудомоечной машиной, потому что ей нужен WiFi и приложение

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

Более того, для использования приложения нужно привязать посудомойку к Wi-Fi, настроить облачный аккаунт для какой-то системы под названием Home Connect, и только тогда вы сможете пользоваться всеми функциями машины.
. . .
Приложение? Я бы мог понять наличие удобных функций для тех, кому они нужны. Как в моём новом холодильнике (который я решил не подключать к WiFI): у него есть приложение, позволяющее мониторить температуру внутри или проще искать коды ошибок. Если бы мне нужны были эти дополнительные возможности, которых не было в моём старом холодильнике, то их можно было бы получить.

Но обязательное требование приложения для доступа к функциям, которыми раньше можно было управлять кнопками на самой посудомойке, или по-прежнему можно, если заплатить на 400 долларов больше за «крутую» модель 800? Это печально.
. . .
Что можем сделать мы?

Не думаю, что мы должны прощать подобное производителям.

Во-первых, это позволяет дизайнерам устройств лениться.

Во-вторых, с моей стороны это может показаться какой-то теорией заговора, но мне кажется, это часть запланированного устаревания. Как и в случае с машиной GE, в которой многие детали спроектированы так, чтобы заржаветь спустя пять или десять лет.

Если у вас есть облачное приложение, то для него должен работать облачный сервис. А его поддержка стоит денег.

Абонентской платы пока нет, что означает один из двух вариантов:

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

В-третьих, это дыра в безопасности вашей локальной сети.

Не буду я подключать посудомойку к вашему дурацкому облаку
https://habr.com/ru/companies/ruvds/articles/894602/

Оригинал
I won't connect my dishwasher to your stupid cloud
https://www.jeffgeerling.com/blog/2025/i-wont-connect-my-dishwasher-your-stupid-cloud

Если что, то Jeff Geerling достаточно известный в узких кругах человек

https://xn--r1a.website/tech_b0lt_Genona/3810
https://xn--r1a.website/tech_b0lt_Genona/3814

В целом, наблюдать за всем этим печально, потому что люди ради своего как бы удобства, перестают владеть не только купленным софтом (в самом широком смысле), но теперь уже и железом. Более того, радостно продолжают голосовать за это рублём.
👍37💯115🤡2