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
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.
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.
I will accept this for a better future.
