В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.

Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.

В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.

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

В этом году я решил выстроить чёткую и долгосрочную систему поддержки энергии и физической формы. Не просто «пить витамины» и «ходить в зал», а реально следить за здоровьем и прогрессом — на цифрах, в динамике, с результатами. И помог мне в этом DeepSeek.

Сегодня расскажу, как построил систему, которая клонирует и сканирует тысячи публичных GitHub-репозиториев — и находит в них утекшие секреты.

В каждом репозитории я восстанавливал удаленные файлы, находил непривязанные («висячие») объекты, распаковывал .pack-файлы и находил API-ключи, активные токены и учетки. А когда сообщил компаниям об утечках, заработал более $64 000 на баг-баунти.

Возможно, пригодится на рабочей неделе 😉

1. aistudio.google.com

Бесплатно доступны:

— лучшая текстовая модель от Google — Gemini 2.5 Pro

— прошлое поколение видеогенератора Veo2 — всё ещё очень хорошо

— прошлое поколение генератора картинок Imagen 3 — для простых задач сойдёт

— генерация речи в свежей Lyria — можно создать качественный голос с интонацией и даже диалог персонажей

Лимитов почти нет.

Данная статья открывает серию из трёх материалов, каждый из которых представляет отдельный уровень изучения Kafka.

Если у тебя уже есть практический опыт работы с Kafka — первый уровень, скорее всего, не для тебя. Он предназначен для новичков, которые хотят понять, зачем вообще нужен Kafka и где он используется. На втором уровне ты углубишься в технологию — и этого уже будет достаточно, чтобы уверенно использовать Kafka в профессиональной работе. Третий уровень — это джедайский уровень. Не обязателен, но если ты его освоишь — будет круто. Серьёзно.

Недавно я работал над достаточно большим проектом на Rust. К моему удивлению, мне никак не удавалось заставить тесты работать правильно.

Команда cargo test запускала выполнение всех тестов в репозитории, но спустя пару миллисекунд все тесты завершались сбоями из-за не очень знакомой мне ошибки:

Io(Os { code: 24, kind: Other, message: "Too many open files" })

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

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

• Когда может потребоваться резервуарное сэмплирование.

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

• Простой способ реализации резервуарного сэмплирования на случай, если вам оно понадобится.

Усаживайтесь поудобнее, ребята! Сегодня мы с вами разберём следующий увлекательный вопрос: что будет, если заинлайнить вообще всё?

Если вы пока не знакомы с техникой встраивания (inlining) то примите к сведению, что в сообществе специалистов по разработке компиляторов многие, в том числе очень авторитетные фигуры (например, Чендлер Каррут) считают этот приём наиважнейшим при оптимизации компиляторов. Подробнее о том, как устроено встраивание, рассказано здесь — мы беззастенчиво хвалимся той презентацией, с которой выступили перед участниками конференции LLVM Developers' Meeting по межпроцедурной оптимизации. Я рассказывал о встраивании и очень рекомендую вам посмотреть хотя бы первые 6 минут. В этом видео я рассказываю, почему встраивание — очень простое преобразование, а вот тут вашему вниманию предлагается реализация встраивания, предложенная великим Крисом Латтнером уже около 20 лет назад — в ней всего около 200 строк кода. К сожалению, сегодня даже само преобразование пропорционально выросло: в качестве примера взгляните хотя бы на InlineFunction.cpp.

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

У себя в блоге мы регулярно делимся полезными ресурсами для специалистов: например, запустили бесплатный курс по DevOps. А сегодня дополнительно рассказываем про ещё четыре открытых материала по DevOps.

Всем привет!

В этой статье, я вам расскажу про свой личный опыт работы с виртуальными сетевыми лабораториями. Хочу начать своё повествование с небольшой предыстории — как я пришёл к теме.

Многие полагают, что если есть некая абстрактная структура материала, то обязательно она состоит из молекул, а атомы... А атомы там просто где-то есть. Они как-то группируются и становятся базовым элементом любой структуры. Но неизменно, что атомы должны обязательно стать молекулой и только потом из молекул будет собрано всё вещество. И уж точно атомы не могут соединяться друг с другом без формирования молекул.

Но оказывается существуют молекулярные и немолекулярные материалы. В одном типе есть молекулы, а в другом - только атомы. Почему иногда так, а иногда так и как тут сработал принцип наименьшей энергии? Разбираю вопрос на винтики. Будет интересно!

Пару дней назад я написал пост о тритонах, в котором упомянул чрезвычайно ядовитого американского тритона. Но тогда у меня не было ни места, ни времени объяснить, почему он настолько ядовитый. И, разумеется, меня немедленно забросали кучей* комментариев и писем с вопросами. 

^*тремя

Что ж, ладно, расскажу. Самый ядовитый тритон в мире — это Taricha granulosa, желтобрюхий тритон. Скромное маленькое земноводное, эндемичное для северо-запада тихоокеанского побережья Северной Америки, к западу от Каскадных гор примерно от округа Санта-Круз (Калифорния) до Юго-Восточной Аляски.

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

Я уже несколько лет чиню гаджеты — от смартфонов до материнских плат ноутбуков. Это не только экономит бюджет, но и приносит удовольствие от возвращения к жизни старых устройств. Конечно, для того, чтобы ремонт был удачным, кроме опыта, нужны инструменты. Без них починка девайсов превращается в гадание на кофейной гуще.

Этот текст для начинающих любителей электроники. Поделюсь опытом использования трех ключевых приборов в моей мастерской — лабораторного блока питания (ЛБП) DS310S, мультиметра Mestek DM100C и USB-осциллографа Hantek 6022BE. Подробно расскажу, как использую каждый прибор, с реальными примерами из практики. Надеюсь, будет полезно!

Посмотрели за вас все доклады с System Level Meetup и выбрали по два лучших из потоков по Linux Kernel и C++. Для «плюсовиков» приготовили выступления о мета-программировании и девиртуализации в компиляторах. Для тех, кто интересуется ядром Linux — материалы о kernel bypass и чем-то еще. 

Остальные доклады и дискусии собрали в плейлисты, ссылки ищите под катом.

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

Сегодня я хочу поделиться историей моего знакомого и бывшего студента Сергея Ракова. Его карьера сложилась довольно необычным образом: от инженера-конструктора в Богородицке он прошел путь до Android-разработчика в Катаре.

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

Также коснулись темы культурных особенностей. Да, заголовок — не кликбейт, в Катаре по-прежнему существуют телесные наказания. Историю о них мы расскажем в конце; забегая вперед, знакомые Сергея поплатились таким образом за пьяное вождение (осуждаем).

Мало что настолько меня угнетает, как невозможность что‑либо понять так, чтобы потом объяснить это самому себе:) И хоть я уже давно не девятиклассник, этот период запомнился мне внезапным переходом от заучивания материала «чтобы не схватить парашу» к некоторой степени осознания «а как оно там устроено и почему именно так». Сложнее всего было с математикой и я постоянно изобретал для себя «объяснялки». Этот навык, к счастью, прижился и стал привычкой.

Привет! На связи команда Standoff Bug Bounty. Недавно мы провели откровенный разговор с топовыми багхантерами — теми, кто превратил поиск уязвимостей в профессию. Они рассказали, как начинали свой путь, поделились личными историями и профессиональными секретами. В этой статье вас ждет рассказ иностранных исследователей о самых запоминающихся репортах в их практике, уязвимостях, которые всегда в топе у исследователей, must-have инструментах для поиска багов и о роли ИИ в багхантинге.