What's happening to FreeBSD?

Espionage724 said:

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

www.phoronix.com 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 :p
Click to expand...
How much added complexity is there? Granted you do have to have some sort of tracking of what depends upon what, but compared with the complexity that is ports and packages, or the work that went into making the system SMP safe without everything running under that giant lock, I'm not sure that it's that bad. They're presumably taking a similar tack with things not being safe to be run in parallel as a default and running in the same order they do now with things being allowed to change those when safe to do so.
 
Again, the boot post (BIOS/UEFI and add on hardware) for most servers I use takes up to several minutes. Once control is given to the OS boot loader, it takes seconds. It simply does not matter if that second boot phase takes 12, 20 or 30 seconds.

Also, I am using my servers not booting them ten times a day. ;)
 
recluce said:
Again, the boot post (BIOS/UEFI and add on hardware) for most servers I use takes up to several minutes
Click to expand...
I installed to clean disks from memstick in about 3 mins; not sure what server-grade hardware does, but that time almost sounds like more of an issue vs a benefit of a server vs a random desktop or Pi :p

If it's hardware diagnostics: I'm pretty confident hardware isn't failing between last-boot and the next, and I'd probably notice an issue sooner real-world on the next boot vs a lengthy headless delay I might get used to not checking.

I didn't imagine multi-minutes being tolerated, but is there something to look for when purchasing a server to determine POST times?
 
Hardware diagnostics, integration of UEFI blobs for certain hardware, hardware enumeration, etc. all takes time. For example, my storage server here needs to check 512 GB of memory, 45 hard drives and whatever else is in the system. That takes about two minutes from turning on the power until handover to the FreeBSD boot loader. Also, I noticed that server designs just don't pay much attention to boot post times. And really, this is not much of a problem - reboots happen once a month if you are diligent on updates, less often if not. If you need high availability, server layout should be clustered or have a hot standby anyhow.
 
bakul said:
You realize that *you* may not but other users do use jails and may want other key features....
Click to expand...
I'd be curious to hear a real-world example of someone using jails and FreeBSD now, and how integrating rc.d is a benefit to their stack. I like proof :D

Whatever exists now works for me, so anything newer I'd hope to work just as well. rc.d might be cool, and if it drops-in easy enough to just change a couple word around like rcctl reload nginx vs service nginx reload then cool. I've heard dances with Wayland for 8+ years though :p
 
recluce said:
Again, the boot post (BIOS/UEFI and add on hardware) for most servers I use takes up to several minutes. Once control is given to the OS boot loader, it takes seconds. It simply does not matter if that second boot phase takes 12, 20 or 30 seconds.

Also, I am using my servers not booting them ten times a day. ;)
Click to expand...

On VMs the phase to pass control to the FreeBSD bootloader can be as low as a second.

And if you are doing kernel debugging on VMs you might reboot very often as you panic the kernel, or use the ultimate debugging utility - debug printfs :)
 
mer said:
For your specific use case, sure.
But other use cases, boot time has more importance.

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 :)
Click to expand...
I second this. That's exactly what I said with:
kirsche said:
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.
Click to expand...
Development has to be efficient and effective. IMHO it is not efficient to solve an edge use case at all costs. Great, if someone prepares a solution in their spare time.
Beastie7 said:
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.
Click to expand...
Call me old-fashioned, but boot speed is the last thing on my mind when I discuss to develop something for a system. To me, the claim that the current boot process isn’t modern enough is like calling bits and bytes outdated simply because they’ve been around for a long time. - But of course I welcome any improvement to a system, provided it does not come at the expense of other system features. LUA adds complexity. Complexity is always undesirable.
 
kirsche said:
Call me old-fashioned, but boot speed is the last thing on my mind when I discuss to develop something for a system. To me, the claim that the current boot process isn’t modern enough is like calling bits and bytes outdated simply because they’ve been around for a long time.
Click to expand...
You'll fit in just fine with most of us here. Age is never any indication of quality or value.
 
kirsche said:
But of course I welcome any improvement to a system, provided it does not come at the expense of other system features. LUA adds complexity. Complexity is always undesirable.
Click to expand...
Nothing is being done at the expense of anything.

In open-source, most stuff gets done because someone wants to scratch an itch, and we're not in a position to tell developers what to do or don't.

This stuff is optional and is not being pushed by anyone on anyone.

And life goes on.
 
kirsche said:
Call me old-fashioned, but boot speed is the last thing on my mind when I discuss to develop something for a system.
Click to expand...

Then you can simply use ignore it and reap the benefits of the other features. Improved boot speed is just one feature.

kirsche said:
LUA adds complexity.
Click to expand...

No it doesn’t. It’s actually a good and simple scripting language. Much that it comes shipped in base.

kirsche said:
Complexity is always undesirable.
Click to expand...

rcd isn’t complex. It’s practically a natural successor to rc.d; much like SMF was so sysvinit.
 
kirsche said:
Complexity is always undesirable.
Click to expand...
Have you considered using Plan9? Far far simpler than FreeBSD. On the original pi I could compile the entire system in 4 minute (kernel 1 min, the rest 3 min, 1 of which was for ghostscript!). About 2.3 Million lines of code. The system booted almost instantly (faster than Linux -- about 10-20 seconds from power up). Good enough for writing code. But you don't get your comfort foods (browsers, fancy windowing systems, GUI games...). And that’s why most people won’t use simpler systems.
 
Espionage724 said:
I'd be curious to hear a real-world example of someone using jails and FreeBSD now, and how integrating rc.d is a benefit to their stack. I like proof :D

Whatever exists now works for me, so anything newer I'd hope to work just as well. rc.d might be cool, and if it drops-in easy enough to just change a couple word around like rcctl reload nginx vs service nginx reload then cool. I've heard dances with Wayland for 8+ years though :p
Click to expand...
Right now I"m using a jail as the host for my jellyfin install, and if I can get Nextcloud to play nice with my reverse proxy, that will go there as well. I've also used it for a few other things, although often times I just use it as a place to work out installing and configuring things before deciding whether they deserve to get their own hardware or not.

As far as the new RC goes, anything that makes it more efficient to get back into your system is something worth looking into.

Edit : I did get NextCloud working and now I'm working on getting Guacamole going as well. Super nice having 100% of the config contained to a couple directories and the jail.
 
Last edited:
mer said:
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.
Click to expand...

That's systemd. Not what FreeBSD is planning. With systemd they've been moving functions from the kernel into systemd. Sometimes this makes sense, i.e. TLS negotiation. Many times not. And, systemd has taken on a life of its own, like managing encrypted blobs which are in fact encrypted home directories: systemd-homedir. FreeBSD isn't interested in this kind of malfunction. We're interested in improving boot times and managing services like inetd manages its network services.

Systemd has become a monstrosity.

mer said:
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.
Click to expand...
That's what the new rc system will use. Text files. Not some secretive binary file or some undocumented or semi-documented location that is at risk of changing should some user choose to leverage it. We don't work that way.
 
drsnx60 said:
When rcd delivers parallel startup & shutdown of the daemons and networks the reboot time would shrink to some seconds.
Click to expand...

rcorder(8) has supported parallel service ordering for a good while, and I've been running my own system with a fixed version of this patch (\/\/\/) for couple of years, for the sake of curiosity.

⚙ D26484 /etc/rc: optionally turn on new 'rcorder -p' option to run rc scripts in parallel.

reviews.freebsd.org reviews.freebsd.org
(I don't know why a revised version of it hasn't been merged.)

While with the patch and a custom timed down kernel some seconds are shaved from the boot process, it is not that impressive. Boot speeds are not something I care about at all; now that FBSD has good S3 support, I reboot rarely, and with S4 on the way that's gonna be reduced even more.

A cold boot up, even without all these patches and mods, is under 30 seconds on my ancient hardware, that's what it takes to take a sip of tea and ponder about what I'm planning to do with this magic box, so its more that good enough for me 🧙‍♂️.
 
I've read up a tiny bit on rcd, and I wonder, with rc being shown to be capable of doing parallel startup with rcorder -pand good-old shell &(async)-[a]wait can't just the rest of the key features be implemented as
daemon(8) improvements? That looks to me like a much more simple and "non-invasive" task.
 
baaz said:
rcorder(8) has supported parallel service ordering for a good while, and I've been running my own system with a fixed version of this patch (\/\/\/) for couple of years, for the sake of curiosity.

⚙ D26484 /etc/rc: optionally turn on new 'rcorder -p' option to run rc scripts in parallel.

reviews.freebsd.org reviews.freebsd.org
(I don't know why a revised version of it hasn't been merged.)

While with the patch and a custom timed down kernel some seconds are shaved from the boot process, it is not that impressive. Boot speeds are not something I care about at all; now that FBSD has good S3 support, I reboot rarely, and with S4 on the way that's gonna be reduced even more.

A cold boot up, even without all these patches and mods, is under 30 seconds on my ancient hardware, that's what it takes to take a sip of tea and ponder about what I'm planning to do with this magic box, so its more that good enough for me 🧙‍♂️.
Click to expand...
I've tried it when something like it was first introduced in-tree, without issue.

But the benefit was limited. And deactivated by default just a while later it was once activated by default, even though (if I recall correctly) I've not seen any problems reported on Bugzilla nor MLs I've been subscribed at the moment (subscribing more currently, though).

Maybe some fatal or severe issues would be reported in any of MLs I've not subscribed (including committers-only, non-public ones).

In my humble opinion, to make this kind of pararrelizations most benefical, drivers in kernel would be needed to be bare minimal, as few as possible, and load as kmods by pararrelized devd (,devmatch and devfs).
This is because, as far as I've observed, what are taking time is:
  1. device detection and initializations
  2. time synchronization
  3. limited large (including what are called from it) rc.d scripts like clamd
 
You must log in or register to reply here.
Back
Top