Call for Foundation-supported Project Ideas

… Getting the Linux layer into better shape would be equally compelling. For some of us using FreeBSD as a desktop, there are valuable apps missing.

+1 from me, however this is not to suggest that things are in poor shape.

Noted with thanks, completed in the first quarter of 2021:

{link removed}

… for some applications for Linux I simply can't be bothered …

When I last experimented, there was an unwanted consequence of linux_enable="NO".
 
Last edited:
That reminds me a few things. Completing Firefox Capsicum support would be a worthwhile project. Another usually ignored thing is incompatibility between C++ binaries compiled with Clang and GCC. The latter is decidedly not great and actually interferes with my CUDA library loading hack.
 
Another usually ignored thing is incompatibility between C++ binaries compiled with Clang and GCC. This is decidedly not great and actually interferes with my CUDA support hacks.
This is actually interesting... never occurred to me before. I did read about how the two projects are rather differently designed. Is there a good blog that you can point to that highlights the differences and incompatibilities between the two?
 
I am dying to use FreeBSD as my daily driver but for that I need a easy to use sandbox tool like firejail. Please create an equivalent of firejail for FreeBSD. Under Linux if you want to run Firefox inside firejail all you need to do is $firejail firefox. That's it.
https://forums.freebsd.org/threads/...-the-only-reason-i-moved-back-to-linux.83175/

https://firejail.wordpress.com/
The handbook offers a good section on jails. If you want, there's an 'ezjail' port, and a 'bastille' port. Both offer jail management, and you can run Firefox inside a jail that was managed by either tool.
 
THE ONLY thing I am missing is PCIe pass-through... Why can't I pass my INTEL habanero GPU, NEC Aurora GPU, NVIDIA A100 GPU and AMD Instinct GPU on different jails instead of an emulated environment like Bhyve or QEMU... Anyways not sure if it is a JAIL/EMULATION feature but something tells me it might need kernel edits.
 
Here's from the FreeBSD Journal magazine (Sep/Oct 2014) about UFS, how it's good for science related data storage on FreeBSD:
This makes it sound very good. I'm happy with it. The only issue is when my harddrive fails, though that's about the harddrive, and I have important data backed up. I use TMPFS for compiling and such.

I'd like to see a NeXtaw implementation (Xaw toolkit) that's ported to XCB. or even halfway to XCL. Then this be its own ecosystem that remains simple. A few BSD-like window managers ported to XCB or halfway to XCL. Edit - NeXtaw's last update is 20 years old. libXaw3dxft is the only modern Athena Widget toolkit that has Unicode and Freetype, thus internationalization support. This is a better target to port to XCB.

LibCanberra being forked or replaced for basic sounds. If forked, simply remove ALL graphical dependencies from it. Make dbus optional on it. Make it separate from Pango, which that can have graphical dependencies. Pango can be indicated by message from a LibCanberra install, or made optional, but not used as the default install. Pango would be the only exception for libCanberra options related to graphical dependencies.

Making Bonjour (net/mDNSResponder) or net/openmdns the default Zeroconf implementations. Allow Avahi as an option, but not be the default.

Improve the dependencies structure, where some options or versions aren't hardset. This is a little difficult to explain. Let's say, a port asks for a specific version of ImageMagick and many versions conflict with each other. Installing a port, makes an existing version of ImageMagick be removed, and replaced with another version or x11 variant.

Make this improved either through port messages, or have it so dependency requirements are met by a class that for example is of ImageMagick port. Back to a previously made point, let "Zeroconf" be the dependency, and this will be as a class. Allow it so the user can select whether they want Bonjour, openmdns or Avahi from make.conf. Also, make CUPS not be a hardwired dependency, let it be installed and queried for to the user by pkg install message. "Print" can also be a dependency class which includes CUPS as a choice.

Another example is how window managers and Xorg are kept separate, because of this, upgrading a window manager doesn't require all of Xorg to be reinstalled. There's often a chain reaction of dependency requirements that requires much to be rebuilt, including from the toolchains and other dependencies. In some case, use messages to tell that more dependencies are needed for a certain functionalities.

In short, dependency classes, where a dependency can be satisfied by a few varying specific options, along with package messages for dependency features.

Edit - package messages was referring to pkg-message that exists under many individual ports in the /usr/ports/ tree. This message shows when those ports are finished compiling, and can be shown using pkg info -D.
 
Last edited:
Also, make CUPS not be a hardwired dependency, let it be installed and quiered for to the user by pkg install message. "Print" can also be a dependency class which includes CUPS as a choice.

In short, dependency classes, where a dependency can be satisfied by a few varying specific options, along with package messages for dependency features.
This is why I stick with ports - in packages, deps are hard-wired.
 
THE ONLY thing I am missing is PCIe pass-through... Why can't I pass my INTEL habanero GPU, NEC Aurora GPU, NVIDIA A100 GPU and AMD Instinct GPU on different jails instead of an emulated environment like Bhyve or QEMU... Anyways not sure if it is a JAIL/EMULATION feature but something tells me it might need kernel edits.
Jail/Bhyve != emulation, unless we're talking about different architectures.
 
Jail/Bhyve != emulation, unless we're talking about different architectures.

VGA/GPU NOT supported with passthru unless I dive neck deep in the code to get it working with latest GPU drivers and other hacks. Believe me I am not the only one that is trying EMULATION section is full of people/gamers mostly trying GPU passthru for a while.... I don't care too much about gaming anymore but ML (Machine Learning) models is something I am working on would love this for that BUT game developers, digital twinning developers, AI professionals, Research Labs, Scientist in Physics, (_____INSERT_BLANK______) will need parallelization this will be the start.
 
This is why I stick with ports - in packages, deps are hard-wired.
I need to clarify. This is about ports. Packages are also dependent on that (besides the point). I'm referring to pkg-message that exists under many individual ports in the ports tree. The message shows when compiles are completed.

CUPS has been hardwired to a few ports as a dependency, at least the last time I checked.

Edit - when CUPS is selected for builds, it becomes ingrained or hardwired with those packages, including from the default repository. Let CUPS be modular, so it can be uninstalled and installed without uninstalling builds that were selected to depend on it.
 
I am dying to use FreeBSD as my daily driver but for that I need a easy to use sandbox tool like firejail. Please create an equivalent of firejail for FreeBSD. Under Linux if you want to run Firefox inside firejail all you need to do is $firejail firefox. That's it.
https://forums.freebsd.org/threads/...-the-only-reason-i-moved-back-to-linux.83175/

https://firejail.wordpress.com/
Firejail is a security disaster
And, yes, I'm aware that Firejail is both complex and setuid root. I think that's an inadvisable design, and a significant security risk.

Please let's not have the Foundation support any such nonsense.
 

? although it's already on the Foundation's Technology Roadmap, from which I assume (jrm@ please correct me if I'm wrong) that there's Foundation support; a funded development effort.



 
? although it's already on the Foundation's Technology Roadmap, from which I assume (Jose please correct me if I'm wrong) that there's Foundation support; a funded development effort.
Not sure why I'm expected to have any special knowledge of this. Am I get a rep for correcting people?
 
Something simple. To write mbr, partition & label gpt partitions i use linux. Formatting to ufs/zfs i do with freesd.
Linux feels smoother and streamlined , for this simple job.
Or in other words there is room for improvement on the freebsd "tooling".
 
There is a thread on the freebsd-hackers@freebsd.org mailing list seeking project ideas. If you have ideas about projects that the Foundation could support, please leave your feedback.
For the past week or two, I've been thinking about that: What would I personally want to be improved in FreeBSD? Unfortunately, this thread here was terribly disrupted by two topics (KDE and XFS). And the bigger problem is that in my use of FreeBSD (as a small home server, with PF, firewall/routing, DNS/DHCP/NTP server for internal uses, web server, and some monitoring/control software), it is nearly perfect. I really can't point at "make this one thing much better".

In general, it's not the foundation's main task to get ports under control. It develops FreeBSD, not Chromium, Python or KDE. That division of labor between base and ports is one of the things that keeps the FreeBSD ecosystem healthy.

What I ended up with is two areas where improvement would be helpful.

First, the 802.11 access point support (not client!). Today, you can configure Linux machines to be APs, and they supposedly work nearly perfectly for a single-node access point. I've tried this with both Open- and FreeBSD several years ago, and the AP driver stack just has too many bugs to be reliable, and I've switched back to using dedicated APs (first Apple, now TP). Since I have not tried again, it might be that FreeBSD today can do it perfectly, in which case please ignore this request.

Second:
Wifi and sound (over HDMI) for the Raspberry Pi 400 would be nice.
I would go further. It would be wonderful if FreeBSD worked "perfectly" on the Raspberry Pi series, with feature parity with "Raspbian" (yes, I know that OS has been since renamed, but the content stays the same, a Debian Linux distribution compiled for the Pi). That includes hardware support (WiFi, sound, HDMI, as eternal_noob said), but also things like GPIO flexibility without rebooting, without having to build DTS overlays, with full kernel support for typical RPi accessories (hats) such as i2c and 1wire. I know that many of these things can be done using FreeBSD, but there they are dastardly tricky and time-consuming, and on Raspbian, they are smooth and effortless. I've been very impressed with how well the RPi ecosystem works with Raspbian: You plug a random hat on, and things just work.

Now, doing this is a huge task. Two reasons: The universe of potential hardware accessories for the RPi is *HUGE*, so supporting all this requires a massive test and QA infrastructure. And getting "desktop" use of the Pi to work perfectly would also mean getting the DE port system under control, which (see above) should probably not be in this list of tasks. So this is a difficult request.
 
I would love to see an enhancement in jail(8) for including configuration files in /etc/jail.conf, so that one could split one's jail configuration files somewhere under /etc/jail.conf.d/*.conf or /usr/local/etc/jail.conf.d/*.conf.
My company has a product that manages multiple jails but the pain point is that after changing each jail /etc/jail.conf needs to be locked and regenerated. It would be much better to simply generate a config file per jail and then include them all in /etc/jail.conf:
Not sure if you had already run across this feature request (PR 233310, but there has been some progress on it: Add support for jail.d
I find this great! There is only one thing I don't like: jail dependencies are not possible. It works as if every conf file is independent from the rest and dependencies cannot be implemented.

Does anyone know how can jails can be dependent on each other?
As you got me reading jail(8) a bit more thoroughly, it should be noted that there is dependency support baked into jail.conf with the pseudo-parameter depend:

Rich (BB code):
depend Specify a jail (or jails) that this jail depends on. When
       this jail is to be created, any jail(s) it depends on must
       already exist.  If not, they will be created automatically,
       up to the completion of the last exec.poststart command,
       before any action will taken to create this jail. When jails
       are removed the opposite is true: this jail will be removed,
       up to the last exec.poststop command, before any jail(s)
       it depends on are stopped.
 
Back
Top