What's happening to FreeBSD?

[kirsche]

freebsd-update is a bit redundant with pkgbase now.

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.

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....

??? I do not understand your point. BE solves all issues but you want to throw AI on ... which problem is left?

 

[rbranco]

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.

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:

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

 

[rbranco]

pkgbase was redundant with freebsd-update from start.

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.

 

[fahrenheit]

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:

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

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.

 

[bakul]

??? I do not understand your point. BE solves all issues but you want to throw AI on ... which problem is left?

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.

 

[Erichans]

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".

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.

 

[kirsche]

bakul Which problem is not solved by BEs what your tool tries to solve?

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.

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

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.

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.

 

[rbranco]

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.

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.

 

[recluce]

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?

 

[MG]

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?

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.

 

[Espionage724]

Why are people so focused on boot times?

Why should an OS boot slower than needed? I cold boot Linux in about 12 secs, and 3-5 secs Windows. FreeBSD takes like 40 secs if IPv6 is enabled

 

[mer]

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.

 

[rbranco]

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?

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.

 

[Crivens]

rcd in FreeBSD is a welcome development.

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.

Sometimes I feel like I'm in listening to third-worldist fake environmentalists preaching degrowth. There's nothing wrong with improving FreeBSD.

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.

 

[rbranco]

There is nothing good about unchecked growth, by the way.

I think most of us agree that pkgbase & rcd don't fit that criteria.

 

[Crivens]

I think most of us agree that pkgbase & rcd don't fit that criteria.

I think most of us agree what that means

 

[kirsche]

Why should an OS boot slower than needed? I cold boot Linux in about 12 secs, and 3-5 secs Windows. FreeBSD takes like 40 secs if IPv6 is enabled

Maybe you should compare the same hardware? FreeBSD boots faster as Windows on my system. And Debian Linux? Since systemd it boots slower as with old school init.

But get back to the question: How often do you reboot your system? I boot it once per day. It is obviously a waste of time to improve boot times while some can use the same amount of resources to fix bugs instead or add a new feature.

 

[cracauer@]

Boot delays on FreeBSD are usually either from sendmail or waiting for ntp to do the one-shot time set.

 

[Espionage724]

Maybe you should compare the same hardware? FreeBSD boots faster as Windows on my system. And Debian Linux? Since systemd it boots slower as with old school init.

But get back to the question: How often do you reboot your system? I boot it once per day. It is obviously a waste of time to improve boot times while some can use the same amount of resources to fix bugs instead or add a new feature.

It's same hardware, but it might be more 10s-30s of a boot delay from power button press to log-in prompt if I have IPv6 enabled with default SLAAC (I don't seemingly benefit from IPv6 and been disabling it on FreeBSD for a while to avoid that delay; IPv6 is more complex than I care to figure out for static ). Without IPv6 I think FreeBSD's about the same as tweaked Linux (dracut hostonly/omits/cat)

I have a RPi4 running 16.0-CURRENT now and it reboots in less than a minute. I reboot my server daily to avoid potential long-running issues (memory leaks; Windows PHP had a thing where so many connections would block it till restart; theoretically I like RAM being scrambled so it isn't relying purely on software ASLR). It also lets me catch new issues quickly: If a website isn't working after that reboot or update, I can track the commit or cause down to something within the last day

 

[mer]

But get back to the question: How often do you reboot your system? I boot it once per day. It is obviously a waste of time to improve boot times while some can use the same amount of resources to fix bugs instead or add a new feature.

For your specific use case, sure.
But other use cases, boot time has more importance.
I upgrade my system, the faster the reboot the quicker I can validate the upgrade was successful.
If you run servers that have contractually obligated uptime requirements, the faster you reboot the less you run afoul of a contract with monetary penalties.
That also feeds into redundancy: containers/VMs are a good way to provide this but sometimes you have hardware. I have a redundant pair of systems providing service A. Primary fails, secondary takes over. I need the primary to come back up (fixed) as soon as possible so boot time affects that.

So yeah, a system that is booted and stays running 24/7 and reboots once or twice a year for updates, boot times are noise. 365/2*24hrs/day*60mins/hr*60secs/min boot time of 120 sec vs 60 sec is statiscally "almost irrelevant".
But that may not be "the use case".

So again, rcd is not systemd, faster boottimes may affect only a small percentage, but "your use case" is not "every single use case".
I will take correctly booting 100% of the time over faster boottimes that is correct 98% of the time but I will also take faster if we can get to 100% correct

 

[cy@]

As far as i know its a new init system (i might be wrong). Just like openrc or systemd. cfr SMF Solaris.

Kind of. It's like Solaris SMF. It doesn't replace init. It manages services, just like SMF does. And IMO it will be easier to manage because the config files will be user editable, not squirreled away in some undocumented or semi-documented place like SMF or systemd. It will not become the kitchen sink that systemd (systemd, journald, homed, etc.) is.

 

[mer]

Kind of. It's like Solaris SMF. It doesn't replace init. It manages services, just like SMF does. And IMO it will be easier to manage because the config files will be user editable, not squirreled away in some undocumented or semi-documented place like SMF or systemd. It will not become the kitchen sink that systemd (systemd, journald, homed, etc.) is.

This is key for me. The current discussion around rcd it sounds like existing service files work, so things can migrate as they want.
One of the biggest problems I have with systemd is "system doesn't boot, some weird numeric code is thrown, oh the logs are binary so you have to use this other tool to retrieve an understand the logs" all of which means you need another system you can ask DuckDuckGo "wtf does this systemd message mean". systemd error messages are like Windows BSOD that provide zero to barely above zero useful information as to the root cause.

My opinion, logs related to system startup/init/service management should be plain text files that I can cat/grep/awk/sed on because those are basic tools every admin must know how to use.

 

[T-Aoki]

So again, rcd is not systemd, faster boottimes may affect only a small percentage, but "your use case" is not "every single use case".

Maybe who want fast startup would be users of notebooks that want suspend/resume, but at least some workarounds (i.e., some deinitialize on suspend and reinitialize on resume are needed).

For servers that have hardware RAID controllers, yes, fast boottime would be near zero percents compared with acutal running timespans, like machine epsilon. Measurable but ignorable if the logic is really sane and it doesn't cumulative. For these use-cases, reliabilities / dependabilities that cannot imagine how to make boots failing should be far more important. Always starts up in same startup time to be announced for users are far more important.

 

[Beastie7]

Not only will it improve boot times for scaled infrastructure or the “cloud” (where boot times actually matter), but also embedded devices (IoT, mobile, kiosks, consoles, appliances, etc). For todays market, FreeBSD having its own modern service manager is long overdue. I actually think rcd could attract more developers to base their projects/products on FreeBSD. Nothing else like SMF exists that isn’t completely screwed up and/or permissively licensed.

 

[Espionage724]

...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.

Libinput Hit By Worrying Security Issues With Its Lua Plug-In System - Phoronix

www.phoronix.com

---

I like the idea of faster boot times, but don't like added complexity. Reading the key features, I haven't needed or knowingly need any of that. I haven't used jails and don't particularly need native integration built-in for it (implies bulk). I guess the features might be useful for certain use-cases, but I've gotten by no-problem so far with service start/stop/restart/oneshot, some scripts, and cron