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

првиет хабр! на момент написание данной статьи три уязвимости о котрых пойдет речь уже залатали в IOS 27 beta 5 для разработчиков а сами уязвимости уже слиты разработчиком johnny (@0xjohnny в X). всего вышло четыре уязвимости о которых пойдет речь

В прошлой статье мы рассмотрели, как создать простой синтезатор на основе Raspberry Pi Pico. Звуки на основе синусоиды интересны, но хочется получить звук реального инструмента с его уникальным тембром.

Если вы думаете, что достаточно просто проигрывать записанный звук для каждой ноты, то, по крайней мере, для Raspberry Pi такой подход не сработает из-за ограниченных ресурсов. А вот использование звуковых шрифтов (SoundFont), которые придумали ещё в прошлом веке, поможет решить задачу.

Изобретать велосипед и реализовывать обработку SoundFont-файлов с нуля мы не будем, а воспользуемся готовой библиотекой TinySoundFont.

Изучение технологии SoundFont и то, как устроены звуковые банки вообще, даёт много в понимании синтеза звука.

В этой статье мы подключим библиотеку TinySoundFont к Raspberry Pi Pico, устраним главный недостаток библиотеки — загрузку всего SoundFont в оперативную память, и заставим синтезатор читать семплы напрямую из флеш-памяти.

Один пользователь Claude утверждает, что прогнал через модель больше миллиарда входных токенов. Другой оставил AI-агента без присмотра и насчитал около $6000 расходов. Цифры из Reddit можно оспаривать, но механизм за ними вполне реальный.

Я посмотрел, почему короткий запрос внутри длинного чата может оказаться совсем не коротким для LLM, что происходит, когда контекст разрастается до сотен тысяч токенов, зачем нужен prompt caching и почему большое контекстное окно иногда делает ответы не лучше, а хуже.

А заодно собрал несколько способов снизить расход токенов без бессмысленной охоты за каждым словом в промпте.

Часть 2 из 2. В первой части был холивар про самодельные фреймворки. Здесь - цифры: мы дали ИИ-агенту построить одно и то же приложение на Джеймиксе и на голом Spring и честно сравнили результаты.

После моей прошлой статьи в Telegram-бот за один день пришли 60 человек. Я тогда подумал: ну всё, полетело. Спойлер: не полетело.

Сейчас в базе почти 300 аккаунтов, за неделю возвращаются 11 человек, средний DAU 7, а реферальная программа привела троих. Разбираю честную воронку, ошибки с метриками, странный парадокс обратной связи и V2, которая должна проверить одну конкретную вещь: получится ли удержать хотя бы четыре возвращения из семи.

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

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

Проблему обнаружил один вопрос: а мониторы он теперь тоже должен закупать?

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

Чтобы понять, как оно туда попало, надо вернуться к началу проекта. В подписанном техническом задании была совершенно нормальная строка:

15 уроков охватят все: от настройки интерфейса и трассировки трубопроводов до гидравлических расчётов, выпуска документации и работы с базами данных. По окончании – сертификат от разработчика и доступ к материалам на три месяца.

С развитием ИИ себестоимость кода стремительно падает. Его становится все больше, а команды не растут пропорционально количеству. AI-инструменты генерации кода (Copilot, Cursor, Codex, Claude Code) увеличивают скорость написания, но не скорость проверки кода.

Узким горлышком становится сам PR, они могут висеть днями в вашей компании или opensource-проекте, контекст может теряться, на его оценку тратится время, и иногда впустую.

В среднем, команда на ревью тратит ~20% рабочего времени, особенно если это большой PR, или PR от новичка.

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

В этой статье я расскажу о том, как помочь вашему корпоративному или опенсорс-проекту, если он тонет в код-ревью, и расскажу о существующих решениях — devin ai, context7, deepwiki, rabbit code review и других.

Привет, Хабр! Я Захар Захаров, разработчик в команде LBaaS. Контроллеры (они же операторы) в Kubernetes — паттерн, который выглядит просто на схеме из документации и неожиданно обрастает деталями, когда садишься писать его руками: очередь, воркеры, кэш, индексы, манифесты, схема, веб-хуки.

В статье разберу, из чего на самом деле состоит контроллер, что из этой обвязки берет на себя kubebuilder и какие грабли мы собрали на работе — от бесконечной реконсиляции до finalizers, которые молча не срабатывают для ресурсов из разных неймспесов. Погнали.

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

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

Под рукой была GTX 1080 Ti на 11 ГБ. Карта 2017 года, архитектура Pascal, никаких Tensor Cores.

Так из прикладной задачи постепенно вырос небольшой домашний стенд. Я прогнал три модели в одинаковых условиях, отдельно проверил длинный контекст, затем сделал свой набор reasoning‑задач и сравнил режимы с размышлением и без него. Результаты получились не совсем такими, как я ожидал.

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

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

До революции? Возможно.

Одно было ясно всем: стол переживёт их. Переживёт он и того самого пожилого человека в тёмном форменном кителе с несколькими звёздами на погонах, который сейчас сидел во главе стола.

Сам этот человек, впрочем, понимал это не хуже остальных.

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

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

— Так точно! По вашему распоряжению штат укомплектован армейским переводчиком.

— Тогда начинайте.

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

Может показаться, что старый Yii1 в 2026 году уже никому не нужен. Но, на удивление, проектов, застрявших на этом фреймворке, довольно много. Чаще всего сдерживающими факторами от переезда являются размер проекта, какие‑то свои надстройки над фреймворком или отсутствие денег у бизнеса. Переезд сопряжён с рисками получить два проекта на годы вперёд. Параллельно требуются какие‑либо доработки, что требует вдвое больше ресурсов и от разработчиков, и от бизнеса.

Последний год я активно изучаю устройство современных PHP‑фреймворков и PSR‑стандарты. Относительно недавно мне пришла мысль: а что ценного есть в Yii1 и что блокирует возможность быстро съехать на другой фреймворк? Ответ довольно банален — это Active Record. Можно сказать, что это сердце фреймворка. Почему же так получилось? Как ни странно, внешний API данного слоя довольно неплох даже в 2026 году, не говоря уже о 2008-м, когда он появился на свет, а скорее всего, намного раньше.

Что же мы имеем из возможностей данной ORM?

Допустим, вы пишете программу для обработки изображений. Программа получает изображение, преобразует его в значения с плавающей запятой, выполняет обработку и сохраняет изменённые пиксели на диск в виде 8-битных цветов. Сегодня я хочу рассмотреть вопрос преобразования целых значений в значения с плавающей запятой. Существует два решения, которые на Python и NumPy выглядят так:

Стандартное деление на 255

pixels = img / 255.0
result = process(pixels)
output = np.trunc(result * 255 + 0.5)

Альтернативное деление на 256

pixels = (img + 0.5) / 256.0
result = process(pixels)
output = np.trunc(result * 256)

Я предполагаю, что в обоих случаях выходные значения ограничиваются перед окончательным преобразованием типов:

# Ограничение и преобразование в 8 бит
output_8bit = output.clip(0, 255).astype(np.uint8)

В стандартном случае целочисленный 0 соответствует 0.0, а 255 соответствует 1.0. Это работает абсолютно нормально и именно так всё реализовано в GPU. В альтернативном случае прибавляется смещение на 0,5 и деление происходит на 256, поэтому целочисленный 0 соответствует 0.5/256=0.001953125. Это неудобно, потому что код обработки изображений, например, без знания константы не сможет обнаруживать чёрные пиксели. Из‑за этого мы привязываем логику к 8-битным значениям, даже если вычисления выполняются с плавающей запятой. В стандартном решении всегда можно предполагать, что чёрный соответствует 0.0.

Однако некоторых программистов всё равно притягивает альтернативное решение. В чём дело? Чем оно им так нравится?

Известно, что чем больше продается мороженого, тем больше регистрируется несчастных случаев с утонувшими. Корреляция есть - значит, мороженое опасно?

Эта статья — о том, почему знание правила «correlation ≠ causation» еще не гарантирует, что вы сами на нем не попадетесь

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

Привет! Я Никита, разработчик системного ПО в Selectel. В этой статье рассмотрим эволюцию трех наиболее известных планировщиков Linux: O(1), CFS (Completely Fair Scheduler) и EEVDF (Earliest Eligible Virtual Deadline First).

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

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

Если вы пишете SQL-запросы, то наверняка сталкивались с ситуацией, когда данные исчезают, отчеты не сходятся, а бизнес теряет деньги. И виновник этого — маленькое, но очень коварное слово NULL. В 1974 году Эдгар Кодд, создатель реляционной модели данных, ввел это понятие, чтобы обозначить отсутствие информации. Он хотел, как лучше, но спустя пятьдесят лет NULL продолжает «терроризировать» разработчиков по всему миру. Важно усвоить раз и навсегда: NULL — это не значение. Это состояние неизвестности.

Поэтому:

·       NULL ≠ 0 (ноль - это число);

·       NULL ≠ '' (пустая строка - это строка);

·       NULL ≠ ' ' (пробел - это символ).

Но всегда есть нюансы и исключения. Например, в Oracle INSERT INTO table (col) VALUES ('') запишет NULL. Это поведение отличается от других СУБД и часто становится сюрпризом при миграции.

Команда VK Cloud подготовила перевод обзора релиз-команды Kubernetes (Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor) из блога kubernetes.io. О том, что устареет, сломается и перейдёт в GA в Kubernetes v1.37, релиз которого запланирован на 26 августа 2026 года. Будет полезен тем, кто эксплуатирует кластеры Kubernetes в проде: DevOps- и SRE-инженерам, платформенным командам, которые планируют обновление.

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

Вчера получила пуш от Я.Навигатора о “новой” фиче “по шагам”. 

Привет! Меня зовут Маша, я Senior Product Manager и я разбираю только те продукты, которыми сама пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей

Авторизация — это сложно… Хотя казалось бы — самая частая используемая фича в мире. Очень многие процесы завязаны на авторизации и аунтентификации. Начиная от ваших любимых соц сетей и заканчивая редакторами кода.