| |||||||||||||
The license?The license?Posted Sep 20, 2007 4:28 UTC (Thu) by roelofs (guest, #2599)In reply to: The license? by jamesh Parent article: The case of the unwelcome attribution 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
(Log in to post comments)
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).
|
|||||||||||||