Thanks to the luck with QEmu this week I finally got a Gentoo/FreeBSD VM working again, so I can actually resume working on the one thing I joined Gentoo for, initially. The nice thing about this is that the project is, in itself, mostly an experimentation, which means it’s quite easygoing. But it also has some very interesting and useful results.
Every time people ask me why do I think Gentoo/FreeBSD is useful to something, I point out that by not using ports, we’re ensuring that the software builds out of the original sources, and if it doesn’t, we can provide the patches upstream, since we have to write them in a way that is compatible with other systems anyway. This hasn’t changed the slightest in the last two years I didn’t work on the project: ports maintainers still don’t seem to provide upstream with patches, and lots of software is quite broken.
Indeed, in the last couple of days I identified quite a few issues both in and outside of Gentoo: bsdtar from libarchive failed to work with latest Portage version (thanks to Tim who provided me a patch within the hour!), pambase was putting nologin in the wrong chain (fixed and pushed a new release out), sandbox does not compile (still broken, need to be investigated yet), PulseAudio was totally borked upstream (now I made it build but it still fails tests, need to fix and port some areas, and if I had the time there is also the OSS driver to fix), libSM has a dependency over libuuid (which collides in FreeBSD, where the system already provides a different, incompatible interface; I submitted a patch to use the FreeBSD uuid interface when available), and more.
I cannot blame the Gentoo/FreeBSD team for this, because, well, it’s just Alexis right now I guess; I’m getting my hands dirty and making sure I can get the thing to work as it’s supposed to, and this is the important part, I guess. On the other hand, I wonder why is it that FreeBSD developers don’t seem to care about this kind of problems at all. PulseAudio might not have the best OSS support, but that’s just because Lennart obviously don’t care about it (Fedora now also disabled it by default, good for them!), but if somebody were to actually mind PulseAudio (more than I can do, since I don’t have audio in my VM anyway), I don’t think it would be impossible for it to provide proper support for the FreeBSD OSS options.
At any rate, I guess I’m now back to my original plans as well, at least part time, hopefully it won’t be too bad on the long run. Going to try GCC 4.4 with the system packages, and the kernel, later on today. Or rather I’ll leave it to test the build since I’m actually supposed to be out of here to a friend’s house for some photo shoots (long story…).
Oh by the way, if you haven’t noticed I’m still making some changes to the blog, in particular now the tags and categories pages show decent titles; I have made some changes to Typo that allows me to set the titles in a more human-readable way. If I can find time I’ll be also cleaning up the tags, since I have lots of tags with one post each, and there are some synonyms that I should really get rid of. To do the latter, though, I’m going to write a script that can merge the tags’ contents and then set up redirection, since I dislike very much to break the links in my blog, as you may know already.
Oh well!
For what exactly would anyone need PulseAudio? Why not simply use OSS directly?
“Already discussed”:https://blog.flameeyes.eu/2… .
The big question from a BSD user like me has always been: why not FreeBSD? That is the question for which I haven’t really found an answer.If it is “because we can” or “just for fun”, then okay, I applaud it, but otherwise it sounds silly — silly to duplicate any efforts at Linux distribution level and silly to bring the Linux “package madness” to a system that tries to avoid it at all costs to begin with.Disclaimer: Gentoo’s policy to avoid patching and to stay as clean as possible is preferable in this regard, so perhaps the question is really aimed towards Debian and alike.
Since I had to mess with freebsd and macosx from time to time I must say that it’s “just because works better for me”.Certain packages in portage are easier to install and configure than the ones in plain freebsd ports (e.g. ejabberd).there isn’t much duplication btw, you get the package better tested across more systems, but you do not redo them for every os/userspace combination. In the end just the system/runtime packages are the ones you have to redo
I sincerely can’t understand Debian GNU/kFreeBSD once you get over the technical proof of concept idea. On the other hand I find Gentoo’s Portage system much simpler to deal with than ports or macports or all the stuff like that, so I love having it available on a system with a kernel that is better designed for other tasks than the standard ones Linux is used for.But in particular Gentoo/FreeBSD is supposed to strengthen FreeBSD itself, since we often have in Portage versions that ports don’t have yet, we tend to forwardport the patches earlier and, since that’s our policy, we forward upstream for integration. It’s a second pair of eyes looking into the patches, after all, which is certainly positive.
> Flameeyes about 11 hours later:>> Already discussedYes, but not in the context of FreeBSD. See, FreeBSD uses OSS. And there’s no reason to pick PulseAudio over OSS4, which does resampling, mixing and volume, out of the box and without the user needing to set it up. There’s even a Gentoo ebuild for OSS4. Hell, I even use it on Linux. After I tried it, I completely removed ALSA, PulseAudio, ESD and Arts (back when I was on KDE3). Everything became much simpler. There was just one audio system on my machine: OSS4.I think the simplicity of that approach can’t be beat.