Вот, пожалуйста, как и предполагалось, свежий gcc - https://www.opennet.ru/opennews/art.shtml?num=59038

Я думаю, что так гнали с релизом, чтобы запустить сокращения?

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

Есть цифровая часть звукового тракта, которая, условно говоря, идет от провайдера (Spotify, Я.Музыка), до ЦАП (пусть это будет bluetooth колонка/наушники).

По мере прохождения сигнала, он пару раз пережимается с потерями (mp3/ogg/aac/whatever, ldac), и пару раз перенормируется по громкости (провайдер, приложение, bluetooth). Где-то громкость идет out of band (метаинформация), а где-то может происходить ресемплинг при сжатии (я не знаю, как и где).

Какие нужны настройки, и что проверить, чтобы убедиться, что громкость везде идет out of band, чтобы, финально, было одно умножение на Г1*...*Гn? А не чтобы любимое (умножили X перекодировали)^m?

Короче, как меньше всего информации потерять при передаче?

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

Расскажите, как правильно.

https://www.memorysafety.org/blog/sudo-and-su/

Какие-то ноунеймы решили хайпануть, и переписали sudo/su на Rust. Я бы у них хотел вежливо спросить "а su-то зачем, на нем нет suid bit".

А еще мне в голову пришла гениальная идея по поводу безопасности suid бинарей. Мне в последнее время вообще много хороших идей про безопасность приходит!

А давайте соберем важные #suid бинари, типа sudo, с санитайзерами, и так и выложим в прод?

Вот, реально, собрать их с asan, msan, ubsan, и так и катить.

Вместо того, чтобы эскалировать привилегии почем зря, будут просто падать с нормальным таким panic().

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

Полезного эти утилиты все равно ничего не делают, небольшое замедление им не страшнО.

The 2-MAXSAT Problem Can Be Solved in Polynomial Time


Comments   on lobsters

"Hence, we provide a proof of P = NP"

https://felipec.wordpress.com/2023/03/04/one-decade-later-gnome-still-sucks/

Обычный #rant про #GNOME, текст интересен ссылками, которых я раньше не видел.

Here’s another lovely example from a gnome-terminal bug:

No.

CHRISTIAN PERSCH

Ну и так далее.

Для комментариев.

https://gvisor.dev/blog/2023/04/28/systrap-release/

Текст про #gvisor.

Приятно, что проект жив и развивается. Считаю, что за таким вот очень lightweight sandbox большое будущее. Напомню, что контейнеры - не sandbox, а вот KVM и gvisor - sandbox (KVM в большей степени, gvisor - в меньшей).

Хотел прекратить читать текст после того, как увидел график про getpid, потому что это нечестное сравнение (в одном случае используется vdso, в другом, очевидно, нет), и люди, которые этот график нарисовали, не могли про это не знать.

Используемая техника довольно стандартная, "а давайте перезапишем mov ..., eax; syscall на какой-нить подходящий jmp".

Ускорение вполне заметное, хотя, конечно, не такое впечатляющее, как график про getpid.

https://github.com/carbon-language/carbon-lang/discussions/2807

#carbon

Очередной transparency report, а вы чего ждали? Кода?

https://www.phoronix.com/news/Linux-6.4-x86-Mem-Copy

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5624566431de76b17862383d9ae254d9606cba9

Дед опять забыл принять таблетки, и буянит

На мой неискушенный взгляд, Линус зачем-то выделил часть кода из двух файлов в один новый, и назвал это рефакторингом, с объяснением на страницу текста.

Мне кажется? Я в глаза долблюсь?

Вышел новый #musl, https://musl.libc.org/releases.html

Постоянство - признак мастерства, новые версии выходят раз в год, примерно в одно и то же время.

Запилили в dns resolver поход по TCP, вот только я приспособил #dnsmasq, ага.

Убрали макросы stat64, lstat64, и прочее барахло для совместимости с API glibc. Сломали сборку примерно всего кода, ожидающего glibc-style API по поддержке 64-битных оффсетов, печаль-беда.

#dbus #systemd #kdbus

https://www.phoronix.com/news/Ubuntu-23.10-Dbus-Broker-Plan

dbus-broker - это замена dbus-daemon, но:

* linux-only
* https://github.com/bus1/dbus-broker/blob/main/meson.build#L76 довольно безальтернативно зависит от libsystemd, без нее глючит в плане запуска процессов
* зависит от каких-то велосипедных библиотек для С - https://github.com/c-util, https://github.com/bus1/dbus-broker/blob/main/meson.build#L24 Факт того, что уже есть безальтернативная зависимость от #glib, никого не волнует - это не +-1, это +1 велосипедная либа

И все это для чего? Для того, чтобы показать эфемерный выигрыш в производительности. Ага, для десктопной шины, которая должна тумбнейлеры запускать, это, конечно, очень важно.

Вот тут я могу несколько плавать, но появилось все это после того, как Линус окончательно отказался запихивать dbus в ядро, и чем-то же надо было заняться.

Мораль? Да какая мораль, все равно нас всех скоро заменит AI, пусть кожаные порезвятся напоследок.

С musl, и с их чисткой "ненужного" кода, конечно, попандос.

https://github.com/bminor/binutils-gdb/blob/master/gdbserver/linux-low.cc#L5384

Вот, gdb, например, при configure, считает, что pread64 больше нет, потому что смотрит на линкер, а не на компиляцию. И в данном ifdef попадает на fallback, компиляция которого валится каким-то интересным образом.

Или, вот, например, как валится сборка std crate через #mrustc:

ld.lld: error: undefined symbol: open64
>>> referenced by libstd.rlib.c
>>>               .../libstd.rlib.o:

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

Нормального способа в musl узнать про наличие той или иной фичи нет, и это их принципиальная позиция.

Я пока откатил версию musl к херам.

Ночной (уже) #rant

У меня продолжает бомбить от обновления #musl, да.

Есть такое, довольно популярное мнение, что мы "должны" open source'у, и что надо тащить все изменения в #upstream, неважно, насколько там упоротые мейнтейнеры.

Я с этим категорически не согласен, ничего мы никому не должны, кроме того, что написано в файле LICENSE.txt.

Вот, возьмем данную ситуацию.

Что я якобы "должен" сделать?

* Сходить к Ричарду Фелкеру, и попытаться его убедить, что надо дать людям возможность узнать версию musl, с которой ты собираешься, чтобы по этой информации сделать какой-либо вывод? Да щаз, он в readme своего проекта написал, что этого не будет никогда (https://wiki.musl-libc.org/faq.html "Why is there no MUSL macro?"), а он же не может ошибиться?

* Сходить к авторам configure/autoconf скриптов, и рассказать, как "правильно" детектить наличие тех или иных фичей? Так никто не знает, как "правильно", даже Фелкер, потому что есть тесты на собираемость, и есть тесты на linkability, и они в C/C++ могут давать разный результат, из-за "define pread64 pread" https://git.musl-libc.org/cgit/musl/tree/include/unistd.h#n203 - какой-то класс тестов может не скомпилироваться, какой-то - не слинковаться.

* Сходить к авторам rust (компания пидорасов, не забываем про это!), и сказать им, что не надо руками писать интерфейсы к libc - https://github.com/rust-lang/rust/blob/master/library/std/src/sys/unix/mod.rs#L98 ?

К кому из этих трех обобщенных высокомерных мудаков мне сходить? В чем убедить?

Правильно, я пойду к самому близкому ко мне высокомерному мудаку с сильным мнением - к себе!

Мое "сильное мнение" в данном вопросе - не надо чинить то, что не сломано, и пошел бы Фелкер со своим мнением к херам.

Он удалил функции, я их вернул назад. Без патчинга исходников, просто скопировал символы - https://github.com/pg83/ix/commit/632e40fdcb56917c19f9299c165b56d77052675b#diff-d0dfd80046e1a8679abbcdebbc7ee3984b5b75653d63cc2469ec0ee6427b7c20R25

Думаю, я в хорошей компании!

Призывал и буду призывать владельцев open source софта всегда делать официальный бекап на github.

Потому что github самый надежный, а ваш sr.ht/repo.cz/gitlab/whatever однажды ляжет, и поднимать его будут неделю.

Поэтому я всегда радовался, какие же хорошие люди с freedesktop. Несмотря на то, что у них есть свой gitlab, до сего момента у большинства их проектов был mirror на github, чем я и пользовался. Их gitlab периодически лежал, и мешал релизным процессам.

Но нет, нет покоя дуракам, все снесли - https://github.com/freedesktop/

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

https://github.com/GNOME тоже, наверное, долго не продержится, а жаль.

Коллега написал хвалебную статью про какой-то новый компилируемый заменитель питона, как будто мало их - https://www.fast.ai/posts/2023-05-03-mojo-launch.html #mojo

К языку имеет отношение небезызвестный Крис Латтнер (который LLVM/Swift/etc), поэтому я пошел почитать документацию.

Сломался я на https://docs.modular.com/mojo/programming-manual.html#using-the-mojo-compiler "You can run a Mojo program from a terminal just like you can with Python. So if you have a file named hello.mojo (or hello.🔥—yes, the file extension can be an emoji!)" - слушайте, ну пусть зумеры и хипстеры на таком программируют, а мне это даже не кажется смешным, если это шутка.

Наверное, опять какая-то попытка хайпануть на Python/ML/AI/whatever.

Между прочим, тот, кто сегодня провисел весь день на главной https://lobste.rs/, и даже пару часов висел на первом месте - тот я!

Это прямо классно, в каком-то смысле, большое дело и достижение!

(не просьба накрутить лайки, если что)

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

Статья от Amazon Prime про то, как можно сэкономить кучу бабла, перейдя с микросервисов на монолит. Это все, само по себе, давно известно и никому не интересно.

Но, знаете ли, пока я читал эту статью, у меня не проходило ощущение какого-то пиздеца. Потому что Amazon должен писать другие статьи - про то, как надо пилить все на микросервисы, запускать их в Лямбде и Функциях, и иметь свой "web scale".

Потому что вот эта вот неэффективность за счет масштабируемости - это же хлеб Амазона, они это продают.

Пчелы против меда какие-то, короче.