What's happening to FreeBSD?

[hedwards]

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

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.

 

[recluce]

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.

 

[Espionage724]

Again, the boot post (BIOS/UEFI and add on hardware) for most servers I use takes up to several minutes

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

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?

 

[recluce]

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]

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

You realize that *you* may not but other users do use jails and may want other key features....

 

[Espionage724]

You realize that *you* may not but other users do use jails and may want other key features....

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

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

 

[cracauer@]

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.

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

 

[kirsche]

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

I second this. That's exactly what I said with:

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.

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.

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.

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.

 

[drhowarddrfine]

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.

You'll fit in just fine with most of us here. Age is never any indication of quality or value.