Программирование *

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

В апреле 2023 года, спустя несколько месяцев работы, мы, наконец, выкатили ленту Барашек и цветок. Можете сами скачать его или проследить на YouTube ход выполнения программы.

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

В этом посте я буду говорить о страничной организации только в контексте PML4 (Page Map Level 4), потому что на данный момент это доминирующая схема страничной организации x86_64 и, вероятно, останется таковой какое-то время.

Окружение

Это необязательно, но я рекомендую подготовить систему для отладки ядра Linux с QEMU + gdb. Если вы никогда этого не делали, то попробуйте такой репозиторий: easylkb (сам я им никогда не пользовался, но слышал о нём много хорошего), а если не хотите настраивать окружение самостоятельно, то подойдёт режим практики в любом из заданий по Kernel Security на pwn.college (вам нужно знать команды vm connect и vm debug).

Я рекомендую вам так поступить, потому что считаю, что самостоятельное выполнение команд вместе со мной и возможность просмотра страниц (page walk) на основании увиденного в gdb — хорошая проверка понимания.

Выберите двухразрядное число, допустим, 23. Оно будет вашим «порождающим значением» (seed).

Создайте новое двухразрядное число: количество десяток плюс шесть, умноженное на количество единиц.

Пример последовательности: 23 –> (2 + 6 * 3) = 20 –> (2 + 6 * 0) = 02 –> 12 –> 13 –> 19 –> 55 –> 35 –> …

Его период будет порядком множителя (6) в группе остатков, простых относительно модуля, 10 (в данном случае 59).

«Случайными цифрами» будет количество единиц двухразрядных чисел, то есть 3,0,2,2,3,9,5,… то есть члены последовательности mod 10.

• В правила работы с указателями и memcpy в С не заложены грамотные способы представления пустого среза памяти.
• В С++ с правилами указателей проблем нет, но поведение memcpy здесь аналогично её поведению в С.
• Интерфейс внешних функций (Foreign Function Interface, FFI) в Rust не лишён накладных издержек. Rust использует несовместимое с C/C++ представление срезов, требуя их преобразования при передаче в обоих направлениях. При этом о преобразовании очень легко забыть.
• Срезы в Rust также несовместимы с арифметикой указателей, что создаёт проблемы в работе итератора срезов стандартной библиотеки. (Обновление от 2024-01-16: похоже, над этой проблемой работают).

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

Задавались ли вы когда-нибудь вопросом, можно ли полноценно программировать при помощи директивы #define в языке C? Полнота по Тьюрингу шаблонов C++ известна весьма широко, например, люди пишут трассировщики лучей, делающие все вычисления во время компиляции (вместо времени исполнения). А как обстоят дела с препроцессором C? Вопрос оказался сильно нетривиальнее, и эта история является, на мой вкус, отличным анекдотом для курса лекций по теории компиляторов, что я готовлю в данный момент. В частности, для лучшего понимания происходящего здесь, рекомендую ознакомиться со второй статьёй, которую я опубликовал параллельно этой: лексер и парсер.

Чтобы не было обманутых впечатлений, предупрежу сразу, что рейтрейсера не будет, но про́клятый код будет очень даже! Итак, поехали. Для начала, почему я вообще задался этим вопросом? Если обычный код компьютерной графики вам скучен, следующий раздел можно пропустить, перематывайте до последней картинки.

Недавно у меня было телефонное собеседование, на котором мне задавали разнообразные вопросы по Java. Это стандартное собеседование, и большинство вопросов тоже было вполне стандартным:

Что такое полиморфизм?

В чём разница между List и Set? Когда стоит использовать первое, а когда второе?

Где можно столкнуться со взаимной блокировкой (deadlock)?

В чём разница между строгой и слабой типизацией?

В основном вопросы были вполне закономерными. Лично мне не нравится вопрос про полиморфизм, ведь он настолько тесно связан с большинством объектно-ориентированных языков и наследованием, что многие люди, используя его (например, при переопределении или перегрузке метода), даже не думают «О! Это же полиморфизм в действии!». Вместо этого я бы задал вопрос «Что такое наследование, и где оно используется», потому что в большинстве объектно-ориентированных языков для него есть ключевое слово или паттерн. Но это уже мои личные предпочтения, и я вполне понимаю логику проводившей собеседование компании.

В комментах к предыдущей части некоторые читатели предложили рассказать о ещё нескольких ЯП, которые сыграли значительную роль для развития программирования в СССР. Автор не смеет игнорировать просьбы трудящихся. В этой части цикла поговорим об АЛМО, Эль-76 и Рапира и ЛЯПАС.

Вам когда-нибудь приходилось задаваться вопросом, как работает компилятор, но так руки и не дошли разобраться? Тогда этот текст для вас. Мне тоже не доводилось заглядывать под капот, но тут так случилось, что мне нужно прочитать курс лекций о компиляторах местным третьекурсникам. Кто встречался с некомпетентными преподавателями? Здравствуйте, это я :)

Итак, чтобы самому разобраться в теме, я собираюсь написать транслятор с эзотерического языка программирования wend (сокращение от week-end), который я только что сам придумал, в обычный ассемблер. Задача уложиться в несколько сотен строк питоновского кода. Основной репозиторий живёт на гитхабе (не забудьте заглянуть в мой профиль и посмотреть другие tiny* репозитории).

В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.

Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:

«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»

Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.

Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.

Дал ему подборку книг, он приходит месяца через два, и с порога такой сразу:
— Я с друзьями не могу разговаривать.
— Ну да есть такой, недостаточек.
интервью Жака Фреско

В C и C++ есть особенности, о которых вас вряд ли спросят на собеседовании (вернее, не спросили бы до этого момента). Почему не спросят? Потому что такие аспекты имеют мало практического значения в повседневной работе или попросту малоизвестны.

Целью статьи является не освещение какой-то конкретной особенности языка или подготовка к собеседованиям, и уж тем более нет цели рассказать все потайные смыслы языка, т. к. для этого не хватит одной статьи и даже книги. Напротив, статья нужна для того, чтобы показать малоизвестные и странные решения, принятые в языках C и C++. Своего рода солянка из фактов. Вопрос “что делать с этими знаниями?” я оставляю читателю.

Если вы, как и я, любите и интересуетесь C/C++, и эти языки являются неотъемлемой частью вашей жизни, в том числе и его углубленного изучения, то эта статья для вас. По большей части я надеюсь, что эта статья сможет развлечь и заставить поработать головой. И если получится, рассказать что-то, чего вы, возможно, еще не знали.

• Безопасность типов с проверками форматирующих строк во время компиляции. Эти проверки включены по умолчанию начиная с С++ 20, и присутствуют в качестве дополнения для С++ 14/17. Форматирующие строки среды выполнения в {fmt} также оказываются безопасными, чего невозможно достичь в printf.
• Расширяемость. Определяемый пользователем тип можно сделать форматируемым. При этом большинство типов стандартных библиотек, например, контейнеры и пакеты для обработки даты и времени, предлагают возможность форматирования изначально.
• Производительность. {fmt} намного быстрее любой распространённой реализации printf, порой на несколько порядков (например, в форматировании чисел с плавающей запятой).
• Возможность переноса поддержки Unicode.

Самое страшное слово для инноватора или очень уж упёртого студента, который проходит практику у вас в компании: «Зачем?»

Знаете почему? Потому что в 80% случаев ответа вам на этот вопрос не дадут. Давайте разберёмся, причём здесь Оккам и что ему от нас нужно.

Хотя уменьшение сегодня уже необязательно, оно всё равно лучше.

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

Этот главный навык пригодится всем в индустрии — программистам, лидам, продуктологам, тестерам, менеджменту и всем остальным.

Имя ему этому навыку — здравый смысл.

Да, вот так просто, но на самом деле все совсем не просто, и я сейчас это объясню.

X11 это тот механизм на чем работает весь графический интерфейс Unix подобных ОС.

Но мало кто знает как он работает на самом деле. Потому что с годами он оброс слоями и слоями библиотек, которые стремятся скрыть саму сущность протокола.

А протокол в своей сути прекрасен. Он лаконичен и почти совершенен.

В Интернете есть полная документация по протоколу. Но дело в том, что эта документация большая, написана не совсем ясным языком и, по сути, является просто спецификацией. Важные моменты никак не обозначены, а как использовать – тоже оставлено на фантазию читателя.

А все книги и статьи по использованию X11 описывают это через библиотеки прокладки типа XLib и XCB, и даже, что хуже, GTK или Qt.

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

Как бы то ни было, если кому-то интересно как все работает на самом деле, пожалуйста под кат.