Короче, я сделал, можно поздравлять(не, реально!)
Mix, на голом железе, real 3D accel, network, no systemd, no .so, no /lib/.
Mix, на голом железе, real 3D accel, network, no systemd, no .so, no /lib/.
🎉18🔥16
Хотел бы я написать, что переезд под полное управление моим пакетным менеджером заработало like a charm, но увы.
* у меня нет /lib, /usr, и прочей лабуды. При попытке скомпилировать gcc(для того, чтобы собрать ведро, clang я тут пока не доверяю), gcc на голубом глазу мне заявил, что у меня в системе не хватает папки /usr/include, и он не может запустить свой процесс fixincludes.
Вот хороший текст про это от автора musl, почитайте. https://ewontfix.com/12/
Вот фикс от arch - https://github.com/archlinux/svntogit-packages/blob/packages/gcc/trunk/PKGBUILD#L57
Мне такой не подошел, потому что у меня ломается раньше, так как папки /usr нет вообще. Зато я нашел configure опцию! https://github.com/pg83/mix/blob/main/pkgs/bin/gcc/11/mix.sh#L50
Кстати, давно хотел рассказать про такой fun fact про configure. #autohell позволяет в одном дереве исходников разместить несколько проектов с ./configure скриптами. Тогда верхнеуровневый configure будет проксировать все неизвестные опции вниз, и узнать, какие опции есть, решительно невозможно.
Так вот, fun fact - у проектов gcc, gdb, binutils - общий(ну, почти одинаковый, немного разъезжается) верхнеуровневый configure, c опциями от gcc. Это, конечно, добавляет понимания, как эти проекты собирать.
* В процессе персборки мира я столкнулся со странными падениями сборки, когда один проект не мог найти другой. Потратил на поиски этой проблемы несколько часов, пока не понял, что:
1) Все случаи - когда cmake проект не может найти meson проект.
2) Во всех случаях установка meson проекта была несколько странной - вместо ${out}/include/blah.h было ${out}/include/${ver}/blah.h
Это должно было нивелироваться *.pc файлами, которые разруливают пути.
Тут до меня дошло, что я забыл к cmake проектам дописать зависимость от pkg-config, и ранее использовался системный. После этого все прошло like a charm, герметичная сборка рулит.
Я мог бы все контейнеризовать, но не хочу, потому что под mac это сложно, а я хочу и для него обеспечивать герметичность.
* у меня нет /lib, /usr, и прочей лабуды. При попытке скомпилировать gcc(для того, чтобы собрать ведро, clang я тут пока не доверяю), gcc на голубом глазу мне заявил, что у меня в системе не хватает папки /usr/include, и он не может запустить свой процесс fixincludes.
Вот хороший текст про это от автора musl, почитайте. https://ewontfix.com/12/
Вот фикс от arch - https://github.com/archlinux/svntogit-packages/blob/packages/gcc/trunk/PKGBUILD#L57
Мне такой не подошел, потому что у меня ломается раньше, так как папки /usr нет вообще. Зато я нашел configure опцию! https://github.com/pg83/mix/blob/main/pkgs/bin/gcc/11/mix.sh#L50
Кстати, давно хотел рассказать про такой fun fact про configure. #autohell позволяет в одном дереве исходников разместить несколько проектов с ./configure скриптами. Тогда верхнеуровневый configure будет проксировать все неизвестные опции вниз, и узнать, какие опции есть, решительно невозможно.
Так вот, fun fact - у проектов gcc, gdb, binutils - общий(ну, почти одинаковый, немного разъезжается) верхнеуровневый configure, c опциями от gcc. Это, конечно, добавляет понимания, как эти проекты собирать.
* В процессе персборки мира я столкнулся со странными падениями сборки, когда один проект не мог найти другой. Потратил на поиски этой проблемы несколько часов, пока не понял, что:
1) Все случаи - когда cmake проект не может найти meson проект.
2) Во всех случаях установка meson проекта была несколько странной - вместо ${out}/include/blah.h было ${out}/include/${ver}/blah.h
Это должно было нивелироваться *.pc файлами, которые разруливают пути.
Тут до меня дошло, что я забыл к cmake проектам дописать зависимость от pkg-config, и ранее использовался системный. После этого все прошло like a charm, герметичная сборка рулит.
Я мог бы все контейнеризовать, но не хочу, потому что под mac это сложно, а я хочу и для него обеспечивать герметичность.
GitHub
svntogit-packages/trunk/PKGBUILD at packages/gcc · archlinux/svntogit-packages
Automatic import of svn 'packages' repo (read-only mirror) - archlinux/svntogit-packages
👍8
https://blog.ffwll.ch/2018/08/no-2d-in-drm.html
Недавно плакался, что для ускорения десктопа используется дорогущее и жрущее батарейку 3D железо. Хотя хватило бы блиттера и смешения по альфа-каналу.
Вот, объяснение, можно сказать, от самих разработчиков dri. Пишут, что 2D сложнее, чем 3D. Интересно, что он этим имеет в виду? Конечно нет, не сложнее. Просто не стандартизировано, в отличие от. Стандартизировать ни у кого желания нет, потому что профит по сравнению с уже существуюшим 3D не то чтобы большой.
———
https://wingolog.org/archives/2021/12/13/webassembly-the-new-kubernetes
Писал про #ebpf + #io_uring, и, буквально, на днях, про #wasm. Короче, идея, что нужна более легкая виртуализация, витает в облаках.
———
https://www.supergoodcode.com/zink-4ever/
Важная для меня тема :) Я в Mix решил строить графический стек в виде #zink + vulkan, чтобы 2 раза не вставать(и чтобы без #LLVM в драйверах*). И оказывается, не прогадал. Уже писал, что zink по перфу догнал классический OpenGL, а теперь просто прекрасное - #zink - самый фичастый из OpenGL в Mesa. Короче, старый стек уже можно закапывать.
Чувак работает на Valve.
Все #хорошее в OSS делают корпорации, когда это не основной их продукт. Гугл продает рекламу, а не браузер, FB, знаете ли, не продает системы сборки, и так далее. А вот результат у mongo и elastic немного хуже. Вот и Valve продает не OpenGL, а игры.
Короче, самый годный продукт - это когда код пишется по корпоративным нормам, с нормальным менеджментом, и когда за этот код не хотят денег(чтобы не было желания крутить всякие серые схемы). OSS - дополнительная вишенка на торте, на публику люди стараются больше.
*: кстати, в копилку про "не умеют договариваться" и #fontconfig - в нормальной жизни компилятор шейдеров был бы демоном. Тогда и кеш понятно, как устроить, без вычисления md5 от образа библиотеки, и как не запускать llvm в каждом приложении, и как падения ретраить(sic).
PS: тут про компилятор шейдеров я имел в виду штуку, которая SPIR-V в машинный формат переводит.
Недавно плакался, что для ускорения десктопа используется дорогущее и жрущее батарейку 3D железо. Хотя хватило бы блиттера и смешения по альфа-каналу.
Вот, объяснение, можно сказать, от самих разработчиков dri. Пишут, что 2D сложнее, чем 3D. Интересно, что он этим имеет в виду? Конечно нет, не сложнее. Просто не стандартизировано, в отличие от. Стандартизировать ни у кого желания нет, потому что профит по сравнению с уже существуюшим 3D не то чтобы большой.
———
https://wingolog.org/archives/2021/12/13/webassembly-the-new-kubernetes
Писал про #ebpf + #io_uring, и, буквально, на днях, про #wasm. Короче, идея, что нужна более легкая виртуализация, витает в облаках.
———
https://www.supergoodcode.com/zink-4ever/
Важная для меня тема :) Я в Mix решил строить графический стек в виде #zink + vulkan, чтобы 2 раза не вставать(и чтобы без #LLVM в драйверах*). И оказывается, не прогадал. Уже писал, что zink по перфу догнал классический OpenGL, а теперь просто прекрасное - #zink - самый фичастый из OpenGL в Mesa. Короче, старый стек уже можно закапывать.
Чувак работает на Valve.
Все #хорошее в OSS делают корпорации, когда это не основной их продукт. Гугл продает рекламу, а не браузер, FB, знаете ли, не продает системы сборки, и так далее. А вот результат у mongo и elastic немного хуже. Вот и Valve продает не OpenGL, а игры.
Короче, самый годный продукт - это когда код пишется по корпоративным нормам, с нормальным менеджментом, и когда за этот код не хотят денег(чтобы не было желания крутить всякие серые схемы). OSS - дополнительная вишенка на торте, на публику люди стараются больше.
*: кстати, в копилку про "не умеют договариваться" и #fontconfig - в нормальной жизни компилятор шейдеров был бы демоном. Тогда и кеш понятно, как устроить, без вычисления md5 от образа библиотеки, и как не запускать llvm в каждом приложении, и как падения ретраить(sic).
PS: тут про компилятор шейдеров я имел в виду штуку, которая SPIR-V в машинный формат переводит.
blog.ffwll.ch
Why no 2D Userspace API in DRM?
The DRM (direct rendering manager, not the content protection stuff) graphicssubsystem in the linux kernel does not have a generic 2D accelaration API.Despit...
Читал тут исходники pulse audio. Осознал, что Поттеринг всю жизнь пишет одну и ту же программу - граф обработки каких-нить событий в realtime, и обязательно чтобы граф связывался в runtime, и без проверок на то, что этот граф может выполниться в реальной жизни. Ну не дает покоя человеку эта идея.
Бывает, чо. Некоторые вот уже 5-ую систему сборки пишут.
———
#gold, #security
Сначала небольшая вводная, для тех, кто с нами недавно.
Mix - это пакетный менеджер для linux/macos, и дистрибутив Linux на основе.
Я очень хочу, чтобы пакетным менеджером пользовалось как можно больше народу(не прямо сейчас, а вообще), потому что 1 человек потянет 500 пакетов(у меня сейчас 300), а больше уже нужно больше людей.
Поэтому я очень явно разделяю пакетный менеджер, который может быть использован как угодно и где угодно, хоть в другом Linux, и дистрибутив, построенный из этих пакетов.
При этом я, скажем, не хочу терять потенциальных пользователей, которым почему-то нравится systemd(я вообще считаю, что взрослые люди по взаимному согласию могут и в #systemd, да, хотя сам не буду ни за что).
Поэтому я предполагаю, что у меня будет несколько "пресетов" - наборов пакетов, которые формируюут законченную идею(вид линковки + libc + DE + whatever).
Далее, когда я говорю, что "у меня в Mix вот так-то", я имею в виду вот этот вот пресет - https://github.com/pg83/mix/blob/main/pkgs/set/system/0/mix.sh, или System/0 #system0. Все, что я делаю в нем, может и не относиться к потенциальному Mix на #systemd + gnome.
Я повторю, что мне все равно, кто и как использует пакетную базу, лишь бы помогали обновлять пакеты.
Так, вводная закончилась. Далее про то, как будет устроен System/0(а точнее, про один из аспектов устройства).
Мне очень хочется, чтобы пакетный менеджер не работал от root, и чтобы в нем не было postinstall скриптов. А точнее, я хочу, чтобы пакет можно было установить, распаковав папку с его содержимым, и все. Это здорово облегчает реализацию, и упрощает модель безопасности. Скажем, как в Android.
Я решил почти все проблемы, связанные с этим:
* заведение пользователей/групп
* резолвер
* динамическая настройка сети
Да даже попакетные настройки ядра.
Но вот одна проблема оставалась для меня сложной. Как эскалировать привилегии? Да, sudo. Если пакетный менеджер не работает от root, нет postinstall скриптов, то как получить #suid бинарник в системе?
До недавнего времени я решал эту задачу довольно криво - фоновый процесс, который проставлял setuid бит некторым бинарям.
На днях придумал элегантное решение, и спешу им поделиться.
На хосте запущен(скажем, через socket activation) ssh демон, от рута. И sudo - это простой скрипт, который делает ssh root@localhost. ssh поднят на unix domain socket, чтобы не светить в сеть. Базово эта схема уже работает.
Чем больше думаю, тем больше мне эта схема нравится.
* Эскалация привилегий в ssh, я думаю, отлажена даже лучше, чем в sudo. Потому что так мы привилегии эскалируем IMHO чаще.
* Вход не по паролю, а по ключу, 1 на пользователя, а не одному на host.
* Парольный/беспарольный вход остается на стороне пользователя(пароль на приватной части ключа), без fragile вмешательства в /etc.
Схема работает очень годно - у меня нет ни одного #suid бинаря.
Бывает, чо. Некоторые вот уже 5-ую систему сборки пишут.
———
#gold, #security
Сначала небольшая вводная, для тех, кто с нами недавно.
Mix - это пакетный менеджер для linux/macos, и дистрибутив Linux на основе.
Я очень хочу, чтобы пакетным менеджером пользовалось как можно больше народу(не прямо сейчас, а вообще), потому что 1 человек потянет 500 пакетов(у меня сейчас 300), а больше уже нужно больше людей.
Поэтому я очень явно разделяю пакетный менеджер, который может быть использован как угодно и где угодно, хоть в другом Linux, и дистрибутив, построенный из этих пакетов.
При этом я, скажем, не хочу терять потенциальных пользователей, которым почему-то нравится systemd(я вообще считаю, что взрослые люди по взаимному согласию могут и в #systemd, да, хотя сам не буду ни за что).
Поэтому я предполагаю, что у меня будет несколько "пресетов" - наборов пакетов, которые формируюут законченную идею(вид линковки + libc + DE + whatever).
Далее, когда я говорю, что "у меня в Mix вот так-то", я имею в виду вот этот вот пресет - https://github.com/pg83/mix/blob/main/pkgs/set/system/0/mix.sh, или System/0 #system0. Все, что я делаю в нем, может и не относиться к потенциальному Mix на #systemd + gnome.
Я повторю, что мне все равно, кто и как использует пакетную базу, лишь бы помогали обновлять пакеты.
Так, вводная закончилась. Далее про то, как будет устроен System/0(а точнее, про один из аспектов устройства).
Мне очень хочется, чтобы пакетный менеджер не работал от root, и чтобы в нем не было postinstall скриптов. А точнее, я хочу, чтобы пакет можно было установить, распаковав папку с его содержимым, и все. Это здорово облегчает реализацию, и упрощает модель безопасности. Скажем, как в Android.
Я решил почти все проблемы, связанные с этим:
* заведение пользователей/групп
* резолвер
* динамическая настройка сети
Да даже попакетные настройки ядра.
Но вот одна проблема оставалась для меня сложной. Как эскалировать привилегии? Да, sudo. Если пакетный менеджер не работает от root, нет postinstall скриптов, то как получить #suid бинарник в системе?
До недавнего времени я решал эту задачу довольно криво - фоновый процесс, который проставлял setuid бит некторым бинарям.
На днях придумал элегантное решение, и спешу им поделиться.
На хосте запущен(скажем, через socket activation) ssh демон, от рута. И sudo - это простой скрипт, который делает ssh root@localhost. ssh поднят на unix domain socket, чтобы не светить в сеть. Базово эта схема уже работает.
Чем больше думаю, тем больше мне эта схема нравится.
* Эскалация привилегий в ssh, я думаю, отлажена даже лучше, чем в sudo. Потому что так мы привилегии эскалируем IMHO чаще.
* Вход не по паролю, а по ключу, 1 на пользователя, а не одному на host.
* Парольный/беспарольный вход остается на стороне пользователя(пароль на приватной части ключа), без fragile вмешательства в /etc.
Схема работает очень годно - у меня нет ни одного #suid бинаря.
https://www.opennet.ru/opennews/art.shtml?num=56580
Как я удачно про #suid бинари написал. Напомню, что polkit это хрень с модулями на javascript, которая, по идее, должна быть на любом Linux.
———
https://github.com/swaywm/sway/releases/tag/1.7
Недавно писал, что перешел с GPU accelerated терминала на простой и тупой, как пробка, #foot. А теперь и в sway по умолчанию.
———
https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix-compliant-certified
Текст про то как и зачем Apple стала почти единственным настоящим Unix на рынке. Спойлер - все из-за денег.
Yes, we had access to all of Apple’s source code, at that point in the game.
And so we submitted high priority bug fixes to the projects, some of which downgraded the priority immediately, and some of which they simply fixed, since we had provided them with the patch already.
And then the VP of engineering, Bertrand Serlet, re-escalated the priority on the ones which had been downgraded.
"If I were asked to do the same thing for Linux, it likely would take five years, and two dozen people.
Linux is pretty balkanize, has a lot of kingdom building, and you have to pee on everything to make it smell like Linux."
Вообще, забавно читать про такие "подвиги", рефакторинги на пару тысяч файлов в монорепе - дело повседневное. Ну, чувак поднял 10^7 денег за эту работу, я явно что-то делаю не так.
———
https://drunkard.com/the-zen-of-drinking-alone/
The next time you get loaded with the gang, gaze into your drink, your secret mirror, and think: “Hey, old friend. Remember our quiet time together? Remember the thoughts we shared? We’ll meet up again down the road. Just you, me, and the bottle.”
Не постесняюсь сказать, что я тоже предпочитаю надираться в одиночку, в лучшей доступной мне компании, с самим собой. Правда, возраст уже не тот, здоровье не позволяет.
Как я удачно про #suid бинари написал. Напомню, что polkit это хрень с модулями на javascript, которая, по идее, должна быть на любом Linux.
———
https://github.com/swaywm/sway/releases/tag/1.7
Недавно писал, что перешел с GPU accelerated терминала на простой и тупой, как пробка, #foot. А теперь и в sway по умолчанию.
———
https://www.quora.com/What-goes-into-making-an-OS-to-be-Unix-compliant-certified
Текст про то как и зачем Apple стала почти единственным настоящим Unix на рынке. Спойлер - все из-за денег.
Yes, we had access to all of Apple’s source code, at that point in the game.
And so we submitted high priority bug fixes to the projects, some of which downgraded the priority immediately, and some of which they simply fixed, since we had provided them with the patch already.
And then the VP of engineering, Bertrand Serlet, re-escalated the priority on the ones which had been downgraded.
"If I were asked to do the same thing for Linux, it likely would take five years, and two dozen people.
Linux is pretty balkanize, has a lot of kingdom building, and you have to pee on everything to make it smell like Linux."
Вообще, забавно читать про такие "подвиги", рефакторинги на пару тысяч файлов в монорепе - дело повседневное. Ну, чувак поднял 10^7 денег за эту работу, я явно что-то делаю не так.
———
https://drunkard.com/the-zen-of-drinking-alone/
The next time you get loaded with the gang, gaze into your drink, your secret mirror, and think: “Hey, old friend. Remember our quiet time together? Remember the thoughts we shared? We’ll meet up again down the road. Just you, me, and the bottle.”
Не постесняюсь сказать, что я тоже предпочитаю надираться в одиночку, в лучшей доступной мне компании, с самим собой. Правда, возраст уже не тот, здоровье не позволяет.
www.opennet.ru
Критическая уязвимость в PolKit, позволяющая получить root-доступ в большинстве дистрибутивов Linux
Компания Qualys выявила уявзвимость (CVE-2021-4034) в системном компоненте Polkit (бывший PolicyKit), используемом в дистрибутивах для организации выполнения непривилегированными пользователями действий, требующих повышенных прав доступа. Уязвимость позволяет…
Меня тут спросили, сколько места-то занимает. Сначала отвечу, потом объясню, почему эта цифра не имеет смысла.
Почему эти цифры не имеют смысла? Ну, по крайней мере, для Linux на реальном железе.
* Ядро примерно 30МБ(модули built-in)
* firmware для ядра - одна большая папка размером в 900МБ, пилят ее на части только очень отчаянные люди. Потому что вот, например, драйвер AMD без патчей от Gentoo даже не пишет в консоль, какую фирмварь он загружает, а без фирмвари - просто черный экран. https://wiki.gentoo.org/wiki/AMDGPU#Kernel (реально, почитайте, автору особенно доставил пассаж с рекомендацией вбивать команды вслепую)
* Папка с какими-то дефолтными шрифтами занимает 200МБ
mix@mix:/bin$ du -h $(find . | while read l;Userspace, достаточный, чтобы загрузить ядро, поднять сеть, запустить графическое приложение(без композитора, разумеется), системная шина для контроля и управления <10MB в несжатом виде. Ну, как Alpine, и было бы странно иначе.
do realpath $l; done | sort | uniq)
840.0K /mix/store/BxNMUMuUPquoZbWG-bin-iw/bin/iw
1.1M /mix/store/CTeWFHWDCSA3QjRO-bin-dbus-sys/
bin/dbus-daemon
4.0K /mix/store/FzLWUWyAW7xeQM6U-bin-sud/bin/sudo
868.0K /mix/store/IUS1aLEwKRNGUDJG-bin
-dropbear-sys/bin/dbclient
912.0K /mix/store/IUS1aLEwKRNGUDJG
-bin-dropbear-sys/bin/dropbear
452.0K /mix/store/IuLQZHWKACpHHIMb
-bin-mingetty/bin/mingetty
2.1M /mix/store/Lxg7GGmAKFS6JRHF
-bin-busybox-full/bin/busybox
16.0K /mix/store/QCGQYMxNFX7JVPNI/
bin/bin_dhcpcd_sys/dhcpcd-hooks
24.0K /mix/store/QCGQYMxNFX7JVPNI/
bin/bin_dhcpcd_sys
92.0K /mix/store/QCGQYMxNFX7JVPNI/bin
344.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/bin/chpst
24.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/bin/runit
12.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/
bin/runit-init
32.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/
bin/runsv
16.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/
bin/runsvchdir
328.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/
bin/runsvdir
28.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/bin/sv
352.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/bin/svlogd
16.0K /mix/store/RDejKYbHOBtsKiXE-bin-runit/
bin/utmpset
464.0K /mix/store/VhhsJUEQVQ6SN9MR-bin-seatd-sys/
bin/seatd
4.0K /mix/store/XjIiXHuLYGOTmHkb-bin-dhcpcd-sys/
bin/bin_dhcpcd_sys/dhcpcd-hooks/01-test
8.0K /mix/store/XjIiXHuLYGOTmHkb-bin-dhcpcd-sys/
bin/bin_dhcpcd_sys/dhcpcd-hooks/20-resolv.conf
4.0K /mix/store/XjIiXHuLYGOTmHkb-bin-dhcpcd-sys/
bin/bin_dhcpcd_sys/dhcpcd-hooks/30-hostname
12.0K /mix/store/XjIiXHuLYGOTmHkb-bin-dhcpcd-sys/
bin/bin_dhcpcd_sys/dhcpcd-run-hooks
796.0K /mix/store/XjIiXHuLYGOTmHkb-bin-dhcpcd-sys/
bin/dhcpcd
1.1M /mix/store/pwC5GgAGQBVEGBEY-bin-iwd/bin/iwctl
1.7M /mix/store/pwC5GgAGQBVEGBEY-bin-iwd/bin/iwd
1.4M /mix/store/pwC5GgAGQBVEGBEY-bin-iwd/bin/iwmon
Почему эти цифры не имеют смысла? Ну, по крайней мере, для Linux на реальном железе.
* Ядро примерно 30МБ(модули built-in)
* firmware для ядра - одна большая папка размером в 900МБ, пилят ее на части только очень отчаянные люди. Потому что вот, например, драйвер AMD без патчей от Gentoo даже не пишет в консоль, какую фирмварь он загружает, а без фирмвари - просто черный экран. https://wiki.gentoo.org/wiki/AMDGPU#Kernel (реально, почитайте, автору особенно доставил пассаж с рекомендацией вбивать команды вслепую)
* Папка с какими-то дефолтными шрифтами занимает 200МБ
👍5
Я давно откладывал эту тему, но вот вышла эта новость, и, видимо, пора:
https://www.opennet.ru/opennews/art.shtml?num=56587
"Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования окон на стороне клиента."
libdecor - это леденящий душу пиздец.
Очень хорошо со стеком #glib /gtk я познакомился под НГ, когда собирал себе браузер Epiphany, на основе WebKitGTK(*).
* Он написан на диалекте С от GNU. Это очень странная объектная система, которая позволяет конструировать классы на лету, и несщадно тормозит, потому что минимум 2 уровня косвенности.
* Он жрет много памяти. Потому что любой объект в куче, там нет оптимизации любой нормальной VM, позволяющей создавать большинство объектов на стеке.
* Там есть система пропертей, которая реализована посредством линейного сравнения поступившего имени метода со всеми известными значениями, потому что хеш-таблиц в С не завезли.
* Он косой и кривой - я заметил, что браузер всегда мерцает(1 кадр - белый фон, второй - реальная картинка(видос записывать лень)). Бугага, зато девелоперы пишут победные статьи - https://blogs.igalia.com/carlosgc/2017/02/10/accelerated-compositing-in-webkitgtk-2-14-4/. Ремарка - плохие девелоперы у Igalia, не у WebKit.
В процессе исследования это проблемы я пришел к следующему интересному выводу: динамической линковкой в мире OSS решают две проблемы:
* Кто-то с кем-то не договорился. #fontconfig
* Круговые зависимости.
Сегодня про первую проблему :) #GNOME #SSD
Вот такой феерический тред - https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Обязательно его прочитайте! Краткое содержание - все упрашивают разработчиков Gnome добавить поддержку server side decorations, а они отказываются, мотивируя тем:
* Что могут(Wayland не требует поддержки SSD).
* Что их собственный композитор не зависит и не должен зависеть от GTK. Дебилы, у меня нет других слов.
И, тем самым, не-GTK приложения должны в себя влинковывать GTK, чтобы не выглядеть в Gnome чужеродно. Чувствуете логику, да? То есть, не 1 гномовский композитор должен зависеть от их платформенной библиотеки, а каждое приложение на QT должно зависеть от чужой платформенной библиотеки.
Короче, TL;DR - они не договорились, и появилась библиотека libdecor, которая должна в runtime загрузить в себя плагин, который загрузит GTK в QT приложение, запустит в отдельном event loop GTK, и будет отрисовывать клиенсткие декорации.
Я думаю, последствия такого леденящего душу пиздеца очевидны - надежность и так ненадежного кода падает в разы, потребление памяти растет, сложность растет, у клиентов все глючит, потому что библиотека не может найти сраный плагин(это вообще такая особенность плагинов в мире OSS), и потому что определение того, под каким DE мы запущены, глючит.
И вот, теперь безвинные приложения на SDL будут загружать это УГ, и рисовать им декорации.
Я после этого треда очень сильно поменял свое отношение к этим упырям из Gnome, они реально негодяи. Считают, что GTK - это платформенный тулкит, и все должны под него подстраиваться. С его-то проблемами.
* Почему WebKIT? Мне показалось, что его проще всего собрать, потому что меньше мудохаться с вендорингом. Я ошибался, но это уже другая история.
https://www.opennet.ru/opennews/art.shtml?num=56587
"Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования окон на стороне клиента."
libdecor - это леденящий душу пиздец.
Очень хорошо со стеком #glib /gtk я познакомился под НГ, когда собирал себе браузер Epiphany, на основе WebKitGTK(*).
* Он написан на диалекте С от GNU. Это очень странная объектная система, которая позволяет конструировать классы на лету, и несщадно тормозит, потому что минимум 2 уровня косвенности.
* Он жрет много памяти. Потому что любой объект в куче, там нет оптимизации любой нормальной VM, позволяющей создавать большинство объектов на стеке.
* Там есть система пропертей, которая реализована посредством линейного сравнения поступившего имени метода со всеми известными значениями, потому что хеш-таблиц в С не завезли.
* Он косой и кривой - я заметил, что браузер всегда мерцает(1 кадр - белый фон, второй - реальная картинка(видос записывать лень)). Бугага, зато девелоперы пишут победные статьи - https://blogs.igalia.com/carlosgc/2017/02/10/accelerated-compositing-in-webkitgtk-2-14-4/. Ремарка - плохие девелоперы у Igalia, не у WebKit.
В процессе исследования это проблемы я пришел к следующему интересному выводу: динамической линковкой в мире OSS решают две проблемы:
* Кто-то с кем-то не договорился. #fontconfig
* Круговые зависимости.
Сегодня про первую проблему :) #GNOME #SSD
Вот такой феерический тред - https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Обязательно его прочитайте! Краткое содержание - все упрашивают разработчиков Gnome добавить поддержку server side decorations, а они отказываются, мотивируя тем:
* Что могут(Wayland не требует поддержки SSD).
* Что их собственный композитор не зависит и не должен зависеть от GTK. Дебилы, у меня нет других слов.
И, тем самым, не-GTK приложения должны в себя влинковывать GTK, чтобы не выглядеть в Gnome чужеродно. Чувствуете логику, да? То есть, не 1 гномовский композитор должен зависеть от их платформенной библиотеки, а каждое приложение на QT должно зависеть от чужой платформенной библиотеки.
Короче, TL;DR - они не договорились, и появилась библиотека libdecor, которая должна в runtime загрузить в себя плагин, который загрузит GTK в QT приложение, запустит в отдельном event loop GTK, и будет отрисовывать клиенсткие декорации.
Я думаю, последствия такого леденящего душу пиздеца очевидны - надежность и так ненадежного кода падает в разы, потребление памяти растет, сложность растет, у клиентов все глючит, потому что библиотека не может найти сраный плагин(это вообще такая особенность плагинов в мире OSS), и потому что определение того, под каким DE мы запущены, глючит.
И вот, теперь безвинные приложения на SDL будут загружать это УГ, и рисовать им декорации.
Я после этого треда очень сильно поменял свое отношение к этим упырям из Gnome, они реально негодяи. Считают, что GTK - это платформенный тулкит, и все должны под него подстраиваться. С его-то проблемами.
* Почему WebKIT? Мне показалось, что его проще всего собрать, потому что меньше мудохаться с вендорингом. Я ошибался, но это уже другая история.
www.opennet.ru
Мультимедийная библиотека SDL переходит на использование Wayland по умолчанию
В кодовую базу библиотеки SDL (Simple DirectMedia Layer) принято изменение по умолчанию активирующее работу на базе протокола Wayland в окружениях, предоставляющих одновременную поддержку Wayland и X11. Ранее в Wayland-окружениях с компонентом XWayland по…
Уважаемые, а продайте OSS process supervisor?
Не статический, по типу s6/runit/shepherd, а динамический. В идеале, хочу команду spawn, которая по UDS сходит в демон, и демон запустит процесс, за которым будет следить:
* ротейтить stdout/stderr в файлы
* очищать ошметки после смерти
* перезапускать при падении
Все известные мне решения смотрят или на папочку с сервисами, или на конфиг с сервисами. Хочется динамики.
Не статический, по типу s6/runit/shepherd, а динамический. В идеале, хочу команду spawn, которая по UDS сходит в демон, и демон запустит процесс, за которым будет следить:
* ротейтить stdout/stderr в файлы
* очищать ошметки после смерти
* перезапускать при падении
Все известные мне решения смотрят или на папочку с сервисами, или на конфиг с сервисами. Хочется динамики.
Я тут себе собирал свое личное ядро для System/0 #system0. Это оказалось очень сложно, и заняло 4 бессонных ночи(+ целиком прошлое воскресенье).
Ну, то есть, собрать-то легко, а вот сделать так, чтобы оно заработало, очень сложно.
* Первое ядро ничего не писало на экран, и просто мигало капсом(это типа такой kernel panic). https://en.wikipedia.org/wiki/Kernel_panic#Linux. К счастью, от Gentoo я знал историю про то, что ядро себя так ведет с amdgpu, если не может загрузить firmware. Незачет номер раз - в такой ситуации нормальные люди откатывались бы на efi framebuffer, и показывали хотя бы сообщение об ошибке. Видимо, реализовать приоритет драйверов - это очень сложно.
* Загрузка firmware. Ядро напрочь отказалось загружать firmware с файловой системы, а до firmwared дело просто не доходило. Я так понимаю, некоторые штуки надо загружать или только из initrd,или прямо вкомпилять внутрь ядра. Я пока вкомпилял внутрь, причем вообще всю фирмварь для amdgpu, так как я уже писал, что нормального способа узнать, что загружено - не существует. - несколько часов.
* Для интелевых карточек в репе лежит примерно 20 разных фирмварей. Если дать ядру возможность выбора, то драйвер загружает НЕ ТУ фирмварь(оно при попытке поднять интерфейс срет в dmesg). То есть, фирмварь пришлось заблеклистить. На минуточку, драйвер от Intel, загружает фирмварь от Intel, подписанный Intel, для интеловой же карты, и ошибается. - несколько часов.
* Дальше началось самое интересное. Не работал мой тачпад в Sway. Последовательный bisect проблем показал, что ядро не видит тачпад, и не создает для него /dev/input/чегототам. Суммарно на решение этой проблемы ушло часов 20, за которые я успел по настоящему подебажить ядро. Я узнал, что такое шина i2c, hid, как они сопрягаются, и кучу прочего бесполезного барахла. А теперь придется и вам.
Итак, мое текущее понимание устройства ядра(это все довольно поверхностно, физически устроено еще сложнее *):
* Ядро - это такой большой std::map<void*, void*> M, как Spring :))
* Все подсистемы могут туда что-то положить, и зарегистрировать.
* Все подсистемы там могут что-то поискать, и что-то дернуть.
Какие отсюда интересные следствия?
* Если ты забыл что-то вкомпилять в ядро, то посреди цепочки регистрации что-то потеряется, и твое устройство не будет найдено.
* В модулях ядра стоят неполные зависимости. Что это значит? Это значит, что загрузятся не все нужные подсистемы, и мы возвращаемся в пункт 1.
* Зависимость от порядка регистрации. Если его не соблюсти, то в момент регистрации драйвера могут быть зареганы не все нужные подсистемы(пункт 2), и возвращаемся в пункт 1.
В моем конкретном случае я забыл** вкомпилять драйвер для gpio pins. Не спрашивайте что это такое, я к ядру подхожу с чисто практической точки зрения - "проходит или не проходит сигнал", а что там - мне глубоко пофиг.
Поэтому шина i2c видела мое устройство, но сигнал не доходил до HID драйвера, и устройство не могло зарегаться.
В какой-то момент я отчаялся найти проблему дебагом, и сделал просто. Скомпилировал все драйвера ядра в виде модулей, и начал на них делать цикл по загрузке модулей в ядра, в разном порядке, определяя, после какого модуля мое устройство таки найдется(напомню про то, что порядок важен, как я писал выше).
В конце-концов я нашел модуль про gpio pins, увидел, что его нет в зависимостях ни у i2c, ни у hid, и все стало понятно.
Кстати, собрать ядро со всеми драйверами built in невозможно(будет падать, или бесконечно висеть в probe девайсов), потому что это какое-то безумие - probe у некоторых драйверов работает лишь по факту их включения в ядро, что потенциально ломает систему, если нужного девайса нет. У меня это выражалось в том, что попытка загрузить какой-то левый драйвер для i2c контроллера ломало драйвер для настоящего i2c контроллера.
Почему нельзя вкомпилять в ядро на правах модуля(типа, звать probe только тогда, когда явно попросили init этого драйвера) - непонятно.
Короче, ядро у меня уже свое, но пока не до конца пригодно для всех.
Ну, то есть, собрать-то легко, а вот сделать так, чтобы оно заработало, очень сложно.
* Первое ядро ничего не писало на экран, и просто мигало капсом(это типа такой kernel panic). https://en.wikipedia.org/wiki/Kernel_panic#Linux. К счастью, от Gentoo я знал историю про то, что ядро себя так ведет с amdgpu, если не может загрузить firmware. Незачет номер раз - в такой ситуации нормальные люди откатывались бы на efi framebuffer, и показывали хотя бы сообщение об ошибке. Видимо, реализовать приоритет драйверов - это очень сложно.
* Загрузка firmware. Ядро напрочь отказалось загружать firmware с файловой системы, а до firmwared дело просто не доходило. Я так понимаю, некоторые штуки надо загружать или только из initrd,или прямо вкомпилять внутрь ядра. Я пока вкомпилял внутрь, причем вообще всю фирмварь для amdgpu, так как я уже писал, что нормального способа узнать, что загружено - не существует. - несколько часов.
* Для интелевых карточек в репе лежит примерно 20 разных фирмварей. Если дать ядру возможность выбора, то драйвер загружает НЕ ТУ фирмварь(оно при попытке поднять интерфейс срет в dmesg). То есть, фирмварь пришлось заблеклистить. На минуточку, драйвер от Intel, загружает фирмварь от Intel, подписанный Intel, для интеловой же карты, и ошибается. - несколько часов.
* Дальше началось самое интересное. Не работал мой тачпад в Sway. Последовательный bisect проблем показал, что ядро не видит тачпад, и не создает для него /dev/input/чегототам. Суммарно на решение этой проблемы ушло часов 20, за которые я успел по настоящему подебажить ядро. Я узнал, что такое шина i2c, hid, как они сопрягаются, и кучу прочего бесполезного барахла. А теперь придется и вам.
Итак, мое текущее понимание устройства ядра(это все довольно поверхностно, физически устроено еще сложнее *):
* Ядро - это такой большой std::map<void*, void*> M, как Spring :))
* Все подсистемы могут туда что-то положить, и зарегистрировать.
* Все подсистемы там могут что-то поискать, и что-то дернуть.
Какие отсюда интересные следствия?
* Если ты забыл что-то вкомпилять в ядро, то посреди цепочки регистрации что-то потеряется, и твое устройство не будет найдено.
* В модулях ядра стоят неполные зависимости. Что это значит? Это значит, что загрузятся не все нужные подсистемы, и мы возвращаемся в пункт 1.
* Зависимость от порядка регистрации. Если его не соблюсти, то в момент регистрации драйвера могут быть зареганы не все нужные подсистемы(пункт 2), и возвращаемся в пункт 1.
В моем конкретном случае я забыл** вкомпилять драйвер для gpio pins. Не спрашивайте что это такое, я к ядру подхожу с чисто практической точки зрения - "проходит или не проходит сигнал", а что там - мне глубоко пофиг.
Поэтому шина i2c видела мое устройство, но сигнал не доходил до HID драйвера, и устройство не могло зарегаться.
В какой-то момент я отчаялся найти проблему дебагом, и сделал просто. Скомпилировал все драйвера ядра в виде модулей, и начал на них делать цикл по загрузке модулей в ядра, в разном порядке, определяя, после какого модуля мое устройство таки найдется(напомню про то, что порядок важен, как я писал выше).
В конце-концов я нашел модуль про gpio pins, увидел, что его нет в зависимостях ни у i2c, ни у hid, и все стало понятно.
Кстати, собрать ядро со всеми драйверами built in невозможно(будет падать, или бесконечно висеть в probe девайсов), потому что это какое-то безумие - probe у некоторых драйверов работает лишь по факту их включения в ядро, что потенциально ломает систему, если нужного девайса нет. У меня это выражалось в том, что попытка загрузить какой-то левый драйвер для i2c контроллера ломало драйвер для настоящего i2c контроллера.
Почему нельзя вкомпилять в ядро на правах модуля(типа, звать probe только тогда, когда явно попросили init этого драйвера) - непонятно.
Короче, ядро у меня уже свое, но пока не до конца пригодно для всех.
👍4
Будни бутстрапа.
/usr/share - это жесть. Каждый тулкит, каждая графическая библиотека, содержит в себе те или иные хаки по поиску
* шрифтов
* иконок
* курсоров
Да, да, курсоров. Я был очень удивлен, узнав, что в wayland курсор отрисовывает клиент. Отсюда полная неразбериха в темах и размерах. В какой-то момент у меня получилось сделать так, что у меня были 3 разных размера курсора - в sway, foot, и в waybar.
Хорошее описание проблемы тут - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/58
Некто Simon Ser настойчиво отстаивает право авторов клиентов творить любую дичь. Наверное, потому что он автор одного из таких клиентов - wlroots/sway. Не верите? А пожалуйста!
Вот Simon героически скопировал в wlroots кусок wayland(а тот, в свою очередь, скопировал кусок из XCursor) по локации папочки с курсорами - https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/xcursor/xcursor.c#L622 Зачем, я хз.
Конечно, это очень удобно - в одной шапочке писать правила и протоколы wayland, а в другой - разрабатывать sway.
К счастью, это open source, и то, что сломано одним долбоебом, всегда может быть исправлено другим. Я, конечно, у себя этот файлик обнуляю - https://github.com/pg83/mix/blob/main/pkgs/lib/wlroots/14/mix.sh#L52.
/usr/share - это жесть. Каждый тулкит, каждая графическая библиотека, содержит в себе те или иные хаки по поиску
* шрифтов
* иконок
* курсоров
Да, да, курсоров. Я был очень удивлен, узнав, что в wayland курсор отрисовывает клиент. Отсюда полная неразбериха в темах и размерах. В какой-то момент у меня получилось сделать так, что у меня были 3 разных размера курсора - в sway, foot, и в waybar.
Хорошее описание проблемы тут - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/58
Некто Simon Ser настойчиво отстаивает право авторов клиентов творить любую дичь. Наверное, потому что он автор одного из таких клиентов - wlroots/sway. Не верите? А пожалуйста!
Вот Simon героически скопировал в wlroots кусок wayland(а тот, в свою очередь, скопировал кусок из XCursor) по локации папочки с курсорами - https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/xcursor/xcursor.c#L622 Зачем, я хз.
Конечно, это очень удобно - в одной шапочке писать правила и протоколы wayland, а в другой - разрабатывать sway.
К счастью, это open source, и то, что сломано одним долбоебом, всегда может быть исправлено другим. Я, конечно, у себя этот файлик обнуляю - https://github.com/pg83/mix/blob/main/pkgs/lib/wlroots/14/mix.sh#L52.
GitLab
Cursor shapes, server-side cursor themes (#58) · Issues · wayland / wayland-protocols · GitLab
The problem Wayland handles cursor graphics on the client-side. This has several annoying implications/issues: It requires most...
👍2❤1
Я думаю, вы уже поняли, что #system0 - это "моя прелллесть" :)
В ней я, по мере сил, намерен исправить разные проблемы, с которыми я сталкивался по мере взаимодействия с Linux/Unix.
Одна из таких проблем - это свойство Unix по наследованию init-ом процессов, у которых умер родитель. Я считаю, что это треш, угар, и содомия(и одна из причин появления cgroups, кстати). Мне приятно видеть completely supervised tree, если вы понимаете, о чем я. Это удобно и для понимания, и для отладки. Долгоживущие процессы надо запускать через команду spawn сессионного супервизора.
Поэтому у меня есть https://github.com/pg83/mix/blob/main/pkgs/bin/killd/cycle.sh - демон, убивающий "залетные" процессы. Если это полетит, то я это, конечно, добавлю в свой init.
Кстати, убиение через SIGINT там исключительно потому, что, если sway убить через SIGKILL, то он регулярно вешает систему намертво. Вот такой классный графический стек в Linux.
К сожалению, тот же sway зачем-то запускает все процессы через double fork. К счастью, исправление - 3 строки кода.
———
https://www.opennet.ru/opennews/art.shtml?num=56609
Че-то уже третья новость про обновление uutils. Я имею сказать:
* Несмотря на все вбуханные усилия, среднестатичтический configure пока не работает(ну, ладно, на состояние 2 месяца назад).
* Размер busybox-style статического бинаря для busybox - 1.5MB, coreutils - 2.5MB, uutils - 10MB(опять же, на состояние пару месяцев назад, сейчас проверить не могу, потому что Rust у меня уже не запускается). Надо еще понимать, что в busybox в 3 раза больше утилит, там и cron, и dhcp, и util-linux, и так далее. Но они вообще упоротые, читать их код очень интересно.
* Зачем переписывать простой код, который и память-то особо не выделяет, я не понимаю. Какой от этого added value?
В ней я, по мере сил, намерен исправить разные проблемы, с которыми я сталкивался по мере взаимодействия с Linux/Unix.
Одна из таких проблем - это свойство Unix по наследованию init-ом процессов, у которых умер родитель. Я считаю, что это треш, угар, и содомия(и одна из причин появления cgroups, кстати). Мне приятно видеть completely supervised tree, если вы понимаете, о чем я. Это удобно и для понимания, и для отладки. Долгоживущие процессы надо запускать через команду spawn сессионного супервизора.
Поэтому у меня есть https://github.com/pg83/mix/blob/main/pkgs/bin/killd/cycle.sh - демон, убивающий "залетные" процессы. Если это полетит, то я это, конечно, добавлю в свой init.
Кстати, убиение через SIGINT там исключительно потому, что, если sway убить через SIGKILL, то он регулярно вешает систему намертво. Вот такой классный графический стек в Linux.
К сожалению, тот же sway зачем-то запускает все процессы через double fork. К счастью, исправление - 3 строки кода.
———
https://www.opennet.ru/opennews/art.shtml?num=56609
Че-то уже третья новость про обновление uutils. Я имею сказать:
* Несмотря на все вбуханные усилия, среднестатичтический configure пока не работает(ну, ладно, на состояние 2 месяца назад).
* Размер busybox-style статического бинаря для busybox - 1.5MB, coreutils - 2.5MB, uutils - 10MB(опять же, на состояние пару месяцев назад, сейчас проверить не могу, потому что Rust у меня уже не запускается). Надо еще понимать, что в busybox в 3 раза больше утилит, там и cron, и dhcp, и util-linux, и так далее. Но они вообще упоротые, читать их код очень интересно.
* Зачем переписывать простой код, который и память-то особо не выделяет, я не понимаю. Какой от этого added value?
👍3
У меня сегодня большой день - я перенес загрузчик на свою партицию, и загрузился с него. Старые FS и линуксы можно стирать, окончательно перерезав пуповину с материнской системой.
Это оказалось сложнее, чем я думал, потому что разработчик efibootmgr сошел с ума.
https://github.com/rhboot/efivar
Там сделано вообще все возможное, чтобы код не собирался ничем, кроме gnu toolchain, хотя никакого особого смысла в этом нет(спойлер - все собралось и заработало с clang), и чтобы не работала статическая сборка.
https://github.com/rhboot/efivar/blob/main/src/include/workarounds.mk
Вот тут автор якобы поддерживает lld, но проваливаемся мы в not supported case.
Автор явно вызывает gcc-ar, вместо ar. Что, зачем...
Автор в системе сборки написал кодогенерацию ld script, котрый хитроумно переименовывает символы в итоговых библиотеках и бинарях, чтобы окончательно запутаться.
Автор очень широко использует расширения gnu libc(я это называю горе от ума), мне ажно пришлось реализовать функцию qsort_r самому - https://github.com/pg83/mix/blob/main/pkgs/lib/qsort/r/mix.sh#L15. Я, конечно, тот еще кулхацкер и ленивая жопа, но сохранять контекст и реальный коллбек в пертредных переменных - это даже для меня мощно.
Систему переименований символов я заменил на систему регулярок поверх исходного кода.
У чувака есть файлик safemath.h вот такого содержания - https://github.com/rhboot/efivar/blob/main/src/safemath.h
Он пишет эту простую утилиту непрерывно с 12 года, и ему явно стало скучно.
Короче, запускать получившийся grub мне было ссыкотно - там или все отработает, или попортит таблицу разделов, и я останусь с кирпичом вместо ноутбука, 50 на 50.
Все обошлось.
Сейчас форматирую освободившийся большой раздел под XFS(а вы знали, что старичок - все еще одна из лучших FS для Linux?), и переношу систему на него. #xfs
Это оказалось сложнее, чем я думал, потому что разработчик efibootmgr сошел с ума.
https://github.com/rhboot/efivar
Там сделано вообще все возможное, чтобы код не собирался ничем, кроме gnu toolchain, хотя никакого особого смысла в этом нет(спойлер - все собралось и заработало с clang), и чтобы не работала статическая сборка.
https://github.com/rhboot/efivar/blob/main/src/include/workarounds.mk
Вот тут автор якобы поддерживает lld, но проваливаемся мы в not supported case.
Автор явно вызывает gcc-ar, вместо ar. Что, зачем...
Автор в системе сборки написал кодогенерацию ld script, котрый хитроумно переименовывает символы в итоговых библиотеках и бинарях, чтобы окончательно запутаться.
Автор очень широко использует расширения gnu libc(я это называю горе от ума), мне ажно пришлось реализовать функцию qsort_r самому - https://github.com/pg83/mix/blob/main/pkgs/lib/qsort/r/mix.sh#L15. Я, конечно, тот еще кулхацкер и ленивая жопа, но сохранять контекст и реальный коллбек в пертредных переменных - это даже для меня мощно.
Систему переименований символов я заменил на систему регулярок поверх исходного кода.
У чувака есть файлик safemath.h вот такого содержания - https://github.com/rhboot/efivar/blob/main/src/safemath.h
Он пишет эту простую утилиту непрерывно с 12 года, и ему явно стало скучно.
Короче, запускать получившийся grub мне было ссыкотно - там или все отработает, или попортит таблицу разделов, и я останусь с кирпичом вместо ноутбука, 50 на 50.
Все обошлось.
Сейчас форматирую освободившийся большой раздел под XFS(а вы знали, что старичок - все еще одна из лучших FS для Linux?), и переношу систему на него. #xfs
GitHub
GitHub - rhboot/efivar: Tools and libraries to work with EFI variables
Tools and libraries to work with EFI variables. Contribute to rhboot/efivar development by creating an account on GitHub.
🔥9👍7🤔1
https://maskray.me/blog/2022-01-16-archives-and-start-lib #maskray
Рассказ про изобретение thin archive.
Я однажды их изобрел сам, и использовать их, конечно, не нужно.
История изобретения:
Однажды вышел clang с поддержкой lto, и я очень захотел собрать с ней базовый поиск. LTO там было сделано на отъебись - компилятор мог родить .o файл с промежуточным представлением, и на этом все.
Эти объектные файлы нельзя было объединить в .a, нельзя было позвать clang для линковки. Единственное, что там было - это команда "opt", которая могла слинковать несколько lto .o файлов в 1, попутно применив оптимизации, была команда, которая делала asm файл из этого .o, а дальше можно было взять этот asm, руками сделать из него настоящий .o, и слинковать все это вместе с системным кодом, для которого нет lto .o файлов.
Короче, я на петончиге соорудил подобие архиватора и линкера из этих примитивов, и оно даже заработало. В тот момент мне стало понятно, что гораздо проще в .a запиклить* пути к lto .o, чем пиклить данные, а потом разпикливать их в fs, для запуска "opt". Так я изобрел thin archives.
Простые утилиты я так сумел собрать, но не базовый. Для базового не хватило памяти, lto, если вы вспомните, тогда был уж очень прожорливый.
Почему их не нужно использовать.
* На HDD это приводило к бешеному росту iops, по понятным причинам. На ssd это менее релевантно.
* Даже на ssd остается проблема с readahead - мы читаем с диска существенно больше данных, чем надо.
Ладно, есть 1 случай, когда thin archives немного помогают. Если у вас до жопы памяти, и вы потребляете архивы сразу по мере изготовления(one shot build, например), некое ускорение можно наблюдать.
Но лучше не надо, потому что ускорение эфемерно, а огрести при нехватке памяти все еще можно.
* - literally. pickle.dumps(sys.argv[2:]) - вот примерное устройство моего ar.
Рассказ про изобретение thin archive.
Я однажды их изобрел сам, и использовать их, конечно, не нужно.
История изобретения:
Однажды вышел clang с поддержкой lto, и я очень захотел собрать с ней базовый поиск. LTO там было сделано на отъебись - компилятор мог родить .o файл с промежуточным представлением, и на этом все.
Эти объектные файлы нельзя было объединить в .a, нельзя было позвать clang для линковки. Единственное, что там было - это команда "opt", которая могла слинковать несколько lto .o файлов в 1, попутно применив оптимизации, была команда, которая делала asm файл из этого .o, а дальше можно было взять этот asm, руками сделать из него настоящий .o, и слинковать все это вместе с системным кодом, для которого нет lto .o файлов.
Короче, я на петончиге соорудил подобие архиватора и линкера из этих примитивов, и оно даже заработало. В тот момент мне стало понятно, что гораздо проще в .a запиклить* пути к lto .o, чем пиклить данные, а потом разпикливать их в fs, для запуска "opt". Так я изобрел thin archives.
Простые утилиты я так сумел собрать, но не базовый. Для базового не хватило памяти, lto, если вы вспомните, тогда был уж очень прожорливый.
Почему их не нужно использовать.
* На HDD это приводило к бешеному росту iops, по понятным причинам. На ssd это менее релевантно.
* Даже на ssd остается проблема с readahead - мы читаем с диска существенно больше данных, чем надо.
Ладно, есть 1 случай, когда thin archives немного помогают. Если у вас до жопы памяти, и вы потребляете архивы сразу по мере изготовления(one shot build, например), некое ускорение можно наблюдать.
Но лучше не надо, потому что ускорение эфемерно, а огрести при нехватке памяти все еще можно.
* - literally. pickle.dumps(sys.argv[2:]) - вот примерное устройство моего ar.
MaskRay
Archives and --start-lib
.a archives Unix-like systems represent static libraries as .a archives. A .a archive consists of a header and a collection of files with metadata. Its usage is tightly coupled with the linker. An arc
👍3
commit -m "better"
https://hardcoresoftware.learningbyshipping.com/p/061-bsod-to-watson-the-reliability Забавно. Товарищ (из Microsoft?) считает, что качество софта улучшилось, когда ввели телеметрию. Плохая статья. На пути к хорошему софту было 3 этапа: 1) Перестали писать…
Я тут обратил внимание, что, после перехода с fedora на мою сборку ядра(и вообще, полностью на свой rootfs), мои configure скрипты стали на вид ощутимо быстрее. Померял,
dash + coreutils: 23s
У меня нет объяснения, кроме замены btrfs на xfs, и своим ядром без всего там лишнего. Наверное, существенное отличие - у меня full rt ядро, но это должно улучшать latency и ухудшать throughput, а мы видим другое.
UPD: подумал еще раз - у меня включены THP, и mimalloc по умолчанию(а он старается использовать THP, если они есть).
dash + coreutils: 23s
У меня нет объяснения, кроме замены btrfs на xfs, и своим ядром без всего там лишнего. Наверное, существенное отличие - у меня full rt ядро, но это должно улучшать latency и ухудшать throughput, а мы видим другое.
UPD: подумал еще раз - у меня включены THP, и mimalloc по умолчанию(а он старается использовать THP, если они есть).
commit -m "better"
Я тут обратил внимание, что, после перехода с fedora на мою сборку ядра(и вообще, полностью на свой rootfs), мои configure скрипты стали на вид ощутимо быстрее. Померял, dash + coreutils: 23s У меня нет объяснения, кроме замены btrfs на xfs, и своим ядром…
Мне, все же, кажется, что это FS. Я проверил еще и #F2FS:
dash + coreutils: 20s
BTW, мне очень импонирует идея log structured fs(я не знаю, почему, но мне кажется, что это "натуральный" способ строить FS), поэтому попробую пожить с корнем на ней.
Arch не советует - https://wiki.archlinux.org/title/F2FS, но и терять мне особо нечего, rootfs я восстанавливаю за 5 минут.
dash + coreutils: 20s
BTW, мне очень импонирует идея log structured fs(я не знаю, почему, но мне кажется, что это "натуральный" способ строить FS), поэтому попробую пожить с корнем на ней.
Arch не советует - https://wiki.archlinux.org/title/F2FS, но и терять мне особо нечего, rootfs я восстанавливаю за 5 минут.
Собирал тут boost. Люди, которые меня хорошо знают, удивятся - я же известный boost hater. #gold
Не себе, для дела. Boost требуется для сборки Inkscape, а Inkscape нужен для рендера иконок в теме Adwaita(это, кстати, та еще кольцевая зависимость, потому что иконки требуются для gtk, а gtk нужен для сборки inkscape, ну да ладно). #svg
Для этого пришлось бутстрепнуть B2, оно же бывший bjam. Удивительно, но в ней нет поддержки кросс-компиляции, хотя, конечно, авторы утверждают обратное.
Давайте я поясню, что я имею в виду, когда говорю, что система сборки поддерживает кросс компиляцию: #cross #cmake
* Возможность указать компилятор и cflags - это НЕ поддержка кросс-компиляции, потому что без "раздвоения" сборочного графа это приводит к невозможности собирать проекты, которым требуется строить host тулзы во время сборки(если host != target). cmake, bjam - отличные представители.
* Кросс-компиляция начального уровня - когда сборочная система знает про HOSTCC, TARGETCC, и позволяет описать разные части сборочного графа используя разные *CC. Например, make, ninja(без надстроек над ними), autoconf.
* Кросс-компиляция второго уровня - когда можно для таргета сборки указать, host он, или target, а далее сборочная система сама правильно подставит HOSTCC, TARGETCC. meson - прекрасный представитель.
* "Высшая" кросс-компиляция - когда любым таргетом можно оперировать как в контексте host, так и target. Все будет сделано прозрачно для пользователя. ya, bazel(buck? честно, не знаю так глубоко). Кстати, Mix тоже(с поправкой на то, что не все таргеты в OSS принципиально можно кросс-компилировать).
Теперь к B2/BJAM:
* https://www.bfgroup.xyz/b2/manual/release/index.html#bbv2.tasks.crosscompile - нет разделения на target/host вообще.
* https://github.com/bfgroup/b2/blob/main/bootstrap.sh#L26 - позорище, facepalm, запуск свежесобранной target тулзы для инсталляции ея же.
Не себе, для дела. Boost требуется для сборки Inkscape, а Inkscape нужен для рендера иконок в теме Adwaita(это, кстати, та еще кольцевая зависимость, потому что иконки требуются для gtk, а gtk нужен для сборки inkscape, ну да ладно). #svg
Для этого пришлось бутстрепнуть B2, оно же бывший bjam. Удивительно, но в ней нет поддержки кросс-компиляции, хотя, конечно, авторы утверждают обратное.
Давайте я поясню, что я имею в виду, когда говорю, что система сборки поддерживает кросс компиляцию: #cross #cmake
* Возможность указать компилятор и cflags - это НЕ поддержка кросс-компиляции, потому что без "раздвоения" сборочного графа это приводит к невозможности собирать проекты, которым требуется строить host тулзы во время сборки(если host != target). cmake, bjam - отличные представители.
* Кросс-компиляция начального уровня - когда сборочная система знает про HOSTCC, TARGETCC, и позволяет описать разные части сборочного графа используя разные *CC. Например, make, ninja(без надстроек над ними), autoconf.
* Кросс-компиляция второго уровня - когда можно для таргета сборки указать, host он, или target, а далее сборочная система сама правильно подставит HOSTCC, TARGETCC. meson - прекрасный представитель.
* "Высшая" кросс-компиляция - когда любым таргетом можно оперировать как в контексте host, так и target. Все будет сделано прозрачно для пользователя. ya, bazel(buck? честно, не знаю так глубоко). Кстати, Mix тоже(с поправкой на то, что не все таргеты в OSS принципиально можно кросс-компилировать).
Теперь к B2/BJAM:
* https://www.bfgroup.xyz/b2/manual/release/index.html#bbv2.tasks.crosscompile - нет разделения на target/host вообще.
* https://github.com/bfgroup/b2/blob/main/bootstrap.sh#L26 - позорище, facepalm, запуск свежесобранной target тулзы для инсталляции ея же.
www.bfgroup.xyz
B2 User Manual
👍1
#svg
С иконками, я, конечно, намучался.
* Пути к дефолтным иконкам в тулкитах.
* Какие иконки должны быть.
* Часть иконок в Adwaita лежит в png, часть - в svg, эти множества частично пересекаются. Что выберет то или иное приложение, одному (хз знает кому) известно. В svg лежат ЧБ иконки, в png - цветные.
* Загрузка svg устроена через плагин для gdk-pixbuf. Плагины для него устроены самым ненатуральным образом из всех мне известных(постараюсь написать про то, как извращенно разработчики устраивают загрузку своих плагинов). К сожалению, последняя версия этого плагина, не переписанная на Rust, не очень корректно рендерит последние иконки от Adwaita.
* Отладка "чего там реально загружается" через strace не очень помогает, так как каждая папка с иконками должна содержать индекс.
Так и живем - для качественного рендеринга в png требуется inkscape, для некачественного на лету - Rust.
К сожалению, компилятор Rust у меня сейчас даже не запускается, потому что он принципиально не может быть слинкован статически.
Вся надежда на https://github.com/thepowersgang/mrustc #mrustc, чувак все ближе и ближе к тому, чтобы поддержкать 1.54. Понятное дело, что без borrow checker, но кому оно надо не в процессе разработки? У него своя реализация proc macro(по понятным причинам), не требующая подгрузки .so в компилятор.
Я сейчас остановился на svg иконках с не совсем корректным рендерингом, потому что облизывать Epiphany уже поднадоело(https://wiki.gnome.org/Apps/Web). Надо посмотреть, что ждет на пути сборки Chromium.
Кстати, я почти победил тиринг в Epiphany. Для этого я собрал webkit web process(который занимается непосредственно рендерингом) на gtk4, в котором все лучше с поддержкой opengl/vulkan канвы, а сам браузер с gtk3. Потому что Igalia уже портировала WebKIT на gkt4, а сам браузер - еще нет. Думаю, Igalia подавились бы чем-нибудь на радостях, узнав, что я так делаю. #igalia
С иконками, я, конечно, намучался.
* Пути к дефолтным иконкам в тулкитах.
* Какие иконки должны быть.
* Часть иконок в Adwaita лежит в png, часть - в svg, эти множества частично пересекаются. Что выберет то или иное приложение, одному (хз знает кому) известно. В svg лежат ЧБ иконки, в png - цветные.
* Загрузка svg устроена через плагин для gdk-pixbuf. Плагины для него устроены самым ненатуральным образом из всех мне известных(постараюсь написать про то, как извращенно разработчики устраивают загрузку своих плагинов). К сожалению, последняя версия этого плагина, не переписанная на Rust, не очень корректно рендерит последние иконки от Adwaita.
* Отладка "чего там реально загружается" через strace не очень помогает, так как каждая папка с иконками должна содержать индекс.
Так и живем - для качественного рендеринга в png требуется inkscape, для некачественного на лету - Rust.
К сожалению, компилятор Rust у меня сейчас даже не запускается, потому что он принципиально не может быть слинкован статически.
Вся надежда на https://github.com/thepowersgang/mrustc #mrustc, чувак все ближе и ближе к тому, чтобы поддержкать 1.54. Понятное дело, что без borrow checker, но кому оно надо не в процессе разработки? У него своя реализация proc macro(по понятным причинам), не требующая подгрузки .so в компилятор.
Я сейчас остановился на svg иконках с не совсем корректным рендерингом, потому что облизывать Epiphany уже поднадоело(https://wiki.gnome.org/Apps/Web). Надо посмотреть, что ждет на пути сборки Chromium.
Кстати, я почти победил тиринг в Epiphany. Для этого я собрал webkit web process(который занимается непосредственно рендерингом) на gtk4, в котором все лучше с поддержкой opengl/vulkan канвы, а сам браузер с gtk3. Потому что Igalia уже портировала WebKIT на gkt4, а сам браузер - еще нет. Думаю, Igalia подавились бы чем-нибудь на радостях, узнав, что я так делаю. #igalia
GitHub
GitHub - thepowersgang/mrustc: Alternative rust compiler (re-implementation)
Alternative rust compiler (re-implementation). Contribute to thepowersgang/mrustc development by creating an account on GitHub.
👍2
#fontconfig #font
Ох. Шрифты. Я надеялся, что до этой темы не дойду :) Потому что могу написать раз в 5 больше, чем на страницах про fontconfig/gtk/etc у Arch и Gentoo, вместе взятых(https://wiki.archlinux.org/title/font_configuration).
Писать столько мне, конечно, лень, поэтому я пройдусь по самым интересным вещам, возможно, потом будет вспоминаться что-то еще.
Про то, что уже писал(например, про то, что fontconfig должен быть демоном), повторяться не буду. Про проблемы старых механизмов типа X server fonts, Xft, тоже писать не буду, в этом нет никакого смысла, да и объем бы сильно увеличило.
Казалось бы, очень простая задача - приложение хочет шрифт X, с параметрами A=a, B=b, C=c, и надо вернуть или его outline, или растеризованные картинки.
Задача сильно облегчается тем, что приложение в системе Linux может ожидать в наличии всего 4 шрифта, с именами "sans", "serif", "monospace", "system-ui"(+ алиасы к ним). Все остальные шрифты могут и не найтись, приложение(например, браузер) должно обеспечить их наличие само.
Проблема номер раз - тулкиты и их разработчики.
Тулкиты, конечно, не смогли договориться, где хранятся настройки, отображающие эти несчастные 4 алиаса в настоящие имена шрифтов. Поэтому ожидать, что в fontconfig придет какое-то нормализованное имя, типа "serif", и оно вернет шрифт для него, ожидать не приходится. Вот мое ненависное Epiphany посылает вместо "sans" -> "Cantarell". И, кстати, не потому, что так где-то зашито в gtk, а, насколько я понял, это результат разрешения какого-то цикла в резолве имен(об этом чуть позже).
Проблема номер 2 - fontconfig и его разработчики. Fontconfig, конечно, появился тогда, когда задача "поставить какой-то конкретный шрифт на машину" была принципиально неразрешима. И когда какое-то приложение просит там Arial, надо было вернуть хоть что-то, минимально похожее. Поэтому там нагородили каких-то странных циклов в резолве имен:
https://github.com/freedesktop/fontconfig/blob/master/conf.d/45-latin.conf#L281
https://github.com/freedesktop/fontconfig/blob/master/conf.d/60-latin.conf#L75
Реально же цикл, который решается тем, что какое-то из этих определений weak. Обратите внимание на слово Cantarell, и на то, что оно идет первым. Возможно, Epiphany таки и посылает "sans", но после цикла в нормализации мы получаем что-то странное.
Поэтому раздебажить, почему тупо не работает моя локальная настройка, которая говорит, что для system-ui надо вернуть Segoe UI, а оно возвращает DejaVu Sans, решительно невозможно.
В fontconfig, конечно, есть FC_DEBUG=, но, удивительный факт, оно не печатает на экран ту строку с именем шрифта, что запросило приложение. Потому что строка сначала парсится, и нормализуется(в набор алиасов) уже в процессе парсинга, а не мэтчинга.
Я попробовал убрать все дефолтные правила из fontconfig, но, с налету, так не заработало. Почему? Хер его знает. Дебажить это сложно.
Поэтому простая, с виду, задача - "написать конфиг с маппингом 4 строк на реальные шрифты" превращается в леденящий душу пиздец.
Про то, где вообще брать шрифты, и что ожидает в наличии дефолтовый Linux - в следующей серии.
Ох. Шрифты. Я надеялся, что до этой темы не дойду :) Потому что могу написать раз в 5 больше, чем на страницах про fontconfig/gtk/etc у Arch и Gentoo, вместе взятых(https://wiki.archlinux.org/title/font_configuration).
Писать столько мне, конечно, лень, поэтому я пройдусь по самым интересным вещам, возможно, потом будет вспоминаться что-то еще.
Про то, что уже писал(например, про то, что fontconfig должен быть демоном), повторяться не буду. Про проблемы старых механизмов типа X server fonts, Xft, тоже писать не буду, в этом нет никакого смысла, да и объем бы сильно увеличило.
Казалось бы, очень простая задача - приложение хочет шрифт X, с параметрами A=a, B=b, C=c, и надо вернуть или его outline, или растеризованные картинки.
Задача сильно облегчается тем, что приложение в системе Linux может ожидать в наличии всего 4 шрифта, с именами "sans", "serif", "monospace", "system-ui"(+ алиасы к ним). Все остальные шрифты могут и не найтись, приложение(например, браузер) должно обеспечить их наличие само.
Проблема номер раз - тулкиты и их разработчики.
Тулкиты, конечно, не смогли договориться, где хранятся настройки, отображающие эти несчастные 4 алиаса в настоящие имена шрифтов. Поэтому ожидать, что в fontconfig придет какое-то нормализованное имя, типа "serif", и оно вернет шрифт для него, ожидать не приходится. Вот мое ненависное Epiphany посылает вместо "sans" -> "Cantarell". И, кстати, не потому, что так где-то зашито в gtk, а, насколько я понял, это результат разрешения какого-то цикла в резолве имен(об этом чуть позже).
Проблема номер 2 - fontconfig и его разработчики. Fontconfig, конечно, появился тогда, когда задача "поставить какой-то конкретный шрифт на машину" была принципиально неразрешима. И когда какое-то приложение просит там Arial, надо было вернуть хоть что-то, минимально похожее. Поэтому там нагородили каких-то странных циклов в резолве имен:
https://github.com/freedesktop/fontconfig/blob/master/conf.d/45-latin.conf#L281
https://github.com/freedesktop/fontconfig/blob/master/conf.d/60-latin.conf#L75
Реально же цикл, который решается тем, что какое-то из этих определений weak. Обратите внимание на слово Cantarell, и на то, что оно идет первым. Возможно, Epiphany таки и посылает "sans", но после цикла в нормализации мы получаем что-то странное.
Поэтому раздебажить, почему тупо не работает моя локальная настройка, которая говорит, что для system-ui надо вернуть Segoe UI, а оно возвращает DejaVu Sans, решительно невозможно.
В fontconfig, конечно, есть FC_DEBUG=, но, удивительный факт, оно не печатает на экран ту строку с именем шрифта, что запросило приложение. Потому что строка сначала парсится, и нормализуется(в набор алиасов) уже в процессе парсинга, а не мэтчинга.
Я попробовал убрать все дефолтные правила из fontconfig, но, с налету, так не заработало. Почему? Хер его знает. Дебажить это сложно.
Поэтому простая, с виду, задача - "написать конфиг с маппингом 4 строк на реальные шрифты" превращается в леденящий душу пиздец.
Про то, где вообще брать шрифты, и что ожидает в наличии дефолтовый Linux - в следующей серии.
👍9🔥5👏1🤔1😢1
Продолжение про шрифты. Если вчера было про "как", то сегодня будет про "что". #font
В целом, у меня стоит очень простая задача - выбрать какое-нить не очень вырвиглазное семейство шрифтов, которое ставить по умолчанию.
20 лет назад эта задача имела очевидное решение - нужно было украсть ttf шрифты с ближайшей инсталляции Windows, потому что шрифты, которые шли вместе с X, были ужасны. Microsoft, кстати, не только мышки классные делает, но и шрифты. Не, конечно, были шрифты от Кнута(Type1, metafont), но у дяди довольно странный вкус.
Потом в Linux появилось семейство dejavu(https://dejavu-fonts.github.io/), а потом Ubuntu нарисовала пару хороших шрифтов, и стало попроще. Уже можно было не воровать, и иметь при этом более-менее приличные шрифты.
В общем, сейчас выбор по умолчанию для любого дистрибутива - это DejaVu fonts + что-то со своим вкусом.
Обойтись совсем БЕЗ DejaVu особо не получается, потому что есть глифы, которые ни один приличный разработчик шрифтов рисовать не захочет, а люди ими зачем-то пользуются.
Чтобы далеко не ходить - вчера наткнулся на такого странного человека. https://vermaden.wordpress.com/2022/02/04/books-about-freebsd/ И у нас сегодня задачка по бутстрапу!
Определите, к какому юникодному классу символов относится текст из заголовка вышеуказанной страницы, и определите, каким шрифтом ваш браузер(или ваш WM, в моем случае) рендерит этот заголовок.
Короче, я для себя задачу дефолтных шрифтов решил так:
* DejaVu, как фоллбек для всех извращений
* Classic Microsoft Fonts(arial, helvetica, times new roman, etc) - для всяких сайтов, которые по привычке указывают эти шрифты. Вопреки расхожему мнению, эти шрифты можно использовать бесплатно, распространять только нельзя. Бывают metric compatible шрифты, но зачем мне заниматься этим скучным анализом, если доступен качественный оригинал?
* Какое-нить семейство для sans и serif шрифтов
* system-ui и monospace я решил никак не покрывать, потому что все равно каждый себе выберет что-то свое(я вот выбрал Segoe UI + Consolas)
Осталось выбрать sans и serif шрифты.
Эту задачу я решил решать так - найти подходящий foundry, и выбрать у него какое-нить очень популярное семейство, которое есть под все популярные языки.
Мои варианты:
* Google Noto
* Google Roboto
* Неожиданно, но IBM Plex
Adobe не попало под "подходящий foundry", потому что она шрифты продает, а, значит, у их бесплатных шрифтов будут какие-то интересные stringsincluded attached.
По совокупности причин(общий размер, покрытие языками, привлекательность) я пока остановился на IBM Plex. Noto тоже хороши, но очень уж объемны(в мегабайтах), и немного узковаты(на мой вкус).
Имею сказать, что подход IBM к разработке(поменьше творчества и побольше waterfall), конечно, очень благоприятно сказался на их шрифте - без изъебов, ничем не выделяется, просто не мешает читать текст.
В целом, у меня стоит очень простая задача - выбрать какое-нить не очень вырвиглазное семейство шрифтов, которое ставить по умолчанию.
20 лет назад эта задача имела очевидное решение - нужно было украсть ttf шрифты с ближайшей инсталляции Windows, потому что шрифты, которые шли вместе с X, были ужасны. Microsoft, кстати, не только мышки классные делает, но и шрифты. Не, конечно, были шрифты от Кнута(Type1, metafont), но у дяди довольно странный вкус.
Потом в Linux появилось семейство dejavu(https://dejavu-fonts.github.io/), а потом Ubuntu нарисовала пару хороших шрифтов, и стало попроще. Уже можно было не воровать, и иметь при этом более-менее приличные шрифты.
В общем, сейчас выбор по умолчанию для любого дистрибутива - это DejaVu fonts + что-то со своим вкусом.
Обойтись совсем БЕЗ DejaVu особо не получается, потому что есть глифы, которые ни один приличный разработчик шрифтов рисовать не захочет, а люди ими зачем-то пользуются.
Чтобы далеко не ходить - вчера наткнулся на такого странного человека. https://vermaden.wordpress.com/2022/02/04/books-about-freebsd/ И у нас сегодня задачка по бутстрапу!
Определите, к какому юникодному классу символов относится текст из заголовка вышеуказанной страницы, и определите, каким шрифтом ваш браузер(или ваш WM, в моем случае) рендерит этот заголовок.
Короче, я для себя задачу дефолтных шрифтов решил так:
* DejaVu, как фоллбек для всех извращений
* Classic Microsoft Fonts(arial, helvetica, times new roman, etc) - для всяких сайтов, которые по привычке указывают эти шрифты. Вопреки расхожему мнению, эти шрифты можно использовать бесплатно, распространять только нельзя. Бывают metric compatible шрифты, но зачем мне заниматься этим скучным анализом, если доступен качественный оригинал?
* Какое-нить семейство для sans и serif шрифтов
* system-ui и monospace я решил никак не покрывать, потому что все равно каждый себе выберет что-то свое(я вот выбрал Segoe UI + Consolas)
Осталось выбрать sans и serif шрифты.
Эту задачу я решил решать так - найти подходящий foundry, и выбрать у него какое-нить очень популярное семейство, которое есть под все популярные языки.
Мои варианты:
* Google Noto
* Google Roboto
* Неожиданно, но IBM Plex
Adobe не попало под "подходящий foundry", потому что она шрифты продает, а, значит, у их бесплатных шрифтов будут какие-то интересные strings
По совокупности причин(общий размер, покрытие языками, привлекательность) я пока остановился на IBM Plex. Noto тоже хороши, но очень уж объемны(в мегабайтах), и немного узковаты(на мой вкус).
Имею сказать, что подход IBM к разработке(поменьше творчества и побольше waterfall), конечно, очень благоприятно сказался на их шрифте - без изъебов, ничем не выделяется, просто не мешает читать текст.
𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗
Books About FreeBSD
There are many books in which FreeBSD is covered or it is the one of the main objectives of such book. Today I will guide you through these books. I will try to focus on more up to date ones becaus…
👍2
Уважаемые, а правда же, что zram swap в 15% от MEM - это исключительно хорошо, и ничем не плохо(ну, кроме как для странного случая "моя программа хочет ровно 95% MEM")?