Post a Comment
I think that you are overstating the importance of the license in this respect. For instance, Apple has contributed back to FreeBSD. Linux just had more hype and better PR. Besides that, things would probably have worked out differently if the BSDs had their Red Hat.
That said, look up recent benchmarks, and you will see that most BSDs are doing fine, even on multi-core hardware. Sure, there are some weak spots, but they are all decent and solid UNIX systems.
"That said, look up recent benchmarks, and you will see that most BSDs are doing fine, even on multi-core hardware. Sure, there are some weak spots, but they are all decent and solid UNIX systems."
And I'd like to add that most of the Internet runs on BSD code, and not Linux.
Example: Cisco routers, Junos?, TCP stacks, etc. are all BSD based.
So? The BSD license allows for this use, and most developers don't mind, otherwise they wouldn't have used the BSD license. While I emphasize with (copyleft) free software, I also think free choice of developers is important (they wrote the code), and some developers chose to use a license that allows vendors to use their code in a proprietary manner.
And in the end, I think this is good. Remember that in the 80ies and early 90ies free software wasn't accepted as much in the industry. If BSD originally used a copyleft license, vendors probably wouldn't have used the BSD TCP/IP stack en-masse. The result could have been miserable: a dozen of semi-compatible proprietary stacks.
Sometimes non-copyleft code is necessary to make standard implementations.
need four things in my opinion:
1. A good binary package manager. 99% of the world uses compiled software. There is no reason not to have a decent package manager. Mix ports and packages and you will get a beautifully screwed up system.
2. A virtualization strategy for running full emulation - not just jails. I think Linux market share is going to keep rising because of this. BSDs, instead of focusing on linux emulation to run linux software should focus their energies on a virtualization solution like KVM. I am not sure why only NetBSD runs Xen and even that poorly. Lots of features don't work under NetBSD dom0.
3. Diffrentiate from linux. If the BSDs are going to run the same software and have the same capablility (give or take a few percentage points of performance) as a Linux box, then it will always be .... Take a Hint from Apple.
4. treat Linux as a competitor. Stop calling it a fad or the "latest hype" and call it what it is - A TARGET.
I run several servers (20+) on FreeBSD and they run fantastic. I recently started installing Ubuntu server on a couple of systems for KVM (its actually pretty good). I used to run FreeBSD as my laptop OS as well, but recently switched to Ubuntu on that (got fed up with broken ports and hours of compiling).
I have 0 experience with NetBSD so I can only assume that it works like in OpenBSD.
I have yet to have any problem with packages and ports. They are pretty straightforward and easy to hack which I fear is the main worry of the BSD developers. Of course I would enjoy an aptitude-like package/port manager, but I have yet to run into a problem. The system is user friendly enough to not allow you to screw up.
On the licence, I believe that the freer the licence the most likely that someone will use and modify your code. So the more likely that someone will contribute back willingly as opposed to by force. That said I would keep the advertising clause.
1. A good binary package manager. ... Mix ports and packages and you will get a beautifully screwed up system.
NetBSD is actually pretty good about this if you use one of the quarterly pkgsrc releases, and haven't changed any of the default make options. What NetBSD doesn't necessarily make easy is installing them remotely; you have to set an environment variable to the mirror you want to use.
2. A virtualization strategy for running full emulation - not just jails. ... I am not sure why only NetBSD runs Xen and even that poorly. Lots of features don't work under NetBSD dom0.
Probably because it was one of the development platforms chosen for Xen. I kind of get the impression that it's not a pressing concern for the developers. I also really am beginning to question whether h/w-dependent virtualization makes any sense for anything above smb/home use.
3. Diffrentiate from linux.
They have. The BSDs are more Unix-like. Most GNU/Linux distributions have very GNU-specific ways of doing things. NetBSD's claim to fame, of course, is clean, portable code. Linux isn't anywhere close, even if it does run on more architectures. Venture outside x86/amd64/ppc with Linux, and problems start cropping up pretty quickly. Even PPC is sketchy sometimes.
4. treat Linux as a competitor. Stop calling it a fad or the "latest hype" and call it what it is - A TARGET.
With the exception of FreeBSD, I don't think the project developers care about competing with Linux. OpenBSD is focused on being free and secure. NetBSD is focused on being portable and clean. DragonFlyBSD is focused on Matt Dillon's kernel concepts and clustering.
All that said, NetBSD is a wonderful system. It's clean, simple, quick, and stable as hell. I'm happy to see them move to the modified license; it's been a long time coming. I do wonder if this really does spell the end of XFree86 in the kernel tree, however.
My understanding of why XFree86 is still around is because its the only x server that will run on some arches. Xorg hasn't either been ported to all arches yet, or it isn't stable enough to use. At least that was the case the last time I checked, which hasn't been for a while.
Yeah, that was my understanding, too. Xorg from pkgsrc seems to be the preferred method these days. The reason I brought it up is that now the Xorg license is incompatible with the rest of the shipping code. It was XFree86's change to a BSD-with-attribution license that caused the Xorg fork in the first place.
NetBSD makes it possible to cross-build build NetBSD itself and XFree86, on virtually any supported platfor for nearly all supported platforms. Simply through the invocation of the build.sh script.
The build infrastructure and patches to do the same thing with X.org is not completely there yet. So, replacing XFree86 with X.org in the base system would be a (large) regression.
That said, X.org can be built from pkgsrc, and there has been a lot of work in making it possible to crossbuild packages with pkgsrc. Once X.org can be crossbuilt through pkgsrc, it may become a good alternative for X.org.
1. A good binary package manager. 99% of the world uses compiled software. There is no reason not to have a decent package manager. Mix ports and packages and you will get a beautifully screwed up system.
Gentoo is a good Linux distro and it is a sourcecode based distro. For pkgsrc, there are a lot of users that provide precompiled packages too. I do not consider this as a blocker.
2. A virtualization strategy for running full emulation - not just jails. I think Linux market share is going to keep rising because of this. BSDs, instead of focusing on linux emulation to run linux software should focus their energies on a virtualization solution like KVM. I am not sure why only NetBSD runs Xen and even that poorly. Lots of features don't work under NetBSD dom0.
The problem here is human power, almost all stuff (if not ALL the stuff) about Xen dom0/domU in NetBSD is implemented by Manuel Bouyer (just one developer) that did an amazing work porting Xen to NetBSD (or NetBSD to Xen)
3. Differentiate from linux. If the BSDs are going to run the same software and have the same capablility (give or take a few percentage points of performance) as a Linux box, then it will always be .... Take a Hint from Apple.
Agree.
4. treat Linux as a competitor. Stop calling it a fad or the "latest hype" and call it what it is - A TARGET.
Agree.
The problem here, again, is human power, the BSDs do a very very good work with the scarce resources they have; though they disagree, I thing a good dose of "hype" is needed to move these nice projects very steps ahead.
There's a page dedicated to NetBSD on the Eee:
http://www.netbsd.org/ports/i386/eee.html
I certainly welcome this move by the NetBSD Foundation.
William Hoskins, the director of the office of technology licensing for Berkeley, removed the obnoxious BSD advertising clause in 1999, in response to a request from Richard Stallman himself. FreeBSD and OpenBSD followed suit.
This clause made the BSD license incompatible with the GNU GPL, which caused problems for a number of projects. See for instance http://www.linux.com/articles/59456
I guess its removal will also ease the cross-pollination with other BSD systems.
It's pretty nice seeing that all the code which was contributed to the NetBSD Foundation has been modified to use the new 2-clause NetBSD license.
In 2005, I counted NetBSD required about 240(!) acknowledgments. Does anyone know much of the NetBSD codebase has been contributed to the Foundation and how much is still subject to this annoying clause?





fixed that for you.