The chips by themselves can't make unauthorized copies, so are they still breaking the contract? If they are, that means they can't sell the case, the sound jacks, the CPU,...
Breaking news. Today, unnamed sources at the pentagon have confirmed the existance of a covert, technical ops group whose sole mission is to create a national defense army of worms, designed to seek out and destroy malicious, terrorist worms that have infiltrated our homeland. Under authorization of the Homeland Security Act, these elite hackers, are devising worms to not only destroy the terrorist worms, but to reprogram every computer around the world in an effort to shutdown the global terrorist network of worms. When contacted, Richard Stallman of the FSF, was quoted as saying "While I like the idea of stopping global terrorist worms, the FSF is fundamentally opposed to ANY closed software worms. This special technical ops group needs to make their worms open and free."
If you ever get hit with a trojan horse that gains root, oops, I mean "administrator", priviledges, you should reinstall or go to a back-up.
Unless you want your PC to be someone's b*tch, you need to press the "do over" button, i.e. do a system install or recovery and install the proper patches to prevent another root, I mean "administrator", comprimise.
Even if the "known" exploit is reported to doing nothing harmful, there is no guarantee that you haven't been comprimised by a clever variant of the exploit. Any of the system programs could be replaced with a copy that opens a back door when it starts.
Once you get comprimised, it's GAME OVER and some script kiddie OWNS you.
And that is to have a decrypter embedded in everyone's ears and eyes. The music/video can then be played publicly, but only the people that PAID for valid decryption keys, encapsulated in their heads, can listen to the music or watch the video.
For ANY audio/visual media, hardware/software can be built to read the output before it goes to the output device (speaker/screen) and record it into a unencrypted format. Virtual sound drivers or virtual moniters can record as easy as outputting to the device.
All of the recording and movie industries' efforts to control audio/video output is mearly slowing down the inevitable - no restrictions for private, fair use.
Of course, the other way is to arrest anyone who has private, peer-to-peer communication - which, considering the current political climate, doesn't sound too crazy.
Apparently they didn't actually open source UNIX. SCO retained the rights to the code. Here's a link on LinuxToday to comments made by Bill Baxter. Seems like he had it figured out in Feb. 2000.
Bill Baxter - Subject: Not Open Source, I'm afraid. ( Feb 23, 2000, 00:01:50 )
Note that these releases are not open source. SCO retain rights to the source code. Maybe they even hope that some of their code will wind up in linux, so that they can then sue, and render the Linux license terms invalid. Or would they be that spiteful? My guess == yes.
"hmmm..., if the Athlon XP 3200+ actually operates at 2.2Ghz, then, assuming the new chips start at 2.2 Ghz, we can market them as 3200 * 130% or 4160. Heck, just round it up to 4200+"
I want a laptop with a 21" screen. A portable portfolio sized laptop. full sized keyboard dual processor multi drive. (and about 2 minutes of battery life ) That's where i'll spend my 5 grand.
What they stole was "excess bandwidth". They can only burst up in speeds when they're is excess bandwidth. Otherwise they're connection speeds are the same as everyone elses when the network is bottle necked.
" The more the customer uses, the less there is to go around for other customers. These customers were impacting the performance of all our other customers."
If there is not enough to go around, then everybody gets throttled back. The bottle neck would occur at the ISPs up link and the capacity should be scaled evenly between the connections - not just the one with the extra burst. If they can get more than their share out of the pipe, then everybody else can get at least their share. The only way that they could have impacted other customers if they were running a web server or something that may be serving up hundreds of connections at one time or if they can change a routing QOS setting through the modem. Otherwise they are just using unused bandwidth.
Sound like you might be on one of my former projects:-)
If you have multiple levels of testing, (e.g. unit testing, integration testing, acceptance testing, performance testing, etc.), then you are in a large, complex environemt. This environment probably has had several hundred developers working on a few thousand different programming modules at different release levels. Unlike a program like a browser that may have 50 or so basic functions that it can perform, this environment has probably several thousand function points that span an enterprise.
Each level of testing is designed to catch different types of errors. A program that passes a proper unit test should have bug free code, i.e. no core dumps or segmentation violations and proper exception handling.
A set of programs are tested together in integration testing to verify that the programs are calling each other properly and are performing basic business functions, e.g. adding a new user, maintaining account info, routing calls, etc.
Acceptance testing is designed to ensure that the user of the system can perform his mission critical business tasks with the new system. Acceptance testing will also allow the end users to verify that what they are getting is what they asked for. Every business case scenario should be performed during acceptance testing by the ultimate users of the system.
Performance testing is used to identify bottlenecks when running the system against a fully loaded database/system. When a programmer is building the initial program, the test bed used is only a fraction of the size of the ultimate database to handle tens of millions of customer accounts.
There are several problems that manifest in these environments. First and foremost is sheer incompetence, from management to designers to programmers to database and system administrators.
These large, complex environments allow for incompetence to go unfettered under the cloud of technology. Errors that are made often go unchecked and when they are discovered, there's no accountability to the individual that made the error.
Programmers rush to meet deadlines and don't properly test their code. A designer may not include certain business functions that are required to complete a business scenario. Management may make decisions based on trade magazines or a sales pitch and those decisions could introduce instability into the product (i.e. use MS in a clustered 24x7 SQL Server environment). You get my drift.
Second is empowerment. A programmer may know of buggy code and even identify the bug, but code is locked down and has a defined migration path that has to be adhered to. Applying a quick fix and throwing the code to a location available to all programmers is not facilitated. Most of these enviornments have not made the paradigm shift from a traditional version control tool like SCCS or PVCS to the open source approach of CVS. With CVS a programmer can't lock the code in a project.
Anyway, these levels of testing are essential in delivering enterprise wide solutions. Unfortuanately, the levels of testing in themselves do not ensure success. Without proper quality assurance (e.g. peer reviews of test plans, detailed designs, technical architecture approach documents), good communication and life-cycle accountability (sure you completed it on time and within budget, but it was crap - you're fired!), buggy code will prevail.
Slashdot Mirror
The chips by themselves can't make unauthorized copies, so are they still breaking the contract? If they are, that means they can't sell the case, the sound jacks, the CPU, ...
Breaking news. Today, unnamed sources at the pentagon have confirmed the existance of a covert, technical ops group whose sole mission is to create a national defense army of worms, designed to seek out and destroy malicious, terrorist worms that have infiltrated our homeland. Under authorization of the Homeland Security Act, these elite hackers, are devising worms to not only destroy the terrorist worms, but to reprogram every computer around the world in an effort to shutdown the global terrorist network of worms. When contacted, Richard Stallman of the FSF, was quoted as saying "While I like the idea of stopping global terrorist worms, the FSF is fundamentally opposed to ANY closed software worms. This special technical ops group needs to make their worms open and free."
Cheers
If you ever get hit with a trojan horse that gains root, oops, I mean "administrator", priviledges, you should reinstall or go to a back-up.
Unless you want your PC to be someone's b*tch , you need to press the "do over" button, i.e. do a system install or recovery and install the proper patches to prevent another root, I mean "administrator", comprimise.
Even if the "known" exploit is reported to doing nothing harmful, there is no guarantee that you haven't been comprimised by a clever variant of the exploit. Any of the system programs could be replaced with a copy that opens a back door when it starts.
Once you get comprimised, it's GAME OVER and some script kiddie OWNS you.
And that is to have a decrypter embedded in everyone's ears and eyes. The music/video can then be played publicly, but only the people that PAID for valid decryption keys, encapsulated in their heads, can listen to the music or watch the video.
For ANY audio/visual media, hardware/software can be built to read the output before it goes to the output device (speaker/screen) and record it into a unencrypted format. Virtual sound drivers or virtual moniters can record as easy as outputting to the device.
All of the recording and movie industries' efforts to control audio/video output is mearly slowing down the inevitable - no restrictions for private, fair use.
Of course, the other way is to arrest anyone who has private, peer-to-peer communication - which, considering the current political climate, doesn't sound too crazy.
Cheers
Bill Baxter - Subject: Not Open Source, I'm afraid. ( Feb 23, 2000, 00:01:50 )
Who would have thunk.
"hmmm..., if the Athlon XP 3200+ actually operates at 2.2Ghz, then, assuming the new chips start at 2.2 Ghz, we can market them as 3200 * 130% or 4160. Heck, just round it up to 4200+ "
I want a laptop with a 21" screen. A portable portfolio sized laptop. full sized keyboard dual processor multi drive. (and about 2 minutes of battery life ) That's where i'll spend my 5 grand.
cheers
That's like saying - "I didn't break my agreement because it doesn't explicitly say I can't use a black box to get premium channels"
What they stole was "excess bandwidth". They can only burst up in speeds when they're is excess bandwidth. Otherwise they're connection speeds are the same as everyone elses when the network is bottle necked.
" The more the customer uses, the less there is to go around for other customers. These customers were impacting the performance of all our other customers."
If there is not enough to go around, then everybody gets throttled back. The bottle neck would occur at the ISPs up link and the capacity should be scaled evenly between the connections - not just the one with the extra burst. If they can get more than their share out of the pipe, then everybody else can get at least their share. The only way that they could have impacted other customers if they were running a web server or something that may be serving up hundreds of connections at one time or if they can change a routing QOS setting through the modem. Otherwise they are just using unused bandwidth.
Sound like you might be on one of my former projects :-)
If you have multiple levels of testing, (e.g. unit testing, integration testing, acceptance testing, performance testing, etc.), then you are in a large, complex environemt. This environment probably has had several hundred developers working on a few thousand different programming modules at different release levels. Unlike a program like a browser that may have 50 or so basic functions that it can perform, this environment has probably several thousand function points that span an enterprise.
Each level of testing is designed to catch different types of errors. A program that passes a proper unit test should have bug free code, i.e. no core dumps or segmentation violations and proper exception handling.
A set of programs are tested together in integration testing to verify that the programs are calling each other properly and are performing basic business functions, e.g. adding a new user, maintaining account info, routing calls, etc.
Acceptance testing is designed to ensure that the user of the system can perform his mission critical business tasks with the new system. Acceptance testing will also allow the end users to verify that what they are getting is what they asked for. Every business case scenario should be performed during acceptance testing by the ultimate users of the system.
Performance testing is used to identify bottlenecks when running the system against a fully loaded database/system. When a programmer is building the initial program, the test bed used is only a fraction of the size of the ultimate database to handle tens of millions of customer accounts.
There are several problems that manifest in these environments. First and foremost is sheer incompetence, from management to designers to programmers to database and system administrators.
These large, complex environments allow for incompetence to go unfettered under the cloud of technology. Errors that are made often go unchecked and when they are discovered, there's no accountability to the individual that made the error.
Programmers rush to meet deadlines and don't properly test their code. A designer may not include certain business functions that are required to complete a business scenario. Management may make decisions based on trade magazines or a sales pitch and those decisions could introduce instability into the product (i.e. use MS in a clustered 24x7 SQL Server environment). You get my drift.
Second is empowerment. A programmer may know of buggy code and even identify the bug, but code is locked down and has a defined migration path that has to be adhered to. Applying a quick fix and throwing the code to a location available to all programmers is not facilitated. Most of these enviornments have not made the paradigm shift from a traditional version control tool like SCCS or PVCS to the open source approach of CVS. With CVS a programmer can't lock the code in a project.
Anyway, these levels of testing are essential in delivering enterprise wide solutions. Unfortuanately, the levels of testing in themselves do not ensure success. Without proper quality assurance (e.g. peer reviews of test plans, detailed designs, technical architecture approach documents), good communication and life-cycle accountability (sure you completed it on time and within budget, but it was crap - you're fired!), buggy code will prevail.
Cheers
jpg