What's happening to FreeBSD?

rbranco said:
freebsd-update is a bit redundant with pkgbase now.
Click to expand...
pkgbase was redundant with freebsd-update from start. 😉

I saw the slides and the video of pkgbase in Production: A Practical Overview but it does not convince me - and not only because Lukas Engelhardt is working in a Powershell 6 (not 7.x) on Microsoft Windows 11 during the session. Maybe I do not get it:
  • In 2026 some has not enough storage for running FreeBSD so they want to remove parts of the system?
  • Some wants to run FreeBSD on embedded hardware? Seriously? Why reinvent the wheel?
  • pkgbase enables some to build their own packages. What was the reason for poudriere and ports?
And after all: What has this to do with "Production"? For me it is only a demo of a sysadmin using pkgng during shift from 14.x to 15.0. All I saw was a long list of commands for transition to pkgng. He tells me nothing about his systems and his problems which are solved by pkgng.

bakul said:
This can be due to user error or some driver issue or something going wrong during install. BE protects against all three. Making an installation foolproof takes a lot of time and lot of systems and having to consider a lot of variability. FreeBSD doesn't have the resources for it and most volunteers don't want to spend time on doing this sort of work. Now this may be a good use of AI....
Click to expand...
??? I do not understand your point. BE solves all issues but you want to throw AI on ... which problem is left?
 
fahrenheit said:
I have nothing against ZFS or BEs. What I was saying is that most of the cases where I see BEs (and ZFS usually, but as vermandeen explains on his blog also possible with UFS, or lets be real, with any filesystem, ZFS BEs are just better integrated after all these years) is by users worried, just like you mentioned, that an upgrade breaks their system.
So, in my opinion, what should be solved is the breakage, real or potential, people associate with upgrades.
Click to expand...
This UFS setup is convoluted and wastes disk space. This seems like an A/B partition scheme with a /C added? Why not take advantage of UFS snapshots?

They're not real Boot Environments like ZFS provides and that he masterfully describes here:
vermaden.wordpress.com

ZFS Boot Environments Explained

This article will not be a general ZFS explanation attempt – we will focus on ZFS Boot Environments only. There are a lot of misconceptions and misunderstandings when it comes to them –…
vermaden.wordpress.com vermaden.wordpress.com
 
kirsche said:
pkgbase was redundant with freebsd-update from start. 😉
Click to expand...
No because they serve different needs. But with a bit of effort pkgng + pkgbase can make freebsd-update redundant.

pkgbase allows you to define minimal systems in bare-metal, jails & OCI containers. Getting rid of stuff with setuid binaries like the lp commands and ppp is as easy as uninstalling FreeBSD-lp & FreeBSD-ppp.
 
rbranco said:
This UFS setup is convoluted and wastes disk space. This seems like an A/B partition scheme with a /C added? Why not take advantage of UFS snapshots?

They're not real Boot Environments like ZFS provides and that he masterfully describes here:
vermaden.wordpress.com

ZFS Boot Environments Explained

This article will not be a general ZFS explanation attempt – we will focus on ZFS Boot Environments only. There are a lot of misconceptions and misunderstandings when it comes to them –…
vermaden.wordpress.com vermaden.wordpress.com
Click to expand...
Again, not the point. For all intents and purposes it could be some goblin that lived inside a box and had two or more copies of your data in high speed parchment, and when you pressed a lever on your compute engine swapped the teared parchment, after your upgrade operation went kaput, with the parchment that he painstakingly copied before you initiated the upgrade process.
End state, you are back to a working environment, the goblin is still a goblin and the issue is still that upgrades need work.
 
kirsche said:
??? I do not understand your point. BE solves all issues but you want to throw AI on ... which problem is left?
Click to expand...
The point was that BE doesn't *solve* all problems but helps protect your system from being completely messed up.

What I was getting at is that creating a much more foolproof uprgade program *can* reduce even users accidentally messing up, but for that to happen a lot of work, and many more previous bug reports and forum posts would have to be looked at to at least fix known problems and a lot of what-if scenarios and a lots and lots iterations are needed. Commercial companies spend those resources (as well as limit their testing to "qualified" hardware) but most volunteers don't have the needed time or motivation to do such a job. The alternative is for an experienced FreeBSD developer/user/sysadmin to drive some AI to help them (the human) create a much better upgrade program.
 
mer said:
So my current understanding, pkgbase does not depend on ZFS, it works fine on UFS, but the question comes down to should any pkgbase tools become ZFS aware. Again, I don't know. Left brain says "no, user needs to control" Right Brain says "Maybe tools should because easier on newbies".
Click to expand...
freebsd-update(8) is already ZFS aware, that is, it makes use of ZFS (~depends) in the sense that if run on a ZFS on root system BEs will be created during an upgrade. I think that there is no discussion that in the same sense for the binary upgrade management of a packaged base system this ZFS awareness is considered very usefull. I imagine it may be added pkg(8), and even in such a way that it will become a command line option to create a BE when packages of the ports tree are updated/upgraded.
 
  • Like
Reactions: mer
bakul Which problem is not solved by BEs what your tool tries to solve?


rbranco said:
No because they serve different needs. [...]

pkgbase allows you to define minimal systems in bare-metal, jails & OCI containers. Getting rid of stuff with setuid binaries like the lp commands and ppp is as easy as uninstalling FreeBSD-lp & FreeBSD-ppp.
Click to expand...
You’re saying what I don’t understand. On one side we have developer needs. I tried to explain this using the following:
kirsche said:
By the way, I consider downgrading to be one of the most important tasks for developers and QA staff – though not for production systems. If a developer or QA staff member needs a test environment: use virtual machines, containers and so on. Stay well away from production systems! I say this because QA is part of my job.
Click to expand...
But if minimal systems are the reason, why pkgng is the replacement for freebsd-update? Different needs, different tools. Separation of concerns.

I’m still searching for a plausible and reasonable argument to have pkgng as a replacement for freebsd-update.
 
kirsche said:
bakul Which problem is not solved by BEs what your tool tries to solve?



You’re saying what I don’t understand. On one side we have developer needs. I tried to explain this using the following:

But if minimal systems are the reason, why pkgng is the replacement for freebsd-update? Different needs, different tools. Separation of concerns.

I’m still searching for a plausible and reasonable argument to have pkgng as a replacement for freebsd-update.
Click to expand...
pkgng doesn't replace freebsd-update, though the latter is redundant with pkgbase now with pkg-upgrade. The only missing piece is ZFS boot environments like Solaris/Illumos's pkg-update.
 
  • Like
Reactions: mer
Why are people so focused on boot times? The BIOS post of most of my servers takes well in excess of a minute, it just does not matter if FreeBSD then boots in 25 or 20 seconds. Also, unless there is a kernel upgrade, why reboot a FreeBSD server?

systemd was sold to people with the same fantasy, much faster boot times! We all know what a gong show that turned out to be. And now we want to do something similar on FreeBSD?
 
recluce said:
Why are people so focused on boot times? The BIOS post of most of my servers takes well in excess of a minute, it just does not matter if FreeBSD then boots in 25 or 20 seconds. Also, unless there is a kernel upgrade, why reboot a FreeBSD server?

systemd was sold to people with the same fantasy, much faster boot times! We all know what a gong show that turned out to be. And now we want to do something similar on FreeBSD?
Click to expand...
Rc.d is similar for what I know. It's the default configuration that takes time but it tries to activate all hardware. It's of not much use on a dedicated system with a clear list of activities. This can start all services much faster than 25 seconds.
I think faster booting is valuable for full-system development because the post-kernel booting process kind of gets that time added to deliver the start screen of whatever the system is for within acceptable time after the power button. It also counts at a power failure that causes a reboot. You don't want that to take 3 minutes in specific environments.
 
Boot times in theory are noise when a system is up for 365 days.
Boot times (or unsuspend times) for a laptop are critical for the user
Boot times for a desktop are inbetween.

One consideration for a server is any SLAs around what the server is providing. We all know about telco "5 nines" requirements, which is often handled by redundant systems/services. Boot times are important here because faster boot leads to faster recovery.

Faster boot times is also welcome when you are upgrading.

The mailing lists have good threads about rcd and it certainly is not systemd; it is more Solaris SMF.
 
recluce said:
Why are people so focused on boot times? The BIOS post of most of my servers takes well in excess of a minute, it just does not matter if FreeBSD then boots in 25 or 20 seconds. Also, unless there is a kernel upgrade, why reboot a FreeBSD server?

systemd was sold to people with the same fantasy, much faster boot times! We all know what a gong show that turned out to be. And now we want to do something similar on FreeBSD?
Click to expand...
Faster boot time has nothing to do with Systemd. OpenRC is faster.

rcd in FreeBSD is a welcome development.

Sometimes I feel like I'm in listening to third-worldist fake environmentalists preaching degrowth. There's nothing wrong with improving FreeBSD.
 
rbranco said:
rcd in FreeBSD is a welcome development.
Click to expand...
For the record - I quite like the idea of rcd. I had evaluated the possibilities of that myself a long time ago. What I seriously dislike is the inclusion of lua into anything that is that close to PID1 or is running as root if there is no absolutely relevant reason to do so and it can not be avoided at all.
rbranco said:
Sometimes I feel like I'm in listening to third-worldist fake environmentalists preaching degrowth. There's nothing wrong with improving FreeBSD.
Click to expand...
Sometimes making things smaller and simpler is the improvement. I totally concur with Wirth about that. There is nothing good about unchecked growth, by the way.
 
You must log in or register to reply here.
Back
Top