When did VMS take-over Windows? Which iteration? NT5 (2000/XP) or NT6 (Vista/Win7)? Or earlier?
Dave Cutler, the architect of VMS developed Windows NT. Lots of Windows NT kernel mode terminology - working sets, paged pools, IRQLs, IRPS and so come from VMS and were not present in 16 bit Windows (which didn't really have any architecture).
If you take the next letter after V you get W, M you get N and S you get T, so W(indows)NT is a successor to VMS. The Windows NT kernel run on Dec's preferred Mips architecture (and later the Dec Alpha) before it run on x86. Much of the development of 64 bit Windows was done on Alpha.
Actually before Cutler worked on Windows NT at Microsoft he worked on a project to run Unix and VMS binaries on a single kernel in separate subsystems. Orignally Windows NT supported Win32, Posix, OS/2 and Win16+Dos subsystems, though Win32 obviously ended up being by far the most important. In fact Windows NT was originally so CPU agnostic that it run Win16 and Dos applications using a software emulator on Risc chips before it run them using V86 mode on x86.
Oh, and the A8 goes up to 1GHz. Things like Freescale's i.MX515 ship at this speed. The A9 is designed to scale up to 2GHz. The Snapdraggon is quite a nice A8 implementation, but it's not particularly exceptional.
The Snapdragon is not an A8 implementation - it's a custom implementation of the ARMv7 instruction set. Implemented on the same process as n A8 it will run at a 50% faster clock speed and running at the same clock speed it will consume 50% less power.
Back in 2005, Qualcomm announced that it had licensed the ARMv7 instruction set architecture and was working with ARM to create its own high-performance core based on that architecture. The new core was dubbed "Scorpion," and at the time it was announced, Qualcomm didn't disclose much about it except that it would run at 1 GHz in a 65 nm process and would be customized to provide a high level of performance and energy efficiency in its target mobile applications. Exactly how this combination would be achieved was not revealed, which is typical of Qualcomm; historically, the company has disclosed few details about the processor cores that live inside its chips.
Then in 2006, Qualcomm announced a new chip platform, "Snapdragon," in which the Scorpion core would be used alongside several other processors and co-processors. According to Qualcomm, Snapdragon will serve a range of high-performance mobile applications, such as high-end smartphones and mobile internet devices. Still, there was little information about the Scorpion core itself.
In conference presentations this year, however, Qualcomm popped the hood on the Scorpion core and presented a detailed description of the core's microarchitecture and implementation. The Scorpion core is similar to ARM’s Cortex-A8, which also implements the ARMv7 architecture. Like the Cortex-A8, Scorpion is a superscalar, dual-issue machine, and supports the powerful, signal-processing-oriented NEON instruction set extensions and VFPv3 floating-point extensions (referred to collectively on Scorpion as the "VeNum" media processing engine). Scorpion will be supported by ARM's standard software development tools, and Qualcomm expects to offer off-the-shelf multimedia codec software that uses VeNum.
Although Scorpion and Cortex-A8 have many similarities, based on the information released by Qualcomm, the two cores differ in a number of interesting ways. For example, while the Scorpion and Cortex-A8 NEON implementations execute the same SIMD-style instructions, Scorpion's implementation can process128 bits of data in parallel, compared to 64 bits on Cortex-A8. Half of Scorpion's SIMD data path can be shut down to conserve power. Scorpion's pipeline is deeper: It has a 13-stage load/store pipeline and two integer pipelines—one of which is 10 stages and can perform simple arithmetic operations (such as adds and subtracts) while the other is 12 stages and can perform both simple and more complex arithmetic, like MACs. Scorpion also has a 23-stage floating-point/SIMD pipeline, and unlike on Cortex-A8, VFPv3 operations are pipelined. Scorpion uses a number of other microarchitectural tweaks that are intended to either boost speed or reduce power consumption. (Scorpion's architects previously designed low-power, high-performance processors for IBM.) The core supports multiple clock and voltage domains to enable additional power savings.
In addition to developing a custom microarchitecture, Qualcomm also customized the core's circuit design and layout in an effort to improve energy efficiency.
Overall, Qualcomm has made a huge investment in creating a custom implementation of the ARMv7 architecture. By way of comparison, Texas Instruments customized just the
Yup. I think the best way to do this would be to have a compiler that works in two passes - the first one would turn C into some intermediate format and would be run on the developer's machine, the second would turn that intermediate code into native code and then link it.
Of course for this to work there would need to be a NT 4.0 like similarity between the processor platforms. In the world of NT 4.0 all supported processors were 32 bit, all are little endian and all had the same alignment rules for structures. The same API existed across all platforms and all the types had the same sizes. Of course it is possible to force unaligned data, and in that case the Risc chips would fault, but NT 4.0 installed an alignment fixup handler to let the code run - albeit much more slowly - if they did this.
So Win16 code could be ported with a bit of work to Win32 and once ported it was trivial to cross compile. Still in practice no one bothered because 99.9% of the users had x86.
Still if the Risc chips had taken over, the NT 4.0 approach would probably have worked quite well. In fact now with x64 taking over this approach works quite well now. The current Windows API is cunningly defined to be portable between x64 and x86 you follow the rules you produce code which will build for x86 and x64. Your code will build for Itanium too - the only things that change size are pointer sized ones.
Now in the world of free software it's not like this - alignment, endianess structure packing rules and so on all vary. It's not standard on Unix to fixup alignment faults transparently. There are multiple library versions around on different distributions. So if you had an executable in some intermediate format there would be no way to know it would work once it was turned into native code on your system unless the developer had tested it. If he had tested it, he might was well give you the native binary for your system. If he hadn't you need to get the source code and port it.
Actually if Qualcomm has their way all the smartphones will be running a Qualcomm Snapdragon with a Qualcomm Scorpion CPU, their superpipelined version of the Cortex A9.
A Snapdragon should run at 1 GHz (Cortext A9 is 600 MHz on a comparable process), from what I've read the A5 will be 480 MHz on a 40nm process.
So the A5 is aimed at cheaper devices than the Snapdragon. Of course the A5/A9 are presumably available to all ARM licensees whereas the Snapdragon is as far as I can tell only going to be manufactured by Qualcomm.
I've played around with an Atom based machine with 2Gb of Ram and a 160GB drive and Win7 which is relatively efficient compared to Vista. Still it was not a fast device and frankly not the sort of machine I'd buy.
I can't see how people can think this sort class of machine has the spare horsepower to run a JIT compiler - It's dog slow even with the code being executed natively for bloated modern applications.
I hope ARM beats x86 merely because x86 is an ancient technology that has a pile of limitations preventing the industry from moving forward as fast as it otherwise might. Previous attempts to move away from x86 failed due to the absence of software to run on the new machines. It's all fine and dandy if Microsoft write NT for the Dec Alpha and Itanium, but if there are no apps, it's pointless.
Actually there is a way for this to work. Microsoft ports Windows to Arm. Most of the time the processor is in kernel mode so that makes a difference. Now running user mode code through an emulator which is basically a big switch statement will not deliver a decent performance level. Microsoft could port their Office applications to ARM.
ARM have actually quite some experience of running non native instruction sets - Jazelle is mode where the ARM runs 80% of Java byte code natively. Basically there is an extra pipeline stage that decodes Java byte code into native ARM instructions.
Now surprisingly this doesn't give particularly good performance
It's actually better to JIT the code. ARM have actually have a second generation produce that uses a mixture of Ahead or Time compilation to native code for the Java platform, DBX aka Jazelle for rarely used code and JIT for the hotspots that are executed frequently. In practice I'm told that you could get by with purely AOT for the platform and JIT for the rest, except that application startup will seem sluggish.
x86 Java VMs have to do this because there is no equivalent of Jazelle DBX there. Now ARM could do something similar for netbooks. Still that is not without problems. Notebook processors, whether x86 or ARM are optimized for power consumption, not performance. Notebooks are also very short of memory - you basically can't afford to keep both the native ARM code and the original x86 code in memory. Actually there isn't much disk space either.
So it's far from clear whether an ARM that can perform as fast as an Atom on native code - i.e. a faster processor that the fastest Cortex A9 - would be able to run x86 code as fast as an Atom. Given that the performance of an Atom running x86 code is pretty awful, that makes me wonder if you could sell them even if the battery life is much better. Even that is doubtful actually - Atom is pretty power efficient but current Atom chipsets are not. It's likely that Intel will fix that problem if Arm based notebooks start to become popular though. They'll cut the price of Atoms too. At that point ARM doesn't really have any advantage over x86.
Of course I say x86 but most x86 chips will be running x86-64 code by then. ARM doesn't have a 64 bit extension either.
> "We are planning to launch the universal charger internationally during the first half of 2010,' Aldo Liguori, spokesperson for Sony Ericsson told the BBC."
Wow. This must be one of those UN resolutions that are enforced by the USAF.
Maybe you don't install toolbars and the like? Toolbars are very invasive in Windows - many of them will install global hooks. This is a horrible technique where you load a DLL into every process in the system and that DLL can be installed as a WndProc for every Window. The idea is that you have a chance to look at all messages.
Now the problem with an upgrade in the presence of things like this is that probably a Windows hook can be made to work with 90% of applications when it is released. The other 10% will have some sort of issue. New applications will probably fare worse and a new OS will introduce all sorts of issues.
Actually I've got Google Desktop Search installed here and it looks like unlike the MSN and Yahoo toolbars it does not do this - I don't see any 'foreign' DLLs injected into a notepad process. These days the Microsoft DLLs are all signed code and every single DLL in the Notepad process has a Microsoft signature.
To demonstrate this approach, Turing proposes a test inspired by a party game known as the "Imitation Game," in which a man and a woman go into separate rooms, and guests try to tell them apart by writing a series of questions and reading the typewritten answers sent back. In this game, both the man and the woman aim to convince the guests that they are the other. Turing proposes recreating the game as follows:
We now ask the question, "What will happen when a machine takes the part of A in this game?" Will the interrogator decide wrongly as often when the game is played like this as he does when the game is played between a man and a woman? These questions replace our original, "Can machines think?"
So yes I'm sure he's a good manager/CEO, and I'm sure he's evil. Just like Hitler was a really strong leader, and also totally evil (sorry, Godwin, just using him as an example here).
Actually Hitler was a terrible leader. If you look at Nazi Germany as a corporation whose business was military expansion, Hitler was a very bad boss.
Both Rommel in North Africa and the leaders of Army Group centre lost because when they asked Hitler for permission to make a tactical withdrawal - warfare being all about manoeuvre and withdrawal is part of that - he refused. That lead to catastrophic defeats at El Alamein and Stalingrad. You can also argue that a less ideological approach to occupied Eastern Europe would have made it a productive part of the Reich. Given that the Reich was far behind the Allies at industrial production, that was very serious.
E.g. Rosenberg wanted the Germans to champion Ukrainian nationalism against the Russians, and also to attempt to either turn Russian POWs into Axis soldiers or conscript them into labour battalions. Hitler backed a policy of exterminating the Russian POWs and also effectively reducing the Ukrainians and other slavs to a slave race. This meant that industrial production was very low in Eastern Europe.
Basically Hitler was the boss from hell if you were Rosenberg or Rommel. In fact in company terms there were numerous attempts by the board (i.e. the Generals) to get rid of him as CEO, basically because people feared his micromanagement in areas he did not understand would destroy everything.
By not buying their programs. Or by powering off the computer when they crashed. Seriously back in the days where the OS was in Rom and you booted games off floppies and rebooted when you were done, protection didn't make an sense. Plus the in the 68K days there wasn't room for an MMU on chip. And privilege transitions (e.g. user to kernel) were prohibitively expensive for system calls, as was flushing the TLB on a context switch.
It's a different world from now where machines can be attacked from the internet by worms, malware, viruses and the like.
I can see that I am not the only deeply perverted Slashdotter here.
to pass through cracks by squeezing . iRobot calls the new technique "jamming."
Come on, they are just asking for it.
Although I think the best market for this is initially one populated by disgusting perverts (a larger market than anyone wants to admit) there is something incredibly terrifying about a military machine whose primary target is your asshole.
Imagine the horror. Somewhere in eastern Afghanistan there are men huddled in a cave fervently whispering. Talking not about smart missiles, bunker busters, and fuel bombs, but about smart AI blobs of fast moving jelly that get inside you and your death is one by your asshole exploding slowly through intense pressure deep in your bowels.
Between one of those horror blobs and 10 Navy Seals, I think I would choose death by Navy Seals instead.
And shitting yourself with fear just gives them an opportunity to STRIKE!
Slashdot Mirror
Brass Eye always seemed funnier than Jam.
> Uh you know that JC owns a FORD GT40, right?
Why would Jesus Christ need a supercar?
When did VMS take-over Windows? Which iteration? NT5 (2000/XP) or NT6 (Vista/Win7)? Or earlier?
Dave Cutler, the architect of VMS developed Windows NT. Lots of Windows NT kernel mode terminology - working sets, paged pools, IRQLs, IRPS and so come from VMS and were not present in 16 bit Windows (which didn't really have any architecture).
http://windowsitpro.com/Windows/Articles/ArticleID/4494/pg/2/2.html
If you take the next letter after V you get W, M you get N and S you get T, so W(indows)NT is a successor to VMS. The Windows NT kernel run on Dec's preferred Mips architecture (and later the Dec Alpha) before it run on x86. Much of the development of 64 bit Windows was done on Alpha.
Actually before Cutler worked on Windows NT at Microsoft he worked on a project to run Unix and VMS binaries on a single kernel in separate subsystems. Orignally Windows NT supported Win32, Posix, OS/2 and Win16+Dos subsystems, though Win32 obviously ended up being by far the most important. In fact Windows NT was originally so CPU agnostic that it run Win16 and Dos applications using a software emulator on Risc chips before it run them using V86 mode on x86.
Oh, and the A8 goes up to 1GHz. Things like Freescale's i.MX515 ship at this speed. The A9 is designed to scale up to 2GHz. The Snapdraggon is quite a nice A8 implementation, but it's not particularly exceptional.
The Snapdragon is not an A8 implementation - it's a custom implementation of the ARMv7 instruction set. Implemented on the same process as n A8 it will run at a 50% faster clock speed and running at the same clock speed it will consume 50% less power.
http://www.insidedsp.com/Articles/tabid/64/articleType/ArticleView/articleId/238/Qualcomm-Reveals-Details-on-Scorpion-Core.aspx
Back in 2005, Qualcomm announced that it had licensed the ARMv7 instruction set architecture and was working with ARM to create its own high-performance core based on that architecture. The new core was dubbed "Scorpion," and at the time it was announced, Qualcomm didn't disclose much about it except that it would run at 1 GHz in a 65 nm process and would be customized to provide a high level of performance and energy efficiency in its target mobile applications. Exactly how this combination would be achieved was not revealed, which is typical of Qualcomm; historically, the company has disclosed few details about the processor cores that live inside its chips.
Then in 2006, Qualcomm announced a new chip platform, "Snapdragon," in which the Scorpion core would be used alongside several other processors and co-processors. According to Qualcomm, Snapdragon will serve a range of high-performance mobile applications, such as high-end smartphones and mobile internet devices. Still, there was little information about the Scorpion core itself.
In conference presentations this year, however, Qualcomm popped the hood on the Scorpion core and presented a detailed description of the core's microarchitecture and implementation. The Scorpion core is similar to ARM’s Cortex-A8, which also implements the ARMv7 architecture. Like the Cortex-A8, Scorpion is a superscalar, dual-issue machine, and supports the powerful, signal-processing-oriented NEON instruction set extensions and VFPv3 floating-point extensions (referred to collectively on Scorpion as the "VeNum" media processing engine). Scorpion will be supported by ARM's standard software development tools, and Qualcomm expects to offer off-the-shelf multimedia codec software that uses VeNum.
Although Scorpion and Cortex-A8 have many similarities, based on the information released by Qualcomm, the two cores differ in a number of interesting ways. For example, while the Scorpion and Cortex-A8 NEON implementations execute the same SIMD-style instructions, Scorpion's implementation can process128 bits of data in parallel, compared to 64 bits on Cortex-A8. Half of Scorpion's SIMD data path can be shut down to conserve power. Scorpion's pipeline is deeper: It has a 13-stage load/store pipeline and two integer pipelines—one of which is 10 stages and can perform simple arithmetic operations (such as adds and subtracts) while the other is 12 stages and can perform both simple and more complex arithmetic, like MACs. Scorpion also has a 23-stage floating-point/SIMD pipeline, and unlike on Cortex-A8, VFPv3 operations are pipelined. Scorpion uses a number of other microarchitectural tweaks that are intended to either boost speed or reduce power consumption. (Scorpion's architects previously designed low-power, high-performance processors for IBM.) The core supports multiple clock and voltage domains to enable additional power savings.
In addition to developing a custom microarchitecture, Qualcomm also customized the core's circuit design and layout in an effort to improve energy efficiency.
Overall, Qualcomm has made a huge investment in creating a custom implementation of the ARMv7 architecture. By way of comparison, Texas Instruments customized just the
Yup. I think the best way to do this would be to have a compiler that works in two passes - the first one would turn C into some intermediate format and would be run on the developer's machine, the second would turn that intermediate code into native code and then link it.
Of course for this to work there would need to be a NT 4.0 like similarity between the processor platforms. In the world of NT 4.0 all supported processors were 32 bit, all are little endian and all had the same alignment rules for structures. The same API existed across all platforms and all the types had the same sizes. Of course it is possible to force unaligned data, and in that case the Risc chips would fault, but NT 4.0 installed an alignment fixup handler to let the code run - albeit much more slowly - if they did this.
So Win16 code could be ported with a bit of work to Win32 and once ported it was trivial to cross compile. Still in practice no one bothered because 99.9% of the users had x86.
Still if the Risc chips had taken over, the NT 4.0 approach would probably have worked quite well. In fact now with x64 taking over this approach works quite well now. The current Windows API is cunningly defined to be portable between x64 and x86 you follow the rules you produce code which will build for x86 and x64. Your code will build for Itanium too - the only things that change size are pointer sized ones.
Now in the world of free software it's not like this - alignment, endianess structure packing rules and so on all vary. It's not standard on Unix to fixup alignment faults transparently. There are multiple library versions around on different distributions. So if you had an executable in some intermediate format there would be no way to know it would work once it was turned into native code on your system unless the developer had tested it. If he had tested it, he might was well give you the native binary for your system. If he hadn't you need to get the source code and port it.
You could use Mono. Of course if you built C for CLR that would not hide differences in libraries as far as I can tell.
Or ANDF. Then again ANDF has never been used commercially and is owned by the OSF.
Nextstep isn't really gone, it just possessed MacOS and now it walks around in its body, a bit like VMS did to Windows.
Oops. The Snapdragon is a superpipeline Cortex A8. It's not really clear how an Cortex A9 would compare against a Snapdragon.
Actually if Qualcomm has their way all the smartphones will be running a Qualcomm Snapdragon with a Qualcomm Scorpion CPU, their superpipelined version of the Cortex A9.
A Snapdragon should run at 1 GHz (Cortext A9 is 600 MHz on a comparable process), from what I've read the A5 will be 480 MHz on a 40nm process.
So the A5 is aimed at cheaper devices than the Snapdragon. Of course the A5/A9 are presumably available to all ARM licensees whereas the Snapdragon is as far as I can tell only going to be manufactured by Qualcomm.
I've played around with an Atom based machine with 2Gb of Ram and a 160GB drive and Win7 which is relatively efficient compared to Vista. Still it was not a fast device and frankly not the sort of machine I'd buy.
I can't see how people can think this sort class of machine has the spare horsepower to run a JIT compiler - It's dog slow even with the code being executed natively for bloated modern applications.
I hope ARM beats x86 merely because x86 is an ancient technology that has a pile of limitations preventing the industry from moving forward as fast as it otherwise might. Previous attempts to move away from x86 failed due to the absence of software to run on the new machines. It's all fine and dandy if Microsoft write NT for the Dec Alpha and Itanium, but if there are no apps, it's pointless.
Actually there is a way for this to work. Microsoft ports Windows to Arm. Most of the time the processor is in kernel mode so that makes a difference. Now running user mode code through an emulator which is basically a big switch statement will not deliver a decent performance level. Microsoft could port their Office applications to ARM.
ARM have actually quite some experience of running non native instruction sets - Jazelle is mode where the ARM runs 80% of Java byte code natively. Basically there is an extra pipeline stage that decodes Java byte code into native ARM instructions.
Now surprisingly this doesn't give particularly good performance
http://weblogs.java.net/blog/mlam/archive/2007/02/when_is_softwar_1.html
It's actually better to JIT the code. ARM have actually have a second generation produce that uses a mixture of Ahead or Time compilation to native code for the Java platform, DBX aka Jazelle for rarely used code and JIT for the hotspots that are executed frequently. In practice I'm told that you could get by with purely AOT for the platform and JIT for the rest, except that application startup will seem sluggish.
x86 Java VMs have to do this because there is no equivalent of Jazelle DBX there. Now ARM could do something similar for netbooks. Still that is not without problems. Notebook processors, whether x86 or ARM are optimized for power consumption, not performance. Notebooks are also very short of memory - you basically can't afford to keep both the native ARM code and the original x86 code in memory. Actually there isn't much disk space either.
So it's far from clear whether an ARM that can perform as fast as an Atom on native code - i.e. a faster processor that the fastest Cortex A9 - would be able to run x86 code as fast as an Atom. Given that the performance of an Atom running x86 code is pretty awful, that makes me wonder if you could sell them even if the battery life is much better. Even that is doubtful actually - Atom is pretty power efficient but current Atom chipsets are not. It's likely that Intel will fix that problem if Arm based notebooks start to become popular though. They'll cut the price of Atoms too. At that point ARM doesn't really have any advantage over x86.
Of course I say x86 but most x86 chips will be running x86-64 code by then. ARM doesn't have a 64 bit extension either.
> "We are planning to launch the universal charger internationally during the first half of 2010,' Aldo Liguori, spokesperson for Sony Ericsson told the BBC."
Wow. This must be one of those UN resolutions that are enforced by the USAF.
Maybe you don't install toolbars and the like? Toolbars are very invasive in Windows - many of them will install global hooks. This is a horrible technique where you load a DLL into every process in the system and that DLL can be installed as a WndProc for every Window. The idea is that you have a chance to look at all messages.
http://msdn.microsoft.com/en-us/library/ms644990(VS.85).aspx
Now the problem with an upgrade in the presence of things like this is that probably a Windows hook can be made to work with 90% of applications when it is released. The other 10% will have some sort of issue. New applications will probably fare worse and a new OS will introduce all sorts of issues.
Actually I've got Google Desktop Search installed here and it looks like unlike the MSN and Yahoo toolbars it does not do this - I don't see any 'foreign' DLLs injected into a notepad process. These days the Microsoft DLLs are all signed code and every single DLL in the Notepad process has a Microsoft signature.
The original Turing Test was based on The Imitation Game where people try to convince someone they are the opposite gender.
http://en.wikipedia.org/wiki/Turing_test#Alan_Turing
To demonstrate this approach, Turing proposes a test inspired by a party game known as the "Imitation Game," in which a man and a woman go into separate rooms, and guests try to tell them apart by writing a series of questions and reading the typewritten answers sent back. In this game, both the man and the woman aim to convince the guests that they are the other. Turing proposes recreating the game as follows:
We now ask the question, "What will happen when a machine takes the part of A in this game?" Will the interrogator decide wrongly as often when the game is played like this as he does when the game is played between a man and a woman? These questions replace our original, "Can machines think?"
So yes I'm sure he's a good manager/CEO, and I'm sure he's evil. Just like Hitler was a really strong leader, and also totally evil (sorry, Godwin, just using him as an example here).
Actually Hitler was a terrible leader. If you look at Nazi Germany as a corporation whose business was military expansion, Hitler was a very bad boss.
Both Rommel in North Africa and the leaders of Army Group centre lost because when they asked Hitler for permission to make a tactical withdrawal - warfare being all about manoeuvre and withdrawal is part of that - he refused. That lead to catastrophic defeats at El Alamein and Stalingrad. You can also argue that a less ideological approach to occupied Eastern Europe would have made it a productive part of the Reich. Given that the Reich was far behind the Allies at industrial production, that was very serious.
E.g. Rosenberg wanted the Germans to champion Ukrainian nationalism against the Russians, and also to attempt to either turn Russian POWs into Axis soldiers or conscript them into labour battalions. Hitler backed a policy of exterminating the Russian POWs and also effectively reducing the Ukrainians and other slavs to a slave race. This meant that industrial production was very low in Eastern Europe.
Basically Hitler was the boss from hell if you were Rosenberg or Rommel. In fact in company terms there were numerous attempts by the board (i.e. the Generals) to get rid of him as CEO, basically because people feared his micromanagement in areas he did not understand would destroy everything.
I always thought this scenario was what really inspired "The Turing Test".
It's all fine and dandy until one of the hydraulic lines breaks and someone needs a new set of genitals.
Yeah, but your new genitals will have telepresence too.
By not buying their programs. Or by powering off the computer when they crashed. Seriously back in the days where the OS was in Rom and you booted games off floppies and rebooted when you were done, protection didn't make an sense. Plus the in the 68K days there wasn't room for an MMU on chip. And privilege transitions (e.g. user to kernel) were prohibitively expensive for system calls, as was flushing the TLB on a context switch.
It's a different world from now where machines can be attacked from the internet by worms, malware, viruses and the like.
There was a time when Windows was a niche product, after all (I was there, I remember), and will be again some day.
Ze Windows Reich vill last for ein thousand years!!!1
Let's get the nuclear war out of the way first, then we can work on the warp drive.
You'd also have to be living in a Universe with Star Trek physics.
I can see that I am not the only deeply perverted Slashdotter here.
Come on, they are just asking for it.
Although I think the best market for this is initially one populated by disgusting perverts (a larger market than anyone wants to admit) there is something incredibly terrifying about a military machine whose primary target is your asshole .
Imagine the horror. Somewhere in eastern Afghanistan there are men huddled in a cave fervently whispering. Talking not about smart missiles, bunker busters, and fuel bombs, but about smart AI blobs of fast moving jelly that get inside you and your death is one by your asshole exploding slowly through intense pressure deep in your bowels .
Between one of those horror blobs and 10 Navy Seals, I think I would choose death by Navy Seals instead.
And shitting yourself with fear just gives them an opportunity to STRIKE!
I think they should keep it away from Japanese school girls.
You don't need an MMU, you need careful programmers.
You are number 6!