If you've got a good color printer, you could get the (fairly large) images here and print those. Of course, you'd then owe Unisys $10,000, since they're in gifs...
The developers it would attract are already engaged in various Gnu projects and Linux development itself.
It doesn't matter much to me what people claim about their code if they can't prove it. If they can, more power to them. If they're nice people, they'll say what they did, if not, it can probably be figured out.
(Anyway, everyone with a brain knows NetBSD is better than FreeBSD and BSDOS put together.;^>)
Wakko Warner wrote: ..his original point, that the Mac OS sucks, is still valid.
Only in so far as all operating systems suck.
Nothing's good at everything, MacOS isn't good for what you want, that doesn't make it universally bad. Even in a web production company I know well, where everything's done in ASP and served on NT (the 17/6 server!), all three graphics guys use Photoshop on macs for a good reason. They're better for that.
Quibbling about an absolute that is inherently impossible is silly.
I wrote:Is this a compromise of the system behind hotmail or of the hotmail ASP itself? My guess would be the latter, ASP is good at making cute web pages, lousy at doing so with efficient code, worse at making them secure.
Hee hee... s/ASP/cgi/
So this just means it's lousy coding. No surprise there. cgi-bin's been a scary thing to have on your system for a long time.
Anonymous Coward writes How abouts some more information concerning the crack -- was it something unique to hotmail or a general flaw everyone needs to be concerned about? (I seriously doubt hotmail will be very forthcoming with this information.)
I agree. Why haven't I seen this on Bugtraq yet? I'll admit I've haven't been reading very closely, and Bt isn't really the right forum for that, but things like this usually hit the fan there about a week or so ahead of mainstream media (that counts/. these days).
Is this a compromise of the system behind hotmail or of the hotmail ASP itself? My guess would be the latter, ASP is good at making cute web pages, lousy at doing so with efficient code, worse at making them secure.
Btw, someone want to moderate up that (intelligent) AC comment?
Mr Donkey wrote: What I wanted out of switching to BSD is a more secure machine, so I decided to look into OpenBSD. The unsupported hardware I was talking about was multiprocessor i386 support in OpenBSD. (It really sucks not to be able to use the added processing power of a second CPU). I did not look into the other BSD's, cause the only reason I was looking at BSD as an alternative was security.
Although OpenBSD's undergone (and is undergowing) that much-lauded line-by-line security audit, all three others (Net, Free, and BSD/OS) benefit from the code kicked back into the base by that process.
FreeBSD, though it's perhaps a little less paranoically secure in a standard install, does perfectly good SMP and can easily be made even more secure than the standard OpenBSD install.
... and, not that I don't respect Jordan and his gang, I'd personally think you were cooler if you went to ftp.netbsd.org/pub/NetBSD/NetBSD-1.4. 1 and picked your architecture.
Just download the boot.fs file, dd it to a floppy, and do an ftp install.
I agree completely with Jordan, nothing could be easier! Oh, wait, I guess his way could be easier if you don't know how to use dd. But that's pretty basic in my book...:^>
Linux Network Address Translation is a really good explanation of what's available for Linux and how NAT works in general. (Or, at least, links to those things.)
I think the package offered at Linux IP NAT Forum is the one I tried to use. There's nothing wrong with it, but Linux's arp is inherently broken to my eye and it had become too great an irritation to make Linux do what I knew I could do in an hour in...
OpenBSD, using ipf and ipnat (the real and original way to do this, also available on Solaris, I believe).
[Warning, extremely off-topic, though this does relate to IP-on-Linux issues]
Madwand wrote: (NATs, which the Linux weenies renamed "IP Masquerading" for no good reason)
Erm, sort of.
Having just tried to set up a GW/FW on a RH 6.0 machine with two NICs, I can tell you that IP Masquerading in the full Linux sense != NAT (masquerading maps all internal IP addresses to the GW's IP address, which isn't really NATing at all - NAT lets you map addresses in both directions). There are, in fact, NAT patches for the kernel that you can compile in and which, to all appearances work fine. The control software for the one I used is ipnatadm and it's modeled on ipfwadm.
My problem wasn't with ipnatadm or with ipchains, however, it was with the fact that Linux's arp is basically broken (when compared with BSD 4.4 or System V arp) in that you can't arp a second IP address onto a MAC address physically in the machine (at least, not properly), which makes it hard to NAT. (Yes, I know I could have used a VIF and done the assignment of the IP to the MAC address through ifconfig, but then I would have had to do some kind of virtual NATing which none of the Linux NAT packages are capable of doing yet.)
The basic schtick is that I threw in the towel and went back to getting OpenBSD to cooperate with the SCSI card in the GW/FW machine.
I'd dig up some links for all this stuff, but I need to run to lunch. I'll try to come back and reply to my own message with urls after that.
Most of the sound effects you hear in video games come from commercial sound effect collections that one can buy (come on CD, usually).
You didn't really think that people played around with sound generators and such at every game development house, did you?
Good grief, that'd be a tremendous waste of time and effort.
So, no Ambrosia (probably) doesn't own the sound effects in most of its games, id doesn't own the shotgun/door/whatever sounds in Doom or Quake, Bungie doesn't own any (to the best of my knowledge) sounds in the Marathon series, etcetera.
Since Ambrosia folks seem to be watching this thread, you guys want to clear this up further?
Scott Francis[Mecham (sic) wrote: Avara 1.0.0 came out while I was in high school--and hasn't EVER been patched, cheated on, or broken in a major way.
Er, not sure what crack you're smoking, but I want some.
There is a wealth of bugs in Avara (player movement in close situations and polygon clipping through other polygons are to that jump right to mind), and it most certainly was cheated on - not within the game, but within the registration system.
In fact, that's the reason Juri ditched the whole project (too many people pirating, too few actually paying for the software), according to some things he and Andrew Welch said on (EFNet) IRC.
There was talk of a community-spawned Avara 2 which was mentioned for a while on avara.com, but the links have disappeared and I don't remember the url straight to the files (which could well not be there any more either), but I really doubt that'll ever happen. EFNet #avara still exists, but it relates to that game about as much as #marathon does to Bungie's Marathon these days, I imagine.
It's a pity, Avara is a really good game that lends itself well to network play by focusing on gameplay and dispensing with silly things like true-to-life graphics. Worked speedily on my 28.8 as Quake X does on a T1. (Yes, I registered, thank you very much.)
... and you weren't the only one to ask for an X11 port. It should be very feasible if Ambrosia and Juri were willing to let hold of the source code so someone could do it. Last I checked, though, Juri had a pretty bitter taste in his mouth about the whole affair, so one might be better off reverse-engineering the network code and writing one's own rendering engine (and one would almost have to do that anyway since one would be porting from MacOS QuickDraw to XLibs).
Not that I have anything against newbies in most contexts (excepting IRC and when they're on my systems, I guess), but having a user number below, oh, say, 10,000 would be a good start (you are... 22743). I guess that number has to keep increasing, though.
First, for those of you that haven't, go read the real story. This movie's a nice fiction, but it's just that. When you're done with that, you migth like to read this article (even if it is on Salon). I'm not sure I quite agree with all the negative things said in it, but it's a pretty good response piece.
Also, regarding the compass... if the group was actually moving south all day the second day and if they came back to the same log across the creek they'd seen the day before, it's quite possible that this is not because of any witchcraft but because of a perfectly natural phenomenon. There is a lot of lode stone in the back country of Maryland, Pennsylvannia, and West Virginia, which would make compasses pretty useless (when in close proximity to it). (Well, at least, there was at the time that Mason and Dixon put the southern border of Pennsylvania through.)
You'd think that this would be an effect that any outdoorsmen with half a clue would know about, but as others have noted, these three weren't portrayed as the sharpest knives in the cutlery tray. Still, if you're pretty clearly walking around in a circle, get a clue...
C'mon, for software companies to actually switch off your usage remotely, their software will have to open a port to receive the kill signal.
Gank that port at the firewall, problem solved. (Unless their software tries to connect on startup, in which case they end up in court for unfair and insecure practices anyway, so use something else.)
If you actually care about security, this is so very not an issue that it would blow your mind.
While this is certainly true, it is not inconceivable that the JVM could be made much faster, if it were taught to more intelligently optimize code. (Right now, it hardly does any optimization.)
That said, interpretted compilation will forever be slower. Nothing to do about that. It might be made workable, though (which Java really isn't, currently).
Swarthmore college (where I'm a sys admin for the cs dep't) is right now confronting exactly this issue.
A cracker broke into a student's Linux 2.0.34 machine in a dorm subnet (we presume he port scanned to find the machine, haven't quite tracked down from where yet), ran a sniffer with which he gained passwords to cc.swarthmore.edu (Digital Unix, school's official server, all student users have/usr/bin/nologin as their shell), sccs.swarthmore.edu (Linux 2.0.35, run by a student computer users' group, see this), and cs.swarthmore.edu (Sun Enterprise 450 running SunOS/Solaris 2.6, CS departments main server).
The details of the breakin are available if you want them (email me, be sure to prune out the NOSPAM part), but are less relevant here than our response. To date, that has been:
to lock up and check out the systems we know where effected
to (plan to) perform our own portscan of all the campus subnets (basically, one for each building) so we can find any other machines in promiscuous mode and warn users of other insecure OSes (sorry, but Linux 2.0.34 or earlier definitely qualfies as insecure... really, any Linux does)
to form a new users' group (or, really, a subset of the SCCS) with open and announce mailing lists for all students running some form of Unix on their dorm computers
to schedule a security seminar (run by the SCCS), to which all of the above group are strongly urged to come.
I'd be interested in hearing how other people have responded to similar situations, how it's worked, etcetera, and I'd be glad to discuss our own results. (It'd be nice if you could email me, though, digging through/. can be a pain, and it'd waste less bandwidth to post a compiled statement on the subject.)
A better comparison would be between LinuxPPC and Rhapsody^H^H^H^H^H^H^H^Hmacos X server.
MkLinux and mXs both run on the Mach microkernal, whereas LinuxPPC runs directly on the PPC chip. It is documentably 20% faster than either. So, no need to go out and test, it's already been tested.
I've run all three OSes (okay, fine, I used Rhapsody DR2, but they didn't change the Mach part between then and release) on my PPC 7500/150, and LinuxPPC is visibly the fastest. It's in use right now. As soon as NetBSD/macppc works reliably, it will (probably) beat LinuxPPC (in my esteem, anyway).
Well, Mac OS X = Rhapsody, which is essentially PowerPC OpenStep with a Mac interface and Mac software/technology compatability. Also, Mac OS X Server, the "rough cut" of Mac OS X is shipping, right now, in February.
I think you're the one who needs to get your facts straight.
MacOS X Server is no kind of rought cut, it is basically OpenStep with a macish interface, and will probably stick around long after run-of-the-mill MacOS X is released. It is a server operating system aimed at competing with WinNT, and priced accordingly (well, for Apple... other companies might try to undersell their competition).
MacOS X, on the other hand, is a subset of that OS. It will, of course, run on the 4.4 BSD kernel just as MXS does, but it will be a single user environment, not include kernel and command line access (except, maybe, through third party add-ons), and be aimed at competing with Win2000.
To say "MacOS X = Rhapsody" is blatantly incorrect, as Rhapsody is now MXS, and MX will be a somewhat wimpy, userland version thereof.
For reference, I ran Rhapsody DR2 for a while on my PowerMac 7500/150 and found it mighty sluggish when compared with LinuxPPC and even MkLinux (which also uses that silly run-on-top-of-the-Mach-microkernel thing). I hope to get a chance to try NetBSD/macppc some time soon, and expect it will be the best of the lot.
Slashdot Mirror
Anyone had a look at Rob's Karma lately?
Or Hemos's, for that matter?
Hrm...
(This is meant to be funny, kiddos...)
If you've got a good color printer, you could get the (fairly large) images here and print those. Of course, you'd then owe Unisys $10,000, since they're in gifs...
bugg wrote:
;^>
(err, i say freebsd but this applies to all OSes that come from BSD)
Nice save.
The developers it would attract are already engaged in various Gnu projects and Linux development itself.
;^>)
It doesn't matter much to me what people claim about their code if they can't prove it. If they can, more power to them. If they're nice people, they'll say what they did, if not, it can probably be figured out.
(Anyway, everyone with a brain knows NetBSD is better than FreeBSD and BSDOS put together.
(... please observe the smiley, kiddies.)
Wakko Warner wrote:
..his original point, that the Mac OS sucks, is still valid.
Only in so far as all operating systems suck.
Nothing's good at everything, MacOS isn't good for what you want, that doesn't make it universally bad. Even in a web production company I know well, where everything's done in ASP and served on NT (the 17/6 server!), all three graphics guys use Photoshop on macs for a good reason. They're better for that.
Quibbling about an absolute that is inherently impossible is silly.
Ah.
;^>
So that's why I couldn't read admin@hotmail.com's mailer error messages.
I wrote: Is this a compromise of the system behind hotmail or of the hotmail ASP itself? My guess would be the latter, ASP is good at making cute web pages, lousy at doing so with efficient code, worse at making them secure.
Hee hee... s/ASP/cgi/
So this just means it's lousy coding. No surprise there. cgi-bin's been a scary thing to have on your system for a long time.
Anonymous Coward writes
/. these days).
How abouts some more information concerning the crack -- was it something unique to hotmail or a general flaw everyone needs to be concerned about? (I seriously doubt hotmail will be very forthcoming with this information.)
I agree. Why haven't I seen this on Bugtraq yet? I'll admit I've haven't been reading very closely, and Bt isn't really the right forum for that, but things like this usually hit the fan there about a week or so ahead of mainstream media (that counts
Is this a compromise of the system behind hotmail or of the hotmail ASP itself? My guess would be the latter, ASP is good at making cute web pages, lousy at doing so with efficient code, worse at making them secure.
Btw, someone want to moderate up that (intelligent) AC comment?
Mr Donkey wrote:
What I wanted out of switching to BSD is a more secure machine, so I decided to look into OpenBSD. The unsupported hardware I was talking about was multiprocessor i386 support in OpenBSD. (It really sucks not to be able to use the added processing power of a second CPU). I did not look into the other BSD's, cause the only reason I was looking at BSD as an alternative was security.
Although OpenBSD's undergone (and is undergowing) that much-lauded line-by-line security audit, all three others (Net, Free, and BSD/OS) benefit from the code kicked back into the base by that process.
FreeBSD, though it's perhaps a little less paranoically secure in a standard install, does perfectly good SMP and can easily be made even more secure than the standard OpenBSD install.
Want proof? Go look at the FreeBSD Symmetric MultiProcessor Kernel, and this archive of the de-bsd-chat mailing list in which FreeBSD 3.1's SMP is described as outperforming that of SuSE 6.0's.
... and, not that I don't respect Jordan and his gang, I'd personally think you were cooler if you went to ftp.netbsd.org/pub/NetBSD/NetBSD-1.4. 1 and picked your architecture.
:^>
Just download the boot.fs file, dd it to a floppy, and do an ftp install.
I agree completely with Jordan, nothing could be easier! Oh, wait, I guess his way could be easier if you don't know how to use dd. But that's pretty basic in my book...
Mr Donkey wrote:
./ ../m pile/GENERIC macppc
/.?
It seems that linux has a wider hardware support base than BSD.
Hrm.
uriel:/usr/src/sys/arch 363$ ls -al
total 56
drwxrwxr-x 27 root wsrc 512 Aug 21 22:49
drwxrwxr-x 32 root wsrc 512 Aug 21 22:49
drwxrwxr-x 2 root wsrc 512 Aug 21 22:49 CVS/
-rw-rw-r-- 1 root wsrc 777 Mar 4 14:46 Makefile
drwxrwxr-x 15 root wsrc 512 Aug 21 22:49 alpha/
drwxrwxr-x 9 root wsrc 512 Aug 21 22:49 amiga/
drwxrwxr-x 21 root wsrc 512 Aug 21 22:49 arm32/
drwxrwxr-x 12 root wsrc 512 Aug 21 22:27 atari/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:27 bebox/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:49 hp300/
drwxrwxr-x 12 root wsrc 512 Aug 21 22:49 i386/
drwxrwxr-x 9 root wsrc 512 Aug 21 22:30 m68k/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:49 mac68k/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:31 macppc/
drwxrwxr-x 6 root wsrc 512 Aug 21 22:31 mips/
drwxrwxr-x 9 root wsrc 512 Aug 21 22:32 mvme68k/
drwxrwxr-x 8 root wsrc 512 Aug 21 22:49 newsmips/
drwxrwxr-x 9 root wsrc 512 Aug 21 22:32 next68k/
drwxrwxr-x 8 root wsrc 512 Aug 21 22:33 ofppc/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:49 pc532/
drwxrwxr-x 9 root wsrc 512 Aug 21 22:49 pica/
drwxrwxr-x 11 root wsrc 512 Aug 21 22:49 pmax/
drwxrwxr-x 6 root wsrc 512 Aug 21 22:49 powerpc/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:49 sparc/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:35 sparc64/
drwxrwxr-x 10 root wsrc 512 Aug 21 22:49 sun3/
drwxrwxr-x 16 root wsrc 512 Aug 21 22:36 vax/
drwxrwxr-x 11 root wsrc 512 Aug 21 22:49 x68k/
uriel:/usr/src/sys/arch 364$ uname -a
NetBSD uriel.eclipsed.net 1.4.1 NetBSD 1.4.1 (GENERIC) #1: Wed Aug 11 18:08:32 JST 1999 tsubai@mint.iri.co.jp:/usr/src/sys/arch/macppc/co
uriel:/usr/src/sys/arch 365$
Yeah. Linux has more hardware support. That's why it runs (usefully) on about three of those platforms.
I'm not flaming, I swear, nor am I asking to be flamed. I just wish folks would get their facts straight before saying stuff like the original post.
PS, since when does not work on
Linux Network Address Translation is a really good explanation of what's available for Linux and how NAT works in general. (Or, at least, links to those things.)
I think the package offered at Linux IP NAT Forum is the one I tried to use. There's nothing wrong with it, but Linux's arp is inherently broken to my eye and it had become too great an irritation to make Linux do what I knew I could do in an hour in...
OpenBSD, using ipf and ipnat (the real and original way to do this, also available on Solaris, I believe).
[Warning, extremely off-topic, though this does relate to IP-on-Linux issues]
Madwand wrote:
(NATs, which the Linux weenies renamed "IP Masquerading" for no good reason)
Erm, sort of.
Having just tried to set up a GW/FW on a RH 6.0 machine with two NICs, I can tell you that IP Masquerading in the full Linux sense != NAT (masquerading maps all internal IP addresses to the GW's IP address, which isn't really NATing at all - NAT lets you map addresses in both directions). There are, in fact, NAT patches for the kernel that you can compile in and which, to all appearances work fine. The control software for the one I used is ipnatadm and it's modeled on ipfwadm.
My problem wasn't with ipnatadm or with ipchains, however, it was with the fact that Linux's arp is basically broken (when compared with BSD 4.4 or System V arp) in that you can't arp a second IP address onto a MAC address physically in the machine (at least, not properly), which makes it hard to NAT. (Yes, I know I could have used a VIF and done the assignment of the IP to the MAC address through ifconfig, but then I would have had to do some kind of virtual NATing which none of the Linux NAT packages are capable of doing yet.)
The basic schtick is that I threw in the towel and went back to getting OpenBSD to cooperate with the SCSI card in the GW/FW machine.
I'd dig up some links for all this stuff, but I need to run to lunch. I'll try to come back and reply to my own message with urls after that.
Most of the sound effects you hear in video games come from commercial sound effect collections that one can buy (come on CD, usually).
You didn't really think that people played around with sound generators and such at every game development house, did you?
Good grief, that'd be a tremendous waste of time and effort.
So, no Ambrosia (probably) doesn't own the sound effects in most of its games, id doesn't own the shotgun/door/whatever sounds in Doom or Quake, Bungie doesn't own any (to the best of my knowledge) sounds in the Marathon series, etcetera.
Since Ambrosia folks seem to be watching this thread, you guys want to clear this up further?
Scott Francis[Mecham (sic) wrote:
... and you weren't the only one to ask for an X11 port. It should be very feasible if Ambrosia and Juri were willing to let hold of the source code so someone could do it. Last I checked, though, Juri had a pretty bitter taste in his mouth about the whole affair, so one might be better off reverse-engineering the network code and writing one's own rendering engine (and one would almost have to do that anyway since one would be porting from MacOS QuickDraw to XLibs).
Avara 1.0.0 came out while I was in high school--and hasn't EVER been patched, cheated on, or broken in a major way.
Er, not sure what crack you're smoking, but I want some.
There is a wealth of bugs in Avara (player movement in close situations and polygon clipping through other polygons are to that jump right to mind), and it most certainly was cheated on - not within the game, but within the registration system.
In fact, that's the reason Juri ditched the whole project (too many people pirating, too few actually paying for the software), according to some things he and Andrew Welch said on (EFNet) IRC.
There was talk of a community-spawned Avara 2 which was mentioned for a while on avara.com, but the links have disappeared and I don't remember the url straight to the files (which could well not be there any more either), but I really doubt that'll ever happen. EFNet #avara still exists, but it relates to that game about as much as #marathon does to Bungie's Marathon these days, I imagine.
It's a pity, Avara is a really good game that lends itself well to network play by focusing on gameplay and dispensing with silly things like true-to-life graphics. Worked speedily on my 28.8 as Quake X does on a T1. (Yes, I registered, thank you very much.)
jetpack queried:
what do you consider !newbie ?
Not that I have anything against newbies in most contexts (excepting IRC and when they're on my systems, I guess), but having a user number below, oh, say, 10,000 would be a good start (you are... 22743). I guess that number has to keep increasing, though.
- gr (4059, not that it matters)
First, for those of you that haven't, go read the real story. This movie's a nice fiction, but it's just that. When you're done with that, you migth like to read this article (even if it is on Salon). I'm not sure I quite agree with all the negative things said in it, but it's a pretty good response piece.
Also, regarding the compass... if the group was actually moving south all day the second day and if they came back to the same log across the creek they'd seen the day before, it's quite possible that this is not because of any witchcraft but because of a perfectly natural phenomenon. There is a lot of lode stone in the back country of Maryland, Pennsylvannia, and West Virginia, which would make compasses pretty useless (when in close proximity to it). (Well, at least, there was at the time that Mason and Dixon put the southern border of Pennsylvania through.)
You'd think that this would be an effect that any outdoorsmen with half a clue would know about, but as others have noted, these three weren't portrayed as the sharpest knives in the cutlery tray. Still, if you're pretty clearly walking around in a circle, get a clue...
C'mon, for software companies to actually switch off your usage remotely, their software will have to open a port to receive the kill signal.
Gank that port at the firewall, problem solved. (Unless their software tries to connect on startup, in which case they end up in court for unfair and insecure practices anyway, so use something else.)
If you actually care about security, this is so very not an issue that it would blow your mind.
(You do have a firewall, right?)
Alternately, skip ftp entirely as an inherently insecure method.
ssh's own scp is a thing of beauty.
Beware of how scp2 and scp1 interact (or don't, rather), though.
~gr
That Java Virtual Machine's a beast.
While this is certainly true, it is not inconceivable that the JVM could be made much faster, if it were taught to more intelligently optimize code. (Right now, it hardly does any optimization.)
That said, interpretted compilation will forever be slower. Nothing to do about that. It might be made workable, though (which Java really isn't, currently).
A cracker broke into a student's Linux 2.0.34 machine in a dorm subnet (we presume he port scanned to find the machine, haven't quite tracked down from where yet), ran a sniffer with which he gained passwords to cc.swarthmore.edu (Digital Unix, school's official server, all student users have
The details of the breakin are available if you want them (email me, be sure to prune out the NOSPAM part), but are less relevant here than our response. To date, that has been:
- to lock up and check out the systems we know where effected
- to (plan to) perform our own portscan of all the campus subnets (basically, one for each building) so we can find any other machines in promiscuous mode and warn users of other insecure OSes (sorry, but Linux 2.0.34 or earlier definitely qualfies as insecure... really, any Linux does)
- to form a new users' group (or, really, a subset of the SCCS) with open and announce mailing lists for all students running some form of Unix on their dorm computers
- to schedule a security seminar (run by the SCCS), to which all of the above group are strongly urged to come.
I'd be interested in hearing how other people have responded to similar situations, how it's worked, etcetera, and I'd be glad to discuss our own results. (It'd be nice if you could email me, though, digging throughA better comparison would be between LinuxPPC and Rhapsody^H^H^H^H^H^H^H^Hmacos X server.
MkLinux and mXs both run on the Mach microkernal, whereas LinuxPPC runs directly on the PPC chip. It is documentably 20% faster than either. So, no need to go out and test, it's already been tested.
I've run all three OSes (okay, fine, I used Rhapsody DR2, but they didn't change the Mach part between then and release) on my PPC 7500/150, and LinuxPPC is visibly the fastest. It's in use right now. As soon as NetBSD/macppc works reliably, it will (probably) beat LinuxPPC (in my esteem, anyway).
Older power supplies tend to do this more.
/. needs a Beowulf cluster to serve really efficiently, right Rob?
Take my friend with his two Apple Lisae... raises the temperature in the room about five degrees when they're both running.
(Otoh, you don't really want to keep those things on for long, as replacement parts are scarce, but...)
I guess quantity would do the trick, though.
Well, Mac OS X = Rhapsody, which is essentially PowerPC OpenStep with a Mac interface and Mac software/technology compatability. Also, Mac OS X Server, the "rough cut" of Mac OS X is shipping, right now, in February.
I think you're the one who needs to get your facts straight.
MacOS X Server is no kind of rought cut, it is basically OpenStep with a macish interface, and will probably stick around long after run-of-the-mill MacOS X is released. It is a server operating system aimed at competing with WinNT, and priced accordingly (well, for Apple... other companies might try to undersell their competition).
MacOS X, on the other hand, is a subset of that OS. It will, of course, run on the 4.4 BSD kernel just as MXS does, but it will be a single user environment, not include kernel and command line access (except, maybe, through third party add-ons), and be aimed at competing with Win2000.
To say "MacOS X = Rhapsody" is blatantly incorrect, as Rhapsody is now MXS, and MX will be a somewhat wimpy, userland version thereof.
For reference, I ran Rhapsody DR2 for a while on my PowerMac 7500/150 and found it mighty sluggish when compared with LinuxPPC and even MkLinux (which also uses that silly run-on-top-of-the-Mach-microkernel thing). I hope to get a chance to try NetBSD/macppc some time soon, and expect it will be the best of the lot.