The difference between this and the Apple problem is with standards. Apple's drives work correctly when using media that conforms to the appropriate standards. The copy-protected disks in that instance were explicitely breaking the standards, so it was the media that was at fault. That's why Philips stated that that type of media was a shiny plastic disk or something - but it was not a CD(tm).
With his problem, if the Mandrake installer is conforming to standards when accessing the drive, and the drive fails because it doen't meet those standards, then it's the drive at fault. If however, the Mandrake installer is pushing something too far and stepping outside the boundries the standard specifies, then Mandrake would be at fault.
It appears at this point that they (Mandrake) are still looking into which of the two above it is.
As someone posted above, SCO hasn't actually sent the bills they claim they're going to. Once they actually send invoices to people for something those people never purchased, intended to purchase, or agreed to purchase, then those people can persue legal action. This may include RICO, Mail Fraud, or other charges. The problem is that SCO keeps saying "We're gonna real soon now..." but still hasn't done anything other than talk the talk.
AOL spokesman Nicholas Graham said the company had not yet reviewed the lawsuit.
Umm... If a preliminary injunction was won by CIHost last Friday, shouldn't AOL have at least reviewed the suit even if they didn't wish to represent themselves in court?
I think the "participated" point is that she may have downloaded files from kazaa, but if she wasn't allowing uploads than she is not guilty of the "crime" the RIAA assumes.
Personally, I've been waiting for someone to offer this defense. By either configuring the P2P application to not allow uploads, or by blocking the port used for uploads at a firewall, you can have thousands of song titles appear as shared when in fact they are not. From all I've read about the RIAA methods, they don't actually download any of the files, they simply compiled a list of accounts showing thousands of files shared. That in itself is not a violation. To be in violation of their Copyrights, the user has to actually allow those files to be downloaded from their PC.
In summary, this WILL benefit the public - by setting the precedence that the RIAA must show the person was actually sharing and not just appearing to share their Copyrighted works.
Face it. There is stolen code in Linux. How much and how severe the value of the theft is to be determined but that there was theft is almost certain.
Not exactly!
It may show that there is identical code in Linux and Unix, but that in no way "proves" the code was stolen from the latter! The code may have come from BSD, it may have been stolen from Linux and copied into Unix, some of it may be OEM code that was released by a hardware vendor to many platforms with the same comments but slightly different actual code. There is no way possible to determine any of this with what pathetically little has been shown.
Which returns to the point that most here have. If this the all they can show - they've got crap for a case! If they have some "smoking gun" type example, then show it so the matter can be resolved. Using "smoke and mirrors" to extort money from Linux users is NOT an acceptable tactic.
1. If the Red Hat vs. SCO goes to trial before SCO vs. IBM SCO will need to substantiate their claims earlier then they would have wanted giving IBM prep time.
No! IBM has all the prep time they need because they are the defendant and already (or shortly will) have the specific details the rest of us dont - it's called the Discovery Phase. This is the phase that the SCO vs. IBM suit is at now.
The only thing this may do regarding substantiating their claims is with the public. If the court documents in the RedHat vs SCO suit are released publicly rather than being sealed, then we can learn the specifics. SCO will of course fight to keep the details sealed in the RedHat case as well, so don't count on learning anything new.
Exactly, he lost me when he got to scalability. He starts that section with a little quip about there being no clear definition of what scalability is - so no matter how wrong he gets it, he can just say "well this is MY definition".
Given that, he then goes on to describe something more accurately called a migration path. Scalability, in all the years I've been in IT (god! Almost 20!) has always referred to handling an increase in load. Whatever the load for the particular system is, ie. a Transaction Processing System is scalable if it can expand easily to support an increase in the number of transactions per second it needs to process. This has nothing to do with migrating to newer hardware or whatever.
Also, to claim FreeBSD doesn't support multiple processors is simply pathetic. Back when Walnut Creek hosted the FreeBSD ftp server, it had the record for most data transferred how many years in a row on a multi-processor Intel box?
Alas, as I said, he's indemnified himself of any corrections by stating there is no one correct definition (in his mind). At least if he got it wrong but showed a hint that he'd accept being corrected if it turned out he was off-base by a bit I could consider the rest of his article worth reading. As it stands, it's disappointing to see any valid points overshadowed by the ignorance/inaccuracy of others.
Perhaps the near-constant media hostility towards any and everything Apple does/doesn't do contributes greatly to this issue.
If Apple announces a new product/model, everyone looks first at the Apple Store to have it in stock. If Apple shipped limited supplies of a new line to independant Apple dealer's, and not to their own stores, clueless market analysts would drive their stock price into the toilet claiming they can't deliver what they've just announced.
To avoid this, it would make sense to be sure the Apple Store's have the latest announced product ready and waiting on the shelves.
This is, of course, pure speculation. But if I were an Apple exec, I'd definately make sure "we" had what "we" just announced, even if it meant "they" would have to wait a couple more weeks for additional shipments.
The basic religious mantra of the Neo-Con's is that Satan is due to rise up in Babylon (Baghdad). Once man defeats Satan, then Christ will come back and lead all the Good Folks(tm) to Heaven.
So.... Sending Satan...err Ms. Rosen to Baghdad makes sense. Once there, she can be nuked and all the Good Folks(tm) will be off to the Promised Land.
I wonder though, how much of an effect increasing job security would have on increasing employee adherence to security policies. It seems that there are alot of people around that just don't really care because their employer doesn't. If you're treated like a commodity item, replacable on the slightest whim; underpaid and given increasingly lower quality benefits, are you really gonna maintain an attitude where protecting company data is important?
I've been in companies that do periodic unannounced audits, looking for this stuff. They will fire on the spot someone who fails in order to scare others into adhering to policy. If the indications (not that I trust the actual statistics presented) are correct and there are still more than half of workers who would fail at any given time, perhaps positive reenforcement would improve those numbers. Negative doesn't appear to be doing the trick. People face the prospect of losing there jobs on a moments notice for meriad other reasons - giving out their password probably just doesn't rate high on a "Things to do to keep your job" list.
Well, the proactive approach to that is putting a "Vacation Hold" message in the box, or better yet bring to the local Post Office. Then they know you're coming back on a specific day and will simply hold it all at the PO rather than sending it back as undeliverable.
I had an experience years ago in a full time regular position. I was in the server design/admin group and a business group of the company bought a piece of crap transaction processing system without our review first. As a result, when the system began to severely buckle under the load they were throwing at it, the vendor advised us to drastically exceed the manufacturer's design specs to try and tweak performance. He should have been focusing on fixing his sloppy, unscalable application.
During a conference call with the vendor in the CIO's office, with several other executives from the impacted business groups present, the vendor reiterated his idea. As the one stuck administering this horrendous system, everyone turned to me to see how soon I could implement the changes. I refused to do it, plain and simple. My direct manager said basically "you'll do it if I tell you to". My reply was "No, I won't do this. It exceeds the manufacturer's specs so far that it puts company data at great risk. You can fire me and have someone else do it, but it won't be me. I have an obligation to the shareholders of this company to protect their assets, including the data processed by this system, and I won't put that data at such a risk"
After picking his jaw up off the floor, and everyone else reinserting their eyes into their skull, the CIO turned back towards the phone and said "Looks like we need a better solution!"
I could have been easily fired on the spot, but instead the CIO was impressed with my courage and figured I had to have a solid point to be that bold. A few months later, the crappy system was replaced with a solution from another vendor that scaled to our requirements.
Umm if they work at Apple and are caught releasing stuff like this they are FIRED! In today's job market, there's an even bigger incentive to avoid doing things known to get yourself fired. As much of a flogging the individual developer (if identified) would face, losing their job would not likely be an issue.
Well, he used a bulldozer when a screw driver would do;)
I think the issue is that he used a different bulldozer. As he stated, he'd "(re)installed this particular OS more times than I care to recollect". That can easily be seens as being forced to use a bulldozer when a screwdriver should be available. So rather than continuing that trend, he bought a different bulldozer.
As for the expensiveness of his choice, perhaps value of his time - having been eaten up by all of the reinstalls over the years - more than compensates for the cost of a new Mac.
Oh, what the heck... I'll touch on the office suite (notice "office" is not capatilized unless referring to Microsoft Office or such) point too. Plain and simple, there is NO comparable office suite available on the Mac at this point in time. So of course he's going to use it! He's a CTO - not Joe Haxxor, Sheppard of GNU!;-P
You're not understanding what I'm using the term dependant for. Project Builder utilizes gcc, but doesn't have a dependancy on it. PB will run fine without any trace of gcc on the system. PB could easily build your project with an alternate compiler. Think of it more like a web plugin. A browser may utilize the Flash plugin, but in no way depends on it to run.
I don't have the time to find the exact clause at the moment, but the basic premise is that if your app links/depends upon GPL code it must be GPL'd as well. So even though Apple may include gcc along with their dev tools, the dev tools aren't dependant upon gcc. None of MacOS X is directly connected to GPL code because then whatever portion does would also have to be GPL'd. This is what's considered "viral" about it. One call to a GPL'd library and the whole app needs to be GPL.
The available telnet and X Windows servers for MacOS 9 sucked royally. I needed more than telnet, the Sun workstations served additional purposes such as HP OpenView, Tivoli TSM, and other applications.
I started working at Apple in their datacenters doing Unix Admin and Disaster Recovery work. When I started MacOS X wasn't even in Public Beta, so the PowerMac sitting on my desk had MacOS 9.04 on it. Trying to do AIX & Solaris admin from that box was absolutely horrible! Within weeks I had a new Sun Ultra5 on my desk next to the Mac for the Unix work I needed to do, the Mac ran email, calendar/scheduling, and problem tracking system.
Once MacOS X hit Public Beta I was allowed to run it on my system there (actually encouraged to assist in finding bugs). That's the point that I can truly say I started liking the Mac. I hated the "Classic" MacOS and have been free from it since Jaguar was released (didn't install Classic when I reinstalled on my PowerBook).
I left Apple a year ago, but did buy a PowerBook while still working there. I now use my Mac for everything except the couple of PC only games I play.
If you want the purchase music online rather than venturing out in winter, order from cdnow or amazon or some-other-online-store. I purchase what little music I buy from online stores, opting for used CDs whenever possible. I can have them shipped ground in a weeks time, or if really important to me next-day air.
There's a story here that reaches the exact opposite conclusion. Basically, cold, salty, dense polar water sinks and flows towards the equator. Warm, less salty, less dense tropical water flows toward the polar region along the surface. With polar waters warming, and melting ice descreasing the salt levels - this round trip process would stop, causing the cold water to remain at the poles and forming a drastic "instant" ice age.
So, yes, you are missing a large part of the Global Warming argument - the effect on ocean currents, and their impact on the environment.
True, but you as the downloader have no idea ahead of time whether the sharer has implemented such a practice. I have downloaded songs that were missing anywhere from a few seconds to a minute of the song. I've also downloaded crappy rips that have pops and clicks in the song. Since I use downloading to preview songs before purchasing CDs (which I then buy used) it doesn't bother me too much. However, these are still reliability and even quality issues that are inherent in the P2P space.
It would still work today because P2P networks suffer from a simple, frequent, inherent limitation - users LOG OFF!
If you're downloading from them when they logged, tough cookies! You spent 20 minutes downloading at a low average throughput downloading 30% of a song you wanted. Now you go back and search again and find another user with a copy of it, so you start downloading from them. This time the transfer from them to you completes 100% - BUT... their download from someone else crapped out at 72% complete, so the song you got is STILL incomplete!
This problem is called reliability! As hyped as P2P might get in the press and in the minds of advocates - it's still unreliable! If Janis' suggestion were implemented, listeners would have a reliable source to obtain full downloads of quality music. I think most people would be like me and pay up to a quarter for that reliability. My time, as well as most others I'm sure, is worth much more than $.25 for the countless cummulative hours spent dealing with transfer interruptions and abortions.
Yes, however the Sherman Act prevents a single company from abusing monopoly power. It doesn't work so well with an ogilopoly of several companies since theoretically they "compete" with each other.
To make any progress on this front you'd have to bring charges of racketeering against the group of companies for conspiring together to prevent additional competitors from coming to the table. There have already been racketeering and collusion allegations against the MPAA/RIAA members, but so far no convictions which would actually prompt a change.
Slashdot Mirror
With his problem, if the Mandrake installer is conforming to standards when accessing the drive, and the drive fails because it doen't meet those standards, then it's the drive at fault. If however, the Mandrake installer is pushing something too far and stepping outside the boundries the standard specifies, then Mandrake would be at fault.
It appears at this point that they (Mandrake) are still looking into which of the two above it is.
Umm... If a preliminary injunction was won by CIHost last Friday, shouldn't AOL have at least reviewed the suit even if they didn't wish to represent themselves in court?
Personally, I've been waiting for someone to offer this defense. By either configuring the P2P application to not allow uploads, or by blocking the port used for uploads at a firewall, you can have thousands of song titles appear as shared when in fact they are not. From all I've read about the RIAA methods, they don't actually download any of the files, they simply compiled a list of accounts showing thousands of files shared. That in itself is not a violation. To be in violation of their Copyrights, the user has to actually allow those files to be downloaded from their PC.
In summary, this WILL benefit the public - by setting the precedence that the RIAA must show the person was actually sharing and not just appearing to share their Copyrighted works.
Not exactly!
It may show that there is identical code in Linux and Unix, but that in no way "proves" the code was stolen from the latter! The code may have come from BSD, it may have been stolen from Linux and copied into Unix, some of it may be OEM code that was released by a hardware vendor to many platforms with the same comments but slightly different actual code. There is no way possible to determine any of this with what pathetically little has been shown.
Which returns to the point that most here have. If this the all they can show - they've got crap for a case! If they have some "smoking gun" type example, then show it so the matter can be resolved. Using "smoke and mirrors" to extort money from Linux users is NOT an acceptable tactic.
No! IBM has all the prep time they need because they are the defendant and already (or shortly will) have the specific details the rest of us dont - it's called the Discovery Phase. This is the phase that the SCO vs. IBM suit is at now.
The only thing this may do regarding substantiating their claims is with the public. If the court documents in the RedHat vs SCO suit are released publicly rather than being sealed, then we can learn the specifics. SCO will of course fight to keep the details sealed in the RedHat case as well, so don't count on learning anything new.
Given that, he then goes on to describe something more accurately called a migration path. Scalability, in all the years I've been in IT (god! Almost 20!) has always referred to handling an increase in load. Whatever the load for the particular system is, ie. a Transaction Processing System is scalable if it can expand easily to support an increase in the number of transactions per second it needs to process. This has nothing to do with migrating to newer hardware or whatever.
Also, to claim FreeBSD doesn't support multiple processors is simply pathetic. Back when Walnut Creek hosted the FreeBSD ftp server, it had the record for most data transferred how many years in a row on a multi-processor Intel box?
Alas, as I said, he's indemnified himself of any corrections by stating there is no one correct definition (in his mind). At least if he got it wrong but showed a hint that he'd accept being corrected if it turned out he was off-base by a bit I could consider the rest of his article worth reading. As it stands, it's disappointing to see any valid points overshadowed by the ignorance/inaccuracy of others.
If Apple announces a new product/model, everyone looks first at the Apple Store to have it in stock. If Apple shipped limited supplies of a new line to independant Apple dealer's, and not to their own stores, clueless market analysts would drive their stock price into the toilet claiming they can't deliver what they've just announced.
To avoid this, it would make sense to be sure the Apple Store's have the latest announced product ready and waiting on the shelves.
This is, of course, pure speculation. But if I were an Apple exec, I'd definately make sure "we" had what "we" just announced, even if it meant "they" would have to wait a couple more weeks for additional shipments.
So.... Sending Satan...err Ms. Rosen to Baghdad makes sense. Once there, she can be nuked and all the Good Folks(tm) will be off to the Promised Land.
I've been in companies that do periodic unannounced audits, looking for this stuff. They will fire on the spot someone who fails in order to scare others into adhering to policy. If the indications (not that I trust the actual statistics presented) are correct and there are still more than half of workers who would fail at any given time, perhaps positive reenforcement would improve those numbers. Negative doesn't appear to be doing the trick. People face the prospect of losing there jobs on a moments notice for meriad other reasons - giving out their password probably just doesn't rate high on a "Things to do to keep your job" list.
Well, the proactive approach to that is putting a "Vacation Hold" message in the box, or better yet bring to the local Post Office. Then they know you're coming back on a specific day and will simply hold it all at the PO rather than sending it back as undeliverable.
During a conference call with the vendor in the CIO's office, with several other executives from the impacted business groups present, the vendor reiterated his idea. As the one stuck administering this horrendous system, everyone turned to me to see how soon I could implement the changes. I refused to do it, plain and simple. My direct manager said basically "you'll do it if I tell you to". My reply was "No, I won't do this. It exceeds the manufacturer's specs so far that it puts company data at great risk. You can fire me and have someone else do it, but it won't be me. I have an obligation to the shareholders of this company to protect their assets, including the data processed by this system, and I won't put that data at such a risk"
After picking his jaw up off the floor, and everyone else reinserting their eyes into their skull, the CIO turned back towards the phone and said "Looks like we need a better solution!"
I could have been easily fired on the spot, but instead the CIO was impressed with my courage and figured I had to have a solid point to be that bold. A few months later, the crappy system was replaced with a solution from another vendor that scaled to our requirements.
I think the issue is that he used a different bulldozer. As he stated, he'd "(re)installed this particular OS more times than I care to recollect". That can easily be seens as being forced to use a bulldozer when a screwdriver should be available. So rather than continuing that trend, he bought a different bulldozer.
As for the expensiveness of his choice, perhaps value of his time - having been eaten up by all of the reinstalls over the years - more than compensates for the cost of a new Mac.
Oh, what the heck... I'll touch on the office suite (notice "office" is not capatilized unless referring to Microsoft Office or such) point too. Plain and simple, there is NO comparable office suite available on the Mac at this point in time. So of course he's going to use it! He's a CTO - not Joe Haxxor, Sheppard of GNU! ;-P
Tiffany has a crush on you too!
And the link to, or at least the name(s) of, these amazing filters is where????
I started working at Apple in their datacenters doing Unix Admin and Disaster Recovery work. When I started MacOS X wasn't even in Public Beta, so the PowerMac sitting on my desk had MacOS 9.04 on it. Trying to do AIX & Solaris admin from that box was absolutely horrible! Within weeks I had a new Sun Ultra5 on my desk next to the Mac for the Unix work I needed to do, the Mac ran email, calendar/scheduling, and problem tracking system.
Once MacOS X hit Public Beta I was allowed to run it on my system there (actually encouraged to assist in finding bugs). That's the point that I can truly say I started liking the Mac. I hated the "Classic" MacOS and have been free from it since Jaguar was released (didn't install Classic when I reinstalled on my PowerBook).
I left Apple a year ago, but did buy a PowerBook while still working there. I now use my Mac for everything except the couple of PC only games I play.
So, yes, you are missing a large part of the Global Warming argument - the effect on ocean currents, and their impact on the environment.
If you're downloading from them when they logged, tough cookies! You spent 20 minutes downloading at a low average throughput downloading 30% of a song you wanted. Now you go back and search again and find another user with a copy of it, so you start downloading from them. This time the transfer from them to you completes 100% - BUT... their download from someone else crapped out at 72% complete, so the song you got is STILL incomplete!
This problem is called reliability! As hyped as P2P might get in the press and in the minds of advocates - it's still unreliable! If Janis' suggestion were implemented, listeners would have a reliable source to obtain full downloads of quality music. I think most people would be like me and pay up to a quarter for that reliability. My time, as well as most others I'm sure, is worth much more than $.25 for the countless cummulative hours spent dealing with transfer interruptions and abortions.
To make any progress on this front you'd have to bring charges of racketeering against the group of companies for conspiring together to prevent additional competitors from coming to the table. There have already been racketeering and collusion allegations against the MPAA/RIAA members, but so far no convictions which would actually prompt a change.