Call for Foundation-supported Project Ideas

gotta sell the idea of FreeBSD a bit better than that. Otherwise, you just come across as a FreeBSD fanboi who doesn't care what others think, and just chants. 'FreeBSD is the greatest, FreeBSD is the greatest, FreeBSD is the greatest! Try it!'. Figure out what their difficulty is with getting stuff to run on Pi, and show them how FreeBSD does the same thing so much better. If you look at comments people make about what prompts them to move to FreeBSD from Linux - the reasons vary by the person.

Excuse me? I stated what their reasons were and their objections. I cannot be clearer, I would have thought. 🤔

(Though I never mentioned this, I suggested FreeBSD purely because he wanted to try headless computing where they installed putty on their laptops, connected to the PI via SSH and ran commands as a user; giving them concepts of multi-user systems etc).

Anyway, this is just two examples I have of coming up against established bias.
 
This is simply not going to happen. 'Pi founders all use Linux and originally did substantial work to get Linux working on it. A huge user community has coalesced around the 'Pi running Linux and for them FreeBSD doesn't buy anything -- its API is just like Linux but far fewer devices work with it.

Yes I realise this. It was never about the RPI foundation putting FreeBSD on their website. It was an example about established bias and how the foundation could align to an SBC/SOC and push it and get kids in schools using their OS.

I don't believe ARM is the chip to align to either. It's RISC-V.

It's another pie-in-the-sky musing requiring lots of money and is never going to happen. Enough from me.
 
Excuse me? I stated what their reasons were and their objections.
You did. I'd suggest that you re-read my post to find out what I said about that.
(Though I never mentioned this, I suggested FreeBSD purely because he wanted to try headless computing where they installed putty on their laptops, connected to the PI via SSH and ran commands as a user; giving them concepts of multi-user systems etc).
Why would Raspbian be unable to do that? If the whole class is having difficulty setting that up, or if Raspbian only accepted a specific version of the SSH server that has a Heartbleed bug, then yeah, you'd have a case for FreeBSD. 🤷‍♂️
 
I think the foundation should push hard to align itself with a SOC like Odroid or RPI to get it out into schools and spread the love and critical mass for freebsd and perhaps add another free OS to the psyche of future CEOs, CIOs, lecturers, teachers, managers etc.

You're onto something. Kind of like a Linaro-style project for FreeBSD. I think the concept of Jails fits perfectly embedded stuff since it's so lightweight.

I hope you're watching Foundation!
 
Edit: just remembered that Debian does have 'community repos' that are used by derivative projects like Ubuntu... and so does Arch. Haven't checked Slackware, but I imagine it's pretty 'hands off' on its package management. There are some ideas from the Linux world that FreeBSD can look at and see what might work in their case.
Slackware have slackbuilds. And actually, I wouldn't mind having something similar to zugaina for gentoo, since we can have OVERLAYS= for an unsupported extra port (in gentoo, you can use your own ports picked by hand from zugaina, but you're on your own if you do crap, I would accept this kind of risk in some scenarios).
 
You did. I'd suggest that you re-read my post to find out what I said about that.

Why would Raspbian be unable to do that? If the whole class is having difficulty setting that up, or if Raspbian only accepted a specific version of the SSH server that has a Heartbleed bug, then yeah, you'd have a case for FreeBSD. 🤷‍♂️
I never said raspbian would be unable to do it. The 'case' for FreeBSD was to expand their knowledge to other systems, especially those designed as servers... otherwise they would all just use windows 10.
 
I never said raspbian would be unable to do it. The 'case' for FreeBSD was to expand their knowledge to other systems, especially those designed as servers... otherwise they would all just use windows 10.
That is where the 'extra credit' idea comes in. Expanding the knowledge beyond what's 'officially available and supported'. But even in that case, gotta prepare a good discussion for the class, about how to mentally handle the idea that 'officially supported' fits the scenario of 'easy to maintain', but should not be a limiter. Some people treat 'officially supported' idea like it's the end to everything, and don't bother to venture beyond that. But the flip side of that is, 'officially supported' means it's relatively easy to support, and not get lost in the complex scenarios that can be difficult to debug and get right. There's a saying that too many cooks spoil the broth.
 
I thought of one thing. Porting IP balancing from Openbsd's CARP.

The last time I used Freebsd in a professional setting, I configured a set of outgoing gateways that would back each other up with CARP. Because Freebsd's CARP does not have a load-balancing option, I had to use stupid Ansible tricks to ensure that 1/n hosts used each gateway, where n is the number of gateways. This gets awkward very quickly when there are a large number of gateways, and requires constant maintenance. The Ansible script had to be re-run weekly to account for hosts being added to, and decommissioned from the running fleet.
 
From my perspective there are a few things I'd like see to happen...

1. Bringing up Pf to the level of features it has in OpenBSD.
2. Polishing Bhyve more, e.g. adding SPICE as remote protocol, and less picky in other things, e.g. location of EFI files
3. Making the Raspberry Pi 4 fully functional
4. Implementing a GUI installer - partitioning disks e.g. is easier understandable for most in graphics than in text form
5. Replacing Sendmail as default MTA with Postfix

These are my opinions only, and I will not discuss them here, since the topic is about "bring your ideas to the Foundation", not "defend your ideas before other users." Thanks.
 
I added a missing link, a table of contents, and links to the calls.

Should I merge these two sections?
  • Other Third-party Software Improvements
  • Other
– some of what's already under Other is third party software.
 
I added a missing link, a table of contents, and links to the calls.

Should I merge these two sections?
  • Other Third-party Software Improvements
  • Other
– some of what's already under Other is third party software.
Sure. If you think the organization is clearer that way. Thanks.
 

… FreeBSD is an amazing system, but all the … configuration, tweaking, … time consuming … Bluetooth, … drives me up the wall. …

… Bluetooth support.

<https://wiki.freebsd.org/action/info/2021FoundationCFI?action=diff&rev2=21&rev1=20>

… Scott Longs Thunderbolt/USB4 work,

<https://wiki.freebsd.org/action/info/2021FoundationCFI?action=diff&rev2=20&rev1=19>
 
Last edited:
I think driver support, work on the Linux compatibility layer, and some sort of container orchestration are the areas I would like to see improvement. I saw other people suggesting the same in this thread.

I appreciate tools like Docker because they make it easy to see exactly what’s necessary to build a piece of software. Nix/Guix have similar benefits. It’d be cool to see some sort of practical, declarative package management on FreeBSD. I‘ve only seen one example of using Nix on FreeBSD, and it was pretty daunting to me.

I’ve got a five-year-old laptop with hybrid graphics that I’ve been running NixOS on for a while. I want to try FreeBSD out on it, but since Nvidia Optimus/Prime or any other hybrid graphics configurations aren’t really supported I’ve been hesitant. I can’t exclusively use the discrete GPU because the power consumption would be awful on battery, and the temperature increase can cause the device to halt. Nvidia’s recent inclusion of Vulkan support has been good to see though.

I’ve also tried FreeBSD out on the RPi2B+ and the experience wasn’t all that great. My best experience was running it on a 32-bit computer that should’ve been recycled long ago.
 
… work on the Linux compatibility layer, … other people suggesting the same …

Summarised as Application container framework like Linux OCI, with reference to rootbert's <https://forums.freebsd.org/posts/543634>.


FYI the proposer's original thread (focused discussion):

 
3. Making the Raspberry Pi 4 fully functional
Indeed, I would like to see this. There are more Pis out in the wild than almost any other brand of PC (I wonder if they have surpassed the entirety of i686 in terms of numbers?) and it is always sad to have half working SoCs lying around which are only partially usable. Basically the same problem with Android mobiles running custom images and probably the new vendor lockin Apple chips.

But I believe developers alone can't solve this. Possibly the FreeBSD foundation may need to provide financial incentive to the Pi foundation or Broadcom to get accelerated GPU or fully comprehensive power management (i.e for Firmware rights or Documentation).
 
Indeed, I would like to see this. There are more Pis out in the wild than almost any other brand of PC (I wonder if they have surpassed the entirety of i686 in terms of numbers?) and it is always sad to have half working SoCs lying around which are only partially usable. Basically the same problem with Android mobiles running custom images and probably the new vendor lockin Apple chips.

But I believe developers alone can't solve this. Possibly the FreeBSD foundation may need to provide financial incentive to the Pi foundation or Broadcom to get accelerated GPU or fully comprehensive power management (i.e for Firmware rights or Documentation).
I frankly see more Pi-related content on the Internet than FreeBSD-related stuff (Even with the bias of me specifically seeking out FreeBSD-related content most of the time). I would imagine that from the FreeBSD camp, the closest we can come is GPIO-driven fartd. :p
 
Back
Top