My sense is that the MEAN Stack (Mongo, Express, AngularJS, Node) is sort of winning. There's some packaging of it over at mean.io.
Personally, I'm really getting interested in Meteor (www.meteor.com). Watch the videos, and realize I saw a smart non-coder go from zero to *ridiculously* interactive site design in three months.
I took a pass at Python 3 a while back. The amount of hoops I needed to jump through, to deal with compilation errors around Unicode handling, was terrifying. It was simply a poor user experience.
Python 2.7 just works. Sure, it's a nightmare past a certain scale point. But until you get into the dregs of OO it really is executable pseudocode.
Python 3 is some other language that lost that property.
The big problem is that we don't ship languages with telemetry that reports when they fail to work. So things that are completely obvious to outsiders never make it to inner circles. Not that I can really see any way for Python 3 to mend its errors.
Seriously. Write some code, publish it on Github. Spin up a single serving web page, does one interesting thing as soon as you arrive. Remember, everyone else with resumes could be pretending, you're actually doing stuff.
For work experience, sign up on freelancing sites like odesk. Take jobs just to do them. Nobody knows how old you are, there. Even if all you can do is sysadmin -- well, admin some cloud services!
Yeah. 66% of AT&T's 4th quarter sales were iPhones. I was on Verizon for years, switched to AT&T only for their iPhone, and stuck with them only for their GSM capabilities worldwide. Sure, your margins are less when you offer a better service. Would you prefer no sales though?
The platform that most successfully upgraded itself was the NES. One of the degrees of freedom they had, because there were chips in each cartridge, was to deploy new memory management units inside the games themselves. Quite literally, the NES became more powerful for games released later in its dev cycle. SNES did this too, with the SuperFX chip inside of Starfox (the most popular DSP in the world, for its era) but it wasn't quite the "all games ship upgrading hardware".
I suspect if there was ever to be upgradable hardware, it'd have to work by yearly subscription, and it'd have to be no more than $50 a year for the part. However, with guaranteed sales in the millions of units (as games would hard-require it) the logistics of making some pretty crazy stuff fit into $50/yr wouldn't be unimaginable. Remember that XBox Live is already pulling, what, $60/yr?
You realize this is completely unscientific garbage, right? None of http://www.fwi.co.uk/Articles/25/01/2011/125212/Handle-with-care.htm makes sense outside of a conscious entity.
DNSSEC is an infrastructure shift, and you can't use it on.com domains for another few months. Have some patience.
At Black Hat this year, I actually demonstrated the endgame. Want federated authentication in OpenSSH that actually scales? Want servers able to autogenerate TLS keys that will be recognized and secured worldwide, even against broken certificate authorities?
Want secure email, without the mess that is PGP key management?
End to end secure key management via DNSSEC makes it all actually really easy. Code is here -- BSD licensed, feel free to play:
http://dankaminsky.com/phreebird
Also, I'm putting together a set of diaries on the subject:
The problem is collateral damage. Legitimate actors can't get into the DDoS game, because if they legitimize DDoS, the network will *fry*.
The "good guys" cannot flood nearly as significantly as the bad guys. Worse, the good guys are significantly more exposed -- they have corpnets, they have partner nets, etc. Today it's the website, tomorrow it's Hulu.
There are paths on which the anti-piracy people have the high ground (not moral high ground, tactical high ground). DDoS, in no uncertain terms, is not one of them.
Fascinating! Looks like I got to spend the night being wrong myself. Serves me right for being so cocky.
It seems that the key to this question is that there are boy/boy pairs where neither boy was born on a Tuesday. That's why Tuesday matters:
If your first child was not a boy, you cannot pass. If your first child was a boy born on Tuesday, your second child only needs to be a boy to pass. If your first child was a boy born not on Tuesday, your second child both needs to be a boy, and needs to be born on a Tuesday to pass.
Given this complex constraint set, it's unsurprising that 50% doesn't actually show up.
# echo 'select child1_gender,count(*) from families where child2_gender = "M" and child2_day=2 group by child1_gender;' | mysql test child1_gender count(*) F 111608 M 112037
50.095% male. If I remove the Tuesday constraint?
# echo 'select child1_gender,count(*) from families where child2_gender = "M" group by child1_gender;' | mysql test child1_gender count(*) F 783068 M 784087
50.03% male.
But you know, perhaps I'm being not literal enough. It's always possible to misencode a problem, and there's a lot of insistence that you have to handle the overlapping case of boy/boy. So, lets try a different mechanism. Lets literally do what the problem asks:
"I have two children, one of whom is a boy born on a Tuesday. What's the probability that my other child is a boy?"
For each family, if either of the children is male, return whether they are both male.
# echo 'select child1_gender=child2_gender from families where (child1_gender="M" and child1_day=2) or (child2_gender="M" and child2_day="2") ' | mysql test | sort | uniq -c | sort -n 1 child1_gender=child2_gender 207934 1 223445 0
...heh! That's kind of neat! I think I shall play with this some more.
Alright. It's 4:21AM, I'm in a random hotel room with a $400 voucher from Delta, and somewhere, someone on the Internet is wrong.
This sounds like a job for SQL.
First, lets start with a table:
# echo "describe families" | mysql test Field Type Null Key Default Extra child1_gender char(1) YES NULL child1_day int(11) YES NULL child2_gender char(1) YES NULL child2_day int(11) YES NULL
Now, lets put a million records in it.
# echo "select count(*) from families" | mysql test count(*) 1025537 # echo "select * from families limit 10" | mysql test child1_gender child1_day child2_gender child2_day F 1 M 0 F 4 M 3 M 1 F 1 F 5 M 1 M 0 M 3 F 0 F 3 M 0 M 2 M 4 F 1 M 6 M 3 F 3 F 1
(We're going to define 2 as Tuesday.) Now, lets look at the problem statement:
"I have two children, one of whom is a boy born on a Tuesday. What's the probability that my other child is a boy?"
We're going to translate that to, as in parent post.
Select the gender of all second children where the first child was born on a Tuesday and the first child was male.
Select the gender of all first children where the second child was born on a Tuesday and the second child was male.
Or, in actual SQL:
select child2_gender,count(*) from families where child1_gender = "M" and child1_day=2 group by child2_gender; select child1_gender,count(*) from families where child2_gender = "M" and child2_day=2 group by child1_gender;
The results?
# echo 'select child2_gender,count(*) from families where child1_gender = "M" and child1_day=2 group by child2_gender;' | mysql test child2_gender count(*) F 36593 M 36617
# echo 'select child1_gender,count(*) from families where child2_gender = "M" and child2_day=2 group by child1_gender;' | mysql test child1_gender count(*) F 36811 M 37031
So, in the first set, we see 49.58% male for the other child. In the second set, we see 50.14% male for the other child.
And in myself, I find a renewed respect for numerical simulation. Happy Tuesday!
Take a thousand families, with two children, where one of the children was a boy born on a Tuesday.
I don't mean a thousand theoretical families. I mean, lets say you straight up took one thousand real families, that matched the above constraints, straight out of the census. No joke, you break out the SQL.
When you check the gender of the other child, you are going to see the breakdown of gender being 50% male, 50% female.
Now, I know there's a lot of fun handwaving going on. Here's the flaw, in a nutshell. There are indeed three possibilities, when one child is constrained to be a boy:
boy, girl girl, boy boy, boy
The mistake -- and it is a mistake, because when you actually run the experiment, the hypothesis is invalidated -- is thinking that each of the above cases is equally likely. Specifically, order of birth has been incorrectly elevated as a determining factor. So we see:
boy, girl: 33% girl, boy: 33% boy, boy: 33%
When we really should be seeing:
boy, boy: 50% boy, girl: 25% girl, boy: 25%
Or, more accurately:
same-gender, both male: 50% different-gender: 50%
boy first: 25%
girl first: 25%
Another way to frame the query, with similar results, is to say:
Select the gender of all second children where the first child was born on a Tuesday and the first child was male.
Select the gender of all first children where the second child was born on a Tuesday and the second child was male.
You'll note the girl, girl families will show up in neither result set. So they can do nothing to skew the numbers.
The results of both queries will, predictably, be 50/50 male and female.
This is a good example of why framing a problem correctly is so difficult and critical. It's only because this problem is so amenable to experimental formulation that it's easily defensible.
(Note that the use of Tuesday was an excellent DoS against math geeks.)
(Note also, by the way, this is the exact opposite of the Monty Hall problem. In that problem, people are expecting:
Door 2: 50% Door 3: 50%...when, really, we have:
Host Told You Where The Car Was: 66%
Was Behind 3, Therefore Exposed 2: 33%
Was Behind 2, Therefore Exposed 3: 33% Host Didn't Tell You Where The Car Was: 33%
Randomly Exposed 2: 16.5%
Randomly Exposed 3: 16.5%
If you modify the Monty Hall problem, such that he opens a random door *which might actually expose the car*, then when he opens the door and you see a goat, it doesn't matter whether you switch or not.)
Heh, can you find me a cite that shows that Groovy is actually extracting the SQL grammar and reassembling it safely? If so that is awesome and I want to cite that.
Basically, I create a wrapper class, that's really just a String inside. But when I test the types for each argument of the vararg wrapper, I can see whether the passed string is a SafeString or a bare (thus unsafe) string.
It occurs to me I didn't release this implementation; I'll get it out there.
I actually put some more demos and test kits on recursion.com, and the slides aren't bad. I really want this to get bashed on.
This isn't taint mode. Taint mode is single language, and in the field, is just turned off without any checking being applied. I don't know of many other efforts that really address the problem that we use strings to communicate across languages, and when we do, we lose all type safety.
There are tricks like LINQ, which allow you to basically express one language with the syntax of another, and I like them lots. (Actually, I think they don't get enough credit for their security implications!).
The idea is that we make very expensive asks of developers, who simply don't follow our advice.
The question is whether we can ask less of developers -- specifically, whether we can get out of this silly zero sum game where the harder software is to write, the more secure it is.
Actually, that's how the Java version works -- you take strings, and subclass them into safe versions and unsafe versions. Then you combine, either through a vararg shell, or through sequential dot notation.
I'm not a big fan of either; I really think interpolation is the right way for a programmer to express intent, and the compiler should be smart enough to extract it.
OK, I was actually there. Not, "I heard this from a guy." I mean, I'm Dan Kaminsky, who's named in the article.
This was kind of a silly situation. One of the guys in our group hit the ball and it sort of sailed into this guy's face. It's a styrofoam ball, the maximum speed of those things is maybe ten miles an hour. It's actually slower than a Nerf ball.
Anyway, the guy who actually hit the thing was sort of an awkward nerd, and laughed about it nervously. You know in the article when the guy's like, it was just one guy? That's because it was just him. There was certainly no mob taunting.
Really, this was a bunch of nerds and burners. There was no damage going on, just general silliness and large scale commerce with institutions that were each contacted in advance and specially staffed to seat all of us. I don't think it'll happen again, and that's sort of sad. Urban golf was a lot of fun for everyone.
Slashdot Mirror
Talk to me about IOPS -- Input/Output operations Per Second -- or don't pretend you're talking to me about performance.
Not saying this isn't actually really exciting, but that's the metric in at least 90% of use cases.
World's largest *unclassified* tunnel boring machine.
My sense is that the MEAN Stack (Mongo, Express, AngularJS, Node) is sort of winning. There's some packaging of it over at mean.io.
Personally, I'm really getting interested in Meteor (www.meteor.com). Watch the videos, and realize I saw a smart non-coder go from zero to *ridiculously* interactive site design in three months.
No really.
I took a pass at Python 3 a while back. The amount of hoops I needed to jump through, to deal with compilation errors around Unicode handling, was terrifying. It was simply a poor user experience.
Python 2.7 just works. Sure, it's a nightmare past a certain scale point. But until you get into the dregs of OO it really is executable pseudocode.
Python 3 is some other language that lost that property.
The big problem is that we don't ship languages with telemetry that reports when they fail to work. So things that are completely obvious to outsiders never make it to inner circles. Not that I can really see any way for Python 3 to mend its errors.
Seriously. Write some code, publish it on Github. Spin up a single serving web page, does one interesting thing as soon as you arrive. Remember, everyone else with resumes could be pretending, you're actually doing stuff.
For work experience, sign up on freelancing sites like odesk. Take jobs just to do them. Nobody knows how old you are, there. Even if all you can do is sysadmin -- well, admin some cloud services!
I'm not seeing any data on what portion of those keys with bad moduli were actually attached to valid certificates.
It's damn fine survey work, but the conclusions are just strange. More detail here:
<a href="http://dankaminsky.com/ronwhit">Survey is good. Thesis is strange.</a>
http://arstechnica.com/apple/news/2012/01/82-percent-of-atts-q4-2011-sales-are-smartphones-66-percent-are-iphones.ars
Yeah. 66% of AT&T's 4th quarter sales were iPhones. I was on Verizon for years, switched to AT&T only for their iPhone, and stuck with them only for their GSM capabilities worldwide. Sure, your margins are less when you offer a better service. Would you prefer no sales though?
The platform that most successfully upgraded itself was the NES. One of the degrees of freedom they had, because there were chips in each cartridge, was to deploy new memory management units inside the games themselves. Quite literally, the NES became more powerful for games released later in its dev cycle. SNES did this too, with the SuperFX chip inside of Starfox (the most popular DSP in the world, for its era) but it wasn't quite the "all games ship upgrading hardware".
I suspect if there was ever to be upgradable hardware, it'd have to work by yearly subscription, and it'd have to be no more than $50 a year for the part. However, with guaranteed sales in the millions of units (as games would hard-require it) the logistics of making some pretty crazy stuff fit into $50/yr wouldn't be unimaginable. Remember that XBox Live is already pulling, what, $60/yr?
You realize this is completely unscientific garbage, right? None of http://www.fwi.co.uk/Articles/25/01/2011/125212/Handle-with-care.htm makes sense outside of a conscious entity.
Applications will never, ever tell you anything bad about DNSSEC.
They might tell you a TLS validation failed, but that an IP was good or bad? No.
We can do this incrementally, mostly because we're just *not* securing most things right now. So the conversion cost is lower than you'd think.
DNSSEC is an infrastructure shift, and you can't use it on .com domains for another few months. Have some patience.
At Black Hat this year, I actually demonstrated the endgame. Want federated authentication in OpenSSH that actually scales? Want servers able to autogenerate TLS keys that will be recognized and secured worldwide, even against broken certificate authorities?
Want secure email, without the mess that is PGP key management?
End to end secure key management via DNSSEC makes it all actually really easy. Code is here -- BSD licensed, feel free to play:
http://dankaminsky.com/phreebird
Also, I'm putting together a set of diaries on the subject:
http://dankaminsky.com/2010/12/13/dnssec-ch1/
Enjoy!
The problem is collateral damage. Legitimate actors can't get into the DDoS game, because if they legitimize DDoS, the network will *fry*.
The "good guys" cannot flood nearly as significantly as the bad guys. Worse, the good guys are significantly more exposed -- they have corpnets, they have partner nets, etc. Today it's the website, tomorrow it's Hulu.
There are paths on which the anti-piracy people have the high ground (not moral high ground, tactical high ground). DDoS, in no uncertain terms, is not one of them.
Fascinating! Looks like I got to spend the night being wrong myself. Serves me right for being so cocky.
It seems that the key to this question is that there are boy/boy pairs where neither boy was born on a Tuesday. That's why Tuesday matters:
If your first child was not a boy, you cannot pass.
If your first child was a boy born on Tuesday, your second child only needs to be a boy to pass.
If your first child was a boy born not on Tuesday, your second child both needs to be a boy, and needs to be born on a Tuesday to pass.
Given this complex constraint set, it's unsurprising that 50% doesn't actually show up.
OK, now with 3.13M families:
50.095% male. If I remove the Tuesday constraint?
50.03% male.
But you know, perhaps I'm being not literal enough. It's always possible to misencode a problem, and there's a lot of insistence that you have to handle the overlapping case of boy/boy. So, lets try a different mechanism. Lets literally do what the problem asks:
For each family, if either of the children is male, return whether they are both male.
...heh! That's kind of neat! I think I shall play with this some more.
Alright. It's 4:21AM, I'm in a random hotel room with a $400 voucher from Delta, and somewhere, someone on the Internet is wrong.
This sounds like a job for SQL.
First, lets start with a table:
Now, lets put a million records in it.
(We're going to define 2 as Tuesday.) Now, lets look at the problem statement:
We're going to translate that to, as in parent post.
Or, in actual SQL:
The results?
So, in the first set, we see 49.58% male for the other child. In the second set, we see 50.14% male for the other child.
And in myself, I find a renewed respect for numerical simulation. Happy Tuesday!
Take a thousand families, with two children, where one of the children was a boy born on a Tuesday.
I don't mean a thousand theoretical families. I mean, lets say you straight up took one thousand real families, that matched the above constraints, straight out of the census. No joke, you break out the SQL.
When you check the gender of the other child, you are going to see the breakdown of gender being 50% male, 50% female.
Now, I know there's a lot of fun handwaving going on. Here's the flaw, in a nutshell. There are indeed three possibilities, when one child is constrained to be a boy:
boy, girl
girl, boy
boy, boy
The mistake -- and it is a mistake, because when you actually run the experiment, the hypothesis is invalidated -- is thinking that each of the above cases is equally likely. Specifically, order of birth has been incorrectly elevated as a determining factor. So we see:
boy, girl: 33%
girl, boy: 33%
boy, boy: 33%
When we really should be seeing:
boy, boy: 50%
boy, girl: 25%
girl, boy: 25%
Or, more accurately:
same-gender, both male: 50%
different-gender: 50%
boy first: 25%
girl first: 25%
Another way to frame the query, with similar results, is to say:
Select the gender of all second children where the first child was born on a Tuesday and the first child was male.
Select the gender of all first children where the second child was born on a Tuesday and the second child was male.
You'll note the girl, girl families will show up in neither result set. So they can do nothing to skew the numbers.
The results of both queries will, predictably, be 50/50 male and female.
This is a good example of why framing a problem correctly is so difficult and critical. It's only because this problem is so amenable to experimental formulation that it's easily defensible.
(Note that the use of Tuesday was an excellent DoS against math geeks.)
(Note also, by the way, this is the exact opposite of the Monty Hall problem. In that problem, people are expecting:
Door 2: 50% ...when, really, we have:
Door 3: 50%
Host Told You Where The Car Was: 66%
Was Behind 3, Therefore Exposed 2: 33%
Was Behind 2, Therefore Exposed 3: 33%
Host Didn't Tell You Where The Car Was: 33%
Randomly Exposed 2: 16.5%
Randomly Exposed 3: 16.5%
If you modify the Monty Hall problem, such that he opens a random door *which might actually expose the car*, then when he opens the door and you see a goat, it doesn't matter whether you switch or not.)
[This is Dan]
So, if they're so great, why does the boss have to put a gun to people's head?
[This is Dan]
Heh, can you find me a cite that shows that Groovy is actually extracting the SQL grammar and reassembling it safely? If so that is awesome and I want to cite that.
[This is Dan]
Basically, I create a wrapper class, that's really just a String inside. But when I test the types for each argument of the vararg wrapper, I can see whether the passed string is a SafeString or a bare (thus unsafe) string.
It occurs to me I didn't release this implementation; I'll get it out there.
I actually put some more demos and test kits on recursion.com, and the slides aren't bad. I really want this to get bashed on.
Because they're much harder to work with. If they weren't, we wouldn't have to beg developers to use them.
[This is Dan]
This isn't taint mode. Taint mode is single language, and in the field, is just turned off without any checking being applied. I don't know of many other efforts that really address the problem that we use strings to communicate across languages, and when we do, we lose all type safety.
There are tricks like LINQ, which allow you to basically express one language with the syntax of another, and I like them lots. (Actually, I think they don't get enough credit for their security implications!).
[This is Dan]
The idea is that we make very expensive asks of developers, who simply don't follow our advice.
The question is whether we can ask less of developers -- specifically, whether we can get out of this silly zero sum game where the harder software is to write, the more secure it is.
Interpolique is an effort in this direction.
[This is Dan]
Actually, that's how the Java version works -- you take strings, and subclass them into safe versions and unsafe versions. Then you combine, either through a vararg shell, or through sequential dot notation.
I'm not a big fan of either; I really think interpolation is the right way for a programmer to express intent, and the compiler should be smart enough to extract it.
OK, I was actually there. Not, "I heard this from a guy." I mean, I'm Dan Kaminsky, who's named in the article.
This was kind of a silly situation. One of the guys in our group hit the ball and it sort of sailed into this guy's face. It's a styrofoam ball, the maximum speed of those things is maybe ten miles an hour. It's actually slower than a Nerf ball.
Anyway, the guy who actually hit the thing was sort of an awkward nerd, and laughed about it nervously. You know in the article when the guy's like, it was just one guy? That's because it was just him. There was certainly no mob taunting.
Really, this was a bunch of nerds and burners. There was no damage going on, just general silliness and large scale commerce with institutions that were each contacted in advance and specially staffed to seat all of us. I don't think it'll happen again, and that's sort of sad. Urban golf was a lot of fun for everyone.