Linux *

Когда речь заходит о корутинах (сопрограммах) на С++, большинство программистов вспоминает фреймворк coroutine_ts, появившийся в стандарте С++20. Многие даже не догадываются о том, что писать корутины можно было задолго до появления упомянутого стандарта. При этом можно было использовать не только С++, но и Си. Данной статьей я открываю серию, в которой хочу описать свой личный опыт изучения корутин и привести примеры их использования. Надеюсь мои статьи помогут начинающим разобраться в этой сложной и интересной теме.

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

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

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

Обычно я за то, чтобы не усложнять рантайм лишний раз, но здесь случай приятный: можно включить у своих CLI автоматический выбор библиотек под реальные возможности CPU и не ломать обратную совместимость. Механизм называется glibc-hwcaps, появился в glibc 2.33, и он позволяет динамическому загрузчику подбирать lib’ы из специальных поддиректорий по уровню x86-64-v2/v3/v4. Это ровно те уровни, что определены в x86-64 psABI, без частных расширений конкретных вендоров. На практике достаточно положить собранный под v3 lib рядом с обычным, соблюсти SONAME, и ld.so сам подхватит оптимизированный вариант на новых процессорах. На старом железе всё продолжит работать на базовой сборке.

У нас 1С развёрнут на Linux и PostgreSQL. Всё началось с запроса клиента на развёртывание 1С в Linux-среде. Мы создали первый кластер, а затем перевели всю облачную 1С на open source.

В этой статье расскажем о нашем пути, сложностях и результатах. Больше подробностей об особенностях работы облачной 1С вы узнаете на вебинаре — запись эфира открыта по ссылке. 

Здравствуйте, уважаемые читатели Хабра и любители вирусного анализа!

Сегодня хочу поделиться своим дебютным(на Хабре) разбором простенького семпла шелла под Linux.

Начнём.

Откроем в файл в DIE. Семпл для 32-битной UNIX системы, не упакован.

Рассказ о самой полезной части Nix — управление пакетами из репозитория nixpkgs.

Я использовал и использую разные языки. В Rust есть прекрасный пакетный менеджер cargo и инсталлятор rustup, для JavaScript — npm. Мне также нравится conda в мире Python.

Мне всегда не хватало чего-то подобного для проектов на Си и C++. Пакетные менеджеры для этих языков часто оставляют желать лучшего. Даже если они работают, в их репозиториях может не быть нужных библиотек. Даже если вроде всё работает хорошо, может оказаться, что для работы бинарного кэширования нужно прилагать усилия, а когда это что-то вроде разных версий Qt — собирать всё на машине разработчика неприятно.

Я хотел, чтобы инструмент из коробки давал максимум без дополнительной настройки.

Поэтому я расскажу, как использовать Nix в качестве пакетного менеджера для Си и C++.

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

Главной темой и проблемой IT является, необходимость набора софта для осуществления тех или иных целей. Например - графический редактор, редактор/читалка документов, локальный DNS-сервер, система мониторинга, почтовый сервер или вовсе доменный контроллер - зачастую с этого всё и начинается. Всё это вероятнее всего, имеет закрытый код - проприетарный.

В дополнение, многие делают очень весёлую ошибку, пытаясь используя знания и/или специфичную терминологию NT-мира (Windows*) полноценно работать/судить в/о *nix среде. Естественно, ничего не получается, но некоторые особенно упёртые, пытаются заставить работать, например AD (Active Directory) в Linux. В итоге сохраняется базовая функциональность в лице пароль+логин+сертификаты/билеты и не более, потому что закрытый остров Windows, сильно отличается от открытого света.

Собственно, а почему так? А потому что “удобно”, "быстро", "красиво", "едино" и ещё сотня подобных слов, где будет оправдываться монополия Microsoft, а так же зависимости, проприетарность, закрытость и невозможности внесений изменений. Всё это и так же отсутствие стандартизации между проприетарными проектами (Не только в Microsoft), без установки дополнительного софта или даже костылей - не решается. Ну и ещё цена неадекватно большая была примерно... Всегда, за лицензию Windows и уж тем более серверного издания.

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

29 сентября 2025 года Линус Торвальдс объявил о выходе ядра Linux 6.17. За два месяца работы 2 118 разработчиков внесли 14 334 патча. В общей сложности затронут 12 841 файл. В ядро добавлено 646 тысяч строк кода, удалено около 399 тысяч, а общий объем изменений составил 46 МБ.

Основной фокус релиза — драйверы (43% изменений), сетевой стек (14%), файловые системы (4%) и поддержка архитектур (10%). Собственно, все как всегда. Ну и обновление добавляет поддержку нового оборудования, оптимизацию производительности и исправления, которые делают систему стабильнее. В статье разберем, что нового в Linux 6.17, как улучшения повлияют на работу и почему этот релиз стоит вашего внимания.

Некоторые уязвимости, связанные с повреждением памяти, невероятно сложны для эксплуатации. Они могут вызывать состояния гонки, приводить к сбоям системы и накладывать разные ограничения, которые усложняют жизнь исследователя. Работа с такими «хрупкими» багами требует значительно больше времени и усилий. CVE-2024-50264 в ядре Linux — как раз одна из таких сложных уязвимостей, которая получила премию Pwnie Award 2025 в категории «Лучшее повышение привилегий» (Best Privilege Escalation). В этой статье я представлю свой проект kernel-hack-drill и покажу, как он помог мне разработать прототип эксплойта для уязвимости CVE-2024-50264.

Всем привет! Меня зовут Константин. Моя карьера в сетевой разработке началась со времен Symbian OS, когда я участвовал в создании сетевого стека этой платформы. С 2010 года я работаю в «Лаборатории Касперского», разрабатывая мобильные и сетевые продукты, а последний год плотно погружен в проект NGFW. В мои задачи входит как проработка архитектурных решений, так и написание кода ключевых модулей. 

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

- об архитектуре передающего слоя (data plane) нашего продукта, основанной на связке DPDK/VPP;
- о пути сетевого пакета в рамках data plane NGFW;
- о частых ошибках при разработке решений на базе VPP;
- о разработке и сценариях встраивания в высокоскоростной конвейер обработки пакетов VPP некоторых из наших движков безопасности;
- об истории создания наших собственных движков безопасности DPI и IDPS (хочу выразить благодарность за неоценимую помощь в подготовке материала для данного раздела коллегам из команды IDPS и лично Евгению Прусову);
- об интеграции data plane с протоколами динамической маршрутизации.

Материал будет полезен архитекторам и разработчикам, участвующим в создании высокопроизводительных и отказоустойчивых сетевых решений.

Линус Торвальдс в своём классическом стиле категорически высказался против предлагаемой поддержки режима big-endian для архитектуры RISC-V в ядре Linux. Всё началось с вопроса в рассылке о том, смогут ли патчи для RISC-V BE попасть в текущий цикл разработки ядра.

Вы много своих приложений упаковывали, как RPM пакет? Мне, до недавних пор, не доводилось. Тенденция импортозамещения и перехода на OC Linux потребовала освоить и это умение. Ничего сложного, но, как и везде, есть нюансы, детали и особенности.

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

Статья - достаточно подробная инструкция, как решить эту задачу и автоматизировать ее с помощью GitLab CI/CD.

Привет, Хабр! Уже давненько вокруг ходит тема про io_uring — новую высокопроизводительную модель асинхронного I/O в Linux. В теории это обещает минимальные системные вызовы и очереди отправки/завершения, но как это в деле работает с привычными утилитами? Я решил разобраться на примере типичной задачи — копирования файлов (и немного упомянем хеширование) – переписав её под liburing и сравнив с традиционной синхронной версией.

Представь мир, где каждый сервер, приложение и сетевая конфигурация тщательно оркестрируются через Git, где обновления, аудиты и восстановления происходят с помощью одного коммита. Эти и другие возможности открывает GitOps. Особенно мощно он проявляет себя в сочетании с универсальностью Linux-систем. Как же преобразить управление инфраструктурой Linux? И каким образом с помощью Git добиться ясности, контроля и уверенности в каждом изменении?

Вот и прошел примерно год с момента начала эксперимента "а что, так можно было?"
Год назад привычный ноутбук был отложен в сторону, а вместо него поднята рабочая машинка на базе процессора с архитектурой arm, точнее aarch64.

И там и там — примерно одинаковый набор ПО, чтобы можно было сравнивать: linux, Firefox, Office, GIMP, vim для работы, видеоплееры фильмы смотреть, ну и всякое разное, никакой особо экзотики, локальных LLM и прочего — для этого есть сервера.

Среда — Wayfire (Wayland) и WindowMaker (Xorg), и так и так.

Железо: одноплатник Allwinner h618 со встроенным видео Mali‑G31, 4 ядра, 1.5Ггц, 4 Гб RAM, 100Мб Ethernet, USB3, HDMI.
Изначально — ТВ‑приставка на Андроиде (Z8 или вот Vontar — обе есть)

Ожидания: это примерно как запуск линукса на кофеварке — добавить ачивку «получилось», реально работать будет невозможно, но интересно попробовать.

Привет, друзья! Примерно раз в год я пишу большой пост о развитии проекта far2l — порта Far Manager под Linux, MacOS и BSD. И, должен сказать, 2025-й выдался невероятно продуктивным! Накопилось столько всего вкусного, что пора поделиться с вами очередным выпуском нашего дайджеста. Под катом — обзор двух больших и двух небольших, но очень ценных нововведений, которых мы все очень долго ждали.

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

В духе веяний времени, KDE собирается выпустить неизменяемый (immutable) дистрибутив, основанный на archlinux. Что, на мой взгляд, в очередной раз подтверждает, что KDE пережила многие другие графические оболочки не просто так. Вначале я, конечно, отнёсся к идее скептически и удивился, что её одобрили - потому что, с виду, она чрезвычайно наивная.

Но потом до меня дошло, в чём тут может быть юмор. В общем, судя по всему, разработчики KDE забьют очередную шайбу в ворота конкурентов - GNOME с их GNOME OS. Банан для названия выбран очень удачно: я помню, как какой-то художник выставил банан в качестве инсталяции современного искусства, а потом кто-то купил его за большие деньги и сразу съел. В этой статье вы найдёте "вредные советы" о том, как сделать свой дистрибутив, которые на практике могут оказаться очень даже полезными.

Фича под названием перезапускаемые последовательности была добавлена в версию ядра 4.18 в 2018 году. Она позволяет повысить производительность в определённых категориях многопоточных приложений. Притом, что кому-то перезапускаемые последовательности действительно пригодились, такой код считается достаточно специализированным — как правило, разработчики приложений этим инструментом не пользуются. Но со временем перезапускаемые последовательности выросли и, по-видимому, тренд к их росту сохраняется, так как эта фича привязана к новым возможностям, предоставляемым в ядре. Но по мере того, как перезапускаемые последовательности стало всё сложнее считать нишевой фичей, с ними стали возникать заметные проблемы. Если исправить одну из них, это может повлечь заметные изменения ABI, которые будут видимы в пользовательском пространстве.