Just a few points... not to argue, really... of all the idiotic "My OS is bigger than yours" arguments you can have the ones between "BSD people" and "Linux people" are the worst, but...
my problem with GNU/Linux (and note that I'd LOVE to be wrong) is that it's very poorly supported on non-x86 and non-amd64 architectures. Sure, you can get distros which are a few years old, but how much time do you want to spend trying to figure out how to get x86-specific patches to work on PowerPC to get modern enough to get past security issues?
I wasn't suggesting they go out an install some "old version" of Linux. Debian is reasonably well maintained on PowerPC from all the evidence I can find on the subject and it has release parity with the x86 version.
(IE, Debian Lenny, 5.0.7, released 11/27/2010 supporting 12 architectures.)
To some extent your objection here comes across as FUD. I know Linux has this bad rep when it comes to non-x86 platforms, but the fact is that a Linux-kernel based OS is now outselling iOS in the ARM-based mobile phone market so they must be able to handle a little more than i386/x86-64 semi-competently. Debian worked fine on the last Sun box I tried it on, and I've also run a Debian variant on my R4400 Indy within the last five years or so. Linux works on non-x86 platforms, and while PPC Linux hasn't gotten much press recently (mostly because of the whithering on the vine of most of the remotely mainstream sources of PPC desktop and server hardware) PowerPC is still possibly the *best supported* non-x86 "big computer" architecture Linux runs on. So I think you're reaching a bit when it comes to the cross-platform-ability business.
Linux's biggest flaw in my opinion when it comes to the oddball platforms is in documentation. Linux "works" on a lot of things but actually getting it installed and bootstrapping is where you hit the wall on the weird stuff. NetBSD's installation documentation is a *lot* better, I won't deny that.
Gorgonops brings up some interesting points, but they're mostly moot - NetBSD has ways of doing things which are either painfully simple, but take more time (like building everything from source), or kind of brute force (download yesterday's entire OS build, which is typically less than 100 megs without X, and untargzip everything except etc.tgz, and the system is up to date)
And this is better than a system that does intelligent version checking automatically and downloads appropriate packages... how?
As far as paths being different from documentation, that's partly what drove me from GNU/Linux to NetBSD in the first place. Back in the day I had Red Hat (some version) on m68k on one machine, and the same version on an x86 box. Everything was peachy. The new version of Red Hat came out..
There's your problem, you're basing your opinion of Linux on Red Hat. Red Hat for all the numbered pre-Fedora/Enterprise split versions was always incredibly inconsistent, particularly when it came to the configuration directives stored in the /etc/sysconfig directory. It was really a horrid mess even in its last days. (And Fedora still is a horrid mess. Enterprise... could be worse.) But, as I'm sure you've heard before, a singular distribution is not "Linux".
Gorgonops - the starting and stopping daemons issue is easily fixed. In your /etc/mk.conf (which is where you set your pkgsrc base, too), just put "PKG_RCD_SCRIPTS=YES", and all of the rc.d scripts get installed automatically. Then, just edit /etc/rc.conf and put configuration options for each daemon. For instance, Apache's is nothing more complex than adding "apache=YES" to /etc/rc.conf. Starting and stopping is done by running /etc/rc.d/apache start or /etc/rc.d/apache stop (or restart, or reload, or status, or others).
I'm aware of how to work the rc.conf system in NetBSD. (It's essentially the same as FreeBSD's, which the bulk of my soul-scarring BSD experience since 2002 is with.) Perhaps I'm a little embittered from my experience back in the old days prior to that system being developed. 1.4 was still the "release" version when I started dealing with it, and it took *quite a while* before packages were fixed to work with system introduced with 1.5, which in many ways is a close copy of the System V init system that most Linux distributions newer than Slackware use. And should I fault NetBSD for being inconsistent for adopting something more elaborate than the BSD 4.4 system? It was a major *change*, after all, and there was a long period in which at least two completely different methods for starting and stopping services was in play. How Linux-y...
Anyway, my point was that there are scads of HOWTOs out there for getting a LAMP server running on the "L" part of the acronym. Is it simple enough to translate those instructions to NetBSD-ese? Sure, if you know NetBSD. The OP does not.
pkgsrc has gotten a lot betterregarding updates. Your best friend is pkg_rolling-replace. You can only really fault the naming scheme, if you ask me. To update all of your pkgsrc software to the latest, just cvs update your pkgsrc tree, then run pkg_rolling-replace -ru and let it run.
And wait a few days. And hope your system doesn't self-destruct its dumb self half way through it.
(And yes, that's me being old and embittered again. I just recall way too many incidents of having to fix people's machines (they were of course way too busy being ENGINEERS to do it themselves) in which a bulk pkgsrc build crashed after it'd de-installed half the software on their computer in a vain attempt to sort out dependencies. In my opinion the only safe way to compile packages on NetBSD is to do it in a chrooted environment, and if you're spending that much effort building packages you'd better be able to leverage that investment over a whole herd of machines. To maintain just one it's stupid busy work unless you have no other alternative.)
Maybe it works perfectly every time now. If it does, well, happy motoring.
Regarding SMP, New World SMP is supported and pretty well tested. ChristTrekker - you just need to get the MP kernel. However, Old World SMP is broken, and although I have a dual CPU 604e card, I haven't had time to do any testing myself. Sure, you can run GNU/Linux from 2006, but would you want to?
Again, where did I suggest they run Linux from 2006? (Pardon the length of this reply at this point, but this is the one thing I'm a little annoyed about... it seems like you're dying to put words into my mouth that I did *not* say. If the only source of Linux for PowerPCs was some creaky and completely abandoned 2006 version I wouldn't recommend it as an alternative.) I was just noting that the date on the blog post saying it worked was from 2006, and I have no way to test as to whether it works *now*. But unless something has changed which has *broke* it theres' no reason to presume it doesn't work on a modern kernel. You just said that Old World SMP is *definitely* broken on NetBSD, so... seems like it'd be worth at least *trying* Linux first, eh?
The bottom line is do you want to try to maintain an OS where everything non-x86 and non-amd64 is treated as second-class, or do you want to have an OS which is kept up to date for all architectures?
So, the "OS is kept up to date for all architectures", in the sense that the base packages all build out of the same source tree and they throw tarballs that boot on at least some machines of that architecture up on the ftp site, but it's *really* a stretch to imply that every architecture gets the same amount of "lovin'" on NetBSD. (Some of the ports seem to be pet projects maintained by literally one person.) I'm not sure how reassuring that really is in practice. And again, I think your allegations so far as they apply to PowerPC Linux are a little dirty-pool... it's not like we're discussing the best OS for something really ancient like an m68k Macintosh... the Linux community has clearly lost interest in some of those old dead platforms. PowerPC isn't there yet.
Anyway, this is all besides the point. My reasoning for suggesting Debian was *assuming the software installation went ok* (I don't know if it would or not, again, haven't touched a Beige PPC mac in the better part of a decade) Linux might be a better choice because:
A: Once the OS is installed and the machine has net access installing the software the OP wants to try will take about as long as it takes to download it;
B: There are oodles of HOWTOs out there describing how to set up the environment the OP wants on Debian-based Linux-i, so getting up and running wouldn't require the OP to exert much effort; and
C: There is at least a chance the second CPU in their DP machine might work.
If Debian turned out to be a complete faceplant fail, either because it won't work on the machine or because even with two CPUs the machine is too slow to do what they want then they haven't wasted anywhere near as much time as they might of if they'd started with NetBSD and subsequently hit a wall. (I figure a healthy way to approach a task like this is to see if the chainsaw will do the job before breaking your back swinging an axe or pulling a saw. Debian is the chainsaw approach to this. It's not "elegant", but if it works who cares?)
