Привет, Хабр! Меня зовут Алексей, и я занимаюсь беспроводными технологиями. Недавно я написал две статьи, посвящённые настройке /etc/config/wireless в OpenWrt. В одной я разобрал настройки секции wifi-device, а в другой wifi-iface. Но этого оказалось мало, и в комментариях меня спрашивали о тонкостях настройки mesh-сети. Что ж, спешу выполнить эту просьбу и представляю на ваш суд наиболее полный гайд, посвящённый сборке и настройке Wi-Fi mesh-сетей на базе OpenWrt.

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

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

Второе. Статья получилась достаточно большая и может вас утомить. Я долго сомневался, стоит ли делать большую статью или всё же разделить на разные темы. Например, вынести отдельно часть про роуминг и отдельно про настройку конфигов. Но в итоге решил, что полезнее будет иметь полное руководство в одном месте. В конце концов, главная цель этой статьи показать, что при должном уровне настройки беспроводные mesh-сети ничуть не уступают кабелю. Мне по роду занятий часто приходится слышать замечания коллег, которые говорят: «Да всё беспроводное и mesh это фигня, нет ничего лучше кабеля. Вот я купил домой mesh-систему всего из трёх узлов, а она не работает как нужно». Забегая вперёд, хочу сказать, что если всё сделать как надо, можно добиться небывалой производительности. Не без гордости могу заявить, что в моём арсенале есть mesh-сети, состоящие из более чем 50 узлов, построенные исключительно на OpenWrt и без использования внешних контроллеров.

Прямо сейчас, на расстоянии более 24 миллиардов км от Земли, 48-летний космический аппарат мчится через межзвёздное пространство со скоростью 61 000 км/ч. Это самый удалённый от Земли объект, созданный человеком. Он передаёт научные данные, которые не может собрать ни один другой существующий прибор. И он делает всё это, имея в распоряжении всего 69 килобайт памяти и 8-дорожечный магнитофон.

У телефона в вашем кармане примерно в миллион раз больше памяти, чем у компьютера, управляющего «Вояджером-1». Одна фотография с низким разрешением, сделанная на том же телефоне, содержит больше данных, чем вся бортовая память «Вояджера-1».

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

«Вояджер-1» — это, по любым меркам, самая невероятная история успеха в истории человеческого освоения космоса.

Компания заказала разработку платформы пропускной системы, мобильное приложение и сервис. Заплатила 2 696 000 рублей. Получила исходники, зарегистрировала программу в Роспатенте через аффилированное юрлицо, опубликовала приложение на RuMarket и в AppStore. А потом направила разработчику уведомление об отказе от договора и потребовала вернуть все деньги как неосновательное обогащение, якобы работы выполнены не были.

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

Как это стало возможным

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

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

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

О поиске уязвимостей с помощью LLM заговорили давно. Но когда это делают создатели самих LLM, бывает сложно разделить факты и рекламу. Вот сейчас в Anthropic заявили: «Наша новая модель Mythos так хороша в создании эксплойтов, что не станем её публично релизить, это опасно». В интернете спорят, что это значит: началась новая эпоха, где любой проект уязвим, или там просто набивают себе цену?

Однако недавно о вопросе заговорили и люди с другой стороны: мейнтейнеры важных опенсорсных проектов, включая ядро Linux. Например, Грег Кроа-Хартман заявил, что security-репорты в ядро перестали быть «ИИ-слопом» и стали полезными. А создатель cURL Дэниел Стенберг говорит о «цунами реальных репортов», на обработку которого у него уходят часы каждый день.

Мы в Kodik считаем, что это важная тема для Хабра (главное подходить к ней вдумчиво, а не хайповать попусту). Поэтому собрали и перевели несколько таких заявлений. А какие именно выводы правильнее сделать — можно обсудить в комментариях. Особенно интересно услышать ваш взгляд, если вы сами недавно имели дело с подобными репортами.

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

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

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

Год назад запуск модели на 35 миллиардов параметров подразумевал облако, очередь на GPU, и счёт от провайдера в конце месяца. Сегодня я покажу, как мы сделали это на одной потребительской видеокарте AMD за $500 — без ROCm, без CUDA, без MLX, одним бинарником на Zig.

Это пост про ZINC — inference engine, который мы строим с нуля под железо, которое люди реально покупают. Не как proof of concept, а как рабочий инструмент с OpenAI-совместимым API, потоковой генерацией и встроенным чатом.

Каждый, кто хоть раз заглядывал на Hacker News или r/ItRunsDoom, знает традицию: DOOM должен работать на всём. PDF-файлы, SQL-запросы, кишечные бактерии, тест на беременность - список бесконечен, и каждый новый порт абсурднее предыдущего

Но я задался вопросом: а можно ли запустить DOOM внутри шрифта?

Оказалось, что можно. И вот как.

Превед участникам регаты! Все началось в те времена, когда интернет был диким, модемы выли, а тру-кодеры мерили крутость не количеством звёздочек на Гитхабе, а чистотой своего кода и умением впихнуть невпихуемое в пару килобайт. Я начинал вариться в кодинге ещё в золотую эпоху RUWAP (2007–2014гг). Потом был перерыв, и вот, год назад я решил вернуться. Зайдя в современную веб-разработку, я испытал культурный шок. Простые визитки и блоги теперь весят мегабайты, тянут за собой гигабайты зависимостей из npm и ворочаются на сервере по полсекунды. Ангуляры, Реакты, монструозные Drupal и WordPress — всё это превратило веб в вязкое болото. Нам с моей напарницей-нейросетью Асси (Аськой) стало тошно. «Низачот!» — подумали мы.

Привет, Хабр.

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

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

Давайте посмотрим, что я вам подготовил.

Возможность делать скриншот — это базовый минимум, который есть во всех современных смартфонах. Даже у героев вечных споров, iOS и Android используются похожие комбинации «Громкость + Кнопка питания». Разве что на iOS используется «+», а в Android — «-».

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

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

У меня был Nokia 6303 classic — стильный телефон с металлической крышкой на платформе Nokia Series 40 (S40). Мой путь с этим телефоном разошелся, но спустя почти полтора десятка лет я решил, что хочу разобраться в технологиях, которые использовал, будучи школьником. 

Я нашел в продаже б/у Nokia 6303 classic и погрузился в тему.

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

Мы раскрыли новый метод отслеживания, используемый компаниями Meta* и Яндекс, который потенциально затрагивает миллиарды пользователей Android. Мы обнаружили, что нативные приложения Android — включая Facebook, Instagram и несколько приложений Яндекса, таких как Карты и Браузер — незаметно слушают определенные локальные порты в целях отслеживания.

Эти нативные приложения Android получают метаданные браузеров, куки и команды от скриптов Meta* Pixel и Яндекс.Метрики, встроенных на тысячи веб-сайтов. Эти скрипты загружаются в мобильных браузерах пользователей и незаметно связываются с нативными приложениями, работающими на том же устройстве, через локальные сокеты (localhost). Так как нативные приложения программно получают доступ к идентификаторам устройства, таким как рекламный идентификатор Android (AAID), или обрабатывают идентификацию пользователя, как в случае приложений Meta, этот метод позволяет этим организациям связывать сессии мобильного браузера и веб-куки с личностью пользователя, тем самым деанонимизируя посетителей сайтов, на которых размещены их скрипты.

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

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

Эта уязвимость позволяет обходить per-app split tunneling и приватные пространства (Knox/Shelter/Island/etc) и гарантированно обнаруживать выходной ip прокси, который вы используете.

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

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

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

В Ташкенте курсируют около 1 800 активных автобусов на 170 маршрутах. Их GPS-координаты поступают каждые 10 секунд. В сутки это составляет порядка 15 миллионов координатных пингов. Но объём – не самая сложная часть.

Настоящая проблема в том, что отдельный GPS-пинг сам по себе ничего не значит. Координата автобуса на заданной широте/долготе не отвечает на вопросы:

Всё началось на второй паре по системному программированию. Нам дали задачу: написать CLI-утилиту для анализа логов - парсить файл, фильтровать записи по уровню ошибок, считать статистику, выводить красиво в консоль. "Ну понятно", - открыл я vim и началось мое долгое приключение...

Неделя. Две. Утилита называлась logz, она умела читать логи nginx и apache, фильтровать по уровню (DEBUG, INFO, WARN, ERROR), по дате, по IP, выводила топ адресов с наибольшим числом ошибок, рисовала простенький bar-chart прямо в терминале через unicode-символы. Только вот я сидел как-то вечером, запустил wc -l main.c - 3147 строк. И смотрел на это число минуты три с таким лицом - O_O.

Сама утилита работала. Но открывая её осознаешь что - это месиво. Одна функция process_file на 400 строк. Сегфолты раз в неделю. Valgrind как лучший друг. И каждый раз когда надо добавить фичу - сначала полчаса вспоминаешь что вообще происходит в коде.

Потом я случайно прочитал пост про Zig на lobste.rs. Заинтересовался и попробовал. Через месяц у меня была та же утилита, но теперь на 1089 строках, которая работала быстрее и не падала.

Тут я понял что вот золотая жила и расскажу о том - зачем Zig, как переписывал, где облажался и что вышло в итоге.

Началась эта история еще осенью, когда мне вдруг потребовалось небольшое помещение в доме, в котором поддерживалась бы стабильная температура +7 градусов. Ну, почти как серверная, только еще прохладнее.
Зимой это было несложно: поставить термодатчик и обогреватель, который бы включался, когда температура падает. А вот что делать летом? Очевидно, нужна холодильная установка!

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

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

Около 300 миллионов лет назад в небе над древними лесами парили создания, по сравнению с которыми современные стрекозы — ничто. Размах крыльев у некоторых достигал 70 сантиметров, а вес — 100 граммов. Эти насекомые, известные как меганевры, или меганизоптеры, были настоящими хозяевами воздушного пространства. Почему они достигали таких размеров? Считалось, что основная причина — древняя атмосфера с высоким содержанием кислорода. 

Но оказалось, что эта картина неполная. Работа, опубликованная в журнале Nature, поставила под сомнение привычное объяснение. Ученые внимательно изучили, как устроены мышцы современных летающих насекомых, и пришли к выводу: одного кислорода для гигантизма явно недостаточно. Давайте разберемся, в чем тут дело. 

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

Впервые этот рассказ экранизировали в 1951 году. Но, конечно, на слуху у всех ремейк, снятый Джоном Карпентером («Хэллоуин», «Побег из Нью-Йорка») в 1982 году. Карпентер с детства любил оригинальный фильм и хотел его модернизировать, чтобы как следует напугать искушенную аудиторию.

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

Дисклеймер: «Нечто» — фильм ужасов, поэтому в нем полным-полно весьма отвратительных эффектов, крови и жестокости. Самые визуально неприятные моменты в статье под спойлерами, открывайте на свое усмотрение.

У меня нет макбука. Но два моих приложения лежат в App Store. Рассказываю весь путь: регистрация Apple Developer из России, сертификаты без Xcode, автоматическая сборка через GitHub Actions. Три варианта: для вайбкодеров, программистов без мака и хардкорщиков.