| |||||||||||||
The license?The license?Posted Sep 20, 2007 1:01 UTC (Thu) by felixfix (subscriber, #242)Parent article: The case of the unwelcome attribution
BSD has forked several times and Linux has not forked at all. I have thought this is probably in the license, specifically that the GPL makes it harder to keep your changes private, not that the public BSD variants have gone private, but you can have private BSD variants, so I suspect there are some, other than Max OS X and whatever Microsoft copied.
Seems to me that this forces Linux developers to get along more; they can't just get huffy and take their marbles home.
Or maybe this is all baloney. I don't claim to actually know what I am talking about.
(Log in to post comments)
The license? Posted Sep 20, 2007 1:50 UTC (Thu) by smurf (subscriber, #17840) [Link] Dunno about the license, but one reason is probably that, let's face it, the BSDs split up because the splitters didn't get along with the splittees.
One would almost expect the "not getting along with others" meme to continue, and bingo, that's exactly what we see happening.
The license? Posted Sep 20, 2007 2:00 UTC (Thu) by felixfix (subscriber, #242) [Link] Sounds about what I was thinking. I guess I am curious about whether the license attracts argumentative sorts, argumentative sorts decided on that license, or it is pure luck of the draw that attracted the argumentative sorts to BSD.
Maybe also a feeling of when will their time come, seeing as how one BSD variant was about to go public when AT&T sued them, and I know that colored my decision to go with Linux way back when. Maybe that set the tone for the frustration to follow, when each fork made it that harder for them to regain their rightful throne.
Eh well, it's not a topic worthy of a thesis.
The license? Posted Sep 20, 2007 2:54 UTC (Thu) by jamesh (guest, #1159) [Link] Note that each of the *BSDs produces a full OS distribution in addition to working on a kernel, so saying that Linux has never forked while the BSDs have is not really a fair comparison.
Many Linux distros started as forks of existing ones (e.g. Mandriva from Red Hat, Ubuntu from Debian, Slackware from SLS, etc).
The license? Posted Sep 20, 2007 4:28 UTC (Thu) by roelofs (guest, #2599) [Link] Note that each of the *BSDs produces a full OS distribution in addition to working on a kernel, so saying that Linux has never forked while the BSDs have is not really a fair comparison.That's a valid point, but isn't it the case that all three major BSD kernels (Open/Free/Net) have diverged significantly? I haven't followed BSD development in a long while, but my impression was that the kernel architectures were no longer compatible. If so (and I could well be wrong!), that would be a significant difference from Linux--I don't think there are any true forks of the latter, just different versions (chronologically speaking) and lots and lots of out-of-tree variants. Greg
The license? Posted Sep 20, 2007 7:06 UTC (Thu) by rsidd (subscriber, #2582) [Link] You are absolutely right. The BSD advocates like to say that there are "only" 3 (now 5, including DragonFly and Darwin) incompatible forks of BSD, while there are dozens in Linux. But the linux kernel is still the same. You can install the "vanilla" linux kernel in any linux distro and get a working system. Binaries will also run, as long as the dependent library versions are compatible. The BSDs have meanwhile forked into completely incompatible systems with not even a pretence of commonality. If they had agreed to keep a common API for userspace programs, it would have been much better. Ironically, they all implement a reasonably good version of the Linux API, so they can run Linux binaries, but not one another's binaries.
The license? Posted Sep 20, 2007 12:26 UTC (Thu) by eSk (subscriber, #45221) [Link] I see the coupling of kernel and user space development, allowing the APIs to be developed in tandem, as one of the strengths of the BSD world. A common kernel API would have defeated this completely. I've never seen a good reason to have binary compatibility interfaces between the BSDs. Recompiling the applications in question typically works out of the box. The main reason for having Linux compability mode is that many applications are Linux-binary only (acrobat reader, flash, etc.) Without a Linuxulator there is no way to run these apps on a BSD box.
The license? Posted Sep 20, 2007 13:37 UTC (Thu) by rsidd (subscriber, #2582) [Link] I see the coupling of kernel and user space development, allowing the APIs to be developed in tandem, as one of the strengths of the BSD world.I keep seeing this claim, but what is the benefit? Increased stability? Fewer bugs? Any interesting features that could not have been developed with a stable API? Apart from certain very specific programs like ps and top, I don't see why the userland needs to be developed in tight integration with the kernel. And in fact, with 99% of the userland, it isn't. Developers routinely update their kernels every day but go weeks or months without updating the userland. I tried FreeBSD-current a little while ago. They still have problems with removable media -- if you remove it without unmounting (which is easy to do by mistake with a USB memory stick), you panic the system. This has been true for years. Check the long thread on freebsd-stable in July, where Warner Losh says it is a very hard problem to fix because assumptions that media aren't removable are hardwired deep into the system; basically he says don't expect a fix. Then someone points out that it has been fixed in DragonFly, and Matt Dillon says all they did was repeatedly unplug peripherals and analyse core dumps. End of thread -- no replies. DragonFly is impressive for what a small team can do, but it has too many warts to be a regular desktop OS for most people. I am keeping an eye on it, though.
The license? Posted Sep 20, 2007 22:22 UTC (Thu) by ajross (subscriber, #4563) [Link] That's a commonly-made point, but I'm not sure it's really borne out by evidence. From my perspective, the kernel/userspace interaction layer is far *more* robust in linux than it is in BSD. Think about things like the module subsystem, udev, hald, sysfs, NetworkManager, et. al. In theory, the "tight coupling" between the BSD kernel and userspace layers would make this sort of thing easier, yet this is one of the areas where BSD, frankly, compares very poorly.
The license? Posted Sep 20, 2007 12:15 UTC (Thu) by eSk (subscriber, #45221) [Link] True. The BSD in-kernel architectures are not completely compatible. Some porting effort has to be employed in order to bring code from one kernel into another one---depending on the extent and type of code in question of course. There's still quite a bit of code flowing in between the kernel trees though (just look at the CVS commit messages). Perhaps more importantly, one of the projects may have a completely new architetural design that is getting polished and reaching a mature state proving its usefullness before other competing solutions in the other projects get phased out in favour of the superior one. This is pretty much a win-win situation.
Sure, in the Linux world one may have out-of-tree variants attempting sort of the same thing, but these variants will for the most part want to be short lived and get merged into mainline to easy the task of keeping things up to date. On the BSD side, on the other hand, the forkers are more inclined to follow through with their ideas fully without compromise, not necessarily aspiring to having the code merged back at a later stage. This can often create more interesting and radical changes (e.g., DragonflyBSD).
The license? Posted Sep 20, 2007 6:56 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > Note that each of the *BSDs produces a full OS distribution in addition to> working on a kernel, so saying that Linux has never forked while the BSDs > have is not really a fair comparison.
But distributions compete amically, and core developers move from one to another pretty often. You don't have let's-burn-bridges forks, or follow-our-leader-maximo-to-the-death distros (ok, except for Ubuntu, and it's not a technical leader). Linux distributions have been known to cooperate and even merge.
The BSD forking process seems a lot more extreme
The license? Posted Sep 20, 2007 22:25 UTC (Thu) by ajross (subscriber, #4563) [Link] With all due respect, OpenBSD is precisely a "let's-burn-bridges" fork. It began when Theo was ejected from the NetBSD team following a complicated and only partially public flame war.
The license? Posted Sep 20, 2007 23:46 UTC (Thu) by sflintham (subscriber, #47422) [Link] I may be naive, and I'm certainly no Ubuntu fanb0i (I run it, and although it is slick in its way, I have had a number of issues which have certainly made me doubt its reputation for a polished environment), but is Ubuntu really a let's-burn-bridges fork? I could certainly see it has some kind of 'follow our leader' quality, but does that really have a serious technical impact? Not trying to be awkward, just asking - while I run it I certainly have no strong emotional investment in it...
The license? Posted Sep 21, 2007 6:34 UTC (Fri) by nim-nim (subscriber, #34454) [Link] Ow, seems I wasn't clear - when I was writing about distributions, I was writing about Linux distributions, which seem a lot less antagonistic than the various BSDs
The license? Posted Sep 27, 2007 12:02 UTC (Thu) by renox (subscriber, #23785) [Link] >But distributions compete amically
Amically is a too strong term, otherwise instead of having each distro reinventing the wheel for its installation tool, configuration tool, etc we would have only a few of these tools with higher quality..
The license? Posted Sep 20, 2007 20:59 UTC (Thu) by amikins (guest, #451) [Link] Actually, I think it's the other way around. Linux forks all the time, and vastly more often than BSD forks. People branch off and do their own development on independent trees that may or may not track mainline at all. Frequently they mostly do, but contain some combination of patches that haven't made it to Linus yet. The trick is, this is a good thing, and intentional. The danger is not, and has never been forking..
It's the ease with which you can merge forks later, and that's the real strength of the Linux kernel development community. All of these forks of the kernel, and then the result gets filtered into the 'mainline' tree and released by Linus. It's the natural way for open source development to work, it's just been more clearly embraced by the development process. You can see this reflected in GIT's design.
|
|||||||||||||