FreeBSD Developers Continue Work On Shortening Boot Time, Improving WiFi Driver Support

[phoronix]

Phoronix: FreeBSD Developers Continue Work On Shortening Boot Time, Improving WiFi Driver Support

FreeBSD a few days ago published its Q1'2022 status report highlighting all the advancements made by this open-source operating system project...

https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-Q1-2022-Status

[kylew77]

I find FreeBSD to be the best of both worlds between *BSD and Linux, you get working Linuxemulator and wine support, good hardware support, and some security, especially some security through obscurity since it isn't as heavily used as Linux. Linux maintains it's higher hardware support and OpenBSD greater security but FreeBSD tries to strike a balance and is far and above the best "engineered" OS-- by that I mean that a team puts it together as a collective whole. Linux is piece meal distros with the kernel having Linus as its final say person and OpenBSD has Theo as its final say on everything. FreeBSD and NetBSD are team projects that build every part of the OS into a cohesive whole product. Debian is probably the closest Linux equivalent but is still built piece meal.

[Vorpal]

I'm in two minds about my reaction to the freebsd boot time thing:

• On one hand: "ouch my Arch Linux install boots to login manager in just 4 seconds from grub" (uefi takes way more time than all the other parts combined).
• On the other hand FreeBSD have way less manpower and resources than Linux, so it is completely understandable. Good job getting this far!

[kpedersen]

On the other hand FreeBSD have way less manpower and resources than Linux, so it is completely understandable. Good job getting this far!

To an extent; however if you discount the (often duplicated) work of distributions and focus on a specific area, i.e the init system; then systemd, openrc, runit, sysvinit individually doesn't have that much more developers working on it compared to the *one* used in FreeBSD. And then if you look at some proprietary ones like Apple; their launchd has even less developers.

FreeBSDs init system is generally slower because the design of it has been a balance between flexibility and performance. This balance is hard to strike but in some ways is only achievable by monolithic operating systems like FreeBSD compared to the distributed approach like Linux. Both have merits; Linux implements good ideas much faster; but at the cost of some bad ideas for some creeping in.

Myself? I don't quite get the point of boot speed. Servers rarely boot (and their ie. hardware boot routines often dwarf that of the OS) and laptops are generally suspended anyway. I am guessing people just don't like the 10 second vs 3 second wait from their desktop/workstation in the morning?

[Steffo]

What did they do in order to reduce the boot time? Have they something like systemd?

[kylew77]

What did they do in order to reduce the boot time? Have they something like systemd?

From the last quarterly update they cut out a lot of 1 second waits. SystemD requires cgroups and other Linuxisms so for better and worse isn't portable to FreeBSD as is.

[sinepgib]

From the last quarterly update they cut out a lot of 1 second waits. SystemD requires cgroups and other Linuxisms so for better and worse isn't portable to FreeBSD as is.

Note they asked about something like systemd, not systemd itself. The boot time improvements in particular require no linuxisms, they are just proper dependency handling, socket activation, asynchronous and parallel execution, all things that can be done in FreeBSD without complications. At some point someone tried to port launchd, that is pretty much systemd-like sans socket activation (I think), but IIRC that effort died off.

[dreich]

Myself? I don't quite get the point of boot speed. Servers rarely boot (and their ie. hardware boot routines often dwarf that of the OS) and laptops are generally suspended anyway. I am guessing people just don't like the 10 second vs 3 second wait from their desktop/workstation in the morning?

Nowadays, there are more use cases than just booting laptops and servers. With s6, my laptop boots to a TTY in ~2 seconds but that hardly justifies the effort. What does however are the thousands upon thousands of VM instances booting on hypervisors every minute for various applications which, for hyperscalers, results in a compound downtime amounting to wasted compute just waiting to boot.

[sinepgib]

Nowadays, there are more use cases than just booting laptops and servers. With s6, my laptop boots to a TTY in ~2 seconds but that hardly justifies the effort. What does however are the thousands upon thousands of VM instances booting on hypervisors every minute for various applications which, for hyperscalers, results in a compound downtime amounting to wasted compute just waiting to boot.

There's also slower hardware out there and suspension is not appropriate or desirable in all cases (not even taking into account that suspension is broken in many systems). In richer countries it might be the case that everything has plenty of RAM, powerful CPUs and SSDs, but in many peripheral countries that's not the case. So what boots in 2 seconds for you may very well be 30+ seconds around here, possibly even minutes. From anecdotal evidence (i.e. seeing what people in my environment uses) I'd say the average age of a laptop in my country is probably about 6 years, and most of it wasn't even high end when it was new. Not that they use FreeBSD anyway, of course, they mostly suffer through Windows' absurdly long boot times (it's common to wait ~5 minutes for the computer to become usable).

[kpedersen]

What does however are the thousands upon thousands of VM instances booting on hypervisors every minute for various applications which, for hyperscalers, results in a compound downtime amounting to wasted compute just waiting to boot.

That is fair. In some ways containers rather than full blown VMs being fired up on an existing machine could offset that problem for many use-cases.

That said, I do feel a typical server / desktop init system such as sysv / systemd will never be perfectly suited for this and as such a more bespoke solution will be needed for hyperscalers anyway.

Ironically Alpine and OpenRC is often commonly used on these systems needing regular spinups and that system doesn't particularly have speed in mind.