Т.е. здесь вместо

Copyright (C) 2004 Sam Hocevar <sam@hocevar.net> 

вписать

Copyright (C) 2021-2666 Моё Имя <моё@мыло> 

?

А то вдруг этот (c) относится к автору собственно текста лицензии, а себя любимого я должен ещё куда-нибудь вписать (e.g. AUTHORS.txt).

Если после ввода неправильного пароля сразу нажать Ctrl+C (т.е. послать этому su не помню уж какой сигнал), то можно не дожидаться таймаута перед сообщением «Authentication failure», и перебирать пароли гораздо быстрее.

Как? Набрёл на вот такое:

char buf[SIZE];
freopen("/dev/null", "a", stdout);
setbuf(stdout, buf);

ЯННП как это работает. Почему /dev/null на вход stdout? Каким боком это к задаче его перехвата?

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

С примером на пальцах если можно. В вике слишком сжато. Нашлась ещё какая-то Rust API дока, но от тамошнего английского у меня глаза на клавиатуру вытекли.

И вот, недели не прошло как я поставил artix:

• https://forum.artixlinux.org/index.php/topic,3331.msg21592.html#msg21592

• https://forum.artixlinux.org/index.php/topic,3334.msg21597.html#msg21597

Там где гента матюгнулась бы ещё в процессе сборки пакета, тут мы обнаруживаем ошибку, пытаясь открыть pdf-ку.

1. Сначала в иксах – и удивляемся, почему сначала ничего не происходит, а потом вместо моего любимого qpdfview вдруг пытается вылезти firefox (ему запретил: # chown root:root ~me/.mozilla; chmod …), а потом chromium (этот сука успешно).

2. Потом в консоли – с подозрением на альцгеймер полез в ~/.config/mimeapps.

3. Потом вызвал из консоли qpdfview и увидел что .so не найден.

4. Потом ldd ``which qpdfview``, so не увидел.

5. Потом догадался # pacman -S pax-utils; lddtree ``which qpdfview``.

6. Потом вспомнил, что обновлялось 3 qt-шных пакета сразу, нашёл их в /var/log/pacman.log, по двум другим вызвал `pacman -Ql {package} | grep -F .so’, по найденным .so прогнал dlltree чтобы убедиться, что они тоже битые.

7. Ручками отдаунгрейдил 3 пакета (вместе с libreoffice – 4) и прописал в игнор-лист в /etc/pacman.conf.

В будущем этот путь будет короче (как минимум без п.4), но всё равно – напороться на косяк в процессе работы (причём в данном случае – умеренно-срочной) крайне неприятно.

Сижу думаю над правильным аналогом гентушного revdep-rebuild; неправильный в AUR есть и он ни о чём т.к. не различает обязательные и опциональные зависимости. И вообще на питоне написан.

Правильно ли я понял:

1. .MTREE нужен для установки пакета: в нём прописано с какими правами нужно создавать каталоги и т.д. Он копируется в /var/lib/pacman/local/*/mtree ради pacman -Qk. В каждой строчке по дефолту type=file, mode=хз-что-да-и-пох.

2. Непонятно: зачем атрибут time в каждой строчке?

3. pacman -Qo использует не mtree, а files, который генерится в момент установки.

Поставил я пакет nvidia (то бишь блоб). Разрешение в консоли конечно же слетело*, но иксы стартуют в нативном разрешении безо всяких xorg.conf (как и полагается).

Вопрос в сабже. А точнее:

1. Встанут ли драйвера amd и intel рядом с nvidia, не будет ли каких-нибудь конфликтов (типа как при установке nvidia блэклистится nouveau)?

2. Будут ли иксы сами определять, какой из драйверов загружать? Или от меня потребуются какие-то дополнительные пляски? (Какие?)

3. Какие нынче драйвера нынче в моде – для amd (там была какая-то свистопляска) и для intel? С именами пакетов плиз.

4*. (праздное любопытство) Вроде ж была не так давно новость, что nvidia пилят что-то вокруг framebuffer? Не смог найти.

1. Это версия чего?

2. Кто выводит это сообщение? Грепом 'Starting version' в /usr/lib/initcpio не нашёл.

«Multiple providers» bla-bla-bla. Чаще всего выбор из world (artix-репа, эквивалент арчевой extra) и extra (arch-репа). По дефолоту предлагает world (что логично: она в pacman.conf объявлена выше) (UPD: что попало по дефолту предлагает), однако даже тупо жать enter на все вопросы не то чтобы сильно влом, но как-то глупо.

У меня всё.

Если кто не понял: хрен бы с ней с компиляцией, но вычисление зависимостей, поиск пакета-владельца файла и т.п. – pacman делает мгновенно, в то время как на «самом быстром дистре» emerge, equery, eix пердолятся часами.

Вопрос раз. Идея, что большая часть работы PID1 выполняется в early init (stage1) и shutdown (stage3), и весь этот код не нужен в аптайме (stage2) – очень толковая. Идея реализации этого принципа через три разных процесса, переход между которыми – тупо exec() без fork() – шикарная. Т.е. все три процесса имеют PID1. На stage1 работает s6-linux-init, на stage2 – лёгкий s6-svscan, и их функционал не пересекается. А вот с shutdown ЯННП:

1.1. Схренали в stage2 (т.е. весь аптайм) висит supervised-демон s6-linux-init-shutdownd? Прямо нарушая всю идею.

1.2. Схренали ли скрипты /run/service/.s6-svscan/{crash,finish} оба вызывают s6-linux-init-hpr -fr (forced reboot)? Т.е. получается, что в модели «exec() следующей stage из предыдущей» stage3 – это не shutdown, а исключительно мгновенный ребут в случае падения, а логический shutdown выполняется в рамках stage2.

1.3. Схрена ли s6-svscan по SIGTERM сначала останавливает супервизоры (и управляемые ими процессы), дожидается их завершения – и опять-таки проваливается в finish т.е. в forced reboot. Чем это отличается от shutdownd? Ну наверное можно найти чем: shutdownd вызывает /etc/s6/current/scripts/rc.shutdown, который вызывает s6-rc (полагаю, для остановки сервисов; доки подсистемы s6-rc ещё не читал). Т.е. по идее это более «корректная» остановка сервисов, чем тупо остановка long-running процессов, но всё равно ощущается как задвоение функционала с shutdownd.

1.4. И отсюда: почему нельзя было сделать так, чтобы по SIGTERM s6-svscan exec()-ался не в {crash,finish}, а в какой-нибудь другой скрипт, выполняющий честный stage3 (shutdown / halt / reboot), с вызовом s6-rc и всё такое?

Вопрос два. Аргументация, что /sbin/init должен быть сверхмаленьким и сверхнадёжным, – логична. Но: тут же этот s6-svscan под тем же рутом поднимает кучу процессов s6-supervise – по одному на сервис (точнее на long-running supervised process). Отсюда сразу две непонятки:

2.1. Схрена ли нельзя было все сервисы обслуживать одним супервайзером?

2.2. Схрена ли нельзя было объединить s6-svscan и s6-supervise, раз уж они один хрен все под рутом. (Впрочем, на эту тему автор что-то писал: мол, даже если супервайзер какой-то подохнет, PID1 останется жив. Но я не уверен, насколько это серьёзная аргументация.)

Вообще, я выбрал s6 т.к. повёлся на манифест его автора «нахрена ещё одна init-система», и может быть когда-нибудь в итоге даже и порадуюсь – мол какой я умный, разобрался и даже без 66 обошёлся. Но пока что чёт страшновастенько как-то…

Перемещено alpha из admin

Имеется:

std::map<K,V> cache;
void updateCache(K k, V v) {
    auto it = cache.find(k);
    if (it == cache.end() || it->second.value != v) {
        cache[k] = v;
        persistCache();
    }
}

Как бы мне в строчке cache[k] = v; избежать повторного поиска ключа в map, а заюзать вместо этого уже имеющийся it?

Чтобы какой-нибудь nginx конфиг перечитал, не перезапускаясь.

В artix вики пишут:

Restart # sv restart service_name
Reload  # sv restart service_name 

В gentoo вики пишут:

The sv reload and sv try-restart commands are equivalent to sv -v hup, sv -v term respectively

Я правильно понимаю, что SIGHUP процессу это reload и есть, т.е. гентушная документация правильная?

И в догонку: какие в openrc есть фичи, которых нет в runit? Шоб такскать знать, чего потеряю. Например: есть ли dependencies override аналогично openrc-шному need !net net.eth0 в /etc/conf.d/...?

А то пишут, что дескать возможны проблемы если устанавливаемый из AUR пакет зависит от systemd. Это что, автоматом никак не отслеживается? Т.е. e.g. раз systemd в арче один хрен обязателен, то и в зависимости пакетов он нигде не прописывается – ни в AUR, ни в других цепляемых артиксом арчевых репах?

Кстати, артикс вообще юзает по дефолту арчевы репы? И как там в этом Artix вообще с пакетами?

Имеется Qt-прога myapp. Её главное окно соответственно имеет WM_CLASS=myapp (это неизменяемое поведение Qt) и заголовок «mycaption». Имеется открытый QtCreator с заголовком окна «globals.h (src @ myapp) …».

Вызываемое из самой этой проги fork() + execl("/usr/bin/wmctrl", "-x", "-a", "myapp", (char*)nullptr) не работает (активирует QtCreator если в заголовке его окна есть myapp, иначе ничего не делает), а вот system("wmctrl -x -a myapp") работает (активирует окно проги).

В чём может быть фокус? Не хочу лишний шелл вызывать.

// myMainWindow->activateWindow() не предлагать, оно поднимает окно в своём виртуальном десктопе, который может быть неактивен. Средствами Qt это не решается, задрачиваться с EWMH не имею желания.

Здрасьти.

Гента уже давно пытается мне навязать pipewire-сервер как замену pulseaudio-серверу, вот решил попробовать.

У меня браузеры сидять под отдельными юзерами, и хочется чтобы в них тоже звук был. В pulseaudio это решается (вероятно опцией auth-anonymous=1).

В pipewire – не могу найти подходящей опции, чтобы сделать unix сокет общедоступным:

# cp /usr/share/pipewire/pipewire-pulse.conf /etc/pipewire/
# vi /etc/pipewire/pipewire-pulse.conf
...
    {   name = libpipewire-module-protocol-pulse
        args = {
        # the addresses this server listens on
            server.address = [
                # dimgel: Вписал сюда то же, что и в /etc/pulse/*.
                "unix:/tmp/pulse-socket"

...
# ls -l /tmp/pulse-socket 
srwxr-xr-x 1 me me 0 2021-09-27 20:25:53.158629941 /tmp/pulse-socket

И звук есть только под моим основным юзером.

UPD. Юзать TCP вместо unix socket не предлагать: это дичь.

UPD2. Solved.

Нашёл у себя в makefile камент:

# После перехода на gcc:11 попробовал заюзать модули (объявил модуль test_MyClass_module в файле test_MyClass.cpp),
# но в .d-файлах генерируется что-то невразумительное, e.g.:
#     main.o: test_MyClass_module.c++m
#     CXX_IMPORTS += "test_MyClass_module.c++m"
# Да и QtCreator модуль не находит. Независимо от того, пихаю я gcm.cache в корень проекта или в target
# (для чего вызывал makefile из target, подкрутив в нём все пути).

Что делать с этими *.c++m и CXX_IMPORTS, откуда брать *.c++m и как всё это юзать в makefile? Хрен бы с ним с QtCreator пока что.

Что ни обновление qt5ct, то все цвета слетают. Твари. Нашёл свои заметки, как лечил прошлый раз – и хрен. Кто ещё нарывался? Как лечили?

Кастомная цветовая схема, лежит в ~/.config/qt5ct/colors/dimgel.conf. При запуске qt5ct после обновления ко всем цветам добавился префикс «ff» (альфа-канал). В диалоге qt5ct выбор любой кастомной цветовой схемы (с последующим выходом-входом из иксов) ничего не меняет, схема остаётся дефолтная (например в pcmanf-qt, gwenview и моих собственных qt-поделках). QT_QPA_PLATFORMTHEME=qt5ct в environment есть, как и QT_LOGGING_RULES="qt5ct=false", и даже QT_PLATFORM_PLUGIN=qt5ct (без которого впрочем до сих пор всё работало). Откат на 1.1 (с восстановлением конфига из бэкапа) не помог.

UPD. Починили в qt5ct-1.5; текущая версия qtgui-5.15.2-r13.

Если сам арч 64bit only? Смутно помнится, что для 32-битных игр в арче нужно только nvidia-блоб 32-битный водрузить. Но гента, например, для поддержки 32бит требует не только wine и nvidia с ABI_X86=«32 64», но и огромную прорву их зависимостей.

Ау, растаманы! Почему нельзя вместо

fn f(x: &impl Trait1) -> impl Trait2 

писать

fn f(x: &Trait1) -> Trait2 

? Trait – не first class тип? Это бред, но даже если так: и что? Или может возможен конфликт одинаковых имён структуры и trait? Короче, смахивает на синтаксический оверхед.

UPD. Ну и вдогонку, чтобы дважды не вставать: «we can’t implement external traits on external types» – это не просто дичь, а просто дичь. Ну и аргументация трындец: «Without the rule, two crates could implement the same trait for the same type, and Rust wouldn’t know which implementation to use.». Вот когда конфликт возникнет, тогда и ругались бы на него.

UPD2. fn vs fun – зачем отдельный keyword для лямбд?