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

Добрый день/вечер/ночь/утро! Есть один экспериментальный курс по операционным системам. Есть он в Стэнфордском университете. Но часть материалов доступно всем желающим. Помимо слайдов доступны полные описания практических занятий.

Чем этот курс отличается от прочих других? Большая часть кода пишется самостоятельно и выполняется на вполне реальном современном железе. В качестве целевой платформы выбран Raspberry Pi 3 model B. Т.е. достаточно актуальная архитектура AArch64. ARMv8 Cortex-A53, четыре ядра, 64-бита и вот это всё. В качестве основного языка программирования выбран Rust. Который безопасный, быстрый, без GC и так далее. Его, Rust, предполагается изучать во время курса.

Тут есть про диски, файловые системы, операции ввода-вывода, потоки /процессы, планирование, виртуальную память, защиту и безопасность, прерывания, параллелизм и синхронизацию. Как и в любом другом, уважающем себя курсе. Разница в актуальности материала и в количестве практики. Коддить придётся много.

   	/*
-	 * Select the list item based on the index. Negative operand means
-	 * end-based indexing (-2, ...), and -1 means out of range.
+	 * Decode end-offset index values.
   	 */
-	if (opnd < -1) {
-	    index = opnd+1 + objc;
-	} else {
-	    index = opnd;
-	}
+	index = opnd + (opnd <= TCL_INDEX_END)*(objc - 1 - TCL_INDEX_END);
   	pcAdjustment = 5;

index = opnd + cmp(opnd, (-2))==>(0 | 1) * (objc - 1 - (-2));

Как-то я сказал своему коллеге, что в Rust имеются макросы, ему показалось, что это плохо. Раньше у меня была такая же реакция, но Rust показал мне, что макросы не обязательно плохи.

Где и как их уместно применять? Смотрите под катом.

В сегодняшней статье я расскажу об уязвимостях сервера 1С в корпоративной сети.

Как показала практика, в инсталляциях с 1С все допускают одни и те же ошибки разной степени серьезности. Я не буду касаться очевидных вещей вроде установки обновлений, но пройдусь по специфике работы сервера приложений под Windows. Например, по возможности бесконтрольно манипулировать базами Microsoft SQL с помощью инструментов 1С.

Давайте познакомимся с Rust, поработав над маленьким проектом! Мы покажем основные концепты Rust на реальном примере. Вы узнаете о let, match, методах, ассоциированных функциях, подключении сторонних библиотек и много о чем другом. Мы реализуем классическую задачу: игра “угадай-ка”.

В последнее время я долго думал над персистентными коллекциями и в особенности над тем, как они относятся к Rust. Хочу поделиться с вами своими наблюдениями.

О том, как устроены персистентные векторы, быстрее ли они традиционных коллекций — смотрите под катом.

[0] Интро

Криптографический API в Linux введён с версии 2.5.45 ядра. С тех пор Crypto API оброс всеми популярными (и не только) международными стандартами:

• симметричного шифрования: AES, Blowfish, ...
• хэширования: SHA1/256/512, MD5, ...
• имитозащиты: hMAC-SHA1/256/512, hMAC-MD5, ...
• AEAD: AES-GCM, ChaCha20-Poly1305, ...
• генерации псевдослучайных чисел: FIPS, ...
• асимметричного шифрования: RSA
• согласования ключей: DH, ECDH
• сжатия: Deflate, ZLIB

Эта криптография доступна и, в основном, используется различными подсистемами ядра (в kernel space): IPsec, dm-crypt и др. Воспользоваться функциями Crypto API из пространства пользователя (user space) также возможно через Netlink-интерфейс, в который, начиная с версии 2.6.38 ядра, введено семейство _AFALG, предоставляющее доступ к криптографии ядра из user space кода. Однако, существующего функционала иногда недостаточно, таким образом появляется необходимость расширения Crypto API новыми алгоритмами.

Часто, когда я обсуждаю дизайн Rust на RFCs или на internals-форуме с другими пользователями, я замечаю характерные высказывания насчет явности. Обычно что-то в духе:

Мне не нравится <дизайн возможности X>, потому что он менее явный. Всякая магия уместна в <другом языке Y>, а Rust — это явный язык, так что следует использовать <дизайн возможности Z>.

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

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

Английский — довольно нечеткий язык, в котором прилагательные имеют множества контекстно-зависимых значений, например, как используется слово "нечеткий" (fuzzy) в предыдущем предложении. Слово "явный" тоже многозначно, так что я не могу утверждать наверняка, что кто-то неправильно использует это слово. Однако я предлагаю выражать свои мысли при обсуждении "явности" более четко, чтобы все лучше понимали, о чем именно идет речь.

«Опыт — это то, что ты получаешь только после того, как он тебе понадобится» — Стивен Райт