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.
A bitrig is 1/8 of a byterig.
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
"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
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.
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