Slashdot Mirror
OpenBSD Fork Bitrig Announced
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.
sounds like a place to keep my bitcoins...
I don't think he will be mad about that. Mad about the devs leaving, sure, but not about the commercial fork. If they contribute back to the main trunk, then I think all is well.
Seriously, Theo may be a bit aggressive, but he's not an idiot, the BSD license allows this more clearly than anything else out there short of public domain.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
If they contribute back to the main trunk, then I think all is well.
The double edged sword of the BSD License. I'm sure they will probably contribute back but unlike the GPL there is nothing legally to compel them to.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
This is a good "Put up or shut up" moment for BSD. For all the whining I hear about "Viral" and "Anti Business" licenses the various *BSD projects sure do have a meager adoption (Buisness, home, free or otherwise) compared to their GPL counterparts (Linux). I think an aggressive, forward looking BSD project would be great to have.
Granted, not all the most popular open source projects have "Viral" licenses (Eg - Most Apache foundation projects), but maybe.. Just maybe Linux's success is in part due to the GPL.
Some people feel the GPL is stealing something that they're somehow entitled too. In reality, it's more of an exchange. You give up the ability to have a certain business model, and in return you get the collective work of everyone else who's made the same agreement. You give up exclusive control of your source in return for a world-class, flexible, free, operating system with widespread uses. For free. With a BSD style license you're able to opt out of that "collective work" provision. You can take, but you don't have to give. As a result, the project does not grow.
It's probably in your long-term interest for the project to grow. I think the success of Linux proves this.
Freedom -- true freedom -- is about people having the ability to be assholes if they choose.
More Twoson than Cupertino
Most points of their agenda are common with FreeBSD and some are already done there or actively been worked on. No one would stand in their way porting WAPBL from NetBSD (if done decently). Ok, stripping the base is (fortunatelly) not on the FreeBSD agenda, but making most of it optional for embedded needs is.
From their FAQ, "OpenBSD [...] has some of the best code around". Ok, but I still do not buy it. If they want to leave some of the conservatism that comes with the security focus of OpenBSD behind (from the article), I do not find a real reason why they started with OpenBSD.
Not that some more good, modern code with any of the BSD would be wrong...
Why would those companies want to have to maintain their own forks and keep those up to date?
"be a very commercially friendly code base by using non-viral licenses where possible."
The advantages to Linux over BSD licensed operating systems is that improvements are reinvested in the code base, by mandate. This accelerates development at a much faster rate than we've seen with any of the BSDs since it is a positive feedback loop. Contrary to this, companies take BSD code, improve it, and tend to release nothing back. Because they don't have to. Look at OSX.
So now we have a project that is "focused on modern hardware and SMP" among other things. Compare and contrast to Linux which keeps up with modern hardware a lot better than any of the BSDs. I'm betting the goal of "keeping up with modern hardware" is going to fall by the wayside when they eventually discover how difficult it is when it's just them doing all the heavy lifting.
I also take issue with the "commercially friendly" jab. Linux is GPL, and it's commercially friendly. Sensible companies are not afraid one bit of using Linux. The ones who are don't understand what they're missing when it comes to the code reinvestment cycle.
-- ... 1...
BMO Downmods coming in 3... 2
Take a look at DragonFly BSD -- it exists, Matt Dillon has a track record, and it's doing cool stuff (like HAMMER fs).
Do you even lift?
These aren't the 'roids you're looking for.
The double edged sword of the BSD License. I'm sure they will probably contribute back but unlike the GPL there is nothing legally to compel them to.
That is not a problem from the perspective of the BSD people. In their experience, code being contributed back only because of legal reasons is so rarely of the quality that anyone would consider merging it back to the original OS that it does not matter to worry too much about that code. Anyhow, there are companies that choose to contribute some of their changes back without legal obligation, which tends to be of better quality, since they want to have it included for whatever reason (for example not to have to maintain their own fork in rapidly changing regions of the code), while they do not consider working on GPL code for their own reasons.
It might be different for different projects.
"i386" is OpenBSD-speak for the architecture variously known as "x86", "x86-32", "i686", "IA-32", and "32-bit Intel". Just as "amd64" is OpenBSD-speak for the architecture known to others as "x64", "x86-64", "IA-32e", "64-bit Intel", "Intel 64", and whatever VIA calls it.
> The double edged sword of the BSD License. I'm sure they will probably
> contribute back but unlike the GPL there is nothing legally to compel them to.
In practice, this only matters if the project is so stagnant that it doesn't actually matter any more after all.
If the project is active, the work of maintaining your changes (either by constantly updating your patches every time an upstream change breaks them or, if you prefer to go the clean fork route, porting over or reimplementing upstream changes that you specifically want) is so burdensome that any reasonably competent developer will WANT to get his changes incorporated upstream just so he can get off the maintenance treadmill for a bit and maybe have time to implement something else.
Cut that out, or I will ship you to Norilsk in a box.
Including the freedom to take away other peoples freedom, I suppose?
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
As others have said, though I'll add a bit more depth, is that i386 is the catch all for anything x86, with the exception of ensuring that it distinguishes from the 286 and below. The 386 was a major step up from the 286 and below due not only to being 32-bit, but also allowing protected mode and virtual mode operations, in addition to paging.
Virtually no modern software is adaptable to a 286 processor, whereas nearly all of them are adaptable to a 386, hence the common usage of "i386". As a matter of fact, intel actually didn't stop producing the 386 until around 2007. It was still widely used for embedded applications long after it was already obsolete.
Careful with names containing L slashdot.org/~AiphaWolf_HK slashdot.org/~AlphaWoif_HK slashdot.org/~AiphaWoif_HK