https://www.opennet.ru/opennews/art.shtml?num=61605

TL;DR - github хранит все форки (публичные и приватные) вместе с основным репозиторием, потому что форк - это бранч.

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

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

Вместе это некоторая дыра в безопасности, потому что позволяет выгрепать приватное репо всего за 16^4 запросов, что вполне может провернуть кто угодно.

https://pnut.sh/
https://github.com/udem-dlteam/pnut

Гля какая красота! Компилятор из C в POSIX shell!

Причем он self-hosted, то есть, может скомпилировать сам себя!

Я пока не придумал, где мне оно может пригодиться в хозяйстве, но, кажется, на ранних стадиях #bootstrap, когда в PATH нет ничего, кроме shell и компилятора, это может сильно упростить мои потуги по сборке всякого изначального инструментария.

https://www.opennet.ru/opennews/art.shtml?num=61607

В node.js добавили поддержку TS.

Ну добавили и добавили, хорошее же дело?

Но, чтобы не плодить "лишнюю" (видимо, небогоугодную) зависимость от Rust, на котором написан используемый ими компилятор, они положили предсобранный блоб с этим компилятором, в WebAssembly!

Реально, блоб в виде WebAssembly, который выполняется самой node.js, и компилирует TS на лету.

Мало? Ну, подумаешь, экосистема JS не отличается большой любовью к решению supply chain attack, кого этим можно удивить?

Если мало, то:

* Выбранная ими реализация компилятора - тупая, по сути, она просто стрипает аннотации типов, и не проверяет их. Почему?

* Потому что эта же реализация используется и в Deno (а в Bun?).

Как говорится, живите тепрь с этим знанием про экосистему JS.

#bootstrap #terminal #rant #cosmic

https://www.phoronix.com/news/Pop-OS-24.04-Alpha-8-August

Тут вон пишут, что скоро выйдет альфа COSMIC desktop.

Мне, с одной стороны, очень импонирует эта штука, как глоток свежего воздуха после засилья GNOME/KDE.

С другой, оно безумно сырое, и не работает за пределами окружения своих же разработчиков:

https://gist.github.com/pg83/777521db03c528bbeadbf90befc551f7

Я, как вы знаете, очень люблю смотреть на новые эмуляторы терминала, но я так и не смог завести cosmic-term, потому что не смог передать ему хоть какой-то шрифт, который бы он нашел в моей системе. Не то что тот, что он хочет по умолчанию, а вообще хоть какой-то.

Нуачо, все перепишем на Rust, и проигнорируем традиционные способы эти шрифты найти.

int main() {
    const unsigned char arr[] = {
#embed `cat X.txt | awk '{print $1}' | sort | uniq`
    };
}

вот так хорошо будет

Будни #bootstrap, #rant

Продолжу тему "gobject introspection" #gir

Во-первых, я собрал vala.

https://vala.dev/

Ну потому что нужно же как-то развивать набор тулчейнов, и мне показалось, что, локально, мне больше всего профита будет от vala, на нем прилично написано gtk приложений.

Но собрать что-то содержательное им оказалось весьма сложно, потому что с внешним миром код на vala общается именно через gir.

А вот эти вот интерфейсные правила собираются очень хрупким образом - частично это парсинг исходников (а там дальше много интересного - какой препроцессор взять, clang, или gcc, какие туда передаются опции, и так далее), и частично - через загрузку интроспектируемого кода в специальном режиме, когда мы просим бинарник выплюнуть все сведения о зарегистрированных в нем типах в виде .gir файла (прощай, кросс-компиляция, ага).

С одним набором настроек собирается gir для libadwaita, но не собирается для libhandy или #harfbuzz (не спрашивайте). Пофиксил - отваливается что-то третье.

Собрать консистентно все gir для всех гномовых либ я пока не сумел, у меня нет столько времени.

В конце-концов, я нашел вот эту вот репку - https://github.com/gtk-rs/gir-files

Здесь растоманы прикопали все более-менее популярные gir. Ну потому, что они в своей cargo вряд ли смогут как-то разумно воспроизвести все условия для того, чтобы повторить эти гномьи экзерсизы. Ну и обновляют их руками, по мере необходимости.

Ну я и присоседился, беру эти файлы у них.

Вроде, как-то оно работает, но весь этот техпроцесс вызывает сомнение.

Вот примерно все, что вам нужно знать про именование библиотек в мире #GNOME:

gck = dependency('gck-1')
gcr = dependency('gcr-3')
gdk = dependency('gdk-3.0')
gee = dependency('gee-0.8')
gio = dependency('gio-2.0')
goa = dependency('goa-1.0')

From https://gitlab.gnome.org/GNOME/geary/-/blob/main/meson.build

https://xn--r1a.website/mintsifry/2316
https://xn--r1a.website/rasstriga/12445

Тут вот пишут, что теперь надо работать в IT весь срок IT-шной ипотеки.

Сразу в нескольких местах это сравнили с крепостным рабством.

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

Возьми да бери обычную ипотеку, без привязки к IT, если так хочется.

.

https://www.datagubbe.se/crt/

Кстати очень классный текст про то, что современный pixel art - это совсем не то, потому что исходно эстетика pixel art появилась на CRT мониторах, и выглядела совсем иначе.

Подтверждаю, в 95 - 00 годах картинка выглядела совсем иначе, и пиксели совсем не раздражали глаз. Антиалиаснутые шрифты, по ощущениям, стали выглядеть примерно так же хорошо, как на тех самых старых CRT, ну, где-то при разрешении 4k.

Посмотреть на это вживую (ну, почти) можно, например, через https://www.dosbox-staging.org/ (это такой форк dosbox, который решил запариться насчет эмуляции CRT) (смотреть на скриншоты особого смысла нет, все равно их перемасштабируют в процессе доставки до глаз 100500 раз, и эффект пропадает).

Будни #bootstrap

Я тут запилил звук в #gstreamer. Раньше его не было, и порно приходилось смотреть без звука, потому что мой браузер (webkit) зачем-то использует gstreamer. А это, как вы понимаете, никуда не годится!

Это было не так просто, потому что я использую #sndiod (пробовал #cras, но пока вот так), а плагин для него в gstreamer находится в плачевном состоянии.

В конце-концов, протоптал дорожку через OpenAL: gstreamer -> openal -> sndio, потому что поддержка в openal у sndio вполне норм, а поддержка openal в gstreamer сильно лучше, чем sndio.

Пришлось по пути соорудить #herobora, потому что openal плагин лежит в gstreamer-bad, и если оттуда включить хоть один плагин, то в библиотеку начинает приезжать тонна говна, потому что все плагины по умолчанию "auto", а не "disabled": https://github.com/GStreamer/gstreamer/blob/main/subprojects/gst-plugins-bad/meson_options.txt

В meson вроде как есть [--auto-features {enabled,disabled,auto}]

https://mesonbuild.com/Commands.html

Но как это прокинуть в subproject, я не понял, даже в cmake лучше сделано.

Поэтому я поступил по-рабоче-крестьянски (а тут реально две черточки нужны?):

https://github.com/pg83/ix/blob/main/pkgs/lib/gstreamer/ix.sh#L65-L66

https://www.opennet.ru/opennews/art.shtml?num=61656

Коллеги хотя автоматически транслировать C в Rust, без unsafe.

C unsafe это довольно просто, правда, результат интересует только тех, кто хочет прикопать наследие C, и, в целом, довольно малоинтересно.

Без unsafe эта задача кажется нерешаемой, только если у вас нет AGI #strong_ai, более хорошего, чем человеческий, потому что такое переписывание с С - процесс очень творческий, он должен держать в голове всю программу, и иметь возможность (и уметь!) менять структуру данных этой программы, и, возможно, способы ее взаимодействия с внешним миром.

А если у вас есть такой AGI, то вам больше нет дела до Rust, хехе.

Короче, дело хорошее, но верится с трудом.

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