Hi!

I am not really making a complete sense of what you wrote, so I am asking
some questions:

o1bigtenor via Dng - 29.06.24, 12:41:52 CEST:
> On Sat, Jun 29, 2024 at 1:37 AM Steve Litt <slitt@???>
>
> wrote:
> > Simon Walter said on Fri, 28 Jun 2024 22:47:00 +0200
> >
> > >On 2024-06-28 04:18, o1bigtenor via Dng wrote:
> > >> LXD was enough - - - - the joys I experienced there - - - well - -
> > >> -
> > >> the old
> > >> saying is once burnt and twice shy!
> > >
> > >Ah... So it's a fork of LXD. OK. I proceed with more caution then.
> >
> > Is there something wrong with LXD?
> >
> > Well - - - it was promoted as a feature but you were (software)
> > updated
>
> whenever
> the system chose to. So if there was a buggy update - - - you didn't
> have a choice
> you lived with it until it was rolled back. If you tried to circumvent
> the constant
> updating (newest is always best you know) then your system would crash
> (at least mine did (actual system shutdown)).

You were forced to update and could not roll back? How so?

I can certainly delay an update, in case for example apt-listbugs lists
some serious bug with it.

"your system would crash" is quite non descriptive of what actually
happened. What was the concrete error?

> Then trying to remove
> snapd or snappy
> or whatever its nomen is was impossible to remove. even using rm -r
> didn't remove
> things. I finally managed to remove it by reinstalling (you know the M$
> way of resolving
> issues).

snapd is not LXD!? Did you run LXD on Ubuntu, maybe even as a snap?

As I searched for a way to install some apps that are not readily
available in Debian/Devuan, I looked at AppImage, Flatpak an Snap. From
all I have seen about Snap I decided to never even try it out. AppImage's
usually work okay. I use mostly Flatpak's for some 3rd party software that
is not readily available, cause unlike those completely self-contained
AppImage's I can update them all at once with "flatpak update".

But I really do not see the connection between LXD and Snap! Did you run
LXD as / inside a Snap container? I don't even have a clue on why I would
ever want to do that. I thought Snap was more thought for desktop apps
like Flatpak's and AppImage's.

> Seemed to me that the idea was to force one into a close and intimate
> relationship
> with Canonical - - - canonical seemed to think that this would then
> enhance its
> share price which would then make some individuals a LOT of moolah. Note
> - - -
> this is my analysis(!!!!). Some of the devs seemed to listen but most
> were like
> to have been programmed in - - - my way or the highway.

I am not really making much sense of this. It is quite across the board.

I am rather a fan of accuracy when it comes to things like that. Sure, as
written, I do not trust Canonical. But what I see here is just broad
accusations without any evidence.

This is sadly a pattern also regarding Systemd critics. There is a lot to
criticize about Systemd. And there might easily be an agenda behind it.
But it is also not as evil versus good as some like to put it.

> It would have been a great system without that particular group of
> features but
> I really don't have the time to dig into something that burned me badly
> once - - -
> there was a lot of time spent trying to get things to where I wanted
> them. So
> - - - now its a warning that the antecedents are/were 'not friendly'.
>
> HTH

Not really. Your description lacks a lot of detail and accuracy on what
exactly went wrong.

Anyway, I have Incus without any Snapd on my Devuan based server. No one
really forces me to update. And I may even be able to pick a version from
snapshots.debian.org to go back in time. Not really sure about that, as I
never tried it. There might be limits to that, but that is true for other
software as well. Of course even with no forcing me to update, I'd prefer
to have software that is up to date regarding security fixes.

Heck, there is not even any DBUS service running on the server. The DBUS
library is installed, cause LXC *depends* on it, for some reason. Note:
LXC not Incus! But no DBUS daemon. No Snapd, no DBUS daemon, no Systemd,
no nothing. libsystemd is installed though. I could put elogind onto the
server, then it would be replaced by libelogind. However, then I'd also
get DBUS service installed.

libsystemd gets installed due to login and libpam related package pre
depending on it. That is a hindrance coming from Debian that Devuan
developers donot work around (anymore). I believe there has been a post on
why. It would be hard to avoid AFAIR and need to fork and recompile a lot
more packages. In the end I believe the decision was that it is not worth
the effort to go completely libsystemd free.

I did not yet test out Void or Alpine Linux. Maybe they manage without
libsystemd. Well a package search for Alpine Linux yields no result for
"libsystemd" and Void does not have it either. That is the luxury of not
depending on Debian, I guess.

Best,
--
Martin