Ещё одно разочарование: Epycion
Нашёл вчера ещё один Fediverse-клиент под названием Epicyon. Сначала понравился: он позиционируется как легковесный (насколько это слово вообще применимо к Python), быстрый движок для небольших сообществ, работающий без JS и даже в консольных броузерах. В общем, как раз то, каким и должен быть софт. В какой-то момент даже подумал, а не запустить ли на нём предварительную версию сообщества идеалистов (да ещё и с готовой интеграцией в Fediverse), пока не напишу свой движок.
Но когда попытался запустить, наступило разочарование. Во-первых, как выяснилось, заставить его работать на нестандартном порту без SSL — задача весьма непростая. Но гораздо хуже другое: незалогиненному пользователю на главной вообще ничего не показывается, кроме краткого описания сообщества. И самое плохое — автор, похоже, был каким-то privacy-озабоченным (чего стоит только фраза «The administrator of this instance does not agree to participate in human subjects research, or research to study website policies and practices, carried out by academic institutions or their executors without prior written consent.» в описании сообщества по умолчанию) и сознательно по умолчанию заблокировал индексацию сообщества поисковыми системами. И если бы я не наткнулся в одном из readme-файлов на упоминание об этом, то мог бы долго недоумевать на тему «а чего это меня не индексируют».
Была мысль поднять виртуальную машину и сделать всё как надо, даже сертификат от Let's encrypt получить. Но тут понял, что для виртуализации в целях потестировать то или иное ПО лучше подходит всё же VIrtualBox, чем QEMU. Во-первых, там есть динамически растущие диски, а во-вторых, при клонировании виртуальной машины можно сделать связанный диск, то есть на диске новой машины будут записываться только изменения по сравнению с основной. Это даёт возможность держать машину с почти чистым дистрибутивом, а перед каждым экспериментом делать такой связанный диск. А QEMU диск клонируется целиком. Причём если делать маленький (я для Alpine сделал 4 Гб изначально), его может просто не хватить (как вчера было с Foremом). Ну и плюс от частого копирования целых гигабайт износ SSD получается слишком большой.
Но когда попытался запустить, наступило разочарование. Во-первых, как выяснилось, заставить его работать на нестандартном порту без SSL — задача весьма непростая. Но гораздо хуже другое: незалогиненному пользователю на главной вообще ничего не показывается, кроме краткого описания сообщества. И самое плохое — автор, похоже, был каким-то privacy-озабоченным (чего стоит только фраза «The administrator of this instance does not agree to participate in human subjects research, or research to study website policies and practices, carried out by academic institutions or their executors without prior written consent.» в описании сообщества по умолчанию) и сознательно по умолчанию заблокировал индексацию сообщества поисковыми системами. И если бы я не наткнулся в одном из readme-файлов на упоминание об этом, то мог бы долго недоумевать на тему «а чего это меня не индексируют».
Была мысль поднять виртуальную машину и сделать всё как надо, даже сертификат от Let's encrypt получить. Но тут понял, что для виртуализации в целях потестировать то или иное ПО лучше подходит всё же VIrtualBox, чем QEMU. Во-первых, там есть динамически растущие диски, а во-вторых, при клонировании виртуальной машины можно сделать связанный диск, то есть на диске новой машины будут записываться только изменения по сравнению с основной. Это даёт возможность держать машину с почти чистым дистрибутивом, а перед каждым экспериментом делать такой связанный диск. А QEMU диск клонируется целиком. Причём если делать маленький (я для Alpine сделал 4 Гб изначально), его может просто не хватить (как вчера было с Foremом). Ну и плюс от частого копирования целых гигабайт износ SSD получается слишком большой.
И то, и другое умеет QCOW2 (даже, вроде бы как, для этого и был создан).
Создать QCOW2-образ (по умолчанию создаётся динамический):
qemu-img create -f qcow2 image.img 64G
Создать дочерний QCOW2-образ (может быть дочерним от образа другого формата):
qemu-img create -f qcow2 -b parent-image.img child-image.img
Как давний пользователь QEMU/KVM и Virt-Manager+libvirt могу сказать, что для тестирования ПО они примерно одинаково подходят, разве что в плане графики VirtualBox может превосходить QEMU/KVM, но и то не факт. Другое дело, что в VirtualBox всё делается через GUI, а Virt-Manager (как и вообще libvirt) много чего не умеет из того, что умеет QEMU. И странно, что такой часто используемый функционал, как создание дочерних дисков, отсутствует в Virt-Manager, из-за чего приходится делать это исключительно в терминале.