https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212

#GNOME #gtk moment

К чувакам пришли с реализацией уже принятого в wayland протокола, на что им, в своей уникальной манере, ответили, что для GTK/GNOME от реализации этого протокола пользы не будет. Речь идет о server side cursor. Попытка решить очень древнюю проблему с неконсистентностью курсовров в разных приложениях (напомню, что поверхность с курсором отдает клиент, и это может быть вообще все, что угодно).

Они, на полном серьезе, сравнивают курсор (который, на минуточку, может быть отрисован не только клиентом, а еще композитором, когда курсор находится вне любого клиента, или клиентом другого DE), и рендеринг шрифтов - https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212#note_2056112

Цикл моих заметок про курсоры в Wayland:

https://xn--r1a.website/itpgchannel/185
https://xn--r1a.website/itpgchannel/1214
https://xn--r1a.website/itpgchannel/246
https://xn--r1a.website/itpgchannel/854
https://xn--r1a.website/itpgchannel/1758

Нет слов.

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

А вот "правильный" заход в #Wayland - #SDL говорят, что не будут включать Wayland по дефолту, пока им не запилят два нужных расширения. И тут уж коллегам из Wayland придется прогнуться, потому что один из основных потребителей SDL - Valve, которая сейчас пилит половину десктопного кода под Linux (стек драйверов, компиляторов шейдеров, да и свои компизиторы у них есть https://github.com/ValveSoftware/gamescope). Все #хорошее в графическом стеке Linux делают корпорации!

Будьте уверены, в данном вопросе все пойдет, как по маслу. Потому что одно дело, когда что-то нужно сообществу, тогда можно поломать комедию и повыебываться, а другое дело - когда оно нужно уважаемым людям, которые непосредственно вас кормят.

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

"а мне 3 ящика водки, и Михаила обратно" (шутка, понятная узкому кругу лиц, хехе)

#vendor

Пришлось на днях снова применить "кузькину мать".

На этот раз по тележеньке - https://github.com/pg83/ix/commit/d64dfd7a674571ee331df253942cef270851f72e

Потому что эти господа, видимо, наслаждаются своей ересью в виде scudo allocator (https://xn--r1a.website/itpgchannel/1494). А мне мил мой #tcmalloc (https://xn--r1a.website/itpgchannel/328), потому что с ним памяти жреть меньше, и скроллинг плавнее.

У меня со scudo allocator тоже собрана пара программ, типа ssh server, который я использую для эскалации привилегий в системе, там это оправдано.

Так как конечный продукт, в итоге, собираю я, то я и навязал свою точку зрения в виде tcmalloc.

Если у вас, вдруг, есть доступ на машину по ssh, но нет по sftp (а такое зачем-то бывает!), то всегда можно сделать

cat x | gzip | ssh user@host 'gzip -d > x'

А так же сюда можно добавить tar, и вообще все, что угодно.

Так же это работает и в обратную сторону (только не забудьте обрезать message of the day).

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

Интересно, зачем в современных 64-битных системах нужна защита памяти?

Казалось бы, поместил программу и ее данные по рандомному адресу, и тогда злоумышленник просто не сможет ее найти во всем адресном пространстве, потому что, каждый раз когда он будет промахиваться, его будут убивать, ну и потому что 64 бит - это ОЧЕНЬ много.

Я понимаю, что современные CPU используют меньше 64 бит, и что надо как-то защищать небольшую часть операционной системы, которая являлась бы gate для входа в нее, но, все же?

Действительно годные советы от коучей, наконец-то.

Programmer memes

https://www.davd.io/posts/2024-03-20-kubernetes-and-back-why-i-dont-run-distributed-systems/

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

Конечно проще все поставить на один хост, без кворумов, перезапросов, и прочей лабуды.

https://www.swift.org/blog/adwaita-swift/
https://github.com/AparokshaUI/adwaita-swift

Чуваки запилили биндинги gtk + adwaita к swift.

Идея прикольная, потому что не на С с Vala же gui программирвать, и не на Python.

Я вот для себя совершенно точно знаю, что, если я захочу запилить gui на gtk, то я возьму golang.

Swift кажется тоже годной альтернативой.

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

В копилочку. #fork

О-че-редь. Огромная очередь. За любым популярным проектом. Стоит лишь раз ошибиться.

И, в целом, это очень хорошо, потому что нехуй набирать пользователей под лозунгом "халява", а потом переобуваться на лету.

Самое интересное, что, кажется, у компаний, которые идут по этому пути, нет особого выбора.

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

Такой хороший бесплатный инкубатор идей софта для больших облаков, и ничего личного.

https://www.opennet.ru/opennews/art.shtml?num=60860 просто оставлю тут очередную #cve про #ksmbd.

(а некоторые меня спрашивают, почему я отказываюсь использовать NFS из ядра)

https://www.phoronix.com/news/Inkscape-Switches-To-GTK4

Inkscape как-то очень быстро и решительно запилили поддержку gtk4.

Я почему-то, смотря на gimp, думал, что они не переедут примерно никогда, потому что переписать с одной версии gtk на другую - ну, чуть мнее сложно, чем переписать вообще на другой тулкит.

Видимо, здесь дело в разнице между сильно типизированным языком (С++), и слабо типизированным (С).

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

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

#xz_gate

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

Не менее прекрасно и то, как эксплоит был найден:

https://mastodon.social/@AndresFreundTec/112180406142695845

"I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.

Really required a lot of coincidences"

А что же #stal/ix?

А stal/ix эксплоиту не подвержен, по двум причинам:

* IFUNC не работает со статической линковкой. Это ограничение не принципиально, можно и завести, но всем лень.

* Более интересная причина - потому что я проактивно борюсь с такого рода возможностью, когда сумасшедший мейнтейнер может учудить, и не беру tgz, сваренные человеком, а беру tgz, сваренные системой контроля версий (прямые ссылки на архивы бранчей и коммитов) - https://xn--r1a.website/itpgchannel/93.

UPD: https://github.com/tukaani-project/xz - репу закрыли :(

github - контора пидорасов. Дважды пидорасов.

Потому что, по сути, они закрыли источник кода без наложенного вредоноса (https://github.com/tukaani-project/xz). Ну и сломали большое количество CI по всему миру.

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

В Rust std нет семафоров, их выпиляли давным-давно. Решил поискать готовое, но лучше бы сразу сделал велосипед.

Зато нашел вот такие перлы. Рукалицо, дайте мне это развидеть.

Всегда проверяйте чужой код (даже если он из std - тоже проверяйте).

Истории про мою home #lab.

Заебался я на самом деле с этой загрузочной флешкой.

Много чего было, расскажу про две проблемы.

Первая - то, что root fs пытается настроиться до того, как проинициализирован usb controller.

Сука, это леденящий душу пиздец.

GRUB загружает ядро Linux, передает в загрузчик ядра partition uuid, а потом Linux не может найти этот partition uuid, потому что разделы на флешке еще не пронумерованы, потому что система их еще не нашла.

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

Дебажил это реально несколько часов.

Решение?

Слушайте, вот как бы эту проблему решил нормальный разраб? Я бы написал там какой-то retry, с exponential backoff, пытаясь примонтировать rootfs до того момента, когда инициализация драйверов не будет полностью завершена.

Конечно, это было бы слишком просто, и работало бы слишком хорошо, поэтому это явно не Linux-way.

Заботливые кернел-какеры предлагают вот такую опцию - https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re58.html. Ну, типа, сделайте sleep 20, наверняка за это время все usb устройства будут найдены.

Леденящий душу пиздец. Программирование многопоточных программ на sleep, ага.

Истории про мою home #lab.

И вторая проблема - а как написать правильную конфигурацию GRUB, чтобы не надо было заморачиваться с probe всего и вся?

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

В итоге, решил я это так:

* На первой партиции, в которой лежит EFI, я кладу же и сам GRUB, с его конфигом, который устроен вот так:

https://github.com/pg83/lab/blob/master/lab/services/mk/boot.sh#L19-L28

set root=hd0,2
configfile /etc/grub.cfg
set root=hd1,2
configfile /etc/grub.cfg
set root=hd2,2
configfile /etc/grub.cfg
set root=hd3,2
configfile /etc/grub.cfg
set root=hd4,2
configfile /etc/grub.cfg

А дальше, на второй партиции лежит уже настоящий конфиг, который адресован относительно root:

https://gist.github.com/pg83/7941d82e39c6a019ce184e01572ed62d

GRUB тут себя ведет, как POSIX sh без set -e, то есть, просто пропускает все неуспешные команды, пока не сможет попасть в реально существующий конфиг.

Работает like a charm, загружается на любом моем конфиге.

Вообще, это максимально простое устройство самозагружающейся флешки, которое я видел, как говорится, дарю.

Истории про home #lab.

Пока я переводил хосты на новую схему загрузки (с флешкой в качестве /dev/root), мне несколько раз пришлось пошатать #etcd.

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

Два раза все прошло хорошо, на третий раз я осмелел, и решил устроить ученьки с disaster recovery.

Взял, и под живым инстансом etcd забил его базу из /dev/random, дождался, пока это все не дошло до кластера, ребутнул, переналил на новую схему, поднял пустой инстанс etcd.

В общем, провел пару часов за чтением документации, кластер оживил.

Но это было несколько сложнее, чем я ожидал.

Потому что кворум из двух машин перевел этот третий инстанс в состояние "never again", то есть, пометил его id как сломанный навсегда, и отказывался с ним иметь дело даже после переналивки.

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

Зачем так сложно, и зачем эта процедура отличается от предыдущей, не очень понятно.

Зато, КМК, теперь я получил некоторый опыт, и уверенность, что, в случае чего, данные в etcd я не проебу, и мне теперь не сташно класть туда какие-то master/original данные, а не только легко восстановимые копии.