Trail of Bits на грант от DARPA запилили исследование тулинга вокруг Clang

Выглядит оно увлекательно (все врут)

The Clang AST is a lie
The Clang CFG is a (pretty good) lie
LLVM IR as the one true IR is a lie
Encore: the lib in libClang is a lie
Encore the second: compile_commands.json is a lie
Final encore: Compilers textbooks are lying to you (sort of)

На самом деле есть вопросы к посту, потому что в конце они рассказывают про свой тулинг (возможно, пост специально написан в таком ключе), но почитать всё равно интересно.

Тулинг от ToB

VAST is an experimental compiler pipeline designed for program analysis of C and C++
https://github.com/trailofbits/vast

Peter's Amazing Syntax Tree Analyzer
https://github.com/trailofbits/pasta

Полностью по ссылке

The future of Clang-based tooling
https://blog.trailofbits.com/2023/07/28/the-future-of-clang-based-tooling/

До сих пор тестовые выпуски Asahi Linux базировались на пакетной базе Arch Linux. 
. . .
Переход обусловлен тем, что Fedora Linux имеет официальную поддержку ARM64 в upstream ветке. Кроме того, переход поможет команде Asahi Linux сфокусировать усилия на обратном инжиниринге оборудования, в то время как Fedora Asahi будет заниматься поддержкой дистрибутива. Также миграция на Fedora позволит разработчикам Asahi Linux напрямую взаимодействовать с сопровождающими upstream репозиториев Fedora для исправления проблем в сборках ПО.

Проект Asahi переводит свой дистрибутив для ARM-чипов Apple на Fedora Linux
https://www.opennet.ru/opennews/art.shtml?num=59545

Я тут решил разобраться с тем как работает cloud-init чтобы найти хоть какие-то спецификации для конфигурации. Забегая вперёд скажу - их нет. С архитектурной точки зрения это просто какой-то ужас. Но что-то откопать таки удалось.

Начнём с того что cloud-init поддерживает большое количество датасорсов, там и OpenStack, и OpenNebula, и AWS, и Azure, и Google Cloud, и всё такое…

Все они собираются в единую структуру - instance metadata, которая слава богу имеет стандартизированную спеку. Её можно использовать в скриптах и темплейтах, но передать её напрямую ни через один датасорс нельзя.

Что же из себя представляет датасорс? Как правило это метод получения конфигурации из облака, который, в зависимости от облака в котором работает, превращает метаданные облака в instance metadata. Меня интересовали в первую очередь форматы OpenStack configDrive и NoCloud, которые позволяют передавать метаданные инстанса через ISO или файловую систему со специально определённый лейбл.

И тут начинается самое весёлое, так как единого стандарта нет, но есть некоторые негласные соглашения. А именно, что данные передаются в виде четырёх структур: meta-data, user-data, vendor-data и network-config (именование может быть разное, но суть примерно одна)

- meta-data - более-менее общий для всех клаудов, в нём чаще всего передают instance-id, local-hostname и public-keys для ssh.
- user-data - позволяет принимать в себя cloud-config структуру, которая тоже не стандартизирована, но тоже имеет общепринятые поля, либо вообще может быть чем угодно, например баш-скриптом, jinja-темплейтом для cloud-config’а или скрипта, так и конкатенировать в себя всё вышеперечисленное.
- vendor-data - тоже самое что и user-data, но по логике предоставляется вендором, а не пользователем
- network-config - у разных вендоров разный, но в NoCloud он более-менее стандартизирован и представляет собой конфиг netplan в чистом виде.

https://fuckjava.com

Подглядел в одном из закрытых чатов.

🫡

EXCLUSIVE: Hacking tool Flipper Zero tracked by intelligence agencies, which fear white nationalists may deploy it against power grid

Racially and ethnically motivated violent extremists may seek to exploit the hacking capabilities of a new cyber penetration tester.

https://www.dailydot.com/debug/flipper-zero-racially-motivated-extremists-fusion-center-alert-nypd/

Я и сам стараюсь следить за его развитием, но что-то писать на нём полноценное не довелось ни разу.

 Сам язык Zig имеет ряд интересных решений, которые выделяют его на фоне других «убийц» языка C. Коротко:

- встроенная система сборки;

- прямое использование заголовочных файлов написанных на C;

- компиляция кода написанного на C компилятором Zig;

- выполнение comptime кода во время компиляции;

- механизм аллокации памяти с возможностью выбора аллокатора;

- и другие.
. . .
А почему не Rust?

На этот вопрос я специально оставил ответ на конец. И ответ банален и прост. Rust не замена C. Вообще. Это не значит, что его нельзя использовать вместо C. Отнюдь. И даже совместно можно. Но не так, как можно С совмещать с Zig. Одна из киллер фитч языка Zig, возможность напрямую взаимодействовать с кодом языка C. Хотя Zig в этом не уникален. Есть ряд других языков (C2, C3, V, Vox, и ещё несколько языков, названия которых я забыл), которые делаю практически то же самое, что и Zig. Пытаются заменить C, как язык системного программирования и межпрограммного использования библиотек. В языке Zig взаимодействие с языком C работает в обе стороны. То есть можно написать библиотеку на Zig, соблюдая некоторые правила, которую можно будет использовать в проекте написаном на C, или на другом языке, где можно подгружать библиотеки написанные на C.

Zig для меня — это новый C
https://habr.com/ru/articles/753078/

Чаты в телеге
@ziglang_ru
@zig_ru

rust is elegant they say

https://github.com/rust-lang/rust/blob/master/compiler/rustc_error_codes/src/error_codes.rs#L10

Успешные плюс в чат

Заколоченные окна:
Microsoft с 30 сентября перестанет продлевать лицензии российским компаниям

Risen (tribute to Terry A. Davis)

orig: https://www.youtube.com/watch?v=DmV49ogMDEI

Всё ещё мучаюсь вопросом как решить проблему прогона тестов bash под MacOS не используя MacOS. На днях нашёл очень перспективное, на первый взгляд, решение.

Но нужно чуть подробностей, поэтому, начну по порядку.

А что расходится?

1. Вот лично у меня одна из вечных проблем: sed. Поведение GNU sed и BSD sed расходится. Есть трюки, которые позволяют их сделать похожими вплоть до идентичности. Например, опция -E. Она _почти_ всегда даёт одинаковый результат в обоих реализациях. Хороший совет для себя самого: всегда использовать эту опцию. Она, кстати, и выражения позволяет немного проще писать. Но всё равно, я не верю в 100% сходство. Без тестов на целевой платформе я такое выпускать боюсь.

2. Вот недавно напоролся на немного разную работу bash. К сожалению, не могу здесь привести подробностей. Но казалось, что в конструкции типа такого:

xargs -I% bash -c "func \"%\" \"${arg2}\"

символ % не подставляется. Было очень странно и непонятно.

Как можно решить мою проблему?

Ну часть решений я писал выше.

Сейчас чуть подробнее про новое найденное мною: https://chimera-linux.org

Что они говорят:

Chimera uses a novel combination of core tools from FreeBSD, the LLVM toolchain, and the Musl C library, delivering a fresh experience with several major benefits.

Кажется, что это то, что надо!

ну то есть, я хотел:

BSD userland утилиты, которые можно собрать напротив glibc+linux... 

но musl мне тоже ОК.

Дополнительные плюсы:
* apk как пакетный менеджер.

Минусы:
* Официального docker образа не нашёл. Есть вот такое: https://hub.docker.com/r/takano32/chimeralinux/tags

К сожалению, даже нет GitHub репа этого докер образа, что бы посмотреть как он его собирал.

Именно этот образ я попробовал. Что вижу:
* судя по всему, это, действительно, chimera linux
* там BSD утилиты, а не GNU.

Фатальный недостаток: проблемы, которые у меня воспроизводятся на MacOS на этом образе не воспроизводятся. Пробовал, правда, только sed.

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