What would you like to see over the next few FreeBSD versions?

I’ve been reading some analyses comparing FreeBSD ULE and Linux’s CFS, and it makes me wonder whether FreeBSD should eventually move toward a new generation of schedulers. ULE is simple and can be very effective under certain workloads, but it also has some weaknesses.
I've had sound stutter randomly with high CPU (default mixer), so desktop-side tuning might benefit. Overall performance is seemingly better though and I'd rather keep that.

Have a set of guidance modules which direct the scheduler which threads shall have affinity to what core, and provide modules which base these decisions on things like instructions executed, type of instructions, cache misses, ... Modern CPUs count these anyway. So maybe make it have all the cache trashers on one partition of cores and the well-behaved on another, so they don't stomp on each other feet.
Looking into that stuff back with Windows 1809 and Ryzen scheduling (it got "improved" 1903+) was the reason I disabled SMT/HT to avoid gambles with how that stuff is prioritized :p I'd rather not guess if L2 or L3 thrashing is happening under specific apps/games because of shared cache with SMT or something, and like the idea of a real core just having what it natively has hardware-side.
 
zsh: /usr/local/bin/zsh

And why not? /bin/zsh ?

another.gif


#! /usr/bin/env zsh
 
For security/doas to go into base system, with option of disabling it.
If it weren't for POLA, I would love getting rid of sudo and replacing it with doas. But before we do that, let's get the kernel support for doas ready, so it remembers recent authentication.

The problem is POLA: So many people and so many scripts rely on sudo. It would take a decade of deprecating and warning people that sudo is going away. Similar to sendmail, which took many years to be removed.
Never mind, see Espionage and T-Aoki messages below: sudo is a port. People should just stop using it and switch to doas.
su, on the other hand, is in base. My fault.

For there to be an option to fall back onto sh(8) through chsh [chpass(1)] if a chosen shell for a user in ports like shells/pdksh, shells/osk or shells/mksh isn't installed from ports, which can temporarily happen during system upgrades or during single user mode.
Disagree. I'm an example: So many of my initialization files and workflows are built around a specific shell being available (in my case bash) that logging in with a different shell when bash is not available is not helpful. If bash is broken, the right answer on my system is to log in as root, and fix the system.

Send two of the three firewalls to ports.
That means making them fundamentally unmaintained, and they would probably rot away relatively soon. That seems to be more and more the fate of ports. The underlying question here is: How do most/many FreeBSD users manage their firewall? If they use a stock config, which they just enable (for example on a single-user laptop) without editing its configuration, they would be well served by that stock config just migrating to the "one surviving" firewall. On the other hand, if they hand-configure their firewall to an interesting network configuration, common for server installs or dedicated firewall machines, they would need to port to the "one surviving" firewall.

So in a nutshell, this proposal comes down to "support desktop users better, at the expense of dropping server users". Which seems to be the overall trend of FreeBSD right now.
 
The problem is POLA: So many people and so many scripts rely on sudo. It would take a decade of deprecating and warning people that sudo is going away. Similar to sendmail, which took many years to be removed.
When I started with FreeBSD 14.1, I saw sudo not default-included and figured early-on it'd be better not to rely on that :p

Managed to come up with something like su - root -c 'service cupsd onestart' for a few commands, but I usually just su -
 
I would like freeBSD to detect hardware thoroughly, determine the hardware compatibility for the kernel+ o/s version, check for mismatches between the kernel and o/s and packages, mismatches between the dependencies/packages installed from the ports tree and from pkg update (yes, ports tree is not to be mixed with packages from pkg update, but sometimes packages like drm515kmod is recommended from the ports tree); I would like freeBSD to automatically warn if a user chooses stable or current, automatically warn if the user fetches from a ports tree that is different from his environment, all this in full or in part while Installing, updating and upgrading.
 
I would like freeBSD to detect hardware thoroughly
I installed 14.3 on a Dell Latitude 5591 and during install it presented firmware install options for the GPU (kabylake) and both an Intel 9560 AC and AX210 cards. I thought it presented it nicely and was impressed! (iirc it wasn't on 14.1 where I started but came new with 14.2). fwget could go a step further and uninstall unnecessary firmware, but that might be tricky (I installed with 9560 first and its firmware pkg, then swapped it to AX210; fwget got the AX210 firmware but kept the unnecessary 9000 firmware around).

check for mismatches between the kernel and o/s and packages, mismatches between the dependencies/packages installed from the ports tree and from pkg update (yes, ports tree is not to be mixed with packages from pkg update, but sometimes packages like drm515kmod is recommended from the ports tree)

I had the fun of kmods with 14.1 to 14.2, seeing the new kmods-latest repo created; but in that short time now with 14.3 neither of that is as-complex as it was 14.1! (I think kmods-latest is default-added, and drm-61-kmod seems built up-to-date quick now or provided by that repo by-default)
 
Send two of the three firewalls to ports.
That means making them fundamentally unmaintained, and they would probably rot away relatively soon. That seems to be more and more the fate of ports. The underlying question here is: How do most/many FreeBSD users manage their firewall?
I used to question IPF (IPFilter) being in base, but that's because the documentation from a book about its configuration seemed wrong, and the similar names were confusing. It got confusing sorting out the 3 different firewalls: PF, IPF, IPFW. It seemed doubtful that the book was wrong, but I think that was the case. If I were to edit the book, the filenames for configuration of IPF would seem correct. With two widely used firewalls, the author may have just thrown IPF in there without checking it or fully understanding it. BSD Toolbox was a great book, but the author came from jumping from a Linux environment which it seemed so with a focus on tools like Bash. Also, there were Linux variant releases of the book: Linux Toolbox. Other parts of the book were BSD related. I'd like to see a re-release with the addition of an author with a focus on ksh, oksh, mksh, zsh and sh, and with more shell tools. More attention and correctness to IPF as well.

Setting up OpenBSD's PF took a lot of learning and studying, so I lost my saved PF configuration file a long time ago. OpenBSD's PF needed the Book of PF and online documentation for me. I may have had it right, but I worried whether I may have blocked too much with PF. It has a good, but complex structure where all parts are needed. That fits a purpose. One thing about PF, is that there was a setting with stateful which easily dropped packets.

I recently found IPFilter useful. I'd use a canned configuration from FreeBSD's IPFW (FIREWALL). When I have a canned IPFW setting already with a few bypass rules, and when I need an immediate block of a port, use IPF. Done. I believe the rules for IPF and IPFW go in a different order, though, just keep that in mind. Either way, I now use IPF (IPFilter) as a convenient extension to IPFW (FIREWALL).

I may use 3 firewalls together one day.

It's true, when something goes to ports, it doesn't get the support that it does in base. I thought there should be an extended base, which gets more attention than ports and is done structurally correct correctly. What I wished PkgBase to be, to keep the main install small.

A good sound system Linux would steal.
We already have that. Sort of with Sndiod from OpenBSD and OSS. Maybe it's not as complete.

So many of my initialization files and workflows are built around a specific shell being available (in my case bash) that logging in with a different shell when bash is not available is not helpful.
That's why it would be optional. I didn't foresee so many using Bash in initialization scripts. Shouldn't initialization scripts be in what's native to FreeBSD?

If it weren't for POLA, I would love getting rid of sudo and replacing it with doas. But before we do that, let's get the kernel support for doas ready, so it remembers recent authentication.

The problem is POLA: So many people and so many scripts rely on sudo. It would take a decade of deprecating and warning people that sudo is going away. Similar to sendmail, which took many years to be removed.
It's worth doing. The only question is, would it be be more secure to install doas from ports simply by making them do that extra step, or if it doesn't matter. If that's the case, that would be luck, and real security measures are more important. Someone harming your computer who has physical access wouldn't bother upgrading our system for us.

I would like freeBSD to detect hardware thoroughly, determine the hardware compatibility for the kernel+ o/s version
That's NomadBSD.
check for mismatches between the kernel and o/s and packages, mismatches between the dependencies/packages installed from the ports tree and from pkg update (yes, ports tree is not to be mixed with packages from pkg update, but sometimes
packages like drm515kmod
We need better documentation for which kmod we're supposed to use, or a tool from ports which can tell us, but a lot of us don't want automatic configuration. Older, but still relatively new drm drivers keep being put in with newer drivers that recently arrived from STABLE for each FreeBSD release.
 
The problem is POLA: So many people and so many scripts rely on sudo.
It's NOT a POLA violation.
sudo was never in base until I've started using FreeBSD (on 2.x era!) and always needed to install it via ports/packages.

Whether or not doas is incorporated into base, sudu can be installed via ports/pkg as always, unless it is removed from ports.
 
I may use 3 firewalls together one day.
I have been using PF and IPFW together many years already. Do not think any of these should be moved to ports. What comes to IPF, personally, I have not been a user. But there are probably also dedicated users in the community. Strongly support to keep them all in base.
 
That's why it would be optional. I didn't foresee so many using Bash in initialization scripts. Shouldn't initialization scripts be in what's native to FreeBSD?
Sorry, when I said "initialization scripts", I means: my .bashrc and friends. If I were to log into my normal user accounts, and bash weren't available and substituted with sh, and my .bashrc and friends not executed, I wouldn't be able to get work done comfortably; I would just log in as root, and get bash back to work.
 
but a lot of us don't want automatic configuration.

How about BSD-Intelligent-Automatic-Interactive configuration, showing options such as automatic, -y configuration by configuration / -yes to all / -Interactive (interactive for all those who have expertise)?
 
I have been using PF and IPFW together many years already. Do not think any of these should be moved to ports. What comes to IPF, personally, I have not been a user. But there are probably also dedicated users in the community. Strongly support to keep them all in base.
I still use IPFW's canned preconfigured firewall. In rc.conf, I opened up more rules. I've used PF with that in the past, though it had a high learning curve. Now, I use IPFilter as an extension to IPFW to block off ports which immediately need to be.
when I said "initialization scripts", I means: my .bashrc and friends. If I were to log into my normal user accounts, and bash weren't available and substituted with sh, and my .bashrc and friends not executed, I wouldn't be able to get work done comfortably; I would just log in as root, and get bash back to work.
After upgrades, when Bash isn't there, shouldn't you fall back to sh, then immediately get Bash to work. Rescue or single user mode should run without needing Bash.
How about BSD-Intelligent-Automatic-Interactive configuration, showing options such as automatic, -y configuration by configuration / -yes to all / -Interactive (interactive for all those who have expertise)?
Maybe in ports as an option. Though, it should determine or suggest, otherwise, it becomes too Linuxy. Idk, maybe that could work.
 
On the other hand, if they hand-configure their firewall to an interesting network configuration, common for server installs or dedicated firewall machines, they would need to port to the "one surviving" firewall.
Yeah that's the point or the "what I would like to see". One firewall that does all the things. No split efforts.
 
After upgrades, when Bash isn't there, shouldn't you fall back to sh, then immediately get Bash to work. Rescue or single user mode should run without needing Bash.
Absolutely, that's why there are root-like accounts that use tcsh and sh.

Yeah that's the point or the "what I would like to see". One firewall that does all the things. No split efforts.
You are looking at it only from the effort of the FreeBSD core group. Think about the effort of all users who have custom firewalls: If FreeBSD dropped two of the three firewalls, they would need to either (a) translate their firewall configuration to the one surviving one, or (b) switch to an OS that offers the firewall they had been using, or a closely compatible one. For me, it would be pretty easy: my /etc/pf.conf is only ~100 lines long, and is (unfortunately) not tied into automated systems (like spam control or blacklisting). I could probably migrate to another firewall in an afternoon. For others, it might take several days.
 
Think about the effort of all users who have custom firewalls
No, I'm thinking about them, that's why it gets carted off to ports or a non-default option in pkgbase. If people care, it gets work on it. If they don't, the writing has been on the wall. In my optimal scenario, whatever one gets to stay gets all the features that the others had so you can write automatic translations.

This sort of thing happens all the time in ruder ways. There's no "set software and forget it."

The one I use is pf, but my wish is for simply one, not for pf to be the one. If I have to translate my pf rules... ok? 🤷‍♀️ I will accept this for a better future.
 
Never mind, see Espionage and T-Aoki messages below: sudo is a port. People should just stop using it and switch to doas.
su, on the other hand, is in base. My fault.
The lack of authentication persistence killed doas on Freebsd for me. I just use plain su now. I use doas on Openbsd.
 
I also tried using doas but like Jose the lack of persistence was a nuisance, so I went back to sudo. Alpine Linux has doas as a builtin and it works with persistence, though I'm sure they've modified the OpenBSD version. Don't forget that you can limit sudo by using /usr/local/etc/sudoers.d so I can give various powers to user scottro rather than wheel, for example. (You can do that just using the regular sudoers file too, of course).
 
I also tried using doas but like Jose the lack of persistence was a nuisance, so I went back to sudo. Alpine Linux has doas as a builtin and it works with persistence, though I'm sure they've modified the OpenBSD version. Don't forget that you can limit sudo by using /usr/local/etc/sudoers.d so I can give various powers to user scottro rather than wheel, for example. (You can do that just using the regular sudoers file too, of course).
I think that the lack of persistence helps me slow down instead of just firing commands off as root. I've found that even though having to put my password in every time is a pain, it's made me consider the effects of my actions more deeply than with sudo.
 
I think that the lack of persistence helps me slow down instead of just firing commands off as root. I've found that even though having to put my password in every time is a pain, it's made me consider the effects of my actions more deeply than with sudo.
you wouldn't like my sudo habits then

alias Z='sudo'
and (%sudo) ALL:NOPASSWD in the sudoers file.

Yeah, it's bitten me in the past, but nothing that could not be easily recovered from. I grew up on sudo and at BellLabs we had "csu" (controlled super-user) and "doas", where all oeprator operations were closely monitored and logged, but in my R&D world I need quick (you asked for it, you got it).
 
Finish removing remaining GNU parts in base system, replacing toolchain parts with LLVM and BSD components: https://wiki.freebsd.org/GPLinBase. bsddialog is completed for 15 CURRENT. diff3 is being imported from OpenBSD. bwn and gcov are all that's left for GPL in Base, according to that page. bwn is a kernel module for wireless hardware by Broadcom, which if not completed can move to ports in the meantime. gcov is a coverage implementation used with debugging for LLVM. That page may possibly be not up to date, as there's llvm-cov(1).
This may already be done by next release. As of 14.3:
uname -a; freebsd-version
Code:
FreeBSD s 14.3-RELEASE-p2 FreeBSD 14.3-RELEASE-p2 GENERIC amd64
14.3-RELEASE-p2
Under /usr/src/gnu/ and /usr/src/sys/gnu/, all that's left are directories related to: gcov, dialog, diff3 and bwn drivers. In past FreeBSD releases, gnu/ directories under src/ were full.
 
Back
Top