Forgot your password?
typodupeerror

Comment: Re:DVD's are just as easy. (Score 1) 180

by khasim (#46826839) Attached to: How Much Data Plan Bandwidth Is Wasted By DRM?

Or the iTunes Digital Copy.

I will download the video exactly once. It then lives on my computer, and I can copy it onto my iPod or iPad.

That is convenient but I think it is still the wrong question.

Eventually, the first download-only (no DVD) will be released by a studio. Then a second. The studios want download-only because then they control everything. You will never own anything from them again.

Then the studios demand further restrictions from the hardware manufacturers. Abandon old format A and include new format B.

Sure, you can repurchase all your A content and they'll even give you a discount on the B versions. But they will set the A price at whatever they want. What choice will you have? Stay with your old electronics and disable the updates?

No matter how convenient they make it it is still about removing your ownership of what you've paid for.

Comment: Re:DVD's are just as easy. (Score 2) 180

by khasim (#46826237) Attached to: How Much Data Plan Bandwidth Is Wasted By DRM?

You really think that people want to cart around a portable DVD player too?

That wasn't the question. He's complaining about not being able to pre-download large files.

Once you get past the "why can't I pre-download this" there isn't an issue with using your phone or tablet or whatever to watch movies.

But if Bennett Haselton is going to focus on pre-downloading then yes, I do expect him to use a portable DVD player.

DRM is not about pre-downloading.

DRM is about never owning what you paid for.

Comment: DVD's are just as easy. (Score 3, Insightful) 180

by khasim (#46825915) Attached to: How Much Data Plan Bandwidth Is Wasted By DRM?

He is complaining about getting large files (movies) sent to his viewing device (phone).

If only there were some way to pre-download those files.

Such as DVD's. And play them on a hand held DVD player. And DVD's do not count against your 3G data allowance for the month.

Another useless article by Bennett Haselton.

Comment: Buy an axe. (Score 1) 271

by khasim (#46822497) Attached to: 'The Door Problem' of Game Design

When I walk to my own frontdoor (to which I do have the key) I encounter dozens of doors for which I have no key and which will remain forever locked to me.
Why couldn't this be true for a game as well?

You stated that incorrectly.

Those doors are locked but can be opened. Usually with equipment that an RPG character carries around "in-game". Whether that equipment is "lock picks" or "an axe" or "a rocket launcher".

What stops you from opening them is that you do not try to. Why you do not try to is because you do not want to go to jail.

Criminals "open" doors you consider to be "locked" in the real-world all the time.

Comment: Hey Soulskill! (Score 1, Offtopic) 108

by aardvarkjoe (#46820711) Attached to: WRT54G Successor Falls Flat On Promises

Hey Soulskill -- JImbob0i0 may be a new submitter, but you're not a new editor. How about editing the content of the submission so that it actually makes sense?

What exactly is it they pay you to do? I'm sure I could write a shell script that would randomly select a few stories every day to copy to the front page.

Comment: Mod parent up. (Score 2) 166

by khasim (#46817571) Attached to: Ask Slashdot: How Can We Create a Culture of Secure Behavior?

The people that understand the risks generally don't represent a problem, but the people that don't understand them often also don't benefit from an explanation in a way that would change their behavior.

And in the corporate world there is the problem of status. People higher on the hierarchy do not like being told that they cannot do something by people lower on the hierarchy.

And if something goes wrong then it is YOUR fault because "security" was YOUR responsibility.

Computers are not magic, but many people believe that they are.

The problem there is that software has all the problems of a magical system. If you do A, B and C and then expect D to happen ... maybe it will, maybe it won't. Had you previously done X, Y or Z without rebooting?

There was a CAD program that had a problem with memory fragmentation. Even if you closed the previous files, eventually you ran out of contiguous memory and then your computer would complain about "issues" when you tried to open a file larger than your available contiguous memory. So first thing in the morning everything was fine. But around lunchtime things got weird. And the weirdness wasn't evenly distributed. On Monday, Alice would have a problem but Bob would work fine. On Tuesday Bob would have a problem but Alice would be fine. Etc. .....

And that was a problem that I could diagnose. There are hundreds more where all I can say is "perform the rite of reboot" and only open the app you have trouble with right now and let me know if it's still having trouble my god what are all those apps that are loading on start-up.

Comment: Re:I've grappled with the ethics of CS for 20 year (Score 2) 175

by khasim (#46810381) Attached to: The Ethical Dilemmas Today's Programmers Face

It's worse because while YOUR post actually reflects an ethical/moral issue, TFA does not.

Here's their #1 item:

Ethical dilemma No. 1: Log files -- what to save and how to handle them
Programmers are like pack rats. They keep records of everything, often because it's the only way to debug a system. But log files also track everything users do, and in the wrong hands, they can expose facts users want kept secret.

90%+ or whatever of the programmers out there are working on in-house code for in-house projects used by in-house people. Stuff that will never ship. So it does not matter how much stuff is logged.

For those coders who are working on code to ship, the issue becomes more about where to save the huge log files.

Log everything and store it locally? Why is your app taking up 20 GB of space?

Log everything and store it remotely? Why is your app sending 20 GB of traffic?

The ethics/morality is more "how badly do you want to be the punchline to a joke when it is discovered".

Comment: Re:No answer will be given (Score 5, Insightful) 307

How long does it take before you're no longer allowed to justify what "your guy" does by pointing out the the "other guy" did bad stuff too? Does that end after Obama's current term, or are we still going to be hearing the "Bush did it too" excuse in 2020?

Comment: Re:Not Uncommon for Portland (Score 2) 330

by Valdrax (#46802163) Attached to: Why Portland Should Have Kept Its Water, Urine and All

We Portlanders greatly appreciate our open air reservoirs however the City Water Bureau does not. Despite a large public outcry to keep our open air reservoirs our water department despite saying that they were working to keep our reservoirs, did not file for a waiver from the department of homeland security to keep the reservoirs open air.

What the hell... WHY?

I used to live in Portland for about three years and regularly drank the tap water The idea that I was drinking water straight from an open-air reservoir post-treatment nauseates me. Why would anyone want this?

Comment: Re:When did slashdot become a blog for Bennett? (Score 1) 235

by khasim (#46791205) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

Except he did not stop there. That's the problem. Allow me to re-state his original premise.

For a currency "X" there exists an amount "Y" at which (or below) no one will sell accurate bug reports to you.

When X = "pennies" and Y = "2" you can see how it works. Would you spend your time looking for bugs and reporting them for a possible payout of two cents per report? So at that point I can agree with him.

BUT THEN HE TRIES FOR A FALSE COROLLARY.

For a currency "X" there exists an amount "Z" at which (or above) people will sell accurate bug reports to you.

He uses X = "dollars" and Z = "10 million" there.

The reason it is a false corollary is that it depends upon a bug's existence being based upon the amount offered to find it.

Comment: No, they are not. (Score 1) 235

by khasim (#46790893) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

All of the people talking as if I had said there were "literally infinite" bugs in a product are missing the point.

No. They understand and they are explaining to YOU where YOU are wrong.

I said, very clearly, that of course the number of bugs is not literally infinite, but I was considering the case where there are so many bugs which can be found for $X worth of effort, that it's unrealistic to find and fix them all in the time frame before the product becomes obsolete anyway.

And that is where you are wrong. YOU are claiming that a very specific HYPOTHETICAL situation is same as the general ACTUAL situation.

Your HYPOTHETICAL situation is 100% divorced from the ACTUAL situation.

In the ACTUAL situation there are a finite number of buffer overflow bugs in any specific program and those buffer overflow bugs can be found and fixed WITHOUT another buffer overflow bug appearing. And it is EASY to find the MAXIMUM number of buffer overflow bugs by searching the source code for every instance of a buffer being used.

Finite AND countable AND fixable.

The fact that there are dozens of people responding as if I had said "literally infinitely many bugs" does not make their point any more valid.

No. They are pointing out that YOU have made that assumption even though YOU keep denying it.

Because once you admit that the number of buffer overflow bugs is finite AND countable then there exists a point where they can ALL be fixed. And you keep denying that that is possible.

Comment: Re:Bennett's Ego (Score 1) 235

by khasim (#46790713) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

Well, theoretically yes.

"Theoretically". Got it.

But do you think that Apache could ever reach a state in practice, in the world we actually live in, where you couldn't find a new vulnerability in it for $10 million worth of effort?

Emphasis added.

So now you're conflating a real-world situation with a hypothetical situation ... no. You do not get to mix real-world and hypotheticals in the same sentence. No one is offering $10 million and no one is likely to offer $10 million.

IF someone would offer $10 million for buffer overflow bugs in Apache then a lot of people would comb through the code and check each instance of a buffer for an overflow bug. All the buffer overflow bugs would be found.

After that, finding ANOTHER buffer overflow bug would not be possible IN THAT CODE BASE. No matter how much money was offered. Because all the instances should have been checked and identified.

Someone would have to submit code that included a NEW buffer overflow bug in order for a NEW buffer overflow bug to be discovered.

No matter how much money was being offered. No "theoretically" about it. It's Computer SCIENCE.

Comment: Re:That's where you are wrong. (Score 1) 235

by khasim (#46789043) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

Do you really believe that if you offered a $10 million prize to anyone who could find a vulnerability in the Apache web server, that you would reach the point where people weren't finding and reporting new ones...

From your inclusion of "really believe" I'd say that your question was rhetorical.

And wrong.

At $10 million per buffer overflow? Yes. There would be a finite number of buffer overflows that would be found and fixed.

At $10 million per X category of bug? Yes. There would be a finite number X's that would be found and fixed.

Therefore, unless you assume an infinite number of categories of bugs, all the bugs would eventually be fixed.

Because the code base comprises a finite number of bits and there is a finite number of ways that those bits can be run.

Comment: That's where you are wrong. (Score 1) 235

by khasim (#46788717) Attached to: Bug Bounties Don't Help If Bugs Never Run Out

My point is that if there are (effectively) infinitely many bugs...

No need to read any further because that is an incorrect assumption.

There cannot be an infinite number of bugs (effectively or otherwise) because there is not an infinite about of code NOR an infinite number of ways to run the finite amount of code.

From TFA:

(He confirmed to me afterwards that in his estimation, once the manufacturer had fixed that vulnerability, he figured his same team could have found another one with the same amount of effort.)

Then he was wrong as well.

There are a finite number of times that buffers are used in that code base. Therefore there are a finite number of times that buffers could be overflowed. If someone went through the code and checked each instance and ensured that an overflow situation was not possible then it would not be possible.

"Infinite" does not mean what you think it does.

If bankers can count, how come they have eight windows and only four tellers?

Working...