Lots of people have always got attached to their first language or IDE or whatever, but the core skills learned are transferable. What's being talked about isn't vocational training; it's introducing, for example, programming to patrons at a library.

I think a Chromebook has some very good properties for a public library. They're not just cheap, they're simple and maintainable. If they couldn't support learning how to program at all, I think that would be an important disadvantage. But I think in the context of a library, having online tools and sites available to learn programming is perfectly reasonable, and "ticks that box" so to speak.

There's no reason you couldn't learn to program inside a web application - it limits the tools you can use, sure, but it's certainly not impossible.

Try playing 20 games of Heroes of Newerth, then 20 games of League. You'll feel the difference.

I much prefer Heroes as a game - but in HoN it's routine that over the in game voice chat people will threaten to kill you because (for example) you missed denying a creep - and if you mute people, you lose any kind of coordination. In League, strangers have to type out their abuse - and if you get tired of it, you just mute them (because most "real" communication is done via pings anyway). But for the most part, you don't have to mute people - because the whole happy sticker tribunal thing actually seems to work. Heck, people are often legitimately friendly, even when you're losing.

Overall, in League, 1 in 10 games will be ruined by someone going nutbars griefing or hurling abuse, or leaving because they feel abused. In HoN, 5 out of 10 games are ruined that way.

So even though I love the game (Newerth), I'll probably never play again. The League stuff works.

I don't think you're an asshole at all (though there's plenty of condescending jerks in this thread, on both sides). This subject just has a lot of baggage and history - much more emotional content than makes any sense. There's a good chance many people responding negatively to you have just been primed by encountering a lot of condescending idiots in the past.

It'd be like trying to start a new discussion of "Intelligent Design" or something. Whatever your argument or question is, or its merits, many people would be likely to get very mad very quick.

If that same person said they had mathematical evidence that proved he could see Saturn with his naked eye, I don't think I'm out of line for asking to see that data.

Well yeah - if someone could actually see the moons, they'd likely be able to produce evidence pretty easily (or at least they'd conciously know they're lying). You could ask them to say, for example, whether the moons are currently aligned or whatever. The positive side of this is really easy to resolve - if you find a dead Sasquatch, that kind of resolves things.

It's the flip side - "can you prove nobody can see the moons?" that's more the question here. I mean, you can give an explanation of why this would be very unexpected based on normal human visual acuity and how eyes work. And you can say that you've tested lots of humans and none of them can see the moons. But you can't stamp out the possibility that SOMEONE can tell the difference, just like you can't eliminate the possiblity of Sasquatches just based on never having seen one.

To be clear though, the presence of this possibility is not usually what's being argued by the "other" side. Rather, they're saying that the differences are large, reasonably easily heard, and attributable to phenomenon that don't make sense or they don't understand. It's not like they're saying "there MIGHT be Sasquatches". It'd be like if 1/3rd of the people in every discussion claimed Sasquatches were common and they saw them every day. And when questioned further, it really sounds like they're just seeing a dog - but they get very defensive when you mention dogs. Meanwhile, any time you've gone out to meet these people, they've been unable to show you a Sasquatch (time and time again) - but have pointed out several dogs.

You could imagine how it would get tiring being a "Sasquatch denier" and having this discussion often - so I don't envy people who are involved in, say, making audio equipment, and I don't fault them for being a bit chippy.

The fact that it isn't 100% mathematically provable is true, but also kind of uninteresting.

I mean, if someone comes and claims they can see the moons of Saturn during the day with their naked eyes, that's an extraordinary claim. I can't invalidate it with 100% mathematical reasoning. It's far outside the bounds of what we know about human visual perception, but it's not impossible.

Still, there's also no reason to take their claim seriously - especially when other people have made the same claim many times (and done so with honest belief they're right) and always been shown to be wrong. There's just something about human perception of audio that attracts a lot of superstition and false conclusions.

Looking back at your original question:

Can you show me the math that proves that there's no difference between an uncompressed audio source and a 320kbps mp3?

The best I can say is to read something like http://en.wikipedia.org/wiki/P.... But the proof you're looking for isn't going to be mathematical - and is not 100% sound or something. The only real proof is empirical (people can't tell the difference in double blind tests); the psychoacoustic stuff is just an explanation for why that result makes sense given basics of how our ears and brains work.

It's also interesting to look at how audio compression works, and frequency space transforms and what not. But that's very easy information to find.

This video explains sampling and reconstruction of digital audio very well, and is a good jumping off point if you want to learn more.

http://www.youtube.com/watch?v...

It isn't like Code Jam is their main stream of employee finding, and in general their engineer interviews are less puzzly than they used to be.

Google has a broad variety of problems that need solving, including a lot of problems where understanding algorithms is tremendously important. If anything Code Jam allows Google to cast a broader, more inclusive, fairer net - giving opportunities to people to shine who don't have a degree from MIT education or who don't fit the average software developer mold.

Well, the starting point for this discussion a discussion like this is "the attacker has access to the hashed passwords and they understand our hashing algorithm, are they able to recover the passwords". Nobody is talking about attempting a million logins through their interface.

Rather, my comment was just stating the obvious - if you are capable of logging in a single user based on the information at rest, then an attacker can use that same test, with the same information, in a brute force attack on a short password.

Their actual solution, which I didn't realize when I wrote my first comment there, is that their system can't just validate a single user.

Google Code Jam is a really super excellent way to get into algorithm programming competitions, at least in North American. The serious competitors are pretty thin on the ground here (or at least they have been in past years) so with a bit of commitment, some programming experience, and a little luck, getting to the on site rounds is very achievable.

It's especially a great opportunity if you're interested in working at Google - doing well will definitely attract their attention.

It's also one of the most approachable competition formats; it's very "approach agnostic", and doesn't focus on anything too obscure in terms of required knowledge or skills. The time bounds are loose enough that you don't have to worry about things like "reading from a file efficiently". The initial rounds usually just test whether you can do basic programming. The test cases they supply do a good job of making sure you get things like formatting right - meaning you get to focus on the actual problem instead of goofy side issues.

Very well run contest, and lots of fun even if you're not a real expert.

Yes, that is the point. My point, in turn, was that you can't do what they describe while still being able to log in a single user.

The surprising resolution to this little dilemma (as discussed in other posts) is that they can't log in a single user (they need kind of a quorum of login attempts before a newly rebooted server can actually log someone in). This wasn't what I expected, so my first post there is kind of misleading (because I was, in turn, mislead by the summary).

The point of this thing is to get an effective key into memory without storing it somewhere (ie. you can reconstruct it based on login attempts). If you just store the logins somewhere, you might as well just store the key there instead (and this, combined with communication restrictions, is how a normal setup like this would work), because from the logins you can get the effective key you need to do authentication. So this scheme isn't really adding anything to that scenario.

To be clear, I don't think you're wrong - you could do a setup like you describe; I just don't think adding this process into the mix would effectively increase security (or, at least, wouldn't help any more than storing passwords in 1000 different files around your network would - it makes things less convenient for the attacker, but not really more secure given the assumptions we have about the attack).

Well, the starting point for this kind of discussion (and the reason you'd use a system like this) is "they've stolen the database and they know how the hash algorithm works". This system is to prevent you from getting passwords out from here by making them more difficult to brute force (and they can't exactly stop you from trying more passwords after you have the database).

They do this by having an effective key that isn't stored in the database and is required for authentication, but is instead reconstructed based on a number of logins (and those logins don't "work" until there's a quorum). Like my post suggested, with something like this you have to pick between "can you authenticate a user" and "can you prevent a brute force attack on short passwords". I assumed they picked the former, but they actually picked the latter - using this system you can't just authenticate a single user on a newly rebooted system.

Anyway, it's a cool thing, but I think there's practical problems.

Yeah - I was wrong. I had assumed that the system would need to be able to log in a single user based on their password (crazy me!) and that was incorrect.