[kwlug-disc] Snappy judgements, snappy issues, flat shadows

[Mikalai Birukou]

Observation/Exhibit 1.

Eventually, I am moving to VSCodium from VSCode.

In my Mint Linux, with inbuilt software manager I've installed VSCodium. 
The only option there is in Flatpack format.

VSCodium gets installed. It opens my project's directory. Asks if we 
trust this folder (by the way, remind me about it at LibreOffice macros 
discussion). It is just VSCode. I type something, ensuring on the way my 
workflow is not affected by VS' migration. I commit, and then "git push" 
shows an error in git console.

My ssh setup has all hosts configured from respective files, using 
respective keys. Like, house key is not used for company's door. 
VSCodium git console says that to fix permissions for ssh config file. 
But, config is readable by everyone.

In the inbuilt console I do "git push", and get the same error. In the 
external terminal I do "git push", and all works. WIN (why in hell?) 
hangs in the air.

Then I download just deb. And it just works.

Does Flatpack have a shadow of containerization issues, like snaps have, 
introducing boundaries inside of already existing corpora of intertwined 
programs that get migrated into more tight paradigm?


Observation/Exhibit 2.

I am lazy. So, ease of making vm and getting into its shell directly 
within LXD (lxc commands) is the only way for a lazy soul to arrange a 
vm, where BigBlueButton can sit, with its preferences toward full vm, 
not just a container.

Host machine is Ubuntu 18 (lot's of lazy here for 2024), and LXD version 
with vm guests is already snap-only. Fine. It was installed. Newer LXD 
also needed ZFS to be 0.8+, forcing upgrade. Fine.

So, yesterday I picked into our host with webconference.kwlug guest. And 
"lxc ls" would not work, saying something about a socket. I felt like 
that has already happened, to which "restart it all" returned to working 
properly. But after restart this time, it still complained, and deeper 
digging showed clear "no zpool tools", which still makes no sense.

kwlug, of course was a test bed of a new setup and skills where applied 
to other machines (microk8s hosts in vms on one physical host). "snap 
list" on another machine that works showed older lxd version, 5.19, 
tracking more specific branch 5.19/stable, and it is "held" from 
automatic updates. Recreating this setup, and doing "lxd recover" 
existing data into new install (new after remove then install pair in 
snapd), brought kwlug back to life.

Obvious morals here are about automated upgrades, and holding them, like 
one may do in production clusters.

Generally, with a promise of strict version watching, snap here and 
flatpack (can you hold version there?) elsewhere, I have a feeling, warm 
for the lazy feeling, that a simple "don't touch that which works" may 
actually work.

This feeling has developed in containerized environments, where ubuntu 
18 in 2024 is not the loudest example of lazy. In those environments we 
also introduce network boundaries to limit damage, in case old 
components get compromised.


Do you remember presentation about Qubes OS, https://kwlug.org/node/1158 
? It noted pains from boundaries due to vm-ization of programs' corpora 
on a desktop.


Comments? Similar stories? Perspectives?


As a side note, may I add that I specifically separate Canonical's 
universal store for snaps behaviour from snap as a technology. 
Judgements about social aspects should not be downplayed, but mixing 
them with tech aspects introduces smoke in a discussion about overall 
landscape of solutions/posibilities/designs in tech evolution.