Когда ходили нонстоп после нефтебазы немного не туда сунулись по пути на Капитанский мостик, но возникло жаление по осени прогуляться тут с сыном, просто посмотреть, куда идут дороги. Сентябрь пришёл, время реализовывать планы. Что бы долго не тянуть выбрали 7 сентября.

Внезапный поход на вершину, которую ещё не доводилось сходить. Сходили 17-18 августа, но руки написать дошли только сейчас.

$ date +%j                    
256

С праздником всех причастных!

Век живи, век учись, а дураком помрёшь.

Открыл для себя чудную утилиту timeout из состава coreutils.

Делает ровно то, что описывает её название: запускает команду, переданную как аргумент, на заданное время в секундах (s), минутах (m), часах (h) или днях (d):

timeout 10s ping ya.ru
sudo timeout 10s tcpdump -i wlan0 -Q in -A udp 

Обратите внимание: если команда должна быть выполнена под sudo, то sudo должно стоять перед timeout.

По истечении таймаута передаётся сигнал TERM в дочерний процесс. Если нужен другой, то укажите его через аргумент -s SIGNAL. Утилита дополнительно может послать сигнал KILL, если команда не отреагировала на сигнал TERM по истечении таймаута, указанного через параметр -k TIMEOUT. Прочие вкусности смотреть через --help, хотя их там, по большей части, и нет.

Или: казалось бы, при чём тут Firefox…

Заметка в мемориз, на случай когда /var/lib/docker/overlay2 весит неприлично много.

Первое:

docker system df

вывод такой:

$ docker system df                                         
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE  
Images          2         0         4.467GB   4.467GB (100%)  
Containers      0         0         0B        0B  
Local Volumes   6         0         0B        0B  
Build Cache     193       0         21.39GB   21.39GB

Images - тут скорее то, что нужно. Чистим стандартными средствами:

1. Смотрим образы: docker images
2. Удаляем ненужные: docker rmi <IMAGE_ID>

Containers - аналогично:

1. Смотрим через: docker ps -a
2. Удаляем: docker rm <IMAGE_ID>

Local Volumes:

1. Чистим: docker volume prune

Build Cache:

1. Чистим: docker buildx prune

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

Короткая заметка касательно пакета Quaternion для Octave. И, скорее всего, специфичная для ArchLinux/Manjaro.

Итак, пакет ставится из AUR:

yay -S octave-quaternion

Для использования в Octave нужно выполнить:

pkg load quaternion

Ну а дальше всё согласно документации:

octave:2> q = quaternion(1)  
q = 1 + 0i + 0j + 0k

Но где-то на этом шаге можно получить ошибку:

is_real_array undefined

Происходит это, обычно, после обновления Octave, когда меняется версия API: пакет собирает библиотеку для текущей версии API Octave и помещает её в то место, где Octave может её найти согласно версии API:

/usr/lib/octave/packages/quaternion-2.4.0/x86_64-pc-linux-gnu-api-v59/

Решение: просто пересобрать пакет после обновления Octave:

yay -S --rebuild octave-quaternion

Душевно прогулялись по маршруту руч.Смольный-Фалаза-Капитанский мостик-руч.Смольный.

28 апреля - 1 мая 2024.

19 марта началось составление планов на первые майские по части похода с простого, но ёмкого вопроса-предложения Ксюши в нашем походном чатике:

Давайте замутим поход на майские?

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

Других предложений не было (у меня вообще с идеями в последние годы как-то не очень), поэтому по отсутствию возражений остановились на первом варианте: водопад Зуевский, скальный массив “Белый город”, Еломовские водопады и радиальный выход на гору Лысая.

Группа собралась из пяти человек:

• Я, т.е. Саша
• Женя
• Маша
• Ксюша
• Алина

Как-то забывал сделать заметку, что данный ноутбук поддерживает обновления встроенных прошивок (как минимум BIOS и далее по накату: UEFI, System firmware, EC и так далее) через через Linux Vendor Firmware Service (LVFS), для его используется пакет fwupd.

Несколько месяцев назад у меня на ровном месте перестала работать Ethernet карточка, обновление FW решило вопрос в положительном русле.

У меня последовательность обновлений выглядит так:

sudo fwupdmgr get-devices
sudo fwupdmgr refresh --force
sudo fwupdmgr get-updates
sudo fwupdmgr update

Перед началом лучше закрыть всё лишнее и быть готовым к запросу на перезагрузку. Ну и питание от сети лучше не отключать.

Хотел на Khadas VIM3 выключить DWC3 (USB Host controller), сделал оверлей, поместил в /boot/dtb/overlays/kvim3, добавил запись в /boot/env.txt и… получил кирпич.

Оверлей простой и, вроде, правильный (в конце приведу), но система отказалась загружаться. Возможно на его клоки или ещё что что-то завязано, что не даёт ядру загружаться дальше. Но возникает резонный вопрос: “Шо делать!?”

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

Дошёл до Manjaro и переезд на KDE6. В лучших традициях жанра, альтернативы в виде KDE5 не оставили.

Но не так страшен чёрт оказался. Правда, при моих 141 DPI (1080p при мониторе 15.6", скрипт для Octave для расчёта тут) пришлось повозиться.

Если ничего не менять, то всё мелко. Если следовать рекомендациям и ставил глобальное масштабирование в 150%, которое и даёт DPI 144, то всё становится адово огромным. При этом установка DPI меняет не только шрифты, но и размеры элементов интерфейса (б$@). В результате вспомнил, что как только у меня QtC стал собираться с Qt6 в какой-то апдейт он тоже стал на моих 141, полез в мой родной .qtc-override (это моя самодеятельность, не обращайте внимание) и выставил теперь для всей системы то, что стояло для Qt Creator:

export QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor

что дало то, что мне прямо вот нужно!

Прописал этот параметр в ~/.config/plasma-workspace/env/dpi.sh. Для других окружений можно, например, в ~/.profile или в ~/.config/environment.d/dpi-plasma.conf, но в виде без export:

QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor

Детали:

• https://doc.qt.io/qt-6/highdpi.html#configuring-x11 - про вообще скалинг и
• https://doc.qt.io/qt-6/qt.html#HighDpiScaleFactorRoundingPolicy-enum - про то, какие полиси на округление есть и что они значат

При этом ложка дёгтя остаётся. Глобальное масштабирование рьяно требует шага в 6.25% (на X11). Как я выше писал: для 15.6" монитора при FullHD матрице - это 141 DPI. Два ближайшие значения глобального скалирования, кратные 6.25% это:

• 150%, что даёт DPI 144
• 143.75%, что даёт DPI 138

И мои 141 аккурат по середине: 3 пункта вверх и 3 пункта вниз. Ни туда, ни сюда. 138 DPI подходит, наиболее близко для новых матриц в 16". Но для X11 остаётся возможность вручную скорректировать DPI на вкладке Fonts, хотя они и не рекомендуют делать этого. На Wayland сессии этой возможности нет, но, вроде, нет и ограничения на кратность 6.25% (а ещё можно кратность меньше 100% задать). Wayland сильно не тыкал палочкой, так как там нужный мне VirtualBox тупо не работает (точнее гостевые OS с GUI, типа Windows 10).

Короче, что-то у них хреново с промежуточными DPI отличными от 100..200..300% но хоть такие ручки есть.

Ну и резюмируя:

1. Указываем переменную QT_SCALE_FACTOR_ROUNDING_POLICY (у меня в RoundPreferFloor)
2. На X11:
   1. Ставим глобальный масштаб (“Input & Output” → “Display & Monitor” → “Display Configuration”) в ближайшее значение, что даёт 141 DPI, для простоты пусть будет 150%
   2. Корректируем DPI в 141 в настройках шрифтов (“Appearance & Style” → “Fonts” → “Fonts” и “Force Font DPI” в нужное значение). Или не трогаем, если вас всё устраивает. Плюсом не трогать: per-monitor работа.
3. На Wayland:
   1. Судя по всему, только ручками глобального масштаба.

ЗЫ да, напоминаю, что 100% - это 96 DPI, поэтому все множители отсюда и пляшут. Исторически сложилось. Хотя на странице со скриптом-калькулятором физически у мониторов может быть любая дичь.

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

И так, в продолжение темы Conan vs vcpkg. Как я там уже писал с vcpkg подружиться получилось.

UPD 2024-04-15 vcpkg поборол, причём статику сгенерил как при помощи системного MinGW из Manjaro, так и с тулчёном из MXE. Подробности чуть позже. Conan в пролёте. UPD 2024-04-23 а вот и подробности: Conan vs vcpkg, действие второе

дискас.

А вообще, мне нужно было кросс-компильнуть максимально статический бинарник из-под Linux в Windows. Оба не справились, но vcpkg продвинулся дальше.

Не без мук, но дальше. Настолько дальше, что бинарь он отстроил… но в конце он зачем-то пытается сделать:

/bin/sh: строка 1: powershell.exe: команда не найдена  
ninja: build stopped: subcommand failed.

o_O

А быстрее всего и с минимальными телодвижениями справился MXE, но он чисто под MinGW кросс-компиляцию и создаёт свой sysroot. Понятно, что как универсально средство - не очень подходит.

MXE можно использовать и только собрать тулчейн (make cc), а остальное отдать на откуп пакетникам. vcpkg частично справляется (см выше). Conan на рецепте iconv свалился из-за косяка в рецепте (жёстко ищет RC компилятор с именем windres, причём не понятно по каким путям), а что-то сходу как его заоверлеить я не нашёл (MXE и vcpkg позволяют это и достаточно лехко).

ЗЫ у меня в системном MinGW тулчейне сломали статическую сборку.