You have a user ID, you have a password, you use them to play many games. You don't even need the physical media for HL2 to play it, just log into Steam, choose the game from the list, click play.
If you installed from CD, you can uninstall the game, log into steam, choose to play it and it will reload it without a need for a CD.
So in this case, there's no point in a crack at all.
That was a user comment, if you didn't notice, not Microsoft's comment.
Also...
Just FYI -- most of the ASP.NET issues can be corrected by adding FireFox to either machine.config or web.config (former is global, latter is local).
Microsoft's default web.config only handles IE -- it does not handle even mobile devices correctly. Do a search for browserCapabilities on CodeProject, download it, and install it and FireFox will be a lot happier with ASP.NET-served sites.
The problem here is that in the US, we currently have no laws requiring this at a federal level. Enforcing European laws internationally is unlikely to happen; the US has tried to shut off sites that aren't operating within US laws internationally, and the WTO has turned us down every time (gambling, etc.).
The other big problem is defining spyware accurately and consistently.
I have real problems with some of the programs that AdAware and Spybot flag as spyware/malware. Some of these programs shouldn't be flagged, but are.
When a Virus Scanner finds a virus, you can usually exclude it from future scans. When a Virus Scanner finds a virus, you can usually click on a button to have an accurate description of what it does, and what its impact is.
I think that what's really needed is to have some system of categorizing risks in the spyware systems, so you can say "hey, you know what? it's OK for a program to 'phone home' for DRM, but I don't want it tracking me."
An example of this would be wild tangent, which phones home for DRM purposes. When you view wild tangent content, whoever wrote the content gets billed. It has to phone home to do that, and personally, I don't see it as a privacey risk, and it's not a performance risk since the client is only loaded if you view a site that HAS tangent content.
At the very least, the amount of information removal programs give needs to be greatly improved.
Microsoft Avalon is an XML system for writing rich clients that operate on data stored on a server. For the technical people, you have a secure XML Web Service that provides the Model and Controller of a MVC application, and then you have the rich client providing the View and a proxy into the controller.
I am not going to say "this is what Google is going," but Google would have to be scared about this, since in order to use these new features, you have to install a new Microsoft OS and IE, and in the process msn.com/search.msn.com probably take over the browser, and all their tools might not be loadable, etc.
Meanwhile, Microsoft is pushing ease of deployment of applications and security of data as big selling points to this model. If your document never leaves the server, even when you are editing it, if you e-mail a link which is secured at the server, then the document itself becomes much more secure.
And, of course, DRM is trivial when everything has to be routed through the server, too.
If you're google, you're sitting there though going, well we can write XML Web Services, and we can write desktop applications. You might look to develop an alternative, say using Java and XUL for the client application.
You might think user's trust us with their e-mail, and send sensitive documents. We could reuse our storage back end to store word processing documents, we could index them, and serve ads based on that information.
You might think we could provide a word processor for free (as in cost) using this revenue, just as we provide search, webmail, etc. now.
I'm not saying that is what they are doing, but it seems a lot more likely (since it would tie into Google's strongest traits as a company, including name recognition and perceived integrity) that developing a new operating system (which would be outside Google's current realm of strengths).
My stack of DVD-RAM disks that is a backup of 4 different computers disagrees strongly that 9g is enough storage. I use double sided disks with 4.7g/side (9.4g total) right now for backup.
Autoupdating is a good idea, the problem on Windows is the design of the OS and programming environment.
On Linux, make a directory:/opt
Under/opt, make a folder for each vendor's product:/opt/vendor1/opt/vendor2 (note vendor here could include package maintainers, organizations, etc. not necessarily a commercial vendor)
All the vendor's software is chrooted to this base folder when it runs, and the base folder is determined from a digitally signed package with a trusted root authority listed (note: trusted doesn't necessarily mean commercial -- Debian could maintain its own CA, for example).
Additionally, a Java or.NET style security policy is applied to each program. The default settings disallow network access, disallow file access outside the chroot jail, etc.
When running a vendor's app, you put their/lib in from of the system lib's, etc.
Now if Another Useless toolbar (AUT) installs itself, it can't perform its spyware functions without obtaining authorization from the user. The user can select whether the program should have access or not.
Meanwhile, the system administrator can lock the policy, etc. so that end user's can't modify it or grant permission, and can grant permission to applications that they know are safe.
It's that easy.
The issue with conflicts has never been the auto updater in Windows, the issue has been that program XYZ installs library ABC into \Windows\System32, and then program 123 needs a different version, and installs an incompatible version over the top.
Spyware/Malware replaces some files sometimes in order to "get in deep" where it can't be removed.
If you remove the capability of non-OS provided files to install themselves into places reserved for OS-provided files, then you remove the primary issue with application compatibility.
Additionally, if program XYZ just can't function with the patched version of libC, you have a standard, known, easily obtainable folder to put the copy of the file that program needs to ensure it gets that copy of the library until you're ready to upgrade it.
Windows "kind of" supports this, but it's half hearted and not well thought out, and most vendors have ignored it totally.
The issue is that LSB needs to evolve over time. The current standard is outdated and hasn't been applied by most vendors in several years.
LSB is absolutely critical to taking on Windows, and needed to be updated. There cannot be dozens of packages that have to be maintained by those of us writing software for Linux. This makes the user experience bad for people who aren't computer science majors and can't work configure, GNU C, etc.
Installing a program from binaries should be the single simplest thing a user ever has to do. It should be simple and consistant across all distributions. An individual distribution may have a "better way of doing it" (dpkg vs rpm, etc.), but the user experience needs to be consistent, and there needs to be a set of features, libraries, etc. that package maintainers can write to to be able to say: "Click here to install the GNU/Linux LSB 2 package"
Windows has been to this point for a long time. You don't see a lot of programs saying "click here for Windows 95, click here for NT." There are programs that do, just not many. Even in the Windows 3.1 to 95 transition, you saw a lot more programs that used Win32s and just shipped a 95 version than that shipped both versions.
GNU/Linux needs to get there. Diversity is fine, version numbering is confusing across the board. The kernel version is usually stated on the box or on the information on the website. Versions of other pieces aren't commonly reported.
Being able to say "LSB 2.0" and being able to have a LSB 2.0 package that installs on all LSB 2.0 plaftorms is absolutely critical.
From a developer standpoint, the most attractive alternative is to use Java or ECMA.NET (or a similar solution), as these have widespread support over many platforms at this point, and require only a single package and handle versioning relatively well.
A lot of people seem to have not read the article (including potentially the poster of the story)
1. Microsoft purchased smart cards to upgrade their existing smart cards that they use for system and facility access. This is said explicitly about 2/3 of the way down.
2. Microsoft was the first to purchase this particular type of smart card.
3. The smart cards have an ECMA-compliant implementation of the.NET CLI and CLR on them. This means you can send ECMA compliant code, such as code compiled with Mono, to the smart card and it can run it, if you use their tool.
4. The smart cards ship with the device driver and libraries to work with it.
People are going "why.NET why not Java." This is a third party, not Microsoft. Java involves purchasing a license from Sun for commercial use (to make a Java-logo compliant JVM), while.NET involves downloading a specification from ECMA for free.
So far as raw assembly being superior, I'm not even going to touch that one except to say that the processor is junk on these things, you need isolation of code, the best way to get it is a VM of some sort you might as well use a standard one for which tools are available as roll your own.
So this is the situation. Some company released a smart card with an ECMA compliant.NET implementation on it, Microsoft bought a bunch of them and wants to use them for security.
This doesn't really involve anyone outside of Microsoft (it really doesn't), doesn't involve embrace and extend or FUD, or anything else that's been brought up in the comentary.
And it's not some great shocker that Microsoft doesn't like passwords, as a lot of people have said. For years, most of the industry preached passwords as the way to go. With a few exceptions, most people understand now that users are generally stupider than the chairs that they sit in, and either write down their password, chant it while they type, or use the same password everywhere. Also, if you require a user to change their password every 30 days, generally they achieve this by attaching a number and incrementing it.
The good news is hackers have been getting dumber, too, so they're unlikely to realize the user uses Pa$$word10 one month and Pa$$word11 the next...
It costs a fixed amount of work to move a 100kg (or any mass) payload 1m (or any other constant distance) anywhere in our universe (so far as we know).
Any technology that is reuseable can potentially do the work, so you must look at the costs and risks of the tecnologies.
A space elevator has cables which provide a huge surface area against the atmosphere, a system we don't fully understand and a system which impacts every other system on our planet. We don't know what the impact of that could be, but it has the potential to shift weather globally, intentionally or not.
You have environmental forces acting on the cable throughout it's length, and you have temprature differences acting on the cable throughout it's length. All this energy entering the system msut go somewhere, and most of it isn't in a form that can be readily applied to propulsion. You have a temprature difference of at least 100c between the base and summit, and probably more than that.
You have a potential difference along the whole thread, which means electrons are going to want to flow, destructively or not. You might be able to use this as a power source, but more likely it would be random and difficult to control.
You have corrossive forces acting against the cable, and the entire structure from ground to top must be actively maintained and monitored.
The platform must have thrusters. The corces applied to the cables will turn the cable into a giant lever. the platform must expend energy to counter the force of the lever. The platform, however, has to use pure thrust to accomplish this, there isn't a simple machine it can use, and gyroscopes control only attitude, not position.
I'm not saying this is a bad idea, or that it's not possible, etc. But there are a lot of technological problems with it that would need to be ocercome.
The article says "Nasa is abandoning economical space travel to pursue the vision." This is a false assertion based on the bias of the author of the article.
Nasa is doing what government and industry most often do, and pursuing "safer" technologies.
The risk is, you spend $4b on a space elivator and have nothing to show at the end. The structure is theoretical, so whether it might work or not is a theory and nothing more. There are a lot of unknowns and ther eis a lot of risk.
You spend that same $4b on improving efficiency of existing technologies or developing new derivatives, and you have many fewer unknowns and a much lower level of risk.
Risk drives spending. If you have a risky venture, then try a venture capitalist -- they make their money by taking good risks.
So far as the DoD goes, Nasa's current approach to economical space travel -- i.e. improve the economy of existing infrastructures, build new derivatives that work with existing infrastructures -- fits much more with their specific needs.
It's not just about getting the spy satalite into space for them. They need to minimize the number of people with exposure to it, they need to minimize its presence on civilian structures. Something that they can launch from an airforce base off of a conventional landing field fits those needs much more than a needle would. It's not just the matter of moving the cargo to the needle, it's the matter of minimizing contact of the cargo with non-military personnel and launching it from as close to its point of origin as possible.
Economy isn't the primary concern here, physical security of the payload is. For this reason, I couldn't see them taking this project on in any way that would benefit civilians or industry. If they built such a thing, I would think that they would keep it to themselves.
After all, you don't see other pieces of the military infrastructure being routinely used for civilian use. For example, I live near Write Paterson Airforce Base. When I flew to Australia, I flew out of an airport 30 minutes farther away from Write Parterson Airforce Base, because obviously the airforce base doesn't want me using their infrastructure -- their infrastructure is solely for their use.
If they became involved in a project of this sort, I couldn't see them opening it's infrastructure to anyone else, which would destroy the value of the project for the intended use in the article.
Hubble was designed for operation for a particular period of time. With shuttle flights being limited and us now being down 2 shuttles from the fleet, we have to prioritize it versus other projects.
They are currently building robots in Canada for use to repair and keep Hubble operational. These robots will be used to keep it up, however, there is a much better solution if we can get the budget.
What better solution?
If there were a telescope attached to the ISS and if there were a telescope attached to the new station they are talking about building for assembly of the CEV, these telescopes would both be free of the earth's atmosphere, and (more importantly) would be somewhere where it would be easier to maintain them long term. Not trivial, but easier.
Also, if we were to have a semi-permanent base on the moon (which isn't inconceivable), one would imagine that a telescope on the dark side of the moon might be able to provide as good or better imaging as well, and if there were a permanent or semi-permenant human presence, could be maintained easily.
... it sent without clicking submit.
Anyway, they have full source for what the code looked like when IBM bought it from AT&T, they have full code for Linux, if they want it. So they can prove where the code came from. Presumably, the kernel folks have a log of what they accepted from IBM in CVS/SVN...
I don't understand here why they need IBM to do anything.
So far as the BSD code, the BSD code should carry a BSD copyright still, and therefore if Linux did use any of it, the BSD copyright should be there. You cannot just apply GPL across someone else's code and call it your own -- SCO, BSD, whoever. BSD's license would let you use it in the kernel while following GPL, but you would have to still preserve the BSD copyright on code you copied from BSD.
I didn't see this in existing comments, so adding it myself.
What exactly does SCO want from IBM?
SCO has the full source to Unix. They should have, for historic reasons, some indication as to what the source looked like when IBM bought it from AT&
To do business in China, you have to go through the government there.
China wants the internet filtered -- they are installing government firewalls, and you cannot access internet except through them.
So China goes to Symantec and says "either you mark this as a trojan and remove it, or you cannot sell in our Country" and Symantec does it. No suprise.
Not foolproof by far.
The channel on which right/wrong answers are being communicated must be secure for this approach to work.
If both channels are compromised, then Eve can very effectively perform a man-in-the-middle. Once both channels are compromised, Eve can monitor without detection.
Well, think of it this way...
If it were this easy to bypass the security on the network, then nobody would be paying for calls. The IP address does not let you deliver a message to the phone, period.
There is going to be a secure session between the phone and the provide, plain and simple. Vonage doesn't want you to make a call without going through their servers, because then they cannot bill you. They do not wnat you receiving a call without going through their servers, because they cannot bill you.
Granted, it is unlimited calls per month, but if you don't pay, they are able to shut down your service. The most efficient way of doing this is to have the device on your network open a secure channel, and to use only the secure channel.
This is pure paranoia unless there is a security hole, and one would hope that the VoIP companies would have the capability to patch the software running the phone so that they could replace it when/if a hole is found, since it directly impacts their ability to charge for the service.
Getting a call into the voice mail would require hacking their service. Even if there were gateways between providers to route over internet, those would use some form of mutual authentication.
This article is pure and total FUD.
Slashdot Mirror
This is the point in Steam...
You have a user ID, you have a password, you use them to play many games. You don't even need the physical media for HL2 to play it, just log into Steam, choose the game from the list, click play.
If you installed from CD, you can uninstall the game, log into steam, choose to play it and it will reload it without a need for a CD.
So in this case, there's no point in a crack at all.
That was a user comment, if you didn't notice, not Microsoft's comment.
Also...
Just FYI -- most of the ASP.NET issues can be corrected by adding FireFox to either machine.config or web.config (former is global, latter is local).
Microsoft's default web.config only handles IE -- it does not handle even mobile devices correctly. Do a search for browserCapabilities on CodeProject, download it, and install it and FireFox will be a lot happier with ASP.NET-served sites.
The help system also uses IE, as does Windows in some places, so it isn't always spyware, either.
The key phrase here is "operates in the UK."
The problem here is that in the US, we currently have no laws requiring this at a federal level. Enforcing European laws internationally is unlikely to happen; the US has tried to shut off sites that aren't operating within US laws internationally, and the WTO has turned us down every time (gambling, etc.).
The other big problem is defining spyware accurately and consistently.
I have real problems with some of the programs that AdAware and Spybot flag as spyware/malware. Some of these programs shouldn't be flagged, but are.
When a Virus Scanner finds a virus, you can usually exclude it from future scans. When a Virus Scanner finds a virus, you can usually click on a button to have an accurate description of what it does, and what its impact is.
I think that what's really needed is to have some system of categorizing risks in the spyware systems, so you can say "hey, you know what? it's OK for a program to 'phone home' for DRM, but I don't want it tracking me."
An example of this would be wild tangent, which phones home for DRM purposes. When you view wild tangent content, whoever wrote the content gets billed. It has to phone home to do that, and personally, I don't see it as a privacey risk, and it's not a performance risk since the client is only loaded if you view a site that HAS tangent content.
At the very least, the amount of information removal programs give needs to be greatly improved.
A lot of people are theorising OS here...
Microsoft Avalon is an XML system for writing rich clients that operate on data stored on a server. For the technical people, you have a secure XML Web Service that provides the Model and Controller of a MVC application, and then you have the rich client providing the View and a proxy into the controller.
I am not going to say "this is what Google is going," but Google would have to be scared about this, since in order to use these new features, you have to install a new Microsoft OS and IE, and in the process msn.com/search.msn.com probably take over the browser, and all their tools might not be loadable, etc.
Meanwhile, Microsoft is pushing ease of deployment of applications and security of data as big selling points to this model. If your document never leaves the server, even when you are editing it, if you e-mail a link which is secured at the server, then the document itself becomes much more secure.
And, of course, DRM is trivial when everything has to be routed through the server, too.
If you're google, you're sitting there though going, well we can write XML Web Services, and we can write desktop applications. You might look to develop an alternative, say using Java and XUL for the client application.
You might think user's trust us with their e-mail, and send sensitive documents. We could reuse our storage back end to store word processing documents, we could index them, and serve ads based on that information.
You might think we could provide a word processor for free (as in cost) using this revenue, just as we provide search, webmail, etc. now.
I'm not saying that is what they are doing, but it seems a lot more likely (since it would tie into Google's strongest traits as a company, including name recognition and perceived integrity) that developing a new operating system (which would be outside Google's current realm of strengths).
My stack of DVD-RAM disks that is a backup of 4 different computers disagrees strongly that 9g is enough storage. I use double sided disks with 4.7g/side (9.4g total) right now for backup.
Autoupdating is a good idea, the problem on Windows is the design of the OS and programming environment.
/opt
/opt, make a folder for each vendor's product: /opt/vendor1 /opt/vendor2
.NET style security policy is applied to each program. The default settings disallow network access, disallow file access outside the chroot jail, etc.
/lib in from of the system lib's, etc.
On Linux, make a directory:
Under
(note vendor here could include package maintainers, organizations, etc. not necessarily a commercial vendor)
All the vendor's software is chrooted to this base folder when it runs, and the base folder is determined from a digitally signed package with a trusted root authority listed (note: trusted doesn't necessarily mean commercial -- Debian could maintain its own CA, for example).
Additionally, a Java or
When running a vendor's app, you put their
Now if Another Useless toolbar (AUT) installs itself, it can't perform its spyware functions without obtaining authorization from the user. The user can select whether the program should have access or not.
Meanwhile, the system administrator can lock the policy, etc. so that end user's can't modify it or grant permission, and can grant permission to applications that they know are safe.
It's that easy.
The issue with conflicts has never been the auto updater in Windows, the issue has been that program XYZ installs library ABC into \Windows\System32, and then program 123 needs a different version, and installs an incompatible version over the top.
Spyware/Malware replaces some files sometimes in order to "get in deep" where it can't be removed.
If you remove the capability of non-OS provided files to install themselves into places reserved for OS-provided files, then you remove the primary issue with application compatibility.
Additionally, if program XYZ just can't function with the patched version of libC, you have a standard, known, easily obtainable folder to put the copy of the file that program needs to ensure it gets that copy of the library until you're ready to upgrade it.
Windows "kind of" supports this, but it's half hearted and not well thought out, and most vendors have ignored it totally.
The issue is that LSB needs to evolve over time. The current standard is outdated and hasn't been applied by most vendors in several years.
.NET (or a similar solution), as these have widespread support over many platforms at this point, and require only a single package and handle versioning relatively well.
LSB is absolutely critical to taking on Windows, and needed to be updated. There cannot be dozens of packages that have to be maintained by those of us writing software for Linux. This makes the user experience bad for people who aren't computer science majors and can't work configure, GNU C, etc.
Installing a program from binaries should be the single simplest thing a user ever has to do. It should be simple and consistant across all distributions. An individual distribution may have a "better way of doing it" (dpkg vs rpm, etc.), but the user experience needs to be consistent, and there needs to be a set of features, libraries, etc. that package maintainers can write to to be able to say:
"Click here to install the GNU/Linux LSB 2 package"
Windows has been to this point for a long time. You don't see a lot of programs saying "click here for Windows 95, click here for NT." There are programs that do, just not many. Even in the Windows 3.1 to 95 transition, you saw a lot more programs that used Win32s and just shipped a 95 version than that shipped both versions.
GNU/Linux needs to get there. Diversity is fine, version numbering is confusing across the board. The kernel version is usually stated on the box or on the information on the website. Versions of other pieces aren't commonly reported.
Being able to say "LSB 2.0" and being able to have a LSB 2.0 package that installs on all LSB 2.0 plaftorms is absolutely critical.
From a developer standpoint, the most attractive alternative is to use Java or ECMA
A lot of people seem to have not read the article (including potentially the poster of the story)
.NET CLI and CLR on them. This means you can send ECMA compliant code, such as code compiled with Mono, to the smart card and it can run it, if you use their tool.
.NET why not Java." This is a third party, not Microsoft. Java involves purchasing a license from Sun for commercial use (to make a Java-logo compliant JVM), while .NET involves downloading a specification from ECMA for free.
.NET implementation on it, Microsoft bought a bunch of them and wants to use them for security.
1. Microsoft purchased smart cards to upgrade their existing smart cards that they use for system and facility access. This is said explicitly about 2/3 of the way down.
2. Microsoft was the first to purchase this particular type of smart card.
3. The smart cards have an ECMA-compliant implementation of the
4. The smart cards ship with the device driver and libraries to work with it.
People are going "why
So far as raw assembly being superior, I'm not even going to touch that one except to say that the processor is junk on these things, you need isolation of code, the best way to get it is a VM of some sort you might as well use a standard one for which tools are available as roll your own.
So this is the situation. Some company released a smart card with an ECMA compliant
This doesn't really involve anyone outside of Microsoft (it really doesn't), doesn't involve embrace and extend or FUD, or anything else that's been brought up in the comentary.
And it's not some great shocker that Microsoft doesn't like passwords, as a lot of people have said. For years, most of the industry preached passwords as the way to go. With a few exceptions, most people understand now that users are generally stupider than the chairs that they sit in, and either write down their password, chant it while they type, or use the same password everywhere. Also, if you require a user to change their password every 30 days, generally they achieve this by attaching a number and incrementing it.
The good news is hackers have been getting dumber, too, so they're unlikely to realize the user uses Pa$$word10 one month and Pa$$word11 the next...
It costs a fixed amount of work to move a 100kg (or any mass) payload 1m (or any other constant distance) anywhere in our universe (so far as we know). Any technology that is reuseable can potentially do the work, so you must look at the costs and risks of the tecnologies. A space elevator has cables which provide a huge surface area against the atmosphere, a system we don't fully understand and a system which impacts every other system on our planet. We don't know what the impact of that could be, but it has the potential to shift weather globally, intentionally or not. You have environmental forces acting on the cable throughout it's length, and you have temprature differences acting on the cable throughout it's length. All this energy entering the system msut go somewhere, and most of it isn't in a form that can be readily applied to propulsion. You have a temprature difference of at least 100c between the base and summit, and probably more than that. You have a potential difference along the whole thread, which means electrons are going to want to flow, destructively or not. You might be able to use this as a power source, but more likely it would be random and difficult to control. You have corrossive forces acting against the cable, and the entire structure from ground to top must be actively maintained and monitored. The platform must have thrusters. The corces applied to the cables will turn the cable into a giant lever. the platform must expend energy to counter the force of the lever. The platform, however, has to use pure thrust to accomplish this, there isn't a simple machine it can use, and gyroscopes control only attitude, not position. I'm not saying this is a bad idea, or that it's not possible, etc. But there are a lot of technological problems with it that would need to be ocercome. The article says "Nasa is abandoning economical space travel to pursue the vision." This is a false assertion based on the bias of the author of the article. Nasa is doing what government and industry most often do, and pursuing "safer" technologies. The risk is, you spend $4b on a space elivator and have nothing to show at the end. The structure is theoretical, so whether it might work or not is a theory and nothing more. There are a lot of unknowns and ther eis a lot of risk. You spend that same $4b on improving efficiency of existing technologies or developing new derivatives, and you have many fewer unknowns and a much lower level of risk. Risk drives spending. If you have a risky venture, then try a venture capitalist -- they make their money by taking good risks. So far as the DoD goes, Nasa's current approach to economical space travel -- i.e. improve the economy of existing infrastructures, build new derivatives that work with existing infrastructures -- fits much more with their specific needs. It's not just about getting the spy satalite into space for them. They need to minimize the number of people with exposure to it, they need to minimize its presence on civilian structures. Something that they can launch from an airforce base off of a conventional landing field fits those needs much more than a needle would. It's not just the matter of moving the cargo to the needle, it's the matter of minimizing contact of the cargo with non-military personnel and launching it from as close to its point of origin as possible. Economy isn't the primary concern here, physical security of the payload is. For this reason, I couldn't see them taking this project on in any way that would benefit civilians or industry. If they built such a thing, I would think that they would keep it to themselves. After all, you don't see other pieces of the military infrastructure being routinely used for civilian use. For example, I live near Write Paterson Airforce Base. When I flew to Australia, I flew out of an airport 30 minutes farther away from Write Parterson Airforce Base, because obviously the airforce base doesn't want me using their infrastructure -- their infrastructure is solely for their use. If they became involved in a project of this sort, I couldn't see them opening it's infrastructure to anyone else, which would destroy the value of the project for the intended use in the article.
Hubble was designed for operation for a particular period of time. With shuttle flights being limited and us now being down 2 shuttles from the fleet, we have to prioritize it versus other projects. They are currently building robots in Canada for use to repair and keep Hubble operational. These robots will be used to keep it up, however, there is a much better solution if we can get the budget. What better solution? If there were a telescope attached to the ISS and if there were a telescope attached to the new station they are talking about building for assembly of the CEV, these telescopes would both be free of the earth's atmosphere, and (more importantly) would be somewhere where it would be easier to maintain them long term. Not trivial, but easier. Also, if we were to have a semi-permanent base on the moon (which isn't inconceivable), one would imagine that a telescope on the dark side of the moon might be able to provide as good or better imaging as well, and if there were a permanent or semi-permenant human presence, could be maintained easily.
... it sent without clicking submit. Anyway, they have full source for what the code looked like when IBM bought it from AT&T, they have full code for Linux, if they want it. So they can prove where the code came from. Presumably, the kernel folks have a log of what they accepted from IBM in CVS/SVN... I don't understand here why they need IBM to do anything. So far as the BSD code, the BSD code should carry a BSD copyright still, and therefore if Linux did use any of it, the BSD copyright should be there. You cannot just apply GPL across someone else's code and call it your own -- SCO, BSD, whoever. BSD's license would let you use it in the kernel while following GPL, but you would have to still preserve the BSD copyright on code you copied from BSD.
I didn't see this in existing comments, so adding it myself. What exactly does SCO want from IBM? SCO has the full source to Unix. They should have, for historic reasons, some indication as to what the source looked like when IBM bought it from AT&
To do business in China, you have to go through the government there. China wants the internet filtered -- they are installing government firewalls, and you cannot access internet except through them. So China goes to Symantec and says "either you mark this as a trojan and remove it, or you cannot sell in our Country" and Symantec does it. No suprise.
Not foolproof by far. The channel on which right/wrong answers are being communicated must be secure for this approach to work. If both channels are compromised, then Eve can very effectively perform a man-in-the-middle. Once both channels are compromised, Eve can monitor without detection.
Well, think of it this way... If it were this easy to bypass the security on the network, then nobody would be paying for calls. The IP address does not let you deliver a message to the phone, period. There is going to be a secure session between the phone and the provide, plain and simple. Vonage doesn't want you to make a call without going through their servers, because then they cannot bill you. They do not wnat you receiving a call without going through their servers, because they cannot bill you. Granted, it is unlimited calls per month, but if you don't pay, they are able to shut down your service. The most efficient way of doing this is to have the device on your network open a secure channel, and to use only the secure channel. This is pure paranoia unless there is a security hole, and one would hope that the VoIP companies would have the capability to patch the software running the phone so that they could replace it when/if a hole is found, since it directly impacts their ability to charge for the service. Getting a call into the voice mail would require hacking their service. Even if there were gateways between providers to route over internet, those would use some form of mutual authentication. This article is pure and total FUD.