Comment by spijdar
6 hours ago
The BSDs do have comparatively miserable contributor experiences, though I understand why. At least from my very, very limited exposure.
Several years ago now, I ran into a problem with playing audio on NetBSD/sparc. I had an RDI PowerLite laptop, which is 80% of a SPARCstation 5 clone stuffed into a laptop chassis. Part of the 20% different was the audio chip, which was the same AMD ISDN chip used in the SPARCstation 1/2, doing mu-law audio.
Whenever I'd play audio, the laptop would instantly reset. Huh. That's weird. I ended up figuring out that someone had recently massively overhauled the audio driver subsystem in the kernel, and basically the relevant audio driver was missing some mutex operation, and an assert() was panic'ing the kernel.
For a non SMP system, the lock wasn't necessary (IIRC) but the new code was being more rigorous and causing a kernel panic.
The patch was pretty easy, just adding a few locks/unlocks. But I could never figure out what I was supposed to do with the patch after.
I'm probably just stupid. I don't want to imply there's no path to do this, I just never figured it out. I didn't try for long either, since getting 8-bit mu law audio working was just something goofy I was doing for fun.
But for comparison, when I found a bug in the signal handler for 32-bit PowerPC, my memory was that it was pretty straightforward to produce a patch: find the relevant maintainer, open a dialogue, and eventually submit a patch: https://marc.info/?l=linuxppc-embedded&m=160963760120837
Neither fix was ultimately very important, and neither would have impacted more than a couple dozen people on the entire planet. But Linux got a patch, while NetBSD didn't...
These days there are too many choices for FreeBSD, you can submit a GitHub PR, Phorge PR, Bugzilla patch, Phabricator patch, mailing list patch... sharing the code is not the hard part. For NetBSD, a Gnats PR and/or mailing list comment with a patch or link is still the way.
Getting a person's attention who can and will do something is still challenging if you don't know whom, which is the same problem I saw sending patches to Linux mailing lists which went unanswered, and was given no specific feedback or path forward privately contacting the corporate maintainers.
Yeah, I probably put too much weight on my anecdote. I didn't try looking for very long at all, and the case of Linux was made easier by the code being part of a small bundle of patches made by a couple of people, and the fact that Michael Ellerman was really nice, communicative on IRC, and accommodating to a very niche and bizarre set of patches.
> But I could never figure out what I was supposed to do with the patch after.
Send an email to the dev list with a patch. Same as Linux, Git itself, and a lot of other projects.
>I had an RDI PowerLite laptop
Just out of curiosity, why the Sparc laptop? While I'd love to find one today to tinker with, I assume anyone who had one back then was mainly working on sun machine's / unix and needed some at home familiarity.
I bought mine back in 2019, when I was ... 22. I was going through my "I want a real UNIX machine!" phase, and that's why I went through the motions of trying to make NetBSD "genuinely usable" on it.
Nowadays it runs SunOS 4.1 with a port of KDE 1 on it, and netboots Sprite for fun.
Of course, after porting the Sprite kernel to said laptop, I learned why the Linux kernel is littered with comments like this, and why it was never quite the beautiful, elegant, UNIX :tm: machine I imagined it was.
Or, maybe, it was even more UNIX-y than I had thought. :-)
(of course, the laptop itself is lovely -- the plastic shell has a nice rounded edge for your wrists, and the keyboard uses proper mechanical switches that feel much nicer than actual Sun keyboards of that era)
Ahh a modern purchase! I get temptations every time I've seen a sparc powered laptop end up on Ebay, but never for a low enough price to justify the the tinkering urges.