GitHub *

Знакомый жанр новостей, правда? В популярный пакет или action подсунули вредоносный код, и все бегут проверять свои сборки. Таких историй за полтора года набралось как минимум три. В марте 2025 года у tj-actions/changed-files перенаправили теги на коммит, который печатал секреты прямо в лог сборки. 31 марта 2026 года в npm на несколько часов попали вредоносные axios@1.14.1 и axios@0.30.4: они тянули зависимость plain-crypto-js со скриптом postinstall, и любая сборка, поставившая их с включёнными install‑скриптами, выполнила чужой код. А 4 августа 2026 года началась волна ChainDrop, и вот тут масштаб был совсем другой: по данным Aikido, начиная с keyv@6.0.0 скомпрометировано не меньше 444 пакетов.

И каждый раз под такой новостью звучит один и тот же совет: проверьте логи и ротируйте все секреты. Совет правильный. А вы сами его когда‑нибудь выполняли? И как успехи? В организации десятки репозиториев и сотни секретов. С какого начинать? Какие точно трогать не нужно? И в какой момент можно выдохнуть и сказать «всё, мы чисты»?

Я предлагаю зайти с другой стороны и задать вопрос поуже: какие именно запуски GitHub Actions в окне инцидента получили плохую версию пакета или action, что эти job’ы могли увидеть и, значит, что ротировать первым. Для ответа вам хватит двух инструментов — gh и jq. Никаких платных сканеров, никакой магии. Давайте пройдём это вместе, по шагам.

И одна просьба: не откладывайте. По умолчанию GitHub хранит логи и артефакты запусков 90 дней, а потом восстановить картину уже нельзя. Для ChainDrop, если срок хранения в репозитории не меняли, это примерно 2 ноября 2026 года.

Убрали AWS-ключи из GitHub Secrets и настроили OIDC — можно считать CI/CD защищённым? Массовая атака Megalodon, в ходе которой злоумышленники внедряли вредоносные workflow в GitHub-репозитории, показала, что временные токены тоже можно украсть. Разбираем, где остаются уязвимости и какие меры помогут защитить GitHub Actions.

Хабр, привет! Хекслет в эфире. 

Мы в десятый раз перепроверяем свои RSA-ключи, чего и всем желаем: 22 сентября 2026 года GitHub объявил, что ужесточает правила для подключений по SSH. Мы расспросили об этом Дмитрия Зайцева — он DevOps, CTO в компании Flocktory, организатор и спикер Devops Days.

Скоро GitHub отключит часть старых алгоритмов и изменит требования для новых RSA-ключей. Изменения касаются только SSH и не затронут репозитории, которые открываются по HTTPS. 

Что и когда изменится, как подготовиться и что проверить — всё расскажем и покажем. 

У меня есть Telegram-бот, который каждое утро присылает пять трендовых репозиториев GitHub с trendshift.io. Под каждым кнопка: нажал, и бот выдаёт выжимку README, чтобы разобрать идею. Я читаю эту ленту каждый день и иногда ставлю то, что понравилось.

26 сентября в ленте был «Microsoft Activation Scripts»: 1774 звезды, аккуратное описание, теги. Бот оформил его так же, как четыре соседних проекта, с той же кнопкой.

Это была ловушка.

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

В статье разберём: какие юридические риски может нести сходство с оригиналами, что всё это говорит о будущем разработки ПО, и насколько его приложения близки к коммерческим аналогам.

Как вернуть LAN-режим в Neverwinter Nights 2 на прошитой Switch: без аккаунта Nintendo, без подписки, по локальной сети между двумя консолями. Разбор ARM64-кода, отладка GDB прямо на консоли и готовый патч для Atmosphere.

15 августа я показал здесь Telemax — мост, который приносит переписку из MAX в Telegram. Пост прочитали 14 тысяч раз, под ним набралось 48 комментариев.

А на следующий день ссылка на GitHub из поста начала отдавать 404. Не репозиторий удалён, не аккаунт заблокирован — просто для всех, кто не вошёл под моим именем, меня и моего кода больше не существовало. Читатели шли по ссылке и упирались в пустую страницу, а те, кто уже поставил мост, потеряли обновления.

Разбанили меня только через месяц. Эта статья — о том, как прошёл этот месяц, как проект пережил его без GitHub и что из ваших комментариев за это время стало обновлениями.

Наш проект называется ExVRAM Lab. Это открытая исследовательская лаборатория, в которой мы проверяем, насколько большие локальные LLM можно запускать на обычных видеокартах с ограниченным объёмом VRAM, если использовать ultra‑low‑bit quantization, полное размещение весов на GPU и существующие open‑source inference‑технологии.

ExVRAM расшифровывается как Exchange Compute for VRAM. Основная идея проекта — в ряде сценариев выгоднее потратить часть свободной вычислительной мощности GPU на работу с более компактным представлением весов, чем хранить часть модели в оперативной памяти и постоянно передавать данные через PCIe.

Когда мы начинали проект, исходный вопрос был достаточно простой: можно ли запустить dense‑модель примерно на 27 миллиардов параметров на видеокарте всего с 8 ГБ VRAM так, чтобы она не просто «запустилась», а работала полностью на GPU, поддерживала длинный контекст и обеспечивала нормальную интерактивную скорость генерации.

В качестве основной тестовой системы мы используем NVIDIA GeForce RTX 5060 8 GB на архитектуре Blackwell. Основная модель в текущих экспериментах — Qwen3.8–27B.

Сначала результат выглядел не слишком впечатляюще. Модель запускалась, но значительная часть весов оставалась в системной памяти. Около 5,7 GiB весов находилось на GPU, ещё примерно 2,5 GiB — на CPU. Скорость генерации составляла порядка 3,8–5,5 токена в секунду.

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

Это стало одним из первых важных наблюдений проекта. Проблема заключалась не столько в нехватке вычислительной мощности RTX 5060, сколько в том, что часть decoder weights находилась в RAM. Во время autoregressive generation данные приходилось постоянно передавать между CPU и GPU через PCIe.

Вечером я дописал на ноутбуке кусок проекта, утром сел за пк и начал объяснять ассистенту, что вчера было сделано. Второй раз за неделю.

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

Облако для этого ставить не хотелось, платить за синхронизацию заметок тем более. В итоге всё свелось к приватному репозиторию и двум хукам на двадцать строк bash.

Ниже: почему не подошли облачная папка, Obsidian Sync и плагин, как устроен скрипт, что сломалось по дороге и зачем вообще отдельное хранилище, если у Claude Code есть встроенная память.

Всем привет!
Меня зовут Шатохин Дмитрий, я работаю в компании SM Lab старшим программистом 1С.

Выносим полнотекстовый поиск за пределы кластера 1С. Нечеткое соответствие, учет опечаток и регистра без нагрузки на сервер и СУБД основной базы.

Sku-search: кроссплатформенный сервис полнотекстового поиска для 1С — находит все по наименованию, артикулу, штрихкоду и любым реквизитам
Когда стандартный поиск 1С сдается, а Elasticsearch кажется пушкой по воробьям.

Знакомая боль?

Оператор в вашей 1С создает новую номенклатуру и вбивает «Болт М16 оцинк.». Система молчит. Он сохраняет — и в базе появляется дубль, потому что «Болт М16х60 оцинкованный ГОСТ 7798-70» уже существовал три года.

Или другой случай. Приходит прайс поставщика. В нем артикул ART-000002, в вашей 1С — тот же, но записан как Art-000002. На первый взгляд безобидно: строки в 1С по умолчанию сравниваются без учета регистра, и «в лоб» эти значения не отличить друг от друга. А для акцизных марок, марок Честного ЗНАКА, серийных номеров и артикулов, где регистр различает модификации, это ловушка: 1С выдает кучу ложных совпадений, а поиск «с учетом регистра» из стандартного запроса не настроить.

23 сентября GitHub окончательно убрал Node 20 из раннеров GitHub Actions. JavaScript-экшены теперь выполняются на Node 24, а временный выключатель ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION, которым можно было вернуть Node 20, больше не работает. Через шесть дней, 29 сентября, на GitHub Enterprise Cloud включилась полная проверка версий self-hosted раннеров.

Две новости за неделю, и обе ломают тихо.

Помните Million Dollar Homepage? В 2005 году студент продал миллион пикселей по доллару за штуку и заработал миллион. Никакой пользы в этих пикселях не было, но люди платили за участие в мемчике и за место, которое видят другие.

Мне захотелось сделать что‑то похожее для разработчиков, только вместо денег — валюта, которую у нас и так все копят: звёзды на GitHub.

Так появился Star Throne — репозиторий‑игра. Ставишь ему звезду, и через минуту‑две GitHub Actions считает, сколько звёзд у тебя самого. Если ты сильнейший в своей лиге, твоя аватарка появляется на троне прямо в README. Сервера нет, базы данных нет, хостинга нет. Всё работает на GitHub.

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

Как IT-стартапу говорить с пользователями, инвесторами и медиа, не смешивая три разные истории в один пресс-релиз

Стартап может годами объяснять, почему его продукт нужен рынку, а потом столкнуться с другой задачей: объяснить, почему в этот продукт стоит инвестировать. На первый взгляд разница небольшая. В обоих случаях мы рассказываем о компании, проблеме, решении и планах. На практике это разные разговоры. Пользователь хочет понять, станет ли ему проще, быстрее или дешевле. Инвестор хочет понять, может ли из этого продукта вырасти масштабируемый бизнес, почему именно сейчас и что изменит дополнительный капитал.

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

Поэтому продуктовый PR и PR для раунда в коммуникационном агентстве «ЛАМПА» мы не строим по одному шаблону. В первом случае мы отвечаем на вопрос: «Почему этим стоит пользоваться?» Во втором: «Почему в это стоит инвестировать сейчас?»

Представьте парк аттракционов, фуд-корт на фестивале, корпоративную столовую или сеть автомоек. Что их объединяет? Всем им нужна своя закрытая платёжная система или внутренняя программа лояльности (клубные карты).

Обычно внедрение такой системы — это боль. Нужно покупать дорогие терминалы, нанимать интеграторов и пилить самописный софт. А что делать, если система нужна «на один раз» (для трёхдневного фестиваля) или у малого бизнеса просто нет бюджета?

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

Под капотом — классический стек React + Node.js и капелька технологии в виде WebNFC.

Мне давно нравится идея хранить заметки обычными Markdown-файлами в своём репозитории на GitHub. Файлы остаются твоими, их можно открыть на github.com или в любом редакторе, а история изменений достаётся даром: это просто коммиты.

Был проект BatNoter, который делал ровно это, но ему нужен был собственный сервер для входа через GitHub. В конце 2022 года сервер перестал отвечать, и приложение умерло.

Я переписал его так, чтобы сервер был не нужен вовсе. Получился Notewing: браузер сам ходит в GitHub API, изменения копятся офлайн и отправляются одним коммитом, а конфликтующие правки не теряются. В статье расскажу, как устроена синхронизация через Git Data API, где были подводные камни и как всё это тестировать, не трогая настоящий GitHub.

За месяц дайджест трендов GitHub про ИИ-агентов принёс мне 138 уникальных репозиториев. Я взвесил каждый, ничего не запуская: скачал архив через API и посчитал отдельно код, прозу, тесты и сгенерированное. 56 % оказались платформами, которые форкают только с намерением сопровождать. Лёгких, которые можно переписать под себя за вечер, всего 24, и половина из них вообще не инструменты. Лицензия оказалась фильтром раньше веса: у 9 репозиториев её нет совсем, а один файл начинается словами MIT и ниже запрещает коммерческое использование. В статье метод, таблицы и три признака накрутки звёзд, которые я пытался автоматизировать и которые не сработали.

Если вы ищите работу и у вас много телеграм-каналов с вакансиями, слова апи, python, гитхаб вам знакомы, то вам будет полезно. Мой кейс: когда я искала работу то смотрела по 50+ постов в день в десятках каналов в телеге, из них подходящих вакансий было штук 10, одна и та же вакансия висит в четырёх каналах, половина постов это курсы и "ищу работу", фильтров никаких. Платить за агрегатор мне не хотелось.

Собрала свой сервис, который вы можете адаптировать под любую роль: скрипт читает папку каналов в Telegram, отсеивает не-вакансии, вытаскивает компанию, грейд, город и зарплату, склеивает дубли и раз в день выкладывает одну страницу с фильтрами на GitHub Pages. Стоимость - ноль, ключи нужны только от Telegram.

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

Экспортер написан на Go и совмещает функции сборщика метрик, логов, проверки обновлений образов и встроенной панели мониторинга в одном легковесном образе.

MCP-сервер - это по переходник между ИИ и внешним сервисом. Например, один MCP читает файлы на ПК, другой - программирует, третий - ищет инфу в интернете. 

То есть ИИ в основном отвечает на вопросы, анализирует и генерит картинки, а через MCP он может еще подключаться к Figma, Google Drive, базе данных, браузеру, почте и тысячам других сервисов.

В этой подборке я собрал 100 самых популярных MCP-серверов - вместе они набрали ⭐3.1 млн звезд на GitHub.

Мода на квантизацию скоро закончится...когда появятся они: модели, обученные на тернарной/тритовой/троичной логике.

Или нет?

Пройдемся по форматам обучения от FP32 до FP4, а потом сделаем аналог модели Microsoft Bitnet 1.58 на C#, размером 29Кб (в экстремальном варианте — 17,1 КБ).