*nix *

🔖 Наконец‑то дождались: git branch ‑delete‑merged

У нас у всех есть куча проектов. Мы работаем над фичами. Каждая фича — отдельная локальная ветка. Мы её делаем, пушим, открываем PR, PR мержат, ветку на сервере удаляют.

А локальная ветка остаётся. И так каждый раз. Через полгода у тебя в git branch тридцать восемь веток:

  feature/login
  feature/login-fix
  fix/typo
  topic/auth
  topic/auth-v2
  ...
  main

И ты такой сидишь и думаешь: «Какая из них ещё живая? Какие уже смержены? Можно ли что‑то удалить или я что‑то потеряю?».

И вот ты уже пишешь скрипт на коленке, который тебе должен всё почистить. Запускаешь его и вуаля, ты слегка ошибся и больше в твоей репе нет бранчей, паника и судорожный поиск решения на ohshitgit.com.

В общем, короче. Harald Nordgren походу сам задолбался с этим и ребята только что релизнули Git 2.56, в котором запилили опцию delete‑merged.

Самое классное, что команда супер простая и простая как полено (хоспадепрости patch‑format с 100 500 аргументами).

$ git branch --delete-merged 'origin/*' --dry-run
Would delete branch feature/login (was abc1234).
Would delete branch feature/login-fix (was def5678).
Would delete branch fix/typo (was 9876fed).

Посмотрел. Всё выглядит нормально. Запускаешь без --dry-run:

$ git branch --delete-merged 'origin/*'
Deleted branch feature/login (was abc1234).
Deleted branch feature/login-fix (was def5678).
Deleted branch fix/typo (was 9876fed).

Всё. Ветки, которые уже влиты в свой origin, снесены. Ветки, где есть неотправленная работа, — остались. Ветки с deleteMerged = false — остались. Ветки, которые ты вычеканил в другом worktree, — остались.

Это безопасно. Свои скрипты можно выкинуть. Также можно точечно чистить категориями topic-*, feature/*, origin/*.

В общем, если git branch уже не помещается в терминал — обновляемся на 2.56 и теперь вы знаете что делать.

Telegram | Github | YouTube | X

🔖 Наводим красоту в htop

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

Я не хочу долго расписывать как и что настраивать, а просто дам вам однострочник который сделает всю магию. Он по сути он просто бекапит текущий конфиг (если он вообще был) и забирает из https://gist.github.com/itcaat/45ea5994d66378fc4bd647cab860a05f новый.

mkdir -p ~/.config/htop && [ -f ~/.config/htop/htoprc ] && mv ~/.config/htop/htoprc ~/.config/htop/htoprc.bak.$(date +%Y%m%d%H%M%S); curl -fsSL "https://gist.github.com/itcaat/45ea5994d66378fc4bd647cab860a05f/raw" -o ~/.config/htop/htoprc

После этого запускаем htop и наслаждаемся.

—

Telegram | Github | YouTube | X

Только что релизнул net-peek v0.1.8. Этот маленький, но классный 🚲 на Go я сделал, когда надо было быстро понять кто поджирает трафика на серваке.

Можно, конечно, расчехлить tcpdump, добавить tshark, немного awk или iftop но богу тулов нужны новые тулы😈.

Он показывает по каждому удалённому IP:
- входящую и исходящую скорость;
- сколько данных уже передано;
- количество активных соединений;
- подробности по каждому соединению.

Можно смотреть конкретный интерфейс или сразу все. Есть поиск, сортировка, пауза и отдельный gateway-режим для анализа трафика на NAT-сервере.

sudo net-peek -i all

В общем, делюсь с вами аккуратным TUI-монитором трафика. Репозиторий и инструкции как установить лежат тут: https://github.com/itcaat/net-peek.

Сохраните на будущее - кто знает когда он может понадобиться 🔫
—
Telegram | Github | YouTube | X

Если вы пользуетесь Linux и регулярно созваниваетесь через Discord, Teams, Telegram, Телемост и другие программы, то наверняка сталкивались с проблемой шумоподавления.

Где-то встроенный шумодав работает нормально, где-то его нет вообще.

Я раньше использовал NoiseTorch (долго и велосипедно настраивать), пробовал EasyEffects (очень громоздко и избыточно). А недавно нашёл HushMic.

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

https://github.com/Fovty/HushMic

В ошалевшую от безделья голову пришла шальная мысль — может ли современный уважающий себя в меру упитанный человек прожить на голом ядре Linux, coreutils, пачке элементарных консольных мастхэв и нескольких консольных же баловст для приятственного времяпрепровождения?

Пораскинув в хорошем смысле мозгами, сделал такую подборку:

• Основа — linux, linux-firmware, grub, runit, coreutils, util-linux, kmod, shadow, kbd

• Сеть — iproute2, dhcpcd, ca-certificates

• Окружение — kmscon/fbterm, tmux, nerd-fonts, mc

• Мастхэв: sudo, file, procps-ng, neovim, git, wget, openssh, openssl, gcc, make, glibc, tar, zstd, unzip, less, grep, sed, awk, findutils, man-db, man-pages

Если немножко додать жиру, то — yazi, neomutt, lynx/w3m, newsboat, alsa-lib, alsa-utils, mpv.

Наверняка чего-то упустил / чего-то захочется ещё. Но такова природа человека… Иначе до пятидесятого гнома мы бы не дошли.

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

И распивая чаи со спиртом (опционально), буду читать здесь холивары о гноме и кедах 😁

Что нам стоит override для юнита systemd написать? Подумал я как-то пятничным вечером, да чего там, я 100 раз так делал, 5 минут и справимся. Но не тут-то было, в посте хочу разобрать основные ошибки создания override.

Для начала немного теории - зачем он нужен. Как правило такая потребность возникает в сценариях:

• автор ОС/пакета предусмотрел плохие дефолты или не подходящие для вас. классический пример PrivateTmp=Yes для exim или чего-то похожего

• вам хочется дополнить/исправить логику работы демона, например очистить кэш, перегенерировать какой-то uuid перед стартом

• юнит начал много кушать сокетов/памяти и вам хочется расширить-зарезать оные персонально этому юниту. зачастую плохая идея зарезать для определенного класса софта

• да зачем нужен override, я просто внесу нужные изменения в юнит? нужен, потому что при любом обновлении dnf/apt системный пакет перетрет ваши изменения и вы очень долго будете искать потом что сломалось

Итак, основные ошибки при созданию override файлов:

• мы все любим в deb based дистрибутивах цветовую схему nano по-умолчанию, прочитать блеклый текст между каких строк нужно писать я с первого раза не смог
  

  

• писать нужно включая секцию, но это я помнил и так, пример
  

### Editing /etc/systemd/system/ssh.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Service]
ExecStartPre=

### Edits below this comment will be discarded

• у systemd нет шелла. совсем. поэтому пайпы, редиректы и все что связано не работают
  пример нерабочего оверрайда
  [Service]
  ExecStartPre=/usr/bin/uuidgen > /tmp/123
  пример правильного
  [Service]
  ExecStartPre=/bin/sh -c "/usr/bin/uuidgen > /tmp/123"
  
  без прямого указания шелла у вас uuidgen будет просто выплевываться в journalctl

После правки изменения нужно сохранить и сказать systemctl daemon-reload. Проверить внесенные изменения можно systemctl cat unitname, что не очень наглядно, лучше использовать systemctl status unitname будет виден результирующий юнитфайл.

Надеюсь сэкономил вам несколько минут.

Вышел lazy-tmux 0.2.0!

Напомню в двух словах: lazy-tmux — менеджер tmux-сессий на Go, который показывает все сохранённые сессии деревом, но реально восстанавливает сессию с её процессами и скроллбэком только когда вы её открываете, а не поднимает всё разом. Подробнее про сам проект я уже писал раньше, а сейчас — про новый релиз, в котором накопилось много всего.

Настройки наконец переехали в TOML-конфиг. Раньше приходилось прокидывать флаги каждый раз, теперь есть файл: config gen создаёт болванку, config show печатает итоговую конфигурацию с учётом всех источников. Заодно появился контроль над тем, что вообще перезапускается при восстановлении сессии — белый и чёрный списки, причём оба матчатся как регулярки по всей командной строке.

Сильно переработал сам TUI picker: нормальная тема, поддержка мыши, цветные режимы действий, панель хоткеев по ?, относительное время снапшота. Пока сессия поднимается, прямо внутри picker’а теперь рисуется анимация загрузки, а Esc аккуратно отменяет восстановление и убивает частично поднятую сессию.

Ещё в релизе появился слой интеграций со сторонними программами, и первая из них — Claude Code. Рядом с каждой сессией в picker’е показывается живой статус: работает, ждёт вашего ответа или подтверждения, либо просто простаивает. Когда крутишь несколько агентов по разным проектам, удобно видеть, кто из них заблокирован, не переключаясь внутрь каждого. А восстановленные окна Claude сами переподхватывают свою сессию.

Из остального: проверил совместимость с tmux от 2.9 до 3.7b, починил поведение когда сервер tmux вообще не запущен, добавил фоновый демон автосейва, команду version и обновил сайт документации.

Поставить можно одной строкой:

curl -fsSL https://lazy-tmux.xyz/install.sh | sh

Есть и Homebrew с AUR. Код — https://github.com/alchemmist/lazy-tmux, документация — https://lazy-tmux.xyz. Проект ещё молодой, открытых задач хватает, так что буду рад фидбэку и контрибьюшенам!

удалено

Удалено удалено удалено

Так получилось, что мне приходится работать с достаточно древними серверами (причины оставаться на старом железе и софте разные, но достаточно веские). Я и так стараюсь держаться на два шага позади переднего края (чаще всего это Debian oldoldstable), но иногда приходится делать резкий шаг вперёд (обновляться до oldstable, который скоро oldoldstable станет).

Вот и сейчас обновил кое-что с Bullseye на Bookworm. И получил при попытке зайти со старого OpenSSH 5.3 на новый 9.2 “no hostkey alg”. В новой версии OpenSSH по умолчанию отключены алгоритмы ssh-rsa и ssh-dss (первый из-за небезопасного хеша SHA1, второй из-за общей проблемности DSA); а старые версии ещё не умеют rsa-sha2-256, rsa-sha2-512 (не говоря уж об эллиптических кривых).

К счастью, эти алгоритмы ещё не удалены напрочь! Поэтому для обеспепчения возможности подключения старого клиента OpenSSH 5 к новому серверу OpenSSH 9 достаточно записать такие строки в файл /etc/ssh/sshd_config.d/local.conf (и перезапустить sshd):

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

В обратную сторону тоже работает, чтобы иметь возможность заходить новым клиентом OpenSSH 8 (и выше) на старый сервер OpenSSH 5 (и ниже) достаточно прописать такие три строки в файл ~/.ssh/config:

Host old-server
        Hostname 1.2.3.4
	. . .
        HostKeyAlgorithms +ssh-rsa
        PubkeyAcceptedKeyTypes +ssh-rsa
        KexAlgorithms +diffie-hellman-group14-sha1

Представлена вторая версия книги FreeBSD Device Drivers (PDF, EPUB, HTML).

«Драйверы устройств FreeBSD: от первых шагов к освоению ядра» — это бесплатная книга с открытым исходным кодом, которая проведёт вас от состояния «Я никогда не писал код ядра» до состояния «Я могу писать, отлаживать и отправлять драйверы FreeBSD производственного качества». Это скорее пошаговый курс, чем справочник, структурированный вокруг 38 глав, 6 приложений и десятков практических заданий, которые компилируются и загружаются в реальной системе FreeBSD 14.x, пояснил автор проекта Эдсон Бранди.

Пора вспомнить про RFC 1149 (wikipedia.org/wiki/IP_посредством_почтовых_голубей)

vegard@gyversalen:~$ ping -c 9 -i 900 10.0.3.1
 PING 10.0.3.1 (10.0.3.1): 56 data bytes
 64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
 64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms
 64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms
 64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

--- 10.0.3.1 ping statistics ---
 9 packets transmitted, 4 packets received, 55% packet loss
 round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms

Недавно перешел с Nixpkgs на Nix Flakes. После третьего флейка начал задумываться над их публикациями и обнаружил, что репозитория для флейков по сути нет. Поиск проектов на гитхабе не различает nix репозитории по типам. Есть NUR (Nix User Repository), но он появился до флейков и просто так добавить в него чистый флейк репозиторий без дополнительных приседаний нельзя. Плюс процесс публикации требует прохождения ревью, что весьма неинклюзивно и мешает развитию экосистемы.

Flakes стали относительно зрелыми и решают проблему центрального репозитория. Однако в репозитории Nixpkgs на GitHub всё ещё остаётся более 5 тысяч открытых задач и сопоставимое количество пулреквестов, и он продолжает ежедневно получать множество коммитов. Добиться включения пулреквеста с новым инструментом в Nixpkgs может быть сложно — файл README репозитория Nixpkgs прямо не рекомендует пользователям добавлять свои «любительские» проекты. На nix форуме существует "вечная" тема посвященная пулреквестом оставшимся без внимамия.

Флейки, это чистные самодостаточные функции, которые должны компноваться значительно легче файлов с произвольными nix выражениями, но до сих пор не отвлекли внимание от nixpkgs. Считаю, что причиной этому может быть отсутсвтие конвенционального репозитория с возможностью поиска зависимостей и удобным интерфейсом для публиции того, что не хватает по мнению автора.

Репозиторий Nixpkgs огромен. Он содержит более 120 тысяч пакетов, но большинство из них не являются нативными для Nix. Например, около 10% составляют импортированные пакеты Haskell. Поэтому такое большое число не может служить надёжным показателем того, насколько хорошо развит процесс публикации в Nix. К примеру, только в репозитории PyPy сейчас насчитывается почти 900 тысяч пакетов. Аналогичные подход можно встретить и в Java - Maven Nexus, и в NodeJS - npm, и в Perl - CPAN...

Также важно отметить, что Python — самый популярный язык программирования общего назначения, и его процесс публикации был разработан программистами для программистов. Однако в этом рабочем процессе нет этапа пулреквеста! По сути, интерфейс работает по принципу «загрузил и забыл», что положительно влияет на конверсию пакетов Python.

Flakes легко устанавливать, но процесс их публикации пока недостаточно отлажен. Текущий подход к распространению flakes, по-видимому, унаследовал многие черты рабочего процесса Nixpkgs.

Для Nixpkgs это был естественный путь развития, поскольку все деривации образуют большое и связанное Nix-выражение, разбитое на множество файлов внутри одного Git-репозитория.

Размышления выше мотивировали меня написать сайт для управления классическим репозиторием специально заточенным на флейки.

a-piece-of-flake-nix-repository

«Обёртка» для системы мониторинга системного журнала операционной системы с открытым исходным кодом.

Концепция заключается в адаптивности решения. Написана на «bash» с использованием лингвистической модели с китом.

Код

Когда мне пришла в голову мысль что я хочу навайбкодить операционку, у меня было смутное представление что полноценным успехом можно будет считать только self-hosted OS, то есть чтоб в ней запускались дев-тулы, можно было поправить исходники, скомпилировать, ребутнуться с новым ядром и все продолжало работать.

Если честно, я не думал что получится, думал в лучшем случае получу что-нибудь что может запустить пару kernel-space процессов которые будут по очереди что-то в UART печатать и все. А оно раз, и получилось… Self-hosting milestone взят!

В Slopix есть:
- Простенький шелл
- Компилятор Си (и прочие build essentials)
- Интерактивный редактор текста с подсветкой синтаксиса для Си

Принципиально ничто не мешает теперь заниматься разработкой слопикса в слопиксе.

Потребовалось 5 weekend sprints. Получилось примерно 45к строк на Си. Узнал много нового про операционки и многому научился в плане coding agents workflows. Ну и тонну удовольствия получил, конечно же!

Реп тут: https://github.com/davidklassen/slopix

Только что я релизнул cli-stash v0.2.9. Теперь можно редактировать сохраненную команду.

cli-stash - tui-тулза для добавления терминальных команд в избранное, с возможностью переноса из истории

Кейсы использования такие:

1. Вы хотите параметр заменить на какое то ключевое слово. Например, я хочу в избранное добавить команду dig для определения NS серверов, которые отдает нам 1.1.1.1. Я не хочу видеть захаркорженные значения. И чтобы было красиво меняю их просто на ключевые слова. Это дает больше эстетического удовольствия при использовании команды - не более.
   Ну и в будущем я подвезу автосинк с шарингом на команду, так что может быть полезно.

2. Да просто надо поменять команду - почему бы не дать такую возможность =)

Кстати, тут вопрошали сколько 🌟 наберет тулза в github - пока всего 37. Ну а что это за инструмент и чем он может быть полезен можно подробнее прочитать в предыдущем посте.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Ребята, я сегодня релизнул cli-stash. Это TUI-утилита на Go + Bubble Tea для сохранения shell-команд в "избранном".

Она решает простую боль: сложные команды (docker, kubectl, ffmpeg) постоянно забываются, а копаться в history каждый раз это страдание.

Что умеет:

• Сохраняет ваши команды в избранном

• Возможность добавить из истории шелла

• Нечеткий поиск

• Сортировка по частоте использования
  

И самое крутое, что команда вставляется прямо в терминал. Таким образом вам не надо ничего копипастить: нашел → выбрал → enter → команда уже в cli.

# Установка в Linux
go install github.com/itcaat/cli-stash@latest

# Сборка из исходников
git clone https://github.com/itcaat/cli-stash.git
cd cli-stash
go build -o cli-stash .
sudo mv cli-stash /usr/local/bin/

В macOS поставить изян brew install itcaat/tap/cli-stash

Исходники и инструкция по использованию есть на github.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Вышла новая версия fq 0.16.0

fq - это инструмент, язык и декодер для работы с двоичными данными. Конечная цель проекта — объединить в одном инструменте функции jq, hexdump, dd и gdb.

Поддерживаем массу форматов, полный список: https://github.com/wader/fq/blob/master/doc/formats.md

Написан на Golang.

GitHub: https://github.com/wader/fq

ChangeLog: https://github.com/wader/fq/releases/tag/v0.16.0

@Regnar, навеяло статьёй…

Свалился на меня «последний из 32-битных могикан», но машинка прямо финал возможностей архитектуры — насколько я понял, видит спокойно 8 гигов рамы (PAE во все поля?), слотов не пожалели, в общем, в такое чудо бы камень хотя бы на 2 ядра, но, увы…

Я его практически не смотрел ещё и ХЗ когда посмотрю (вроде не совсем мёртвая), но превентивно задам вопрос. Допустим, поставил я туда 32-битный BunsenLabs. Допустим, я хочу запустить какое-нибудь 64-битное приложение, которое в 32 битах давно уже не обновляется. Допустим, мне пофиг, что там в плане скорости (очень важное допущение, потому что оно как бы понятно, что там будет).

Насколько это реально — настроить для него резервативию… презервацию… короче, специально обученный загон с софтовой эмуляцией 64 бит? Существуют ли решения? Чтобы их установить и отконфигурировать, обязательно пройти все круги ада, как в той статье?

Практического смысла это по понятной причине не несёт — просто пятничное.

Почему я снова вернулся на Debian после Ubuntu 24.04 и Fedora 42

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

Сначала я поставил Ubuntu 22.04, но быстро понял, что хочу поэкспериментировать и посмотреть, как себя чувствуют другие дистрибутивы на новом железе.

Я решил обновиться с Ubuntu 22.04 до 24.04 - казалось бы, логичный шаг: свежий LTS, новые пакеты, улучшения в GNOME. Но спустя пару недель я понял, что дистрибутив нужно менять. Расскажу, почему.

Медленная работа с большим количеством файлов

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

Если регулярно работаешь с проектами, папками картинок или архивами — это превращается в настоящий тормоз.

Да, баг могут исправить, но в тот момент он мешал работать каждый день.

Fedora: понравилась, но не подошла под задачи

Первым я решил попробовать Fedora 42.
Впечатления были отличные:

• система работает быстро,

• GNOME выглядит аккуратнее без патчей Canonical,

• Wayland ощущается максимально плавным,

• окружение ощущается «современным из коробки».

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

Да, что-то можно было поставить, но не все инструменты, которыми я пользуюсь в работе, нашлись. Также наблюдалась проблема обновления некоторых пакетов из России. Получается замкнутый круг.

В итоге я пытался найти нужные программы, но либо я их не там искал, либо их не было, либо которые я нашел не заработали.

Почему я выбрал Debian 13

В этом году как раз вышел Debian 13 с GNOME 48, я решил попробовать его.

И для себя получил:

• стабильность, к которой привык,

• современный GNOME без патчей,

• огромный набор пакетов в репозиториях,

• отсутствие лишних предустановленных компонентов,

• а главное — всё, что мне нужно, установилось без танцев.

В итоге Debian остаётся для меня тем самым балансом:

Итог

Ubuntu 24.04 — неплохой релиз, но сейчас он не подходит под мои задачи.

Fedora оставила отличные впечатления — она бы идеально подошла мне «для души».
Но для работы мне нужна система, где всё устанавливается из репозиториев, ничего не ломается после обновлений и не приходится искать обходные решения.

Так я и остановился на Debian 13 с GNOME 48 — и пока это лучший вариант для моего сценария.

А прочитать статью про мой ноутбук, который я приобрел для Линукс за 25000 рублей, вы можете по ссылке:

https://kodprog.ru/noutbuk-dlya-linuks-za-25000

Почему мне не понравился Arch Linux

Однажды я решил попробовать Arch Linux — в качестве эксперимента, чтобы понять, подходит ли он мне как основная система. Спойлер: нет. Хотя я понимаю, почему Arch нравится многим, лично мне он не зашёл. Расскажу коротко — без холивара, просто субъективный опыт.

1. Слишком много ручной настройки

Да, это философия Arch — «собери систему под себя».
Но когда даже базовые вещи требуют:

• поиска пакета вручную,

• чтения вики,

• настройки конфигов,

в какой-то момент это начинает отвлекать от работы.

Мне хотелось просто пользоваться системой, а не постоянно её собирать.

2. Установка превращается в квест

Я понимаю, что сейчас есть Archinstall, но это всё равно:

• больше шагов,

• больше точек, где можно ошибиться,

• больше нюансов, которые надо держать в голове.

Для сравнения: Ubuntu/Debian/Fedora ставятся буквально за 10–15 минут без сюрпризов.
Arch — это отдельный процесс, который каждый раз занимает время, силы и концентрацию.

3. Постоянные обновления и риск поломок

Rolling release — это круто, но это также:

• риск, что обновление завтра что-то сломает,

• необходимость держать в голове зависимости,

• желание обновляться реже, но при этом понимание, что массово обновлять ещё опаснее.

Мне нужен более предсказуемый рабочий инструмент, а не адреналиновый аттракцион.

4. Много времени уходит на поиск информации

Arch Wiki — одна из лучших в мире, но:

• почти каждое действие требует чтения документации,

• часто нужно искать решения на форумах,

• иногда конфликты пакетов решаются вручную.

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

5. Минимализм оказался минусом

Arch устанавливается «голым».
Ты ставишь:

• окружение,

• драйверы,

• кодеки,

• шрифты,

• инструменты,

• конфигурируешь систему практически с нуля.

Кому-то это даёт свободу.
Мне — лишние часы, которые можно было потратить на реальную работу.

Итог

Я понимаю, за что любят Arch — скорость, свежие пакеты, гибкость. Но для моего сценария использования он требует слишком много времени и внимания. В итоге я вернулся к Debian/Ubuntu: они просто работают, а я могу заниматься задачами, а не конфигами.