Linux *

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

Цель этой книги — продемонстрировать практические приемы программирования сценариев на bash и познакомить с самыми распространенными утилитами на коротких и компактных примерах, не вдаваясь в излишние подробности. Экспериментируйте с этими сценариями — ломайте, исправляйте и приспосабливайте их под свои нужды, чтобы понять, как они работают. Только так вы сможете решать самые сложные задачи.

Так выглядела Ubuntu Touch, когда проект анонсировали 2 января 2013 года. Изображение: Canonical

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

Чтобы резюмировать моё участие в проекте: я использовал Ubuntu Touch на Nexus 7 постоянно и периодически с момента его анонса в 2013 году и до декабря 2014 года, начал работать над приложениями Click в декабре 2014-го, начал писать статью из 15-ти частей “Hacking Ubuntu Touch” об устройстве системы в январе 2015-го, был инсайдером по программе Ubuntu Phone Insider, получил Meizu MX4 от Canonical, организовал конкурс для разработчиков приложений UbuContest и был его спонсором, работал над баг-репортами и приложениями примерно до апреля 2016 года, а затем продал или переделал все мои оставшиеся устройства в середине 2016-го. Так что думаю, что могу поделиться какими-то мыслями о проекте, его проблемах и о том, где мы могли сработать лучше.

Пожалуйста, обратите внимание, что эта статья не затрагивает проект UBPorts, который продолжает работать на операционной системе телефонов, Unity 8 и другие компоненты.

Ubuntu интегрирована в Windows 10 Redstone, Visual Studio 2017 обзавелась поддержкой разработки под Linux – даже Microsoft сдает позиции в пользу растущего числа сторонников Торвальдса, а ты всё еще не знаешь тайны виртуального терминала в современных дистрибутивах?

Хочешь исправить этот пробел и открываешь исходный код? TTY, MASTER, SLAVE, N_TTY, VT, PTS, PTMX… Нагромождение понятий, виртуальных устройств и беспорядочная магия? Всё это складывается в довольно логичную картину, если вспомнить, с чего всё началось…

Представьте, что у вас имеется образ ядра Linux для телефона на базе Android, но вы не располагаете ни соответствующими исходниками, ни заголовочными файлами ядра. Представьте, что ядро имеет поддержку подгрузки модулей (к счастью), и вы хотите собрать модуль для данного ядра. Существует несколько хороших причин, почему нельзя просто собрать новое ядро из исходников и просто закончить на том (например, в собранном ядре отсутствует поддержка какого-нибудь важного устройства, вроде LCD или тачскрина). С постоянно меняющимся ABI ядра Linux и отсутствием исходников и заголовочных файлов, вы можете подумать, что окончательно зашли в тупик.

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

Но больше об этом далее.

Автор: Николай Хабаров, Embedded Expert DataArt, евангелист технологий умного дома.

В этой статье я расскажу, как написать обычное user space-приложение на Python для современного ARM-процессора с ОС Linux для генерирования сложных последовательностей импульсов на выводах платы. Суть идеи — использовать DMA-модуль процессора для копирования из предварительно подготовленного буфера в памяти в GPIO с высокой точностью по времени.

Когда речь заходит о необходимости сгенерировать сложную последовательность импульсов, например, для шаговых двигателей, обычно используют старые добрые простенькие микроконтроллеры с установленной специальной операционной системой реального времени или вообще без операционной системы. Реализация при этом, в лучшем случае, написана на C++. Сейчас процессоры шагнули далеко вперед и имеют массу преимуществ: производительность, возможность использования операционной системы Linux со всей инфраструктурой и ПО, а также высокоуровневых языков программирования, таких как Python. И все же современные микроконтроллеры для генерирования сложных последовательностей на выводах GPIO, как правило, не используют.

Я реализовал генерацию импульсов для управления шаговыми двигателями проекта PyCNC — проекта контроллера машин с ЧПУ, станков, 3D-принтеров, полностью написанного на Python и запускаемого на современном ARM-процессоре на плате Raspberry Pi.

Статья может быть полезна желающим реализовать генерацию сложных последовательностей установки уровней на выводах одного или нескольких GPIO на других высокоуровневых языках программирования, используя DMA-модули других процессоров.

У каждой российской микроэлектронной компании есть рассказ, почему она самая хорошая и передовая. По английски это называется «claim to fame» — «заявка на славу». Одни российские компании славятся оригинальной архитектурой и/или микроархитектурой CPU, другие — спроектированной в России системой на кристалле, третьи — спроектированными в России блоками, которые были лицензированы западным компаниям.

У российской компании ЭЛВИС (ELVEES), которая исторически специализировалась на космической электронике, DSP и хардверно-поддерживаемом распознавании образов, текущая «заявка на славу» выражена в совместном российско-британско-американско-тайваньском чипе для «умных камер» под названием ELISE. Инженеры в подмосковном Зеленограде спроектировали внутри этого чипа важные блоки для видео-обработки и GNSS, которые потом кросс-лицензировала британско-американская Imagination Technologies.

Блоки от элвисовцев интегрированы с тремя разнородными процессорными ядрами: двухядерным кластером суперскалярных ядер MIPS P5607 (Apache) с частотой 1.2 GHz, на котором работает Linux, процессором с аппаратно-поддерживаемой многопоточностью MIPS interAptiv (1 GHz) и небольшим вспомогательным процессором с аппаратно-поддерживаемой виртуализацией MIPS M5150 (Virtuoso).

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

На фотографиях ниже некоторые из инженеров-участников проекта. Девушка слева спроектировала часть load-store unit в MIPS P5607, юноша в зеленой майке написал модели интерфейсов шин, а товарищ в клетчатой рубашке — архитектор софтверной экосистемы:

Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности — от диспетчера задач Windows до команды top в Linux.

Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:



А на самом деле это выглядит вот так:



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

Синопсис

Не секрет, что у многих из нас остался 1 Тб свободного места на MRU-Облаке со времён его бета-теста. Объём приличный по нынешним меркам — но что с ним делать? Фотографии и своё видео туда просто так заливать не очень хочется — взломы аккаунтов случаются нередко, да и в любом случае — облако это облако, и нельзя сбрасывать со счетов тот простой факт, что любое облачное хранилище принадлежит коммерческой компании, в интересах которой использовать его для собственной выгоды. А значит, нужен дополнительный слой защиты, например, EncFS. Полистаем хабр и гитхаб, вроде бы имеется решение о шифровании данных в своём облаке. Но есть неочевидное, но весьма важное неудобство, о котором в исходной статье не упоминается — для того, чтобы синхронизироваться, нужно локально хранить 600Гб шифрованных фотографий. Для скромных локальных хранилищ, в которых и нешифрованные 600Гб фотографий едва умещаются, это слишком много.

Многим сисадминам, которые работают с SCCM, хотелось бы иметь возможность управлять не только Windows компьютерами, но заодно и Mаками. С данной задачей поможет справиться наш продукт — Parallels Mac Management (PMM). Фактически, это расширение для системы SCCM, позволяющее управлять Maками из знакомой консоли System Center, пользуясь уже сложившимися практиками. На стороне Mac работает наш клиент под root’ом, что позволяет администрировать систему в полном объеме. Под катом рассказ нашего тим-лида Тимофея Фуряева об основных трудностях, с которыми мы столкнулись при разработке PMM.

Порой кажется, что на фронте борьбы с проблемой 2038 года наступило относительное затишье. Однако время идет, и тот день, когда 32-битные значения типа time_t больше не смогут корректно отображать даты, наступит уже меньше чем через 21 год. Этот срок может показаться большим, однако сравнительно долгий жизненный цикл многих встраиваемых систем подразумевает, что некоторые из них, будучи введенными в строй в наше время, все еще будут работать, когда наступит критический момент. Арнд Бергманн — один из основных разработчиков, занимающихся этой проблемой. На конференции Linaro Connect 2017 он поделился новостями о текущем положении дел в этой области.

Сразу скажу, что статья пишется вовсе не для того, чтобы показать, что статический анализ работает лучше, чем динамический. Такое утверждение будет неверным, так же, как и обратное. Инструменты статического и динамического анализа дополняют друг друга, а не конкурируют между собой. У тех, и у тех есть сильные и слабые стороны. Некоторые ошибки не могут обнаруживать динамические анализаторы, а некоторые — не могут найти статические. Поэтому, следует отнестись к этой заметке просто, как к очередной демонстрации возможностей PVS-Studio, а не как к сравнению двух методологий.

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

Также будут рассмотрены несколько специфичных для антропоморфных роботов пакетов. Любой робот (наверняка даже машинка со средне-мощным бортовым ПК под управлением Linux и парой веб камер) наверняка найдет здесь что — нибудь для себя.

Паранойя не лечится! Но и не преследуется по закону. Поэтому в Linux Kernel 4.1 добавлена поддержка шифрования файловой системы ext4 на уровне отдельных файлов и директорий. Зашифровать можно только пустую директорию. Все файлы, которые будут созданы в такой директории, также будут зашифрованы. Шифруются только имена файлов и содержимое, метаданные не шифруются, inline data (когда данные файла, не превышающие по размеру 60 байт, хранятся в айноде) в файлах не поддерживается. Поскольку расшифровка содержимого файла выполняется непосредственно в памяти, шифрование доступно только в том случае, когда размер кластера совпадает с PAGE_SIZE, т.е. равен 4К.

Недавно мы применили плату Ethond в качестве мини-роутера и запустили на нём OpenVPN.

Но обнаружилось, что процессор часто нагружается на 100%, а скорость не поднимается выше 15-16 Мбит/с. На канале связи 100 мегабит это очень мало, поэтому мы решили ускорить процесс аппаратно.

Ребята из группы FPGA-разработчиков сделали прошивку на базе открытого IP-core для Altera CycloneV с реализацией шифра AES-128, которая умеет шифровать 8 Гбит/сек и дешифровать 700 Мбит/сек. Для сравнения, программа openssl на CPU (ARM Cortex A9) того же CycloneV может обрабатывать лишь около 160 Мбит/сек.

Эта статья посвящена нашему исследованию по применению аппаратного шифрования AES. Мы сжато представим описание криптографической инфраструктуры в Linux и опишем драйвер (исходный код открыт и доступен на github), который осуществляет обмен между FPGA и ядром. Реализация шифрования на FPGA не является темой статьи — мы описываем лишь интерфейс, с которым происходит взаимодействие c акселератором со стороны процессора.

Кадр из фильма «Матрица: Революция»

В этой статье мы подробно рассмотрим детали одной интересной находки: два часто используемых системных вызова (gettimeofday, clock_gettime) в AWS EC2 выполняются очень медленно.

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

Два вышеназванных системных вызова не могут использовать vDSO (virtual Dynamic Shared Object) в AWS EC2, поскольку виртуализированный источник временных меток (virtualized clock source) в xen (и некоторых конфигурациях kvm) не поддерживает получение информации о времени через vDSO.

Обойти эту проблему не получится. Можно поменять источник информации о времени на tsc, но это небезопасно. Далее мы рассмотрим вопрос более подробно и проведем сравнительное тестирование с помощью microbenchmark.

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

В этой статье мы познакомимся с POSIX Threads для того, чтобы затем узнать как это все работает в Linux. Не заходя в дебри синхронизации и сигналов, рассмотрим основные элементы Pthreads. Итак, под капотом потоки.

Тензор уже более 20 лет работает на рынке программного обеспечения. Бухгалтер, который выдает вам зарплату, точно знает, кто мы, и что мы делаем. А вот в IT-сфере мы о себе специально не заявляли. Пришло время это изменить и познакомиться.

Электронная отчетность, электронный документооборот, поиск и анализ закупок, корпоративная соцсеть, видеокоммуникации, управление персоналом – это лишь часть наших сервисов. Мы автоматизируем рабочие процессы и превращаем их в «несколько кликов».

Работать в СБИС можно офлайн, онлайн и в мобильном приложении.

Не будем грузить вас рассказами о нашем продукте. Если интересно, то вот здесь мы в буковках и картинках рассказали о нем все.

Почему мы – интересные и полезные?

Для разработки своих продуктов (online сервисов, desktop и мобильных приложений) мы используем собственный PaaS-фреймворк.

Backend фреймворк мы пишем на С++, при этом прикладной код можно писать как на С++, так и на Python или Javascript, для этого ко всем встроенным типам сделаны bridges. Помимо встроенных типов и системы вызовов (remoting, IPC, inproc), важной частью фреймворка является сервер приложения, который работает быстрее сервера Node.JS на аналогичном железе, но об этом чуть позже в отдельной статье.

При разработке очередного бота для группы в Telegram у меня возникла необходимость испытать его при различных значениях системного времени. Этот бот в конце каждого дня отправляет (или, в зависимости от ряда условий, не отправляет) сообщение в чат и производит манипуляции с некоторыми предыдущими своими сообщениями (или, опять же, не производит).

Менять системное время глобально ой, как не хотелось. Муторно, плюс у меня в ней столько всего понаставлено, не дай Б-г что-то заглючит (вряд ли, но мало ли). Думал запустить VirtualBox, но уж больно лень было ставить «чистую» Убунту, расшаривать папки, и т. д., тем более что этот вариант жрёт, как троглодит серьёзно потребляет машинные ресурсы.

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

Пришло время вновь проверить проект FreeBSD и продемонстрировать, что даже в таких серьезных и качественных проектах анализатор PVS-Studio легко находит ошибки. В этот раз я решил взглянуть на поиск ошибок с точки зрения обнаружения потенциальных уязвимостей. Анализатор PVS-Studio всегда умел выявлять дефекты, которые потенциально можно использовать для атаки. Но мы никогда не акцентировали на этом внимание и описывали ошибки как опечатки, последствия неудачного Copy-Paste и так далее, и не классифицировали их, например, согласно CWE. Сейчас очень популярно говорить и о безопасности, и об уязвимостях, поэтому попробую немного расширить ваше восприятие нашего анализатора. PVS-Studio — это не только поиск багов, но ещё и инструмент, повышающий безопасность кода.