FTS,
"The moral of this story seems to be that it is a bad idea to buy a game just before a major holiday."
Um, no the moral of this story is that DRM is beyond USELESS and only punishes the honest customers. I am sure that as usual the "pirates" are playing the game just fine.
Another moral to take away is don't give your money to people that want to treat you like a thief EVEN THOUGH YOU HAVE ALREADY GIVEN THEM MONEY.
There is such a huge learning curve, there is simply no way for your average young developer to get into it. Some say that it's good that only older, more experienced people are getting into it. I would argue that when today's youth are older and more experienced, they still won't be working on it.
That's because the average reflects the lowering of standards. Average CS student 15-20 years ago was expected to do Pascal/Ada, C, a full-course on assembly (and not just a few weeks), Lisp/Prolog, create multi-threaded/multi-tasked applications from scratch (and if lucky to be at a good university, create a bootloader or mini-os or an embedded app from scratch as well) by the time of graduation. Some even were lucky to learn how to create primitive calculators with hardware in their computer org classes.
Average CS student now is expected to know how to create a dynamic web site in Java or whatever without ever having to learn how all of this shit works from the moment they press the "power on" button on their computers. Mind you, I do Java for a living, so it's not like I'm a C-enamored freshman bashing Java development for the heck of it.
So to say that the learning curve is too great for the average developer is just a reflection of the averages TODAY (and an indictment of our CS education nowadays.)
Until such time as ISP's are able to uniquely identify WHO did it and not just "well this guy owns the house where the service is terminated", the other folks in the area can get their own internet access.
Until such time as ISP's are able to uniquely identify WHO did it and not just "well this guy owns the house where the service is terminated", prosecutors and plaintiffs should not be able to meet their burden of proof on such offences.
There. FYP.
Obligatory IANAL
Now, hmmm. Consider 2 situations:
Situation A
- Bad guy cracks your WPA / WEP key and uses your network to download copyrighted material.
- You are sued (civil case), and the burden of proof required is preponderence of the evidence / balance of probabilities.
- You live in a densely populated area where there are a large number of computer-unsophisticated users who regularly use somebody else's network because they left it open
- It is introduced into evidence that you secured your network to try to ensure that only you could use your network
- The only question of fact at trial is the identity of the infringer - your defense is that somebody else may have used your network to commit the act in question
Situation B
- Bad guy uses your open wireless network to download copyrighted material.
- You are sued (civil case), and the burden of proof required is preponderence of the evidence / balance of probabilities.
- You live in a densely populated area where there are a large number of computer-unsophisticated users who regularly use your network because you left it open
- The only question of fact at trial is the identity of the infringer - your defense is that somebody else may have used your network to commit the act in question
Do you feel that it is more likely that your defense (somebody else did it) is correct under Situation A or Situation B?
In a civil case, where allegations do not have to be proven beyond reasonable doubt, how do you feel this impacts a balance of probabilities test?
"Securing" your network could put you in a worse situation. DUCY?
(usually its combined with your debit or cash withdrawl card, I've never seen a standalone cheque guarantee card)
Sir, your youth is showing
"Standalone" (ie single function) Cheque Guarantee Cards were common back in the 1980's.
--
They're from Mars. You do the English.
Our entire front end is ExtJS. This means MUCH EASIER porting a whole web app based (SIGH) on Grails to something less craptastic like Rails, Django, or anything else that is good at emitting JSON. It's not as easy to get started with... because you're starting with high-level widgets like controls, panels, and similar.
Yes. Because the Internet has reduced the friction of communication to the point where it is impossible to make a profit selling snake oil.
The people running dns servers are probably 0.000001% of internet users....
ummm... Okay... Only that's not what the story was talking about. The story was talking about a user using a different resolver from comcast, rather than their resolver. This has nothing to do with running a dns server. There are a number of reasons to want to use another resolver, including:
the rest are probably just infected machines... is it simply to try to get a handle on worms and malware... If the cost from malware
Sorry... what does using a different resolver have to do with malware? Yeah. I thought so.
The question is *why* do they care about filtering DNS traffic?
The reasons I've heard advanced most frequently to encourage the use of the ISP's caching nameserver are:
This detracts from their profitability only one one of their lines of business - the one where you are the product.
A well trained pilot would know when to trust the computers and when not to. They would also know how to maneuver and react in situations. It's like the pilot that landed his plane in the river after losing an engine to birds. I don't think a computer would have taken that option and not only would it have been likely that all the passengers would have been killed, but bystanders as the planes computer attempted to correct and eventually goes down in a populated street.
This comment looks sensible on the face of it, but I have to disagree with you. I have a pilot license and am familiar with the process of flying. I've never flown a fly-by-wire aircraft, but I've automated a radio broadcast desk - which might not look like it's relevant, but it taught me that "knowing when to trust the computer" is not an obvious state, not in a radio station and I seriously doubt in a cockpit.
For me the final "aha moment" came when the computer was attempting to tell me something useful, but because I was concentrating on a completely different aspect of interacting with it, I completely missed the information. In my case it caused a few seconds of dead air on a radio station, nothing life threatening, but not human obvious either.
The challenge is not "when to trust a computer and when not to" - the challenge is "how do you get the information that the computer is using to the human in such a way that they can manage that input stream in a timely fashion. Stick shakers are an example of making use of an extra input channel.
Accidents in planes are rarely just one thing going wrong, they generally are a whole string of things. A computer in the mix just exacerbates the issue.
In short, it's just some random operator on the 'net whose only real credential is they paid the fee needed to register a domain name (or SSL certificate).
I see. You are under the illusion that an SSL cert (ought to) assert(s) meatspace identity (or identity other than "one who controls domain xxx.com." Perhaps that identity assertions other than those contained in cn or altSubjectName ought to have some meaning. Kinda what EV intends to do... for corp's.
The real problem here is that "trust" is just a very hard problem. It's labor-intensive to establish trust. What should want? Two forms of ID? Credit references? Notarized forms? Personal appearance? Background check investigations?
You are mixing / begging the question on a few concepts here, including:
- granularity of identification
- strength of identification verification
- reputation
Perhaps if these concepts were dealt with in an orderly, separate manner, the question of trust would be more easy to quantify and address.
Now we're trusting a company -- whose interests aren't necessarily coincident with ours -- to authenticate others for us.
Trust but verify. They publish a statement with respect to the policies and procedures that they follow. They are audited to ensure they follow those policies and procedures. It is up to us (and the browser makers [?]) to ensure that those policies are sufficient for our purposes.
Please name such a CA which "happily hand over valid certs to anyone with a credit card" and does not "take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf" and which is trusted by the major browsers.
And then, perhaps, explain why you feel this is in _any_ way relevant to a discussion on DNSSEC.
Though, I suppose, this is Slashdot. Why post based on relevant facts rather than baseless, off-topic innuendo?
You knew the job was dangerous when you took it, Fred. -- Superchicken
