NetBSD-Current Gets SMP
MobyTurbo writes "NetBSD-current for the i386 architecture now has SMP. (It used to be that only FreeBSD had this feature among the free BSDs.) See the announcement
on the current-users mailing list."
← Back to Stories (view on slashdot.org)
When will the Dreamcast Port get it?
I really want to try this out on my quad-proc Dreamcast.
</sarcasm>
Arrogance is Confidence which lacks integrity. -- me
Finally OpenBSD will ahve some straight up competition. For a long time it has been the most secure, and the only BSD with SMP support. Now we will finally see the battle for BSD supremacy heating up!
Can't wait to see what FreeBSD does to top this!
call me crazy, but i could really care less about smp. i would wager the wide majority of smp systems fall into 2 categories:
1) unnecessarily powerful servers
2) unnecessarily powerful home braggart systems
database servers? sure. heavily loaded web servers? sure. file servers? NO. desktops? NO.
at least the scsi bigots will actually net some measurable performance increases if they drop some money on a 15k drive.
i sincerely hope openbsd continues to focus on OTHER things like openssh - you know, that thing you probably use every day of your life on your non-smp machine?. since most openbsd boxes are used as edge devices, the only big need for processing horespower is in crypto...
and that problem can be solved by purchasing a hifn-based pci crypto accellerator for $90 from soekris.com, thanks to openbsd's excellent hardware crypto accelerator support.
once you get past the crotch-grabbing aspect, low-end smp is not what most of the world would have you believe it is. high-end smp will likely get replaced by clustering of commodity hardware.
I wonder if this means OpenBSD will soon have SMP capability? Anyone have any thoughts? Inside information?
Co-founder and designer at Music Nearby: http://musicnearby.com
I guess it depends on what sort of enterprise application you are talking about. I am building a commercial router/content filtering system for corporations using NetBSD and am *very* happy with it.
NetBSD is small, robust, and fast. Creating customized installation media is a breeze and the networking code is fast (okay, I haven't benchmarked it against any of the 2.4 Linux kernels, but it *seems* faster). Hell, my full ISO to install NetBSD and all of the other supporting software is approximately 100MB, and that's with quite a bit of extra stuff thrown in, like the development tools, etc...
The one place that NetBSD needs some help is with the installation process ("you mean I need to know the geometry of my drive???!" and "what do you mean sshd isn't started by default from rc.conf???") but even that is easily overcome by creating simplified installation floppies.
As a recent convert to NetBSD (from FreeBSD from Linux), I have to say that I am very pleased with the NetBSD product... adding support for SMP can only make it better.
Actually, many embedded system developers use NetBSD for their eval boards and such.
Also, at least one major company has used NetBSD in the past -- DEC, for their DNARD ("shark") systems.
Note that while the i386 port just got SMP support, other ports have had it for a while. NetBSD/macppc got it in August, NetBSD/sparc got it over a year ago, etc.
Now BSD can die twice as fast!
(Note to moderators: Not a troll - just an sad attempt at humour. I'm writing this from my FreeBSD 4.6.2-RELEASE box...)
...but it's being eaten...by some...Linux or something...
At work I have a dual processor 'Windtunnel' Apple Mac running Mac OS X. Does this not count as SMP? Or have I misunderstood the term?
(Dawin is of course a flavour of BSD)
As for journaling filesystems, NetBSD, alone among the BSDs, already offers one; though I'm not sure how mature it is. (The 1.6 release notes say that it's more stable now.) However, soft updates offer many of the advantages of the additional stability journaling filesystems bring. The main reason why journaling filesystems are sutch a big deal on Linux is because ext2 is such an unstable file system, especially with asyncronous metadata, compared to the Berkeley Unix FFS BSD uses. If you don't have asyncronous metadata, yet have the rest asynronous, the whole advantage of redundant metadata storage disappears as I understand it. Of course, you don't have to fsck most of the time with a journaled filesystem; this is the only advantage remaining. In my mind though it is, in practice rather than as a brag, for important 24/7 servers to recover more fast after a power outage; but if you need that kind of availability you should have a power genererator or at least a UPS to deal with the power outage in the first place.
I assume you're joking, since Debian is non-profit. NetBSD is owned by the NetBSD foundation, it's also non-profit, though Wasabi and others do manage to run businesses based on it. (After all, it has the Abbie Hoffman of software licenses - the BSD license, "Steal This Code".Hmm... Time to scour off the netbsd-current@ mailinglists again for answers...
Um, even if your premises were solid, I'd still disagree with your conclusion. I think feature competition between Linux and BSD will more likely benefit both operating systems than harm either one.
I have to assume you're speaking facetiously in the voice of a Linux advocate, right? Because in the spirit of free software, people use what works best, and if that happens to be NetBSD instead of Linux, then so be it; there is nothing to be sad or worry over.
-- Never hit a man with glasses. Hit him with a baseball bat.
you still have io, memory, and chipset performance to improve or bog down your results
that aside, i'd love to see a single metric (really, just one) where a 1.2ghz p3 would get outperformed by 2 underclocked tualatin p3s (to make the competition fair - they'd blow the 600ebs away) on the exact same rig.
2x600mhz != 1.2ghz. it's more around 900mhz average, if you're lucky.