Linux *

Я мобильный разработчик. Иногда при работе со структурами данных я имею дело с endpoint-ами, иду в вики, нахожу страницу с описанием — и не верю ей. Потому что по опыту знаю: страница описывает API таким, каким он был задуман полгода назад, а не таким, какой он сейчас. Дальше начинается знакомый ритуал: пишу в чат бэкендеру, он отвечает «глянь в сваггере», сваггер сгенерирован из аннотаций и показывает приблизительную картину, реальный ответ с сервера от неё отличается, потому что правило сериализации живёт в одном месте, а правило генерации описания — в другом. В итоге я делаю то, что делает большинство клиентских разработчиков: дёргаю endpoint «вживую», смотрю реальный JSON и верю только ему. То же самое бывает и при работе с внешними API (в том числе и солидных компаний).

Это и есть проблема источника правды. У нас не один источник, а несколько, и они конкурируют. Вики — это намерение. Код бэкенда — это реализация. Реальный трафик — это факт. И когда между ними возникает расхождение (а оно возникает всегда), цена ошибки ложится в первую очередь на потребителя API: на фронтенд, на iOS, на Android, на десктоп, на внешних интеграторов.

Эту боль на Habr описывали многие. Алексей, Java-разработчик ЮMoney, в статье «Как улучшить межсерверное взаимодействие и сэкономить время разработчика» формулирует её предельно прямо: «Swagger UI, который генерируется автоматом по метаданным классов, показывает очень примерное описание того, что у нас реально отдаётся из API. Поэтому фронты и мобильные разработчики не могут начать разработку, не вызвав endpoint на живую». Это не чья-то личная неаккуратность — это структурный изъян процесса, в котором правда не централизована.

Я использую Linux 15 лет. Ну, то есть как использую: первые года три я его настраивал, а не использовал. Это разные вещи, и мне понадобилось позорно много времени чтобы это понять.

Сейчас у меня Fedora. Из коробки. С GNOME. Почти без кастомизации. Я набираю в ней код, сижу в браузере, иногда монтирую видео для внутренних демок. Всё работает.

Пятнадцать лет назад я бы от такого описания плевался. Как это «из коробки»? А где i3? Где polybar? Где 400 строк .vimrc? Где кастомный скрипт на баше который при подключении второго монитора переключает раскладку DPI и температуру цвета?

Ну вот, нету. И ничего не сломалось.

Привет, Хабр! На связи Даниэль из InfoWatch, разработчик решений класса информационной безопасности. В предыдущей статье мы рассматривали задачу контроля целостности в среде Linux с помощью системного интерфейса inotify. Поговорили о ключевых недостатках, с которыми приходится сталкиваться в ходе работы с самим инструментом напрямую.

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

Введение

Начнём с краткой сводки по fanotify. fanotify представляет собой kernel-интерфейс, позволяющий мониторить события файловой системы в режиме реального времени. Определение такое же, как и для inotify. Почти. Существенная разница в том, что список обрабатываемых событий у fanotify гораздо шире, а также есть возможность принимать решение kernel-характера в user space. Простыми словами: вы можете разрешать/запрещать запуск программ без написания драйверов (модулей ядра), так как fanotify позволяет разрешить/запретить создание процесса в пользовательском пространстве.

Практический опыт ограничения приложений на Android

В статье рассматривается практический опыт настройки Android‑смартфона с root‑доступом для ограничения сетевого взаимодействия приложений и управления их разрешениями. Анализ трафика, whitelist/blacklist доменов, Magisk, iptables и создание контролируемой среды на устройстве.

На кону финансовые данные клиентов, а странный и неуловимый баг в Cilium не даёт как следует настроить сетевую безопасность.

Статья о том, почему любая «нерешаемая» проблема — это «пока недостаточно изученная» проблема. От случайных догадок — к системному исследованию и пул-реквесту с фиксом прямо в Linux.

Попытался структурировать всю эту прекрасную линуксовую фрагментацию и собрал «айсберг» дистрибутивов

Не так давно у меня на руках появилась плата RK-ZYNQ7020-F REV 1.1.

В данной статье я хочу поделиться своим опытом, связанным с подготовкой buildroot для данной платы. Здесь мы разберем этапы от формирования xsa файла до запуска платы и первых логов, с объяснением что происходит в железе на каждом этапе.
Также в рамках этой статьи я не буду использовать FSBL, мы попробуем обойтись U-Boot SPL.

Итак, приступим к рассмотрению!

Описание отладочной платы

Базовый набор периферии на данной плате, заявленный в документации:

Всем привет! Это моя первая статья на Хабре. Я постарался максимально понятно изложить проблематику получения HDR изображений на современных мониторах и операционных системах.

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

Представьте, что завтра из нашего мира исчезнут все проекты Линуса Торвальдса. Ваш смартфон на Android моментально превратится в кирпич, интернет ляжет, а вся командная разработка ПО намертво встанет без Git. Удивительно, но вся современная цифровая инфраструктура держится на решениях, которые были придуманы одним человеком не ради миллиардов или славы, а просто из любопытства. В этой статье вспоминаем путь главного интроверта IT: от попыток починить старый Commodore до создания ядра Linux, победы над Microsoft и революции в Open Source.

В статье описано восстановление смартфона Alcatel POP3 4035D после отказа большей части встроенной памяти.

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

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

Продолжаю серию подборок. Недавно рассказывал про онлайн-сервисы для сетевиков, а сегодня статья для тех, кто арендовал первый виртуальный сервер. Если нужен мониторинг, защита и резервное копирование, но ставить тяжёлый софт ради одной машины не хочется (или не «можется») — эти опенсорсные инструменты вам точно пригодятся. 

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

Меня зовут Наташа, я менеджер проектов в Selectel. В этой статье расскажу, как, зачем и с какими инсайтами команда SELECTOS разработала aish (agent-integrated shell) —  терминал со встроенным AI-агентом для работы с сервером.

systemd unit‑файл часто начинается с пары строк из чужого примера, а заканчивается сервисом, который странно рестартует, пишет логи куда попало и работает с лишними правами.

В этой статье разбираем, как собрать unit‑файл для своего Linux‑сервиса: от минимального скелета до production‑настроек с рестартами, зависимостями, hardening‑параметрами, лимитами ресурсов и journald.

В версии tcl/tk-9.0 добавлена возможность создавать изображения image из SVG-файлов (а значит и сохранять их в png-формате). Всё было хорошо до тех пор пока мне для статьи на сайте Tcler's Wiki ни потребовался флаг США для кнопки переключения языка интерфейса:

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

Учился на технолога бродильных производств. Защитил кандидатскую. Управляю пивоварней и параллельно — исполнительный директор в фирме по производству пищевого оборудования. Код не писал никогда. Но в детстве, когда появился нормальный интернет, я развлекался тем, что ставил на комп разные дистрибутивы Linux — от OpenBSD до классических. Не особо понимал, как их настраивать и зачем мне это. Потом, когда стал работать — понял, в чём сила Linux, но для настройки просто искал советы в интернете и копировал оттуда команды, или просил брата помочь.

А потом появились LLM. И я понял — вот оно. Можно не учить синтаксис, не зубрить фреймворки. Можно объяснить что нужно и получить работающий код. Вдохновился. Попробовал. Столкнулся с галлюцинациями, бесконечными переделками, кода сгенерировано уже куча — а он не работает. Перегорел. Попробовал снова.

Контекст такой: мне нужно было сделать АСУ ТП для пивоварни. Система управления технологическим процессом — датчики, клапаны, насосы, частотники. Я решил, что ИИ уже дорос. Начал с одного Claude‑агента: я ему говорю что делать, он делает. Потом дошёл до шести параллельных агентов. Они начали конфликтовать, переделывать работу друг друга, плодить баги. На одну фичу — пять новых проблем. Проект рос, но болезненно.

А потом на предприятии по производству оборудования случилась попытка рейдерского захвата. Пришлось бросить всё и месяц заниматься защитой станков. Код и агенты отошли на второй план.

В этой статье я расскажу, как мы с нуля разработали диагностический инструмент для анализа работы ТСПУ (Технических средств противодействия угрозам) в российских сетях. Скрипт позволяет определить режим блокировок, проверить доступность портов, выявить SNI-фильтрацию и даже диагностировать подмену DNS. Весь код — открытый, под MIT-лицензией.

Роб Савойе (Rob Savoye) — один из основных разработчиков GNU Project, всю жизнь посвятил свободному ПО. Он приложил руку к созданию десятка опенсорсных проектов, включая GDB, GCC и Cygwin. Является ведущим разработчиком и мейнтейнером медиаплеера Gnash, через который можно воспроизводить проприетарные файлы Flash (SWF) под Linux.

А недавно Роб получил широкую известность как главный разработчик нового проекта LibrePhone по созданию первого в мире полностью свободного телефона, без проприетарных компонентов и бинарных блобов. Этот проект «должен закрыть последние пробелы между Android и свободным ПО».

Рассмотрим одну из старых проблем со стабильностью работы Postgres – отсутствие полного контроля за потреблением оперативной памяти при выполнении запросов. В ряде случаев это приводит либо к свопированию, либо к падению СУБД и остановке работы информационной системы. Происходит это неожиданно, без предупреждения и в не самый удачный момент. В системах 1С эта проблема точно существует, встречали не раз.

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

Если вы работаете в большой компании и одновременно живёте там, где есть какие-то региональные ограничения на сервисы, у вас почти наверняка две VPN-конфигурации:

рабочая — для доступа к внутренним ресурсам (GitLab, Jira, Confluence и т.д.)

личная — для личных целей

И постоянное переключение между ними — это, мягко говоря, неудобно.