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

CrankyOldBugger crankyoldbugger at gmail.com
Fri May 17 14:02:48 EDT 2024


I have to admit that I'm currently migrating away from Ubuntu towards
Debian now.  All of my Raspis are running the raspbi version of Debian,
along with one laptop.  My other main drivers are on the hotlist for a wipe
and load soon.

I started with Ubuntu, and stuck with it all those years, but honestly,
I've had enough of the enshittification.  So goodbye, Snaps, hello
Flatpak.

And while I don't mind Fedora, I've had some annoying problems with my work
Fedora laptop.  Trying to avoid the same issues at home.


On Fri, 17 May 2024 at 13:38, Doug Moen <doug at moens.org> wrote:

> 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.
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20240517/a06904dd/attachment-0001.htm>


More information about the kwlug-disc mailing list