...в поисках гармонии

https://askubuntu.com/questions/599208/how-to-list-grubs-menuentries-in-command-line

Изумительный пример линукс-вея.

Проблема — в grub2 более сложные конфиги и непонятно как сделать чтобы загружалось нужное ядро (в 1.99 и ранее был простой конфигурационный файл с простым списком, который можно было редактировать вручную).

Довольно быстро можно нагуглить, чтоб для того, чтобы задать нужный номер, теперь нужно не редактировать конфиг, а нужно просто указаеть его в параметре для grub-set-default.

Но если у вас сервер без ipmi или вдс без vnc, то кажется, что нет простого штатного способа получить список возможных ядер с их номерами, чтобы задать нужное.

И вот люди пишут разные скрипты, которые грепают конфиги и строят списки доступных ядер с номерами. Всё это в какой-то момент, вероятно, работало, но в текущий момент все решения по ссылке при построении списка высчитывают слегка разные номера для ядер. И некоторые из решений уже точно не считают корректно.

И вот в конце всего обсуждения человек заметил, что если у вас bash с автодополнением, то оказывается штатный скрипт умеет по двойному TAB показывать список возможных вариантов (хотя не показывает при этом варианты с windows):

I just found out that you can just use auto-complete (pressing tab twice) on commands like grub-reboot or grub-set-default and it'll give you a list of the available boot menu entries.

Переехали на новый тип бекапных серверов — современное железо, 3 диска HE10 по 10 терабайт в raidz1.

Это работает почти ровно в два раза быстре на любой околобекапной нагрузке, чем было раньше (зеркало 2х3 терабайта).

Следующая хотелка — дорасти до конфигов по 12 дисков с кешем на ссд. Но это 750+ т.р. за сервер :(

Открытие дня, цитирую:

To people wondering why this syntax persisted so long: the bug produced by this syntax was actually the only way to have state variables, before the keyword state was introduced. This is why the bug was not fixed. Some people actually used it as a short syntax to implement a state variable:

$ perl -E 'sub flip_flop { my $t if 0; $t = !$t; say $t ? "flip" : "flop"} flip_flop() for 1..4'
flip
flop
flip
flop

https://dev.to/dams/comment/c3mi

А мне то казалось, что так просто код выглядит читабельнее в ряде случаев...

Я когда начинал пробовать что-то делать с ZFS, тестировать какие-то сценарии, всегда непонимал, почему принято основной pool называть 'tank'. И называл его 'zfs'. А недавно понял. На клавиатуре печатать 'tank' — элементарно быстрее.

Бодро делаем новое хостинговое окружение на LXC/LXD в целях замены OpenVZ.

Получается, неожиданно, весьма неплохо и, например, много лучше, чем получилось у Proxmox, но..

Напомню, с OpenVZ мы имеем:

1. базирование на Centos и систематическое существенное отставание от современного мира (да, что-то бекпортится, что-то не так критично, но современные шедулеры, zfs, местами многократные ускорения чего-то в новых ядрах линкса, которые сюда никак...). В случае с Virtuozzo 7 мы имеем еще и проблемы стабильности.


2. плохая поддержка — как от разработчиков, так и от "community", и коллеги, которые пробовали платную поддержку, говорят что различий нет


3. плохое состояние OpenVZ как продукта (в последние года)


4. более плохая работа коммерческой версии, чем опенсурсной, с точки зрения конечного потребителя


5. местами жесткая заточенность и залоченность на сомнительные (ext4, Virtuozzo Storage), с точки зрения потребителя, технологии


6. отличная документация


7. отличная (!!!) техническая продуманность фич, которые сделаны


8. хорошая и изначальная заточенность под около-хостинговые задачи

С LXC/LXD почти все ровно наоборот:

1. современные ядра, фичи, драйвера и т.д.


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


3. продуктом, в форме именно продукта, оно не является. Начиная с ~ LXD 2.0 всё неплохо, но это пока все еще просто инструмент, причем сильно не самодостаточный


4. возможность использовать ZFS и разные современные штуки, но, пока, недостаточно хорошая интеграция с . Например, мы уже придумали как прокидывать юзер-левел квоты, но вот это все — надо пока самостоятельно. Хотя, казалось бы, проблема общая, массовая, и непонятно почему всё так.


5. Документация чуть лучше формальной. Чтобы понять, как сделать что-то, требуются гораздо более фундаментальные знания об администрировании и сетях, прочитать только родную документацию никогда не является достаточным (ну и см. п.3)


6. Некоторые очевидные фичи непонятно как получить (==отсуствуют), при этом, кажется, писать свои патчи здесь много сложнее.


7. полная непродуманность под около-хостинговые задачи. Как реализовывать многие нестандартные сценарии, которые у нас фактически были, причем частоиспользуемы — загадка.

Про OpenVZ дальше — наиболее популярная у нас идея — заопенсурсить панельку под OpenVZ 6 и сделать лоукост хостинг на старых ядрах/дистрибутивах. Вот только, кажется, контейнеры на lxc, в сравнении, работают на столько быстрее (вероятно, из-за более нового ядра), что возникают вопросы к экономическому смыслу.