SPECIAL REPORT/CLINTON'S CRISES MARCH 2, 1998 VOL. 151 NO. 8
Why We Didn't Remove Saddam
By GEORGE BUSH AND BRENT SCOWCROFT
The end of effective Iraqi resistance came with a rapidity which surprised us all, and we were perhaps psychologically unprepared for the sudden transition from fighting to peacemaking. True to the guidelines we had established, when we had achieved our strategic objectives (ejecting Iraqi forces from Kuwait and eroding Saddam's threat to the region) we stopped the fighting. But the necessary limitations placed on our objectives, the fog of war, and the lack of "battleship Missouri" surrender unfortunately left unresolved problems, and new ones arose.
We were disappointed that Saddam's defeat did not break his hold on power, as many of our Arab allies had predicted and we had come to expect. President Bush repeatedly declared that the fate of Saddam Hussein was up to the Iraqi people. Occasionally, he indicated that removal of Saddam would be welcome, but for very practical reasons there was never a promise to aid an uprising. While we hoped that popular revolt or coup would topple Saddam, neither the U.S. nor the countries of the region wished to see the breakup of the Iraqi state. We were concerned about the long-term balance of power at the head of the Gulf. Trying to eliminate Saddam, extending the ground war into an occupation of Iraq, would have violated our guideline about not changing objectives in midstream, engaging in "mission creep," and would have incurred incalculable human and political costs. Apprehending him was probably impossible. We had been unable to find Noriega in Panama, which we knew intimately. We would have been forced to occupy Baghdad and, in effect, rule Iraq. The coalition would instantly have collapsed, the Arabs deserting it in anger and other allies pulling out as well. Under those circumstances, furthermore, we had been self-consciously trying to set a pattern for handling aggression in the post-cold war world. Going in and occupying Iraq, thus unilaterally exceeding the U.N.'s mandate, would have destroyed the precedent of international response to aggression we hoped to establish. Had we gone the invasion route, the U.S. could conceivably still be an occupying power in a bitterly hostile land. It would have been a dramatically different--and perhaps barren--outcome.
We discussed at length forcing Saddam himself to accept the terms of Iraqi defeat at Safwan--just north of the Kuwait-Iraq border--and thus the responsibility and political consequences for the humiliation of such a devastating defeat. In the end, we asked ourselves what we would do if he refused. We concluded that we would be left with two options: continue the conflict until he backed down, or retreat from our demands. The latter would have sent a disastrous signal. The former would have split our Arab colleagues from the coalition and, de facto, forced us to change our objectives. Given those unpalatable choices, we allowed Saddam to avoid personal surrender and permitted him to send one of his generals. Perhaps we could have devised a system of selected punishment, such as air strikes on different military units, which would have proved a viable third option, but we had fulfilled our well-defined mission; Safwan was waiting.
As the conflict wound down, we felt a sense of urgency on the part of the coalition Arabs to get it over with and return to normal. This meant quickly withdrawing U.S. forces to an absolute minimum. Earlier there had been some concern in Arab ranks that once they allowed U.S. forces into the Middle East, we would be there to stay. Saddam's propaganda machine fanned these worries. Our prompt withdrawal helped cement our position with our Arab allies, who now trusted us far more than they ever had. We had come to their assistance in their time of need, asked nothing for ourselves, and left again when the job was done. Despi
It's sound business for Sun to (A) Open source licensing the Java J2SE,J2EE and J2ME framework libraries ; and (B) Release a fork of the Solaris Kernel under the GPL license.
It would benefit the entire Java based industry, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libraries and Java to bytecode compilers.
Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of the vendors were using the same core libraries.
To insure that the standard base core would not become polluted with incompatible forks, the source could be licensed with a clause requiring any incompatible changes or any additional classes or methods to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of the Java to bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.
The OSF definition of an open source license clause five explicitly states: "The license may require derived works to carry a different name or version number from the original software."
Developers and vendors would only be required to shift changes to the vendors/developers namespace if the changes were incompatible with the JCP JSR open standards. This would not prevent the development/distribution of additional optimizations, ports or bug fixes. Since adoption of standards has for a long time been an open source tradition, it would not be much of an imposition on the open source community.
Vendors don't have to use *all* the same "core" libraries - just provide the same standard interface. The open source Java core can been seen as a starting common base. Each vendor would be free to "short circut" their implementation as long as the standard API behaviour remain the same. Vendors would still be free to compete on their JVM performance along with how well it performs interfacing data bases, integrated development tools, etc.
Sun could require contributers to the Java Open Core to let Sun or the JCP dual license the result as Sun does with OpenOffice.org and StarOffice. If a vendor does not wish to disclose their modifcations then the vendor could pay for a closed source license scheme. The payment could then be split up amongst Sun, the JCP and the contributers.
Ask IBM and HP what their customers are demanding and you will find out more often than not that it's vendor neutral/independent solutions. Customers don't want lock-in slavery anymore. That is why Linux is such a success and why there is more demand for Java skills than any other programming language.
It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.
Releasing a fork of the Solaris Unix Kernel makes even more sense when you consider Suns move towards commodity based hardware, like AMD's opteron, and enterprise desktop systems. Sun is going to need drivers to interoperate with x86 hardware and common peripherals. In comparison to Linux, the range and quality of hardware drivers available to Solaris is pitiful.
If Sun can manage to get out from under the SCO Groups claims over the old AT&T code base, by dealing direct with Novell who still appear to hold the rights and copyrights, then Sun would be free to release a fork of the Solaris kernel under the GPL license.
Sun would be then free to take any source code from the Linux kernel and incorporate it into the GPL'ed Solaris kernel fork. Sun would then free to deploy that kernel in desktop and clustered systems markets, where Linux currently does have a lead over Sun.
The Linux based email lists, related Usenet postings and the raft of public position papers is the Linux kernel paper trail. There is heaps of publicly established provenance, it's just scattered all over the internet and residing on people's old harddrives, backup tapes and CD-ROMs.
People have been pretty good (understatement of the year) at debunking
those claims, but the fact is that part of that debunking involved
searching kernel mailing list archives from 1992 etc. Not much fun.
Unlike early post BSDi development of the "free" BSD's, almost all of the Linux kernel development took place in the open and over the internet.
In comparison Microsoft has "lost" the source to MSDOS and "deleted" CEOs email from it's servers. There is NO real public provenance to the source code to most of Microsoft's products. If this is, like the threat from patents is an issue then Linux is in a better postion than its competitors in the market.
The Year of the SCO Group FUD and Outright Lies
on
Groklaw Turns One
·
· Score: 4, Informative
December 2003 : The SCO Group cannot expect to win any case based upon application interfaces which it's AT&T, USL and Novell predecessors relased in open standards specifically for the purpose of interoperability
The COPYING File in the Linux source distribution states at the start...
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Just open source the Java J2ME,J2SE,J2EE Libraries
on
Gosling on Opening Java
·
· Score: 1, Insightful
It would benefit the entire Java based industy, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libraries and Java to bytecode compilers.
Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of vendors were using the same core libraries.
To insure that the standard base core would not become polluted with incompatable forks, the source could be licensed with a clause requiring any incompatable changes or any additional classes or methords to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of Java bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.
The OSF definition of an open source license clause five explicitly states: "The license may require derived works to carry a different name or version number from the original software."
Contributions to the core standard would be required to licensed under the same open source license. The existing JCP standard body could decide what becomes part of the Open Java Core. Sun would still retain the veto, and the Java J2ME, J2SE and J2EE brand would be still be protected under trademark law.
It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.
Now that Sun, like most of the IT industry, is moving towards commodity based hardware ( like AMD's opteron ), then Sun is going to need drivers to interoperate with x86 hardware and
common peripherals.
In comparison to Linux, the range and quality of hardware drivers available to Solaris is pitiful.
If Sun manages to get out from under the SCO claims on the old AT&T code base and does manage to GPL the Solaris kernel then Sun would be free to port any and all GPL'ed drivers and Linux kernel code to Solaris.
The other alternative would be to add a WINE like MS-OS compatable driver emulation layer, to load XP compatable hardware drivers. In comparison to Microsoft XP, performance would suck. There is no reason why Sun, just like WINE could not have the layer running in user space instead of the kernel, which means that Sun could still use a GPL'ed Solaris kernel and not break the terms of the Linux GPL.
Sun's COs claim that they need to maintain tight control over the Java library source code and standards to insure Java cross vendor "write-once" portability. This was the main point for Sun's lawsuit against Microsoft. In fact, in the DOJ case the federal appeal court did find that Microsoft had deceived Java developers, which the court decided was in breach of the Sherman Antitust act.
For Sun to call their settlement anything but a sellout, Sun could at least persuaded Microsoft to create or adopt a modern release of Java to replace the 1997 eon MSJava JVM. Instead Microsoft gained the right to extends life of its Java Virtual Machine to December 31, 2007. Microsoft have stated that it will not be improving ( or updating ) the old JVM and Microsoft's J# "upgrade path" still uses non-standard interfaces for GUI's and.NET libraries. This leaves Microsoft free to play the old "standard" embrace, extend and enclose anti-competitive tactics.
Okay now say a program calls function winA().
So wine implements winA(), by say just calling linuxA()
What a recompiler would do is rewrite the winA() to linuxA() on the fly.. not much different, no real help.
Lets put it this way. Under WINE, a Windows application can inferface the OS though either a replacement WINE project DDL or native-Window-OS DDL which run under a form of emulation, calling lower down replacement WINE project DDLs. The former replacement WINE project DDL can be incomplete, missing functionality. The latter native-Window-OS DDL is often more compatable for Windows applications but run slower on the host OS.
Running that native-Window-OS DDLs though a theoretical re-compiler, which performs global short-circuiting, should produce a binary that provides the same functionality of the native-Window-OS DDL but runs closer to the speed of a replacement WINE project DDL.
In the same way, the same theoretical re-compiler would perform global short-circuiting on the application's own DDLs and executable, producing faster executing code.
This would dissasemble the x86 windows binaries, rewriting any low level OS library and hardware access code, emitting Linux compatible executable binaries. This could be done both Ahead Of Time, before execution, and Just In Time, during execution. Caching the resulting rewrite on disk would speed up execution a lot.
A neat trick if possible. However Soft Labs would have to reverse engineer a hell of a lot of Microsoft's OS to manage it.
You have got to catch the person at just the right time when they are falling asleep and it has to be an action that the person often performs in a repetitive manner. Extreme tiredness and a little alcohol about 20min before hand helps
I have seen it done on three occasions, each time someone who has just fallen asleep ( cat/power napped ) at their desk.
My last blog entry stirred up a lot of commentary and flamage (and some of the flamage was entertainingly wild: I love the Internet!). Reading through it, it's clear that there's still confusion about the meaning of our "collaboration" agreement with Microsoft.
While it is true that as a part of it we did sign up for Microsoft's Communications Protocol Program that is a part of the US v. Microsoft case, our full agreement both modifies and expands on it to give us a much more broad and useful agreement. It is important to understand that in no way does this lock Sun or Sun customers into interoperating with any Microsoft system on Microsoft's strict terms. Right now, most of our interoperability is achieved through reverse-engineering. We have the option, entirely at our discretion, to access Microsoft's specifications through the collaboration agreement. But before we do so, on a case-by-case basis, we will do an analysis of the business case for the entanglements that such access implies (principally confidentiality and royalties). Right now, the vast majority of the software that we (Sun) produce has free and open specifications and we provide the implementations of a large and growing fraction of it as open source. We are not going to slow down our involvement in the open source community. Right now we have launched no projects that will access any Microsoft specifications under the agreement - we simply have the option to, if we decide that the benefits outweigh the costs.
It's a pity that Sun's press release did not make this clear, as Microsoft is using Sun's signing of the MCPP to persuade the DOJ antitrust department to leave the MCPP as is.
The agreements signed today include the following elements:
Microsoft Communications Protocol Program: Sun has agreed to sign a license for the Windows desktop operating system communications protocols under Microsoft's Communications Protocol Program, established pursuant to Microsoft's consent decree and final judgment with the U.S. Department of Justice and 18 state attorneys general.
Sun's signing into Microsoft's Communications Protocol Program locks Sun and Sun customers into interoperating with any Microsoft system on Microsoft's strict terms, conditions and royalty rates. It also denies the possibility that the code using those Microsoft protocols will ever be open sourced.
This raises serous questions. For example, how much longer will Sun be free to distribute and integrate SAMBA with the Java Desktop? Will Sun's signing of the MCPP have a network affect on vendors who have access to Sun's source code -- will they also be forced to sign up to the MCPP?
What General Weygand called the Battle of France is over. I expect that the Battle of Britain is about to begin. Upon this battle depends the survival of Christian civilization. Upon it depends our own British life, and the long continuity of our institutions and our Empire. The whole fury and might of the enemy must very soon be turned on us. Hitler knows that he will have to break us in this Island or lose the war. If we can stand up to him, all Europe may be free and the life of the world may move forward into broad, sunlit uplands. But if we fail, then the whole world, including the United States, including all that we have known and cared for, will sink into the abyss of a new Dark Age made more sinister, and perhaps more protracted, by the lights of perverted science. Let us therefore brace ourselves to our duties, and so bear ourselves that, if the British Empire and its Commonwealth last for a thousand years, men will still say, "This was their finest hour."
British Prime Minister Winston Churchill, on June 18, 1940, at the House of Commons
We can be truly thankful that Churchill's next action was not to sign a
treaty with Hitler, accepting gold looted from occupied states as payment
for damages done.
It should be possible to use public key encryption with inspected outgoing and incoming email gateways to ensure email content privacy.
-Incoming SMTP Email
| Incoming Gateway encrypts plaintext email with User's public Key
- Encrypted Email
| Gmail Web based email server
- Encrypted Email
| User's Web Brower with Javascript decrypt. User supplies/cut-pastes private Key
- Decrypted Email only at user browser side
| User Reads and enters reply into text window
| More Javascript encrypts outgoing content using outgoing gateway's public key
- Encrypted Email
| Outgoing Email gateway decrypts outgoing Email
- Decrypted Email
As long as the Incoming and Outgoing email servers remain seperate,subject to inspection and undergo regular auditing, then the email stored on Gmail will remain unreadable to Google.
1) Create a self replicating, self organizing nanotech phage, that organizes itself into units of solar powered networked RAM and RISC processors.
2) Port Linux to the processor.
3) Drop package on Moon.
4) Lease resulting massive beowulf cluster to interrested parties - Profit!.
Building a throwaway spaceship and going to Mars just to wave a flag and grab samples of microbial life is really a waste.
It would be better to start getting a sustainable foothold in space, opening up the opportunity to start scooting around the rest of the solar system
We need a small fleet of reusable modular spaceships that can be used for a mission and then can be parked in orbit and replenished to be sent out on future missions. The landing component for Mars and other planets should be the only throwaway component.
The Moon can be a source of materials that are cheaper solely because you don't have boosting the mass into earth orbit.
In the same way, in the long term, a manned subsurface base on Moon is a cheaper option for maintaining the engineering crews and astronauts themselves, between missions.
The low gravity and vacuum in space provides some opportunities for new manufacturing processes, which could also provide a source of revenue for the entire space program.
Asteroids have the potential for providing sources of material for both the new manufacturing processes, creating orbital stations and even new space ships.
It's time to show how ridiculous the Neo-Puritan position is in the twentyfirst century.
Watch, mirror, broadcast and create parodies such as Come Join the Fun!.
Slashdot Mirror
SPECIAL REPORT/CLINTON'S CRISES MARCH 2, 1998 VOL. 151 NO. 8
Why We Didn't Remove Saddam
By GEORGE BUSH AND BRENT SCOWCROFT
The end of effective Iraqi resistance came with a rapidity which surprised us all, and we were perhaps psychologically unprepared for the sudden transition from fighting to peacemaking. True to the guidelines we had established, when we had achieved our strategic objectives (ejecting Iraqi forces from Kuwait and eroding Saddam's threat to the region) we stopped the fighting. But the necessary limitations placed on our objectives, the fog of war, and the lack of "battleship Missouri" surrender unfortunately left unresolved problems, and new ones arose. We were disappointed that Saddam's defeat did not break his hold on power, as many of our Arab allies had predicted and we had come to expect. President Bush repeatedly declared that the fate of Saddam Hussein was up to the Iraqi people. Occasionally, he indicated that removal of Saddam would be welcome, but for very practical reasons there was never a promise to aid an uprising. While we hoped that popular revolt or coup would topple Saddam, neither the U.S. nor the countries of the region wished to see the breakup of the Iraqi state. We were concerned about the long-term balance of power at the head of the Gulf. Trying to eliminate Saddam, extending the ground war into an occupation of Iraq, would have violated our guideline about not changing objectives in midstream, engaging in "mission creep," and would have incurred incalculable human and political costs. Apprehending him was probably impossible. We had been unable to find Noriega in Panama, which we knew intimately. We would have been forced to occupy Baghdad and, in effect, rule Iraq. The coalition would instantly have collapsed, the Arabs deserting it in anger and other allies pulling out as well. Under those circumstances, furthermore, we had been self-consciously trying to set a pattern for handling aggression in the post-cold war world. Going in and occupying Iraq, thus unilaterally exceeding the U.N.'s mandate, would have destroyed the precedent of international response to aggression we hoped to establish. Had we gone the invasion route, the U.S. could conceivably still be an occupying power in a bitterly hostile land. It would have been a dramatically different--and perhaps barren--outcome.
We discussed at length forcing Saddam himself to accept the terms of Iraqi defeat at Safwan--just north of the Kuwait-Iraq border--and thus the responsibility and political consequences for the humiliation of such a devastating defeat. In the end, we asked ourselves what we would do if he refused. We concluded that we would be left with two options: continue the conflict until he backed down, or retreat from our demands. The latter would have sent a disastrous signal. The former would have split our Arab colleagues from the coalition and, de facto, forced us to change our objectives. Given those unpalatable choices, we allowed Saddam to avoid personal surrender and permitted him to send one of his generals. Perhaps we could have devised a system of selected punishment, such as air strikes on different military units, which would have proved a viable third option, but we had fulfilled our well-defined mission; Safwan was waiting.
As the conflict wound down, we felt a sense of urgency on the part of the coalition Arabs to get it over with and return to normal. This meant quickly withdrawing U.S. forces to an absolute minimum. Earlier there had been some concern in Arab ranks that once they allowed U.S. forces into the Middle East, we would be there to stay. Saddam's propaganda machine fanned these worries. Our prompt withdrawal helped cement our position with our Arab allies, who now trusted us far more than they ever had. We had come to their assistance in their time of need, asked nothing for ourselves, and left again when the job was done. Despi
Also, The Linux Show: The original weekly Open Source/GNU/Linux webcast talk show.
Disclamer: David Mohring/NZheretic is soon going to be more closely connected to the Linux Show.
W3C home > Mailing lists > Public > public-webapps-cdf-discuss@w3.org > April 2004
Compound Transactions,Documents,Streams,Proxies.
A proxy based approach
It's sound business for Sun to (A) Open source licensing the Java J2SE,J2EE and J2ME framework libraries ; and (B) Release a fork of the Solaris Kernel under the GPL license.
It would benefit the entire Java based industry, including the free software, open source and proprietary based vendors, to open license the core J2ME,J2SE,J2EE libraries and Java to bytecode compilers.
Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of the vendors were using the same core libraries.
To insure that the standard base core would not become polluted with incompatible forks, the source could be licensed with a clause requiring any incompatible changes or any additional classes or methods to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of the Java to bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.
The OSF definition of an open source license clause five explicitly states: "The license may require derived works to carry a different name or version number from the original software."
Developers and vendors would only be required to shift changes to the vendors/developers namespace if the changes were incompatible with the JCP JSR open standards. This would not prevent the development/distribution of additional optimizations, ports or bug fixes. Since adoption of standards has for a long time been an open source tradition, it would not be much of an imposition on the open source community.
Vendors don't have to use *all* the same "core" libraries - just provide the same standard interface. The open source Java core can been seen as a starting common base. Each vendor would be free to "short circut" their implementation as long as the standard API behaviour remain the same. Vendors would still be free to compete on their JVM performance along with how well it performs interfacing data bases, integrated development tools, etc.
Sun could require contributers to the Java Open Core to let Sun or the JCP dual license the result as Sun does with OpenOffice.org and StarOffice. If a vendor does not wish to disclose their modifcations then the vendor could pay for a closed source license scheme. The payment could then be split up amongst Sun, the JCP and the contributers.
Ask IBM and HP what their customers are demanding and you will find out more often than not that it's vendor neutral/independent solutions. Customers don't want lock-in slavery anymore. That is why Linux is such a success and why there is more demand for Java skills than any other programming language.
It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.
Releasing a fork of the Solaris Unix Kernel makes even more sense when you consider Suns move towards commodity based hardware, like AMD's opteron, and enterprise desktop systems. Sun is going to need drivers to interoperate with x86 hardware and common peripherals. In comparison to Linux, the range and quality of hardware drivers available to Solaris is pitiful.
If Sun can manage to get out from under the SCO Groups claims over the old AT&T code base, by dealing direct with Novell who still appear to hold the rights and copyrights, then Sun would be free to release a fork of the Solaris kernel under the GPL license.
Sun would be then free to take any source code from the Linux kernel and incorporate it into the GPL'ed Solaris kernel fork. Sun would then free to deploy that kernel in desktop and clustered systems markets, where Linux currently does have a lead over Sun.
To quote Linus Torvalds:
Unlike early post BSDi development of the "free" BSD's, almost all of the Linux kernel development took place in the open and over the internet.
In comparison Microsoft has "lost" the source to MSDOS and "deleted" CEOs email from it's servers. There is NO real public provenance to the source code to most of Microsoft's products. If this is, like the threat from patents is an issue then Linux is in a better postion than its competitors in the market.
December 2003 : The SCO Group cannot expect to win any case based upon application interfaces which it's AT&T, USL and Novell predecessors relased in open standards specifically for the purpose of interoperability
March 2004 : How the lawsuit is going to go in court
Google: IBM antitrust Microsoft OEM smartsuite lotus
Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!.
Java's primary strength, the ability to write code which is constantly portable across many vendors platforms, would be greatly enhanced if all of vendors were using the same core libraries.
To insure that the standard base core would not become polluted with incompatable forks, the source could be licensed with a clause requiring any incompatable changes or any additional classes or methords to be moved to and occupy only the vendors namespace. Another clause would require that the vendor version of Java bytecode compiler and any GUI IDE defaults to generating portable bytecode, without embedding any vendor specific references.
The OSF definition of an open source license clause five explicitly states: "The license may require derived works to carry a different name or version number from the original software."
Contributions to the core standard would be required to licensed under the same open source license. The existing JCP standard body could decide what becomes part of the Open Java Core. Sun would still retain the veto, and the Java J2ME, J2SE and J2EE brand would be still be protected under trademark law.
It should not be necessary to open source license Sun's JVMs. In the long run it could greatly benefit Sun to develop the JVM under a dual license as it doing with OpenOffice.org and selling StarOffice.
In comparison to Linux, the range and quality of hardware drivers available to Solaris is pitiful.
If Sun manages to get out from under the SCO claims on the old AT&T code base and does manage to GPL the Solaris kernel then Sun would be free to port any and all GPL'ed drivers and Linux kernel code to Solaris.
The other alternative would be to add a WINE like MS-OS compatable driver emulation layer, to load XP compatable hardware drivers. In comparison to Microsoft XP, performance would suck. There is no reason why Sun, just like WINE could not have the layer running in user space instead of the kernel, which means that Sun could still use a GPL'ed Solaris kernel and not break the terms of the Linux GPL.
Sun's COs claim that they need to maintain tight control over the Java library source code and standards to insure Java cross vendor "write-once" portability. This was the main point for Sun's lawsuit against Microsoft. In fact, in the DOJ case the federal appeal court did find that Microsoft had deceived Java developers, which the court decided was in breach of the Sherman Antitust act.
For Sun to call their settlement anything but a sellout, Sun could at least persuaded Microsoft to create or adopt a modern release of Java to replace the 1997 eon MSJava JVM. Instead Microsoft gained the right to extends life of its Java Virtual Machine to December 31, 2007. Microsoft have stated that it will not be improving ( or updating ) the old JVM and Microsoft's J# "upgrade path" still uses non-standard interfaces for GUI's and .NET libraries. This leaves Microsoft free to play the old "standard" embrace, extend and enclose anti-competitive tactics.
Sun' s James Gosling claims, in response to this article and some "slashdot flamage" from the same author that though the new settlement, Sun has gained the right to selectively access Microsoft's Communications Protocol Program. This ablity to selectively pick and choose and other "flexabilities" was a detail left out of Sun's press release, and more interestingly, the recent joint status report on Microsoft's complicance with the US DOJ final antitrust judgement.
Read the EU Microsoft report.
What a recompiler would do is rewrite the winA() to linuxA() on the fly.. not much different, no real help.
Lets put it this way. Under WINE, a Windows application can inferface the OS though either a replacement WINE project DDL or native-Window-OS DDL which run under a form of emulation, calling lower down replacement WINE project DDLs. The former replacement WINE project DDL can be incomplete, missing functionality. The latter native-Window-OS DDL is often more compatable for Windows applications but run slower on the host OS.
Running that native-Window-OS DDLs though a theoretical re-compiler, which performs global short-circuiting, should produce a binary that provides the same functionality of the native-Window-OS DDL but runs closer to the speed of a replacement WINE project DDL.
In the same way, the same theoretical re-compiler would perform global short-circuiting on the application's own DDLs and executable, producing faster executing code.
This would dissasemble the x86 windows binaries, rewriting any low level OS library and hardware access code, emitting Linux compatible executable binaries. This could be done both Ahead Of Time, before execution, and Just In Time, during execution. Caching the resulting rewrite on disk would speed up execution a lot.
A neat trick if possible. However Soft Labs would have to reverse engineer a hell of a lot of Microsoft's OS to manage it.
I have seen it done on three occasions, each time someone who has just fallen asleep ( cat/power napped ) at their desk.
The Toll Road Ahead : The Impact of Microsoft's New Licensing Scheme on Free and Open Source Software (FOSS)
From the April 2, 2004 Sun Press Releases
Sun's signing into Microsoft's Communications Protocol Program locks Sun and Sun customers into interoperating with any Microsoft system on Microsoft's strict terms, conditions and royalty rates. It also denies the possibility that the code using those Microsoft protocols will ever be open sourced.
This raises serous questions. For example, how much longer will Sun be free to distribute and integrate SAMBA with the Java Desktop? Will Sun's signing of the MCPP have a network affect on vendors who have access to Sun's source code -- will they also be forced to sign up to the MCPP?
I understand Sun's attempt to spin "Peace in our time" into "This Was Their Finest Hour"however, if you look where the quote originated from...
We can be truly thankful that Churchill's next action was not to sign a treaty with Hitler, accepting gold looted from occupied states as payment for damages done.It should be possible to use public key encryption with inspected outgoing and incoming email gateways to ensure email content privacy.
-Incoming SMTP Email
| Incoming Gateway encrypts plaintext email with User's public Key
- Encrypted Email
| Gmail Web based email server
- Encrypted Email
| User's Web Brower with Javascript decrypt. User supplies/cut-pastes private Key
- Decrypted Email only at user browser side
| User Reads and enters reply into text window
| More Javascript encrypts outgoing content using outgoing gateway's public key
- Encrypted Email
| Outgoing Email gateway decrypts outgoing Email
- Decrypted Email
As long as the Incoming and Outgoing email servers remain seperate,subject to inspection and undergo regular auditing, then the email stored on Gmail will remain unreadable to Google.
2) Port Linux to the processor.
3) Drop package on Moon.
4) Lease resulting massive beowulf cluster to interrested parties - Profit!.
It would be better to start getting a sustainable foothold in space, opening up the opportunity to start scooting around the rest of the solar system
We need a small fleet of reusable modular spaceships that can be used for a mission and then can be parked in orbit and replenished to be sent out on future missions. The landing component for Mars and other planets should be the only throwaway component.
The Moon can be a source of materials that are cheaper solely because you don't have boosting the mass into earth orbit.
In the same way, in the long term, a manned subsurface base on Moon is a cheaper option for maintaining the engineering crews and astronauts themselves, between missions.
The low gravity and vacuum in space provides some opportunities for new manufacturing processes, which could also provide a source of revenue for the entire space program.
Asteroids have the potential for providing sources of material for both the new manufacturing processes, creating orbital stations and even new space ships.
It's time to show how ridiculous the Neo-Puritan position is in the twentyfirst century.
Watch, mirror, broadcast and create parodies such as Come Join the Fun!.
In a hard-hitting analysis of the Sun-Microsoft settlement, David Mohring argues that - aside from the monetary payoff - the gains for Sun from the terms and conditions "do not make any sense for Sun in the long term."