# The snap is a walled garden made by ubuntu



## malaizhichun (Oct 18, 2022)

What’s The Deal With Snap Packages?​








						What’s The Deal With Snap Packages?
					

Who would have thought that software packaging software would cause such a hubbub? But such is the case with snap. Developed by Canonical as a faster and easier way to get the latest versions of so…




					hackaday.com


----------



## jbo (Oct 18, 2022)

What kind of response are you looking for?


----------



## SirDice (Oct 18, 2022)

It doesn't even mention you could have different snaps installed with a vast amount of ancient and potentially vulnerable dependencies baked inside of them. Hurray for embedded libraries and such


----------



## jbo (Oct 18, 2022)

Yep, and no resource sharing... if you run 15 snaps all of which use the same version of a dependency (as a shared library), you'll find yourself loading that dependency into memory 15 times.


----------



## freezr (Oct 18, 2022)

Nix (and Guix) solved all those problems better than Snap or Flatpak...


----------



## mer (Oct 18, 2022)

Cool  Snaps are the "container version of statically linked executables".


----------



## kpedersen (Oct 18, 2022)

mer said:


> Cool  Snaps are the "container version of statically linked executables".


Indeed. All of the disadvantages and none of the benefits of static linked binaries. Well done Linux community! 

They even require some random running [clown]_snapd_[/clown] service to work.


----------



## jbo (Oct 18, 2022)

kpedersen said:


> They even require some random running [clown]_snapd_[/clown] service to work.


Didn't know about that one. But I guess something has to unpack the snap before the (core) OS can run it regularly.

EDIT: I'm glancing over the man of snapd and I it seems like it would have some network connectivity thingy going on. At least there seems to be a way to query the network connectivity status of snapd. What?


----------



## Jose (Oct 18, 2022)

kpedersen said:


> Indeed. All of the disadvantages and none of the benefits of static linked binaries. Well done Linux community!
> 
> They even require some random running [clown]_snapd_[/clown] service to work.


Hopefully it hangs consuming 100% of CPU from time to time.


----------



## SirDice (Oct 18, 2022)

Had to (re)install Ubuntu for a client a couple of months ago (old system, upgraded many times, /boot became way too small). That snap stuff was the first thing I removed after the initial install. Yeah, no thanks. I'll stick to `apt` if you don't mind.


----------



## Alain De Vos (Oct 18, 2022)

There is also flathub, flatpak & appimage.


----------



## ct85711 (Oct 18, 2022)

The sad part is, the push towards snap/flatpak is more of simplicity/laziness than anything else.  Instead of distro's curating and making sure packages work, they push all that work to upstream.  So instead of having a team dealing with the bug fixes, they now only need a simple script closing bugs telling them complain somewhere else.

I can see on the developer side on going to snap/flatpak in that they don't have to their version of dependency hell, from having to check all the distros and see what the common minimum versions everyone supports.

Sad part is that we didn't learn from the hell/mess from the Log4Jam and openssl vulnerabilities; the entire Linux community is going to be biten even harder when the next major storm comes around.


----------



## Alain De Vos (Oct 18, 2022)

They give the impression that the linux kernel version does not count anymore. Which is offcourse false.


----------



## kpedersen (Oct 18, 2022)

Jose said:


> Hopefully it hangs consuming 100% of CPU from time to time.


Heh, almost certainly. And also the seemingly unfixable systemd classic of:

A stop job is running for Session 1 ( waiting 1 min 30 seconds )


----------



## Jose (Oct 18, 2022)

Alain De Vos said:


> They give the impression that the linux kernel version does not count anymore. Which is offcourse false.


It kind of doesn't as Linus is (in)famous for ranting "WE DO NOT BREAK USERSPACE!" The irony is that userspace is still a hot mess because notably Ulrich Drepper and others didn't get the memo. One of the advantages of having an OS that releases kernel + base at the same time, and with care to not break backwards compatibility. Now let's talk about Pkgbase


----------



## Jose (Oct 18, 2022)

kpedersen said:


> Heh, almost certainly. And also the seemingly unfixable systemd classic of:
> 
> A stop job is running for Session 1 ( waiting 1 min 30 seconds )


Dear Mr. Pedersen,

You are not helping with my browser tabs addiction. The wails into the darkness in those bug reports was worth it, though.

Sincerely,
Jose


----------



## Alain De Vos (Oct 18, 2022)

Jose said:


> It kind of doesn't as Linus is (in)famous for ranting "WE DO NOT BREAK USERSPACE!" The irony is that userspace is still a hot mess because notably Ulrich Drepper and others didn't get the memo. One of the advantages of having an OS that releases kernel + base at the same time, and with care to not break backwards compatibility. Now let's talk about Pkgbase


I'll just do a simple

```
make installworld
make installkernel
etcupdate
make -DBATCH_DELETE_OLD_FILES delete-old
make -DBATCH_DELETE_OLD_FILES delete-old-libs
```
This is so simple i do not consider pkgbase a real improvement. Altough the idea is good.

In src.conf i have:

```
WITHOUT_SENDMAIL=yes
```
So no sendmail when i build world


----------



## zirias@ (Oct 18, 2022)

Jose said:


> Now let's talk about Pkgbase


I really don't get _that_ take in your context. Actually, I think pkgbase is a very nice idea, allowing users to leave out stuff they won't need without compiling themselves. It also creates problems of course, e.g. you have to start actually _tracking_ dependencies to "base packages" from ports. So, not sure whether it will ever take off.

But in any case, there's one thing pkgbase will never change, and it's exactly this:


Jose said:


> […] having an OS that releases kernel + base at the same time, and with care to not break backwards compatibility […]



Seriously, it would _never_ change the integrated development model of the base system. All it would change is the distribution of the binaries, from rather monolithic tarballs to individual packages.

So, what's your concern about _that_ in this context?


----------



## Voltaire (Oct 18, 2022)

freezr said:


> Nix (and Guix) solved all those problems better than Snap or Flatpak...


The problem with Guix is mainly that Guile is slow. They use a lot of GNU Guile in their operating system for eg the package manager but also for initialization processes and other things. If they had chosen Chez Scheme they would have had a very similar language that performs much better.

NixOS is therefore faster than Guix in terms of performance in some things, but NixOS is more a mix of different programming languages, and less structured in its general approach.

Out of Flatpak, AppImage and Snap I observe that AppImage usually gets the best performance in reality (boot times, total MB disk usage, raw performance after startup, etc)
Snap ranks the worst of the three here overall.


----------



## Jose (Oct 18, 2022)

zirias@ said:


> So, what's your concern about _that_ in this context?


My concern is that Pkgbase only makes sense if you want to release kernel and base independently. It only makes things more complicated otherwise.

More, smaller, tarballs = more work to install, and as you said yourself "It also creates problems of course, e.g. you have to start actually _tracking_ dependencies to 'base packages' from ports."


----------



## kpedersen (Oct 18, 2022)

I tend to agree. If we don't like to discuss old unsupported versions of FreeBSD because they are time consuming for us to debug, I think trying to debug some guys half-installed Frankenstein ('s monster) FreeBSD base is going to be much worse.


----------



## zirias@ (Oct 19, 2022)

Jose said:


> My concern is that Pkgbase only makes sense if you want to release kernel and base independently.


No. Then you just got it wrong. Maybe you should have had a look first, the base Makefiles long since support building packages. It's basically just an additional variable telling which packages the built binaries belong into.

Splitting base, releasing parts individually, is and was never planned (and would make no sense, if you wanted _that_, you could just convert everything to ports). All pkgbase was ever about is not having to install everything if you don't need it, pretty similar to how you can use all these `WITHOUT_*` knobs when building from source. A possible benefit is simplified distribution of the binaries, e.g. for security patches.



Jose said:


> More, smaller, tarballs = more work to install


Again, no. There's already `pkg`, together with the also existing concept of meta-packages, it will just install everything by default.



kpedersen said:


> I think trying to debug some guys half-installed Frankenstein ('s monster) FreeBSD base is going to be much worse.


If you imply you could mix packages from different base versions, then no, this will never work. Dependencies will be on exact versions, so `pkg` would refuse installing such a mixture. If your concern is just "missing" base packages causing problems for someone, well that's exactly what I meant with ports having to track base dependencies as well for pkgbase to be production ready.

You can already leave out stuff building from source, but ppl doing that are expected to understand the problem if they're missing something some port would require to work. But once you support binary packages, of course you'll have to make sure all dependencies are correctly set.


----------



## Alain De Vos (Oct 19, 2022)

Note : To distribute you can just make a tarball of /usr/src & /usr/obj after a buildworld,buildkernel ...


----------



## Jose (Oct 19, 2022)

zirias@ said:


> Splitting base, releasing parts individually, is and was never planned (and would make no sense, if you wanted _that_, you could just convert everything to ports). All pkgbase was ever about is not having to install everything if you don't need it...


These two sentences directly contradict each other.


----------



## zirias@ (Oct 19, 2022)

Jose said:


> These two sentences directly contradict each other.


Seriously, no. And I really don't have any idea how else to explain it.


----------



## Alain De Vos (Oct 19, 2022)

Jose, the wording is indeed a bit strange but the context what Zirias said,
"pkgbase is similar to WITHOUT_* k" explains it.


----------



## zirias@ (Oct 19, 2022)

Similar in effect, likely more fine-grained, but the same concept. Base is one single project, going through classic release engineering (released as a whole of course), just the output is a set of (a few hundred) individual packages instead of "only" a few tarballs (e.g. 9 for FreeBSD:13:amd64).

BTW, we already have kernel.txz as a separate distribution file. And it already doesn't mean the kernel would be "released separately". Distributing many files at once doesn't make them individual releases....

edit, I repeat myself briefly: There *are* things to criticize (or, depending on your POV, problems yet to solve) about pkgbase. There's a reason it's not production-ready yet. But claiming it would losen the integration of base is a wrong assumption based on misunderstanding the concept.


----------



## Erichans (Oct 19, 2022)

Jose said:


> zirias@ said:
> 
> 
> > Splitting base, releasing parts individually, is and was never planned (and would make no sense, if you wanted _that_, you could just convert everything to ports). All pkgbase was ever about is not having to install everything if you don't need it...
> ...


As I see it, "releasing parts individually" does not necessarily mean that they have to be on a different release mechanism or timed differently as compared to the kernel. They (i.e. the to-be-packages inside the base install) are just "released" on a per packages basis; think of it as "are made available". Updates on those packages are still to be made under the same scheme as today for the base install.

There are however differences with the (binary) packages in ports as those are governed by "latest" or "quarterly" release mechanism. Latest  is basically on a rolling release mechanism, whereas quarterly is on a "synchronously timed release mechanism" (4 times per year; i.e. quarterly); keep in mind though that quarterly is just a timed snapshot of latest. Packages are also governed by a (very) different set of quality rules regime. Every package manager and the team as a whole tries its very best to create a coherent set of packages in relation to other packages in ports but, that puzzle is not always 100% succesful; think alone of the sheer total number of packages in ports, in addition to the small problem of packages that rely on a different kernel ABI when that changes in the base install (rare). Contrast that to the smaller and more coherently tested whole of a base install.

Bringing packages to the base install would therefore bring another set of packages with different properties than the packages in ports and that would demand extra attention in clarifying those differences to FreeBSD users. IMHO, on balance, I cannot see the big advantage of packages in the base install. As stated, if one wants to selectively create a base install one should build one.

Edit: didn't see zirias' latest message above.


----------



## zirias@ (Oct 19, 2022)

Disclaimer: I'm fine with how base is distributed currently (the set of very few tarballs). Still I think pkgbase is conceptually a good idea:


Erichans said:


> I cannot see the big advantages of packages in the base install.


To summarize:

End-user "experience": You don't need something, you don't have to install it (while the default install of course still installs the whole base system). If there's a security patch for something you haven't installed, you're not affected. etc...
A chance to unify distribution mechanisms. Currently, some complex stuff is required to create and maintain update servers for freebsd-update(8) to just download binary patches. Additional pkg(8)-repositories would be a lot simpler and are already proven for ports. Of course, such a goal is still far away...
So, it could provide simplification and flexibility. And it's still far from finished. And if it's never completed, I'm not sad about it. But if it is, it will be a nice thing.


----------



## Alain De Vos (Oct 19, 2022)

Much simpler, you could also remove functionality ports from base, like sendmail, and put them in ports.
One can also ask the question why no browser is part of base.


----------



## zirias@ (Oct 19, 2022)

Alain De Vos said:


> Much simpler, you could also remove functionality ports from base, like sendmail, and put them in ports.
> One can also ask the question why no browser is part of base.


While I agree that sendmail doesn't *have* to be in base, _some_ MTA is required*). A working base system at least must be able to deliver local mail. A browser OTOH definitely isn't necessary for a working system.

But this hints to another advantage of pkgbase: For some more "controversial" base components, like e.g. sendmail, the discussions would probably fade away as you can tell any user: "if you don't need it, just don't install it".

edit: Reminds me of yet another advantage: There are quite a few ports suitable to "replace" vital base components, e.g. exim/postfix/..., openssh, libressl, .... with pkgbase, users of these could simply choose NOT to install the corresponding base package.

*) IMHO, dma(8) should be "good enough" for that purpose...


----------



## Jose (Oct 19, 2022)

Either there's a base or there isn't. Once "base" becomes a set of packages you can pick and choose from, there no longer is any common "base" and you descend into Linux madness.

You say current base can be customized with compile-time knobs, as a justification for this a la carte approach. I say that customizing base under the current system requires significant knowledge and effort. You will learn a lot just from attempting this, and this knowledge will help you troubleshoot the problems you will encounter. Once it becomes easy to scramble what's in "base" lots of fools will start removing things for stupid reasons like they read on some Internet forum that removing libc would make their system faster.

Yes, the line between what should be in base and what belongs in ports is not always clear. Sometimes difficult choices have to be made which will not please everyone. That is another key difference between Freebsd and the Linuxes. These unpleasant choices are made. You'll have to do the hard work of evangelizing to change the consensus if you strongly believe something should or should not be included. Over in Linux-land you just roll your own "distro" and foist it on the world.


----------



## zirias@ (Oct 19, 2022)

Jose said:


> Either there's a base or there isn't. Once "base" becomes a set of packages you can pick and choose from, there no longer is any common "base" and you descend into Linux madness.


The current practice of distributing several tarballs (some of them even optional) already calls bullshit on that.


----------



## kpedersen (Oct 19, 2022)

zirias@ said:


> The current practice of distributing several tarballs (some of them even optional) already calls bullshit on that.


I only see one base.txz. And extracting that is all that is needed to install the base userland in i.e a Jail or chroot.

Already if they remove that and replace it with the pkg mechanism, it will be slightly more awkward to populate Jails. Instead you will need to do it via bsdinstall (akin to debootstrap) or via pkg (akin to dnf). Neither approach is as simple as the current one unfortunately.


----------



## Alain De Vos (Oct 19, 2022)

The tools to install base should also be in base. E.g. /usr/bin/tar


----------



## zirias@ (Oct 19, 2022)

kpedersen said:


> I only see one base.txz.


Then you won't have any kernel, cause that's in kernel.txz.


----------



## kpedersen (Oct 19, 2022)

zirias@ said:


> Then you won't have any kernel, cause that's in kernel.txz.


Indeed. You don't need a kernel for a jail (presumably a perfectly good one is already running by that point).

I guess if your definition of a _base_ also includes _kernel_ then there are two packages but as far as I thought; _base_ was only concerned with userland.


----------



## Alain De Vos (Oct 19, 2022)

Jose said:


> Either there's a base or there isn't. Once "base" becomes a set of packages you can pick and choose from, there no longer is any common "base" and you descend into Linux madness.
> 
> You say current base can be customized with compile-time knobs, as a justification for this a la carte approach. I say that customizing base under the current system requires significant knowledge and effort. You will learn a lot just from attempting this, and this knowledge will help you troubleshoot the problems you will encounter. Once it becomes easy to scramble what's in "base" lots of fools will start removing things for stupid reasons like they read on some Internet forum that removing libc would make their system faster.
> 
> Yes, the line between what should be in base and what belongs in ports is not always clear. Sometimes difficult choices have to be made which will not please everyone. That is another key difference between Freebsd and the Linuxes. These unpleasant choices are made. You'll have to do the hard work of evangelizing to change the consensus if you strongly believe something should or should not be included. Over in Linux-land you just roll your own "distro" and foist it on the world.


I removed some stuff. As learning experience.
For instance in the kernel i have:

```
nooption     COMPAT_FREEBSD32    # Compatible with i386 binaries
```
So my kernel is not compatible with i386

For world i have:

```
WITHOUT_LIB32=yes
```
So no 32bit libraries in world

I don't think my system is faster, but at least it does not include software I don't use.
[ PS : For xfce-desktop i'm forced to pull in samba but have no choice]


----------



## Crivens (Oct 20, 2022)

Alain De Vos said:


> The tools to install base should also be in base. E.g. /usr/bin/tar


Sorry officer, the keys to the safe are in the safe...

We have a kernel "package" and a userland "package" right now. You can run older userland on a newer kernel, this is one line of dependency. Once you start breaking up base, you end up with a subset of a K{n} of all n components. If I were asked I would vote for keeping base in one set and maybe make it easier to deactivate things. Because once you mess with the dependencies, you are responsible.

The idea to have base as one package (.pkg) seems to be that it is easier to install jails that way, because now you only set up the jail with the application and it will pull the correct base in by itself, saving extra install steps and making sure the requirements are met. This looks like a move to reduce support efford by making this more fool proof.

Freedoms and accountability come in one package, you are not free to choose one but not the other. The Team gives you a perfectly good base, you want things removed, YOU do it. And YOU will make sure it works because the blame is with YOU. I don't want the Team to do all that tracking and testing, they have better things to do.


----------



## Alain De Vos (Oct 20, 2022)

/etc contains configuration. Installing base as a package will still require etcupdate.


----------



## hardworkingnewbie (Oct 20, 2022)

If Linux would be developed like FreeBSD, meaning there's a standard kernel coming with a standard userland, there would be no need for things like Snap or Flatpak.

BTW Ulrich Drepper was the maintainer of glibc, he stopped being it in 2012 when a group of developers took that helm.


----------



## Jose (Oct 20, 2022)

Crivens said:


> We have a kernel "package" and a userland "package" right now. You can run older userland on a newer kernel, this is one line of dependency. Once you start breaking up base, you end up with a subset of a K{n} of all n components.


And if you have n packages to choose from, and say you choose k of them, the possible combinations grow by n!/(k!(n-k)!).


----------



## Alain De Vos (Oct 20, 2022)

Just modify /etc/src.conf & you specify WITH or WITHOUT, does the same thing ? No ?


----------



## zirias@ (Oct 20, 2022)

Alain De Vos said:


> Just modify /etc/src.conf & you specify WITH or WITHOUT, does the same thing ? No ?


Conceptually yes, but it's less fine-grained than pkgbase would be. And a key difference is, ports don't have to care about dependencies to base, because anyone building their own base is expected to be able to solve such problems.


----------



## zirias@ (Oct 20, 2022)

kpedersen said:


> I guess if your definition of a _base_ also includes _kernel_ then there are two packages


Actually, there are more, e.g. packages with debugging symbols, or with 32bit libraries.

And yes, the kernel is part of the base system. Anything that's in the `src` repository is part of the base system, developed as a whole, and whatever is built from it is released together, no matter whether it's 9 tarballs or a few hundred .pkgs.


----------



## sidetone (Oct 20, 2022)

As much as I dislike Ubuntuism and Redhatisms. That's the purpose of it, to be able to do that, for them, or anyone else. If they keep it separate from the rest of their system, it may be good for their base system or even make that part better.

But one problem is the implication that the free set will be neglected and the other one gets better maintenance which it's supposedly supposed to be better. As long as the community is able to keep it good, but from the perspective of the company, a community repository is a competing product.


----------

