Разработка под Linux

Первая часть интервью.

Распределенная система контроля версий Git

Дж.А.: Linux – только первая из ваших работ, глобально повлиявших на мир опенсорса. В 2005 году вы также создали Git, исключительно популярную распределенную систему контроля версий. Вы быстро перенесли дерево исходников ядра Linux из проприетарного хранилища Bitkeeper в новоиспеченный Git, который сделали опенсорсным, и в том же году передали поддержку Git Джунио Хамано. История этих событий увлекательна, расскажите, что побудило вас передать этот проект так быстро, и как вы нашли и выбрали Джунио? 

ЛТ: Итак, ответ на этот вопрос состоит из двух частей.


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

Инфраструктура открытых ключей (PKI/ИОК) включает в себя множество различных объектов и механизмов работы с ними, а также протоколы взаимодействия объектов друг с другом (например, протоколы TLS, OCSP). В число объектов ИОК входят запросы на сертификаты (PKCS#10) и сами сертификаты x509, ключевые пары (приватные и публичные ключи), подписанные и зашифрованные документы (PKCS#7, CMS), защищенные контейнеры для хранения приватных ключей (PKCS#8) и личных сертификатов с ключами (PKCS#12) и т.д. В число механизмов входят не только криптографические функции, которые позволяют шифровать и подписывать документы по различным алгоритмам, но и функции, формирующие конечные объекты ИОК в соответствии со стандартами (сертификаты, запросы, подписанные/зашифрованные документы, пакеты протоколов и т.д. и т.п.). Да, и как не вспомнить центральный объект ИОК/PKI — УЦ.

Сегодня уже трудно представить деловую жизнь страны без ИОК, без сертификатов x509 (без квалифицированных сертификатов), без сервисов ГОСУСЛУГИ и ФНС, где документы принимаются в электронном виде с электронной подписью. И все больше документов возвращаются к гражданину тоже в электронном виде с электронной подписью. Судопроизводство уже также не возможно представить без электронной подписи.

Тридцать лет назад Линусу Торвальдсу был 21 год, он был студентом Хельсинского университета. Именно тогда он впервые выпустил ядро Linux. Анонс этого события начинался так: «Я делаю (свободную) операционную систему (просто в качестве хобби, большой и профессиональной она не будет…)». Три десятилетия спустя все топ-500 суперкомпьютеров в мире работают под Linux, равно как и более 70% всех смартфонов. Linux явно стал и большим, и профессиональным. 

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

Если вы не знакомы с первой частью, советую сначала ознакомиться с ней:
Свой личный SMS-шлюз. Часть 1 – цели, задачи, сборка и тестирование

Прошлое

Начнем с составления краткого списка основных причин неудач линуксфонных проектов:

• Openmoko: Финансовые вопросы,
• Nokia (Maemo/Meego): Изменение корпоративной стратегии (новый генеральный директор),
• HP (WebOS): Изменение корпоративной стратегии (новый генеральный директор),
• Mozilla (Firefox OS): Изменение «Корпоративной» стратегии (смещение фокуса на IOT),
• Canonical (Ubuntu Touch): Изменение корпоративной стратегии (смещение фокуса на облако и прибыльность).

Это, конечно, сильное упрощение и я признаю, что реальная история в каждом случае намного сложнее. Кроме того, трудно сравнивать нынешних игроков, PINE64 и Purism (и большое разнообразие комьюнити-проектов), с компаниями размером с Nokia, HP или даже Mozilla, или Canonical. Сравнение с Openmoko, скорее всего, работает лучше всего.

Широко известен исторический анекдот о том, что царица Екатерина II писала простое русское слово из 3 букв с 4 ошибками. Куда менее известно, что эта ошибка вовсе не уникальна. Дети европейских экспатов, изучающие русский язык, запросто могут в диктанте слово “ёжик” написать как Й-О-Ш-Е-Г.

LV2 - это открытый стандарт для создания плагинов звуковых эффектов. Считается, что он предназначен прежде всего для ОС Linux, хотя не существует никаких ограничений, мешающих использовать его на других системах. До этого в линуксе уже существовало два подобных стандарта - LADSPA и DSSI. Первый из них предназначался в основном для обработки звуковых сигналов и практически не мог работать с MIDI-данными. Второй же наоборот, задумывался как стандарт для виртуальных синтезаторов.

Само название LV2 - это сокращение от LADSPA version 2, он является новой, улучшенной версией стандарта. В отличие от своих предшественников, он позволяет обрабатывать аудиоданные, midi-потоки, создавать любой пользовательский интерфейс и обмениваться любыми данными с приложением-хостом. Стандарт также поддерживает механизм расширений. Благодаря этому LV2 может предложить ряд дополнительных возможностей: набор «заводских» предустановок, сохранение состояния, логирование. В теории, пользователь может создавать свои собственные дополнения. Подробная документация с примерами располагается по адресу http://lv2plug.in

Представляю вам цикл статей по созданию собственного шлюза для отправки SMS-сообщений.
В первой части мы определим цели и некоторые аспекты использования своего шлюза, настроим программное обеспечение для отправки SMS с использованием USB-модемов, а также рассмотрим несколько интересных вариантов отправки

Ровно два года назад, в апреле 2019 года, произошло знаменательное событие для всех сторонников свободного и открытого ПО, которые следят за Российскими новостями. АО «МЦСТ» "опубликовало" ОС Эльбрус для свободного скачивания. И несмотря на некоторые сложности в самом начале из-за возникшего ажиотажа, этот дистрибутив остается в свободном доступе по сей день и даже продолжает периодически обновляться.

На текущий момент доступны для скачивания версии «Эльбрус Линукс» 6.0.0 на базе ядра Linux 5.4 и версии 5.0-rc3 и 4.0.4 на базе ядра Linux 4.9.



Я специально написал слово «опубликован» в кавычках, т.к. на тот момент исходные тексты дистрибутива Эльбрус Линукс в свободном доступе отсутствовали. Два года назад в разговоре с CNews директор по маркетингу МЦСТ Константин Трушкин сообщил, что

… исходные коды на продукты компании пока недоступны ни для самостоятельного скачивания, ни по запросу, но в скором времени компания намерена их открыть.

Разные пакеты ПО выпускались МЦСТ под различными открытыми лицензиями, и под ними же будет происходить распространение исходных кодов.

Раскрывая исходные коды, компания преследует маркетинговые цели, связанные с продвижением продуктов МЦСТ, а также стремится расширить комьюнити разработчиков ПО под ОС «Эльбрус».

Под конец и без того нелегкого 2020 года Red Hat преподнесла всем поклонникам CentOS весьма неожиданный «подарок», объявив о радикальном сокращении EOL восьмой версии дистрибутива и последующем отказе от дальнейшего развития проекта. Пользователи операционной системы, на протяжении многих лет занимавшей третье место по популярности в мире, оказались на распутье. Что выбрать в такой ситуации? Стать «вечным бета-тестером», перейдя на CentOS Stream? Выделить бюджет на покупку лицензии Red Hat Enterprise Linux? Или быть может попробовать одно из конкурирующих решений?

В первой части этого цикла статей мы рассмотрели теорию, стоящую за одновременным доступом в моделях памяти, а также применение этой теории к простым чтениям и записям в память. Правда, этих примитивов оказывается недостаточны для построения высокоуровневых механизмов синхронизации вроде спинлоков, мьютексов и условных переменных. Хоть и полные барьеры памяти позволяют синхронизировать потоки с помощью приёмов, рассмотренных в предыдущей части (алгоритм Деккера), современные процессоры позволяют получить нужный эффект проще, быстрее и гибче — да, всё сразу! — с помощью операций compare-and-swap.

Для программистов ядра Linux операция обмена compare-and-swap выглядит так:

    T cmpxchg(T *ptr, T old, T new);

где T может быть либо числовым типом не больше указателя, либо указателем на что-нибудь. Так как в C нет обобщённых функций, то подобный полиморфизм реализуется макросами. cmpxchg() — это очень аккуратно реализованный макрос, который ведёт себя как функция (например, вычисляет аргументы только один раз). В Linux также есть макрос cmpxchg64(), который работает с 64-битными целыми числами и недоступен на 32-битных платформах.

cmpxchg() читает значение по указателю *ptr и, если оно равно old, то заменяет его на new. Иначе же после чтения ничего не происходит. Считанное значение возвращается как результат операции, независимо от того, произошла ли запись. И всё это выполняется атомарно: если другой поток одновременно с cmpxchg() записывает что-то по адресу *ptr, то cmpxchg() ничего не меняет. Либо old становится new, либо текущее значение остаётся нетронутым. Поэтому cmpxchg() называют атомарной операцией read-modify-write.

В этом посте я расскажу о простом блокноте на языке программирования Vala. Программа создавалась с использованием среды разработки GNOME Builder и редактора интерфейсов Glade.

Пользователь с Reddit под ником mathisweirdaf поделился интересными наблюдениями:

 $ ls -lh /usr/bin/{test,[}
-rwxr-xr-x 1 root root 59K  Sep  5  2019 '/usr/bin/['
-rwxr-xr-x 1 root root 55K  Sep  5  2019  /usr/bin/test

[ и test должны быть псевдонимами друг друга, и все же между исполняющими их файлами из GNU coreutils наблюдается разница в 4Кб. Почему?

tl;dr: форматы файлов Netpbm позволяют легко выводить пиксели, используя только текстовый ввод-вывод.

Вот весь генерирующий это изображение скрипт bash без зависимостей:

#!/bin/bash
exec > my_image.ppm    # Все инструкции echo будут писать в этот файл
echo "P3 250 250 255"  # формат, ширина, высота, максимальное значение цвета
for ((y=0; y<250; y++)) {
  for ((x=0; x<250; x++)) {
    echo "$((x^y)) $((x^y)) $((x|y))" # r, g, b
  }
}

Я недавно писал об опции -exec команды find и ненароком упомянул о «семействе системных вызовов exec()». Это — странное выражение, обычно о Unix-вызовах так не говорят, так как они, как правило, не объединяются в некие «семейства». Но в данном случае речь идёт о целом наборе схожих механизмов. Перечислим их:

execv() execve() execvp() execvpe()
execl() execlp() execle()

(Этот список выглядит именно так в Linux и в OpenBSD; подобный список, составленный для FreeBSD, включал бы в себя execvP(), а не execvpe(). В POSIX-версии подобного списка нет вызова execvpe(), но есть вызов fexecve(), который я не вполне готов включить в семейство вызовов exec().)

Подумываете ли вы о том, чтобы использовать Red Hat CodeReady Containers (CRC) для решения задач локальной OpenShift-разработки? Собираетесь ли устанавливать CRC на Linux? В этом материале я хочу рассказать именно об этом. Мы обсудим некоторые особенности работы CRC и поговорим о настройке контейнеров.



Тут используется система CRC версии 1.21.0, в основе которой лежит OpenShift Container Platform (OCP) версии 4.6.9. Я устанавливаю CRC на Debian 10 GNU/Linux, но нам подойдёт любой современный дистрибутив Linux — вроде Fedora или Ubuntu. CRC 1.21.0 можно установить на Linux-хосте, который удовлетворяет следующим требованиям:

• На нём установлены KVM и libvirt.
• Его сетевые настройки выполняются с использованием NetworkManager.
• Пользователь, устанавливающий CRC, имеет sudo-доступ к этому хосту.

Перед установкой CRC нужно будет загрузить tarball-дистрибутив CRC и так называемый «pull secret». «Pull secret» — это JSON-файл, который содержит аутентификационную информацию, необходимую для доступа к защищённым реестрам образов, поддерживаемым Red Hat. Если вы не являетесь клиентом Red Hat — вы можете присоединиться к Red Hat Developer Program, к программе Red Hat для разработчиков, и бесплатно загрузить этот файл. Участие в этой программе позволяет, кроме того, загрузить tarball-дистрибутив CRC. А отсюда дистрибутив можно скачать без лишних формальностей.

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

Недавно мы успешно портировали фреймворк Flutter на ТВ-приставку c открытой программной платформой RDK. В этой статье расскажем о трудностях, с которыми пришлось столкнуться, и предложим решения для успешного запуска и повышения производительности. 

Учитывая, что программный стек RDK или Reference Design Kit сейчас активно используется для разработки OTT-приложений, голосового управления и других продвинутых функций для «видео по запросу» (VoD), мы хотели разобраться, сможет ли Flutter работать на ТВ-приставке. Оказалось, что да, но, как это обычно бывает, есть нюансы.

Далее мы по шагам распишем процесс портирования и запуска Flutter на встраиваемых Linux-платформах и разберемся, как этот SDK с открытым исходным кодом от Google чувствует себя на «железе» с ограниченными ресурсами и ARM-процессорами.

В прошлом году разработчики ядра Linux предложили использовать Rust для нового встроенного кода. В марте 2021 года эта идея была частично реализована — в состав ветки linux-next, на которой будет базироваться Linux 5.13, включили начальный набор компонентов для разработки драйверов устройств на Rust.

Тогда же была опубликована документация по использованию Rust в ядре Linux с практическими примерами. Изначально Торвальдс не выступал резко против нововведений (не делает этого он и сейчас). Заявил лишь, что нужно проверить, как все эти новинки работают на практике. Сейчас Линус Торвальдс провел рецензирование патчей с реализацией возможности создания драйверов на Rust для Linux и высказал ряд критических замечаний.

В одном из наших проектов используется Edge-модуль, работающий на широком наборе оборудования c процессором ARM, типа Raspberry Pi. Данное устройство используется для того, чтобы пересылать медиа-данные посредством зашифрованного канала на сервер.

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

В новом выпуске systemd v221 мы представляем API sd-bus, поставляемый со стабильной версией systemd. sd-bus - это наша минимальная библиотека D-Bus IPC на языке программирования Си, поддерживающая в качестве бэкэндов как классическую D-Bus на основе сокетов, так и kdbus. Библиотека была частью systemd в течение некоторого времени, но использовалась только внутри проекта, поскольку мы хотели свободно вносить изменения в API, не затрагивая внешних пользователей. Однако теперь, начиная с v221, мы уверены, что сделали стабильный API.

В этом посте я предоставляю обзор библиотеки sd-bus, краткое повторение основ D-Bus и его концепций, а также несколько простых примеров того, как писать клиенты и сервисы D-Bus с её помощью.