Slashdot Mirror
Where Does NetBSD Fit In?
NetBSD Fan writes "KernelTrap offers a fascinating summary of the recent 2004 Annual NetBSD Group Meeting. Included is an introduction by NetBSD foundation president Christos Zoulas discussing NetBSD's relevance in light of competition from well known operating systems such as Linux and Windows which he acknowledges 'both offer more features than we do, and they have behind them the resources of very large commercial organizations.' He also talks about FreeBSD, OpenBSD, Solaris and Darwin, ultimately concluding that they all are facing their own serious challenges, and that plenty of opportunities remain for NetBSD. The NetBSD project recently released NetBSD 2.0."
In fact, the latest release of NetBSD fits better, and runs faster, than the Solaris of 4 years ago.
I'm pretty sure that all of them, at one time, had active DEC Alpha ports. Linux was very popular on the Alpha, as well. However, as the Alpha is pronounced dead time after time, Alpha ports fall out of date and eventually stop compiling altogether. I don't think you can even compile OpenBSD on the Multia any more. Pity.
NetBSD, however, I would trust to keep "obsolete" ports working. Linux is good about this, too, but I wouldn't bet my (theoretical) job on the latest Linux kernels supporting an Alpha server I wanted to put back in production.
If you want, just subsitute your favorite dead platform (Atari, Amiga, 68k Mac, etc) for the Alpha, and I think you'll see that NetBSD will probably never die.
NetBSD is the BSD for people who don't like change, and I'm one of them. Although the system has gained many new features and has matured significantly over the past few years, the base system has largely retained the same design and layout that it has for years. Nearly every NetBSD version looks the same and behaves the same, which means you almost always know what to expect.
One of my favorite things that's come out of the NetBSD Project in the past few years is the Pkgsrc collection. Pkgsrc has been gradually evolving from a NetBSD-only 'ports' system, to a very robust cross-platform package management system. It really cuts down on a lot of work to be able to manage a handful of different Unix systems, but use the same package management scheme on each system, and keep the pkgsrc repository on a single NFS server updated with a nightly cvs cronjob.
In the BSD world, NetBSD seems to be the least driven by hype and feature creep. This makes it a real joy to use and maintain, because like I said before, you always know what to expect: a cleanly-designed, stable, functional, easy to use Unix system.
We got an old SUN. 200M harddrive, poor CPU, not too much RAM, GREAT monitor, nice keyboard and mouse. A dream machine for an X terminal for our servers. But what to run on it? I tried Linux. It would barely fit. No way to fit X, a desktop manager and enough to comfortably use it. It was still possible to mount a drive over NFS and pull some binaries from there, but it was way too slow. In short, Linux sucked for it. I looked what else would work on that architecture. NetBSD? Let's give it a shot. I installed it, installed X, some basic software so it could work as a standalone workstation, not just terminal, then found enough spare diskspace, that I set up root directory and all demons necessary to run YET another SUN, a diskless workstation with equally great monitor from it (even with SWAP memory accessible over NFS, swapfile on that small drive...) So, two very nice terminals on exotic architecture, all off a 200M harddrive.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Perhaps linux is somewhat unreliable because of the speed the patches are being integrated? This is not an app, this is a kernel and kernels require rigorous testing and full security audits. Take a look at the kernel changelogs.Things are moving very fast in the linux world, so fast that merges of unstable/unsecure code are frequent.Even the grsec guys were complaining at the bad quality of code which makes its way to the kernel.Nowadays, linux seems to have become a testbed for all the cool new features, while it's left for the distro makers to further stabilize and test the kernel. This job should be done before releasing the kernel.
One awesome thing about netbsd is that it runs on some of my old hardware that never would otherwise be useful. DECstation 5000 with a sexy 21" monitor would be a paper weight without NetBSD. I can run it as an X terminal just fine. It even is nice for small stuff like my Macintosh SE/30. System 6 can only do so much, barely even run an old version of nutscrape. I have an old copy of MacX but it sucked. NetBSD, got a nice little Xterm, ssh client, etc. Fits in the server room, and bang. I have a xterm smaller than most of our VT510s ;)
NetBSD fills a need no-one else will, and because of that its relevant.
Ran great until I started getting flooded with spam. SpamAssassin just couldn't keep up on that box; it'd still be processing the previous batch of mail when fetchmail grabbed the next batch.
I upgraded to a sparc 10 with dual 60Mhz processors, but had to move to Linux because NetBSD didn't yet support multiprocessor SPARC. It kept up OK, but 2.4 didn't support Sparc32 very well; the ext3 filesystem became corrupted with SMP enabled, so I had to go back to ext2. There seemed to be little remaining interest among the Linux kernel developers for Sparc32 anymore.
I think Solaris 10 is 64-bit only, so NetBSD may be the only option left to stay up to date on all those old Sparcs!
We apologize for the inconvenience.
This is really a no brainer,
NetBSD is designed to be low footprint, highly portable, and flexible. It's the ideal BSD for embedded systems (whereas FreeBSD is suited to larger size systems and servers, and OpenBSD is unfortunately in the middle as a security oriented system, but not portable nor performance enough as NetBSD).
Licensing is a key NetBSD selling point. The problem with Linux/GNU is the GNU license which does not favour commercial embedded manufacturers who want to customise the software inside their product and (a) not have to offer the source code, and (b) not have to offer any competitive/IP/commercially-sensitive content in that source code (i.e. algorithms, device driver interfaces, etc). Despite all of the hoo-haa about the GPL, I'm afraid that companies really do like to minimise risk and lower cost by keeping their product internals as secret as possible.
Portability: NetBSD wins hands down: Linux has been ported to lots of things, but the basic architecture is not as clean. This is been shown time over again, and proven by the supported (not just "happened to be ported to") platforms of NetBSD.
NetBSD also gets to leverage the work from FreeBSD and OpenBSD, as FreeBSD really has greater commercial support in terms of device drivers and so on than either NetBSD or FreeBSD.
What NetBSD should be focusing on (in this order)
1. keeping tight BSD licenses (the kind of Theo style approach being applied to OpenBSD at the moment : to be very strict about licenses of included items) -- commercially friendly for competitive/cost reasons;
2. keeping high portability and flexibility: making sure that as new processors/platforms/drivers come along, that they can be quickly and easily supported -- commercially friendly for time to market allowing easy leverage of the existing product;
3. continually rolling in new support for hardware and security features as possible by grafting from FreeBSD and OpenBSD;
4. continually reworking and streamlining the internals to support all of the above;
5. improving the build environments (i.e. the cross compile is fantastic now), the ports system (fantastic and incredibly easy to bring third-party components in), and other things such as boot code, embedded/compressed installs, etc;
6. not getting "lost" on wasted effort for things like graphical installers, or coloured-ls's, etc;
Basically, NetBSD should continue to
- target small/embedded devices;
- continue/improve commercial friendly;
- innovate/improve on reducing total effort to realise NetBSD onto a new hardware platform;
I stick with Net/Free/Open BSD for the sake of sheer familiarity. I understand the BSD way of organizing things. I understand and love pf. I understand how most BSD projects organize their code trees, so using CVS to pull down a stable branch and compile is really second nature. I could devote time to relearning Linux, but I don't have any circumstances that necessitates such an undertaking.
I'm sure that my circumstances are not unique, and that Linux folks can say the same thing about their flavor of Linux.
-Troy
There was General George Patton. During World War II he raced across Europe, outrunning his own supply lines. He was a lightning warrior who seized every opportunity, and made his own luck. He didn't sit around waiting for the stars to properly align. General Patton is now acclaimed as the one of the most skilled field generals of all time. He was a "can do" guy. He was a winner.
Then there was was another George, General George McClellan. He was a General for the Union side in the American Civil War. General McClellan was a stickler for procedure. He never made a move without drawing up plans in triplicate. Unless every condition was met, he sat tight rather than risk the unknown. Consequently his armies stagnated. They did nothing. Today General McClellan is regarded as one of the most inept generals of all time. He was a failure.
Linux development is fast paced. Linux developers make their own luck. It is a market driven operating system which responds to the needs of the marketplace. Like General Patton, Linux development adheres to a "can do" philosophy. Like Patton, Linux is a winner.
Now then, for extra credit, which struggling operating system might be called "the McClellan OS" ?
We need real-time scheduling support, POSIX real-time extensions, and thread-safe libraries.
That would be AWESOME. NetBSD is already great for embedded, but with the addition of real time we can finally get rid of the hegemony of proprietary RTOS vendors. My company was using an RT Unix, but the royalties were just too great and we had to abandon it for... WinXPe + INtime. Aaargh! NetBSD was actually evaluated for this, but it had to be abandoned due to the lack of RT.
Don't blame me, I didn't vote for either of them!
- Hubert
I can't answer for him, but I know why I'd use it for a firewall. It's simple, efficent, and secure. While some will tell you that you should use OpenBSD because it's the most secure, NetBSD fills this role just fine. It's efficent enough to run on EXTREMELY old hardware. It's portable enough to turn just about anything that can support 2 network interfaces into a firewall.
Umm even Apple gives back.. Open Darwin comes to mind.
The main issue between BSD items and Linux items, is marketing..
And i wouldnt say that BSD is a flop.. Its just not made it big in the comsumer market like linux has..
However, look in server rooms around the world and you will lots of BSD stuff.
---- Booth was a patriot ----
If so, why don't we see BSD as popular as linux?
Possibly because those people who use BSD code aren't required to disclose it? I've always wondered how much out there was running on BSD and nobody knew it. I'm reminded of the exploit discovered in the BSD TCP-IP stack which effected machines running Windows as well.
BSD should stand for BSD is Silent but Deadly. Your car, or DVD player, or cable box, or router could be running on BSD, and you would never know.
The ______ Agenda
You can't do that with Linux either. The name aside, the Linux you run on one arch is not the Linux on another arch. This is especially true if you have an architecture Linux' corporate sponsors don't care about (hint: Linux is all about corporate sponsorship. If you don't believe me, read the changelogs and notice that 99% of the submissions are from employees of big corporations).
Some distros (e.g. Debian) smooth this out, and some make it a nightmare (e.g. Gentoo), but until there's a GNU/Linux distribution that is consistent across all archs in source AND binary deployment and a kernel that contains all architecture fixes at once and keeps up with mainline development, Linux will not be as easy to 'jump between' archs as NetBSD.
NetBSD has the same build procedure on any architecture, using the same headers, sources, and resulting software (sans tools that only make sense one some archs). THAT is the same OS on every arch. The same name of kernel on every arch doesn't even compete. Being able to cross-compile consistently is a great bonus too, but this sometimes breaks down if you're following a development branch. Not all archs have an installer, but those that do appear to have the SAME installer, with extra functionality for those architectures needed.
My example of where even Debian does not have this: SGI MIPS. It does NOT automatically handle the SGI Volume Header (hint: NetBSD does, and installs its own bootloader), nor even tell you what to do: you have to figure out how to use the fdisk-like editor and hope you left enough space for arcsboot or your kernel. On some machines which have very tiny hard drives and need all the space they can get, Debian's way leaves a lot of user calculation to be done. You could call this "well if you're incompetent then don't use Linux", but then that's supporting my argument: NetBSD is an OS for all archs, Linux is a kernel that got ported to some archs at some point in time, and if they're not used by corporate sponsors you can kiss them good bye. Distros won't care either - why should they?
Linux' 'technical excellence' in supporting every arch and every feature anyone could want (to at least some extent) is nice, but that's beside the point of which system is actually more convenient for the architectures it supports. I know if I was running a polyarchitectural (cool word) network I wouldn't use Linux no matter how much faster it was, the administrative mess of managing a plethora of different kernel sources and base packages would be a nightmare. That's how it is in Gentoo at least, maybe Debian is better after installation (but then you lose the source-based flexibility NetBSD still offers without compromise).
Sam ty sig.
The beauty of NetBSD is that I can run the same core configuration (almost all the files in /etc can just be drug around to your various machines) on my Sparc hardware, my i386 boxes (including, finally, my quad PentiumPro box with a released version), my IBM PPC and my Apple 68K and PPC hardware. And even my Macintosh SE/30 machines (bless their little souls). I haven't been able to run it on my ancient MIPS palmpc, because it doesn't have enough memory.
There is one core configuration system, one userland for all the different machines. And it's all built from the same source tarballs.
That is cool.
"What's the frequency Kenneth?"
Somebody once said to me: "Linux is for people who hate [Microsoft]Windows; BSD is for people who love Unix."
;)
After lurking slashdot for a time, I can see this quote is quite accurate.
PS: I am a Linux guy who secretly flirts with BSD (but too young to remember Unix) and loathes Windows.