That's the point of the portable copies: and they do get tested. If there's one thing we can trust OpenBSD for it's releasing solid software, even if not always in the kernel (at least from what I've heard).
Linux is buggier than you think. Factually (this is not trolling, shut the fuck up, the AC who keeps replying to me), NetBSD's bugs found with the same software: http://mail-index.netbsd.org/tech-kern/2005/02/23/ 0037.html
No mention of Free or Open or DFly, but they should be somewhere in between, from the bug reports I've seen around.
Re:About politics rather than functionality
on
The Case for FreeBSD
·
· Score: 1
Microsoft is not a real threat to BSD, since they don't really care about the end-luser market (as noted by some BSD advocates, the end-most of end users don't contribute code and most don't even donate funds, and so there's nothing tangible to gain from appealing to them). The server market IS where Linux, Solaris and the BSDs compete (I'm ignoring OSX at the moment, it's nowhere near free enough to count as a competitor), and the highest-end servers only run Linux and Solaris (right?), so BSD is only on the low->medium market... but the security and development model give it useful competition against Linux (which seems to be the highest performer).
The BSDs compete in a productive way. They share code and designs where practical (unless something conflicts with philosophy or goals), and their constant benchmarking against each other forces each to adress their problems. Some harsh words get said and some personal arguments occur, and this has even caused forks, but that's typically a fact of life. It shows the developers have human personalities, not just senses of humor and coding abilities.
Grr @ HTML nature of Slashdot... the first line of that portage had "net-www/mozilla-firefox-1.0-r3 (from pkg media-libs/freetype-2.1.9-r1)" after a certain bracket I won't repeat.
Hint to Slashdot: Wake up, you can format things without needing HTML.
Gentoo plays dangerously with blockings and confusing dependencies, if you run 'tested' software only (and non-tested basically sets your machine on fire).
I have two examples. Firstly, when XFce 4.2.0 was just released, it was in Portage in a heartbeat. Some days later HALF of it was marked tested, and half was still untested (at least for x86). Since parts that were marked tested needed the untested ebuilds, they couldn't emerge; and since some other software (e.g. panel plugins) needed the older versions altogether, emerging them killed your newer versions (and hence your whole xfce4) and brought back older, incompatible ones.
While this is as much a failure of XFce for being such a disjointed piece of shit in the first place, Gentoo Portage falls way behind FreeBSD which Doesn't Care About Versions. Rightly so.
Second example, copy-n-paste:
[blocks B ]
[ebuild U ] media-libs/freetype-2.1.9-r1 [2.1.5-r1] -bindist -debug -doc +zlib 969 kB
[ebuild U ] media-gfx/gimp-2.2.3 [2.0.4] -aalib (-altivec) -debug -doc +gimpprint +gtkhtml +jpeg +mmx -mng +png -python +sse -svg -tiff -wmf 13,486 kB
I can either have the new GIMP (2.2 was in the tree for one day buildable, then impossible to emerge without hacks for a month or so, now back as untested - even though every other package manager concedes that it is in fact very stable) and lose Firefox because a new freetype is needed, or keep the old GIMP and be able to use Firefox. Charming.
The worst example ever, is that even the tested ebuilds are often completely broken. libusb needs user intervention to work at all (try to emerge hpoj, for instance), and this is a known bug nobody has fixed in portage. It was marked tested in spite of this. The new openmotif (might have been fixed, but was still bad when first marked tested) couldn't be linked against at all - try emerging nedit. It was marked tested.
It just goes to show that, no matter how big a community you have testing your software, if they're complete f#%^ing morons it doesn't help your case. pkgsrc and FBSD Ports have recently shown a MUCH better stability record, even using bleeding-edge software, and without these mysterious breakages and blockings.
I like Gentoo Portage since it gracefully lists what it will do and has USE and all, but sometimes it makes me want to break down and cry.
FreeBSD: Most engineering towards technology for corporations (hardcore SMP, GEOM, etc.)
NetBSD: Cleanest code of any system in existence, very portable (though not yet port/ed/ to all archs), very good performer on UP.
OpenBSD: Security you can bet your manhood on, and possibly the biggest advocate of openness and freedom (won't accept anything non-free for a minute longer than necessary).
DragonFlyBSD: Most innovative and outspoken, least real-world results to date;)
Define 'better'. I love vim, in its ease of use and power, but nvi has a MUCH smaller footprint in every way, and for some of the lower-end systems you may run on (applies more to NetBSD which fits on these systems, than FreeBSD) it's more than enough.
FreeBSD also boldly cater for newbies with ee (easy editor - don't confuse with electriceyes) which is very painful to use (at least compared to pico/nano) but also has a small-enough footprint to be worth keeping just for the broader audience.
At least you get tcsh, which has 90% of bash's features and some bash doesn't, and itself is very graceful and efficient. The other BSDs stick with csh, but anyone in their right mind installs their favorite shell from pkgsrc/ports within their first boot of a new system.
Personally what I think FreeBSD severely LACKS is a CVSup functional equivalent (preferably in C, so as not to need ezm3 in the base too), which is necessary to fetch sources and ports trees in any successful way. NetBSD uses CVS AND has the client in the base package, so you don't have a chicken-egg problem getting pkgsrc.
Base systems get a lot of arguments surrounding them, but of all the BSDs I like FreeBSD's the most. It keeps up-to-date and relevant, and besides the CVSup dilemma it's enough to get a good system up with minimal fishing in ports.
DragonFly BSD's will be better once gcc 3.4 is the default and works for everything, which makes it more consistent. The rest of their work is good, like OpenBSD's new BSD-licensed replacements for GNU junk entering the base system.
It's Slashdot, items are classified by the audience most likely to care, and since there are more Linux users than BSD users (and we have no general 'FOSS' category), they want to offend the smallest portion of the population. Slash is all about politics, didn't you notice? The article is listed under BSD as well but retains its Linux: prefix.
Let's say you're starting a project to make an embedded device that should function as a router, with web and SSH access. 99.9% of the code is already out there.
You could use Linux (GPL), but it does not support your work yet. To write code for Linux (which is necessary) requires that it be under the GPL. This means you must distribute source with your device, or contribute it to the main project and let them do it. Either is a lot of work.
You could use Net or OpenBSD, and the BSD license means you don't have any obligation to distribute the necessary source, only not take away copyrights of the authors of the project. You don't even have to speak up about the software you use.
Apache (or something much lighter, if you know what you're doing) and OpenSS[HL] are fine already, so you don't need to worry about them.
If the resulting functionality is the same (and it will be if you're worth your weight in waffles as an engineer), which would you choose, a GPL product or a BSD product?
Politics and idealism have to stop somewhere. I respect the GPL's effort to keep things open and ultimately relieve the world of reverse engineering and such unecessary difficulties, but its stance on keeping things publicly available and advertised are way too generalized. A small adjustment to the license would make a big difference. Until that happens, there's always BSD.
It only just *got* SMP, and considering many are already using it without problems, it's done pretty well. Linux had memory leaks in stable releases just for burning CDs, which is much more pathetic than NetBSD 2 having 'anecdotal' memory leaks on only that guy's machine(s) in the whole world (since it's the first I've ever heard of it, and I check the mailing lists on a more than hourly basis). And those weren't just anecdotal, they were publicly confessed. What about the NFS bug in 2.6.8 that spawned a new release almost right away?
Even on Slashdot (and damnit, forgot what thread) there have been reports of bugs being in 2.6.9 which were NOT fixed in 2.6.10, and were showstoppers for some x86 rigs. At least one definitely had an official bug report. Hardly anecdotal.
It does, but you might not WANT to have a single process taking up more than one processor because of threads. The change is entirely trivial and not hard to do, but the flexibility allows you to share load on a per-process or close to per-thread basis, depending on this value.
But I agree it'd be saner to have the default be the number of processors, and if I read correctly this is the situation in -current right now.
I won't give the exact URL because the destination forum will die instantly from a Slashdotting, but here is a direct byte-for-byte quote of a friend of mine 'enjoying' the non-breaking nature of Linux/x86.
It was 2.6.0-test3 before PCMCIA worked without making my kernel panic.
2.6.5 worked most of the time, but had stability issues with APM and ALSA. Switching to ACPI fixed some of the problems, but made extra ones with USB.
2.6.7 also had bad stability issues for me.
2.6.9-rc4 is working just fine so far. It's not perfect... but its streets ahead of the earlier versions.
My only issue remaining now is a lack of vesafb support. For some reason, passing vga=788 gives me a black screen, where as 2.4 kernels give me an 800x600 console. My laptop uses some exotic Neomagic video chipset. It's never worked using 'neofb', but worked with vesafb right up to kernel 2.6.3, before dying in 2.6.5.
If it can't stay stable on x86, the other ports can only be worse by extrapolation. I've never heard (personally) of Linux 2.6 running on SGI MIPS machines, and in Gentoo Portage it's impossible to emerge a mainline kernel on MIPS without hacking about.
So where's your evidence? You have some of mine, and that was what I could get off the top of my head.
In name only. Read the errata and lists, it was to get it out into the open for testing, not for adoption by production environments (although some have done so very successfully).
I would argue that a stock Linux kernel given out with an unfortunate binary distribution wouldn't have features that do make a difference. Many skimp on things like local APICs (for interrupt routing), add on SMP (which is slower on UP), and root knows what else. He configured a Linux from scratch and would NOT have made it generic, since he knows what he's doing. He did NOT reconfigure the BSDs (save the essentials) and we all know how conservative their defaults are.
It wouldn't make all the difference, but it would mean NetBSD 2 would beat Linux better in the UP case, and would hopefully stink less in the IO case (but I repeat, that's something really weird, and it's boggling the mailing lists). FreeBSD would do better too, which it really needs to.
Just saying, someone who knows what they're doing for all systems should benchmark, not a Linux yuppie who decides the world needs another biased benchmark to decide not to use a BSD. But I'm not saying Linux isn't a marvel of performance (well, there's still eth1394 sucking, but nobody seems to care), it's just not as far ahead as this bench would 'indicate'.
Read the mailing lists. PTHREAD_CONCURRENCY was not set during this benchmark, making the extra CPU worse than useless. The benchmarker did not actually research any of the systems in any depth before releasing more 'definitive' evidence of their position in the food chain.
Sorry, that's just not true, it isn't uncommon for ports to break or be not well supported on NetBSD.
Where are your examples of this being common, then? You can't just make a claim like that without mailing list references where people say their kit isn't working and a developer says "yeah, netbsd broke support for that in , go run linux". If that is "not uncommon" then my ISP must have a transparent proxy filtering mailing list archives.
Entirely right, and some user-space optimization could have gotten the final few percent in too. He installed stock BSDs and recompiled their kernels straight, didn't tweak any options that weren't necessary to run the suite, and compared to a Linux optimized from the ground up (Gentoo + his knowledge of Linux itself). Real clever benchmark.
That NetBSD performed worse than FreeBSD for disk IO is really strange. I have never seen this happen in any of the machines I've tried both on (hint: a lot), so either he has a very exotic disk controller which isn't supported properly (weird) or there's a disturbance in the force. Members of the mailing lists are talking it over with him now, and a follow-up should arrive eventually.
I would have liked to see results of FreeBSD 5-STABLE too, because he compared a refined Linux and a solid NetBSD to a FreeBSD release that was deemed not-ready-for-benching-let-alone-production on day 0, which gave it little chance. It's interesting to see if the claims 5.4 will be much better hold water.
NetBSD is the opposite of what you said. They do not port to a million new ones, in fact they're way behind Linux in new architectures (ia64, ppc64, HPPA,..), but they DO have solid support for the architectures they've covered. Even the Dreamcast port is highly usable. I'd do a little research before claiming it's not thorough in arch support - they have port-masters that must watch over their port and ensure things don't break, as a bare minimum.
Some archs missing is a bad thing, but they're on the TODO list and will work when they're done. On the other hand, NetBSD was ahead of Linux in some archs, amd64 being a fine example. And it was solid right away, too.
When will you people get over micro performance? Macro matters more when you're using the machine. And micro does not represent macro adequately.
I can vouch for his claim: NetBSD 2 on my Dell Latitude C800 is *very* fast, but not quite as fast on newer machines. Yes, that's actually possible. Linux is okay on the C800 and good on newer machines. There's an amount of accidental 'tuning' involved I can't adequately explain, but you can definitely see it.
OS performance is not about raw low-level numbers, they're way too complicated. If anyone claims notLinux is faster than Linux, people ask for numbers. If anyone claims Linux is faster than everything else, people are satisfied. Huge double standard.
What about NetBSD's internet land speed record? Macro performance at work. There are your numbers. HAND.
Can you have the same single source tree shared over NFS and have every architecture (or one cross-compilation) build for every machine on the network with any Linux distribution? Without needing any disparity in versions, and WITHOUT introducing bugs?
NetBSD's like that by design and it works. Source or binary. Hell, you can cross compile it from another operating system running on another architecture and it will still work. If there's a Linux distro out there that does it just as well (or 'better' because of that 'all the modern architectures' that 0.01% of the sysadmin population will get to look at in the next few years), well, I'd love to hear about it.
Oh. Well, sorry about that, if 32-bit instructions on Sparc64 are faster than 64-bit ones ("Yes faster"), then that's just really weird engineering. Memory/disk footprint is entirely understable on the other hand.
Is it the same for the 64-bit capable MIPS procs? (e.g. R5000 and up). Because many people are trying to get 64-bit free systems running on them but it's not certain to what advantage, since the machines rarely have more than 256MB RAM anyway.
NetBSD was ported to AMD64 so fast because it's clean codebase has been 64-bit on UltraSparc and Alpha for years. And that means the kernel and core userland all build consistently on 64-bit platforms. It's not just a kernel, ya know.
That's exactly my point. That's EXACTLY my point. In favor of NetBSD. What are you trying to say? "You're right, ya know (*snicker* idiot)"?
Linux sparc64 supports SMP just fine
I'm aware, that's why I said it's negative for NetBSD not to support it. I was hoping readers would post-process the post's words to get meaning out of them before responding.
And that's nice to know, but can Linux actually run 64-bit sparc binaries or not? That's the question.
Careful how you use 'run'. It can post some kernel messages. You'll be stuck using a light-weight C library which only supports a bare minimum of applications, possibly enough to write to a file using cat and redirection. 2MiB is not enough for anybody.
The simple answer is not to promote Linux. They are very unlikely to go back to the reliable development model. Why? It implies they are either high-tech or stable, but not both. Linux 2.6 right now is an okay blend (if it even compiles for you - some drivers still aren't quite right in the mainline kernel of 2.6.10) but things could easily get worse fast. I read the changelogs too, and I see a lot of things that look like amazing fixes, in amongst things that would be very lucky not to set your machine on fire.
Relevance to NetBSD? Not much. NetBSD has VERY gradual development in comparison to Linux, but considering it keeps up amazing stability and continued support for all hardware it ever supported, it's the thing to run on your production servers (and especially multi-architectured networks). The lack of uber SMP isn't important to companies smart enough to have clusters. It's explained very well in this (dated but relevant) post: http://mail-index.netbsd.org/netbsd-advocacy/1999/ 12/07/0009.html (skip ahead to the Xeon debunking).
Personally if I had an SMP box I'd run Linux. Maybe DragonFly BSD if it's an x86. Linux' greatest advantage is pretty much its SMP implementation, though you only start to see this on hard-to-afford N-way machines where N is significantly greater than 4.
Admittedly a single 4-way machine is much easier to manage than 4 UP machines, even if overall less efficient (well, depends on your networking capabilities).
Slashdot Mirror
That's the point of the portable copies: and they do get tested. If there's one thing we can trust OpenBSD for it's releasing solid software, even if not always in the kernel (at least from what I've heard).
http://linuxbugs.coverity.com/linuxbugs.htm
/ 0037.html
And we all know the changelogs don't have fixes for all of those at once, so there are still many left in 2.6.11.
Linux is buggier than you think. Factually (this is not trolling, shut the fuck up, the AC who keeps replying to me), NetBSD's bugs found with the same software: http://mail-index.netbsd.org/tech-kern/2005/02/23
No mention of Free or Open or DFly, but they should be somewhere in between, from the bug reports I've seen around.
Microsoft is not a real threat to BSD, since they don't really care about the end-luser market (as noted by some BSD advocates, the end-most of end users don't contribute code and most don't even donate funds, and so there's nothing tangible to gain from appealing to them). The server market IS where Linux, Solaris and the BSDs compete (I'm ignoring OSX at the moment, it's nowhere near free enough to count as a competitor), and the highest-end servers only run Linux and Solaris (right?), so BSD is only on the low->medium market... but the security and development model give it useful competition against Linux (which seems to be the highest performer).
:)
The BSDs compete in a productive way. They share code and designs where practical (unless something conflicts with philosophy or goals), and their constant benchmarking against each other forces each to adress their problems. Some harsh words get said and some personal arguments occur, and this has even caused forks, but that's typically a fact of life. It shows the developers have human personalities, not just senses of humor and coding abilities.
See? Bright side to everything
Did you even read my post? What the hell did I say that was incorrect and trolling? You need a really, really big chill pill. Or a lethal injection.
Grr @ HTML nature of Slashdot... the first line of that portage had "net-www/mozilla-firefox-1.0-r3 (from pkg media-libs/freetype-2.1.9-r1)" after a certain bracket I won't repeat.
Hint to Slashdot: Wake up, you can format things without needing HTML.
Gentoo plays dangerously with blockings and confusing dependencies, if you run 'tested' software only (and non-tested basically sets your machine on fire).
I have two examples. Firstly, when XFce 4.2.0 was just released, it was in Portage in a heartbeat. Some days later HALF of it was marked tested, and half was still untested (at least for x86). Since parts that were marked tested needed the untested ebuilds, they couldn't emerge; and since some other software (e.g. panel plugins) needed the older versions altogether, emerging them killed your newer versions (and hence your whole xfce4) and brought back older, incompatible ones.
While this is as much a failure of XFce for being such a disjointed piece of shit in the first place, Gentoo Portage falls way behind FreeBSD which Doesn't Care About Versions. Rightly so.
Second example, copy-n-paste:
[blocks B ] [ebuild U ] media-libs/freetype-2.1.9-r1 [2.1.5-r1] -bindist -debug -doc +zlib 969 kB
[ebuild U ] media-gfx/gimp-2.2.3 [2.0.4] -aalib (-altivec) -debug -doc +gimpprint +gtkhtml +jpeg +mmx -mng +png -python +sse -svg -tiff -wmf 13,486 kB
I can either have the new GIMP (2.2 was in the tree for one day buildable, then impossible to emerge without hacks for a month or so, now back as untested - even though every other package manager concedes that it is in fact very stable) and lose Firefox because a new freetype is needed, or keep the old GIMP and be able to use Firefox. Charming.
The worst example ever, is that even the tested ebuilds are often completely broken. libusb needs user intervention to work at all (try to emerge hpoj, for instance), and this is a known bug nobody has fixed in portage. It was marked tested in spite of this. The new openmotif (might have been fixed, but was still bad when first marked tested) couldn't be linked against at all - try emerging nedit. It was marked tested.
It just goes to show that, no matter how big a community you have testing your software, if they're complete f#%^ing morons it doesn't help your case. pkgsrc and FBSD Ports have recently shown a MUCH better stability record, even using bleeding-edge software, and without these mysterious breakages and blockings.
I like Gentoo Portage since it gracefully lists what it will do and has USE and all, but sometimes it makes me want to break down and cry.
FreeBSD: Most engineering towards technology for corporations (hardcore SMP, GEOM, etc.) ;)
NetBSD: Cleanest code of any system in existence, very portable (though not yet port/ed/ to all archs), very good performer on UP.
OpenBSD: Security you can bet your manhood on, and possibly the biggest advocate of openness and freedom (won't accept anything non-free for a minute longer than necessary).
DragonFlyBSD: Most innovative and outspoken, least real-world results to date
Define 'better'. I love vim, in its ease of use and power, but nvi has a MUCH smaller footprint in every way, and for some of the lower-end systems you may run on (applies more to NetBSD which fits on these systems, than FreeBSD) it's more than enough.
FreeBSD also boldly cater for newbies with ee (easy editor - don't confuse with electriceyes) which is very painful to use (at least compared to pico/nano) but also has a small-enough footprint to be worth keeping just for the broader audience.
At least you get tcsh, which has 90% of bash's features and some bash doesn't, and itself is very graceful and efficient. The other BSDs stick with csh, but anyone in their right mind installs their favorite shell from pkgsrc/ports within their first boot of a new system.
Personally what I think FreeBSD severely LACKS is a CVSup functional equivalent (preferably in C, so as not to need ezm3 in the base too), which is necessary to fetch sources and ports trees in any successful way. NetBSD uses CVS AND has the client in the base package, so you don't have a chicken-egg problem getting pkgsrc.
Base systems get a lot of arguments surrounding them, but of all the BSDs I like FreeBSD's the most. It keeps up-to-date and relevant, and besides the CVSup dilemma it's enough to get a good system up with minimal fishing in ports.
DragonFly BSD's will be better once gcc 3.4 is the default and works for everything, which makes it more consistent. The rest of their work is good, like OpenBSD's new BSD-licensed replacements for GNU junk entering the base system.
It's Slashdot, items are classified by the audience most likely to care, and since there are more Linux users than BSD users (and we have no general 'FOSS' category), they want to offend the smallest portion of the population. Slash is all about politics, didn't you notice? The article is listed under BSD as well but retains its Linux: prefix.
Let's say you're starting a project to make an embedded device that should function as a router, with web and SSH access. 99.9% of the code is already out there.
You could use Linux (GPL), but it does not support your work yet. To write code for Linux (which is necessary) requires that it be under the GPL. This means you must distribute source with your device, or contribute it to the main project and let them do it. Either is a lot of work.
You could use Net or OpenBSD, and the BSD license means you don't have any obligation to distribute the necessary source, only not take away copyrights of the authors of the project. You don't even have to speak up about the software you use.
Apache (or something much lighter, if you know what you're doing) and OpenSS[HL] are fine already, so you don't need to worry about them.
If the resulting functionality is the same (and it will be if you're worth your weight in waffles as an engineer), which would you choose, a GPL product or a BSD product?
Politics and idealism have to stop somewhere. I respect the GPL's effort to keep things open and ultimately relieve the world of reverse engineering and such unecessary difficulties, but its stance on keeping things publicly available and advertised are way too generalized. A small adjustment to the license would make a big difference. Until that happens, there's always BSD.
It only just *got* SMP, and considering many are already using it without problems, it's done pretty well. Linux had memory leaks in stable releases just for burning CDs, which is much more pathetic than NetBSD 2 having 'anecdotal' memory leaks on only that guy's machine(s) in the whole world (since it's the first I've ever heard of it, and I check the mailing lists on a more than hourly basis). And those weren't just anecdotal, they were publicly confessed. What about the NFS bug in 2.6.8 that spawned a new release almost right away?
Even on Slashdot (and damnit, forgot what thread) there have been reports of bugs being in 2.6.9 which were NOT fixed in 2.6.10, and were showstoppers for some x86 rigs. At least one definitely had an official bug report. Hardly anecdotal.
It does, but you might not WANT to have a single process taking up more than one processor because of threads. The change is entirely trivial and not hard to do, but the flexibility allows you to share load on a per-process or close to per-thread basis, depending on this value.
But I agree it'd be saner to have the default be the number of processors, and if I read correctly this is the situation in -current right now.
If it can't stay stable on x86, the other ports can only be worse by extrapolation. I've never heard (personally) of Linux 2.6 running on SGI MIPS machines, and in Gentoo Portage it's impossible to emerge a mainline kernel on MIPS without hacking about.
So where's your evidence? You have some of mine, and that was what I could get off the top of my head.
In name only. Read the errata and lists, it was to get it out into the open for testing, not for adoption by production environments (although some have done so very successfully).
I would argue that a stock Linux kernel given out with an unfortunate binary distribution wouldn't have features that do make a difference. Many skimp on things like local APICs (for interrupt routing), add on SMP (which is slower on UP), and root knows what else. He configured a Linux from scratch and would NOT have made it generic, since he knows what he's doing. He did NOT reconfigure the BSDs (save the essentials) and we all know how conservative their defaults are.
It wouldn't make all the difference, but it would mean NetBSD 2 would beat Linux better in the UP case, and would hopefully stink less in the IO case (but I repeat, that's something really weird, and it's boggling the mailing lists). FreeBSD would do better too, which it really needs to.
Just saying, someone who knows what they're doing for all systems should benchmark, not a Linux yuppie who decides the world needs another biased benchmark to decide not to use a BSD. But I'm not saying Linux isn't a marvel of performance (well, there's still eth1394 sucking, but nobody seems to care), it's just not as far ahead as this bench would 'indicate'.
Damnit. "netbsd broke support for that in [this *stable* version], go run linux". I never get used to the HTML obsession of Slashdot.
Read the mailing lists. PTHREAD_CONCURRENCY was not set during this benchmark, making the extra CPU worse than useless. The benchmarker did not actually research any of the systems in any depth before releasing more 'definitive' evidence of their position in the food chain.
Sorry, that's just not true, it isn't uncommon for ports to break or be not well supported on NetBSD.
Where are your examples of this being common, then? You can't just make a claim like that without mailing list references where people say their kit isn't working and a developer says "yeah, netbsd broke support for that in , go run linux". If that is "not uncommon" then my ISP must have a transparent proxy filtering mailing list archives.
Entirely right, and some user-space optimization could have gotten the final few percent in too. He installed stock BSDs and recompiled their kernels straight, didn't tweak any options that weren't necessary to run the suite, and compared to a Linux optimized from the ground up (Gentoo + his knowledge of Linux itself). Real clever benchmark.
That NetBSD performed worse than FreeBSD for disk IO is really strange. I have never seen this happen in any of the machines I've tried both on (hint: a lot), so either he has a very exotic disk controller which isn't supported properly (weird) or there's a disturbance in the force. Members of the mailing lists are talking it over with him now, and a follow-up should arrive eventually.
I would have liked to see results of FreeBSD 5-STABLE too, because he compared a refined Linux and a solid NetBSD to a FreeBSD release that was deemed not-ready-for-benching-let-alone-production on day 0, which gave it little chance. It's interesting to see if the claims 5.4 will be much better hold water.
NetBSD is the opposite of what you said. They do not port to a million new ones, in fact they're way behind Linux in new architectures (ia64, ppc64, HPPA, ..), but they DO have solid support for the architectures they've covered. Even the Dreamcast port is highly usable. I'd do a little research before claiming it's not thorough in arch support - they have port-masters that must watch over their port and ensure things don't break, as a bare minimum.
Some archs missing is a bad thing, but they're on the TODO list and will work when they're done. On the other hand, NetBSD was ahead of Linux in some archs, amd64 being a fine example. And it was solid right away, too.
When will you people get over micro performance? Macro matters more when you're using the machine. And micro does not represent macro adequately.
I can vouch for his claim: NetBSD 2 on my Dell Latitude C800 is *very* fast, but not quite as fast on newer machines. Yes, that's actually possible. Linux is okay on the C800 and good on newer machines. There's an amount of accidental 'tuning' involved I can't adequately explain, but you can definitely see it.
OS performance is not about raw low-level numbers, they're way too complicated. If anyone claims notLinux is faster than Linux, people ask for numbers. If anyone claims Linux is faster than everything else, people are satisfied. Huge double standard.
What about NetBSD's internet land speed record? Macro performance at work. There are your numbers. HAND.
Can you have the same single source tree shared over NFS and have every architecture (or one cross-compilation) build for every machine on the network with any Linux distribution? Without needing any disparity in versions, and WITHOUT introducing bugs?
NetBSD's like that by design and it works. Source or binary. Hell, you can cross compile it from another operating system running on another architecture and it will still work. If there's a Linux distro out there that does it just as well (or 'better' because of that 'all the modern architectures' that 0.01% of the sysadmin population will get to look at in the next few years), well, I'd love to hear about it.
Oh. Well, sorry about that, if 32-bit instructions on Sparc64 are faster than 64-bit ones ("Yes faster"), then that's just really weird engineering. Memory/disk footprint is entirely understable on the other hand.
Is it the same for the 64-bit capable MIPS procs? (e.g. R5000 and up). Because many people are trying to get 64-bit free systems running on them but it's not certain to what advantage, since the machines rarely have more than 256MB RAM anyway.
NetBSD was ported to AMD64 so fast because it's clean codebase has been 64-bit on UltraSparc and Alpha for years. And that means the kernel and core userland all build consistently on 64-bit platforms. It's not just a kernel, ya know.
That's exactly my point. That's EXACTLY my point. In favor of NetBSD. What are you trying to say? "You're right, ya know (*snicker* idiot)"?
Linux sparc64 supports SMP just fine
I'm aware, that's why I said it's negative for NetBSD not to support it. I was hoping readers would post-process the post's words to get meaning out of them before responding.
And that's nice to know, but can Linux actually run 64-bit sparc binaries or not? That's the question.
Careful how you use 'run'. It can post some kernel messages. You'll be stuck using a light-weight C library which only supports a bare minimum of applications, possibly enough to write to a file using cat and redirection. 2MiB is not enough for anybody.
The simple answer is not to promote Linux. They are very unlikely to go back to the reliable development model. Why? It implies they are either high-tech or stable, but not both. Linux 2.6 right now is an okay blend (if it even compiles for you - some drivers still aren't quite right in the mainline kernel of 2.6.10) but things could easily get worse fast. I read the changelogs too, and I see a lot of things that look like amazing fixes, in amongst things that would be very lucky not to set your machine on fire.
/ 12/07/0009.html (skip ahead to the Xeon debunking).
Relevance to NetBSD? Not much. NetBSD has VERY gradual development in comparison to Linux, but considering it keeps up amazing stability and continued support for all hardware it ever supported, it's the thing to run on your production servers (and especially multi-architectured networks). The lack of uber SMP isn't important to companies smart enough to have clusters. It's explained very well in this (dated but relevant) post: http://mail-index.netbsd.org/netbsd-advocacy/1999
Personally if I had an SMP box I'd run Linux. Maybe DragonFly BSD if it's an x86. Linux' greatest advantage is pretty much its SMP implementation, though you only start to see this on hard-to-afford N-way machines where N is significantly greater than 4.
Admittedly a single 4-way machine is much easier to manage than 4 UP machines, even if overall less efficient (well, depends on your networking capabilities).