In other words, there could be something nasty out there that hunts and destroys emerging civilizations.
Perhaps the reason there are no radio signals is that a paranoid civilization decided to launch a bunch of self-replicating planet killer probes. The civ may be long dead by now, but the probes continue to hunt for radio signals from potentially competing civilizations. When they find one, they kill it (with meteors or whatever) before it has a chance to develop interstellar spaceflight.
This is essentially the plot of Greg Bear's novels The Forge of God and Anvil of Stars. In the latter novel the surviving remnant of humanity takes revenge on the bastards' evolutionary descendants (with interesting ethical questions about justice and punishment for acts done billions of years earlier.)
The sciam article leaves out a fifth possibility as to why no extraterrestrial civiliations seems to be broadcasting strong radio signals: There is something nasty is out there that hunts and destroys emerging civilizations.
Consider the possibility that one rather paranoid civilization wants to make the galaxy "safe" for later colonization. So they release a bunch of self-replicating planet killer probes. The probes hunt for radio signals from potentially competing civilizations. When they find one, they kill it before it has a chance to develop interstellar spaceflight.
This is basically the plot of Greg Bear's novels The Forge of God and Anvil of Stars. We could be like a babe mewling in the forest, calling down the wolves upon us.
Define "Less Interesting Movie" (LIM') as an ordering relation. Assume that for every pair of movies m1 and m2, m1 LIM' m2 or m2 LIM' m1.
Because LIM' is a full ordering relation on a finite set, there is a Least Interesting Movie (LIM) called m0, such that m0 LIM' m for all m.
m0 is interesting. ("Heartbeeps"??)
Since our assumption in 2 leads to a contradiction, there is no LIM' ordering relation on m, and thus there is no such thing as the Least Interesting Movie.
The Most Insipid Movie (MIM) is another matter. "Heartbeeps"?? Yeah. Ack. Pfft.
Lurking in the shadows is a critical stumbling block for any attempt to make a "pure" emulator (100% non-Microsoft code): the redistributable DLLs that ship with applications. These include the C runtime sytem (MSVCRT.DLL), the Microsoft Foundation Classes (MFC42.DLL), and the OLE runtime system (OLE32.DLL, OLEAUT32.DLL). The license terms for these DLLs state explicitly that they may only be installed on Microsoft operating systems.
So any emulator has to reinvent these DLLs from scratch. And don't forget there are about 20+ versions of each one, and some apps run only with specific versions, i.e. DLL Hell.
This is why a pure emulator is never going to fly.
From reading their manifesto, it looks like they are trying to clone Windows 9x, not Windows NT. They talk about FAT, FAT32, real-mode drivers, and MS-DOS. There is no mention of NTFS, UNICODE, security, or WDM protected-mode drivers.
If this is true, the mind boggles. Let me see if I understand this. They want to clone an OS that has no security, no crash protection, and which (after Windows ME) Microsoft has declared there will be no follow-on versions. Is this right?
And they're throwing in a clone NDIS/TCP/Winsock stack, and OLE (the whole graphical nightmare, not just COM), and DOS support. Hey it's just an all-nighter right? Have they seen Ralf Brown's INT 21 list for DOS? It is the size of a phone book. And that's just for DOS. In short they aim to clone $10+ billion of bug-compatible legacy software created over 15+ years, basically from scratch.
Compare this to WINE, a serious emulation project with modest goals to emulate the Win32 API over Unix. They are working on the GDI, DirectX, DLL interception, security, etc. These people are working on genuine technical issues related to Windows compatiblity. Meanwhile the Open Windows guys are soliciting for snapshots of screen layouts that look cool.
It's like your kids building a sand castle and they say "this is going to be as big as your house Daddy!". You just have to smile and wish them luck.
Also during 1969, Thompson developed the game of `Space Travel.' First written on Multics, then transliterated into Fortran for GECOS (the operating system for the GE, later Honeywell, 635), it was nothing less than a simulation of the movement of the major bodies of the Solar System, with the player guiding a ship here and there, observing the scenery, and attempting to land on the various planets and moons. The GECOS version was unsatisfactory in two important respects: first, the display of the state of the game was jerky and hard to control because one had to type commands at it, and second, a game cost about $75 for CPU time on the big computer. It did not take long, therefore, for Thompson to find a little-used PDP-7 computer with an excellent display processor; the whole system was used as a Graphic-II terminal. He and I rewrote Space Travel to run on this machine. The undertaking was more ambitious than it might seem; because we disdained all existing software, we had to write a floating-point arithmetic package, the pointwise specification of the graphic characters for the display, and a debugging subsystem that continuously displayed the contents of typed-in locations in a corner of the screen. All this was written in assembly language for a cross-assembler that ran under GECOS and produced paper tapes to be carried to the PDP-7.
Space Travel, though it made a very attractive game, served mainly as an introduction to the clumsy technology of preparing programs for the PDP-7. Soon Thompson began implementing the paper file system (perhaps `chalk file system' would be more accurate) that had been designed earlier. A file system without a way to exercise it is a sterile proposition, so he proceeded to flesh it out with the other requirements for a working operating system, in particular the notion of processes. Then came a small set of user-level utilities: the means to copy, print, delete, and edit files, and of course a simple command interpreter (shell). Up to this time all the programs were written using GECOS and files were transferred to the PDP-7 on paper tape; but once an assembler was completed the system was able to support itself. Although it was not until well into 1970 that Brian Kernighan suggested the name `Unix,' in a somewhat treacherous pun on `Multics,' the operating system we know today was born.
I knew it.. the gamers always push the leading edge of technology.:-)
Gates repeatedly alluded to "per-minute charges" for the required broadband access. If this.net thing flies and people actually use it, then MS is set to suck a LOT of money from hapless consumers.
Yep. Microsoft has been fascinated for years with the idea of a per-use licensing scheme, but they couldn't find a way to make it work technically. Any PC can be hacked.
But what if part of the app is sitting on an server in Redmond? The new Office 2003 will have the GUI and some local editing logic on the PC. Global stuff like find-and-replace get executed on the Redmond server.
This is an incredibly beautiful idea (from Microsoft's standpoint). It provides total control as well as absolute protection from piracy. They don't even need to worry about backward compatibility. Just put up the new version while updating the Word documents in Redmond to the new format.
The only danger is somebody creating their own server farm that is compatible with the PC front-end (basically replacing the Redmond side). That can easily be delt with by using strong asymmetric encryption (a la Authenticode) so the front-end demands the server present the proper Microsoft-signed digital certificate. And if the front-end is hacked around this, there are always the lawyers to fall back on.
This is really beautiful. They can finesse the whole anti-trust case. They can cheerfully publish the Win32 API and the OS source code for us lamers while they shove all of the new technology onto untouchable servers.
Even with the new much-hyped APIs you mention above, they are still carefully designed to be almost-but-not-quite complete.
I'll pick COM+ from your list as an example. One of the key features of COM+ is asynchronous remote calls, which is crucial for high-volume server apps that need to handle lots of simultaneous requests. Many outside developers have been begging for async COM for a long time. The underlying OSF RPC/NDR layer has been able to do async RPC on Win 9x/NT for years. And yet the async feature of COM+ is only available on Windows 2000. There is no good technical reason for this. Microsoft's own software (e.g. ADSI for NT) seem to be using async COM just fine on NT. But if anybody else wants to use async COM , Microsoft forces Windows 2000 down your throat.
I could rant about hidden APIs in ADSI to cripple the competition (e.g., Samba was getting too close to unlocking NTLM RPC), but I'll stop here. The point is that Microsoft will never willingly divulge any API information that would hurt the sales of their latest OS.
Under the proposal, Microsoft would be required to provide open, timely and complete access to the parts of the Windows operating system code used by independent software companies to design their software applications to run on Windows.
"See we're giving our competitors exactly the same information our own apps developers have!" This is, to say it politely, bullshit. The Win32 API specs are carefully crafted to be incomplete. They tell you just enough to get locked in to Windows, but not enough to actually make a product that would compete with Microsoft. The apps developers in Redmond have direct access to the OS development team and can obtain detailed specs on DFS/COM+/LSA/ADSI/DHTML or whatever new whiz-bang technology is needed to beat the competition.
Several people (Andrew Schulman 1995, et al) have suggested for a long time that a Chinese Wall should go up between the Apps team and the OS team. All communication that goes over the wall should be made public.
My background is security, so I can give you some classic examples of almost-but-not-quite documented APIs that cripple attempts to compete with Microsoft:
CreateProcessAsUser() Essential for creating a telnetd, rshd, rlogin, etc. Hidden to prevent competitors from creating multi-user applications on NT. Finally published circa 1998 after reverse-engineering results were widely published.
NtCreateProcessToken() Essential for simulating setuid() in a Unix compatibility library. Still undocumentated.
The subsystem API (CSRSS, CSRSRV, etc) Essential for simulating fork() in a Unix compatibility library. Still undocumented.
InitializeSecurityContext() and AcceptSecurityContext() Essential for doing transparent authentication (e.g. Internet Explorer can access private web pages without prompting you for your password.) Netscape still cannot do this, they prompt for passwords in base64 cleartext (even today!). At best partially and inaccurrately documented.
NTLM RPC API Essential for doing DC operations to manage domain accounts. With this Samba could eliminate the need for NT Server. Still undocumented.
Microsoft will only release enough information to ensnare users into the Windows environment. To publish API information that would give a competitor an advantage would be over their dead body.
I looked up the specs of the i-opener and compared the component prices with my wholesaler. While I can't reveal the breakdown, the total cost for the components is around $160-200 (assuming 1000 lots).
They sell the box for a loss but make it up on the $21/mo service fee. This is exactly the same business model the video game manufacturers use. The super-advanced 3D graphics chips in the PlayStation are cost way more than the selling price, but Sony makes it up in license fees for the games.
Hence why Sony is attacking Bleem so ferociously, and the same reason Netpliance is beating on their corresponding "open hardware" hackers: it destroys their business model.
Slashdot Mirror
In other words, there could be something nasty out there that hunts and destroys emerging civilizations.
Perhaps the reason there are no radio signals is that a paranoid civilization decided to launch a bunch of self-replicating planet killer probes. The civ may be long dead by now, but the probes continue to hunt for radio signals from potentially competing civilizations. When they find one, they kill it (with meteors or whatever) before it has a chance to develop interstellar spaceflight.
This is essentially the plot of Greg Bear's novels The Forge of God and Anvil of Stars. In the latter novel the surviving remnant of humanity takes revenge on the bastards' evolutionary descendants (with interesting ethical questions about justice and punishment for acts done billions of years earlier.)
The sciam article leaves out a fifth possibility as to why no extraterrestrial civiliations seems to be broadcasting strong radio signals: There is something nasty is out there that hunts and destroys emerging civilizations.
Consider the possibility that one rather paranoid civilization wants to make the galaxy "safe" for later colonization. So they release a bunch of self-replicating planet killer probes. The probes hunt for radio signals from potentially competing civilizations. When they find one, they kill it before it has a chance to develop interstellar spaceflight.
This is basically the plot of Greg Bear's novels The Forge of God and Anvil of Stars. We could be like a babe mewling in the forest, calling down the wolves upon us.
Since our assumption in 2 leads to a contradiction, there is no LIM' ordering relation on m, and thus there is no such thing as the Least Interesting Movie.
The Most Insipid Movie (MIM) is another matter. "Heartbeeps"?? Yeah. Ack. Pfft.
Lurking in the shadows is a critical stumbling block for any attempt to make a "pure" emulator (100% non-Microsoft code): the redistributable DLLs that ship with applications. These include the C runtime sytem (MSVCRT.DLL), the Microsoft Foundation Classes (MFC42.DLL), and the OLE runtime system (OLE32.DLL, OLEAUT32.DLL). The license terms for these DLLs state explicitly that they may only be installed on Microsoft operating systems.
So any emulator has to reinvent these DLLs from scratch. And don't forget there are about 20+ versions of each one, and some apps run only with specific versions, i.e. DLL Hell.
This is why a pure emulator is never going to fly.
p.s. standard IANAL disclaimers.
From reading their manifesto, it looks like they are trying to clone Windows 9x, not Windows NT. They talk about FAT, FAT32, real-mode drivers, and MS-DOS. There is no mention of NTFS, UNICODE, security, or WDM protected-mode drivers.
If this is true, the mind boggles. Let me see if I understand this. They want to clone an OS that has no security, no crash protection, and which (after Windows ME) Microsoft has declared there will be no follow-on versions. Is this right?
And they're throwing in a clone NDIS/TCP/Winsock stack, and OLE (the whole graphical nightmare, not just COM), and DOS support. Hey it's just an all-nighter right? Have they seen Ralf Brown's INT 21 list for DOS? It is the size of a phone book. And that's just for DOS. In short they aim to clone $10+ billion of bug-compatible legacy software created over 15+ years, basically from scratch.
Compare this to WINE, a serious emulation project with modest goals to emulate the Win32 API over Unix. They are working on the GDI, DirectX, DLL interception, security, etc. These people are working on genuine technical issues related to Windows compatiblity. Meanwhile the Open Windows guys are soliciting for snapshots of screen layouts that look cool.
It's like your kids building a sand castle and they say "this is going to be as big as your house Daddy!". You just have to smile and wish them luck.
Also during 1969, Thompson developed the game of `Space Travel.' First written on Multics, then transliterated into Fortran for GECOS (the operating system for the GE, later Honeywell, 635), it was nothing less than a simulation of the movement of the major bodies of the Solar System, with the player guiding a ship here and there, observing the scenery, and attempting to land on the various planets and moons. The GECOS version was unsatisfactory in two important respects: first, the display of the state of the game was jerky and hard to control because one had to type commands at it, and second, a game cost about $75 for CPU time on the big computer. It did not take long, therefore, for Thompson to find a little-used PDP-7 computer with an excellent display processor; the whole system was used as a Graphic-II terminal. He and I rewrote Space Travel to run on this machine. The undertaking was more ambitious than it might seem; because we disdained all existing software, we had to write a floating-point arithmetic package, the pointwise specification of the graphic characters for the display, and a debugging subsystem that continuously displayed the contents of typed-in locations in a corner of the screen. All this was written in assembly language for a cross-assembler that ran under GECOS and produced paper tapes to be carried to the PDP-7.
Space Travel, though it made a very attractive game, served mainly as an introduction to the clumsy technology of preparing programs for the PDP-7. Soon Thompson began implementing the paper file system (perhaps `chalk file system' would be more accurate) that had been designed earlier. A file system without a way to exercise it is a sterile proposition, so he proceeded to flesh it out with the other requirements for a working operating system, in particular the notion of processes. Then came a small set of user-level utilities: the means to copy, print, delete, and edit files, and of course a simple command interpreter (shell). Up to this time all the programs were written using GECOS and files were transferred to the PDP-7 on paper tape; but once an assembler was completed the system was able to support itself. Although it was not until well into 1970 that Brian Kernighan suggested the name `Unix,' in a somewhat treacherous pun on `Multics,' the operating system we know today was born.
I knew it.. the gamers always push the leading edge of technology. :-)
More reasons why MUXing can be a bad idea:
Gates repeatedly alluded to "per-minute charges" for the required broadband access. If this .net thing flies and people actually use it, then MS is set to suck a LOT of money from hapless consumers.
Yep. Microsoft has been fascinated for years with the idea of a per-use licensing scheme, but they couldn't find a way to make it work technically. Any PC can be hacked.
But what if part of the app is sitting on an server in Redmond? The new Office 2003 will have the GUI and some local editing logic on the PC. Global stuff like find-and-replace get executed on the Redmond server.
This is an incredibly beautiful idea (from Microsoft's standpoint). It provides total control as well as absolute protection from piracy. They don't even need to worry about backward compatibility. Just put up the new version while updating the Word documents in Redmond to the new format.
The only danger is somebody creating their own server farm that is compatible with the PC front-end (basically replacing the Redmond side). That can easily be delt with by using strong asymmetric encryption (a la Authenticode) so the front-end demands the server present the proper Microsoft-signed digital certificate. And if the front-end is hacked around this, there are always the lawyers to fall back on.
This is really beautiful. They can finesse the whole anti-trust case. They can cheerfully publish the Win32 API and the OS source code for us lamers while they shove all of the new technology onto untouchable servers.
Even with the new much-hyped APIs you mention above, they are still carefully designed to be almost-but-not-quite complete.
I'll pick COM+ from your list as an example. One of the key features of COM+ is asynchronous remote calls, which is crucial for high-volume server apps that need to handle lots of simultaneous requests. Many outside developers have been begging for async COM for a long time. The underlying OSF RPC/NDR layer has been able to do async RPC on Win 9x/NT for years. And yet the async feature of COM+ is only available on Windows 2000. There is no good technical reason for this. Microsoft's own software (e.g. ADSI for NT) seem to be using async COM just fine on NT. But if anybody else wants to use async COM , Microsoft forces Windows 2000 down your throat.
I could rant about hidden APIs in ADSI to cripple the competition (e.g., Samba was getting too close to unlocking NTLM RPC), but I'll stop here. The point is that Microsoft will never willingly divulge any API information that would hurt the sales of their latest OS.
Under the proposal, Microsoft would be required to provide open, timely and complete access to the parts of the Windows operating system code used by independent software companies to design their software applications to run on Windows.
"See we're giving our competitors exactly the same information our own apps developers have!" This is, to say it politely, bullshit. The Win32 API specs are carefully crafted to be incomplete. They tell you just enough to get locked in to Windows, but not enough to actually make a product that would compete with Microsoft. The apps developers in Redmond have direct access to the OS development team and can obtain detailed specs on DFS/COM+/LSA/ADSI/DHTML or whatever new whiz-bang technology is needed to beat the competition.
Several people (Andrew Schulman 1995, et al) have suggested for a long time that a Chinese Wall should go up between the Apps team and the OS team. All communication that goes over the wall should be made public.
My background is security, so I can give you some classic examples of almost-but-not-quite documented APIs that cripple attempts to compete with Microsoft:
Microsoft will only release enough information to ensnare users into the Windows environment. To publish API information that would give a competitor an advantage would be over their dead body.
I looked up the specs of the i-opener and compared the component prices with my wholesaler. While I can't reveal the breakdown, the total cost for the components is around $160-200 (assuming 1000 lots).
They sell the box for a loss but make it up on the $21/mo service fee. This is exactly the same business model the video game manufacturers use. The super-advanced 3D graphics chips in the PlayStation are cost way more than the selling price, but Sony makes it up in license fees for the games.
Hence why Sony is attacking Bleem so ferociously, and the same reason Netpliance is beating on their corresponding "open hardware" hackers: it destroys their business model.
TANASTAAFL indeed.
Relax. MN was one of 6 states to vote against UCITA. The state attorney general Mike Hatch is rabidly pro-consumer.