https://fosstodon.org/@drewdevault/111739063243946284

sr.ht/codeberg лежат второй день подряд.

И я, как обычно, когда лежат васянские гиты (а sr.ht/codeberg/прочие gitlab - это все васянские гиты), призываю все проекты иметь заркала на github.

Слушайте, ну меня это реально сильно, прямо сильно удивляет.

Почему есть мнение, что "ddos может отразить каждый", "надежная инфра - это просто", "этим может заниматься кто угодно", и так далее?

Почему считается, что, если человек написал компилятор/операционную систему/wayland композитор/пакетный менеджер, то он сможет построить надежный распределенный сервис? Это, вообще говоря, не очень связанные умения и навыки.

Вот, реально, кесарю - кесарево, а слесарю - слесарево.

Не используйте васянские сервисы, или имейте зеркало где-то еще.

#rant

https://www.phoronix.com/news/GNU-Hurd-x86_64-2023-Progress

Не понимаю, зачем кто-то вообще пишет новости про #gnu #hurd. Пациент, совершенно точно, мертв.

Вот, например, цитата от его разраба:

"Building packages is not very stable. I have been trying to build gcc-13 for a couple of weeks, without success so far. There are various failures, most often odd errors in the libtool script, which are a sign that the system itself is not behaving correctly. A way to reproduce the issue is to just repeatedly build a package that is using libtool, sooner or later that will fail very oddly.

This means that while the buildd will be ready, I'm really not at ease with letting it start, knowing that it can behave erratically. When I built the initial set of packages for debian-ports (~100 packages), I got something like 5-10 such failures, that's quite high of a rate :/"

Курам на смех, конпелятор пересобирается через раз, рандомные bash скрипты падают со странными ошибками, и оно не может пересобрать себя из под себя (то есть, не self hosted).

https://outage.sr.ht/

Пара цитат:

"In our emergency planning models, we have procedures in place for many kinds of eventualities. What has happened this week is essentially our worst-case scenario: “what if the primary datacenter just disappeared tomorrow?” We ask this question of ourselves seriously, and make serious plans for what we’d do if this were to pass, and we are executing those plans now – though we had hoped that we would never have to"

Вот любой человек, который занимается инфрой профессионально, вам скажет - "не надо гадать/молиться/надеяться, надо проверять". Надо регулярно actually отключать ваш самый важный ДЦ, и убеждаться, что вы без этого работаете, или делать задачки, чтобы оно после этого работало.

"Unfortunately, our colocation provider went through two acquisitions in the past year, and we failed to notice that our account had been forgotten as they migrated between ticketing systems through one of these acquisitions. Thus unable to page them, we were initially forced to wait until their normal office hours began to contact them, 7 hours after the start of the incident"

Какой отсюда надо сделать вывод?

* Мелким потребителям не дают прямой телефон людей, которые что-то могут реально сделать в ДЦ. Крупным - дают, или у них свой крупный ДЦ.

* Люди, которые не занимаются инфрой постоянно, проигнорируют проблемы у провайдера ровно до тех пор, пока оно не выстрелит.

Вообще, хороший текст, почитайте.

https://www.reddit.com/r/programminghorror/comments/18x7vk9/why_does_everyone_keep_telling_me_to_use_c/

Утащу из комментариев, это прекрасно.

https://mstdn.social/@RickyRomero/111666711075000961

Чувак запилил симулятор экрана iphone (как пиксели отображаются на ромбовидные точки на экране), и, после этого, запилил гиперреалистичный рендер экрана iphone, используя шейдер на основе этого симулятора.

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

https://blog.tenstral.net/2024/01/wayland-really-breaks-things-just-for-now.html

Классный текст про #wayland.

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

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247

Хочу подробнее остановиться на

"Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps"

Здесь аккуратно написано про следующий факт - люди, которые могут закоммитить новый протокол в wayland (например, позволяющий точно позиционировать окна), по странному стечению обстоятельств, являются стейкхолдерами (в том или ином виде) в kwin(KDE)/gnome shell/wlroots.

И вертели они на хую любые предложения и протоколы, которые не вписываются в их модели работы с десктопом в целом, и окнами приложений, в частности.

Вот, например, зачем человеку, который отвечает за все tiling композиторы принимать proposal, в котором можно разрешить приложению управлять своим положением на экране?

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

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

Собственно, это все описано вот тут - https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%81%D0%B5%D0%BD%D1%81%D1%83%D1%81#%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0

Что с этим делать - непонятно, потому что у владельцев репы с wayland-protocols нет никаких стимулов что-то менять (https://cyclowiki.org/wiki/%D0%9F%D1%87%D1%91%D0%BB%D1%8B_%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2_%D0%BC%D1%91%D0%B4%D0%B0 ), а всем остальным договориться о том, чтобы брать эти протоколы из другого места, кажется нереалистичным.

https://asahilinux.org/2024/01/fedora-asahi-new/ #asahi

Кажется, проблемы с батарейкой коллеги тоже научились решать.

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

Печалит то, что, для того, чтобы достигать приемлемого уровня качества сервиса, коллегам приходится распихивать по всему стеку Linux подпорки для оборудования от Apple, что-то типа "классной психоакустической модели для встроенных в ноутбук колонок в виде plugin к pipewire", и написано оно все на Rust - https://github.com/chadmed/bankstown, то есть, повторить (в #stal/ix) это будет совсем не просто.

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

Я или переоцениваю сложность этой задачи (например, потому что ничего в этом не понимаю), или там какое-то совершенно дикое количество энтузиастов, среди которых есть и такие специалисты. Кода там не очень много, но он весьма специфичный - https://github.com/chadmed/bankstown/blob/main/src/lib.rs

#gnome moment

https://discourse.gnome.org/t/dealing-with-glib-and-gobject-introspection-circular-dependency/18701

В полку сумасшедших прибыло - теперь у нас официально есть кольцевая зависимость glib <-> gobject-introspection (вдобавок к https://xn--r1a.website/itpgchannel/202).

Нормальные люди (оценочное суждение) кольцевые зависимости рвут, ненормальные - документируют, и потом, втихую, наслаждаются страданиями package maintainers.

Иииии rust наносит ответный удар!

https://www.phoronix.com/news/GCC-Rust-Developer-Discussion
https://lore.kernel.org/git/CALNs47s3tUQoOD4ejdoTn6y12ywjL0j5hWU-fUnBLe_o3vV5SQ@mail.gmail.com/T/

Будни #bootstrap

Все же знают историю про то, что размер спейсшаттлов является прямой функцией от ширины задницы лошади?

Вот, в паре скриптов в пакете с gzip нашел прекрасное:

# WARNING: the first line of this file must be either : or #!/ix/store/gF4xURAJ
as4kd5vU-bin-dash-sh/bin/sh
# The : is required for some old versions of csh.
# On Ultrix, /ix/store/gF4xURAJas4kd5vU-bin-dash-sh/bin/sh is too buggy, change
 the first line to: #!/ix/store/gF4xURAJas4kd5vU-bin-dash-sh/bin/sh5

Что тут написано?

Что когда-то, очень давно, в этом скрипте стояли прямые ссылки на /bin/sh, и вот про них было написан комментарий людям, которые бы редактировали этот shell script - мол, под каким-то там Ultrix (что это?) /bin/sh может не работать, берите /bin/sh5.

Но, после серии рефакторингов, и, насколько я понимаю, замены прямой ссылки на /bin/sh на ссылку на shell, найденный в момент выполнения ./configure, случился такой странный казус.

Получается, что мой dash, лежащий в /ix/store, может так себе работать под какой-то несуществующей OS.

https://lobste.rs/s/lgwcpb/statement_regarding_ongoing_sourcehut#c_zz1to9

Из обсуждения этой темы на lobste.rs узнал, что #ddv (ну и еще парочка его коллег) был там забанен пару лет назад, за слишком агрессивный маркетинг sr.ht, https://en.wikipedia.org/wiki/Rage_farming.

Это, конечно, немного в другом свете освещает историю про нападки #ddv на #hyprland https://xn--r1a.website/itpgchannel/1337

#gnu, невменяемые мейнтейнеры

Я как-то рассказывал, что слежу за свежими апдейтами через repology.org. И там, довольно регулярно, настолько, что я обратил на эту странность внимание, ровно про две программы, приходит новая версия, в довольно странном формате - readline 8.2_p10, bash 5.2_p26.

Довольно долго не понимал, что же это за _pX, в "гнусном" ftp/http лежат вот ровно эта версия - 8.2 - https://ftp.gnu.org/pub/gnu/readline/

Оказывается, _p10 - это вот патчи из https://ftp.gnu.org/pub/gnu/readline/readline-8.2-patches/, которые нужно скачать отдельно, и наложить на основные исходники.

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

https://github.com/pg83/ix/blob/main/pkgs/lib/readline/ix.sh#L3-L26

Мягко говоря, не очень удобно, надо вручную прописывать url, sha, и накладывать патч.

В первый раз такое вижу.

Ладно, во второй, еще так делает ядро, но там их можно понять - ядро довольно большое, и лет 20 назад имело смысл качать diff, вместо нового снепшота, потому что ты платишь за каждый мегабайт.

#linux #kernel #ci

https://www.phoronix.com/news/Linux-6.8-Sched-Regression

TL;DR - в процессе слияния ядра 6.8 Линус заметил, что, когда он собирает свежее ядро, будучи загруженным в это свежее ядро (#bootstrap), то у него это ядро собирается в 2 раза медленнее.

Тут, конечно, интересна не причина регрессии, а процесс.

Даже до Миши с фороникса начинает доходить, что что-то в консерватории не так, если такие валенки на пульте находит не автоматизированный CI, а лично Линус в процессе мержа:

"For regressing a workload like code compilation speeds being halved is rather surprising as while the Linux kernel lacks common and robust continuous integration (CI), it seems like kernel developers responsible for the changes would notice such a dramatic change... Especially if the code has been through linux-next and the like"

Все, буквально все (кроме старых линуксхакеров - https://xn--r1a.website/itpgchannel/264), уже понимают, что одна из самых важных программ в индустрии не может разрабатываться ТАК. Ну, то есть, может, но только в 10 раз медленнее, или дороже, чем могла бы.

Треш, угар, содомия.

Особенно смешно на этом фоне смотрится, как Линус материт Intel за то, что они не тестируют свой код перед мержем - https://www.phoronix.com/news/Torvalds-Unhappy-Linux-6.8-DRM

Будни #bootstrap, #stal/ix

Тут вот коллеги подкинули ссылку на смешной способ сделать Dockerfile исполняемым. https://gist.github.com/adtac/595b5823ef73b329167b815757bbce9f

Ничего особо интересного, просто "волшебный" шебанг, который сделает всю работу:

#!/usr/bin/env -S bash -c "docker run...

Я тут сразу вспомнил, что это не будет работать в Alpine Linux, ну только если они не стали специально патчить busybox. Руками я это предположение не проверял, но патчи от Alpine на busybox прогрепал - https://git.alpinelinux.org/aports/tree/main/busybox?h=master

Дело в том, что опция -S не является стандартной, и без нее env не будет токенизировать строчку символов, которую ему надо будет запустить, поэтому, если в команде есть пробелы, будет ошибка.

Вот, смотрите, его разбор command line аргументов: https://elixir.bootlin.com/busybox/latest/source/coreutils/env.c#L60

Все остальные /usr/bin/env, до которых я дотянулся, опцию -S поддерживают. В том числе, *BSD, Darwin, GNU coreutils, и прочая, и прочая.

Меня, в свое время, это поведение не устроило, и я решил, что главный в своем дистрибутиве я, а не сумасшедший автор busybox, который упоролся по минимализму и не сделал полезный флаг.

Поэтому я взял, и спиздил env из bsdutils https://github.com/dcantrell/bsdutils (цельнопижженные из FreeBSD утилиты):

* Размер их статически слинкованного env всего 50k. В coreutils в несколько раз больше, у gnu очень bloated софт.

* Не хочу иметь ничего от #GNU в базовой системе

* Так уж случилось, что я однажды уже опакетил bsdutils - https://xn--r1a.website/itpgchannel/65, поэтому это был наиболее быстрый способ.

Вот, у меня env из bsdutils - https://github.com/pg83/ix/blob/main/pkgs/set/system/0/unwrap/ix.sh#L36, у меня такой скрипт имеет шанс запуститься:

pg# /usr/bin/env -h
/usr/bin/env: unrecognized option: h
usage: env [-0iv] [-L|-U user[/class]] 
    [-P utilpath] [-S string] 
    [-u name]
    [name=value ...] 
    [utility [argument ...]]

Мораль?

* В хозяйстве все сгодится, рано или поздно.

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

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

Как говорится, гора родила мышь, потому что эти 400 человек не осилили сделать OS общего назначения, судя по всему.

TIL новое слово - Еггогология.

https://ru.wikipedia.org/wiki/%D0%95%D0%B3%D0%B3%D0%BE%D0%B3%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F

New comic
https://stonetoss.com/comic/iron-crossed/