Call for Foundation-supported Project Ideas

jrm@ I'm just noting there are a lot of things already going on that people could be working on and pulling in new work removes them from that. Perhaps I'm being unfair because I'm including bugs and getting Chrome to work
 
  • an application container framework like Linux OCI (I refuse to name d..... since most people here do think about the company and the bloated daemon that comes with it and not about the concept behind), something simple and neat, like develop runj and potluck to a production ready solution; also maybe some further improvement on linuxulator so we can run Linux OCI containers. There are various nice projects out there e.g. https://akhramov.github.io/posts/2021-09-16-FreeBSD-OCI-jails.html - a hub/repository thing and a possibility to download/distribute those containers easily would be really really awesome.
  • fuse for unprivileged users in jail
  • security: more mitigations (like from HardenedBSD?; FreeBSD lacks some features that have been standard on other OSes for years), make veriexec production ready (+ docs)
  • update to smb protocal version 3.11 so we can mount windows shares from current proposed configurations!
  • performance improvements is always nice of course ;-)
  • bhyve: suspend/resume, also a shared storage solution to migrate VMs around hosts so one can update the kernel and reboot
  • improvement on HAST - for more than 2 nodes; maybe "steal" some ideas from the current Linux/DRBD versions, encrypted connection
  • ipfw: filter icmp not only on icmptype but also on icmpcode
  • ggate: encrypted connection
 
Beastie7, improving wireless support is something that the Foundation has funded and is still funding. https://freebsdfoundation.org/project/wifi-update-intel-drivers-and-802-11ac
Your other two suggestion are noted.

rootbert, all your ideas have been logged.

drhowarddrfine, I can't say much about Chrome, but www/chromium, is a challenging situation. Upstream has decided to stop accepting patches from Free- or OpenBSD, so the port now has over 1000 local patches. Matthias Wolf (krumel here, I think) has been putting in a tremendous amount of work to keep it usable. Everything is on the table though. The Foundation is listening and projects will be carefully chosen after a lot of discussion. There will still be gaps and those who will argue that different choices should have been made. There is just much more work than resources.
 
A few things:

1. I'd rather FreeBSD find a conventional FS to replace UFS2, either a from scratch or an implementation of a better one. 20 years ago, UFS2 wasn't terrible, but nowadays it's pretty ehhh at best.
2. Nouveau support.
3. Panfrost/Lima support for Mali graphics on ARM.
4. Switch focus for POWER projects to POWERel. If we had to lose Alpha support in 2008 for 7.x, we're well and truly past the point where dropping ancient POWER/PowerPC makes sense. I know some people are fans of obsolete Apple gadgets, but there's zero future for eb POWER as there's no vulkan, OpenGL 4+, most graphics drivers for newer stuff won't work, etc. If you have focus for POWER on POWERel, it's towards the future and will improve Talos/POWER8 and up support immensely and bring it closer to parity with Linux -- as it stands, when my blackbird is in my posession I can't justify running FreeBSD, or OpenBSD for that matter, on it. Probably gonna need to be Linux KVM which is annoying because there's no good support in the BSDs for POWERel.
 
jrm@ said:
I can't say much about Chrome, but www/chromium, is a challenging situation. Upstream has decided to stop accepting patches from Free- or OpenBSD, so the port now has over 1000 local patches.
Click to expand...
I would like to know more about this. Is there some resource you can refer me to (eg. a link) to learn what lead to this decision?
 
Yes I second that. Some python 27 shim is needed to get Seamonkey back into ports tree.
jmos has been doing an excellent job keeping an unofficial SeaMonkey build for us.

How about getting NanoBSD to create UEFI images. I hate so see such an excellent build tool rot on the vine.
 
drhowarddrfine said:
I have never heard anyone say that before.
Click to expand...
Because you've never benchmarked the filesystems?
When the abortion that is GNU/Linux's ext4 is beating your filesystem by a wide margin, you have a problem.

XFS would be fantastic, and I actually have looked into such a thing, but gods above it cannot be done by a single person so nobody give me some condescending "SEND A DIFF" comment.
 
I said it's pretty "ehh' at best. doesn't mean terrible.

The bones of it are good... ish. But the soft-updates system has failed. Soft-updates lost out to journaling and nowadays I/O performance from more modern filesystems is better. We don't need to force everyone who wants decent performance onto ZFS.

In particular, though, I can name three entrenched issues:

1. It's based on 1970s-era technology with all the same deficiencies and short-sighted aspects of it. UFS had a benefit years ago when all the BSDs were relatively speaking the same dialect. Nowadays, none of them really understand each other as each has gone in a different, incompatible direction. The 1970s were nearly 50 years ago, and documentation for the FS is not as good as some better ones.

2. XFS in particular is extremely well documented, enough that making an independent reimplementation of directory structure v2 era XFS is basically quite possible and then merging newer changes in shouldn't be terrible.

3. The amount of work to correctly document UFS2, get it speaking even the OpenBSD dialect (impossible mostly because OpenBSD's is a pure-soft updates version) and get it up to modern performance standards is more work than porting a new filesystem.

4. Even if you did all that it would lack many of the better aspects of say XFS, Reiser4 or other filesystems.
 
I think it would be appreciated not to go off-topic - especially in a thread like this.

jrm@ and his collegues are putting efforts into providing resources to improve the FreeBSD platform. What we're doing now is having a bitch-fight about something completely irrelevant/unrelated. Lets try to keep the signal-to-noise ratio high - at least in threads like this.
 
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:

Code: 
# /etc/jail.conf
some global options
# ...
include /etc/jail.conf.d/*.conf

Edit: I tried to patch "jail" to support include files but while editing the source I noticed that includes are already supported by the "jail" service.
If the respective jail names are added to /etc/rc.conf in jail_list, then the files with paths /etc/jail.conf.d/$jailname.conf can be used separately and get recognized by the jail service.
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?

In any case, one could add the jails in the correct order to jail_list in rc.conf and they will be executed in the proper order.
 
You must log in or register to reply here.
Back
Top