Closed What Would You Like to See FreeBSD Do Differently?

[BSD-Kitsune]

I thought it would be a fun and thought provoking topic to see what we would like FreeBSD to do differently.

I'll start with my list:

• Safer defaults - having a basic PF policy enabled, enforcing many of the sysctls/configurations that are optional in bsdinstall by default, etc.
• Focus on PF - first thing I'd do would be to nix the other firewalls from supported codebase - allow them to be community supported if the community chooses, but focus on PF, and perhaps work towards a PF codebase that could be considered portable between the BSDs, and Linux, if they so chose.
• Ship with X in base - as an optional component. I'd take the opportunity to switch from PAM to BSD Auth and adopt Xenocara as the X distribution.
  
• Eliminate unnecessary architectures. Namely, SPARC, PC-98, POWERPC(32) and maybe even i386. These would still be available if the community decided to support the efforts. I think this is only fair with the dropping of IA-64, completely uncalled for considering the cost of IA-64 hardware is about equal with SPARC and POWER of equal performance.
  
• Migrate entirely to LibreSSL.
• Adopt lld and other LLVM tools in lieu of GNU binutils whereever possible.

That's just me though - this is purely a thread to open this for discussion.

 

[Oko]

This is my list:

• Drop the politics and merge low level security enhancements like Address Space Layout Randomization (ASLR), mprotect hardening, Position Independent Executable (PIE) support, and PTrace hardening, from HardenBSD back to FreeBSD.
  
• Take further clue about security from what is happening in OpenBSD land (pledge, W^X, arc4random, and similar).
• Replace already OpenSSL with LibreSSL and forget about long term support. FreeBSD is not Red Had and should not follow the same ridiculous policies.
• Drop the PAM and take the clue from commercial UNIX-es if you don't like the simplicity of LDAP authorization from OpenBSD
• Do something about Kerberos in the base. Either adopt it as a project like OpenBSD did with LibreSSL or remove it since its code is a mess.
• Focus more on deleting and auditing the code rather than importing new features.
• Start shipping with much saner defaults.
• I am not sure how useful is NFSv4. It is definitely too much ado about nothing. I would have prefer that FreeBSD has focused on NFSv3 just like DragonFly people.
• Fix Unbound in the base. Come on. Emulating Linux defaults is typically a very bad idea.
• Replace Sendmail with DMA (DragonFly Mailer Agent) now!
• Audit the code and do lots of regression and quality testing.
• Either remove the code or finish things like native SNMP daemon (BSNMP) code.
• Drop the politics and finish native sensoring framework. Do not allow IMPI to run on generic kernel due to security issues.
• Fix the syslog daemon. Seriously. Take the clue what OpenBSD have done with its own syslog daemon.
• Move PF and IPFilter to ports or completely remove it. Keep IPFW in the base and enable it by default with sane defaults (obviously will not be able to be too restricitive). Once you move them to ports, synchronize PF and IPFilter with upstream or drop it completely. No pseudo forks please.
• Do something about queuing. ALTQ is dead and has never being enabled in the generic. It used to work better on OpenBSD which now has native queuing system. Lots of people use FreeBSD as a router OS. This is must.
• Installer needs to get some real attention in the area of unattended/automated installation. Seriously bsdinstall has to be fully scriptable and well documented. Even some in house testing with common orchestration software (Ansible, Puppet, Chef) would be nice.
• Import beadm into the base and make update aware of beadm (run snapshot before doing updates).
• Import some basic ZFS snapshot and replication utilities into the base and test it mercilessly. One should be able to schedule snapshots and replication (both full and incremental including deleting things on the target) with the tools from the base.
• Import one of the Jail management tools with ZFS integration into the base (seems that iocell is now a good candidate). Make sure that is fully scriptable and easy to use with some kind orchestration software like my favorite Ansible.
• Having build in hot migration/failover ZFS based jails would be really nice.
• Remove all softraid UFS disciplines from the base except 0, 1, and 10. Make sure system can be easily booted from raid 1.
• Improve UFS Journaling. Learn about WAPBL.
• Work with vendors of hardware RAID cards and make sure they work better than on Linux.
• Drop legacy platforms (FreeBSD was always focused on i386 anyway and not very portable). Focus on amd64, ARM (when it make sense, drop raspberry pi nonsense), and MIPS64 routing hardware.
• Check what DragonFly people have done. It mike make sense to bring some changes even if HAMMER1 is too difficult to port. Virtual Kernels would be nice to have.
• Adopt a significant project which is important to everyone like Portable C Compiler and native bin utils and write them. Be innovators like OpenBSD and DragonFly people. You are not widely used commercial system so there is nothing to be afraid of.
• Making sure that FreeBSD compiles with LLVM is cool but LLVM should not be in the base in particularly now after they change the license to non-free Apache2 license.
• Improve man pages. For starter move to mdoc format. Adopt the policy that lack of man pages is a bug. No code should be enabled in the generic installation without god mdoc man pages.
• Improve the quality of the Handbook. Focus on fewer important topics but make sure that things are updated for the releases.
• I would like to see shorter but evolutionary release cycles. Maybe not every six months like OpenBSD but something very predictable with very long testing period (4-5 month developing + 4-5 months fixing bugs and regressions).
• Support only the last two releases and update Handbook accordingly.
• Aggressively remove the obsolete software from the ports three and even remove current software if the ports are not properly maintained.
• Binary packages needs to be signed! Build them aggressively. It should be no reason for people to compile from the ports other than having custom configuration.
• Be the innovator. Yes ZFS is cool but it didn't originate from FreeBSD. Actually more cool stuff originated lately from 12 man DragonFly BSD project than from FreeBSD.
• Do something about the desktop. X was always clunky on FreeBSD comparing to OpenBSD Xenocara. Either focus on the minimal set of useful things or drop the damn thing all together.
• Get systemd fake interface for desktop applications before it is too late. Large parts of Linux desktop eco system will soon 100% depend on systemd. That thing will no longer run on FreeBSD.
• Adopt another important project like fixing LPD. That code begs for cleaning. Common. Apple has enough resources to maintain CUPS. We need FreeBSD guys to step up and remove legacy code from LPD and add minimal set of new features supported by current printers. Adding IPP would be one example.
• Focus on code correctness, quality control, stability, and security. Introduce new features conservatively but make sure there is always something in the pipe line which nobody else has.
• I am not sure about Bhyve and Xen Dom0. The FreeBSD was so late into the game that it might be too late. At least make sure that FreeBSD runs well as a guest on Xen (AWS). Just compare the size of Open and Free AWS builds and you will see what am I talking about.
• The last but not the least be more careful about importing code with problematic licenses (ZFS comes to mind). In retrospect it would have being much better if FreeBSD ported HAMMER1 and made ZFS only optional via kernel modules.

I probably left out quite a few things but this is a good start.

 

[BSD-Kitsune]

I'm going to comment on a few of these just because:

This is my list:

• Drop the politics and merge low level security enhancements like Address Space Layout Randomization (ASLR), mprotect hardening, Position Independent Executable (PIE) support, and PTrace hardening, from HardenBSD back to FreeBSD
  
• Replace already OpenSSL with LibreSSL and forget about long term support. FreeBSD is not Red Had and should not follow the same ridiculous policies.
• Drop the PAM and take the clue from commercial UNIX-es if you don't like the simplicity of LDAP authorization from OpenBSD
• Do something about Kerberos in the base. Either adopt it as a project like OpenBSD did with LibreSSL or remove it since its code is a mess.
• Focus more on deleting and auditing the code rather than importing new features.
• Start shipping with much saner defaults.
• I am not sure how useful is NFSv4. It is definitely too much ado about nothing. I would have prefer that FreeBSD has focused on NFSv3 just like DragonFly people.
• Fix Unbound in the base. Come on. Emulating Linux defaults is typically a very bad idea.
• Replace Sendmail with DMA (DragonFly Mailer Agent) now!
• Audit the code and do lots of regression and quality testing.
• Either remove the code or finish things like native SNMP daemon (BSNMP) code.
• Drop the politics and finish native sensoring framework. Do not allow IMPI to run on generic kernel due to security issues.
• Fix the syslog daemon. Seriously. Take the clue what OpenBSD have done with its own syslog daemon.

On these I can mostly agree. Ax Kerberos, PAM,OpenSSL and Sendmail. DMA is decent enough.

• Move PF and IPFilter to ports or completely remove it. Keep IPFW in the base and enable it by default with sane defaults (obviously will not be able to be too restricitive). Once you move them to ports, synchronize PF and IPFilter with upstream or drop it completely. No pseudo forks please.

I think we both agree maintaining three firewalls is insane. I like PF, so I'd rather see IPFW go the way of the dodo because it's a confusing mess and as bad, in the few times I've tried it, as Linux's IPTables. I especially don't get the scripting config file... like what the heck were they thinking.

• Remove all softraid UFS disciplines from the base except 0, 1, and 10. Make sure system can be easily booted from raid 1.
• Improve UFS Journaling. Learn about WAPBL.

How about we just port the NetBSD WAPBL/UFS implementation? That would even remove the problematic soft-updates, which I thought for a long damn time was a good idea until I realized how complex it really is. I'm aware that 'porting' from one BSD to another isn't easy, but it's better than writing it from scratch.

• Import beadm into the base and make update aware of beadm (run snapshot before doing updates).
• Import some basic ZFS snapshot and replication utilities into the base and test it mercilessly. One should be able to schedule snapshots and replication (both full and incremental including deleting things on the target) with the tools from the base.
• Import one of the Jail management tools with ZFS integration into the base (seems that iocell is now a good candidate). Make sure that is fully scriptable and easy to use with some kind orchestration software like my favorite Ansible.
• Having build in hot migration/failover ZFS based jails would be really nice.

I feel like the overreliance on ZFS as a killer feature is a little... risky. For one, ZFS is really a bloated FS, and while BTRFS is in development hell, and HAMMER2 is going to be "ready when it is ready" I'd, IMHO, quickly deprecate ZFS for HAMMER2 - and maybe work with the DFBSD team to ensure it's cross-compatibility. I'd like to see the BSDs work more closely together.

• Drop legacy platforms (FreeBSD was always focused on i386 anyway and not very portable). Focus on amd64, ARM (when it make sense, drop raspberry pi nonsense), and MIPS64 routing hardware.

I would focus on x64/amd64, ARM64 (The RPi isn't nonsense!), and POWER64el. MAYBE SPARC64 if there was significant interest. POWER is a great platform and with the way amd64 is going (un-nukable Management Engines, increasingly closed hardware) I'd like to spin up POWER64. Focusing on MIPS64 is hahaha because MIPS is a blobbed architecture with too many pitfalls from vendors to be worth it. MIPS was great in the IRIX days, don't get me wrong, but today? Shell of its former self.

• Adopt a significant project which is important to everyone like Portable C Compiler and native bin utils and write them. Be innovators like OpenBSD and DragonFly people. You are not widely used commercial system so there is nothing to be afraid of.

Agreed. LLVM is cool and all but it isn't a BSD project. We need a better long term solution if LLVM won't be the end all be all.

• Making sure that FreeBSD compiles with LLVM is cool but LLVM should not be in the base in particularly now after they change the license to non-free Apache2 license.
• Aggressively remove the obsolete software from the ports three and even remove current software if the ports are not properly maintained.
• Do something about the desktop. X was always clunky on FreeBSD comparing to OpenBSD Xenocara. Either focus on the minimal set of useful things or drop the damn thing all together.
• Get systemd fake interface for desktop applications before it is too late. Large parts of Linux desktop eco system will soon 100% depend on systemd. That thing will no longer run on FreeBSD.

First off, LLVM is not Apache2. http://releases.llvm.org/ It's a OSI approved license similar to the BSD.
On culling old ports - there's some software in ports one may term obsolete (no longer maintained) but it's relatively stable and I'd like to not get too hasty.
On the desktop, we simply need to stop reinventing the wheel. All of the BSDs should adopt the OpenBSD Xenocara in base, and we should, quid pro quo, in return help the rest of the BSD community by maintaining our own parts of the community for others to reap the benefits
On the desktop, I'm in disagreement. We should simply stop trying already to keep up with the desktops that require logind, networkd and other systemd components. Drop support for GNOME and KDE directly. We're never going to be able to stop the systemd train, so I say stop trying - we should roll our own, preferably without dbus and other Linuxisms. We already have Lumina, we should be able to make an i3-based DE, and bring the CDE (which is LGPL, not a huge deal since it's linkable) into ports. I've decided dbus isn't worth it so much that I even emulate the Windows port of Thunderbird under WINE since I can't stand running dbus.

 

[Oko]

I think we both agree maintaining three firewalls is insane. I like PF, so I'd rather see IPFW go the way of the dodo because it's a confusing mess and as bad, in the few times I've tried it, as Linux's IPTables. I especially don't get the scripting config file... like what the heck were they thinking.

IPFW is the native firewall of FreeBSD (IPTables is its bastardized child. IPTables is an ugly clone of IPFW). PF doesn't scale well to the speeds IPFW/FreeBSD supposedly can reach. I am not talking about 10 Gigabit networks. I am talking 100 Gigabit networks.

How about we just port the NetBSD WAPBL/UFS implementation? That would even remove the problematic soft-updates, which I thought for a long damn time was a good idea until I realized how complex it really is. I'm aware that 'porting' from one BSD to another isn't easy, but it's better than writing it from scratch.

Has long outstanding bugs from circa 2008. NetBSD people have done nothing on it since Wasabi systems went out of business and released WAPBL into the wild. BitRig guys have ported it from NetBSD and fixed many bugs. There was a fellow who made initial porting effort to vanilla OpenBSD but he disappeared from radars. FreeBSD has journaling enabled on UFS by default but WAPBL is really kick as for embedded devices where FreeBSD already has Nano build scripts.

I feel like the overreliance on ZFS as a killer feature is a little... risky. For one, ZFS is really a bloated FS, and while BTRFS is in development hell, and HAMMER2 is going to be "ready when it is ready" I'd, IMHO, quickly deprecate ZFS for HAMMER2 - and maybe work with the DFBSD team to ensure it's cross-compatibility. I'd like to see the BSDs work more closely together.

BTRFS is a vaporware and will never be finished. HAMMER2 might get finished one day but neither HAMMER1 nor HAMMER2 are competing with ZFS. ZFS is also a volume manager aka. software RAID. HAMMER1 and HAMMER2 are pure file systems which need Hardware RAID for redundancy and high availability. DragonFly has zero support from vendors.

I would focus on x64/amd64, ARM64 (The RPi isn't nonsense!), and POWER64el. MAYBE SPARC64 if there was significant interest. POWER is a great platform and with the way amd64 is going (un-nukable Management Engines, increasingly closed hardware) I'd like to spin up POWER64. Focusing on MIPS64 is hahaha because MIPS is a blobbed architecture with too many pitfalls from vendors to be worth it. MIPS was great in the IRIX days, don't get me wrong, but today? Shell of its former self.

RPI is pile of proprietary firmware. Sparc64 is dead and focusing now on it is pure necrophilia. MIPS64 has nothing to do with IRIX. It is the architecture commonly used on routers and switches. Have you heard of EdgeRouter Lite by Ubiquity Networks. that is what I am talking about.

First off, LLVM is not Apache2. http://releases.llvm.org/ It's a OSI approved license similar to the BSD.

LLVM is switching to non-free Apache 2.0 license. That is definite. You might be too young to remember Xfree86 and 386BSD but I do. And LLVM unfortunately will have to die before it is reborn free again.

Finally little food for thought for people who don't understand that commercial UNIX-es are still alive and well and that Linux and Windows are nor the only players in proprietary world. Also a clue for FreeBSD guys if they want to move things in really interesting direction.

Top500 supercomputers are huge clusters. Linux scales well on clusters. HPC clustered workloads run number crunching for loops on a same set of grid points, over and over again. Everything can be run in parallel in the cpu cache. No synching among cpus. Everything run independently on separate cpus. One cluster such as SGI UV3000, serves one scientist at a time, doing 24h calculations. These are scale-out servers. Linux scales excellent on scale-out servers.

Business workloads such as SAP, OLTP databases, etc communicate lots among cpus and synchronize a lot when serving thousands of users. All these thousands of users do different things simultaneously (pay roll, accounting, etc), so you can not cache the workload in a cpu cache. You need to go out to RAM all the time. Typically, RAM is maybe 100 ns or so. This corresponds to a 10 MHz cpu. You remember those? When you do business workloads (serving thousands of users) you scale up to 16 or 32-sockets tops. No more. Clusters are totally useless because when you synchronize among node to node on a network, performance drops much much much much more. You need to have all the cpus on the same bus, i.e. one single huge scale-up server.

SGI explains this well:

http://www.realworldtech.com/sgi-interview/6/

The largest scale-up server on the market is a 64-socket Fujitsu SPARC M10-4s, it has 64TB RAM and runs Solaris. The largest Linux scale-up server is the new HP Kraken which has 16 sockets. It is a redesigned Unix Integrity server which scaled up to 64-sockets when sporting Unix/RISC. Other than the HP Kraken, all the rest of the x86 servers are plain vanilla 1-8 sockets. And Linux scales awful on 8 sockets. Why? Because Linux kernel devs dont have access to 8 socket x86 servers. So how can Linux scale on 8-socket servers when no developer can optimize Linux for 8-sockets? Linux kernel devs have 1-2 sockets tops. And on 1-2 sockets Linux scales well. There is no way Oracle can sell large business servers or database servers, if Oracle switches to Linux. Only Unix and Mainframes have large scale-up servers, serving thousands of users.

 

[gofer_touch]

Interesting thread.

What about Bill Yuan's work on ipfw3 which is supposed to be a lockless firewall?

I agree concerning ZFS. Jordan Hubbard commented recently on this. ZFS isn't a distinguishing feature for FreeBSD anymore. A lot of the commits in the OpenZFS project are now coming from Linux developers.

 

[lme@]

To summarize your post, Oko: Import OpenBSD Kernel, Base and ideology.

 

[gofer_touch]

To summarize your post, Oko: Import OpenBSD Kernel, Base and ideology.

"Import OpenBSD Kernel, Base and ideology with the HAMMER filesystem".

There, fixed that one for you.

 

[ekingston]

I was going to post a reply with a bunch of quotes of things other people said that I disagree with. Then I realized these disagreements probably explain why we have what we have in FreeBSD. So, as per the original question, what I would like to see in FreeBSD base...

1. consistent up-to-date GPU support. Although this is very hard to do or we would probably already have it.
2. better WiFi support for both hardware and management (especially when running FreeBSD as an access point).

That's it. Sadly, I think the community is actually doing a good job with both and the problem stems from the manufacturers not supporting FreeBSD and to some extent open source in general.

 

[Phishfry]

FreeBSD is what we make of it. When i386 turns too old it will slip into Tier 2 status, just like those other platforms

 

[gpatrick]

This is my list:

• Drop the politics and merge low level security enhancements like Address Space Layout Randomization (ASLR), mprotect hardening, Position Independent Executable (PIE) support, and PTrace hardening, from HardenBSD back to FreeBSD.
  
• Take further clue about security from what is happening in OpenBSD land (pledge, W^X, arc4random, and similar).
• Replace already OpenSSL with LibreSSL and forget about long term support. FreeBSD is not Red Had and should not follow the same ridiculous policies.
• Drop the PAM and take the clue from commercial UNIX-es if you don't like the simplicity of LDAP authorization from OpenBSD
• Do something about Kerberos in the base. Either adopt it as a project like OpenBSD did with LibreSSL or remove it since its code is a mess.
• Focus more on deleting and auditing the code rather than importing new features.
• Start shipping with much saner defaults.
• I am not sure how useful is NFSv4. It is definitely too much ado about nothing. I would have prefer that FreeBSD has focused on NFSv3 just like DragonFly people.
• Fix Unbound in the base. Come on. Emulating Linux defaults is typically a very bad idea.
• Replace Sendmail with DMA (DragonFly Mailer Agent) now!
• Audit the code and do lots of regression and quality testing.
• Either remove the code or finish things like native SNMP daemon (BSNMP) code.
• Drop the politics and finish native sensoring framework. Do not allow IMPI to run on generic kernel due to security issues.
• Fix the syslog daemon. Seriously. Take the clue what OpenBSD have done with its own syslog daemon.
• Move PF and IPFilter to ports or completely remove it. Keep IPFW in the base and enable it by default with sane defaults (obviously will not be able to be too restricitive). Once you move them to ports, synchronize PF and IPFilter with upstream or drop it completely. No pseudo forks please.
• Do something about queuing. ALTQ is dead and has never being enabled in the generic. It used to work better on OpenBSD which now has native queuing system. Lots of people use FreeBSD as a router OS. This is must.
• Installer needs to get some real attention in the area of unattended/automated installation. Seriously bsdinstall has to be fully scriptable and well documented. Even some in house testing with common orchestration software (Ansible, Puppet, Chef) would be nice.
• Import beadm into the base and make update aware of beadm (run snapshot before doing updates).
• Import some basic ZFS snapshot and replication utilities into the base and test it mercilessly. One should be able to schedule snapshots and replication (both full and incremental including deleting things on the target) with the tools from the base.
• Import one of the Jail management tools with ZFS integration into the base (seems that iocell is now a good candidate). Make sure that is fully scriptable and easy to use with some kind orchestration software like my favorite Ansible.
• Having build in hot migration/failover ZFS based jails would be really nice.
• Remove all softraid UFS disciplines from the base except 0, 1, and 10. Make sure system can be easily booted from raid 1.
• Improve UFS Journaling. Learn about WAPBL.
• Work with vendors of hardware RAID cards and make sure they work better than on Linux.
• Drop legacy platforms (FreeBSD was always focused on i386 anyway and not very portable). Focus on amd64, ARM (when it make sense, drop raspberry pi nonsense), and MIPS64 routing hardware.
• Check what DragonFly people have done. It mike make sense to bring some changes even if HAMMER1 is too difficult to port. Virtual Kernels would be nice to have.
• Adopt a significant project which is important to everyone like Portable C Compiler and native bin utils and write them. Be innovators like OpenBSD and DragonFly people. You are not widely used commercial system so there is nothing to be afraid of.
• Making sure that FreeBSD compiles with LLVM is cool but LLVM should not be in the base in particularly now after they change the license to non-free Apache2 license.
• Improve man pages. For starter move to mdoc format. Adopt the policy that lack of man pages is a bug. No code should be enabled in the generic installation without god mdoc man pages.
• Improve the quality of the Handbook. Focus on fewer important topics but make sure that things are updated for the releases.
• I would like to see shorter but evolutionary release cycles. Maybe not every six months like OpenBSD but something very predictable with very long testing period (4-5 month developing + 4-5 months fixing bugs and regressions).
• Support only the last two releases and update Handbook accordingly.
• Aggressively remove the obsolete software from the ports three and even remove current software if the ports are not properly maintained.
• Binary packages needs to be signed! Build them aggressively. It should be no reason for people to compile from the ports other than having custom configuration.
• Be the innovator. Yes ZFS is cool but it didn't originate from FreeBSD. Actually more cool stuff originated lately from 12 man DragonFly BSD project than from FreeBSD.
• Do something about the desktop. X was always clunky on FreeBSD comparing to OpenBSD Xenocara. Either focus on the minimal set of useful things or drop the damn thing all together.
• Get systemd fake interface for desktop applications before it is too late. Large parts of Linux desktop eco system will soon 100% depend on systemd. That thing will no longer run on FreeBSD.
• Adopt another important project like fixing LPD. That code begs for cleaning. Common. Apple has enough resources to maintain CUPS. We need FreeBSD guys to step up and remove legacy code from LPD and add minimal set of new features supported by current printers. Adding IPP would be one example.
• Focus on code correctness, quality control, stability, and security. Introduce new features conservatively but make sure there is always something in the pipe line which nobody else has.
• I am not sure about Bhyve and Xen Dom0. The FreeBSD was so late into the game that it might be too late. At least make sure that FreeBSD runs well as a guest on Xen (AWS). Just compare the size of Open and Free AWS builds and you will see what am I talking about.
• The last but not the least be more careful about importing code with problematic licenses (ZFS comes to mind). In retrospect it would have being much better if FreeBSD ported HAMMER1 and made ZFS only optional via kernel modules.

I probably left out quite a few things but this is a good start.

In the end we'd have... OpenBSD.

 

[Oko]

To summarize your post, Oko: Import OpenBSD Kernel, Base and ideology.

Not really but you got mad before reading my post completely. There are lots of things on that list which are very FreeBSD specific and were OpenBSD is not even going. I could also summarize the current state of FreeBSD for you as well. Imported Solaris Kernel, ZFS, and pretend that Jails are more polished than Solaris zones also adopt Linux userland and ideology and most importantly have gazillions half backed sub projects which go nowhere, finally lets pretend that we are Red Hat and have millions of paid customers worldwide. Marry Christmas. Flame war if there was any for me is over. I probably should not have posted to this treat to begin with. That is exactly why we have four different BSDs as somebody already pointed in this thread.

 

[gpatrick]

That is exactly why we have four different BSDs as somebody already pointed in this thread.

Yes, but you always find a way to interject how something should be done because OpenBSD does it that way. OpenBSD does some things that are good, but it isn't perfect.

pretend that Jails are more polished than Solaris zones

I've worked on Solaris for 15 years and I can say that isn't true, but I've never heard anyone make that claim. But then Solaris was a commercial operating system developed by a company that had millions to invest (e.g., Solaris 10 cost $400 million to develop). That isn't available for any open source project.

I am not sure about Bhyve and Xen Dom0. The FreeBSD was so late into the game that it might be too late.

OpenBSD's new hypervisor is even later to the game. What was the point?

also adopt Linux userland and ideology and most importantly have gazillions half backed sub projects which go nowhere

See the point above about money. Plus, there are good and bad in any operating system and using what's good can make any operating system better. SmartOS isn't completely Solaris any longer, neither is it Linux, neither is it NetBSD, but it uses from all to create a usable hypervisor.

Flame war if there was any for me is over.

Then stop claiming NetBSD is dead or SPARC is dead until that is official from some source; if you hear a rumor or such, then it is valid to point it out, but not just off the top of your head with nothing to back the rhetoric.

 

[marino]

If you insist "Dead" has to be used literally, then you're right. One can, however, assert a project is practically dead or "dead project walking", etc, and support the position with facts. There's nothing unreasonable about that.

 

[gkontos]

Nothing

 

[Phishfry]

PF doesn't scale well to the speeds IPFW/FreeBSD supposedly can reach.

This chart shows some of that difference.

 

[BSD-Kitsune]

Oko, I'll address you first.

IPFW needs major work in the user friendliness department to win out over PF. Security over speed is something to be said for it.

As for NetBSD being dead, no, it is not. It is behind, it is lagging and languishing but this is not impossible to recover from. Porting the WAPBL implementation may not be perfect but it's better than writing from scratch.

ZFS I have issues with because it's bloated. HAMMER uses a reimplemented LVM which is fine, I prefer for FS and VM subsystems to be separate, although the HP UX VM is much better compared to LVM. Once HAMMER2 is ready I'd push ZFS to an optional component and out of base ASAP because it's a dead end technologically, we can never catch up to ORACLE and will never be compatible with Solaris's later spool except by a miracle.

I should remind you that MIPS is tier III and that imagine technologies is firmly in the Linux game..That train left long ago and ain't coming back. I say can it.

As for LLVM I did research. Your only viable alternative would be to swtich to the GPLv3 GCC. In lieu of that, I say go for forking LLVM's last non Apache license. PCC is nice but basic. Open64 is dead.

As for better graphics drivers, that's going to always be tough due to Linux's insistence on GPL for the kernel.

And as for that chart on IPFW, it is something to be said, but I think PF is ultimately a better design, and it could be better optimized anyways. When the time comes and I pull the trigger on forking FreeBSD scrapping IPFW and IPF are high on my list. Others include starting work on HAMMER support. But for now, I'm working on a project for a friend and getting paid decently enough to not justify diverting resources to a BSD fork.

Ultimately id like to see better cooperation between the BSDs and the sharing of code to be more open to decrease the workload. We can still specialize, for sure, but we need to drop politics and band together rather than fight and argue.

Ideally I'd have any fork of FreeBSD I would be heading or supporting definitely work on a BSD native build system, and borrow code from NetBSD, DFBSD and OpenBSD where possible while returning the favor by offering to port aspects of my fork back to their projects, namely the forked jails and BHYVE, as well as any other defining features they would like. A house divided cannot stand and I fear loss of NetBSD would be the beginning of the end for BSD.

And for the record commercial UNIX is dead. Super-UX is gone. Xinuos is moving back to BSD and Linux solutions. Oracle has been letting Solaris languish for years, HP-UX is on life support. That leaves AIX which is experiencing little growth. Beyond that you have a bunch of little guys who are slowly losing interest in UNIX for Linux. If you count MacOS as a UNIX then I guess but that has more in common with Linux than UNIX.

I stand by my conviction that we should stop playing catch up with Linux on the desktop and give GNOME, KDE and XFCE the bird if they want to force us to adopt linuxisms to continue running it.

 

[drhowarddrfine]

I stand by my conviction that we should stop playing catch up with Linux on the desktop and give GNOME, KDE and XFCE the bird if they want to force us to adopt linuxisms to continue running it.

I unequivocally agree and have said so for years.

There are so many things a motivated developer can do to make a name for themselves and banding with others to create or port software to FreeBSD would make their mark in this industry.

 

[BSD-Kitsune]

I unequivocally agree and have said so for years.

There are so many things a motivated developer can do to make a name for themselves and banding with others to create or port software to FreeBSD would make their mark in this industry.

I'm glad we can agree on something heh.

As far as porting to FreeBSD goes, nobody's gonna be rich from writing software for the BSDs, but it's a nice gesture and one I'm grateful for when people do it.

 

[ANOKNUSA]

I'm having a hard time thinking of things that aren't mostly just for my own interest or convenience. I guess there are a couple components to the base system I don't really understand. (rsh? Seriously?) I'd also agree with Oko that having sysutils/beadm in base is past-due. The installer and boot menu have been boot environment-friendly for a couple years, with no clear explanation as to why the installer creates its pools that way in the Handbook and no tool to create and manage them readily available on a new install.

 

[BSD-Kitsune]

Stuff like rsh/rcp/rlogin is in place for compatibility.

 

[sidetone]

• Move PF and IPFilter to ports or completely remove it. Keep IPFW in the base and enable it by default with sane defaults (obviously will not be able to be too restricitive). Once you move them to ports, synchronize PF and IPFilter with upstream or drop it completely. No pseudo forks please.

IPFilter definitely needs to go. IPFW should coexist with PF in the base system. I use both IPFW and PF together. IPFW with a canned firewall, and PF for a custom lock down of my system. I like redundancy.

• Adopt a significant project which is important to everyone like Portable C Compiler and native bin utils and write them. Be innovators like OpenBSD and DragonFly people. You are not widely used commercial system so there is nothing to be afraid of.
• Making sure that FreeBSD compiles with LLVM is cool but LLVM should not be in the base in particularly now after they change the license to non-free Apache2 license.

If LLVM is removed from the base system, hardly anything will compile out of the box. It will have to be installed as a package or compiled with Portable C compiler. It was a big deal when GCC was removed from the base system, which was an improvement, but it took time for everything to get up to speed. What's wrong with Apache 2 that is different from Apache 1 license? Is it that Apache 2, while not restrictive as GPL, requires derivatives to be licensed under Apache 2?

If Apache 2 code leaves the base system, so will other programs that can shift from Apache 1 to Apache 2 licensing. Maybe the exception can be made for compilers and programming languages.

Actually, it may be a good idea to move it from the base system, because it's redundant when a newer version of LLVM or CLANG is needed, to have to seek the port or package anyway. So long as PCC can compile it with ease, and it's prepped from the base system as the program pkg is.

• Improve man pages. For starter move to mdoc format. Adopt the policy that lack of man pages is a bug. No code should be enabled in the generic installation without god mdoc man pages.

Deeply layered XML can get a little difficult for users to keep track of opening and closing elements. However, that's fine, and in ways it is organized and offers quicker distribution and maintenance of docs. Overall, this is an improvement, and docs wouldn't require many layers of elements.

• Adopt another important project like fixing LPD. That code begs for cleaning. Common. Apple has enough resources to maintain CUPS. We need FreeBSD guys to step up and remove legacy code from LPD and add minimal set of new features supported by current printers. Adding IPP would be one example

As long as LPD or its fork retains compatibility with old and new printers. CUPS is good, but I'd like to be able to have the option of setting up any kind of printer from the command line too. For other projects, it's better to stay with modern hardware, as you mentioned such as 64 bit, and depreciate old hardware from video drivers. It would be good to reduce the amount of production releases to less than 2 for 32 bit hardware, and just keep the most basic features in those base releases for obsolete hardware. Or 32bit releases could just be dropped altogether then just hope someone else forks it.

Many other suggestions of yours were good. I don't know about those suggestions about adding ZFS related features, or maybe I'm just not familiar with it, or don't understand it (someone will probably yell at me for saying that, but I do know it is a good and reliable function, based on what everyone says). Maybe Hammer, for that kind of filesystem. A jail program in the base system is ideal, with whatever filesystem allows it.

 

[sidetone]

• Ship with X in base - as an optional component. I'd take the opportunity to switch from PAM to BSD Auth and adopt Xenocara as the X distribution.

...

• Adopt lld and other LLVM tools in lieu of GNU binutils whereever possible.

As long as it's optional, Xenocara sounds good. The only issue would be to select driver categories at time of install. Choices should just be down to Nvidia, Intel and ATI for modern graphics drivers, and for ancient hardware, VESA.

Replacing GNU tools, should be automatic consensus.

As for better graphics drivers, that's going to always be tough due to Linux's insistence on GPL for the kernel.

Many modern graphics drivers, especially for Radeon ATI, are already MIT, BSD, or ISC license compatible. It's just that Linux incorporated that code first. BSDs can either reverse engineer the compatible licensed driver from Linux, or just start from scratch importing the existing driver sourcecode. It is overdue for FreeBSD or Xorg to incorporate R series ATI and other modern graphic card drivers. It's not expected of anyone to do this, but eventually it will have to accept at least a few years recent modern graphics cards, or the OS will be left behind.

Old graphics drivers should be dropped and have VESA with possibly a compatible driver added to allow better video rendering.

 

[drhowarddrfine]

It's just that Linux incorporated that code first.

No. It's that the drivers were written for Linux first. FreeBSD and Xorg do not write drivers for modern graphics cards. It's up to the manufacturers to either supply those drivers to run on FreeBSD or some volunteer has to reverse engineer them. This is no fault of FreeBSD.

 

[sidetone]

I didn't blame FreeBSD or any other organization.

https://community.amd.com/thread/170233

Says the graphics stacks for Radeon are BSD licensed, but Mesa or some software isn't caught up.

 

[drhowarddrfine]

Being BSD licensed doesn't mean FreeBSD has anything to do with them.