Правильно ли я понял:
.MTREE нужен для установки пакета: в нём прописано с какими правами нужно создавать каталоги и т.д. Он копируется в /var/lib/pacman/local/*/mtree ради pacman -Qk. В каждой строчке по дефолту type=file, mode=хз-что-да-и-пох.
Непонятно: зачем атрибут time в каждой строчке?
pacman -Qo использует не mtree, а files, который генерится в момент установки.
Поставил я пакет nvidia (то бишь блоб). Разрешение в консоли конечно же слетело*, но иксы стартуют в нативном разрешении безо всяких xorg.conf (как и полагается).
Вопрос в сабже. А точнее:
Встанут ли драйвера amd и intel рядом с nvidia, не будет ли каких-нибудь конфликтов (типа как при установке nvidia блэклистится nouveau)?
Будут ли иксы сами определять, какой из драйверов загружать? Или от меня потребуются какие-то дополнительные пляски? (Какие?)
Какие нынче драйвера нынче в моде – для amd (там была какая-то свистопляска) и для intel? С именами пакетов плиз.
4*. (праздное любопытство) Вроде ж была не так давно новость, что nvidia пилят что-то вокруг framebuffer? Не смог найти.
Это версия чего?
Кто выводит это сообщение? Грепом '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 для лямбд?
Ковыряю тут сорцы постгреса, и нарвался на реализацию типа numeric (он же decimal). Сабж, каждая цифра хранится в int16. По здравому размышлению – логично: делать арифметику сразу на группах по 4 цифры эффективнее, чем на каждой десятичной цифре отдельно.
После всех этих срачей (e.g. из последнего), возник панимаеш ли вопрос о текущем состоянии умов умищ на ЛОРе.
Тыц / Possible implementation: зачем нужны оба test_pre_is_base_of()? Сначала не понял про первый, тупо закомментил его – и вроде всё работает. Потом заинлайнил второй – и опять работает:
namespace details {
template <typename B> std::true_type test_pre_ptr_convertible(const volatile B*);
template <typename> std::false_type test_pre_ptr_convertible(const volatile void*);
}
template <typename Base, typename Derived> struct is_base_of : std::integral_constant<
bool,
std::is_class<Base>::value &&
std::is_class<Derived>::value &&
decltype(details::test_pre_ptr_convertible<Base>(static_cast<Derived*>(nullptr)))::value
> {};
class A {};
class B {};
class D : public B {};
static_assert(is_base_of<B, D>::value);
static_assert(!is_base_of<A, D>::value);
static_assert(!is_base_of<int, bool>::value);
Раз:
class C {
...
// Специализации ниже, вне класса.
template<class T> void fOne(T x);
// - Не-шаблонный метод с пустым списком параметров не вызовется из F::call<TT...>() при пустом списке аргументов:
// оно будет искать fMany<>(), а не fMany().
// - Шаблон с пустым списком аргументов сделать нельзя: оно будет считать синтаксис "template<>"
// специализацией несуществующего шаблона.
// - Если в теле класса объявить "template<class... TT>", то специализация "template<> void fMany<>() {}" возьмётся,
// но "template<class T, class TT...>" будет считаться частичной специализацией, что для функций запрещено.
// Остаётся эмулировать шаблон с пустым множеством аргументов (т.е. "sizeof...(RR) == 0") через enable_if.
template<class... TT, std::enable_if_t<(sizeof...(TT) == 0), bool> = true> void fMany() {}
template<class T, class... TT> inline void fMany(T arg, TT... args) {
fOne(arg);
fMany(args...);
}
}
Всем привет. Сабж. Интересует нормальный IDE (vim не предлагать) и тулчейн, чтобы сидеть либо на онтопике, либо также внутри wine. Кодировка сорцов – cp1251.
| ← назад | следующие → |