What do you think about the new "package base"?

If we admit to Linux's way being easier, more flexible and more reasonable, why is it shameful to adopt? It's shameful that you ridicule Linux users for their decisions. There is nothing shameful about admitting you were wrong and they were right.
 
We used to ridicule Linux and praise ourselves that we have separated ports and base upgrade mechanic.

Did we? I've not been here long, but when people said "we have a separate base and third party Ports system" that they were referring to the fact that we have a base system that is developed as a whole (as apposed to GNU/Linux which simply integrates many third party components) and the Ports system which give easy access to third part programs.
The update mechanism never even entered my mind when people spoke about Base and Ports.

Following along the conversation on the mailing lists, this pkgbase is being offered to FreeBSD by iXsystems after developing it for their TrueOS/TrueNAS products. There is also some required tooling that probably wouldn't end up in FreeBSD's Base system as is and would need some additional development. I believe that this is separate to another pkgbase project being developed within the FreeBSD project.

Do I care what method FreeBSD uses to update my system? Not particularly as long as it works. I prefer binary updates since my machines are fairly standard and not overly powerful.
I would be interested in learning more about how building pkgbase works, my current understanding it that it uses ports-mgmt/poudriere. If that eventually simplifies the system (i.e. only having to maintain ports-mgmt/poudriere infrastructure and dropping freebsd-update(8) infrastructure) then the project can hopefully be more efficient in terms of infrastructure and resources to manage/maintain/develop said infrastructure?
 
I kinda liked that ports / packages were installed into /usr/local and if I broke anything, I could just delete that directory and start again. Obviously the base will not be moved to that directory but I did actually prefer a clear separation.

Really I am happy so long as "base" is a single package and not split into multiple. That way I can just hold back on a base update and only update packages.
I think if /bin/sh starts updating separately to /bin/awk, it is pretty much game over in terms of deterministic behaviour.

Why was this change made? Surely there were more pressing or interesting problems to be solved?
 
For those who are not subscribed to the mailing list, there's more information to be found in the mailing thread. Some legitimate concerns have been raised there.

I haven't delved into this, but as far as I know it's not easy to setup your own freebsd-update() server. While this isn't very useful for i386/amd64 except for
building customized kernels or in offline environments, it might be useful for Tier ≥2 (ARM/ARM64 etc) systems.

If that eventually simplifies the system (i.e. only having to maintain ports-mgmt/poudriere infrastructure and dropping freebsd-update(8) infrastructure) then the project
can hopefully be more efficient in terms of infrastructure and resources to manage/maintain/develop said infrastructure?
Second that. Resources are finite. Take a look at the FreeBSD Foundation financials and especially the counter on top of the page.

My opinion: I prefer having a clean (well-developed) option that works without too much hassle.
When freebsd-upgrade was added to the base system, it made upgrading a lot easier. I was happy.
When the current pkg was added in -RELEASE and ports-mgmt/poudriere to ports, I switched from sysutils/portupgrade. I was happy.
When staging was added to the ports system, I benefited. I was happy.

I trust the FreeBSD developers to make a good decision on PkgBase (either one of the proposals). If it wasn't clear from the text above, I'm happy with the current situation ;)
But I'm not against changes just because they're changes. Or at least, I am no longer. It's a process I had to learn myself, not to get stuck with what I know.
 
I came to FreeBSD for a couple of reasons: sane init system, OS developed as a whole and the virtual separation of the core OS and the user apps. I personally like that there is a one set of tools to update the OS and one (or more, depending on your choice of packages or ports) set of tools to update the user apps. As others have said, if it all goes to heck, you can delete /usr/local and the OS keeps on trucking.

I probably don't understand the implications of "pkgbase" since I am a relatively new FreeBSD user but I too trust the FreeBSD devs to make the right decisions about this.
 
I think it's like a punch in the face.
Wrong. It is an idea that is being discussed and tried out. I have only looked a little bit at it, and it seems reasonable to use large parts of the existing pkg mechanism for the base system too. It might have unintended consequences or problems that I don't understand yet, but it is very likely that the large set of people working on it it or watching it (there are at least a dozen) will be finding those. I like the fact that this is being tried twice, in different places by different (but overlapping) sets of people; that makes it likely that problems with one or the other implementation will be found. The main proponent and author (Kris M) is trustworthy and right-headed.

We used to ridicule Linux
Stop right there. That statement is not just wrong, it is outright evil. There is no "we" here. Maybe you do, and you are free to say anything you want, that's freedom of speech. I do not ridicule Linux. I use Linux heavily. And while I don't always like all of its aspects, and regularly speak out about its shortcomings (all I need to say is "Lennart" and "systemd"), that doesn't mean ridicule.

Honestly: If you are a member of the FreeBSD community only because you hate Linux, then I would prefer that you were not a member of the community. Technical decisions about OSes should not be based on hate (nor on FUD or ancient history).

... and praise ourselves that we have separated ports and base upgrade mechanic.
The mechanics, the "how" the upgrade works, is not very important. The important part is much more philosophical: The base is a single coherent thing. You install either all of it or none of it, and after you install it, you have a functioning shell-based Unix-style OS with networking and the common servers. It all has a single version number, and as long as you are using just install and update, it transitions from one version to the next mostly atomically and consistently (modulo the fact that until the next reboot, running and installed kernel version may differ). And its version has isolation against the version of other packages. The proposals discussed here do not touch or question those axioms.

It's shameful.
It is not shameful to adopt a good idea when you see it. Even if it comes from someone outside your immediate community. Most OS development has worked that way. Matter-of-fact, the name "Unix" is a play on words of the predecessor "Multics", from which Unix stole many good concepts (while leaving the not-so-good concepts). The same applies to other sources of ideas, for example: If Microsoft has a good idea, let's use it if it helps, and let's not use it if it doesn't.

I really don't like the fact that so many people use "hate" as their source of technical decisions. If you hate Linux, I would suggest that you go out for a few beers with Linus, that might make you understand things.
 

I think it's like a punch in the face. We used to ridicule Linux and praise ourselves that we have separated ports and base upgrade mechanic. It means we admit Linux's way is practically easier, more flexible and more reasonable than our own that we finally have to adopt it. It's shameful. What about you?

The base OS and the ports tree will still be completely separate. The base OS lives in /usr/src. The ports tree lives in /usr/ports. Ports are installed to /usr/local. None of that is changing.

All that's changing is that you can run make package under /usr/src and get a series of binary packages that can be installed, upgraded, and managed via the pkg(8) tool. Yes, the same pkg tool that is used for installing binary packages created from the ports tree. But they install into different spots and have different dependencies and will probably come from different repos.

This isn't turning the base OS into "just another set of packages from the ports tree" (aka the Linux distro model). This is going to replace the freebsd-update(8) tool that does binary updates of the OS. Nothing more.

You'll still do development of the base OS under /usr/src. There will still be a concept of "base OS" that's usable without installing anything from the ports tree.

Note: this is also not an official FreeBSD Project call-for-testing. This is a call-for-testing of the iX Systems / TruOS binary package setup. More of a proof-of-concept of one way to do base packages. There's another project underway (the make package target under /usr/src) that's in development by the FreeBSD Project, and has been available for testing since 12-CURRENT.

So, you're getting your knickers in a twist over something completely unrelated to what you're thinking it is. :D
 
Sounds like a great idea-- a logical extension of the already developed and widely tested FreeBSD pkg system, which is easily and by far the most flexible package management system I've used to date.
 
I came to FreeBSD for a couple of reasons: sane init system, OS developed as a whole and the virtual separation of the core OS and the user apps. I personally like that there is a one set of tools to update the OS and one (or more, depending on your choice of packages or ports) set of tools to update the user apps. As others have said, if it all goes to heck, you can delete /usr/local and the OS keeps on trucking.
In Linux there's no clear separation between the base system and third-party software because as far as a distribution maker is concerned, everything from the boot manager to the web browser is essentially third-party.

FreeBSD too has (and always had) third-party software outside of /usr/local but they're considered to be part of the base simply because they're maintained by the team.

For both operating systems, it really doesn't matter whether there's just 1 tool for updates, or 2 or a dozen. What matters is how things are organized on the file system. And this will not change any time soon. So rest assured you'll still be able to # rm -r /usr/local if you want.
 
I don't really need 2 tools to updates the system; It just reinforces in my mind the OS and user apps are separate. This is an informative thread, appreciate the information.

I have only removed the contents of /usr/local once; it's not something I routinely do 😝
 
A difference that I did not realize until today and that is well discussed in the mailing list is the fact that ports will have dependencies related to other ports (like they have now) but also to base packages. I have no clue if it will be easy for ports maintainers to determine those new dependencies.
 
If they keep the option to choice between this new feature and keep using the ports and compile the kernel...is ok
If not...bulsh#@ , but FreeBSD is ok as it is, please..please dont contaminate a excelent system
 
It will save time on removing extra components from base. Clang and formerly GCC from base take long to compile, then a port will require a newer version. Most of what is in base should be kept in, or it breaks the system, but there are things that can be removed, like cleartext services, without breaking the system, or things you know you won't choose to need at all. It's kind of fun finding which applications break which ports, to inform others about these learnings, except it's very time consuming.

When I leave Clang out of base, and install it from packages, time compiling the base is reduced to 2 to 4 hours, which is great.

Using the compiler and its utilities in base package will be beneficial to prevent redundant compiles and installs, it will speed up troubleshooting and improvements of toolchains, and will clarify better understanding of the purposes of various sourcecodes. As an example, in src.conf one option is labeled as for legacy hardware, but it is required as a dependency for drivers that run new hardware too, and that's not self explanatory.

I like being able to compile the base sourcecode myself, but it's time consuming, and takes a lot of trial and error to get it the way I like without having to start over.

The minimum required FreeBSD system shouldn't be included as options in package base. But package base could be a set of vanguard applications with better [quality] controls than ports. It can also be a good starting point to have common components, that will remove redundancy as bloated dependencies from ports.

Improvements in processor compiling speed, and addition of documentation of which ports and applications require which base components can also do away with much need for package base, except for the compiler and its toolchain.

FreeBSD can benefit from package base, but then, it should largely go back to the original way, while carrying over improvements made on the sourcecode. Then, base compilers and toolchains should either go to PCC, or they should have their own or subset package system.

I see packagebase as a temporary way to ease the transition to libressl and toolchain components for all architectures without having to slow this down by restraining to release cycles.
 
Last edited:
In Linux there's no clear separation between the base system and third-party software ...
You have to remember that Linux is not an operating system. It is a kernel. The thing with the trademarked name "Linux" is downloaded from kernel.org, and it builds just the kernel (plus modules). For 99.99% of users, a naked kernel is not useful.

The thing that everyone commonly calls "Linux" is actually a distribution, such as RHEL or Suse. The distributors take a version of the kernel, often patch it (in the case of RedHat quite heavily), and then package it with all the things that make it into a usable OS, for example run-time libraries (beginning with the very fundamental ones like libc), compilers, an init system, login and authentication, a shell, and basic tools. At that point, you have what most users would call a "minimal OS". And the distributor is then free to stack other software on top of it, such as the rest of a LAMP stack, or a GUI and DE, or server applications. And the distributor is free to decide how to break all of this (including the kernel) into "packages". In theory, there is nothing that prevents a Linux distributor from creating a version where kernel and base system are a single package; but I've never seen it done.

There is another thing to consider. Here in the forum, we are in a world of tinkerers, who understand (or at least try to) the internals of the system, and try to "improve it". We're the kind of people who worry about individual packages. For example, in the 90s, I used to take whatever Linux version I was running (SLS, Slackware, Debian, RedHat, you name it ...), and immediately rip out the kernel and replace it with a vanilla one from kernel.org. I was actually modifying kernel sources, and some of my modifications even made it into the official sources. But: 99% of all users are not tinkerers or hackers. They install something, and they want it to "work", meaning getting useful work done, with high productivity, and little hassle and anxiety. They don't care what's underneath the blanket, or how the sausage was made. Part of that absence of hassle and anxiety is a smooth and efficient upgrade process. And this is where FreeBSD has (in my not at all humble opinion) great advantages: as long as you keep up-to-date, and run freebsd-update and pkg up* frequently enough (once a week?), it is very smooth.
 
"Following their work on TrueOS, iX Systems has been working to craft FreeBSD into a "pkgbase" configuration whereby the base system and kernel are managed in package form via Pkg."

I have no use for IX Systems of TrueOS. I took a 2 year sabbatical to study on my own around 2007 and when I returned to the PC-BSD forums IX Systems had taken over the the users were seen as a data collection source from their posts.

My reports of the Firewall Manager GUI breaking pf completely ignored for over a month till the black sheep fled that feckless flock to where my words would be heard in the Security community and got results in 1-2 days. They had planned to put off a fix till the next version bump. To my knowldge, I was the only one using PC-BSD 9 Isotope with a functional pf firewall.


As if that wasn't bad enough, on June 22, 2018 I mentioned being Wexiong having been a beta tester for PC-BSD with forum number around #60 and being privileged to first hand information a PC-BSD fanboy would not during a heated discussion between factions.


On July 1st 2018 when a post came up about opinions on Firewall managers/builders, the reliability and risk associated with using them.


I checked the PC-BSD forums for my old post and had been ghosted sometime over the previous 8 days. The forums and wiki had all disappeared. I had been looking through the forums recently to view my embarrassing posts from mid to late 2000's. The Forums having been previously referred to in their documentation as a Wealth of information".

Now I don't have to be the Red Devils Advocate to make this case in the court of public opinion. Someone, and I have a good idea who (not Dru) saw that post, realized who I was to them and what that first hand knowledge was. Devastating for the reputation of TrueOS Admin in regard to security of their product, the of safety of their users or having put off fixing it for months..

In their effort to erase 7 years of my life as Weixiong and any sign I ever existed they make the same mistake twice. They underestimated me.

First thinking they could ignore me for a matter this serious and I would say "Baa" like everyone else in the flock did and keep quiet. Weixiong being the only person who spoke up for everyone or saw it as the serious issue it was. After a new member stated he was going to deploy it as a server Weixiong took it to a site where it would not be ignored and posted it as my real name, jitte.

The second time they thought themselves so superior in stature and status to Weixiong in every way they could ghost him and what could a lowly user like Weixiong do about it once it was already vapor? They were just too smart for Weixiong, but not jitte. None too big or powerful for Trihexagonal to fear when speaking the facts.

Out them here like they deserve with every shameful detail of the story for the FreeBSD community to see. You tried and failed to ghost Weixiong, this is the consequences of a failed action you brought on yourself. If he haunted you forever with the story it would be no worse than you deserve in his opinion.

I had never mentioned that here since joining in 2012 out of respect for PC-BSD and the time I had invested in it as professional courtesy. I never would have said a word if they hadn't thought me a fool and a speck of dust to be swept under the rug.

But their memory is no better then their scruples. They forgot I had posted the incident at Widers Security Forum, where they had no to power to undo history. I have page copies saved so don't even think about it. Weixiong is liable to post them anywhere anytime. That made it personal and everyone should know the truth of it as documented.

I feel bad for any detrimental effect or headache it caused Dru, but I only documented the facts. I don't know her personally but the person who did needs take ownership and I don't believe it to be her. Again, I would never said a word if someone hadn't thought a cover-up better than the truth. Now the truth cannot be stopped by anything but the truth about what a mistake it was. I know bigshots never apologize so accept the fact PC-BSD gave it's users the shaft.

Oh please, by all means, someone step up and try to say it was a coincidence and all in my imagination. Someone on that team with authority to delete a forum has now twice thought me stupid, so maybe I'll believe it this time. The smart thing to do is beyond someone comprehension or they never would have tried such a lame scan to begin with.

It's a black mark on not only PC-BSD Admin but your sites claim "TrueOS soars above the competition with advanced security features, such as GELI full-disk level encryption, to keep your important data safe and secure." Something best forgotten for the good of everyone's reputation so it was all erased from recorded history. Mostly.

It will be painful to own up to past mistakes, but no more painful for you than it was for what was done to Weixiong. Honesty the path to redemption and a restful spirit of vengeance. Weixiong spent 7 years of his life to beta test your product, taking 2 off to study and this is how you treat your flock? Weixiong is a restless ghost and this story his to tell as a long he feels like it till he finds peace.


Trust IX Systems or TrueOS? Not me, thanks anyway. I'm happy with FreeBSD the way it is and don't want some bastardized version that can't even make up it's mind what to be called.
 
I don't see this as simply an issue of "not invented here".

The clear separation between base and ports should be preserved in my opinion, including the base system tools used to manage and upgrade the base system such as freebsd-update. The base system is FreeBSD, ports is not. Many users still build ports from source, many use only a few specific packages/ports and don't necessarily run a desktop system - TrueOS has very different goals/objectives and is focused on being easy to set up and "graphical" "out of the box" (according to their own website).

What this comes across as, to me at least, is more unnecessary reinvention of the wheel and more "monolithic" merging and streamlining efforts. If you have a specific tool that does a job and does it well, why add even more complexity and scope to the already complex and "apt like" pkg, to take over the role of the already robust and working tool? Why increase "attack surface", complexity and the probability of more bugs and security issues needlessly just because of some OCD thing to have "one tool". It all seems very familiar somehow...

At present pkg should only touch /usr/local, with rare exceptions (none at all?). So this would all change and you have the concern that the pkg tool is also touching the base system.
 
I like FreeBSD because it's something different. If someday it turned into some Linux clone of BSD license I'll left. I would consider Tribblix, I always want to try it. Let's see how it will be :)

Edit: you guys overestimated about FreeBSD as a whole system developed together unlike Linux that you called LEGO. I think it's wrong. You does use and include and adapt/customize/patch third party components nothing different than Linux. The GNU userland despite being portable it main platform is Linux, hence the name GNU/Linux. They are well integrated and well fit together not any lesser extent than FreeBSD. They even more tested and stable than FreeBSD thanks to large user base and much more manpower. The marketing slogan 'developed together, well fit together' just plain nonsense. Just my 2 cents ;)
 
I'm looking forward to pkgbase, because it will potentially be a great tool for my usecase:

I have at home a server with many jails and (bhyve) virtual machines, a desktop, several laptops, all running FreeBSD and all using my custom-built base and custom-built ports. For the ports, ports-mgmt/poudriere does a great job building a ready-to-use package repository that can be hosted on e.g. www/nginx. For base, the official way to do binary distribution is a freebsd-update-server. Setting up your own is complicated, I gave up on this. I use a simple workaround instead, suggested here on the forums:
  • share /usr/src and /usr/obj readonly with NFS to all machines
  • copy /etc/src.conf to all machines
  • on all machines except the "master", only do the make installkernel, make installworld and mergemaster steps.
This works very well, but having a pkg repository for base would still be nicer :)

About all this "cloning Linux" nonsense: FreeBSD is a complete and self-contained OS where toolchain, kernel and basic userland live together in one source repository and are developed together, so they always match. This has nothing to do with the mechanism for binary distribution. Building fine-grained packages from this one source tree just adds a bit of flexibility, you can finally leave out some components without building it all yourself. You still get the complete and well-integrated base OS. If you install it, you still have the guarantee that all the basic tools just work, that the toolchain installed is complete to (re)build anything you want, etc. pp. With Linux, all of this is in the responsibility of the "distribution" project. Nothing like that will ever happen to FreeBSD.
 
I'm looking forward to pkgbase, because it will potentially be a great tool for my usecase:

I have at home a server with many jails and (bhyve) virtual machines, a desktop, several laptops, all running FreeBSD and all using my custom-built base and custom-built ports. For the ports, ports-mgmt/poudriere does a great job building a ready-to-use package repository that can be hosted on e.g. www/nginx. For base, the official way to do binary distribution is a freebsd-update-server. Setting up your own is complicated, I gave up on this. I use a simple workaround instead, suggested here on the forums:
  • share /usr/src and /usr/obj readonly with NFS to all machines
  • copy /etc/src.conf to all machines
  • on all machines except the "master", only do the make installkernel, make installworld and mergemaster steps.
This works very well, but having a pkg repository for base would still be nicer :)

About all this "cloning Linux" nonsense: FreeBSD is a complete and self-contained OS where toolchain, kernel and basic userland live together in one source repository and are developed together, so they always match. This has nothing to do with the mechanism for binary distribution. Building fine-grained packages from this one source tree just adds a bit of flexibility, you can finally leave out some components without building it all yourself. You still get the complete and well-integrated base OS. If you install it, you still have the guarantee that all the basic tools just work, that the toolchain installed is complete to (re)build anything you want, etc. pp. With Linux, all of this is in the responsibility of the "distribution" project. Nothing like that will ever happen to FreeBSD.
And what you will experience is just the blessings Linux users long enjoyed ;) When do comparison, don't cheat by only compare with Linux kernel and think Linux distributions the way Linux From Scratch book doing. Compare with full blown OS like Debian or SUSE. And I think they are just more well integrated and well fit together than FreeBSD, and they have home grown features too, make then distinct from a whole mess of hundreds of distributions ;)
 
Boring troll ...
This is a fact, not troll. But with people always think FreeBSD is the best that even become a religious belief everything opposed to their faith is troll. If you can, please elaborate where I was wrong. I will listen carefully :)
 
Given the torrent of "What you think about" threads you started, all with a lot of negative nonsense and some Linux hate, I sincerely doubt that.

I personally don't hate Linux at all, I hate some particular decisions most distributions made, but that's even off-topic for this thread. The key difference between FreeBSD and Linux you (!) started to talk about is that FreeBSD is a whole operating system while Linux is just a kernel that's combined with a GNU userland by distributors. So far so good. Pkgbase won't change anything about that.
 
Back
Top