Microsoft could TRY to USE the DMCA, but it would not apply. Microsoft would most likely bring forth several charges, such as violation of the DMCA, IP theft, patent infringement, etc. etc.
However, the DMCA charge would be dismissed at pre-trial, as it does not apply research performed in the name of academia.
Therefore, Microsoft CANNOT use the DMCA, as stated prior.
But a 120GB IDE HD is ~$133US (www.pricewatch.com), and HD write/reads are *much* faster than tapes. So, for ~$670 (5*133), you get 600 GB of storage space.
Of course, these are numbers used just for your example. DLT tapes are $50 for a 40/80, which is significantly cheaper than a 120GB HD, but a 40GB HD is only $60 (www.pricewatch.com), which means that DLT is a less expensive option when the aggregate amount of data backed up reaches 5TB (terabytes).
The downsides to HD's are the fragility of the drives, the shorter (30yr) shelf life, and the current lack of IDE hot-plugging. The downsides of the tapes are the slow write/read speed, and the fact that they are more prone to bad bit writing than a HD.
That being said, for smaller applications, a second HD as a backup is an excellent idea over purchasing a DLT.
I was intending to purchase only the November version of the LOTR DVD, until Blockbuster video came out with a nice little deal:
purchase a 10 week video rental card (1 rental per week, for a max of 10 weeks, expiring in 2 years) for ~$25.00, and get the LOTR DVD for free.
I would look for deals like this in the near future.
MS cannot use the DMCA, because the DMCA has explicit clauses which preclude persecution of individuals who are circumventing copyright protection schemes in the name of academia.
The last thing that the entertainment cartel wants to do is to force a large, respectable corporation with deep pockets into a position of having to defend itself against a DCMA violation.
The entertainment cartel (or, rather, their enforcers: the US government) would not prosecute HP. They would prosecute Perens personally. Then, once they defeat Perens in court (by hook or crook), the entertainment cartel will pursue HP, using the legal ruling in the Perens case to seek punitive damages in the tens of millions.
To sneak up on you while you are secretly planning to download the latest LOTR Divx using the ACME Kazaa client, and then
Beep! Beep!
Scares the shit out of you, causing you to fall out of your chair, out the door, down the street, and over a cliff where you freefall for 25 seconds, ending up making a little while poof of smoke.
I can picture it now, playing Return to Castle Wolfenstein, with Gnutella running in the background... Suddenly, my framerate grinds to a halt. "F%#!!@ Gnutella findfast"
if analyzing SLOC says nothing about developer contributions, efficiency, or effectiveness - then isn't estimating value based off SLOC fundamentally flawed?
1) SLOC says nearly *EVERYTHING* about developer contributions. After all, the SLOC is what the developer contributes.
2) Efficiency is a measurable metric, and can be quite as simple as (SLOC/MM)-(NumBugs/MM), where MM=Man-Month. While there is a variance in the efficiency of programmers, for any given company a median efficiency can be determined. From this, a decent cost-estimate for SLOC may be determined.
i just don't know why people don't count 'Customer Problems Solved Over Time' as the end-all, be-all.
That collected metric would have almost no utility, unless you could atomize the concept of a 'customer problem'.
"Well, it took us 6MM to craete that web-based
accounting system, so it should take us about
the same to develop these kernel drivers"
Something like the above doesn't help anyone. It doesn't help the programmers who take part in recording the data; it doesn't help the managers plan and predict the product lifecycle; it doesn't help the customer in letting him know when to expect to see the next product release.
What you failed to do was drill down further in your analysis of the problem. Let's say you just finished putting out product "X", which solved some customer problem. Now the customer wants product "Y" to solve some other problem. How do you estimate "Y" based upon "X"? Answer: Break it down. "X" required the following capabilities: A,B,C, and D. You recorded and tracked the amount of time it took to accomplish each capability.
Now, you break down the customer problem, "Y", and determine what it would take to solve it. If you did a good job at atomizing the customer problem on project "X", then you should have been able to come up with an average amount of time/AtomicProblem. Apply this metric and Viola!, you should have a good idea about the scope of "Y". Many people like to take the AtomicProblem and equate it to a SLOC estimate.
What SLOC counting does is try to establish a commonality among various projects so that future projects of various natures may be estimated using previous metrics. This is not perfect, but it should be used as an aid in determining overall project scope and costs.
i mean, you can't have it both ways. Either SLOC shows how productive programmers are, or it doesn't.
SLOC shouldn't be used to estimate programmer productivity. It should be used to estimate project productity.
In his paper, he uses the basic COCOMO model for estimating the cost. This model, quite frankly, sucks. Boehm's book even states, more or less, that the COCOMO model is only accurate to a factor of 10.
Since I no longer have the Boehm book, this quote from a google-found web page will have to do. This is a quote of a quote from Boehm's book, Software Engineering Economics:
"Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on costs."
Basically, this means that the estimate could be anywhere from $100M->10B in true cost.
At the very least, this kid should have stated which of the model variants he was using.
Better yet, he should have subdivided the source code into multiple categories: kernel+drivers, tools, productivity software, etc. etc., and then applied the various models to them.
Just my 2 bits.
BTW, here is the google-found page which has the quote I stole. Plus, it gives a nice, albeit brief, overview of COCOMO.
There are 2 primary things which LucasArts needs to show in order to have a viable lawsuit:
1) Trademark/IP infringement has occurred. 2) As a result of that infringement/trademark, the claimant has incurred direct revenue losses, or their potential for future revenue has been diminished.
Since LucasArts has a solid claim to #2, scummvm's reply should have been the following:
1) To state, very clearly, that the means by which they conducted their reverse engineering was a legally approved (e.g. stating court precedent) process.
2) To expand their umbrella of legal coverage (aka CYA) by aligning their project under the shield of academia.
Slashdot Mirror
I'm afraid you are the one who is incorrect.
Microsoft could TRY to USE the DMCA, but it would not apply. Microsoft would most likely bring forth several charges, such as violation of the DMCA, IP theft, patent infringement, etc. etc.
However, the DMCA charge would be dismissed at pre-trial, as it does not apply research performed in the name of academia.
Therefore, Microsoft CANNOT use the DMCA, as stated prior.
But a 120GB IDE HD is ~$133US (www.pricewatch.com), and HD write/reads are *much* faster than tapes.
So, for ~$670 (5*133), you get 600 GB of storage space.
Of course, these are numbers used just for your example. DLT tapes are $50 for a 40/80, which is significantly cheaper than a 120GB HD, but a 40GB HD is only $60 (www.pricewatch.com), which means that DLT is a less expensive option when the aggregate amount of data backed up reaches
5TB (terabytes).
The downsides to HD's are the fragility of the drives, the shorter (30yr) shelf life, and the current lack of IDE hot-plugging. The downsides of the tapes are the slow write/read speed, and the fact that they are more prone to bad bit writing than a HD.
That being said, for smaller applications, a second HD as a backup is an excellent idea over purchasing a DLT.
I was intending to purchase only the November version of the LOTR DVD, until Blockbuster video came out with a nice little deal:
purchase a 10 week video rental card (1 rental per week, for a max of 10 weeks, expiring in 2 years) for ~$25.00, and get the LOTR DVD for free.
I would look for deals like this in the near future.
-d
MS cannot use the DMCA, because the DMCA has explicit clauses which preclude persecution of individuals who are circumventing copyright protection schemes in the name of academia.
a Simple sip/puff stick would be sufficient
Take all of the prime numbers that have been computed to date, and you could fit it all on a floppy, with probably room to spare for a Word document.
wrong.
f90 does have dynamic memory allocation.
Does the eating of asparagus affect the presence of primes in P?
Inquiring minds want to know!
The poster did say that they had Linux in mind, so it's actually 1 Tera-BogoFLOP.
I think that translates to 27, or so, FLOPS.
-Dennis
Cell Achieves Perfection
(for all you DragonBall Z fans)
The last thing that the entertainment cartel wants to do is to force a large, respectable corporation with deep pockets into a position of having to defend itself against a DCMA violation.
The entertainment cartel (or, rather, their enforcers: the US government) would not prosecute HP. They would prosecute Perens personally. Then, once they defeat Perens in court (by hook or crook), the entertainment cartel will pursue HP, using the legal ruling in the Perens case to seek punitive damages in the tens of millions.
Fork in the Road II
"Which direction do you come from?"
And go that way.
Scientists have just reported that Element 16 is also bogus.
We now bring you to our correspondent who is on the eckkackkk kuhcc
To sneak up on you while you are secretly planning to download the latest LOTR Divx using the ACME Kazaa client, and then
Beep! Beep!
Scares the shit out of you, causing you to fall out of your chair, out the door, down the street, and over a cliff where you freefall for 25 seconds, ending up making a little while poof of smoke.
Damn you, RoadRunner! Damn you to Hell!
WTF is up with this?
The first thing I asked myself was, "so what"?
Even if these pictures are real, it's just the same old Palm OS, now with color and a new body.
It's still yesterday's news in terms of the OS.
It's not innovative enough.
Palm is showing that they are resting on their laurels, and not driving the market forward.
Now they will be visually and Mentally impaired..
I can picture it now, playing Return to Castle Wolfenstein, with Gnutella running in the background...
Suddenly, my framerate grinds to a halt.
"F%#!!@ Gnutella findfast"
dbretton writes:
click here
this is cutting edge stuff. .amazing. .snore.
Hey Taco, if I email you some interesting info on the Great Wall of China, will you post it on slashdot?
Apparently it's still the only man-made object that can be seen from space. So it must still be newsworthy, right?
seriously, I know I'm trolling. But this post has to be among the worst I have seen.
if analyzing SLOC says nothing about developer contributions, efficiency, or effectiveness - then isn't estimating value based off SLOC fundamentally flawed?
1) SLOC says nearly *EVERYTHING* about developer contributions. After all, the SLOC is what the developer contributes.
2) Efficiency is a measurable metric, and can be quite as simple as (SLOC/MM)-(NumBugs/MM), where MM=Man-Month.
While there is a variance in the efficiency of programmers, for any given company a median efficiency can be determined. From this, a decent cost-estimate for SLOC may be determined.
i just don't know why people don't count 'Customer Problems Solved Over Time' as the end-all, be-all.
That collected metric would have almost no utility, unless you could atomize the concept of a 'customer problem'.
"Well, it took us 6MM to craete that web-based
accounting system, so it should take us about
the same to develop these kernel drivers"
Something like the above doesn't help anyone. It doesn't help the programmers who take part in recording the data; it doesn't help the managers plan and predict the product lifecycle; it doesn't help the customer in letting him know when to expect to see the next product release.
What you failed to do was drill down further in your analysis of the problem.
Let's say you just finished putting out product "X", which solved some customer problem. Now the customer wants product "Y" to solve some other problem. How do you estimate "Y" based upon "X"?
Answer: Break it down. "X" required the following capabilities: A,B,C, and D. You recorded and tracked the amount of time it took to accomplish each capability.
Now, you break down the customer problem, "Y", and determine what it would take to solve it.
If you did a good job at atomizing the customer problem on project "X", then you should have been able to come up with an average amount of time/AtomicProblem. Apply this metric and Viola!, you should have a good idea about the scope of "Y".
Many people like to take the AtomicProblem and equate it to a SLOC estimate.
What SLOC counting does is try to establish a commonality among various projects so that future projects of various natures may be estimated using previous metrics. This is not perfect, but it should be used as an aid in determining overall project scope and costs.
i mean, you can't have it both ways. Either SLOC shows how productive programmers are, or it doesn't.
SLOC shouldn't be used to estimate programmer productivity. It should be used to estimate project productity.
-D
To put it mildly...
In his paper, he uses the basic COCOMO model for estimating the cost. This model, quite frankly, sucks. Boehm's book even states, more or less, that the COCOMO model is only accurate to a factor of 10.
Since I no longer have the Boehm book, this quote from a google-found web page will have to do. This is a quote of a quote from Boehm's book, Software Engineering Economics:
"Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on costs."
Basically, this means that the estimate could be anywhere from $100M->10B in true cost.
At the very least, this kid should have stated which of the model variants he was using.
Better yet, he should have subdivided the source code into multiple categories: kernel+drivers, tools, productivity software, etc. etc., and then applied the various models to them.
Just my 2 bits.
BTW, here is the google-found page which has the quote I stole. Plus, it gives a nice, albeit brief, overview of COCOMO.
-d
That's hurting so much.
Maybe, just maybe , it has something to do with that a DVD costs almost the same as a CD these days...
I guess I have to spell this out for the A/C's:
There are 2 primary things which LucasArts needs to show in order to have a viable lawsuit:
1) Trademark/IP infringement has occurred.
2) As a result of that infringement/trademark, the claimant has incurred direct revenue losses, or their potential for future revenue has been diminished.
Since LucasArts has a solid claim to #2, scummvm's reply should have been the following:
1) To state, very clearly, that the means by which they conducted their reverse engineering was a legally approved (e.g. stating court precedent) process.
2) To expand their umbrella of legal coverage (aka CYA) by aligning their project under the shield of academia.
we would see the following domain name registered:
o m
http://www.fuckfordfuckthemuptheirstupidasses.c
(which is free, btw)
-D