The snap is a walled garden made by ubuntu

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.
 
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...
Click to expand...
These two sentences directly contradict each other.
Click to expand...
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.
 
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.
Click to expand...
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.
 
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.
 
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.
Click to expand...
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...
 
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.
 
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.
Click to expand...
The current practice of distributing several tarballs (some of them even optional) already calls bullshit on that.
 
zirias@ said:
The current practice of distributing several tarballs (some of them even optional) already calls bullshit on that.
Click to expand...
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.
 
zirias@ said:
Then you won't have any kernel, cause that's in kernel.txz.
Click to expand...
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.
 
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.
Click to expand...
I removed some stuff. As learning experience.
For instance in the kernel i have:
Code: 
nooption     COMPAT_FREEBSD32    # Compatible with i386 binaries
So my kernel is not compatible with i386

For world i have:
Code: 
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]
 
Alain De Vos said:
The tools to install base should also be in base. E.g. /usr/bin/tar
Click to expand...
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.
 
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.
 
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.
Click to expand...
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 said:
Just modify /etc/src.conf & you specify WITH or WITHOUT, does the same thing ? No ?
Click to expand...
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.
 
kpedersen said:
I guess if your definition of a base also includes kernel then there are two packages
Click to expand...
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.
 
  • Like
Reactions: mer
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.
 
You must log in or register to reply here.
Back
Top