Все потоки

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

Звучит идеально. Но на практике Serverless — это сделка. Вы отдаете контроль над инфраструктурой в обмен на удобство. И часто цена этой свободы — новые, совершенно неочевидные архитектурные проблемы.

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

И если всё это звучит как безумная смесь олдскула, низкоуровневой магии и настоящего инженерного кайфа? Вы правы! В статье я подробно рассказываю, как от студенческого мини приложения дошёл до своего кодека и p2p-звонилки, почему отказался от готовых решений, что пришлось invent-ить с нуля и какие открытия ждали на каждом шаге. Если хочется увидеть, как «а вдруг?» превращается в работающий проект, милости прошу внутрь.

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

В этой статье я пробую другой подход: записать условия глобальной кооперации как математическую задачу. Три "лагранжиана" — два конкурентных (условные США и Китай/БРИКС) и один кооперативный. Пять инвариантов — что нельзя нарушать. Формула равновесия — когда сотрудничать выгоднее, чем конфликтовать.

Оговорки: это не политическая аналитика и не прогноз. "Лагранжиан" здесь — аналогия из физики, не строгий вариационный принцип. Численных расчётов нет —  только каркас и формулы.

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

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

Свежая подборка интересных научных статей в области Информатики, опубликованных на arXiv.org.

Данный дайджест охватывает передовые и высокоспециализированные исследования в области информатики, которые формируют научный авангард IT-индустрии.

Классический Legal Judgment Prediction почти всегда обучается на уже готовых "юридических фактах" - тех самых установленных судом обстоятельствах, которые попадают в мотивировочную часть решения. Но для юриста или бизнеса важен прогноз до того, как суд всё это отфильтровал: на руках есть только набор взаимно противоречивых документов, а не аккуратный список фактов.

В свежем препринте предложили формализовать недостающее звено для "AI‑судей" — предсказывать факты (Legal Fact Prediction) и датасет LFPBench, который имитирует реальный сценарий "есть только доказательства, решения еще нет". Эту архитектуру - сначала восстанавливаем факты, потом применяем право - постепенно внедряю в "неШемяку!", почему бы об этом не рассказать...

Авторы исследования "Legal Fact Prediction: The Missing Piece in Legal Judgment Prediction" (EMNLP 2025) наглядно показали, что если просто скормить модели "сырые" доказательства и попросить предсказать исход, качество резко проседает относительно идеализированного сценария «когда у нас уже есть факты из решения». Это делает большинство академических LJP‑результатов с высокими цифрами на "чистых фактах" слабо применимыми в продакшене.

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

Приветствие

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

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

Но что, если воспринимать всю эту шумиху буквально? Не нанять одного ИИ-ассистента, а построить компанию, где все сотрудники - ИИ-агенты. Где CTO, маркетолог, продажник и HR - не люди. Где даже CEO - не человек. Человек в компании один, а сама компания существует только в виртуальной среде.

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

Привет, Хабр! Я бэкенд-разработчик в спортивном медиа Спортс”. В этой статье расскажу о glinq – LINQ-подобном API для работы с коллекциями в Go. После появления дженериков в Go 1.18 стало возможным реализовать type-safe функциональные операции без рефлексии и дорогостоящих приведений типов.

Генератор отзывов о ресторане:

Собрано почти 16 000 положительных отзывов от ресторанов с оценкой выше 4,7 (из 5), расположенных в Москве с https://yandex.ru/maps. Использованная модель — Qwen3-4B Qwen3 как поддерживающий русский язык. Для обучения модели в течение двух эпох использовалась библиотека Unsloth с LoRA. В результате был выбран LoRA 32-го ранга и обучено 66 млн параметров. Теперь модель может дать хороший новый обзор:

Целью было понять, как можно начать проект с нуля.

Провайдер Panix в Нью‑Йорке внедрил систему блокировки спама по «чёрному списку» хостов, после чего стал мишенью затяжной SYN‑flood DDoS‑атаки, начавшейся 6 сентября 1996 года и на несколько дней фактически парализовавшей его почтовые, веб-серверы и серверы новостей, а также системы логина и DNS. Эта атака является одной из первых крупных DDoS-атак в истории.

SYN-flood по-прежнему остаётся одним из самых популярных инструментов в арсенале злоумышленников. Согласно отчёту Cloudflare за Q2 2025, этот вектор атак составляет 27% всех DDoS-атак на 3 и 4 уровнях, уверенно занимая «почётное» второе место. В таких условиях надёжная защита от SYN-flood критически важна для любого сервиса.

Меня зовут Лейли, я инженер по информационной безопасности в Ozon Tech, и сегодня расскажу о том, как мы внедряли и контролировали самый простой механизм защиты от SYN-flood и о подводных камнях.

На SOC Forum одним из самых горячих дискуссий стала тема, которая ещё пять лет назад казалась нишевой, а сегодня напрямую влияет на устойчивость критической инфраструктуры: создание доверенных репозиториев ПО.

В дискуссии приняли участие: Федор Герасимов, лидер сообщества FinDevSecOps, эксперты финансового сектора − Максим Кожокарь (Банк России), Всеслав Соленик (Сбертех), а также Антон Прокофьев (ГК «Солар»), Юлия Липатникова (Cloud.ru) и Николай Костригин (Базальт СПО).

Полную запись дискуссии можно посмотреть здесь (Программа 18 ноября, Зал 3, 16.00).

В этом материале приводим самые интересные цитаты экспертов сессии и их рекомендации.

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

А еще он бесплатно расшифровывает голосовые (лучше Telegram Premium), понимает контекст переписки и обходит лимиты API через ротацию ключей. Под капотом — Node.js, никаких баз данных (только JSON) и чистый KISS-принцип.

Приветствую всех в новом сообществе, где я буду делиться ходом разработки!
Сегодня говорим о том где вообще записываются диалоги игры.

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

Вскрытие показало, что я немного отстал от жизни, и язык программирования «Кровожадный краборжав» уже вполне себе пригоден для написания простеньких хелоуворлдов…

Ладно. В кои-то веки обойдусь без ёрничанья. Официально заявляю: я написал свою первую библиотеку на расте и мне понравилось. Раст — несомненно местами красивый и приятный для работы язык. Написание кода укладывается в зелёный диапазон плотности wtf/sec, а инструментарий заслуживает всяческих похвал (кроме кросс-публикации документации на https://docs.rs/, которая в 2025 году занимает час — хоть донаты шли, её-богу).

Итак, я написал библиотеку, которая позволит эрлангистам проще вкатываться в раст. Акторная модель притворяется краденой из эрланга, с примитивами GenServer и GenStatem, с деревьями супервизоров, с боксированными сообщениями, мэйлбоксами, и привычной терминологией. Библиотека названа joerl, светлой памяти Джо Армстронга, с которым мне посчастливилось быть знакомым, и который сильнейшим образом повлиял на менталитет разработчика во мне.

Рассказывать про такие игры как Broken Arrow достаточно тяжело, потому что автор рискует попасть в одну из ловушек. Можно уйти в сухие цифры, терминологию и рассуждения о балансе. Это будет интересно любителям жанра, но для обывателя или новичков — это всё будет звучать как «эльфийский язык». Если же расписать всё «на пальцах», то текст будет не интересен игрокам.

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

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

Далее, будет мой взгляд на этот вопрос. Постараюсь без занудства и максимально просто (даже картинку поставил чёрно-белую, чтобы ничего не отвлекало от мыслей). :-)

В прошлой статье я рассказывал, как настроил личный iptables и перешел в режим Default Deny, чтобы отбиться от внешних DDoS-атак (коллег, пустых встреч и спама). Периметр я защитил, входящий трафик почистил. Uptime вырос.

Казалось бы — живи и радуйся. Но я заметил странную вещь: снаружи тихо, а сервер все равно греется. Я заглянул внутрь контейнера и понял: проблема не во входящих пакетах. Проблема в архитектуре самого приложения.

Парадокс: я могу спроектировать архитектуру, которая выдержит падение дата-центра. Я могу дебажить race condition в многопоточном приложении. Но когда мне нужно позвонить в страховую или выбрать отель для отпуска, я впадаю в ступор.

Мой личный бэклог забит задачами типа «разобраться с налогами» и «начать бегать», которые висят там с 2019 года. Я переношу их из спринта в спринт, испытывая фоновое чувство вины.

В какой-то момент я понял: это не лень. И это не «отсутствие мотивации». Это классический Technical Debt (Технический долг), только не в репозитории, а в нейросети.

И проценты по этому долгу я плачу самым дорогим ресурсом — своей когнитивной емкостью.

Кто угодно может пнуть мёртвого льва. Мёртвый лев не рыкнет на наглеца. Мёртвый лев не откусит ему ногу «по самое не хочу», хотя стоило бы. Лев мёртв, и теперь его может пнуть каждый ишак, что конечно же не показывает превосходство ишака над львом. Эта статья будет полна негодования и ненависти. Кровь ещё закончила кипеть от негодования. Но, разумеется, помимо эмоций будут и сухие объективные факты, немножко исследования и расстановка точек над i. В интернете кто-то не прав... опять...

Существует целый ряд инструментов, технологий и вообще вещей, которым по какой-то непонятной вселенской несправедливости не повезло: нашлась масса непонятных людей, которые по какой-то необъяснимой причине начали распускать про эти инструменты/технологии/вещи разные небылицы, идиотские фейки, слухи и прочий порочащий репутацию «компромат». Можно не переживать, если речь идёт о технологии, которая находится «на пике» — у неё будет большое community и правда восторжествует. Совсем другое дело, когда речь идёт о чём-то, что далеко не на пике, чья минута славы в прошлом (возможно даже давно в прошлом) — здесь мёртвый «лев» не может дать сдачи, и что самое обидное, что в какой-то степени «лев» сейчас мёртв отчасти и потому, что ещё при его жизни началось необоснованное распространение всяких бредовых поверий и мифов про него. И сегодня речь пойдёт об одном из таких случаев.