Системное программирование *

Все говорили – переходи на rust! Начинай пользоваться самым-самым языком, который самый любимый язык на stackoverflow и всё такое.

Я тяжело вздохнул и огляделся. Ну опять двадцать-пять. Ладно, давайте разбираться, как правильно покрывать всё ржавчиной.

Профессионально я программирую уже 17 лет. В далёкие-предалёкие времена я начал изучать программирование с x86 Assembly. Такой жестокий подход к изучению компьютера дал мне глубокое понимание того как работает процессор и что делают другие языки программирования. Учить новые языки для меня никогда не было проблемой. Я их просто учил. C, C++, шарпы, ГО, тысячи разных скриптов и фреймворков. Чего уж там, ещё один язык, можно и выучить.

Ага.

Только вот не с этой ржавой развалюхой. Я просидел две недели над официальным руководством, пялился в VSCode и не мог выдавить из себя больше чем fn main() {}. Ну какого же чёрта? Я просто закрыл глаза, открыл руководство на рандомной странице и начал его читать. И прикол в том, что я понял о чём там говориться. И тут до меня дошло… Руководство написано наизнанку. Начало и конец ничуть не лучше чем в Мементо Кристофера Нолана. Они как-то умудрились запутать в общем-то нормальное руководство. После этого всё пошло получше.

Ржавые шестерёнки заскрипели и начали крутиться. Программа пошла-поехала. Если хотите знать как я внедрил rust в продакшин, как я ему научился и что из этого вышло – добро пожаловать под кат. Реальные люди, коммиты, примеры и никаких todo-list и хеллоу-ворлдов.

В предыдущей заметке «Планировщик Windows? Это очень просто» было рассказано о технологии получения дизассемблированного текста ядра операционной системы Windows XP образца 2013 года. Такой текст потребовался для анализа и корректировки кода ядра, что позволило изменить политику планирования потоков в Windows и выполнить одну конкретную задачу с уменьшением времени отклика операционной системы.

После решения этой задачи я напоследок просто «полистал» текст ядра, особо не вникая, что именно делается в том или ином участке кода. Хотелось посмотреть, какие приемы локальной (т.е. в пределах 1-2 команд) оптимизации применяет использованный для создания ядра транслятор. Или, может быть, несколько трансляторов, если ядро собрано из нескольких отдельных частей. Сознаюсь, главная цель была в поиске таких приемов генерации кода, которые я не догадался использовать в своем трансляторе.

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

Хотя Windows XP и Windows 7 уже, так сказать, «сняты с вооружения», на мой взгляд, изучение даже неподдерживаемых программ имеет смысл. Ядро Windows XP сопровождалось и развивалось около 10 лет. Поэтому на основании анализа кода можно, например, даже прогнозировать пути дальнейшего развития системы. Замечу также, что различия в коде ядер различных версий Windows не так велики как различия некоторых других компонентов.

В процессе перевода своих средств программирования на платформу x86-64 потребовалось перевести и встроенный интерактивный отладчик. В отличие от подключаемых отладчиков данный отладчик находится, так сказать, непосредственно «на борту» каждой исполняемой программы. При этом он имеет сравнительно небольшие размеры (около 44 Кбайт, большую часть которых занимает дизассемблер). Я так привык к этому отладчику, что уже совершенно не могу без него обходиться, и поэтому перевод в 64-разрядную среду стал настоятельно необходимым.

Однако формальный перевод с Win32 в Win64 дал такие странные результаты, что пришлось потратить много сил и времени, чтобы разобраться, почему то, что ранее работало в Windows-XP, перестало нормально работать в Windows 7. Виной всему оказалась структурная обработка исключений, практически не задействованная ранее в среде Win32.

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

Введение

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

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

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

HashiCorp Vault — это инструмент с открытым исходным кодом, который обеспечивает безопасный и надежный способ хранения и распространения секретов, таких как ключи API, токены доступа и пароли. Программное обеспечение, такое как Vault, может быть критически важным при развертывании приложений, требующих использования секретов или конфиденциальных данных.

Реализация одной из ответственных задач моделирования в очередной раз привела к сложностям с операционной системой (ОС). Попытка решить задачу «под Windows», т.е. просто запустить программу, не применяя специальных средств, почти удалась, однако время от времени возникали недопустимые задержки. Эти, возникавшие случайно и редко (раз в несколько минут) задержки никак не удавалось убрать. Например, последовательное снятие всех «лишних» процессов Windows улучшало ситуацию, но, в конце концов, приводило к отказу самой ОС. Положение затрудняло и то, что проведение сравнительно долгого сеанса моделирования не позволяло на все 20-30 минут сеанса установить работающему потоку приоритет «реального времени», так как при этом нормальная работа компьютера нарушалась. Таким образом, несмотря на мощный и гибкий механизм планирования на основе приоритетов, потребовалось особое планирование, не предусмотренное в Windows, а именно: заданный поток в течение определенного периода не должен прерываться по истечению кванта времени, и на время его работы потоки с более низким приоритетом вообще не должны получать управление. Но при этом потоки с изначально более высоким приоритетом должны выполняться как обычно. Поскольку такие высоко приоритетные потоки обычно не занимают весь свой квант времени, время отклика для нужного потока в целом уменьшается и зависит от быстродействия компьютера.

Встал вопрос: можно ли настроить Windows на такой режим работы и как это сделать?

Это вторая часть из 2 частей Практического руководства по HashiCorp Consul. Предыдущая часть была в первую очередь сосредоточена на понимании проблем, которые решает Consul, и на том, как он их решает. Эта часть посвящена практическому применению Consul на примере реальной жизни. Давайте начнем.

Привет! Меня зовут Алексей Соколов. Я представляю компанию mail.ru. И сегодня мы с вами поговорим об Ansible.

Приветствую всех! Меня зовут Георгий. Я работаю в компании servers.com. Я пришел рассказать про Ansible: про хороший Ansible и про плохой Ansible в основном, т. е. про то, как люди могут плохо делать на Ansible.

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

Если вы установили предыдущую версию Rust средствами rustup, то для обновления до версии 1.49.0 вам достаточно выполнить следующую команду:

rustup update stable

Если у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.

Что вошло в стабильную версию 1.49.0

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

fn main() {
  println!("Hello, Rust!");
  println!("... Goodbye!");
}

Синтаксис — это первое, на что обращают внимание разработчики, впервые столкнувшись с кодом на Rust. И сложно найти что-то другое, что вызывало бы больше негодования у новичков, и при этом такое, к чему совершенно спокойно относятся уже "понюхавшие пороха" Rust-программисты. Посмотрите, например, сколько эмоций вызывает синтаксис Rust у комментаторов одной из типичных новостей про Rust на OpenNET:

2020 год. Повсюду карантин. И эта статья тоже про карантин, но он другого рода.

Я расскажу об экспериментах с карантином для динамической памяти ядра Linux. Это механизм безопасности, противодействующий использованию памяти после освобождения (use-after-free или UAF) в ядре Linux. Я также подведу итоги обсуждения моей патч-серии в списке рассылки ядра (Linux Kernel Mailing List, LKML).

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

FT4232H – это интегральная микросхема преобразователя USB – UART, поддерживающая режим High Speed на стороне USB и имеющая четыре порта на стороне UART.

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

Разберемся на примере и сконфигурируем FT4232H непосредственно в системе под управлением GNU/Linux. Делать это будем с помощью утилиты ftdi_eeprom.