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

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

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

Пока в приложении две роли и три проверки, авторизация умещается в if user.Role == "admin". Но стоит добавить пару ресурсов, ролей и исключений — и условные проверки начинают расползаться по хендлерам, дублироваться и жить своей жизнью.

В этой статье разберём, как навести порядок с помощью Casbin: вынесем правила доступа из кода в конфиг, пройдём путь от простого ACL до RBAC с иерархией ролей, соберём HTTP-сервер на Go с авторизационной middleware и обсудим грабли, на которые легко наступить по дороге.

Привет, дорогой читатель! Меня зовут Дмитрий, и я более 12 лет занимаюсь веб-разработкой. Так уж получилось, что за это время у меня набралась база клиентов, которые иногда обращаются с той или иной проблемой. Поскольку мой опыт довольно обширный, был среди них один клиент, которого я консультировал по SEO-продвижению сайта.

На днях он обратился ко мне с очень интересным вопросом: «Дмитрий, помогите, пожалуйста. Хочу, чтобы любой GPT-чат при запросе “топ-10 компаний, валяющих валенки” (реальный запрос я заменил) выдавал нашу компанию в первой пятёрке».

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

Объявлен выпуск MyCompany 6.2 — свободной и открытой ERP-системы для малого и среднего бизнеса, построенной на платформе lsFusion. Решение покрывает задачи складского и финансового учёта, управления закупками и продажами, производством, розничной торговлей и услугами, проектами, кадрами и автопарком.

Типовое решение MyCompany распространяется под лицензией Apache 2.0 и развивается как открытый проект на GitHub. Для начала работы доступны демо-стенд и документация по установке и настройке. Бесплатная поддержка оказывается в открытом телеграмм-канале.

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

 1с, erp, lsfusion, бизнес

Разработка - это инженерная задача!

Где-то полгода назад я понял, что меня так смущает в инфополе касательно ИИ-разработки. Все меряются количеством PR, написанных строк кода, ругают качество, безопасность и стандартные ошибки. Но когда на ретро мы обсуждаем, почему спринт получился не таким, как мы хотели, самая частая причина — не то, что что-то сложно технически. Жалобы в основном на то, что нам приходится оценивать задачу исходя из требований, которые не очень четкие; наши архитектурные решения, принятые до этого, не учли чего-то; стейкхолдеры не отвечают так быстро, как хотелось бы; технический долг накапливается — в общем, все, что мы с вами знаем. Но весь мир так увлекся, что сложная когнитивная задача (написание кода) может быть решена машиной, что, как мне кажется, решает не ту проблему.

В моем представлении, разработка программного обеспечения или иных программных решений — это инженерная задача. Когда-то давно один из архитекторов сказал мне: чтобы “кодить”, достаточно средне-специального образования. А вот чтобы разрабатывать ПО, нужно много чего уметь и знать; написание кода — это приятный бонус. Положив руку на сердце, я хочу сказать, что ИИ достаточно хорошо решает задачу написания кода. Только вот он решает не ту задачу.

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

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

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