Since we are all Tolkein "purists" here (snicker), I'd like to point out that the scene is of a black rider chasing the hobbits on the dock, and not the Nazgul, or Ringwraiths, which are the flying hellish beasts the black riders ride upon in the sky.
The Left Hand of Darkness falls right in line with a great many of LeGuin's books. It contains a main character who is on a mission which, in turns, to be much more of a discovery of the protagonist's own self, as well as a general understanding of the tremendous balance that exists in the universe.
"Light is the left hand of darkness", (Left Hand of Darkness) and "to cast a light is also to create a shadow" (Wizard of Earthsea) are examples of LeGuin's extensive immersion of Taoist beliefs (Yin-Yang) into her work. LeGuin spent several years studying Taoism, and making it into her personal belief system.
On the side, I highly recommend the Earthsea Trilogy. It's well written, easy to read, and is quite enjoyable (especially in all this hub-bub about Harry Potter).
You said:
"Why would Tivo spend millions of dollars and years in court tangling with SonicBlue when they can just pay them a few bucks per unit in royalties and pass that on to the customers?"
Why? I can give you a very good reason. Let's assume that SonicBlue charges Tivo some nominal, per-unit fee for its patented technology, and Tivo agrees and pays the fee. Suddenly, when the lease is up for renewal, SonicBlue changes the lease to an extraordinary amount of money.
What can Tivo do now? Sue? Sure, they can seek litigation. However, the fact that they agreed to pay a licensing fee for some period of time prior to instigating a lawsuit will significantly weaken their chances of winning.
"... in their legal attempt to stop the publication of your work"
You need to re-examine the details of the acse. The RIAA did not make a legal attempt to stop the publication of his work. They only threatened with a legal suit.
There is a HUGE difference between the two: the RIAA can (and, IMO will, be able to successfully) argue that no damages were incurred as a result of their actions, as they did not actually sue, nor did they act in an illegal matter.
Did anyone actually believe that Norton or McAffee (however you spell that name) would actually detect Magic Lantern?
In addition, is anyone here really concerned about the FBI hacking into your computer?
The only thing I would be concerned about would be someone mis-using the Magic Lantern program itself...
#2) A heuristic anti-virus program that is combined with an auto-checksummer, like what Thunderbyte Anti-Virus (TBAV) was (now Norman Virus Control) would probably still be able to detect Magic Lantern. Programs like these combine a general-purpose virus pattern scanner with an enormous set of checksum files. IIRC, TBAV actually had a checksum file for every single directory it scanned, which was conforting.
Ever since I first heard the battle cry of The Tick, I always wondered, "How did these guys come up with the idea?"
I tried to visualize the circumstances which brought forth the famous Tick line, and always end up picturing some semi-intoxicated discussion over battle cries during dinner, then someone started holding up utensils.
So, how did it happen? What were the circumstances? What were the alternative/runner-up battle cries?
(if you say, "chopstick & spork", you'll get me angry. You wouldn't like me when I'm angry.)
Ok, I'll say it.
I know I am not alone here. The changelog has only the slightest modicum of vutility to the average linux user/sys admin/etc.
I don't follow the kernel list intimately. I don't want to. All I want is a description of updates that distinguishes the new kernel from the old one.
"more merging" is complete shit (pardon the language, but it is the most fitting word). There isn't a single person who can read a statement like that and understand what has been changed/added/fixed in the kernel.
Since I cannot sit here and whine about things without offering something better, how about this:
Every developer has a template document that lists the important things their "patch" does. There could be 4 categories:
New Driver
Bug Fix
New Feature
Caveats/Known Bugs
Each submitter would send this document to the "maintainer" of the various portion of the kernel, who would then merge the documents. These merged documents would go to Alan/Linux/etc., who would merge the list again.
So what if it's huge. At least it would be informative. I'd rather see a lengthy list of changes than hardly anything at all.
-Given the choice, would you prefer to hear your local news station go on about the details of the news in the day, or simply say, "And today, more stuff happened"?
Wouldn't it be nice to skim through the changelog and see if firewire support for your HD has been added? (for example)
I wish something like this would exist...it wouldn't even be difficult to do, either!
I would dare to say that the first iteration will fall within about a 2 sigma error margin. That is, your first estimate on your first major program will have a bit of variance in it.
It is a matter of obtaining the correct measurements of performance, time, and complexity for the project.
After the first iteration, accurate estimations can be performed rather easily.
No secret at all, really. Good metrics, a clear understanding of the problem space, and strong control (i.e. exacting configuration management) lead to a successful, well run program.
Quick example:
My customer wants me to design a fault tolerant, web-based acquisitions program to manage a 5,000 employee company's transactions. All of this is via an intranet. (the problem really doesn't matter. I just thought I would toss it in to give "details" people something to think about)
1. Determine problem statement/space.
Get the details! Determine the business-level requests. Brainstorm and develop a document listing the details (implications) of the problem.
Present to the customer. Iterate until problem is completely defined.
2. Draw on previous experience to determine approximate complexity of code. This can be tough, as complexity can be hard to factor. Look at the interactions, locations of system fault, probability of fault, and cross-cutting concerns in system usage.
3. Leverage step 2 with previous metrics, such as source lines of code (SLOC), to make a first order estimation on total code to be produced.
4. Combine SLOC estimate with pre-recorded employee productivity (SLOC/{week,month} as well as error rates (#bugs/{1k,10k}SLOC), to determine the length of time to produce the working product. Note that the above metrics usually include test, demonstration, verification and validation time.
Factor in SLOC conversion rates if the application language differs from the baseline. (e.g. C->Java 1.3, JAVA->C++, ~1.0, Ada->C++ 1.2, cobol->C,...etc)
5. Determine the migration time, if applicable, to move the customer's current base to the new product.
6. Determine amount of time to distribute and train the customer for the new product.
7. Roll numbers in, mix, and viola: you have your numbers for development of a project.
Note that none of the above mentions product life cycle support and the like.
IEEE J-STD-016-1995 is a good source for software life cycle process.
I personally lost more than 100GB of data. ....
....
Somewhere, in a little corner of the basement of a house, someone is installing their new iTunes...
{blip, squeek}.. Oh man, this is sooo cool!
{HD Grrrrinnd!!}
huh? What thee.. !!
NooooOOooooOOOOO!!!! My PORN!!!
Oh my God!
Later that day, at a Starbucks, we see a man, trembling as he sips is triple MochaBucka Latte-chino...
Brtney... GONE!
Pam....GONE!
Margolis....GONE!
That chick doing the horse...GONE!
Halt! I am AnCow, destroyer of worthy notes, and protector of the Holy Bulletin Board. This board is now under my protection (due to recent redistrictring in the northwest area).
None shall post beyond me! Try, and ye shall perish a death worse than.......death!
Do not Test my unbearable power of Posting Prevention!
I cast the spell of "anti-posta" upon thee! Run, vanquished smidgeon upon the sole of my mighty idiom! Go! Flee!
I welcome 2.5! I wish it would come sooner!
This whole VM and severe -ac branching which has occurred truly frightened me. If it persisted, it certainly would have resulted in a fork of sorts.
It seems that Alan has a good understanding of what a release kernel should have, and the types of changes that should occur in such a kernel. Introducing a new VM, as stated before on slushdot, in the middle/end of a stable kernel series, is plain silly.
Come to think of it, I kind of like the idea that Alan is NOT maintaing the stable kernel, for 2 reasons:
1. His talent would be best served on new development of the 2.5 kernel (hey, who doesn't like working on the cool new stuff).
2. In light of his anti-DMCA actions, it would seem that he has no issue with putting Linux up on the firing line to support his politically motivated beliefs. It doesn't matter if you agree with Alan on the DMCA or not, not posting changelog notes like he did was childish and counterproductive to the goal of Linux: world domination through collaboration.
What happens when someone steals the basket with all your eggs?
Eggs? What you talkin' all about eggs for? Don't give me none of that Gibber-Jabber, or you best be tossed!
You took a wallet? I don't see no crazy wallet! You're talking like Face, crazy fool!
Besides, you don't need no wallet! Just dial
1-800-COLLECT and save a buck or two.
XP? That better mean Xtra Punishment, cause that's what I'm gonna do to that Gates fool! He can't escape me, cause my van's hella fast!
Faster than the speeding light she's browsing,
Trying to remember where her wallet ran,
She's lost herself that Ebay afgan,
Waiting for the time when MS shall be as one
You are 100% correct. The CTSA, however, is an attempt to bind everyone under a form of an "NDA", in a way. If you are discussing cryptography, and happen to discuss that a particular type of decryptographic (word? God, I love English!) process will subvert a particular type of proprietary encryption, then I may be able to apply the CTSA to prevent you from discussing it!
That was a very interesting read. I do like stories that have a happy ending.:)
What was most interesting was the distinction made between copyrighted works and trade secrets.
Since copyrighted works have a "fair use" policy, it is clear why the DVDCCA attacked under the premise of a "Trade secret" violation. However, the strategy backfired. severely:
My favorite quote (2nd hand source noted) was this:
"'If a threat to national security was insufficient to warrant a prior restraint in New York Times Co. v. United States, the threat to plaintiff's copyrights and trade secrets is woefully inadequate.' (Religious Technology Center v. Lerma (E.D.Va. 1995) 897 F.Supp. 260, 263.)"
Ouch, indeed! This may mean the eventual demise of the California Trade Secrets Act, as its scope is to far-reaching.
What was of interest, however, is that there was no discussion of the DMCA, which may have aided the cause of the DVDCCA. Perhaps the DCDCCA did not want to use that trump card, for fear that their case may rise to a federal court, and bring the DMCA under scrutiny.
Why is that interesting? The DVDCCA must have felt that their strongest case did not lie in protection under the DMCA
(chapter 12, section 1201, subsection b), aware of the (obvious) orthogonality of the DMCA vs Frist Amendment, but rather in trying to re-address the issue under the pretenses of a trade secret.
Oh, BTW, here is that bit from the DMCA to which I referred:
"ADDITIONAL VIOLATIONS.
(1) No person shall manufac-ture, import, offer to the public, provide, or otherwise traffic in any
technology, product, service, device, component, or part thereof,..."
Slashdot Mirror
Here's a quick question:
What would prevent someone from installing Win-DRM on top of a VM running a different OS, then simply stealing the raw data from the DRM OS?
Since we are all Tolkein "purists" here (snicker), I'd like to point out that the scene is of a black rider chasing the hobbits on the dock, and not the Nazgul, or Ringwraiths, which are the flying hellish beasts the black riders ride upon in the sky.
"I don't want to turn this into a device review - that will come later "
IDIOT!
The Left Hand of Darkness falls right in line with a great many of LeGuin's books. It contains a main character who is on a mission which, in turns, to be much more of a discovery of the protagonist's own self, as well as a general understanding of the tremendous balance that exists in the universe.
"Light is the left hand of darkness", (Left Hand of Darkness) and "to cast a light is also to create a shadow" (Wizard of Earthsea) are examples of LeGuin's extensive immersion of Taoist beliefs (Yin-Yang) into her work. LeGuin spent several years studying Taoism, and making it into her personal belief system.
On the side, I highly recommend the Earthsea Trilogy. It's well written, easy to read, and is quite enjoyable (especially in all this hub-bub about Harry Potter).
You said:
"Why would Tivo spend millions of dollars and years in court tangling with SonicBlue when they can just pay them a few bucks per unit in royalties and pass that on to the customers?"
Why? I can give you a very good reason. Let's assume that SonicBlue charges Tivo some nominal, per-unit fee for its patented technology, and Tivo agrees and pays the fee. Suddenly, when the lease is up for renewal, SonicBlue changes the lease to an extraordinary amount of money.
What can Tivo do now? Sue? Sure, they can seek litigation. However, the fact that they agreed to pay a licensing fee for some period of time prior to instigating a lawsuit will significantly weaken their chances of winning.
"... in their legal attempt to stop the publication of your work"
You need to re-examine the details of the acse. The RIAA did not make a legal attempt to stop the publication of his work. They only threatened with a legal suit.
There is a HUGE difference between the two: the RIAA can (and, IMO will, be able to successfully) argue that no damages were incurred as a result of their actions, as they did not actually sue, nor did they act in an illegal matter.
#1) How is this really news?
Did anyone actually believe that Norton or McAffee (however you spell that name) would actually detect Magic Lantern?
In addition, is anyone here really concerned about the FBI hacking into your computer?
The only thing I would be concerned about would be someone mis-using the Magic Lantern program itself...
#2) A heuristic anti-virus program that is combined with an auto-checksummer, like what Thunderbyte Anti-Virus (TBAV) was (now Norman Virus Control) would probably still be able to detect Magic Lantern. Programs like these combine a general-purpose virus pattern scanner with an enormous set of checksum files. IIRC, TBAV actually had a checksum file for every single directory it scanned, which was conforting.
-D
It appears that this agreement is an important step in the right direction for Microsoft:
It's the only thing they've done where it didn't take them 3 tries to get it right.
Ever since I first heard the battle cry of The Tick, I always wondered, "How did these guys come up with the idea?"
I tried to visualize the circumstances which brought forth the famous Tick line, and always end up picturing some semi-intoxicated discussion over battle cries during dinner, then someone started holding up utensils.
So, how did it happen? What were the circumstances? What were the alternative/runner-up battle cries?
(if you say, "chopstick & spork", you'll get me angry. You wouldn't like me when I'm angry.)
-Dennis
That is not insightful. It's pure partisan politic playing.
Nothing new here.
Ok, I'll say it.
I know I am not alone here. The changelog has only the slightest modicum of vutility to the average linux user/sys admin/etc.
I don't follow the kernel list intimately. I don't want to. All I want is a description of updates that distinguishes the new kernel from the old one.
"more merging" is complete shit (pardon the language, but it is the most fitting word). There isn't a single person who can read a statement like that and understand what has been changed/added/fixed in the kernel.
Since I cannot sit here and whine about things without offering something better, how about this:
Every developer has a template document that lists the important things their "patch" does. There could be 4 categories:
New Driver
Bug Fix
New Feature
Caveats/Known Bugs
Each submitter would send this document to the "maintainer" of the various portion of the kernel, who would then merge the documents. These merged documents would go to Alan/Linux/etc., who would merge the list again.
So what if it's huge. At least it would be informative. I'd rather see a lengthy list of changes than hardly anything at all.
-Given the choice, would you prefer to hear your local news station go on about the details of the news in the day, or simply say, "And today, more stuff happened"?
Wouldn't it be nice to skim through the changelog and see if firewire support for your HD has been added? (for example)
I wish something like this would exist...it wouldn't even be difficult to do, either!
-D
Sen. Kennedy: Ere-ah, this 'ere settlement is an outrage! Massachusetts will never agree to such a piece of this 'ere-ah gahbahge!
Kennedy Aide:(whisper) Sir, Mr. Gates sent you this case of Chivas Regal as a gift.
Sen. Kennedy: Where's my pen?
Accurately, too!
I would dare to say that the first iteration will fall within about a 2 sigma error margin. That is, your first estimate on your first major program will have a bit of variance in it.
It is a matter of obtaining the correct measurements of performance, time, and complexity for the project.
After the first iteration, accurate estimations can be performed rather easily.
No secret at all, really. Good metrics, a clear understanding of the problem space, and strong control (i.e. exacting configuration management) lead to a successful, well run program.
Quick example:
My customer wants me to design a fault tolerant, web-based acquisitions program to manage a 5,000 employee company's transactions. All of this is via an intranet. (the problem really doesn't matter. I just thought I would toss it in to give "details" people something to think about)
1. Determine problem statement/space.
Get the details! Determine the business-level requests. Brainstorm and develop a document listing the details (implications) of the problem.
Present to the customer. Iterate until problem is completely defined.
2. Draw on previous experience to determine approximate complexity of code. This can be tough, as complexity can be hard to factor. Look at the interactions, locations of system fault, probability of fault, and cross-cutting concerns in system usage.
3. Leverage step 2 with previous metrics, such as source lines of code (SLOC), to make a first order estimation on total code to be produced.
4. Combine SLOC estimate with pre-recorded employee productivity (SLOC/{week,month} as well as error rates (#bugs/{1k,10k}SLOC), to determine the length of time to produce the working product. Note that the above metrics usually include test, demonstration, verification and validation time.
Factor in SLOC conversion rates if the application language differs from the baseline. (e.g. C->Java 1.3, JAVA->C++, ~1.0, Ada->C++ 1.2, cobol->C,...etc)
5. Determine the migration time, if applicable, to move the customer's current base to the new product.
6. Determine amount of time to distribute and train the customer for the new product.
7. Roll numbers in, mix, and viola: you have your numbers for development of a project.
Note that none of the above mentions product life cycle support and the like.
IEEE J-STD-016-1995 is a good source for software life cycle process.
-D
I personally lost more than 100GB of data.
....
....
Somewhere, in a little corner of the basement of a house, someone is installing their new iTunes...
{blip, squeek}.. Oh man, this is sooo cool!
{HD Grrrrinnd!!}
huh? What thee.. !!
NooooOOooooOOOOO!!!! My PORN!!!
Oh my God!
Later that day, at a Starbucks, we see a man, trembling as he sips is triple MochaBucka Latte-chino...
Brtney... GONE!
Pam....GONE!
Margolis....GONE!
That chick doing the horse...GONE!
My life is over....
How did they get Janet Reno to pose as the driver?
Halt! I am AnCow, destroyer of worthy notes, and protector of the Holy Bulletin Board. This board is now under my protection (due to recent redistrictring in the northwest area).
None shall post beyond me! Try, and ye shall perish a death worse than.......death!
Do not Test my unbearable power of Posting Prevention!
I cast the spell of "anti-posta" upon thee! Run, vanquished smidgeon upon the sole of my mighty idiom! Go! Flee!
bwa-hahahahhahaha
I welcome 2.5! I wish it would come sooner!
This whole VM and severe -ac branching which has occurred truly frightened me. If it persisted, it certainly would have resulted in a fork of sorts.
It seems that Alan has a good understanding of what a release kernel should have, and the types of changes that should occur in such a kernel. Introducing a new VM, as stated before on slushdot, in the middle/end of a stable kernel series, is plain silly.
Come to think of it, I kind of like the idea that Alan is NOT maintaing the stable kernel, for 2 reasons:
1. His talent would be best served on new development of the 2.5 kernel (hey, who doesn't like working on the cool new stuff).
2. In light of his anti-DMCA actions, it would seem that he has no issue with putting Linux up on the firing line to support his politically motivated beliefs. It doesn't matter if you agree with Alan on the DMCA or not, not posting changelog notes like he did was childish and counterproductive to the goal of Linux: world domination through collaboration.
Xtra Pokey...
what you need is a
"2 bit company that can't stand 1 bit of competition"
And I feel,
like I just got robbed,
And I feel...
What happens when someone steals the basket with all your eggs?
Eggs? What you talkin' all about eggs for? Don't give me none of that Gibber-Jabber, or you best be tossed!
You took a wallet? I don't see no crazy wallet! You're talking like Face, crazy fool!
Besides, you don't need no wallet! Just dial
1-800-COLLECT and save a buck or two.
XP? That better mean Xtra Punishment, cause that's what I'm gonna do to that Gates fool! He can't escape me, cause my van's hella fast!
Don't do drugs! Drink milk!
Come here, sucka. I'll toss you!
eXport Privacy
Faster than the speeding light she's browsing,
Trying to remember where her wallet ran,
She's lost herself that Ebay afgan,
Waiting for the time when MS shall be as one
And I feel like I just got robbed
And I feel...
(all apologies to Madonna)
You are 100% correct. The CTSA, however, is an attempt to bind everyone under a form of an "NDA", in a way. If you are discussing cryptography, and happen to discuss that a particular type of decryptographic (word? God, I love English!) process will subvert a particular type of proprietary encryption, then I may be able to apply the CTSA to prevent you from discussing it!
That was a very interesting read. I do like stories that have a happy ending. :)
What was most interesting was the distinction made between copyrighted works and trade secrets.
Since copyrighted works have a "fair use" policy, it is clear why the DVDCCA attacked under the premise of a "Trade secret" violation. However, the strategy backfired. severely:
My favorite quote (2nd hand source noted) was this:
"'If a threat to national security was insufficient to warrant a prior restraint in New York Times Co. v. United States, the threat to plaintiff's copyrights and trade secrets is woefully inadequate.' (Religious Technology Center v. Lerma (E.D.Va. 1995) 897 F.Supp. 260, 263.)"
Ouch, indeed! This may mean the eventual demise of the California Trade Secrets Act, as its scope is to far-reaching.
What was of interest, however, is that there was no discussion of the DMCA, which may have aided the cause of the DVDCCA. Perhaps the DCDCCA did not want to use that trump card, for fear that their case may rise to a federal court, and bring the DMCA under scrutiny.
Why is that interesting? The DVDCCA must have felt that their strongest case did not lie in protection under the DMCA
(chapter 12, section 1201, subsection b), aware of the (obvious) orthogonality of the DMCA vs Frist Amendment, but rather in trying to re-address the issue under the pretenses of a trade secret.
Oh, BTW, here is that bit from the DMCA to which I referred:
"ADDITIONAL VIOLATIONS.
(1) No person shall manufac-ture, import, offer to the public, provide, or otherwise traffic in any
technology, product, service, device, component, or part thereof,..."
Of couse, IANAL (but I play one on slashdot!).
-D