Bitrig 1.0 – an OpenBSD fork – has been released. Why, exactly, did Bitrig fork OpenBSD?
OpenBSD is an amazing project and has some of the best code around but some of us are of the opinion that it could use a bit of modernization. OpenBSD is a very security conscious project and, correspondingly, has to be more conservative with features. We want to be less restrictive with the codebase when it comes to experimenting with features.
It took about 30 months to get out their first release. That doesn’t inspire much confidence.
That said, good luck to them! If nothing else, maybe Bitrig can blaze something of a trail for OpenBSD — you know, figure out what does and doesn’t work in modernizing the codebase.
yeah they’re still on perl 5.18 vs openbsd is already on 5.20. lots of other examples where they’re not exactly trailblazing. also read that it took them so long to release because they were trying to scrub the openbsd name everywhere. just downloaded their release and they totally failed to scrub puffy (I didn’t even bother searching for openbsd). hilarious.
Um, well considering the perl 5.20 commit happened… 2 weeks ago on openbsd. Just maybe you’re being a bit snobby and elitist?
http://marc.info/?l=openbsd-cvs&m=141625770215854&w=2
Edited 2014-12-05 03:59 UTC
Not really. if they were trailblazing i would have hoped they have put perl in around when it was released in May; i mean they only have one arch to worry about for testing.
My point, is this: what does bitrig do that’s different? I like trying new stuff out and I think competition is good, but I don’t get what their value add is…
I think the project fits into the category of scratching your own itch. Props to them for that!
I’m not going to use bitrig any time soon, since I actually depend on some of those old crazy architectures (i386, ultrasparc) I also have an octeon install running too, but it’s not doing much other than ‘being on’.
Hmm, considering I have several hundred of those little alix systems running openbsd across my province as pop’s, I don’t think I’ll be moving to amd64 any time soon.
Actually, come to think of it I don’t actually have an amd64 installation of anything other than windows 8.1 on the laptop I’m banging this out on right now.
[quote] some of us are of the opinion that it could use a bit of modernization[/quote]
Isn’t FreeBSD modern enough? BSD is becoming a lot like Linux: forking the fork of a fork.
Who will use Bitrig? What will entice people to use it? Or is it just another toy project for some people to hack?
Given that the the Bitrig people are mostly ex-OpenBSD developers, they presumably want something in that vein — only “modern.” FreeBSD might be modern, but it’s definitely different from OpenBSD.
So modern, in fact, that it doesn’t support my wifi card, nor my gpu, nor most of my usb3 dongles. It’s really leet and sweet, keeping me focused on work by disallowing all attempts to watch cats on youtube and play lame games. Now, that’s modern!
Edited 2014-12-05 08:13 UTC
Go ahead and cooperative instead of bashing.
Download the code, write your own drivers for your devices and commit them back to the project. It is obviously easy, isn’t it?
And, if you do not have the skills to do that, then not blame them.
A typical response from individuals in the open source community. I am not saying you are wrong. But that response doesn’t help. Those who download BSD must be aware of the fact that he needs to be certain first that the hardware he owns is supported. Write your own drivers for a proprietary hardware? That is a big NO, even to those with skills I think.
Is there something called <insert_your_flavor>BSD Hardware Compatibility List?
https://www.freebsd.org/relnotes/CURRENT/hardware/
It is a fork of a fork of a fork because of 386BSD -> NetBSD -> OpenBSD -> …
of course this isn’t the first OpenBSD fork (MirBSD) and it won’t be the last. OpenBSD and FreeBSD are clearly ahead in terms of people forking them at this point.
As someone who forked FreeBSD, let me say I don’t blame them for taking so long to do the first release. MidnightBSD wasn’t stable until 0.1.1 and I still haven’t removed all the “freebsd” from the ports tree. In fact, most ports are still impersonating freebsd just to get them to build. A lot of upstream projects won’t take patches from new or less popular OS projects, especially if they compete with Linux. It’s a real problem.
It’s shocking how changing the OS name can break building so easily. I’m starting to think software should do header detection and not try to build based on name kind of like how user agent sniffing in javascript is considered bad now.
yes, but scrubbing “puffy” wouldn’t break anything. I get the need to emulate FreeBSD for ports on midnightbsd. I also remember long ago someone else forked OpenBSD and I think they forgot to wipe theo’s name from the ISO image. that was also hilarious.
I just feel like if you miss this stuff, do you really know the internals of the code you released? Dunno…
I am interesting in what Bitrig has to offer. There is a server I work on that I’ve been thinking of wiping and installing FreeBSD for ZFS support, however FreeBSD does not work properly with the hardware. OpenBSD I think will work with the hardware, but has limited file system support. (So far as I know, OpenBSD has not adopted ZFS yet.)
One of the roadmap goals of the Bitrig project is adding more file system support (especially FUSE) which could be really convenient for me. OpenBSD’s hardware support and documentation combined with an advanced file system would be very appealing to me.
Just fyi, OPENBSD also has fuse these days. I think ZFS is nice, but wow is it resource intensive. personally I’m more interested in the BSDs all getting hammerfs.
ZFS is not particularly resouce intensive. It runs fine on systems with less than 1GB of RAM and it works fine for me on a system with a 1.2GHz CPU. You’d have to have surprisingly low-end machines for ZFS to be a problem where resources are concerned.
Edited 2014-12-05 16:36 UTC
Then you have a very very small ZFS system (< 750GB) if it works “OK” with just 1GB of RAM.
ZFS is fine on VM hosts with ludicrous amounts of RAM. I’ve got a server with 192GB of physical memory running SmartOS, so the OS itself, including ZFS, takes less than 5% of total system RAM for 4TB of physical storage. For more typical smaller installs, ZFS is definitely overkill.
I understand that people disagree about how things should be done, and know we have the right to assembly things from FOSS components the way we want. Some variations even, sometimes, produce something better or valuable but, on most cases, they do not. Most of them are just cosmetic changes or something that could be done concurrently with the master project.
The people involved learn something (or a lot) about how things are done and, by the hard way, how package building is dependent on things they did not expected, like system name, for example, and how changing it can wreak havoc on system build process by a cascade of references in make files, cmake files and other build systems.
I don’t know how things are done on BSD side now as I have changed all things I do/use to Linux a long (relatively) time ago but wonder if would not be a good time to BSD master projects to think about use things like debian ppa or openSUSE repositories to accommodate some variations (pardon if this already exists). It is a kind of compromise, the master project allows small variations that can fill a need of some users and benefit from associated contributions increase and diversity.
From what I have seen, a full fork is seldom needed.
All of the BSD’s already have package repos and tools, all of which are simpler better than what debian and opensuse has.
OK, perhaps I was not clear enough or I plain simple was not aware of them when I used FreeBSD, but what I am talking about is alternative repositories for a set of packages (like variations of KDE, Gnome, or any other set of interest that may contain features not available on official ones).