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

[Doug Moen]

I run Mint, and I only use one Flatpak right now (Ungoogled Chromium). The containerization causes problems at startup, where I have to dismiss multiple security dialogs before the program is running. After that it's fine. Maybe there's a way to configure Flatpak so that it doesn't break the programs it containerizes? Would like to learn more about this. For now I avoid Flatpak when there is an alternative.

On Fri, May 17, 2024, at 12:47 PM, Mikalai Birukou wrote:
> 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.
>
>
>
> _______________________________________________
> kwlug-disc mailing list
> To unsubscribe, send an email to kwlug-disc-leave at kwlug.org
> with the subject "unsubscribe", or email
> kwlug-disc-owner at kwlug.org to contact a human being.