Theo's initial response to the thread, which may help illuminate the situation, was:
"Except for the fact that it is bullshit.
They started the fork because they got kicked out because one
developer (Marco) hired 5 other developers for his startup company,
and attempted to hire around 10 other developers in a sneaky and
underhanded way. They were told, oh i forget they were "asked", to
not tell anyone else in OpenBSD that this was happening, probably
because people "including Theo" would be upset.
Funny thing is, I've never been upset about the 20+ OpenBSD and
ex-OpenBSD developers who now work for google.
Previously, many of those developers were in critical positions in the
development team. As they were suddenly hired with such terms and
conditions, they became more scarce in OpenBSD -- perhaps because they
suddenly got real busy with work, but also to avoid telling others
that this was happening. Various projects lagged. To avoid telling a
lie, they instead chose to not tell the truth. It had effects. It
was dishonest of them to not tell their co-developers that they were
creating vacuums in the development process.
So because of those decisions, they are now gone from OpenBSD. And
now they miss it. So now, all these guys who work for the same
company have started a fork. And it is directed by the guy who hired
them in the first place.
From where I stand, that is the truth.
Yet none of that is in that article, because the truth hurts,
doesn't it guys?"
I don't like that this gossip thread from a few years ago is at the top. People come to Hackernews for entertainment (including me), but I still don't like it. Mainly I'm here so I can learn things, and see what other people are doing. The gossip side of things is sort of annoying.
It's much more interesting to compare the development process of the groups, and how the two groups will help each other.
I always thought if OpenBSD had modern development tools and processes they would do really well, but unfortunately there are too many risks. How they're doing it works well for them already. But perhaps this situation with another group working in a different way better again. Since this project can experiment, and anything that is proven can be taken on by OpenBSD.
A thread with some of the people most directly involved, including OpenBSD's founder, on how the fork happened is as relevant to the subject at hand as it gets. Not sure why you view it as gossip. It also directly answers your question on how the two groups will help each other i.e. not much at all.
> It also directly answers your question on how the two groups will help each other i.e. not much at all.
Hopefully the bitterness surrounding the fork's birth will eventually wash away and the people involved just look at the benefits. And it's not true that the two groups aren't helping each other. Some code does flow between OpenBSD and Bitrig, just as it does between OpenBSD and NetBSD. And there are people who are involved in both, and communicating with developers from both projects.
> I always thought if OpenBSD had modern development tools and processes
I just don't understand this attitude. Git and Clang or GCC 4.bleedingedge.something don't write the code for you. Is having to commit to an older VCS really that high a barrier to entry for developers? Because if it is, that makes me suspicious of their skills and focus.
Theo's thoughts do pass through a dick-filter, there is no denying that, but he is almost always right in what he is saying.
As far as Bitrig is concerned, I don't see the point in it. The FAQ doesn't say anything that makes me want to try it and, although they say they want to support only modern systems, it seems to me that what they are really doing is limiting themselves to what LLVM supports.
This is a problem, because what makes OpenBSD so smooth is testing on the weird legacy architectures like VAX. With a number of the changes on their roadmap I wonder if maybe adopting DragonflyBSD or FreeBSD may have been simpler.
Correct me if I'm wrong, but most of the things (or maybe just the ideas?) you have implemented seems to be coming from NetBSD. If so, could you share other NetBSD stuff you'd like to see on Bitrig ?
For me personally, better armv7 support. Even though many things stem from our hands, NetBSD and FreeBSD are a great resource. I have already started working on SMP support, based on their example.
Otherwise I do not have any NetBSD stuff in mind. Can't speak for our other developers though. ;)
I would love to have FreeBSD's bhyve on Bitrig. I will dedicate some time in January for that goal. DragonflyBSD is an inspiration for us, too. We have an experimental branch (smpns) for revamping the kernel for decent SMP support.
> Why is the project named Bitrig?
>
> The name Bitrig is derived from the Latin "Bitrigus", the name of the software used by the Romans to conquer Europe. Sadly, not having zero among its numerals made traditional computer science difficult for the Romans and the project was put on hold indefinitely. Bitrigus faded into obscurity until it was recently rediscovered at a Viking archaeological site in the modern day country of Iceland.
>
> The Roman emperor Hadrian is rumored to have sent Bitrigus as far west as a boat could carry it to keep it from the then growing threat of religious fanaticism within the Roman Empire.
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.
"With the goal of bringing more experimental development to the OpenBSD code base, a few developers have announced a fork named Bitrig. According to their FAQ, Bitrig aims to build a small system targeting only modern hardware and "be a very commercially friendly code base by using non-viral licenses where possible." Their first step toward that goal was removing GCC in favor of LLVM/Clang. The project roadmap shows their future goals as adding FUSE support, improving multiprocessing, porting the system to ARM, and replacing the GNU C++ library with LLVM's."
Portability and modernity instead of a security focus?
I'm not sure why I would use a fork of OpenBSD instead of just FreeBSD though. I've always seen the primary benefits of OpenBSD as deriving from their obsessive focus on security, but if this fork isn't focussed on that I'm not sure what I gain vs. other BSDs that already have these goals and objectives in place/completed.
OpenBSD has always had a strong focus on protability. It's just the focus on portability was never restricted to "modernity" for the reason that there's few interestingly different processors anymore you can compile against to check for breaking errors.
It would be interesting though if Bitrig became sort of a DragonflyBSD for OpenBSD, where weird experimental stuff can be tested in a separate playground.
Forking is the way of the BSDs. The BSD style is to develop the userland along with the kernel. Thus where Linux has multiple distro families BSD has full userland and kernel forks.
It'd be easier to carefully add specific features to a well-designed and secure codebase such as OpenBSD, rather than try and pare down and audit the huge codebase and large amount of features provided by something like FreeBSD.
Theo's initial response to the thread, which may help illuminate the situation, was:
"Except for the fact that it is bullshit.
They started the fork because they got kicked out because one developer (Marco) hired 5 other developers for his startup company, and attempted to hire around 10 other developers in a sneaky and underhanded way. They were told, oh i forget they were "asked", to not tell anyone else in OpenBSD that this was happening, probably because people "including Theo" would be upset.
Funny thing is, I've never been upset about the 20+ OpenBSD and ex-OpenBSD developers who now work for google.
Previously, many of those developers were in critical positions in the development team. As they were suddenly hired with such terms and conditions, they became more scarce in OpenBSD -- perhaps because they suddenly got real busy with work, but also to avoid telling others that this was happening. Various projects lagged. To avoid telling a lie, they instead chose to not tell the truth. It had effects. It was dishonest of them to not tell their co-developers that they were creating vacuums in the development process.
So because of those decisions, they are now gone from OpenBSD. And now they miss it. So now, all these guys who work for the same company have started a fork. And it is directed by the guy who hired them in the first place.
From where I stand, that is the truth.
Yet none of that is in that article, because the truth hurts, doesn't it guys?"