Почти в каждом PHP-приложении есть форма загрузки: аватар, документ, картинка к объявлению. Если у атакующего получится загрузить файл и заставить сервер его выполнить, он получит на машине ровно те же права, что и само приложение, а дальше — дело техники. Разбираемся, как противостоять таким атакам с помощью веб-шелла — серверного скрипта, который принимает команды через HTTP и выполняет их.
Хабр, привет!
На днях наткнулся на отличную статью Никиты Тимофеенко «Вам не нужны bool и Option». Автор со стороны Rust-разработки поднимает фундаментально правильный вопрос: кодировать состояния системы разрозненными флагами вроде succeeded: bool и failed: bool — это плохой тон, ведущий к трудноуловимым багам. Система типов должна делать некорректные состояния запрещенными на этапе компиляции.
В C++ сообществе эта идея, разумеется, тоже не нова. Мы давно и успешно оборачиваем подобные вещи в std::variant, используя std::monostate как аналог отсутствия значения (можно задать псевдоним, например AbsentResult).
Но читая статью и комментарии к ней, я поймал себя на мысли: мы, разработчики, слишком сильно увлеклись мощью современных компиляторов. Как только стандарты C++ (да и Rust) дали нам инструменты для зубодробительных compile-time проверок любых сущностей, мы начали пихать эти проверки везде, где нужно и не нужно.
В этой статье я хочу показать, как правильное использование std::variant может... замаскировать серьезную ошибку проектирования архитектуры. Как увлечение построением лучшей системы типов отвлекает нас от фундаментальных вопросов проектирования систем. Мы разберем, как классические стейт-машины при поллинге (polling) заставляют нас писать тонны шаблонного кода ради проверок, которых в этой точке программы вообще не должно существовать.
В конце октября вокруг PHP развернулась одна из самых громких дискуссий о безопасности open source этого года. Две критические уязвимости под общим именем PHP2Shell допускали удалённое выполнение кода без аутентификации, а их раскрытие сопровождалось утечками и спором между поставщиками. После первых дней громких заголовков в СМИ тревога успела смениться скепсисом. Пока одни участники сообщества яростно выясняли, почему исправления задержали, другие спрашивали: а не преувеличена ли вовсе опасность?
Разница в реакции была разительна. В Нидерландах из предосторожности отключили государственные порталы, а в Германии прикрыли сайты города Мюнстер и его онлайн-сервисы. Университет Хельсинки временно закрыл свой экземпляр образовательной платформы Moodle и несколько других сервисов, чтобы защитить пользовательские данные. Три дня спустя исследователь Джеймс Павур предложил взломать свой PHP-сервер и забрать биткоины примерно на 500 долларов. Его, наоборот, смущало, что громких предупреждений много, а сообщений о реальных жертвах мало.
И всё же спор не сводится к тому, кто испугался сильнее. Как получилось, что об ошибке знали задолго до публикации, а выпуск исправления сопровождался утечками и разногласиями? И что остаётся выяснить тем пользователям, кто дождался исправлений?
Прикладное руководство, помогающее с азов понять, как организованы атаки с переполнением стекового буфера под Windows. Ведь по Unix‑подобным системам таких разборов уже хватает.
Современные компиляторы делают за нас так много, что можно написать плохо спроектированную программу – и даже не понять этого. Простой мысленный эксперимент помогает проверить, что на самом деле обеспечивает надёжность вашего кода: архитектура или гарантии языка. Представьте, что временем жизни объектов теперь приходится управлять вручную. Насколько понятными останутся правила владения ресурсами – и насколько трудно будет их соблюдать?
В 2001 году Джоэл Спольски, сочинения которого сильно повлияли на мою карьеру, написал великолепную статью Back to Basics. Суть её заключается в том, что практикующим программистам нужно разбираться в основах: какой бы абстрактной и далёкой от базовых алгоритмов ни казалась наша работа, от них неожиданно глубоко зависят наши проекты.
В качестве одного из примеров подобного Джоэл приводит ловушку «маляра Шлемиля», в которой кажущийся простым выбор приводит к квадратичной временной сложности. В притче о Шлемиле маляр, рисующий линии на дороге, не носит с собой банку с краской. Он движется вперёд, и ему приходится всё больше времени тратить на то, чтобы вернуться к банке.
Удивительно, насколько часто паттерн маляры Шлемиля встречается даже в 2026 году.
В прошлых двух статьях я рассказывал, как запустить Qwen3.8-Flash-Next (125 млрд параметров) на старом железе и как снять программный потолок FP16 на видеокартах. Обе статьи были про железо и про то, что можно взять готовое и заставить работать. Эта - другая. Я залез внутрь самого движка (Strata), построил живую визуализацию того, что он делает с экспертами модели под капотом, попробовал ответить на вопрос “а эксперты реально специализируются по темам?” - и на середине пути поймал себя на методологической ошибке, которая чуть не привела к красивому, но неверному выводу. Расскажу как есть, с цифрами и без приукрашивания.
Что такое Strata и при чём тут эксперты
Strata - движок инференса для MoE-моделей (Mixture-of-Experts): вместо одной плотной сети у модели есть десятки экспертов на каждый слой, и на каждый токен активируется лишь небольшое подмножество (top-K). У Qwen3.8-Flash-Next, с которой я работал всю эту серию статей, это 48 слоёв по 512 экспертов - то есть 24576 отдельных “узлов”, из которых на каждом шаге реально считает лишь небольшая часть.
Проблема в том, что весь набор экспертов (сотни гигабайт) физически не влезает в 8ГБ VRAM моей GTX 1070. Strata решает это адаптивным кэшем: часть экспертов постоянно живёт в VRAM (самые “горячие”), остальные читаются из RAM или SSD по мере надобности, и кэш сам решает, кого держать резидентно, а кого вытеснять - на основе decayed-счётчика обращений к каждому эксперту.
Вся эта механика раньше была для меня чёрным ящиком: я видел только агрегированные цифры в мониторинге (сколько экспертов в VRAM, hit rate). Захотелось увидеть её изнутри.
Время идет, технологии меняются, набитые шишки копятся, настала пора обновить материалы по SVG-анимациям. Тем более, что тема для многих фронтендеров все еще остается странной и запутанной. В этой статье мы рассмотрим SVG-анимации с разных сторон, посмотрим на актуальное состояние дел, возможности и сопутствующие инструменты. Мы не будем разбирать каждое свойство и каждый хак. Слишком большой объем материала получится. Для этого есть MDN и ему подобные сайты. Задача текущей статьи — дать общее представление о том, что бывает, и от чего можно оттолкнуться, если вы решили изучать эту тему, а у вас полная каша в голове.
Итан Сигел (американский астрофизик‑теоретик и научный журналист, автор рубрики «Спросите Итана», один из пропагандистов современных научных знаний), разбирает вопрос о «естественности», или, скорее о кажущейся нам «неестественности» соотношений некоторых физических величин. Одни нам кажутся подозрительно близкими, другие непонятно почему различаются на многие порядки...
@avshkol сделал перевод этой статьи, чтобы разобраться в том, где «неестественность» кажущаяся, всего лишь отражение природы такой, какова она есть, а где такие совпадения или нестыковки могут потенциально привести нас к научному открытию?..
В последние пару лет порог входа в разработку изменился навсегда. С появлением Cursor, Claude Code, GitHub Copilot и больших языковых моделей родился феномен «вайбкодинга» (vibe coding): ты набрасываешь мысли в чат на естественном языке, ловишь ощущение потока, нейросеть за секунды генерирует компоненты, скрипты, роуты API — и все это действительно запускается в браузере.
Для пет‑проектов, прототипов на хакатонах и быстрой проверки продуктовых гипотез это потрясающий инструмент. Спорить с этим глупо: скорость черновой сборки выросла в разы. Но у этой легкости есть опасная цена: иллюзия, что генерация синтаксически корректного кода — это и есть разработка программного обеспечения.
В реальности код — лишь самый дешевый и поверхностный артефакт. Настоящая программная инженерия (Software Engineering) начинается там, где сгенерированный код встречается с суровой физической действительностью...
В статье обсудим антипаттерн Primitive obsession, разберём на примерах способы его устранения в разных языках программирования.
Делал интерактивную открытку на день рождения и хотел, чтобы картинка не просто появлялась, а «рисовалась»: сначала карандашные линии, потом по касанию её заливает акварель, причём с рваным краем, как у краски, которая впитывается в бумагу.
Готовых решений под такое не нашёл. Видео не подходило: нужна была реакция на тап и чёткость на любом экране. В итоге всё собралось на чистом SVG, паре фильтров и небольшом количестве JS. Ниже разбираю по шагам, с кодом и граблями, на которые наступил.
В процессе изучения CSS-анимаций мы обычно разбираем синтаксис, говорим что-то про keyframes, про transition, про связанные с ними свойства, про то, как их активировать при наведении мыши или с помощью навешивания классов. И часто на этом все и заканчивается. И вот, сделав пару меняющих цвет кнопок или выезжающих уведомлений, люди считают, что они знают про CSS-анимации все. Но так ли это?
Разумеется, нет. Главные сложности начинаются тогда, когда речь заходит о чем-то более хитром, нежели изменение цвета или прозрачности у элемента, тогда, когда мы сталкиваемся с дизайнером с широкими взглядами, который придумыват всякие разные штуки, не особенно заботясь о том, как их потом верстать. И вот тут многие фронтендеры начинают спотыкаться. Мои наблюдения показывают, что разработчикам, причем не только начинающим, не хватает широты взглядов, не хватает каких-то дерзких идей, ломающих привычный порядок элементов на странице, чтобы реализовать что-то более-менее сложное. И мне кажется, что нужно с этим что-то сделать. В связи с этим мы сегодня посмотрим на некоторые примеры CSS-анимаций с CodePen, которые могут стать триггерами, заставляющими задуматься о широте возможностей простых казалось бы инструментов, и дадим сами себе несколько советов по поводу того, что стоит попробовать сделать при изучении этого класса анимаций. Надеюсь кому-то это поможет взглянуть на CSS-анимации под новым углом и немного прокачать свои навыки их использования.
Итан Сигел (американский астрофизик‑теоретик и научный журналист, автор рубрики «Спросите Итана», один из пропагандистов современных научных знаний), пытается на пальцах объяснить уравнение Эйшнтейна, определяющее общую теорию относительности. Эта теория невероятно сложна с математической точки зрения.
@avshkol перевел эту статью, чтобы любой, кто не готов к резкому погружению в сложный мир тензорных вычислений, смог понять основные принципы того, как устроено пространство-время и как именно масса искривляет пространство-время, а оно, в свою очередь, показывает массе, как ей двигаться...
В программный продукт наряду с собственным кодом попадает и сторонний код через зависимости, которые могут содержать уязвимости и накладывать лицензионные ограничения. Чтобы разобраться в таком наследстве, используется документ с названиями, версиями компонентов и связями между ними. Для него есть название – Software Bill of Materials (SBOM), или перечень программных компонентов (ППК). По этому перечню разработчик может быстро найти библиотеки с известными уязвимостями в своих приложениях. Команда CodeScoring часто работает с этим форматом, так как мы разрабатываем собственное решение для композиционного анализа ПО (Software Composition Analysis, или SCA).
Разработчики могут взять готовую модель машинного обучения в открытом доступе, дообучить её на своих данных и уменьшить точность весов для запуска на машинах послабее. В их продукт таким образом попадёт уже производная модель. Чтобы разобраться в её происхождении, понадобится знать исходную модель, данные и выполненные преобразования.
Для этого были введены понятия MLBOM и AIBOM, которыми обозначают документы с составом моделей и систем, использующих искусственный интеллект. В этой статье мы разберёмся, что за ними стоит, чем отличаются эти названия и какие сведения для таких документов можно собрать автоматически.
Данное научно-популистское исследование посвящено фундаментальному коду русской ментальности, зашитому в грамматику. Мы попытаемся доказать, что русский язык создавался не для передачи информации, а для запутывания вероятного противника и тренировки стрессоустойчивости.
Глава 1. Главный экономический закон лингвистики
Начать наше погружение в бездну филологического хаоса необходимо с фундаментального вклада отечественной финансовой мысли в мировую науку. Речь идет о великом термине, который официально приписывают главе Центробанка Эльвире Набиуллиной, хотя в кулуарах поговаривают, что его нашептал сам Дух русской словесности.
«Отрицательный рост» — это не просто формулировка из экономических отчетов. Это высшая точка развития нашего языка. Математически это выглядит как абсолютный абсурд: рост со знаком минус (-X). Но лингвистически это шедевр! Это когда всё падает, но падает с таким оптимизмом, что в процессе падения успевает подрасти.
Продолжаем наши изыскания по следам блога философа Михаила Эпштейна «Нооцен как движущая сила эволюции».
Начну с ударной цитаты:
