Confessions of a Recovering NetBSD Zealot 194
debilo writes, "ONLamp.com is featuring a lengthy interview with Charles M. Hannum, to Slashdotters probably best known for his wake-up call aptly titled The Future of NetBSD that generated a rather vocal discussion. In the interview, Charles speaks about his role in and the beginning of The NetBSD Project, shares his thoughts on software licenses, discusses the popularity of Linux and its development model, and further addresses the problems that NetBSD is facing. Some notable quotes include: 'If I were doing it again, I might very well switch to the LGPL. I'll just note that it didn't exist at the time.' And: 'There was a lot of FUD around this issue — some of it from Linus, actually — and it did cause us some problems.'"
Cause and Effect of BSD "Safety" (Score:2)
A lot of people (and I don't want to be divisive, but honestly they were mostly Linux proponents, including Linus himself) spread FUD for years about BSD systems being "unsafe"--even after the UCB/USL lawsuit was settled. The fact is that there was no danger in using NetBSD in a product, and a number of companies did so.
You have to wonder if that would have been the case if there was not a much bigger boogie man for Ma Bell, M$ and other greed heads to worry about. If it were not for the success of the
Re:Cause and Effect of BSD "Safety" (Score:5, Insightful)
Just look at what Apple did with OS X. Any company could do that, getting a huge head start by building on top of the rock solid BSD core (with no fear of being sued, as you would with the GPL). That is a very scary thought indeed for MS.
What free OS designers need to do is realize that Apple did something very right with OS X, and follow suit. Unix with X-Windows on top of it is not suitable for the average user. X-Windows needs to be replaced with something more light-weight (i.e. single-user with direct access to the multimedia hardware). X-Windows will always be around for the power users who want it, but the average joe just wants his games/videos/music to run smoothly without any hassles, and he wants to be able to be stupid when it comes to using the Internet without having to worry about viruses, spam, and all that.
Oh my... (Score:5, Insightful)
X-Windows is in many ways archaic, but under the lead of the X.Org project there has been an astounding increase in the rate of development. The project has finally been modularized and the groundwork is in place for direct access to acceleration features. Honestly, the biggest thing holding back X-Windows from even faster modernization right now is the manufacturers of graphics hardware (NVIDIA and ATI) that are ridiculous enough to not even release programming specifications for their chips. Their "support" of the free operating systems is limited to shitty binary drivers, and so when the X-Windows and kernel communities want to introduce new APIs, they are largely at the whims of the moron companies that haven't gotten around to pulling their heads out of their asses yet.
If you believe that UNIX with X-Windows on top of it is not suitable for the average user, you should provide some facts to back up that opinion. Because as every day passes, I've seen all the arguments get displaced by proof of concept and running code.
Finally, what Apple did with OS X indicates just what is wrong with the BSD license. The coders and users that believe in the BSD license have been shown time and time again that the so-called benefits of the license are actually damaging to their projects. Charles Hannum from NetBSD recognized this recently when he talked about NetBSD's stagnation, and aptly characterized part of the problem as the BSD license that allowed companies to fork BSD and hire away all the important developers to work on their proprietary forks. Charles now says that he would have used the LGPL license if he were to do it again, which is exactly what the Wine project did after Transgaming and others ran off with their code and developers.
So this issue of licensing that you describe as making BSD the biggest threat to the proprietary interests is wrong. The BSD license's shortcomings in this area mean that BSD will continue to go nowhere fast. The reason that the BSD lawsuits were more scary was because the free BSDs actually had lineage leading back to the old proprietary (owned) code. The reason the SCO lawsuit is not scary, and rather actually hilarious, is because Linux was (a) developed in a vacuum and (b) is defended by the GPL.
The GPL is very important here, because it creates a safe haven for companies like IBM, SGI, Oracle, Red Hat, Novell, HP, Nortel and others to all cooperate on *one* core. When all of this engineering talent and financial power gets pooled into one project, that one project goes a long ways. And tossing its technical superiority totally aside, you're left with the actual *largest* threat to the proprietary interests - an entire cultural, economic, political and technical shift in thinking from proprietary development to Copyleft.
The BSD project and license followers have been operating with their heads in the sand for a very long time now. Even when the FOUNDER of one of the most significant free BSD efforts came out and said "We fucked up, and here's why," there were still a thousand BSD fans that chose to ignore the majority of the issues he raised, instead babbling on topics like "Theo is finally vindicated!". Given history, I don't expect this to change. There will always be BSD users with their heads buried in the sand, but their numbers are shrinking as they fail to see the train tracks being built directly in their path.
Re: (Score:2)
The choice between BSD and GPL reflects what a developer wants. If they want others to help with their software and want rights to all derivatives of their software, they choose GPL. If they just want to share what they make, they choose BSD.
I don't think that GPL software will make it to the majority of users' desktops. It is just
Re:Oh my... (Score:5, Insightful)
What exactly has BSD won? Just recently, Apple decided to close up XNU. Granted, I'm now hearing that they have changed their mind again, but doesn't that seem like any possible benefit to BSD is totally at the whims of Apple?
The choice between BSD and GPL reflects what a developer wants. If they want others to help with their software and want rights to all derivatives of their software, they choose GPL. If they just want to share what they make, they choose BSD.
You imply that BSD has a monopoly on sharing. Ironically, the difference between the BSD license and the GPL license is all about sharing, and in exactly the opposite way that supporters of the BSD license love to imply.
The GPL gets torn down by such folks as if it is some kind of false freedom. In truth, the GPL license lets you use the GPL licensed works in any damn way you please; in fact, you don't even have to accept the GPL license to use GPL'ed software!
The difference between the BSD and GPL license, then, is what happens when you want to copy the software. GPL looks out for the actual _users_ of the software by ensuring that the software will always remain free. The BSD license, on the other had, allows proprietary forks that _hurt_ the users. Mr. Hannum even pointed this out when he talked about NetBSD developers getting hired away to work on a proprietary NetBSD fork! He sees this as a big problem, so do I, and so does Stallman, which is why the GPL is designed to prohibit individuals and corporations from taking the freedom away.
I don't think that GPL software will make it to the majority of users' desktops. It is just too hard to make profit from Desktop Linux. Unlike a server, support for a Desktop OS can't be worth enough to make enough money to develop the software, or it won't ever sell.
Good thing the free software properties of the GPL and copyleft that defend the GNU/Linux desktop mean that most of the components are the same exact components as running on all those servers, where paid support is plentiful!
Your big error is in starting with the assumption that there Must Be a business of selling desktop operating systems. Personally I think it is plainly obvious that free software will displace that entire business. That is not the goal of free software, but it will happen anyway.
Desktop users don't buy operating systems -- they buy computers.
Re: (Score:2)
Grep the FreeBSD commit logs for @apple, and you'll see. Apple have given a lot of code back to FreeBSD. So have Yahoo, who employ (as I recall) six developers to work full time on FreeBSD. Unlike IBM and Linux, they don't feel the need to issue press releases about it. Actually, in Apple's case, it's in their best interests to keep it fairly quiet; they wouldn't want the average customer to think that they could use FreeBSD for free rather than OS X.
Just recently, Apple
Re: (Score:2, Interesting)
Interestingly, grepping the FreeBSD source tree itself for '@apple' shows a lot of hits in GPL licensed parts of the tree, such as binutils, gcc and gdb.
Now let's look at the BSD-licensed core parts:
Now, I'm too lazy t
Re: (Score:3, Insightful)
Desktop users don't buy OSes, but if their computer is running Linux and "won't work with their monitor", they will return it and tell other people not to buy a penguin computer.
It takes a lot of work to develop an OS. A hardware manufacturers is
Re: (Score:2)
Re: (Score:2)
How can you tell a Unix guru apart from a wannabe? The unix guru positively knows that X sucks, but gives in to it in the name for backward compatibility, the wannabe thinks X is good, 'cuz it belongs to Unix.
Re: (Score:3, Insightful)
I'm g
Re: (Score:2)
Re: (Score:3, Insightful)
They shouldn't have to; rather, they should just go back to releasing specifications to their customers like they used to. I think there are plenty of people in the BSD community that would agree with me on this, especially Theo.
Documentation of that opinion appears regularly and it take far more than "proof of concept" to make a platform "suitable for the average user".
You've mad
Re: (Score:2)
That would be supporting GPLed software now, wouldn't it? These companies don't release specs because they don't want to document their designs for their competitors. It's universal in that particular business.
"You've made an attempt to totally dodge my question."
No I didn't. I just pointed out that what you request is offered all the time and a quick search will show that. I have
Re: (Score:2)
X-Windows needs to be replaced with something more light-weight
I was with you until this point. X is very lightweight; it runs on some truly ancient systems. Quartz is much heavier.
X-Windows will always be around for the power users who want it, but the average joe just wants his games/videos/music to run smoothly without any hassles,
None of this has anything to do with X versus Quartz. Some of it has to do with proprietary video cards and proprietary codecs. Some of it has to do with the fact that c
X11 is heavyweight? (Score:5, Informative)
Really? Can you please point me to some numbers that demonstrate this point?
X11 was invented in the bad old days, running on UNIX systems less powerful than today's PDAs. As I understand it, it's actually quite lightweight. Certainly the network transparency features don't cost much, because when you run the X server and the X client software on the same computer, they communicate by using domain sockets (which are very lightweight). Both Microsoft Windows and Apple OS X have abstraction layers that isolate the graphics hardware; do you have some numbers showing that X11 has significantly more overhead than those abstraction layers?
The latest versions coming out of X.org now have support for features similar to what OS X does: applications are rendered into offscreen buffers, and the buffers are composited together (with transparency effects, or other special effects if you desire). So, X11 is no barrier to cool eye-candy [linuxedge.org] either.
The worst thing about X11 used to be way it was managed (under Xfree86). Now that the project has moved to X.org and has been revamped, progress has sped up a lot.
steveha
Re:X11 is heavyweight? (Score:4, Informative)
Not that lightweight. Fortunately, in the '80s, MIT released the shared memory extension which took away most of that overhead and has been standard in X servers for over a decade. The problem with X11's network transparency is that it is at the wrong layer. X11 puts network transparency between the view and the frame buffer, when it should be between the view and the controller. Sun realised this with NeWS, but did a typical Sun and said 'Hey, we've got this great technology! How can we market it in such a way that it never goes anywhere?'
Architecturally, there are quite a few things wrong with X11. The easiest solution is the one that Apple took; throw it away and replace it with something new. That isn't really a good idea for *NIX, however, since there is a lot of legacy software that uses X11. Fortunately, Keith Packard seems well aware of the shortcomings of X11 and has a set of incremental improvements that address them.
Re: (Score:2)
The rest of the world is waking up to the idea that single user non-network aware systems are limiting. Hacks like VNC and Gotomypc get you somewhere (I use both) but are really still hacks to get around the limitation. As for needing something more "lightweight" - you can run X windows on a Nintendo DS - that's right, on a system with 4MB of total memory and no memory managemen
Re: (Score:2, Insightful)
For the average user and PC, it's ok to make h
Re: (Score:2)
Then make an option available that's already around in many Windows XP program installations.
Install application for:
[ ] All Users
[ ] Just Me
Re: (Score:2, Insightful)
Re: (Score:2)
The point is not the repeated to death "if you don't like the license... blah, blah", but WHY I don't like the license, and why lots of people should at least know this point of view even if they disagree.
Re: (Score:2)
Problem here is, it's no
Re: (Score:2)
(The only exception to the above is aggregations of software that are independant of each other. The original Kororaa CD was clearly dependent upon the non-Free softw
Re: (Score:2)
Yes, of course it means some opportunities will be missed that might have been available otherwise. But I think the loss of Korokaa isn't su
Re: (Score:3, Insightful)
Yes, and we have laws against illegal confinement, slavery, and the like to discourage people from preventing others doing what they will. The GPL is like that.
The GPL doesn't prevent anyone from getting hold of Nvidia's drivers if they want them. It does prevent NVidia from benefitting from somebody else distributing NV's proprietary drivers with free code. In other words, the intent is to discourage NVidia, but the only legal method is to discourage NV
Re: (Score:2)
If the module was a seperate executable there would be no issue. It's not however, it's a part of the kernel, and so must be GPL if you want to distribute it with the GPL kernel. You can "run" it however you like by yourself, just don't break the kernel author's copyright by distributing it outside of the terms of their chosen license.
You c
Lets face it... (Score:5, Funny)
So true...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I'd rather have the combined differences of the top 20 Linux distributions than between Linux and any of the BSDs. In the same vein the difference between any two linux distributions are almost always: 1) versions of the same upstream package. 2) preference of one upstream package over another (Ie. exim vs. postfix). The differences between any two of the BSDs are "same package name, different code/maintainers/development".
So what is the next Toster OS? (Score:3, Interesting)
The answer is simple... (Score:3, Informative)
Re: (Score:2)
Linux more portable than NetBSD? If you look at the number of lines of machine dependent code per-architecuture, then Linux is far less portable than NetBSD. Which is what you'd expect from an operating system designed specifically for the 80386. NetBSD on the other hand is a successor of the first Unix codebase, which was rewritten in C with portability as a key goal. Also, in Linux device drivers are usually tied to one architecture. On NetBSD, a PCI driver for a network card will work on any architecture
Re: (Score:2)
Seems like it would have been a very good match.
You are *totally* wrong (Score:2)
Re: (Score:2)
No, my post is not full of FUD, as I experienced the lack of Linux driver portability when trying to get a network driver working on a PowerPC embedded board. The driver made assumptions about the endianness of the host system as it was written for x86 - a typical portability fuck up. Great care has been taken with support for different bus architectures in NetBSD, which makes drivers much more readily portable than with Linux where there is a huge amount of duplication in driver code that should be abstrac
Re: (Score:2)
If you ran into an endianness assumption, that is a bug, plain and simple. Among Linux's excellent portability layer is a set of macros to swap byte order how and when necessary (cpu_to_le32, cpu_to_be32, etc). If you find *any* architecture specific code that is not in either "include/asm-*/" or "arch/*", it is a bug and should be reported. And for the record, PCI drivers don't live under "arch/*".
All of these things are things you would know if you
Re: (Score:2)
All of these things are things you would know if you actually LOOKED at the code you so readily criticize. Linux is free and freely available. Get a copy from kernel.org and see for yourself.
What the fuck do you think I was doing when I came across the shitty driver in question? Well if you want to believe that Linux is a decent solution for embedded systems then go ahead and use it. Personally I'll stick with NetBSD where I get an entire, well integrated operating system, not some hastily thrown togeth
Re: (Score:3, Informative)
NetBSD does live, it will live,
but it also needs people to do the work, not just talk.
Join in!
- Hubert
What is really needed (Score:3, Interesting)
I am probably going to get flamed to a crisp for this, but what the heck, I have karma to burn...
If Linus continues to dig in and refuses to accept GPLV3 with its anti-DRM provisions, what is is for the linux developers who truly want to move to a GPL V3 model to contribute the fruits of their labour to a GPLV3 fork of the kernel. (Freenix anybody?) Note that they wouldn't have to stop contributing to Linux, they can dual licence as GPL V2/V3 for as long as they wish.
Actually the linux kernel could be forked from the existing code base licenced as GPLV2 with ongoing contributions to the new kernel licenced as GPLV3. Users would be bound by the terms of both licences, which would default to the more restrictive GPLV3 unless they took the time to strip out all of the newly contributed GPLV3 code. Support for DRMed media and hardware would done through clean room design, and hosted from servers in DMCA free countries. Does DVD Jon have some friends and a bit of spare bandwidth?
I really love linux, use it in my home servers and would use it on my desktop if I wasn't doing contract windows development as well. But I disagree with Linus's stand on DRM and the proposed GPLV3. RMS is an arrogant pain in the butt, but in this he is dead right. I like where GPLV3 is going, but we need to build a full featured OS around it.
Re: (Score:2, Redundant)
GPLv3 OS (Score:4, Informative)
You could create a GPLv3 fork of NetBSD though. That might revive NetBSD. You might just take the kernel though, letting distributions form around it. Debian already supports Hurd and FreeBSD kernels; they could do a NetBSD one as well.
Of course you'd need to find a name other than "NetBSD".
Ideas: NetOS, NotBSD, Netix, Netrix, Netux, Nettle, WebBSD...
Re: (Score:2)
Debian already supports Hurd and FreeBSD kernels; they could do a NetBSD one as well.
http://www.debian.org/ports/netbsd/ [debian.org]
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Good grief:
Re: (Score:2)
Point one - it is still a draft so he would be stupid and unprofessional to accept it while it is still changing. Point two - some of the DRM clauses still need work to avoid collatoral damage to people that are helping both linux and gnu but don't want random script kiddies flashing the firmware on their embedded systems from the net becuase authentication would be illegal under a silly clause. Point three - the idea to
Re: (Score:3, Informative)
Actually, no.
The Linux kernel is specifically licensed under GPL v2 only. Due to the deliberate design of the copyleft in the version 2 GPL, it would be illegal to distribute that code in a kernel where portions of the kernel could not be redistributed under the terms of the GPL v2. The inability of GPL v2 code to be put under a more restrictive license wit
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Then you wouldn't need the GPLv3 at all. Without any hardware support, DRM isn't an issue.
BSD Trouble (Score:3, Insightful)
In the linux dev. process, Linus is at the top of the org chart. He accepts or rejects patches that come to him. He trusts other people to maintain certain subsystems and architectures, but ultimately, he decides what goes in and what doesn't (even if he hasn't really looked at it much).
Difference #2: Linux is GPL'd. You can't profit from changes without sharing them. BSD is BSD'd. You can profit from your changes and keep them hidden.
So the sturcture of the Linux license enforces sharing and the structure of the development process enforces a set of standards (each upstream guy's own standards) on the quality (or lack thereof) of the code. The BSD license and the BSD development structure both require social contracts and continuous communication and agreement among the developers to keep things together and quality consistently high.
So in the BSD world there are forks because developers encounter both technical and personal disagreements. In the Linux world, the devs don't really have to get along as much, because the structure of the project is more forceful than the BSD cooperation regime.
All of the problems that this NetBSD guy have described seem to be mitigated more-or-less automatically in the Linux structure and with the GPL. Linux development is not perfect. Nor is the GPL. However, it sure looks like they're better approaches. Linux certainly isn't less successsful than any of the BSDs.
Apart from management; what's the problems? (Score:2)
I'm rambling because I'm tired, sorry. My point is that the software in pkgsrc seems to be recent, and fairly stable (though that port of ajunta is crap, cu
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Hang around here long enough and you'll stsrt to think the answer is "Yes!"
Re:All "in the family." (Score:5, Insightful)
No, that wasn't a serious go at you but it was an attempt at world-weary commentary. I was around when Linux was launched. I was using Minix on an Atari ST before that happened. I was using Linux as a primary desktop in 1994. And once upon a time I had code in the standard Linux driver set (a Compaq SCSI controller, I believe long since factored out. At least, I hope so).
So. The answer is....yes. Geeks eat their young. I remember at the time knowing very vaguely about BSD, but 'knowing' equally that I should steer well clear of it due to ongoing and the future potential for lawsuits. As it turned out, this was utter junk - FUD so to speak. In fact, looking back at things with the artificial benefit of perfect hindsight I would have gone the BSD route rather than the Linux one. I still read amusing little pro-Linux rants that are actually just pro-open source Unix userland, not pro-Linux as they believe themselves to be. Don't get me wrong, there are definite differentiators between BSD, Linux, running GNU tools on Solaris, OS X etc. but that's not the point I'm interested in here. For this discussion, I'm interested in seeing many of Unix per-se's benefits being described as Linux benefits when they are nothing of the sort. Personally I feel a good deal of progress could have been made just following the BSD route instead of going the Linux kernel route. LGPL does seem to encompass the majority of the BSD way, so I find I have agree with the statements made in this article.
Cheers,
Ian
Re:All "in the family." (Score:5, Interesting)
Why, oh why can more people not see this...
Linux is a kernel (as opposed to the BSDs which include a set of integrated userland tools - not just package a bunch of independently developed GNU tools), that really, these days is nothing particularly special, other than being "free". I mean sure, certain aspects of it may be cutting edge, but for the most part they're not "must have" features that will make or break it's usage in a particular application.
As much as I think RMS is a idealist nutjob, I can see his point regarding the whole "GNU/Linux" thing here (even though simply tacking "GNU" on the front isn't fair to other developers, without which the system would be useless for certain purposes, such as xfree.org).
Re: (Score:2)
Re: (Score:3, Insightful)
In fact, the end users wouldn't even care what base system it's on,
Re: (Score:2)
Definately disagree here.
Linux (or more specifically, "GNU" or "the gnu toolchain") is nothing like 'real' unix when you get further than a cursory observation. The GNU tools are usually different in some subtle way for no *really* good reason (it seems) other than to follow GNU's own "standards".
Examples that spring to mind for example: netstat, ifconfig, info, etc...
If you've used a few flavours of Unix (myself, Solaris, SCO (yes, it sucks), AIX, FreeBSD)
Re: (Score:2)
% ls *zip
(oops, I think I want to see some file sizes)
% ls *zip -l
Re: (Score:2)
But, but...GNU's not Unix.
Re: (Score:2)
That's from The Open Group [unix.org], who own the trademark [unix.org]. So if you want to call it Unix, your product must meet their standards of what Unix actually is. Presumably you have to pay to get it certifie
Re: (Score:3, Insightful)
Re: (Score:2)
However, calling the operating system "Linux" is not really being truthful either.
There's a lack of a term for describing what it really is ("Linux kernel + free stuff" doesn't have much of a ring to it :D), unless you use a distribution name, i.e., Redhat or Debian, etc.
Re: (Score:2)
Re: (Score:3, Insightful)
If you ever watch the kernel compiling, most of the time is spent compiling device driver. And the legacy support is immense. Heck, you can shave a few minut
Re: (Score:2)
Re: (Score:2)
I don't really buy this, even if I hear it all the time. Linux is not developed in a vacuum, and neither is GNU userland software. For all practical purposes, Linux is the GNU kernel.
Then again, if you want to argue on the merits of integrating kernel with userspace, look how well Microsoft is doing it ;)
Re: (Score:2)
Re: (Score:2)
There's FreeBSD. You can install the base system off an ~120mb install image last I checked. Granted, it's not *quite* as portable, however I would argue that this is not such a major problem these days, with x86 hardware being so cheap and giving good performance. It's "por
Re:We need a NetBSD (Score:5, Informative)
I can get it installed on older hardware in less than 5 minutes, including the boot time for the floppies. I can get it installed on modern Opteron-based badass hardware in about half that. That's pretty cool.
And you're being very short-sighted about other architectures.
Re: (Score:2)
Yes and no.
I'm aware of the embedded space, but personally I think that within a few years it will all be x86 anyway (much as it's a "crappy" architecture). Also, given that the costs of storage, RAM, etc are dropping extremely quickly, I don't think that worrying about 20mb vs 200-600mb is worth wasting the development time on any more.
But that's my personal opinion...
Re: (Score:2)
I was so hoping for the ppc/alpha to take off myself, but alas... "worse is better" strikes again...
It's getting to the point now though that for 99.99% of the coders out there, they couldn't give a crap what a cpu is like to program from an assembly point of
Re:We need a NetBSD (Score:4, Interesting)
Free, sure. But I dont know about lean and mean.
The whole point of NetBSD is portability. If it weren't for portability, NetBSD might as well not exist. But the problem is Linux has taken over as the portability leader and has a huge margin.
Every 32-bit cpu out there has a corresponding Linux BSP or distro. At least ones with enough ram or external bus interface. To compete, NetBSD will have to do without MMUs in some cases, and allow the kernel to be configured to be really small. Linux can scale and has enough configuration options to be able to produce a 200kb kernel and boot in under 1MB on an ARM7TDMI.
Given its license and code cleanliness (and maturity) I'd prefer NetBSD if it was portable enough. Its not.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Note that uClinux was long ago merged into the mainstream linux 2.6 sources (in version 2.5.46 iirc). These days, the "uClinux patch" for 2.6 kernels mainly contains a few odds and ends for specific chips that haven't been merged yet.
So for many MMU-less chips, you can just grab "linux" and it will work, though if you want a 2.4-derived kernel, I guess uClinux is still necessary (2.6 can be slower and more bloated i
Re: (Score:2)
Given its license and code cleanliness (and maturity) I'd prefer NetBSD if it was portable enough.
From the interview:
Charles M. Hannum: [...] NetBSD today does a very poor job of setting and meeting standards. I created the mythos of NetBSD having "clean" code, and even I don't buy it any more.
FWIW I haven't read any NetBSD code so I don't have any personal opinion on it.
Re: (Score:3, Interesting)
Re: (Score:2)
I suspect NetBSD is dead, and its core developers should wo
Re: (Score:2)
That's exactly the problem for me. Linux' "portability" consists of special cases for each architecture.
NetBSD is one source tree that you can compile on every supported arch or even cross-compile on i386[1], e.g. if your sun2 is too slow to build its own kernel let alone a complete system in reasonable time.
I can take a PCI WLAN card and put it into a Sparc with PCI slots and it runs the same driver from the same source as on i386. That's
Re: (Score:2, Informative)
Yes and no. Most people who make this comment should add the caveat "for 2.2.x/2.4.x series kernels with glibc 2.2.x/2.3.x w linuxthreads".
If your hardware is new and relatively common, linux kernel will most likely have a current working port.
Move off the path well travelled and you are in for a lot of strife.
M
Re: (Score:2)
Re: (Score:2)
In short, give me a 32-bit cpu with gcc support and I'll port 'Linux' to it. I agree that Linux will be more different from its RS6000 versions than NetBSD would be between its smallest and largest implementations. But I happen to have more in my toolbox. Just having more in the toolbox makes it tougher yet more possible to port.
Dont get me wrong, I've used NetBSD at many places a
Re: (Score:3, Insightful)
Re:Why doesn't he pull a Matt or Theo? (Score:5, Insightful)
Forking a project is NOT necessarily detrimental. In fact, I would consider it more an evolutionary inevitability. The plain fact of the matter is that most Open Source projects are a confluence of like minded individuals which is at best ephermal in nature. People age, people's interests change, people's life situations change, new people coming in have a different take on things... to assume that a project can keep the same face forever and that such evolutionary changes as a fork in the road is detrimental can only lead to one result: stagnation.
I wouldn't hold Linux up as a poster child, either. Linux is one of the most commercialized projects in existance compared to the BSDs. Just because the core is free doesn't mean the product is. Every time I turn around yet another GPL'd project is being commercialized by its developers, or using tag-ons to the license that require the author to sign over his copyright to the project. The GPL license no more protects against proprietization and commercialization then the BSD license. Nor does it protect against fragmentation... Linux is far more fragmented then all the BSDs put together, and that has seriously hurt its ability to compete against Microsoft. It's nice to day dream, I guess, but the reality is very different.
-Matt (Dillon)
Soon you'll be a user of DragonFly BSD. (Score:2, Insightful)
So while FreeBSD, NetBSD and OpenBSD will still be working on getting their kerne
Re:Soon you'll be a user of DragonFly BSD. (Score:4, Insightful)
Redesign and reimplementation seems to imply starting from scratch. This doesn't seem to be the case for DragonflyBSD.
So while FreeBSD, NetBSD and OpenBSD will still be working on getting their kernel sufficiently threaded for many years to come, DragonFly BSD will have had that task completed for a while.
DragonflyBSD has the development resources necessary to redesign and reimplement the FreeBSD kernel, *and* get their kernel "threaded" faster than the other BSD projects already working hard on that task?
Pardon me, but I don't think your description makes much sense, and it doesn't sound like you know anything about operating system scalability. In a monolithic kernel design like Linux, FreeBSD, NetBSD, OpenBSD or DragonflyBSD, "threads" are largely a user-space concept. Sure, you have kernel threads to run specialized tasks, but the bulk of the performance critical code runs "on top of" or "on behalf of" user tasks. This differs from a microkernel implementation where the kernel is really broken down into multiple threads that pass messages (even then, however, certain kernel functions like memory management and process scheduling must be centralized.)
In reality, the real effort of creating better scalability centers on implementation of finer-grained locking and faster data structures, so that the locks aren't as contended as they once were.
Reportedly, it has become better than Irix at many tasks, and is even beginning to rival Solaris. With Irix still trumping Linux in most cases, this goes to show how far ahead DragonFly BSD already is.
DragonflyBSD is interesting, but I don't think you should be making claims like this without providing verifiable data. Do you have any references?
Re: (Score:2)
Re: (Score:2)
Eivind.
Re: (Score:2)
Linux was up & running on 128-way SGI Origin Supercomputers back in 2001. Today, the kernel that you get from kernel.org works wi
Re: (Score:2)
Re: (Score:3, Insightful)
That said, I think the constant attemp
Re: (Score:3, Informative)
Re: (Score:2)
FreeBSD is not a branch of, "BSD 4.2 Light," FreeBSD is a fork of Jolix with such a long and divergent development that it looks nothing like that old 386BSD code. Once, long ago, both NetBSD and FreeBSD had a resyncing when they had to take their modifications to 386BSD and move it over to the 4.4BSD-lite codebase, but that
Re: (Score:2)