amarao

Продолжаю инвестировать время в основы. Принял статегическое решение заняться tmux'ом (вместо терминатора), потому что это открывает дорогу к быстрым терминалкам без фич.

Пока что не решён вопрос, что делать с активным/неактивным pane'ом. У terminator'а чуть-чуть менялась гамма и активный был контрастным. tmux рисует рамочку, но её плохо видно (да и не надо ярче), и не совсем решён вопрос с многострочным выделением из pane'а (мне tmux selection очень не нравится). Частично решается с помощью zoom out/zoom in и нормального выделения между ними.

При всей моей любви к дебиану, ifupdown - ужасен. Порождение эпохи перла, garbage in garbage out (где под garbage подразумевается любое неожиданное для ifupdown состояние системы).

Да, там есть масса интересных трюков, но они очень шаткие.

Я окончательно для себя закопал ifupdown. Я его терплю на существующих системах для дефолтных настроек (от провайдера), но всё новое интересное я буду делать только через networkctl. (Я про сервера, вбить пароль в wifi на ноуте всё равно проще в гуе).

Пока что из всех конфигураторов сети (netplan, network scripts, ifupdown, network manager, systemd-networkd), именно systemd-networkd обладает наибольшей адекватностью (то есть а) правильно реагировать на неожиданное, б) не пытаться пушать полиси на пользователя в) не содержать в себе идиотских багов).

Пример идиотского бага: если на хосте есть ovs, но он в mask (то есть отключен), то netplan падает, даже если на хосте нет ни одного бриджа. Почему? Потому что надо посмотреть на бриджи. Почему? Ну ovs же стоит! Значит надо бриджи.

Я думаю, все знают, что есть Ctrl-L для очистки терминала. Но есть ещё комбинация Esc Ctrl-L, которая очищает не только экран, но и буффер терминала. Считай, тот же reset, но быстрее.


//случайно вчитался в ман к readline.

Вот есть у меня файл /etc/default/grub.d/unified.cfg для включения unified cgroups для systemd.

А вот вопрос (ответ на который я хорошо знаю, но существование которого всё равно показывает проблему): почему этот конфиг лежит в /etc/default, а не /etc/grub.d/?

И ведь на каждом шаге решение было логичным, вроде бы. Но что-то пошло не так.

Например, являются ли файлами конфигурации /etc/grub.d?

Я утверждаю, что нет. Потому что там (в 00_header) прямо написано

# grub-mkconfig helper script.
# Copyright (C) 2006,2007,2008,2009,2010  Free Software Foundation, Inc.

А если это технический скрипт, то почему он не лежит в /usr/lib? Инерция сознания. Ведь это "конфиги граба". Хотя на самом деле истинные конфиги граба лежат в /boot/grub/grub.cfg, но это не истинное место для редактирования настроек.

А истинное - в /etc/default, которое, традиционно, было микропомоечкой для параметров sysv-init скриптов, которые админы могли изменить. ..Потому что /etc/rc* тоже не были конфигами, а были скриптами, к которым нужны были параметры.

Так что параметры grub'а лежат в /etc/default, потому что его скрипты лежат в /etc/grub. Логично? Логично. Не логично.

Сравните с это с волевым решением systemd, у которого _НЕ_ конфиги лежат в /lib/systemd/system. А вот _КОНФИГИ_ (практические такие же, как и не-конфиги) лежат в /etc/systemd.

Т.е. Поттеринга можно сильно не любить за его стиль общения, но оцените степень продуманности и волю к реализации. Сломать вот эту вот говнистую дуальность "конфиг-но-не-конфиг", которая десятилетиями обиталась в /etc, и заявить, что некоторые, формально, конфиги, это не конфиги, а куски софта. А конфиги - это то, что админы пишут руками или софтом для конфигурации.

А пока у людей такой воли нет, им приходится плодить .d (!!!!) в /etc/default.