Kurgan-Telecom Ru | Информационные технологии

Анонс игры — одна из самых важных частей её разработки.

Сложно переоценить значение этого этапа. Он важен как для крупных студий, так и для соло‑разработчиков вроде меня. Хочу поделиться своей историей «успеха» анонса на IGN. Расскажу о технических проблемах при работе с движком UE 4, а также какими инструментами я пользуюсь.

Сколько статей на хабре про машинное обучение? Обозначим их количество за и напишем ‑ю.

Это попытка собрать цельное понимание: пройти путь от «что это вообще такое» до условных трансформеров и связать всё в одну логичную цепочку.

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

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

Переход от FP16 к 8 битному квантованию был триумфом инженерии, позволившим запускать LLM на потребительском железе почти без потерь. Но сегодня индустрия сошла с ума. 4 бита стали нормой, 3 бита преподносятся как новый стандарт, а на GitHub всерьез обсуждают 2-битные и 1.58-битные модели. В этой статье мы поговорим о математике квантования и о том, почему экстремальное сжатие весов перестало быть оптимизацией и превратилось в фанатизм. Почему огромная 70B модель, урезанная до 3 бит, математически глупее, чем 32B модель в 8 битах, и как мы обманываем сами себя, глядя на метрики perplexity.

Если Starship уронит цену вывода на низкую околоземную орбиту до $100–150 за килограмм к 2030 году, наземный электромагнитный масс-драйвер теряет экономический смысл. Но Опция B — лунный масс-драйвер — этим выигрывает. $28 млрд капекса, 8-километровый ствол в лавовой трубке кратера Шеклтон, 2,4 км/с скорости капсулы на выходе. С Луны кислород и Гелий-3 в точки Лагранжа за $50–80 за килограмм без единого ракетного двигателя. Опционный анализ 2×4: лунная катапульта даёт выигрыш в 3 из 4 сценариев Starship. Глубокий разбор инженерии ствола, реактора, орбитального ловителя и геополитики ILRS. Продолжение Урал-Драйвера.

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

Продолжаю публикацию интересных математических задач.

5 рациональных пиратов (А, Б, В, Г и Д) должны разделить 100 золотых монет. Иерархия: А — самый старший, Д — самый младший. Старший предлагает план дележа. Если за него проголосует хотя бы половина пиратов (включая его самого), план принимается. Если нет — старшего выбрасывают за борт, и право предложить план переходит к следующему. Как пират А должен разделить золото, чтобы остаться в живых и получить максимум?

Решение: Нужно рассуждать с конца. Если останутся только Г и Д, Г заберет всё (его голоса хватит для 50%). Чтобы этого не допустить, В должен предложить Д хотя бы 1 монету, чтобы тот поддержал его. Пират А знает это и предлагает: 98 — себе, 0 — Б, 1 — В, 0 — Г, 1 — Д. В и Д согласятся, так как при отказе и переходе хода к Б они могут не получить ничего или меньше.

Полгода я давал LLM писать unsafe Rust в боевых проектах и разбирал каждый блок под miri и санитайзерами. Категории ошибок, которые модели делают стабильно: aliasing, провенанс, layout в alloc/dealloc, забытый ManuallyDrop, гонки в FFI-колбэках, ручные Send/Sync, uninit-память, Pin. Каждая категория идёт с минимальным примером и фиксом.

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

Глубинная связь

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

Два примера планирования

1 - Новый контракт

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

от плохого:

Конференции в науке об ИИ очень любят и ждут. Подача работы на какое‑либо мероприятие из верхушки рейтинга CORE обычно престижнее, чем подача её же в журнал первого квартиля. В «большую тройку» главных конференций года принято включать NeurIPS, ICML и ICLR. Последняя обычно проходит раньше двух других — в этом году она прошла в конце апреля в Рио‑де‑Жанейро.

Мы посетили ICLR 2026 вместе с коллегами из AIRI и рассказываем, чем запомнилась нашим исследователям эта командировка.

Тридцать секунд, USB-флешка и зажатая клавиша Ctrl — этого достаточно, чтобы превратить «надёжно зашифрованный» корпоративный ноутбук в открытую книгу. Никакого подбора паролей, никаких хитрых атак на TPM — просто папка с подозрительным именем и среда восстановления Windows, любезно открывающая командную строку с полным доступом к диску.

В прошлой статье я показал, как защищен Open Source проект телеграм-бота. В комментариях меня спросили о иных инструментах и методах проверки в связи с чем, мы вышли к ключевому вопросу: почему, если основная LLM защищена, кастомные боты на ее основе остаются уязвимыми?

Базовые LLM проходят отдельное safety-training и RLHF-выравнивание. Но production-бот, построенный поверх модели, добавляет новый attack surface: system prompts, память диалога, RAG, tools, webhook-логику и внешние API. Именно этот orchestration layer часто становится слабым местом. Вот данные:

Из анализа 14 904 кастомных GPT:

Google полностью обновила сайт и приложение Gemini. Появился выбор уровня мышления, новый дизайн и модель Flash Lite. Однако у пользователей забрали Thinking модель и сильнее ограничили Pro модель.

В статье разберём, как именно раннер решает, что тест прошёл, почему .then без return выполняется уже после теста, почему try/catch в async‑тесте — частый источник ложного зелёного, что не так с forEach и setTimeout внутри тестов и какие инструменты не дают тесту соврать. Примеры на Jest, но контракт у Mocha, vitest и прочих тот же.

15 мая Линус Торвальдс принял в состав ядра документ, регламентирующий процесс обработки ошибок, связанных с безопасностью, определяющий модель угроз, поясняющий, какие ошибки в ядре трактуются как уязвимости, и разбирающий действия с ошибками, выявленными при помощи AI. Документ подготовлен Вилли Тарро (Willy Tarreau), автором HAProxy и давним разработчиком ядра Linux, отвечавшим за сопровождение нескольких стабильных веток ядра. В качестве основы использованы договорённости, достигнутые в ходе обсуждения недавно выявленных критических уязвимостей в ядре («Copy Fail», «Dirty Frag», «Fragnesia», «ssh-keysign-pwn»), раскрытых до публикации исправлений и для которых, благодаря AI, удалось сразу создать рабочие эксплоиты.

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

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

( читать дальше... )

 linux, безопасность, ядро

SpaceWeb в этом году исполняется 25 лет. За это время хостинг из ремесла для энтузиастов превратился в инфраструктурную индустрию, а потом начал растворяться в облаке. Что будет дальше — не очевидно даже тем, кто этот рынок строил.

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

Типичная ситуация: вы находите проблему в компании. Понимаете, как её решить. Пишете документ, готовите презентацию, объясняете идею руководителю. Все соглашаются: «Да, звучит разумно». И… ничего не происходит.

Документ лежит в wiki. Архитектура остаётся прежней. Процесс не меняется.

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

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

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

Но со временем стало очевидно: дело почти никогда не в самой идее. Дело в том, как она проживается людьми вокруг — и какую историю про неё в итоге начинают принимать.

Типичная ситуация: вы находите проблему в компании. Понимаете, как её решить. Пишете документ, готовите презентацию, объясняете идею руководителю. Все соглашаются: «Да, звучит разумно». И… ничего не происходит.

Документ лежит в wiki. Архитектура остаётся прежней. Процесс не меняется.

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

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

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

Но со временем стало очевидно: дело почти никогда не в самой идее. Дело в том, как она проживается людьми вокруг — и какую историю про неё в итоге начинают принимать.

Экосистема Flutter совершила один из самых значительных скачков вперед. С выходом Flutter 3.44 команда официально сделала Swift Package Manager (SwiftPM) менеджером зависимостей по умолчанию для iOS и macOS, ознаменовав начало конца эпохи CocoaPods.

Но это еще не все. Этот релиз также знаменует собой серьезный архитектурный сдвиг в том, как поставляются виджеты Material и Cupertino. Давайте углубимся в детали.

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

Состоялся выпуск Phosh 0.55.0, свободной графической оболочки для мобильных устройств на базе mainline Linux. Проект возник вокруг разработки Purism Librem 5, но сейчас используется на разных смартфонах, планшетах, трансформерах и даже ноутбуках. Основной упор, как и прежде, делается на Linux-смартфоны.

Phosh 0.55.0 опубликован 17 мая 2026 года. В состав выпуска входят обновления основной оболочки phosh, композитора phoc, экранной клавиатуры stevia, мобильных настроек, порталов, вспомогательных библиотек и нескольких новых компонентов.

В самой оболочке phosh 0.55.0 добавлена новая быстрая настройка для Syncthing. Также исправлена логика затемнения экрана: система больше не должна затемнять дисплей в ситуации, когда у устройства нет датчика внешней освещённости. Кроме того, разработчики отмечают различные исправления ошибок, включая устранение утечек памяти.

( читать дальше... )

 linux, mobile, phosh