The same problem happens in movie companies and genetic research: people get caught, regularly, selling their company's products and files for more than they personally are likely to get, especially if they're incompetent or lazy and are due to be fired for good reason.
Then get them to save money by throwing out the Siebel trouble ticket system and replacing it with Bugzilla or something else usable. Siebel is the single worst drain of IT time I have ever seen: it generate lots of "statistics" that are fundamentally fraudulent and used to justify wasting time doing the Siebel tickets badly instead of actually fixing anything.
I'm not kidding. I've watched two distinct companies decide to use Siebel and nearly halve their IT productivity per person from its various failures. The only way to make it work efficiently is to pull the data for it directly from the Oracle back-end and put it in a usable web interface for viewing, and use the Siebel interface if necessary to input new requests.
Doing something stupid, then going back and trying to erase the traces is a very, very bad programming approach. Fix the real problem: the Ubuntu and other Linux password handling command needs an ability to install a pre-encrypted password to avoid exactly this sort of problem. The reason not to have such an option in this day and age is so that you can run password quality checkers on the unencrypted password, which is certainly not justification for forcing the OS installer or other administratively privileged tools from being able to set the password from an encrypted format.
But anyone remotely competent with shell script commands should have a way to write an encrypted password directly into/etc/shadow or/etc/passwd as needed and avoid keeping one lying around in clear text.
Even worse, it's now on all the backup tapes or other backup resources. This password absolutely must be changed ASAP on all the secured Ubuntu systems, and should no longer be used for FTP or HTTP or other services.
I do hope the Ubuntu developers keep this in mind, and have a very harsh word with whoever wrote the installer.
The command "grep -r" can be very useful to look for strings lying around in plain text files: be careful not to use it in such a way as to leave your password lying around in your bash history, or run "history -c" when you're done to clear it.
Actually, the RedHat kickstart installers used to allow this behavior years ago. They switched to allowing the kickstart tools to use an encrypted password, which was a good move. But you could fairly easily pull the kickstart file off the tftp server in most setups, and it may have been stored in plain-text in the kickstart logs, so it was a bad approach then, too.
There are related versions of this problem. Mis-typed IMAP and POP and SSH logins, where the user accidentally types their password in the user account line, are a fun way to get other people's passwords on a shared server. You really have to think about what you put in logs and who gets access to them on a login capable server.
Hold it: merely making a local text file with a password in clear text unreadable to non-root users is still a stupid approach. The Ubuntu users should know this, as do most other Linux users. It's unfortunately common: OpenLDAP does the same thing with the administrative passsword for the LDAP database, which is why root level accounts should never, never, never come from LDAP on the LDAP server itself.
If an installer has to pre-set a password, it should handle it only in encrypted form. The lack of a "use this encrypted password" rather than a "put the plain password in here" option in the Linux "passwd" command has been a deficit for many years. BSD and other UNIX's had the same flaw, but the continuing lack of the feature encourages the same sort of poor scripting that stores and sets passwords from clear text. That leads to this sort of mistake.
1U is exactly 1.75" high. It's an old standard for putting the holes in 19" and 24" racks, designed to allow devices of different heights to be stacked efficiently by having the screw holes laid out according to certain well-defined patterns. The patterns are quite old, and caused a lot of problems when the US tried to switch to metric (and basically failed in the computer manufacturing industry).
No, swapping 8 single units for one octal unit is usually a bad move for webservers. Individual operating systems can typically withstand far fewer than 1000 simultaneous connections, and when one component fails on a big, expensive, octal server, the whole thing is down and you lose 8 servers. Also, the amount of disk you can strap into an 8-way system is limited by the controllers, not the CPU speed, so for storage of actual web content, it can be very expensive or very inefficient unless you buy a great big external array.
But the time you've totaled up all the money and necessity for failover, network resources, disk, etc., you may find that 8 cheap 1U systems is actually a lot cheaper than one very expensive overpowered server.
It seems more likely that they just haven't been able to get it to work, or had the time in their Q/A process to really regression-test it and approve it for general release. When you're doing a big product release, it's often a real business decision to drop niche market features and concentrate your manpower and test rigs on the core features, even if it seems really stupid to the technical people who believe that having those features in at the start will make life much easier for them. Microsoft may not have the people with EFI experience, or the hardware, to really do the necessary regression testing. After Vista comes out, some of those staff can be re-allocated to this new feature.
As a marketing strategy, this also means that the basic installation CD's for Vista won't work for Mac hardware, and when Vista supports Mac hardware, the users will have to buy a special installation set released 3 months later rather than being able to use the same installation CD's and just move their licenses around or test with their old CD's.
One reason is more cynical and manipulative, but the other may be the truth. It's hard to tell.
You are quite lucky, sir. I've had incredible problems with exactly this: the BIOS installers are generally poorly written pieces of proprietary and unreliable garbage which do not handle even the slightest deviation from their standard use, such as putting them on a CD.
Fortunately, the 64-bit system I trashed the BIOS on this way was a test box: it turned out to be simpler to open up the boxes and temporarily install a floppy drive for exactly this use.
It should be possible to control, from the BIOS prompt, the boot order. It's awkward to control from the software or OS level to change it for the next reboot: BIOS's are a real mess of proprietary and closed source errors and debris that need a real cleaning out in order to report system state reliably and to properly control booting. But many BIOS's screw up their ability to control boot order if you do the slightest change such as attaching a USB drive and have to be reset, so it's not reliable.
Fortunately, some very clever people are working on exactly that, at www.linuxbios.org. It's an interesting project, although motherboard vendors are frightened of breaking various non-disclosure agreements with BIOS vendors if they participate in it. And integrating it with the new "Trusted Computing" tools is going to be very painful because of the closed source and secretive hardware used by that.
One reason Cisco doesn't use what you call "white box" hardware is because of its failure rates. What's acceptable down-time for a home PC is absolutely unacceptable for a Cisco-quality router. And with the constantly shifting set of vendors, upgrades, and chipset changes on motherboards that have the same model number, it would be a maintenance nightmare for Cisco to try and support that kind of hardware. The savings in cost per unit would be quickly eaten up by the replacement and repair costs for systems that have to run 24x7.
A better example of Microsoft allegedly complying with a standard but actually breaking it and making it inoperable is Kerberos. HTML is enough of a mongrel standard with lots of developers vying to add new features that it's understandable to add things to it. Kerberos, however, was reasonably mature and stable, and the change made was in no way a feature addition: it simply broke things for non-Windows Kerberos clients.
Raw hydrogen needs to react with something to generate energy. And react it does! You'll almost never find pure hydrogen available except in an environment where it's very hot and breaks down chemicals, or where there's nothing else to combine with (such as the Sun itself). Raw helium reacts with nothing: it's a noble gas, and you can't harvest energy from chemical interactions with it because there are so few that occur. Ice is cold water: the energy available from it was the result of hydrogen combining with oxygen, which released a lot of energy but makes it tough to get any more energy out of it now that it's already turned into water.
Now, there are levels of Jupiter's atmosphere where more complex and useful molecules are likely, due to pressure and lots of available components. Methane, for example, or other useful hydrocarbons that would have some energy to release and could be used for fuel in various interactions should be quite popular at some levels of that very deep atmosphere. And there are some fascinating proposals for how life could eveolve there. But please actually look them up, and maybe take a basic chemistry course to learn about what "using something for energy" means about the chemicals involved.
The only cases where "patent predators" are actually trying this against open source right now is SCO, which is its own problem. The "patent predators" of open source are easy to buy off: simply publish your modifications.
Take a good look at CAD software. Quite a lot of it goes through forced obsolescence as companies buy each other and the old software gets discarded. And if you have licensed software and the old license vendor is gone, you can't transfer it to a new installation.
I read it. The FUD is both explicit and implicit. The failure to compare the copyright or patent violation risks of open source software to those of closed source software, where the intellectual property you may be duplicating accidentally is invisible to you, is an implicit FUD. And the indemnification clause is an explicit FUD, since the resolution to most open source copyright violations is simply to publish your modifications to your clients.
The person who wrote this has clearly never examined the history of intellectual property lawsuits in the closed source world, where code theft is harder to discover but tends to be more destructive to the original author's property rights.
The entire slant of the document is incorrect. There are certainly concerns with the open source licenses, especially for someone unfamiliar with them who is used to using proprietary software, tweaking it, and reselling without every publishing the modifications to their clients or to the authors.
But the use of closed source and proprietary software has a generally greater risk due to risk of copyright violation and patent violation and user agreement violation. Simply reverse-engineering a proprietary protocol in order to get your work done or to fix a serious issue in closed source software can cause serious legal problems which are often far greater, even though they are more familiar. And the closed source tools are far more likely to contain backdoors or to have vital features discarded in new revisions, forcing a painful and expensive upgrade process for both software and its configurations to the new setups, or to simply be discarded and the data or tools permanently lost to users.
The shutdown of companies or their abandonment of products is a real problem in the closed source world.
I've tried to run Windows 2003 on a 500 MHz machine, with 256 Meg of RAM, and a 10 Gig hard drive. After installing MS Office, Symantec Anti-Virus, and Adobe Reader, it was clear that it was painfully unusable, especially because it was so slow doing Microsoft updates that basically one day out of the week had to be reserved for nothing but doing the current round of updates. Actually running any database software on it was entirely unacceptable.
This is of course unusable: I got the users a newer box for that purpose, and put a contemporary Linux on it: it's now running the same database software, quite happily, and gets its security scans and updates without excess user intervention or unavoidable reboots.
The problem is two-fold: they hide the cost of those add-on packages in the cost of the OS, while other software authors have to be added on on top of the OS. We saw similar problems with Netscape's webservers and IIS in the NT 4.0 workstation vs. server lawsuits.
The other problem is that resellers are prohibited by their licensing from Microsoft from un-installing such components and replacing them with other add-on utilities, or even making the other add-on components the default. Microsoft got caught repeatedly threatening to raise their OS price to vendors if they set Netscape to be the default web client, or even if vendors installed Netscape by default in their OEM bundles: we're seeing similar problems now with Real, Quicktime, and other audio and video components. So South Korea has good reason to complain about this.
What's amazing is that they're making exactly the sort of court decision that Judge White should have made against Microsoft here in the US, years ago. Microsoft absolutely does not want to have any precedents, anywhere, of unbundling their software: if South Korea, it means other countries can, too. Remember that Windows is the core product to sell lots of other Microsoft products: Microsoft uses that Windows bundling to prevent other tools from ever bing installed.
LCD's are the most bang for your buck over the first year or two of use. The power consumption is so much higher for a CRT that the electricity costs easily overwhelm the price difference. This is especially true if you get a modest, clean LCD instead of a larger CRT with bigger display, but fuzzier images: for most text editing and web browsing the LCD is actually easier to tune and manage. It also leaves you a lot more useful desk spave for other purposes.
The recruiting companies are already outsourcing. I've gotten a dozen calls in the last month with bad connections with phase-lags indicating the call is from overseas, and the recruiter obviously working from a menu they don't understand and a clearly Indian accent. (I keep my resume up-to-date on the websites with a ridiculously high salary listing, just to keep an eye on the market: my skills are apparently in demand right now.)
I think you've missed something: the existing software to write and read the Trusted Computing keys is copyrighted. That brings it under DMCA protection, making reverse engineering that software illegal.
Loading your own operating system, once you have the technology to read and write the Trusted Computing keys, is a separate issue. The motherboard technology to handle boot loaders is fascinating (and often very badly written) stuff: it's at that interface between hardware and software where the hardware can be patented, and the software can be both patented and copyrighted. Sorting out the legal issues of that is pretty painful: Look at the history of the LinuxBIOS project and if you have the skills, get involved with them to try and clean up both the code and the legal issues.
But protecting boot loaders is a big issue for Trusted Computing: it's one of the places where it can be used to do a lot of good, and to do a lot of bad.
Slashdot Mirror
The same problem happens in movie companies and genetic research: people get caught, regularly, selling their company's products and files for more than they personally are likely to get, especially if they're incompetent or lazy and are due to be fired for good reason.
Then get them to save money by throwing out the Siebel trouble ticket system and replacing it with Bugzilla or something else usable. Siebel is the single worst drain of IT time I have ever seen: it generate lots of "statistics" that are fundamentally fraudulent and used to justify wasting time doing the Siebel tickets badly instead of actually fixing anything.
I'm not kidding. I've watched two distinct companies decide to use Siebel and nearly halve their IT productivity per person from its various failures. The only way to make it work efficiently is to pull the data for it directly from the Oracle back-end and put it in a usable web interface for viewing, and use the Siebel interface if necessary to input new requests.
Doing something stupid, then going back and trying to erase the traces is a very, very bad programming approach. Fix the real problem: the Ubuntu and other Linux password handling command needs an ability to install a pre-encrypted password to avoid exactly this sort of problem. The reason not to have such an option in this day and age is so that you can run password quality checkers on the unencrypted password, which is certainly not justification for forcing the OS installer or other administratively privileged tools from being able to set the password from an encrypted format.
/etc/shadow or /etc/passwd as needed and avoid keeping one lying around in clear text.
But anyone remotely competent with shell script commands should have a way to write an encrypted password directly into
Even worse, it's now on all the backup tapes or other backup resources. This password absolutely must be changed ASAP on all the secured Ubuntu systems, and should no longer be used for FTP or HTTP or other services. I do hope the Ubuntu developers keep this in mind, and have a very harsh word with whoever wrote the installer.
The command "grep -r" can be very useful to look for strings lying around in plain text files: be careful not to use it in such a way as to leave your password lying around in your bash history, or run "history -c" when you're done to clear it.
Actually, the RedHat kickstart installers used to allow this behavior years ago. They switched to allowing the kickstart tools to use an encrypted password, which was a good move. But you could fairly easily pull the kickstart file off the tftp server in most setups, and it may have been stored in plain-text in the kickstart logs, so it was a bad approach then, too.
There are related versions of this problem. Mis-typed IMAP and POP and SSH logins, where the user accidentally types their password in the user account line, are a fun way to get other people's passwords on a shared server. You really have to think about what you put in logs and who gets access to them on a login capable server.
Hold it: merely making a local text file with a password in clear text unreadable to non-root users is still a stupid approach. The Ubuntu users should know this, as do most other Linux users. It's unfortunately common: OpenLDAP does the same thing with the administrative passsword for the LDAP database, which is why root level accounts should never, never, never come from LDAP on the LDAP server itself.
If an installer has to pre-set a password, it should handle it only in encrypted form. The lack of a "use this encrypted password" rather than a "put the plain password in here" option in the Linux "passwd" command has been a deficit for many years. BSD and other UNIX's had the same flaw, but the continuing lack of the feature encourages the same sort of poor scripting that stores and sets passwords from clear text. That leads to this sort of mistake.
1U is exactly 1.75" high. It's an old standard for putting the holes in 19" and 24" racks, designed to allow devices of different heights to be stacked efficiently by having the screw holes laid out according to certain well-defined patterns. The patterns are quite old, and caused a lot of problems when the US tried to switch to metric (and basically failed in the computer manufacturing industry).
No, swapping 8 single units for one octal unit is usually a bad move for webservers. Individual operating systems can typically withstand far fewer than 1000 simultaneous connections, and when one component fails on a big, expensive, octal server, the whole thing is down and you lose 8 servers. Also, the amount of disk you can strap into an 8-way system is limited by the controllers, not the CPU speed, so for storage of actual web content, it can be very expensive or very inefficient unless you buy a great big external array.
But the time you've totaled up all the money and necessity for failover, network resources, disk, etc., you may find that 8 cheap 1U systems is actually a lot cheaper than one very expensive overpowered server.
It seems more likely that they just haven't been able to get it to work, or had the time in their Q/A process to really regression-test it and approve it for general release. When you're doing a big product release, it's often a real business decision to drop niche market features and concentrate your manpower and test rigs on the core features, even if it seems really stupid to the technical people who believe that having those features in at the start will make life much easier for them. Microsoft may not have the people with EFI experience, or the hardware, to really do the necessary regression testing. After Vista comes out, some of those staff can be re-allocated to this new feature.
As a marketing strategy, this also means that the basic installation CD's for Vista won't work for Mac hardware, and when Vista supports Mac hardware, the users will have to buy a special installation set released 3 months later rather than being able to use the same installation CD's and just move their licenses around or test with their old CD's.
One reason is more cynical and manipulative, but the other may be the truth. It's hard to tell.
You are quite lucky, sir. I've had incredible problems with exactly this: the BIOS installers are generally poorly written pieces of proprietary and unreliable garbage which do not handle even the slightest deviation from their standard use, such as putting them on a CD.
Fortunately, the 64-bit system I trashed the BIOS on this way was a test box: it turned out to be simpler to open up the boxes and temporarily install a floppy drive for exactly this use.
It should be possible to control, from the BIOS prompt, the boot order. It's awkward to control from the software or OS level to change it for the next reboot: BIOS's are a real mess of proprietary and closed source errors and debris that need a real cleaning out in order to report system state reliably and to properly control booting. But many BIOS's screw up their ability to control boot order if you do the slightest change such as attaching a USB drive and have to be reset, so it's not reliable.
Fortunately, some very clever people are working on exactly that, at www.linuxbios.org. It's an interesting project, although motherboard vendors are frightened of breaking various non-disclosure agreements with BIOS vendors if they participate in it. And integrating it with the new "Trusted Computing" tools is going to be very painful because of the closed source and secretive hardware used by that.
One reason Cisco doesn't use what you call "white box" hardware is because of its failure rates. What's acceptable down-time for a home PC is absolutely unacceptable for a Cisco-quality router. And with the constantly shifting set of vendors, upgrades, and chipset changes on motherboards that have the same model number, it would be a maintenance nightmare for Cisco to try and support that kind of hardware. The savings in cost per unit would be quickly eaten up by the replacement and repair costs for systems that have to run 24x7.
A better example of Microsoft allegedly complying with a standard but actually breaking it and making it inoperable is Kerberos. HTML is enough of a mongrel standard with lots of developers vying to add new features that it's understandable to add things to it. Kerberos, however, was reasonably mature and stable, and the change made was in no way a feature addition: it simply broke things for non-Windows Kerberos clients.
Raw hydrogen needs to react with something to generate energy. And react it does! You'll almost never find pure hydrogen available except in an environment where it's very hot and breaks down chemicals, or where there's nothing else to combine with (such as the Sun itself). Raw helium reacts with nothing: it's a noble gas, and you can't harvest energy from chemical interactions with it because there are so few that occur. Ice is cold water: the energy available from it was the result of hydrogen combining with oxygen, which released a lot of energy but makes it tough to get any more energy out of it now that it's already turned into water.
Now, there are levels of Jupiter's atmosphere where more complex and useful molecules are likely, due to pressure and lots of available components. Methane, for example, or other useful hydrocarbons that would have some energy to release and could be used for fuel in various interactions should be quite popular at some levels of that very deep atmosphere. And there are some fascinating proposals for how life could eveolve there. But please actually look them up, and maybe take a basic chemistry course to learn about what "using something for energy" means about the chemicals involved.
The only cases where "patent predators" are actually trying this against open source right now is SCO, which is its own problem. The "patent predators" of open source are easy to buy off: simply publish your modifications.
Take a good look at CAD software. Quite a lot of it goes through forced obsolescence as companies buy each other and the old software gets discarded. And if you have licensed software and the old license vendor is gone, you can't transfer it to a new installation.
I read it. The FUD is both explicit and implicit. The failure to compare the copyright or patent violation risks of open source software to those of closed source software, where the intellectual property you may be duplicating accidentally is invisible to you, is an implicit FUD. And the indemnification clause is an explicit FUD, since the resolution to most open source copyright violations is simply to publish your modifications to your clients.
The person who wrote this has clearly never examined the history of intellectual property lawsuits in the closed source world, where code theft is harder to discover but tends to be more destructive to the original author's property rights.
The entire slant of the document is incorrect. There are certainly concerns with the open source licenses, especially for someone unfamiliar with them who is used to using proprietary software, tweaking it, and reselling without every publishing the modifications to their clients or to the authors.
But the use of closed source and proprietary software has a generally greater risk due to risk of copyright violation and patent violation and user agreement violation. Simply reverse-engineering a proprietary protocol in order to get your work done or to fix a serious issue in closed source software can cause serious legal problems which are often far greater, even though they are more familiar. And the closed source tools are far more likely to contain backdoors or to have vital features discarded in new revisions, forcing a painful and expensive upgrade process for both software and its configurations to the new setups, or to simply be discarded and the data or tools permanently lost to users.
The shutdown of companies or their abandonment of products is a real problem in the closed source world.
I've tried to run Windows 2003 on a 500 MHz machine, with 256 Meg of RAM, and a 10 Gig hard drive. After installing MS Office, Symantec Anti-Virus, and Adobe Reader, it was clear that it was painfully unusable, especially because it was so slow doing Microsoft updates that basically one day out of the week had to be reserved for nothing but doing the current round of updates. Actually running any database software on it was entirely unacceptable.
This is of course unusable: I got the users a newer box for that purpose, and put a contemporary Linux on it: it's now running the same database software, quite happily, and gets its security scans and updates without excess user intervention or unavoidable reboots.
The problem is two-fold: they hide the cost of those add-on packages in the cost of the OS, while other software authors have to be added on on top of the OS. We saw similar problems with Netscape's webservers and IIS in the NT 4.0 workstation vs. server lawsuits.
The other problem is that resellers are prohibited by their licensing from Microsoft from un-installing such components and replacing them with other add-on utilities, or even making the other add-on components the default. Microsoft got caught repeatedly threatening to raise their OS price to vendors if they set Netscape to be the default web client, or even if vendors installed Netscape by default in their OEM bundles: we're seeing similar problems now with Real, Quicktime, and other audio and video components. So South Korea has good reason to complain about this.
What's amazing is that they're making exactly the sort of court decision that Judge White should have made against Microsoft here in the US, years ago. Microsoft absolutely does not want to have any precedents, anywhere, of unbundling their software: if South Korea, it means other countries can, too. Remember that Windows is the core product to sell lots of other Microsoft products: Microsoft uses that Windows bundling to prevent other tools from ever bing installed.
LCD's are the most bang for your buck over the first year or two of use. The power consumption is so much higher for a CRT that the electricity costs easily overwhelm the price difference. This is especially true if you get a modest, clean LCD instead of a larger CRT with bigger display, but fuzzier images: for most text editing and web browsing the LCD is actually easier to tune and manage. It also leaves you a lot more useful desk spave for other purposes.
The recruiting companies are already outsourcing. I've gotten a dozen calls in the last month with bad connections with phase-lags indicating the call is from overseas, and the recruiter obviously working from a menu they don't understand and a clearly Indian accent. (I keep my resume up-to-date on the websites with a ridiculously high salary listing, just to keep an eye on the market: my skills are apparently in demand right now.)
I think you've missed something: the existing software to write and read the Trusted Computing keys is copyrighted. That brings it under DMCA protection, making reverse engineering that software illegal.
Loading your own operating system, once you have the technology to read and write the Trusted Computing keys, is a separate issue. The motherboard technology to handle boot loaders is fascinating (and often very badly written) stuff: it's at that interface between hardware and software where the hardware can be patented, and the software can be both patented and copyrighted. Sorting out the legal issues of that is pretty painful: Look at the history of the LinuxBIOS project and if you have the skills, get involved with them to try and clean up both the code and the legal issues.
But protecting boot loaders is a big issue for Trusted Computing: it's one of the places where it can be used to do a lot of good, and to do a lot of bad.