NT Server comes with a lot of server applications that Workstation doesn't come with. Sure, you can flip a switch to make it think it's a server, but that's not why the prices are different.
The kernel is actually Mach 3.0, a 'micro-kernel' architecture, which is also open source. BSD comes in the form of a compatibility layer on top of Mach.
The fuss is more about all of the other parts of the OS they are opening up, like HFS+ (Mac's second generation file system) and others.
There's two parts to their OpenGl support under X. One part gets loaded into the server as a module, the other part is a shared library that gets loaded into the application. The shared library then communicates with the X server to get things done.
The problem is that the two states are highly *correlated*, but you can't actually get any data without communication between the points (i.e. each side will get a random stream of data, but if they compare their data, they can see when it was correlated, and therefore whether spin coupling had happened at that point). Since you need to transmit some data in order to tell, this doesn't let you transfer information faster than c.
You can still run x86 code on the Merced. The IA-64 architecture has two compatibility modes:
1. A 32-bit operating system compatibility mode (basically, the Merced running as a Pentium). I'm not sure what the speed will be on this.
2. A way to execute all types (Real, virtual-86, and protected-mode) of 32-bit code under a 64-bit operating system (this is similar to Virtual-86 mode under a 32-bit OS)
You are correct in that the execution speed is halved, but there are two misconceptions in your reasoning:
1. The execution speed is only "halved" (i.e. half the parallel processors are doing something that will be thrown away) until the test completes executing. How long this is depends on the architecture. The way they do their speculative execution, they can keep more of the processor busy at any given time. Sure, you throw out a lot of your work, but you rarely have to start over. What kills execution time is pipeline stalls, which this avoids.
2. You seem to be implying that this is a bad thing. In a "perfect processor" it might be, since you have some execution units doing stuff that won't be used, but compared to other current architectures, this design is a win, since you avoid the problem of mis-predicted branches, which are expensive.
Compare what the IA-64 does to what the PI/PII/PIII do currently: The processor guesses which side of a branch it should take, and starts speculatively executing just that branch's instructions. When the test completes, either:
1. The prediction was correct, and everything moves along as normal
2. The prediction was incorrect, everything is thrown away, and it goes back to follow the other branch. This is very expensive. (on the order of 10-30 cycles, if I remember correctly. The whole pipeline has to be thrown away.)
There should not be any extra load from reverse ip'ing -- the IP address of the connection is available for free. The only addition is a write to a log file, which isn't very expensive.
Now, if he had to do a reverse-dns lookup, that would put extra load on the system.
You need to have "sky" effects set to "High quality" in order to see the destination of the teleporter in Q3test1. It's under System Configuration/Preferences.
This is not true -- most likely, the key is *not* kept on the disc, but at the company. If they are doing it right, when the box calls up the company to charge your credit card, the company sends back a message with the key to unlock the disk, encrypted so only that single player can get at the key (most likely using some form of Public key cryptography). The Blockbuster scheme will most likely be similar.
The point is, with the Blockbuster stuff, you have the encryption software running on *your* machine, so with the right tools you can intercept the unlocking key after it has been received from the server and decrypted by the program. With complete control of your system, all copy protection schemes must eventually fail, since the program has to decrypt the thing eventually.
Since DiVX is proprietary hardware, it is much harder to intercept the decryption information.
At least in the SF Bay Area, moviefone has no operators -- it's entirely computerized. And I'm sure they are doing *something* to prepare for the volume -- At a $1 "service charge" per ticket, they are going to want to get as many tickets sold as quickly as possible.
Just a couple of minor notes on this, in the hopes of lowering people who are not familiar with what is going on with MacOS X don't get confused:
The system puppybane is describing is MacOS X Server. This is why everything is very network-operator-oriented.
The lack of support of PowerBooks is also readily explained by the server emphasis.
One big thing currently missing is 3d accelerator support.
Another thing currently missing is support for VirtualPC under the Blue Box.
Most of the applications that come with MacOS X Server have OpenStep/NeXTSTEP UIs, which followed a different UI model than Macs.
I was a NeXTSTEP/Intel user, and I am *very* impressed with what Apple has done with the code it got from NeXT. Though it is still work-in-progress, they have merged the two interfaces better than I would have expected.
The bluebox (Mac OS 8.5 running as an application under MacOS X) is amazing -- IME, As long as you aren't hitting swap, most applications run faster and more reliably under the Bluebox than they do under vanilla MacOS.
MacOS X does support remote-hosted programs, but the remote host has to be running MacOS X, too. (actually, OpenStep and NeXTSTEP would probably work, too.)
There will be X servers for MacOS X. NeXTSTEP certainly had one.
As far as remote-hosted Windows, there's always VNC, which will let you view and interact with your Windows 95/98/NT (or Linux) box on another machine, be it Windows or Linux. It even has a client written as a Java applet. It doesn't support multiple logins or anything for Windows -- just interacting as if you were at the console. It is GPLed.
Slashdot Mirror
NT Server comes with a lot of server applications that Workstation doesn't come with. Sure, you can flip a switch to make it think it's a server, but that's not why the prices are different.
The kernel is actually Mach 3.0, a 'micro-kernel' architecture, which is also open source. BSD comes in the form of a compatibility layer on top of Mach.
The fuss is more about all of the other parts of the OS they are opening up, like HFS+ (Mac's second generation file system) and others.
There's two parts to their OpenGl support under X. One part gets loaded into the server as a module, the other part is a shared library that gets loaded into the application. The shared library then communicates with the X server to get things done.
The problem is that the two states are highly *correlated*, but you can't actually get any data without communication between the points (i.e. each side will get a random stream of data, but if they compare their data, they can see when it was correlated, and therefore whether spin coupling had happened at that point). Since you need to transmit some data in order to tell, this doesn't let you transfer information faster than c.
1) Backwards compatible with x86 for applications not OS. Interrupts serviced in IA64 only.
There is a x86-OS compatibility mode. How well it works remains to be seen.
You can still run x86 code on the Merced. The IA-64 architecture has two compatibility modes:
1. A 32-bit operating system compatibility mode (basically, the Merced running as a Pentium). I'm not sure what the speed will be on this.
2. A way to execute all types (Real, virtual-86, and protected-mode) of 32-bit code under a 64-bit operating system (this is similar to Virtual-86 mode under a 32-bit OS)
You are correct in that the execution speed is halved, but there are two misconceptions in your reasoning:
1. The execution speed is only "halved" (i.e. half the parallel processors are doing something that will be thrown away) until the test completes executing. How long this is depends on the architecture. The way they do their speculative execution, they can keep more of the processor busy at any given time. Sure, you throw out a lot of your work, but you rarely have to start over. What kills execution time is pipeline stalls, which this avoids.
2. You seem to be implying that this is a bad thing. In a "perfect processor" it might be, since you have some execution units doing stuff that won't be used, but compared to other current architectures, this design is a win, since you avoid the problem of mis-predicted branches, which are expensive.
Compare what the IA-64 does to what the PI/PII/PIII do currently: The processor guesses which side of a branch it should take, and starts speculatively executing just that branch's instructions. When the test completes, either:
1. The prediction was correct, and everything moves along as normal
2. The prediction was incorrect, everything is thrown away, and it goes back to follow the other branch. This is very expensive. (on the order of 10-30 cycles, if I remember correctly. The whole pipeline has to be thrown away.)
There should not be any extra load from reverse ip'ing -- the IP address of the connection is available for free. The only addition is a write to a log file, which isn't very expensive.
Now, if he had to do a reverse-dns lookup, that would put extra load on the system.
In my experience, Win NT runs *much* faster than 98 does under vmware, almost as fast as it does natively. 98 just sucks.
You need to have "sky" effects set to "High quality" in order to see the destination of the teleporter in Q3test1. It's under System Configuration/Preferences.
The AES is for a new symmetric encryption algorithm, to replace the tremendously outmoded DES. This has nothing to do with public key cryptography.
This is not true -- most likely, the key is *not* kept on the disc, but at the company. If they are doing it right, when the box calls up the company to charge your credit card, the company sends back a message with the key to unlock the disk, encrypted so only that single player can get at the key (most likely using some form of Public key cryptography). The Blockbuster scheme will most likely be similar.
The point is, with the Blockbuster stuff, you have the encryption software running on *your* machine, so with the right tools you can intercept the unlocking key after it has been received from the server and decrypted by the program. With complete control of your system, all copy protection schemes must eventually fail, since the program has to decrypt the thing eventually.
Since DiVX is proprietary hardware, it is much harder to intercept the decryption information.
The problem
It's alpha, and doesn't support their fastest redraw mode. It also has a tendancy to crash.
However, it is really cool to be able to use my Linux box's nice keyboard and mouse instead of the annoying hockey-puck and keyboard the G3 came with.
At least in the SF Bay Area, moviefone has no operators -- it's entirely computerized. And I'm sure they are doing *something* to prepare for the volume -- At a $1 "service charge" per ticket, they are going to want to get as many tickets sold as quickly as possible.
Just a couple of minor notes on this, in the hopes of lowering people who are not familiar with what is going on with MacOS X don't get confused:
- The system puppybane is describing is MacOS X Server. This is why everything is very network-operator-oriented.
- The lack of support of PowerBooks is also readily explained by the server emphasis.
- One big thing currently missing is 3d accelerator support.
- Another thing currently missing is support for VirtualPC under the Blue Box.
- Most of the applications that come with MacOS X Server have OpenStep/NeXTSTEP UIs, which followed a different UI model than Macs.
I was a NeXTSTEP/Intel user, and I am *very* impressed with what Apple has done with the code it got from NeXT. Though it is still work-in-progress, they have merged the two interfaces better than I would have expected.The bluebox (Mac OS 8.5 running as an application under MacOS X) is amazing -- IME, As long as you aren't hitting swap, most applications run faster and more reliably under the Bluebox than they do under vanilla MacOS.
MacOS X does support remote-hosted programs, but the remote host has to be running MacOS X, too. (actually, OpenStep and NeXTSTEP would probably work, too.)
There will be X servers for MacOS X. NeXTSTEP certainly had one.
As far as remote-hosted Windows, there's always VNC, which will let you view and interact with your Windows 95/98/NT (or Linux) box on another machine, be it Windows or Linux. It even has a client written as a Java applet. It doesn't support multiple logins or anything for Windows -- just interacting as if you were at the console. It is GPLed.