Linux *

Прошел ровно год с момента, когда мир с открытым ртом следил за расследованием одного из самых изощрённых бэкдоров в истории Linux. История с библиотекой xz Utils напоминала триллер: внедрение под реальным именем, доверие сообщества, закладки в коде — и случайное обнаружение в самый обычный рабочий день.

29 марта 2024 года программист Андрес Фройнд проснулся, как обычно, рано. На кухне уже фыркала кофемашина, а ноутбук мигал знакомым индикатором обновлений. Андрес любил утренние часы: пока город только-только просыпался, он уже погружался в привычную рутину — тесты, логи, графики загрузки процессора.

Утром он запустил стандартный набор тестов. Всё выглядело штатно: графики ровные, CPU не перегружен, багов не видно. И вдруг — странность. Незначительная ошибка, но не из тех, что просто игнорируешь. Андрес нахмурился. «Что это было?» — пробормотал он. Он подключился по SSH к серверу, чтобы проверить детали, и заметил ещё одно отклонение: задержка отклика в 500 миллисекунд. Полсекунды. Для большинства — ерунда. Но для Андреса — первый тревожный звонок. Он начал копать глубже.

Не так давно ко мне в руки попала игровая ретро-консоль и у меня возникло желание написать для неё свою игру. А возникало ли у вас желание написать свою игру под игровую консоль?

Сколько себя помню, меня всегда привлекали счётчики памяти в Linux: смотришь в условный htop – в плане потребления CPU вроде всё +/- понятно, а вот память всегда считалась как-то не так, как ты это на первый взгляд ожидаешь, и долгое время у меня было довольно наивное и ошибочное представление о механизмах её работы.

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

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

Есть множество сервисов и программ по сборке программных пакетов: OpenSuse Build Service (OBS), koji. Fedora copr, rpmbuild, mock.

Все они позволяют организовать сборку программных пакетов, релиз пакетов в репозиторий и пр. Большинство систем обладают обширным функционалом, например тот же OBS позволяет собирать как deb пакеты, так и rpm, так и AppImage и т. д. Koji позволяет разбить сборку по разным машинам и управляя билдерами организовать сборку огромного числа тяжелых пакетов, многие комплексы типа OBS и Copr вообще организованы в виде сервисов в сети и позволяют различным пользователям собирать пакеты и публиковать их в публичных репозиториях.

Зачем же еще понадобилось дополнительное средство по организации сборки rpm пакетов и репозиториев?

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

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

Поскольку прошлая статья про «особенную» Java вызвала интерес, мы решили продолжить праздник. Настало время познакомить разработчиков С# с темной стороной любимой технологии — сегодня шатаем .NET!

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

Меня зовут Ростислав, я эксперт по разработке ПО отдела систем обработки данных в YADRO. Расскажу о вкладе нашей команды в разработку TATLIN.BACKUP: как мы с нуля создали дедуплицирующую файловую систему, а также какие вызовы преодолели за два года разработки и 200 тысяч строк кода.

В последнем обновлении нашей кроссплатформенной библиотеки EMX Controls для Avalonia UI мы существенно повысили производительность контролов DataGrid и TreeList. Время создания и отрисовки улучшилось почти в 3 раза, а скорость скроллинга - более чем в 2 раза. В этой статье мы приведем конкретные цифры и подробнее остановимся на подходах, которые позволили нам добиться таких результатов.

Работая над проектом «SVG-виджеты для tckl/tk», я с нетерпением ждал выхода не только релиза Tcl/Tk-9.0, но и выхода интерпретатора tclexecomp с его поддержкой. Релиз Tcl/Tk-9.0 появился в сентябре 2024 года, когда работа над проектом приближалась к завершению. После выхода релиза Tcl/Tk-9.0.0, сразу же появилось желание протестировать свой проект с новым интерпретатором, но я решил дождаться появления и интерпретатора tclexecomp с поддержкой нового релиза Tcl/Tk.
Время шло, на Хабре была выложена финальная статья про svg-виджеты, а tclexecomp на базе Tcl/Tk-9.0 так и не появлялся. В настоящее время уже вышел второй релиз, а именно Tcl/Tk-9.0.1. И тогда было решено воспользоваться советом Ивана Владимировича Мичурина:

Привет! С вами Станислав Ермохин, руководитель группы методического обеспечения в команде КОМПАС-3D. Мы продолжает разработку КОМПАС-3D под ОС на базе ядра Linux. Релиз, который состоится в этом году, все ближе и ближе. Правда, пока нам есть над чем работать, но система уже находится в наиболее стабильном состоянии, когда можно производить нагрузочное тестирование. Окончательными результатами тестирования мы поделимся чуть позже, добавив к ним результаты тестирования от наших пользователей после бета-тестирования.

Привет, меня зовут Андрей, и я написал книгу.

Нет, не о синтаксисе и не про очередной набор «лучших практик».
А о том, что часто остаётся за кадром — в рефлексии, в мыслях после проектов, в спорах между «пишем быстро» и «делаем правильно».

24 марта 2025 года Линус Торвальдс представил первый стабильный релиз ядра Linux 6.14. Выпуск новой версии ядра Linux вышел в соответствии с графиком, спустя два месяца после выхода предыдущей стабильной версии Linux 6.13 в середине января. Выпуск Linux 6.15 ожидается в конце мая или начале июня 2025 года.

Сергей Каличев, старший разработчик, Angie Software

Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR. С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet, а оригинал только в архиве Интернета. Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок.

Для тех, кому удобнее читать в PDF, вот ссылки:

PDF оригинальной статьи

PDF перевода

А теперь сама статья.

Думаю, кто читает эту статью, сталкиваются с проблемой драйверов для
внешних устройств, в частности Wi-Fi адаптеров, таких как Alfa, TP-Link и других на
чипсетах RTL. Здесь я опишу принципы компиляции ядер Samsung с использованием
системы сборки Soong для Android-устройств, а также расскажу, как подготовить среду
для компиляции и сборки ядра. Кроме того, я опишу, как скомпилировать внешние модули ядра aircrack-ng для мобильных устройств.

MIK32 АМУР или K1948ВК018 является российским микроконтроллером (МК) с ядром на открытой архитектуре RISC‑V. По какой‑то причине производитель МК ГК «Микрон» предлагает в качестве средства разработки,‑ средство на базе Eclipse, но исключительно под Windows, что далеко не всех устраивает. А также, в руководстве по эксплуатации на данный МК, предлагается использовать VS Code, и это конечно более универсальный (кроссплатформеный) вариант, но предполагает использование VS Code совместно с плагином PlatformIO, что опять же устраивает далеко не всех. Поэтому я рассмотрю в данном руководстве старт работы с отладочной платой MIK32-DIP в ОС GNU/Linux в IDE Eclipse.

Чтобы начать работу вам понадобятся:

Если вы хотите узнать, готов ли RISC-V к мобильным устройствам, как развивается экосистема открытого ПО и какие перспективы ждут технологию в России, то у вас есть планы на пятницу! 14 марта в 19:00 пройдет новый митап российского Альянса RISC-V — независимого объединения разработчиков вычислительной техники и программного обеспечения на основе открытой архитектуры. 

Участники события, организованного совместно с YADRO, узнают о новейших тенденциях в экосистеме программного обеспечения для RISC-V, обсудят развитие технологий и смогут задать вопросы экспертам. Регистрируйтесь на митап, чтобы подключиться онлайн и быть в курсе развития экосистемы RISC-V в России.

Ноутбук засыпает, ноутбук просыпается, батарея «зависает» — более не отдает ни уровень заряда ни другие показатели, вне зависимости от подключения к сети.

Патч ядра Linux и три года изысканий, рассказываю как это было.