What would you like to see in FreeBSD

It's nice to see some developers reaching out in different areas and groups on how to improve FreeBSD. Would love to see more of this. :)
 
  • Thanks
Reactions: Oko
Thanks for bringing up to our attention. I just skimmed over it. Lots of low quality posts. I see lots of people requesting Linux stuff. If you need Linux than run Linux. I have my own list but I guess I would be wasting my time posting it here. I also don't plan on opening an account on reddit to post it.
 
the more people switch from Linux the better for all of us. Personally, I'd like to see up to date graphics stack, Nvidia blob makes me sad.
People from Linux is a good thing. However, I disagree on the other point. Too much work is being done on graphics. I would like to see text utilities expanded. It seems like most of that is old and not under current development - like an abandoned branch.
 
Although a valid question, I'm not convinced that the person that initiated the reddit thread is actualy a FreeBSD developer. When there are so many things to fix/implement and so many user requests on top of it, FreeBSD developers don't even have the time to ask that question (and browse through all answers), I assume.

But if I can throw in my 2 cent, fix & document what's already implemented.

Dominique <-- very slowly gaining FreeBSD-developer skills.
 
I honestly can't think of anything that FreeBSD doesn't excel at. Be it networking, storage, security, virtualization, whatever. The BSDs are responsible for a lot of innovation in those areas. However, I would like to see a cultural shift in how FreeBSD presents itself.

One person said this;

A stronger marketing effort to enlighten the masses as to why FreeBSD should be used in their enterprise.

I believe this would solve most of our "support" issues. ie. Man power/Driver support, etc. Hell, hire a community manager if we have to, or more social media, just do something! Also, the ports tree is way too damn big, we NEED more maintainers. It would solve that issue too.

Also, the entry for new developers seems kind of mute to me from what I've lurked. I would like the FreeBSD wiki to be re-designed into something like Mozillas Developer Network to entice and encourage potential new comers. You can just pick a sub-project (with a brief overview what it is/what needs to be done), get involved, meet developers, and start hacking on code. What it looks like now is just too bland IMO.

On the more technical side, I would like to see distributed computing capabilities with UFS/ZFS. A way to easily consolidate compute (ie. cloud-y stuff) would add more value to FreeBSD.

that's about it for me.
 
Also, the entry for new developers seems kind of mute to me from what I've lurked.

+1 for this. I've felt for a while that the BSD conferences could do with a newbies track that included topics like how to port an application, how to write a device driver, a deep dive into how the FreeBSD development process works, or setting up a FreeBSD development environment etc. If there was such a track I for one would be more likely to go. It's always worth investing in the next generation of developers.
 
One person said this;
My issue with that is what someone else on this board said. FreeBSD is like that quiet beach that no one knows about. As soon as someone finds out, it gets ruined by all the others who quickly come in and make a mess of things.
Also, the ports tree is way too damn big
That's the first I've ever heard anyone say that. The typical (Linux-er) complaint is that there aren't as many as Linux.

Attractiving quality developers is a good thing but I would hate to attract users just for popularity's sake. It's not a contest and especially not that kind of contest.
 
I'd like more of the same which we're enjoying now. Consistency, reliability with bug fixes, transparent channels and in general an OS we can rely on.

And I also hope that FreeBSD won't turn its back on older hardware as easily as Linux has done in the past. I'd miss my Athlon-XP 2k powered server, a whooping 1G memory and running with 2x IDE drives (gmirrored UFS partitions) and some other hardware I hardly use (including a SCSI ZIP drive ;)).

Although much slower than my more professional servers this in-house server never lets me down and helped me out a lot with common & fun tasks (it even runs a small, private, Minecraft server :)).
 
My issue with that is what someone else on this board said. FreeBSD is like that quiet beach that no one knows about. As soon as someone finds out, it gets ruined by all the others who quickly come in and make a mess of things.
That's the first I've ever heard anyone say that. The typical (Linux-er) complaint is that there aren't as many as Linux.

Attractiving quality developers is a good thing but I would hate to attract users just for popularity's sake. It's not a contest and especially not that kind of contest.

What I'm trying to say is that the size of the ports tree has outgrown its rate of maintainability. This is a common problem I hear all over the mailing lists.

When it comes to support, popularity does play its role in this situation here. The difference with FreeBSD is that we have a more controlled and rigorous process (through mentoring) for new comers earning commit bits; thus breeding quality developers. I'm sure the project doesn't just accept whoever on a whim. The more we can expose ourselves of this to the world and get people on board, the better. It's a win win.

All I'm saying is that FreeBSD can improve on its outreach, not mindlessly accepting a flux of people for just popularity sake.

Think of it as FreeBSD School - we make developers greater, not less mediocre.



(Yes, I just quoted Monsters University :p)
 
All I'm saying is that FreeBSD can improve on its outreach, not mindlessly accepting a flux of people for just popularity sake.

Think of it as FreeBSD School - we make developers greater, not less mediocre.
I'm agreeing with you on all counts.

A FreeBSD School! Now that sounds interesting.
 
I'd love to see applications that don't require us to rely on broken software like pulseaudio. Exactly the opposite that one commenter in reddit asked for. PulseAudio amounts to nothing but bloatware when we've got a working sound system that does exactly that.

Also I would love to see the whole "3 firewalls in base" issue resolved. I often go with IPFW, just because that is FreeBSD's native firewall, PF seems to be outdated (at least with regards to the OpenBSD codebase),and I have no idea if IPFilter is any good. We should, ideally, have only one firewall in base. Or at the very least two (IPFW and PF), but only if both are equally valid options with their own tradeoffs.
 
  • Thanks
Reactions: Oko
I'd love to see applications that don't require us to rely on broken software like pulseaudio. Exactly the opposite that one commenter in reddit asked for. PulseAudio amounts to nothing but bloatware when we've got a working sound system that does exactly that.

You can blame GNU/Red Hat for that. The open source world is mostly GTK.
 
It is apparently difficult to separate out the firewall code, which is why the firewalls are not in ports. That would be the ideal solution, I'd say.

The FreeBSD PF does not have the latest features of the OpenBSD one. On the other hand, the FreeBSD PF supports SMP, which the OpenBSD version does not. There is a new third version of PF which is probably different from both (Sun/Oracle? Can't recall.).

IPF nearly went away, but was saved at the last moment because it is apparently very similar to what some commercial equipment uses (Juniper?).

IPFW is slightly faster than PF. PF is, to me, much easier to use, so I use it.
 
It is apparently difficult to separate out the firewall code, which is why the firewalls are not in ports. That would be the ideal solution, I'd say.

The FreeBSD PF does not have the latest features of the OpenBSD one. On the other hand, the FreeBSD PF supports SMP, which the OpenBSD version does not. There is a new third version of PF which is probably different from both (Sun/Oracle? Can't recall.).

IPF nearly went away, but was saved at the last moment because it is apparently very similar to what some commercial equipment uses (Juniper?).

IPFW is slightly faster than PF. PF is, to me, much easier to use, so I use it.
Not true. Solaris is using up to date vanilla version of PF just as OS X. So much about that FreeBSD BS that PF can't be updated. OpenBSD is getting SMP capable and optimized Network and PF capable of speeds up to 50 Gigabits Between FreeBSD SMP capable PF was four times slower than vanilla PF as PF can hardly benefit from SMP due to its nature.. If you need 100 Gigabits you really should be Cisco or Juniper customer. Juno OS is customized Proprietary FreeBSD. I personally like the fact that IPFW is getting lots of love. Diversity is good. IPF is a dead horse as Solaris adoption of PF demonstrates. Note that IPF was a native firewall of Solaris. Between Solaris dropped its own fork of OpenSSH in favour of vanilla version.

FreeBSD will benefit IMHO from reducing number of firewalls. I would keep IPFW in the base and maybe have up to date PF in ports if technically possible Personally I use PF on FreeBSD as I am familiar with it. My FreeBSD machines could run without firewall as they are protected by OpenBSD.
 
AFAIK PF in OS X was imported directly from FreeBSD, not OpenBSD. I've seen a few PF questions on Stack Exchange not long ago that mentioned the PF syntax in OS X is pre-OpenBSD 4.7 which would lend credence to that. Of course that could have changed recently and I wouldn't know as I don't use OS X.

From what I understand the problem with bringing FreeBSD's PF in sync with OpenBSD is OpenBSD's PF is not vnet(9) compatible. There was some talk recently about this being looked at on one of the mailing lists but I can't find a link it right now.
 
AFAIK PF in OS X was imported directly from FreeBSD, not OpenBSD. I've seen a few PF questions on Stack Exchange not long ago that mentioned the PF syntax in OS X is pre-OpenBSD 4.7 which would lend credence to that. Of course that could have changed recently and I wouldn't know as I don't use OS X.
I will take your word for it but I would swear the last time I was using OS X (my daughters have a laptop running OS X) the version of PF was newer. By the way OS X used IPFW before switching to PF couple of years ago.
From what I understand the problem with bringing FreeBSD's PF in sync with OpenBSD is OpenBSD's PF is not vnet(9) compatible. There was some talk recently about this being looked at on one of the mailing lists but I can't find a link it right now.
If that is the case PF should be pruned sooner rather than latter. There is no point in having obsolete version of PF besides native IPFW. People who like PF like me will use OpenBSD anyway.

I didn't want to post here my list of things for FreeBSD but since we started the discussion here it comes. Enjoy :)

1. Remove Sendmail and replace it with DragonFly BSD mail agent (I am running such set up on my FreeBSD servers and I think the things are moving that way in the head). Take a clue of the whole situation with Bind vs Unboud+LDNS tools

2. For God's sake import OpenIKED into the base. It is despicable that FreeBSD has no decent IPSec support and the one in the ports is coming from Linux.

3. Base should contain basic DHCP server. Port OpenBSD version if you don't want to develop your own.

4. Remove PAM from the base and SSSD from the ports and write your own UNIX-like LDAP authorization frame work. If you don't like what OpenBSD guys did then check commercial UNIX-es but don't copy Linux crap (PAM and SSSD).

5. If you are going to support Kerberos (MIT or better Heimdal for licensing purposes) please clean the protocol and the code base as nobody will do it for you. OpenBSD guys have given up on Kerberos completely and removed it from the base. Nobody will be fixing Kerberos for you.

6. Replace OpenSSL with LibreSSL in the base and across the port tree whenever possible.

7. Import arc4random from OpenBSD.

8. I like the fact that developers are talking about better NTP daemon. Please do it. I would like to see an alternative to OpenNTPD (or NTP bloat-ware) This actually could be much higher on my list.

9. mandoc should be the only document formatting system allowed and mdoc should be only format allowed.

10. Clean BSNMP daemon. I like the fact that FreeBSD has its own version of SNMP daemon different than net-snmp or OpenBSD version.

11. Clean syslog code base and add TLS and few other modern features.

12. Finish off native sensoring framework and get rid of infamous IPMI

13. Xen is good. Bring the Dom0 support in par with Debian.

14. Stabilize DTrace in the user-land. It is starting to suck.

15. Clean nvi in the base. Check what OpenBSD guys are doing.

16. Fix mailx in the base check what NetBSD guys have done.

17. Create native BSD tool chain. Adopt portable C compiler as your own PPC.

18. Port the video drivers from DragonFly BSD so that people can actually use FreeBSD as a desktop OS.

19. Porting HAMMER 2 should not be as hard as HAMMER 1.

20. Remove Linux emulation crap. People who need Linux should use Linux.

21. Port Truecrypt DragonFly implementation to FreeBSD.

22. Bring vkernel from DragonFly. That thing is cool.

23. Finish off RAID 5 and add RAID 6 software RAID implementation. If HAMMER 2 is ported it will be needed. HAMMER 2 is a file system not a volume manager. Some people need to use UFS and RAID 6 is still useful to them too.

24. Add IPP protocol to the native LPD daemon. Clean that ancient code. All BSDs would benefit from it.

25. Bring GlusterFS to the level of the fist class citizen.

26. Talk to vendors and try to bring native MATLAB and Mathematica to FreeBSD. Talk to Oracle. Get proprietary JAVA and Oracle database support. It is very important for enterprise users.

27. Make sure that your own developers run FreeBSD on the desktops.


I probably left bunch of useful stuff but this is how my list would look like.
 
1. Remove Sandmail and replace it with Dragon Fly BSD mail agent (I am running such set up on my FreeBSD servers and I think the things are moving that way in the head). Take a clue of the whole situation with Bind vs Unboud+LDNS tools
https://lists.freebsd.org/pipermail/freebsd-current/2014-February/048470.html

3. Base should contain basic DHCP server. Port OpenBSD version if you don't want to develop your own.
It's debatable whether a DHCP server is necessary in the base system. The typical answer: One can choose his own with pkg install my_favourite_dhcpd.

6. Replace OpenSSL with LibreSSL in the base and across the port three whenever possible.
https://wiki.freebsd.org/LibreSSL#Using_LibreSSL_with_base.2Fworld

8. I like the fact that developers are talking about better NTP daemon than Please do it. [/SIZE]I would like to see an alternative to OpenNTPD (or NTP bloat-ware) This actually could be much higher on my list.
https://github.com/bsdphk/Ntimed

11. Clean syslog code base and add TLS and few other modern features.
TLS support would be cool. Kudos to the OpenBSD developers.

17. Create native BSD tool chain. Adopt portable C compiler as your own PPC.
What's wrong with clang/LLVM?

18. Port the video drivers from DragonFly BSD so that people can actually use FreeBSD as a desktop OS.
Maybe we should kidnap François Tigeot, lock him up and only let him out when we we've caught up with DragonFly.
 
What's wrong with clang/LLVM?
The native BSD C compiler is PCC. GCC replaced PCC due to political reasons. That is one of the biggest blunders in BSD history.
LLVM doesn't work on legacy architectures which matter to OpenBSD and NetBSD and its driven by Apple needs. There is nothing that gets bugs faster out of the system than natively compiling code on Vax, or similar slow architectures. Unfortunately FreeBSD was always about i386 and alike.
 
So FreeBSD should just drop clang/LLVM that's backed by a huge community with strong momentum because legacy architecture support matters elsewhere? I'm not sure that's practical. We now have an open RISC ecosystem we can leverage (ARM). Once ARM is tier 1, nothing else (besides x86) would matter IMO.

Of course Apple has their own needs - they're a business, but at least they give out some of the quality low level software they use.
 
Back
Top