NPM – Better Search Is Here - <AUTHOR> http://blog.npmjs.org/post/154912817335/better-search-is-here <comment><AUTHOR> Sorting criteria is explained here: [https://github.com/npms-io/npms- analyzer/blob/master/docs/ar...](https://github.com/npms-io/npms- analyzer/blob/master/docs/architecture.md#evaluators)</comment>


TypedJS: Sanity Check your JavaScript   - <AUTHOR> http://typedjs.com/

<comment><USER2> Please don't use non-commercial licences: you are greatly limiting the number of people who can _afford_ to contribute to your project.

<comment><USER3> Furthermore I don't think CC licenses are meant to be used for code: <http://creativecommons.org/software>

</comment></comment><comment><USER4> Interesting, but if I wanted to get this sort of validation I'd just use Google's Closure Compiler. It supports validating types and also lets you do things like casting variables to different types. And the annotation method is pretty clear, flexible, and easy to understand.

</comment><comment><USER5> Can the implementation be typed? <https://github.com/Proxino/TypedJS/blob/master/typed.js>

</comment><comment><USER6> At first glance this is a fuzz generator not a type checker.

</comment><comment><USER5> What is the license that is free for non-commercial use? Static type checking is nice but implementation in a non-statically-type-checked language is unfortunate.

</comment><comment><USER7> I think Closure Compiler is a lot more useful than this. You get type checking, but you also get best of breed optimization/minification too.

You don't get the automatic runtime test generation stuff, but that's more along the lines of an add-on utility like Quickcheck/Scalacheck.

</comment><comment><USER8> The add_all() function as presented on their web page is wrong,instead of adding the array elements it just returns the last one.

Line 180 should be: count += num_arr[i];

Moreover naming accumulation variable for sum "count" is totally counter intuitive.

</comment><comment><USER9> Interesting idea but I'd _hate_ to maintain that.

</comment><comment><USER10> How much performance hit would it costs, and is there a companion tool that I can remove only those comments with types?

</comment><comment><USER11> I never saw someone using "nil" in JavaScript (even in a comment). I guess the author has a Ruby background.

</comment><comment><USER12> From their home page example

if(obj.valid === true) {

I would flag this line as an error.

<comment><USER13> Why? obj is specified by the type annotation to be an object with a property 'valid' that is a Boolean, so what's the problem?

<comment><USER12> I just don't like this style very much. It's better to write

if (obj.valid) {

<comment><USER14> `if (foo)` and `if (foo === true)` aren't equivalent.

<comment><USER15> According to the TypedJS annotation for the function they are. The function definition says that obj.valid has to be a boolean, so any other type of falsy input (0, undefined, null, etc) should never be provided as an argument here.

</comment></comment></comment></comment></comment><comment><USER16> It would be more interesting if you could also use the annotations to type- check at runtime (optionally). That way if the annotations diverged from the actual code, you'd find out.</comment>


Netflix's Advice on Moving to Amazon Web Services - <AUTHOR> http://cloudscaling.com/blog/cloud-computing/cloud-innovators-netflix-strategy-reflects-google-philosophy

<comment><USER2> C'mon folks...don't reward the blatant blogspam with traffic. The original source is linked right there in the second paragraph:

[http://cloudscaling.com/blog/cloud-computing/cloud- innovator...](http://cloudscaling.com/blog/cloud-computing/cloud-innovators- netflix-strategy-reflects-google-philosophy)

<comment><USER3> <http://news.ycombinator.com/item?id=1934273>

</comment></comment><comment><USER4> One thing I almost never hear in articles about moving to AWS is the mention of network latency and variability of latency. It seems like a fantastic platform for bulk/batch processing but much less so if your service requires low and/or predictable network latency/response times.

</comment><comment><USER5> I notice that they still have data _gathering_ systems in house. They are using the cloud servers for content _distribution_. I suspect even the processing is light: authenticate the user (redirection referrer), determine device parameters, start pumping bytes.

<comment><USER4> Sounded to me it's more like they're using CDNs for content distribution and Amazon AWS for bulk/batch processing jobs. From the original article:

 _RLB: Could you describe at a high level what Netflix is doing on AWS?

AC: Encoding movies for streaming, log analysis, production web site and API, most everything that scales with customers and streaming usage. Easier to say what we don't have there: most internal IT that scales with employee count, legacy stuff, DVD shipping systems, account sign-up and billing systems. We use Akamai, Limelight and Level3 CDN's for streaming the movies, which is a cloud based service. There is an AWS CDN service, but they aren't a big enough player in this space at this point._

</comment></comment><comment><USER6> Anyone know how many AWS instances (and what types) are being run? Are these the same servers that account for up to 20% of downstream bandwidth in the U.S.?

<comment><USER7> I doubt these servers account for the bandwidth, since the article mentions they are using other CDNs for hosting the streaming since CloudFront isn't yet up to the same level.</comment></comment>


Calculating your customers lifetime value (with code) - <AUTHOR> http://thestartupfoundry.com/2011/05/13/calculating-your-customers-long-term-value-with-code/ <comment><USER2> I've done some work on CLTV for one of the major online gaming services. Definitely agree with the segmentation by High/Med/Low as well as the deeper analytic segmentation.

One thing I like to tack onto the setup described is a survival analysis. I've done it mostly in SAS due to my clients, but it's just as easy (and free) in R. Essentially I'm using survival analysis to see what signs indicate someone who is likely to leave/downgrade/upgrade.

Can't really go into details, but essentially I was checking on: minutes played / # of friends who played the same games / freq of games purchased / freq of in-game purchases / purchase method (online vs. in-store giftcard) / plus a lot more. This was in order to predict likelihood of renewing at the next subscription term. Ostensibly this was to intervene and make an offer to retain a customer or squeeze more out of them. Can't say for sure what ultimately happened with the analysis and tools I delivered: I do know it helped someone score a new job.

I can't offer any of the original code (but I could write up some of the basic structure if there's some interest).

<comment><USER3> Survival analysis is definitely the right way to go for this.

Some good resources in R: [http://www.stat.ucdavis.edu/~hiwang/teaching/10fall/R_tutori...](http://www.stat.ucdavis.edu/~hiwang/teaching/10fall/R_tutorial%201.pdf) [http://www.stat.ucdavis.edu/~hiwang/teaching/10fall/R_tutori...](http://www.stat.ucdavis.edu/~hiwang/teaching/10fall/R_tutorial%202.pdf)

In particular, what it allows you to do is to estimate the future duration -- saying that your average LTV is the 6 months of average revenue from your existing customers as the article suggests is incomplete, because the portion of customers who haven't lapsed will continue to provide revenue. With survival analysis, you can estimate the full durational curve to get this right.

Future value generally doesn't matter a huge amount if you're just looking for gross differences across segments, but anything you're getting particularly precise on (like when you want to figure out allowable cost for advertising based acquisitions), needs to take this into account.

There are tons of other great lessons to apply to "regular" business from actuarial science.

<comment><USER2> >what it allows you to do is to estimate the future duration -- saying that your average LTV is the 6 months of average revenue from your existing customers as the article suggests is incomplete, because the portion of customers who haven't lapsed will continue to provide revenue.

I'm almost certain we agree, just want to add two clarifying points for those interested:

+You probably want to try experimenting with different combinations of datasets for left-censored, right-censored and full lifetime cases. Or, at least segmenting that way when you perform the survival analysis (Haven't checked out noahnoahnoah's references yet, so they may mention this).

+Also, the other tricky thing is when it's a subscription service (3,6,12 month sort of thing). Main reason this introduces complications is that you need to account for a "unsubscribe signal" that may not sync well with the next prompt to renew. So rather than predict a survival likelihood at the unit of analysis (I assume monthly, maybe weekly) you need to generate a likelihood for the point in time when the user is prompted to renew (and again, you can also vary that to move it up before the real end of the subscription). It's not particularly hard to grasp at a general level, but it takes a lot of careful thinking of edge cases.*

*That description may be a little convoluted, to simplify: What happens when a 12mo subscription shows signs of leaving only 6mo in?

<comment><USER3> Yep, we agree. Well said.

</comment></comment></comment></comment><comment><USER4> I admire what Paul is doing with the site.

He launched it here on HN with a goal of adding substance to startup blogging. This post shows he's sticking with that mission.

It's much easier to get traffic by stirring controversy or talking about bubblegum issues like "5 ways Twitter is changing everything" posts. But substance posts like this are harder to pull off on a regular-basis.

</comment><comment><USER5> Disclaimer: I'm the co-founder of Custora (YC W11), and one of the keys to our product is accurate lifetime value estimation.

This is a great rundown of how to do a descriptive revenue per customer analysis.

As many have pointed out here, true CLV really needs to account for the expected value of customers as well -- not just what we have seen, but how we expect customers to behave into the future. This information can help us determine how much to spend on customer acquisition. Even better, performing the calculations across acquisition sources helps us decide where to spend our advertising dollars in future periods.

The single most important thing to recognize when building a survival model is that there isn't a constant retention rate. Instead, when customers join, some are good (slow churners) and others are bad (quick churners). The key to an accurate survival analysis (and thus, an accurate LTV number), is getting a sense of this distribution of customers.

<comment><USER6> I just found your company today listed as mailguns customer list. You guys are doing awesome stuff!

</comment></comment><comment><USER7> That's not lifetime value. Let's break the term down:

 _Lifetime:_ The entire length of the relationship with your customer, including the future, not just for the period where you have data, as done in the article. Of course there will be some estimating involved, but that's what happens when you consider an entire "lifetime".

 _Value:_ All cash flows (in AND out) attributable to the customer, discounted to present value. Not just revenue as used in the article. If your sales (e.g. adwords) or support costs are at all significant, you can't ignore them.

I know it's easier to criticize than to write up a helpful article. I do applaud the blogger for taking the time to write about this, but can only recommend not using words like lifetime value to describe something else entirely.

<comment><USER6> Thanks for the comment!

Re Lifetime: Good point, this is value (or more precisely, revenue) to date.

Re Value: The post outlines the first step in deriving "true" value. The intent is to allow you to take the ltv as described & subtract the appropriate costs to find a net gain or loss.

Sorry for not being as thorough as I should have, I'll try to get an amendment from Paul.

<comment><USER7> Pleasure.

Here's an example to help illustrate:

        Discounted (future) revenues: $100
        Discounted (future) ongoing costs: $20
        Value: $80 ($100 - $20)
        Acquisition cost: $60 (e.g. adwords)
        Net Present Value (NPV): $20 ($80 - $60)

An NPV of $20 means you _create_ $20 in value by acquiring a customer. That's what you were trying to say with "true" value / net gain or loss - but there's no such thing as "true" value - you're either working with value or you're not.

Note that revenue to date did not figure into any of the above - we're concerned with the future here, so the past is only useful in as much as it helps you with forecasting.

The wikipedia page on CLV is surprisingly good, have a look.

</comment></comment></comment><comment><USER8> How do you calculate CLTV without knowing how long people subscribe with some precision? Doesn't attrition rate factor into the calculation?

It seems that this would be especially hard to determine if (a) you're a fairly new biz or (b) users stay with you for a long time.</comment>


$.answer=42 - <AUTHOR> http://www.google-analytics.com/analytics.js

<comment><USER2> It's tricky to tell exactly what's happening because the code is obfuscated through compilation, but as best I can tell, it's using the `answer` value to prevent another global from making it seem like the Analytics code has already been initialized.

There is a JavaScript object representing all of the Google Analytics state and functions. When this object is set up, they add the property "answer = 42" to it. Then, before making this object globally accessible at `window.ga`, they double check that `window.ga` does not yet exist or that `window.ga.answer` does not equal 42. If it already equals 42, then the initialization must have already happened (maybe the Analytics code was included twice?), and so it doesn't proceed to clobber that already- initialized global Analytics state. Checking that the `window.ga` variable doesn't exist is not quite enough, since other JavaScript on the page may have set that property for some reason (of course, this logic wouldn't work if other code on the page had simple set `window.ga.answer = 42`, but that's unlikely to happen by accident). As long as it looks like the initialization hasn't already run, then it goes ahead and does the initialization and makes the result globally accessible at that point.

tl;dr: It's not just a joke; it's actually used to make it less likely that other JavaScript on the page hasn't created a global variable called `ga` which may otherwise prevent the Analytics code from running.

<comment><USER3> Here's an useful website if you want to make the code more readable: [http://jsbeautifier.org/](http://jsbeautifier.org/)

<comment><USER2> Chrome also has a button[0] to do this automatically in the Developer Tools, which is what I used when I wrote the initial comment.

[0]: [https://developers.google.com/chrome-developer- tools/docs/ja...](https://developers.google.com/chrome-developer- tools/docs/javascript-debugging#pretty-print)

</comment></comment></comment><comment><USER4> It's been a few decades.. Maybe time for some new community jokes?

<comment><USER5> Agreed...

</comment></comment><comment><USER6> $ is what? [1]

[1] For those not in on the joke: [http://en.wikipedia.org/wiki/42_(number)#The_Hitchhiker.27s_...](http://en.wikipedia.org/wiki/42_\(number\)#The_Hitchhiker.27s_Guide_to_the_Galaxy)

<comment><USER7> var $=function(a){J(1);Z.D[G](Z,[arguments])};

$ is a function object.

$.answer is a property of that object.

$ itself doesn't really mean anything special in javascript.

jQuery and other libraries often use $ as their main object, so it's probably best to avoid using it unless you need to or it's wrapped in another function.

<comment><USER8> The only thing I've learned in the years that I've been writing Javascript is that the dollar symbol variable is as contentious as the West Bank. Obviously there has to be globals somewhere or else a library ceases to be a library in JS, but I see no problem is using the word jQuery explicitly, or simply passing it into a SEAN/IIFE:

      (function($) {
         $('#thing').hide();
      })(jQuery);

<comment><USER9> Yes, that's how you write a jQuery module. That's how I do it:

        (function($,undefined) {
            "use strict";
            ...
        })(jQuery);

Note the undefined. That's because undefined is not a literal but a variable in JavaScript and can be assigned to anything. This way I ensure that undefined is really undefined and "x === undefined" works. But I digress.

<comment><USER8> It has nothing to do with jQuery, or anything else. (function() {})(); is a pretty standard Javascript pattern to execute an anonymous function immediately at evaluation. Because javascript has lexical scoping at the function, your use of "use strict"; and any var-prepended variables won't be hoisted up the prototype chain, potentially becoming globals. The ability to pass in a global as a local variable is simply a convenience. The global is available inside the closure anyways. It's a global after all.

My point was, the battle over the dollar sign single character variable name is stupid.

</comment></comment></comment></comment></comment><comment><USER10> Slightly OT: What is the background for allowing $ to be used in ECMAScript identifiers? I imagine there could be some compatibility background.

</comment><comment><USER11> Nice finding ! And it's so true ! _42 is the answer to everything_ ;)

Even to check an instantiation ...

        $.answer = 42;

[...]

        $.N = function () {

            var a = O[gb];

            if (!a || 42 != a.answer) {

[...]

                O[gb] = $;

[...]

            }

        };

        $.N();

<comment><USER12> _42 is the answer to everything_

That's not really what the Hitchhikers Guide to the Galaxy said - rather, 42 is the answer to _the ultimate question of life, the universe and everything_. But since we don't know what the question is... Very different from _the answer to everything_.

</comment></comment><comment><USER13> A bit of context: [http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker's_G...](http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker's_Guide_to_the_Galaxy#The_number_42)

</comment><comment><USER14> Is it just me, or is their analytics JS file down?

<comment> a-l-c-o Like you I got a 404. Then I remembered I blacklist this adress in /etc/hosts :

0.0.0.0 google-analytics.com

Maybe you forgot you do too ?

<comment><USER15> Maybe a little off topic, but what's the purpose for that? Does it make websites that use google analytics unable to track your visit?

<comment><USER16> Everytime you visit a GA enabled site, it sends back some information to the Google servers including url, referrer, time spent etc. Google can use this build up a history of websites you (this is not linked to your Google account, more like an unique id) frequent and show targeted advertisements.</comment></comment></comment></comment>


Twitter CEO Jack Dorsey: I 'fully admit' our bias is 'more left-leaning' - <AUTHOR> http://thehill.com/policy/technology/402495-twitter-ceo-jack-dorsey-i-fully-admit-our-bias-is-more-left-leaning <comment><USER2> I'm sorry, but the internal evidence is that Twitter's internal bias is _not_ left-leaning. It took a storm of complaints and publicity to get them to punish Infowars, for example. There's lots of anecdotal data that has Twitter punishing minor infractions of left-leaning users harsher than major infractions by right-leaning users.

This looks like an elaborate excuse to give conservative/fascist opinions a little affirmative action.</comment>


NYC's taxi commission says "yes" to one-year trial of taxi-hailing apps - <AUTHOR> http://skift.com/2012/12/13/breaking-new-york-citys-taxi-commission-is-deciding-fate-of-hailing-apps-right-now/

<comment><USER2> We don't need to be able to hail yellow cabs with an app, we need to be able to hail black cars with an app. Cabs aren't going to come to BK because they got a text message, they all swarm around Manhattan looking for short fares, but black car services are local and could benefit from easier dispatch and payment.

If you ask me this is the TLC anticipating public demand for the app and stepping in the way of it actually being useful under the guise of playing along.

<comment><USER3> I think you're probably right, and it's crazy that this is the way things are in NYC. I live in Seattle now (originally from the NYC area) and use Uber extensively. I would be incredibly angry if Seattle tried to pull the same kind of crap that NYC and SF do in regards to black car services like Uber.

</comment></comment><comment><USER4> Why do New Yorkers think it's acceptable that the NYC Taxi Commission gets to say yay or nay on the app?

<comment><USER5> Since they're the ones that control the taxis, I don't see why they wouldn't have a say in the matter.</comment></comment>


Ask HN: AOL owns a domain name I could really use. How to get it? - <AUTHOR>

To be honest, the domain is worth more than I can afford. Can anyone offer any sort of strategy suggestion as to how to approach this?<p>They are not using the domain. <comment><USER2> You'll probably never get it without an exorbitant amount of money.

Try looking for a similar name plenty of people use search engines and bookmarks so a domain like thexxxx.com or getxxxx.com isn't that ridiculous.

</comment><comment><USER3> Make a PDF/html email (pictures, etc etc) that comes off as a desperate plea for help with a project that you have a ton of passion for, then email it to every support email address you can find. If you can make it seem like they're helping a student, single father, struggling programmer, whatever, it might get a forward to someone who can help.

That's my only idea other than the negativity that seems to have infected HN as of late (or maybe it was just a period of positivity when I first showed up?)

</comment><comment><USER4> [http://www.fourhourworkweek.com/blog/2009/02/27/how-to- buy-d...](http://www.fourhourworkweek.com/blog/2009/02/27/how-to-buy-domain- names-like-a-pro-10-tips-from-the-founder-of-phonetagcom/)

See item 4d in the list. James Siminoff tells how he pleaded for and was given the domain Noble.com for free.

</comment><comment><USER5> What makes the domain name valuable? People stopped looking for services by domain name about ten seconds after Google was invented. Unless it's a brand name and trademark-sensitive, there's not much you can do.

If you have a viable money-making idea, build it without the magical domain name, get rich, buy the domain.</comment>


Why pennies cost more than they're worth - <AUTHOR> http://theincidentaleconomist.com/wordpress/why-pennies-cost-more-to-mint-than-theyre-worth-in-one-picture/

<comment><USER2> Whenever I hear the phrase "a penny saved is a penny earned", I like to point out that if you do a back of the envelope calculation for inflation you'll come up with a penny being worth approximately $5 when Benjamin Franklin made his famous quote.

He probably would have thought us to be morons for hand-wringing over a few cents.

<comment><USER3> Is that so? I find it hard to imagine a currency in which the smallest denomination available is the equivalent of five dollars.

If you're inventing a new currency from scratch, why not have a smaller minimum denomination?

<comment><USER4> There were half pennies and farthings (quarter pennies).

Once the US got done with revolting and got around to writing a constitution they decreed the "mill" would be 1/10th of a penny. They seem to have largely only useful for sales tax.

I think a smaller coin would have been impractical:

• Coins were self-backing with their metal value. Even in copper, it gets too small to keep track.

• Manufacture was more labor intensive, the cost to produce a very low coin is a problem.

• Mass production hadn't devalued objects, so things we think of as cheap today would have been relatively more expensive.

• If you live in a small community and "run a tab" at the general store, you don't make payment in small batches.

None of these speculations should be mistaken for accurate historical facts.

<comment><USER3> OK, I looked it up for myself, and the one penny = five dollars conversion doesn't seem too far from the truth. This page gives some 18th-century prices for various things; in British pennies rather than US pennies, but I'm assuming they were similar in value since they were both small coins of copper:

<http://footguards.tripod.com/08HISTORY/08_costofliving.htm>

Half a penny = half a loaf of bread, implying bread was five bucks a loaf... just a bit too expensive by today's standards.

1.5 pennies was an hourly rate for a boy to chop firewood -- I bet you could hire a kid for $7.50 an hour nowadays.

1 penny was enough gin to get drunk on... a third of a bottle of the cheapest $15 gin would get you pretty drunk.

4d was a quart of beer. OK, that's pretty expensive.

1s (12 pence) gets you a dinner at a steakhouse with beer... yep, sixty bucks is a plausible price for a steak dinner. It's also the sign-on bonus for joining the Army, which seems like a bit of a gyp, or postage for a letter from London to New York. (!)

So in conclusion, if you take the one penny to five dollars conversion, then some things (basic foodstuffs) seem expensive while others (labour) seem cheap. This is consistent with the fact that people were much poorer (in real terms) back then, and you'd have to chop wood for 40 minutes just to buy a loaf of bread.

It still seems like a weird way to use money, but I guess that's just because I've grown up in a world where it's entirely possible to undercut your competition by 1% on the price of a loaf of bread. If that ability went away, I might not miss it.

</comment></comment></comment></comment><comment><USER5> Would have been more interesting if there were numbers attached to each step of the minting process. For example, +0.05 cents for stamping, -0.1 cents for recycling damaged coins, etc.

</comment><comment><USER6> A penny is "worth" one cent in that it is the value it represents. However, it can be exchanged many times contributing value in each exchange. Also, there are many other coins that likely cost less to mint than they are "worth". I think you need to look at the overall cost of minting for all coins and blend it together to get a more accurate view.

<comment><USER7> That's along the lines of what I was thinking too. The cost of making a penny isn't really material to the fact that it's worth 1 cent. That'd only be relevant if pennies were used one time, which then would be an issue.

But pennies are re-used multiple times. So a cost of two cents is fine when you consider that.

Now a better question to ask is what are the transactional costs of maintaining prices that require pennies (as oppose to, say, 5 cent increments). Those costs are the better ones to look at, I think.

<comment><USER3> _But pennies are re-used multiple times. So a cost of two cents is fine when you consider that._

Right, until you get to the point where the metal inside a penny is worth so much more than the face value that it becomes worthwhile for somebody to start melting them down. Luckily that doesn't seem to be the case yet (at least not with the new-denomination pennies).

They're still pointless coins, though. Get rid of them.

</comment></comment></comment><comment><USER8> A penny is pretty much negative money, if you care about the debt.

I see no major problem with getting rid of it - other countries have, after all. <http://en.wikipedia.org/wiki/Swedish_rounding>

</comment><comment><USER9> Pre 1982 pennies are worth like 2 or 3 cents melted down I believe. They are becoming more and more rare because they are made of copper, a valuable resource. The federal reserve is printing money out of thin air and diluting the currency more than ever. This means that as we move forward, too many dollars are going to chase too few goods and the prices will rise. Eventually if this grand theft is left to continue without limit, the Federal reserve will print so many dollars that one day even the paper fabric of the money will become worth more than what you can buy with it.

Nickels are worth about 6 cents I recall. Don't get caught melting down pennies or Nickels for the guaranteed profit because it is a crime. However, as inflation continues, the value of the materials in the coins will rise to infinity, at that point all coins will mysteriously vanish and the mint will not make new ones. They will instead add zeros to the dollar bills.

Buy gold, it's going to $5000 an ounce in the next year. Gold is flatline, it is a stable store of value, the gold is not gaining value, it's the unit of measure you're using that is depreciating.

<comment><USER10> Gold is _not_ flatline, nor stable, especially when adjusted for inflation (CPI-U). Gold, like money, is based on faith. People expect it is a limited resource, but in reality, the price of gold simply hasn't always been at a point where it is profitable to mine more of it.

<http://en.wikipedia.org/wiki/File:Gold_price_in_USD.png> <http://en.wikipedia.org/wiki/Gold_as_an_investment>

<comment><USER9> Your correct it is not flat, it's value is modified by how much gold can be mined by companies. Also it is modified by how many people want the metal itself.

What I meant to say that if you worked hard for a year 200 years ago and saved yourself maybe 10 ounces of gold, and buried it in the ground for 200 years and now you have those 10 ounces. The goods and services you could buy between then and now would be comparable. whereas the various currencies he used 200 years ago would be either completely worthless or decreased in value 99.99%.

Gold is going to be around for another 50 years, and you'll be able to buy things with it. The US Dollar however is not. When I say gold is flatline, I mean that in principle a ounce of gold saved will buy you nice things 50 years from now, a thousand dollars now will buy you nothing 50 years from now.

<comment><USER11> The belief that gold holds an intrinsic value is wrong, and the advice you derive from it is incredibly misguided.

There's nothing special about gold. It has some nice properties that make it intrinsically valuable, but not more than copper or other metals. The reason basically all cultures value gold is that other people like it also, and it is hard to counterfeit.

That being said, gold goes through the same ups and downs in perceived value as any other commodity. For what I have read, it is trading now more or less around its long term historic value (think centuries long). If there's so much buzz about gold now, it is because it is coming from a few decades long of sub-valuation, but this is correcting fast, and the pendulum begins to swing now to the other side. If you are not able to pick your time correctly, you'll be loosing money soon enough.

Besides, there is the fact that it is a long time investment. If you are forced to liquidate your position to pay whatever need you have, you will probably loose money. And there's the commissions that will eat out on each transaction, so you better hold to gold until it is a really good time to sell.</comment></comment></comment></comment>


Why you should Never fly into Washington National Airport - <AUTHOR> http://jethead.wordpress.com/2011/12/24/why-you-should-never-fly-into-washington-national-airport/ <comment><USER2> I live in DC and fly into reagan all the time. There is a small park at the very end of the runway where you can watch planes landing that fly just 100 ft above you. It's pretty awesome.

The author of this post suggests you should rather fly into Dulles because the approach to reagan is so dangerous. What isn't factored in is that in rush hour, a commute from dulles to DC can take 2+ hours (and, mind you, the DC metro area has the worst traffic and highest rate of accidents in the country). From reagan you can take the metro and be downtown in 15 minutes. Also, a mere cost of a taxi from dulles (or BWI) to DC will cost just as much as your airfare.

<comment><USER3> The post says there is a metro line to Dulles. Is this not correct?

<comment><USER4> Technically there's not a Metro _rail_ line to Dulles, but there is a Metro express bus that runs there -- the 5A bus picks up passengers at L'Enfant Plaza in DC and Rosslyn in Virginia, and then goes straight out to Dulles without any further stops. [1]

Rail would be better, since the rail cars are more comfortable than buses and don't get stuck in traffic. Unfortunately given the dysfunctional nature of Metro governance the long-hoped-for rail line to Dulles is one of those things that never actually seems to get any closer to completion.

[1] <http://wmata.com/bus/timetables/dc/05a.pdf>

<comment><USER5> The 5A stops at Herndon and often at Tysons/Westpark as well. I don't mean this as a nitpick; it's relevant because a direct trip from Rosslyn to Dulles could take the airport lanes on the toll road all the way from the 66/267 split, but the additional stops mean the bus can't take advantage of the airport lanes, making for a painfully slow trip. I've done it a few times, and it's just not practical if one is travelling for business and at all pressed for time.

National on the other hand is a downright pleasure to fly out of. I go through National once every week or two and Dulles every month or so. Parking, security lines, and everything else are _so_ much better at National.

</comment></comment></comment></comment><comment><USER6> He fails to mention that on the approach you get one of the best views of DC you can get, the pentagon on the right, and the entirety of the city on the left. It is one of the most scenic approaches of any major airport. And it being 10 minutes from downtown is nice as well.

<comment><USER5> Second this one - choose a window seat on the left if you have a flight into DCA. If you are lucky, you'll land from the north, and get an amazing view of the city as you approach - at pretty low altitude so you see everything very clearly.

I've lived here all my life and fly in and out of DCA every week or so, and that view still never gets old.

</comment></comment><comment><USER7> Great article. It's nice to hear from experts in other fields regarding things that involve their expertise, but affect me in ways I didn't previously understand. It's not unlike being in one of those conversations with my relatives on how the computer works...

</comment><comment><USER8> Commenters are failing to mention that the article is about why you shouldn't fly a plane into Regan, not why you shouldn't be on a plane that is flying into Regan.

All of the issues is about piloting, not about traveling.

<comment><USER3> Well all else being equal, would you rather be on a flight with an "easy" approach and more margin for safety in terms of things like runway length and not falling into a river if the pilot makes a mistake, vs. not?

<comment><USER9> On the other hand, would you rather have a pilot that's relaxed due to an easy approach and not giving a landing his full attention or one that he knows he's coming into a dicey situation and giving it his all?

</comment></comment></comment><comment><USER10> The author posts this criticism of DCA from a pilot's perspective, but sprinkles it with cynical opinions on why _passengers_ prefer DCA over IAD, which undermines the whole article. The reality is that I—and many others—would rather pay more to fly out of DCA than IAD. For me, it's Metro access that seals the deal. We'll see what happens after IAD becomes metro accessible.

</comment><comment><USER11> There are a few airports I can think of around the world that are a little more concerning (and possibly more fun).

<http://www.oddee.com/item_93109.aspx></comment>


Please Don't "Learn to Code" - <AUTHOR> https://medium.com/@iancackett/please-don-t-learn-to-code-5525c46d4403#.4ws6rfl0t <comment><USER2> Highly disagree with the author. Not everyone who learns to code needs to go on to become a software developer or engineer. I actually really like the idea of coding being another skill like sewing, cooking or arts and crafts. Something that some people do professionally, but most people have a basic understanding of for when they need it.

<comment><USER3> Yeah, it overlooks the fact that with many of the tools we use now, a little coding can go a long way. I'm far more productive in my job because I can manage to make some of my own tools instead of waiting for the IT department to provide me with something that will likely be not what I asked for, if they even ever get around it it.

<comment><AUTHOR> There is certainly a place for "a little coding", as you put it. I used to work in an investment bank where traders would write their own Excel macros to perform duties it would've taken months for them to get IT to implement. But building most production-worthy software is not what "learning to code" is about. I guess I'm just trying to re-draw the line. Wouldn't want to stop anyone coding :-)</comment></comment></comment>


Django swappable auth.User models landed in trunk - <AUTHOR> https://github.com/django/django/commit/70a0de37d132e5f1514fb939875f69649f103124 <comment><USER2> The documentation for the feature is near the bottom of the commit.

This is a really great addition. Every non-trivial Django project I've ever worked on has required extending the user model using both the bolted-on AUTH_USER_PROFILE pattern and hacked together middleware in order to support email-based logins.

While there's a bit of possible backwards-incompatibility with my hacks, it looks like this change addresses both pain points.

<comment><USER3> It looks like the good stuff is from here: [https://github.com/django/django/commit/70a0de37d132e5f1514f...](https://github.com/django/django/commit/70a0de37d132e5f1514fb939875f69649f103124/#diff-49).

It's been weird to get into Django and see hacky solutions like the UserProfile/get_profile() stuff (and django-registration and South being required for most purposes), and it's great to see this make it into Django.</comment></comment>


Engineers Don't Solve Problems (2018) - <AUTHOR> https://logicmag.io/failure/engineers-dont-solve-problems/ <comment><USER3> This article is making a lot of unattributed claims on behalf "Silicon Valley entrepreneurs":

"the promise of technological fixes peddled by Silicon Valley entrepreneurs that seem to allow us to continue with business as usual."

"But if we are to listen to Silicon Valley entrepreneurs and their allies in government and academia, we should not worry about changing our collective way of living on the planet: climate change is simply a problem that can be solved with "disruptive" new engineering innovations, from carbon capture and storage to electric cars."

The only direct quote is from an unnamed Tesla executive answering an unspecified question: "those are questions for philosophers—next question." For all we know, he might have been asked why bad things happen to good people.

Attacking whole groups of people for unspecified and unattributed proposals is a truly obnoxious rhetorical tactic. You can blame anything on anyone this way.

Edit: I want to clarify that I think the thesis of the article, that engineering is used both to enact and obscure political outcomes, is true and important. The engineering problems described are a fine example of this dynamic, and I wish the author had stopped there, rather undermining this important argument in such an easily avoidable way.

<comment><USER4> I think you are being a little uncharitable towards the author here. He was just pointing to the "Silicon Valley" crowd as an example of the highly visible/vocal proponents of "Technology will solve Everything" dogma without necessary foresight. The caveat is that Technology may solve your immediate problem but also create far more severe ones in the process. And he is right. The whole of Human Civilization is rife with such examples. At this stage in our "progress" we are sufficiently knowledgeable enough that we should always focus on long-term whole systems-view of everything.

<comment><USER3> I think you're missing my point.

If we wish to be taken seriously when attributing claims or beliefs to people, we need to substantiate those with evidence like a cited quote, not just hearsay. The author is PHD candidate so they should understand why it is important to cite sources.

</comment></comment></comment><comment><USER4> This is an excellent article. I think it is a good example of lack of whole "systems thinking" and a failure to really understand the scale of the problem. The main issue it seems to me is that the problem was evaluated and solved only in one given context without thinking through long-term future ramifications. I am almost willing to bet that this was due to the Suits/Politicians wanting to get something done rather than allowing time for the Engineers to fully evaluate the problem and come up with a robust solution. The oft repeated trope "any action is better than inaction" is not applicable under all circumstances. The complexity, scale and risk analysis of the problem should dictate whether one needs to spend more or less time evaluating it. It seems in this case nobody got those parameters right.

<comment><USER5> the takeaway from the article to me was, despite whatever tech implementation they chose - be it better drainage, rainwater capture, recycling, etc. - <USER2> wouldn't solve the issue that Mexico City is just growing way too fast for its own good.

it's not blaming engineers so much as recognizing that all this tech doesn't address the fundamental "problem" and may actually make it more difficult to solve or worse: he alludes to such with the lithium/electric car issue. imagine the engineers built an even better system the first time - it'd probably allow even more growth, worsening the unsolved problem.

<comment><USER6> This is how I read the article as well. Which makes the title a misnomer in one sense but correct in another, which I think was the intent. Technology is great and no doubt makes our lives better, but it isn't a cure all.

I frequently say that we've solved (almost) all first and second degree problems (problems which are cause->effect our cause->effect->effect). A big problem that were facing today is we have high order problems and we're treating them like first degree (the call is always clear "it's easy, you just..."). We've clearly advanced to a stage, at least in the first world, were we have extremely complex issues that are interconnected with many others. Luckily we're also at a stage (in all worlds) where we can recognize this, but we need to act on it. I often see complex issues (name literally any popular topic discussed in political climate: climate, guns, civil rights, reputations, etc) addressed as simple to solve issues. While all of them are solvable, over simplifying actually distracts from the problem. And I think the author of this article would agree with me, they often make things worse in the long run. With these great advancements we've made we not only should, but have a duty, to think better about the future and complexity of the issues at hand.

A good engineer can solve a problem. A great engineer recognizes the usefulness of a thousand page reference manual on orings and uses that reference.

</comment></comment></comment><comment><USER7> I 100% agree with this article, but I suspect it will not be well received here. HN is so focused on innovation at all costs that anything that goes against that will be rejected.

I think that one of the issues with doing as the author suggests and thinking of technology as a transformation is that it can be hard to come up with the downsides of your new tech. Engineers will constantly be encouraged by management and customers to deliver a solution, and often saying 'this is my solution, but it comes with caveats' will be frowned upon. Additionally, it's clear in retrospect that the expansion of the city the grand canal allowed would lead to depletion of the ground water which would lead to sinking of the city and the canal being inneffective, but was that known at the time? Could engineers working on a canal project have anticipated socioeconomic trends like this? I'm not saying they couldn't have, just that it's difficult.

<comment><USER8> > [...] was that known at the time? Could engineers working on a canal project > have anticipated socioeconomic trends like this?

Mexico City has grown from 4 million in 1951 (the time of flood mentioned in the first paragraph) to over 20 million today. Few civil engineering projects solve problems 70 years in the future for a city five times as large. As far as I can tell from the article, the engineers _did_ anticipate population growth and designed a system that would last for decades; furthermore, they monitored the system, were aware of stresses and possible failure points, and took several appropriate corrective actions as the decades went on. All of this is just from reading the article.

If at my job I criticized a design by saying, "this design is terrible because if it is wildly successful and gives us 5X growth, then 70 years from now it might require some rework" I would be laughed at. If I followed it up by suggesting that this reflected some sort of fundamental problem with the methods of engineering I would probably not be taken seriously. Engineers are not godlike miracle workers, setting in motion an ineffable plan that somehow make the world holistically better over an indefinite time frame. It's OK to just solve the tractable problems in front of us and to get a good couple of decades out of a system.

<comment><USER9> >It's OK to just solve the tractable problems in front of us and to get a good couple of decades out of a system.

Is it? Is it _really_? The point the article is making is that by designing a system which solves the problems in front of them to get a good many decades out of a system, those engineers have actually made other problems worse. I think you're being overly simplistic when you suggest that the problem the article is proposing is that the system requires some rework.

The problem the article is proposing is that _fundamental, irreperable damage has been done_. We can't un-do that damage. Short term thinking like what you're proposing is, by the vast majority of evidence and evidenced theories, destroying our world and risking the survival of our species. It is not okay to just solve the problems in front of us now if the cost is that all our children die in chaos and poverty--and it looks like the cost is just that.

<comment><USER10> The engineering is fine.

You simply need to remove 15 million people to _somewhere else_.

So what is your solution to _that_?

(The lesson from Katrina is simply that there _IS_ no solution--you have to let things build until a catastrophic event finally _forces_ people out of the area.)

</comment></comment></comment></comment><comment><USER11> This seems like a misleading title. The article itself is pretty great and I would encourage folks to read it.

The engineers did solve one problem, that of the flooding in the metropolitan city center and they did it pretty well. The transformation the author mentions is the side effect caused by hauling all that water away instead of letting it sink into the ground and replenish the water table. That's another problem, and now the engineers can solve that too.

Damming rivers across the US kickstarted the US economy after the Great Depression but also lead to unintended consequences (depleted water supply downstream, silt buildup near dams etc.). It is the nature of engineering to solve one problem at a time; only an Oracle could forsee all possible consequences of engineering works.

</comment><comment><USER12> Engineers solve problems. Doesn't mean all problems are defined properly. That's why part of the hype around design thinking is about _solving the right problem_ before _solving the problem right_.

<comment><USER13> Working with limited information means making decisions that might turn out to be bad ones down the line. I agree with your statement, but the opportunity cost of figuring out the exact right problem to solve is inaction, and inaction is often worse than making a poorly-informed judgement.

<comment><USER12> Definitely a legitimate consideration. There's always a balance between exploring and exploiting, with an equilibrium point somewhere. My experience is biased by many situations where exploration was unduly limited.

<comment><USER11> > exploration was unduly limited.

Or was just not done in good faith. Which is why having a culture of openness and honesty and acceptance of failure (to an extent) is important to building an effective engineering culture.

</comment></comment></comment></comment><comment><USER14> > The challenge we face as a society is to build the structures of popular > power to decide collectively which burdens are worth their weight, and how > to distribute them justly. These are not choices we should leave to > politicians, or even engineers.

I understand the allure of creating a system that allows the "popular power" to make decisions, but that in itself is a difficult problem to solve.

We couldn't possibly crowd-source how to solve this flooding problem until the majority of that crowd has been educated on several aspects of the issue. Perhaps what the author is implying is that there needs to be a better interface between Politicians/Engineers and the people such that the P/Es say "hey here's our plan, find the flaws" and the people say "here are the flaws"

But there's the difficult problem. There will always be flaws and trade-offs, and this kind of interface eats up large amounts of time that may be better spent implementing a short-term solution to buy a few more years until a long- term solution is reached. It's a catch 22.

The decisions must eventually come down to the P/Es, but maybe we just need to add a few more feedback points into the decision-making system.

<comment><USER15> I took this quote to mean the following: Engineers are well equipped and positioned to understand the set of solutions that are available to them and the material negative impacts of those solutions (e.g if we build a dam at spot x, the region y might have an increase in floods). But engineers should not be given the ability to make decisions about which of set of negative impacts a society should bear, and that should instead be a decision made collectively.

So the interface between the engineers and the people is not to find solutions together, or to find flaws together, but for engineers to find solutions and flaws, and the people to pick the one that they are happiest with.

(I'm not certain my understanding of the quote is right, just sharing my interpretation / an alternative to the ones you shared)

<comment><USER4> You have hit the nail right on the head!

The costs(in various dimensions) of an Engineering decision in projects of this magnitude is borne by the whole population itself. Therefore the populace must have a seat at the decision-making table to choose amongst alternatives.

</comment></comment></comment><comment><USER16> Sounds like a city planning problem rather than an engineering problem. Engineers design solutions to specifications, budgets and constraints. The latter two often dominate the shape and form of the final solution. That the poor areas flood first doesn't sound like an accident. I am reasonably confident that the original designers presented all of the caveats in their solution, and the elites were happy with the trade-offs and signed off accordingly.

</comment><comment><USER17> The engineers that build the new drainage system in 1975 did indeed solve the problem. The new problems are a result of bad city planning.

<comment><USER18> That is the point of the article though. But they did not really solve the issue, it just highlighted a new issue. Engineers solved the flooding of the city but brought to light the fact that groundwater pumping is causing the city to sink. So they solved the short term issue but the root problem is still getting worse.

</comment></comment><comment><USER19> I learned early in my career that in engineering things are really only ever varying degrees of brokenness.

<comment><USER20> If you're not familiar with Richard I. Cook's "How Complex Systems Fail", you're in for a treat.

[http://web.mit.edu/2.75/resources/random/How%20Complex%20Sys...](http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf)

(And if you are, you're in for a re-treat.)

 _General Systemantics_ addresses similar points:

[https://en.wikipedia.org/wiki/Systemantics](https://en.wikipedia.org/wiki/Systemantics)

</comment></comment><comment><USER21> I would agree with this article, as an electrical engineering student.

All solutions to problems have design constraints, and all solutions are limited. All actions have consequences.

The "move fast and break things" mentality is asking for trouble, certainly. Even acting as prudently as possible, serious issues will arise.

</comment><comment><USER22> "[I]n engineering, the "success" of a technology often has less to do with solving problems than rendering them opaque or distant from our imagination. Like an endless game of whack-a-mole, the problems never truly go away—they come back with a vengeance decades later and miles away in new forms, often made worse by the very infrastructure engineers created."

This article reminded me of Kim Stanley Robinson's novel "Aurora", about a generation ship's various engineering issues and how the inhabitants find various ways to rebalance the closed system, but never completely.

</comment><comment><USER23> Pragmatically, I believe engineers indeed "solve" problems. However, the author is getting philosophical here, and argues the solutions themselves would create its unique, unforeseeable problem in the future. Thus engineers don't "solve" problems but "transform" problems.

It makes perfect sense to me, but is it correct to blame engineering?

Philosophically speaking, my pet theory is that the _entire history of human civilization_ is an eternal process of solving existing problem by creating new forms of societies, thus creating their own problems, ad infinitum. It began since the use of fire, the invention of language and systematic agriculture, and moving towards more complex forms, simply because it has to be. I think some radical philosophers have not only argued that the industrial revolution was a mistake, but that the civilization itself can be seen as a type of technology, and it was a mistake.

Although some thinkers believe we should somehow degrowth and freeze the civilization for the best interests of human happiness, I don't think it's really coming. The human civilization on Earth is a very centralized system today. It may be possible in a future space age where human civilization spreads across the galaxy when centralization would be no longer possible and enable some regions to choose a primitive approach to civilization, or in a future digital age when computational resource is practically post-scarcity that enables minds and civilizations to exist independently in cyberspaces (even then, engineers have to work tirelessly to increase the computational power of the system before it collapses, although the laws of physics have set an extremely high upper limit for reversible computation, unlike many types of physical resources, so I don't think it would be a problem in many centuries if improvements is continued).

But before that, the ride will go on. If we are lucky enough not to accidentally destroy ourselves from a massive environmental incident or a world war, and we can keep engineering new solutions before the current system collapses, the ride towards, at least solar system domination, seems certain.

So I don't really think creating new problems to solve is an engineering problem and one should blame engineering for not solving problems.

<comment><USER4> Nicely said!

I don't think the author is blaming Engineering/Engineers so much as cautioning them against short-term thinking when the consequences of getting it wrong can be so catastrophic.

</comment></comment><comment><USER24> City gets built on a lake bed. Engineers are called in to fix the obvious problems that result. Engineers are then blamed for not solving the problems.

</comment><comment><USER25> I'd like to share a related theory I've been thinking about lately, which applies some of the ideas latent in this article to software engineering.

1\. Code is a liability.

2\. Therefore, adding new code to your codebase is adding liability to your codebase, at the margins.

3\. Refining/documenting code at the leaves transforms some of those leaves liabilities into assets.

4\. Refining/documenting code in the branch/trunk transforms some of that branch's liability into an asset, but usually undoes any progress made in the leaves.

5\. We are paid to (a) create liabilities and (b) transform liabilities into assets. If you do too much of (a) and not enough of (b), you are a bad engineer.

The fun thing is that you can analyze a software program like this (module A is a leaf to module B). You can also analyze the whole stack like this (Redux is a leaf to React, is a leaf to JS, is a leaf to Chromium, is a leaf to Intel, is a leaf to the Van Neumann model).

This ties into the article, because engineers don't "just" solve problems (unless you're Van Neumann?). Usually, we first create a problem (which is usually the dual of problem we are nominally paid to solve), and then we very slowly and iteratively "solve" that newly-created problem over time.

It sounds somewhat Sisyphean, but that's life/evolution! It's a joy to see things slowly crystallize into highly-functional, specialized components. Even if those components will inevitably become obsolete one day, they will still make for interesting fossils (see Zork's source code, dinosaurs, etc.).

<comment><USER26> Hmm, but how do you establish whether a piece of code is a liability? Do you account for QA finding no issues, or do you weigh it against the number of years its been used in production, or do you consider that it was written by expert rather than a novice, do you take into account the fact that it was purposefully designed, as opposed to organically etc. I think your theory is nice, but a bit too reductionist to be applicable in the real world..

<comment><USER25> I agree that my theory is reductionist, but on the flip side, that also keeps it simple and interesting to talk about, like we are now :)

I start with the very debatable axiom that all new code begins its life as liability. I've argued this in the past by deduction:

You type a single character into your editor, and (depending on the change, and your language's execution story), you've probably broken your code. Type a few more characters, and it is now less of a liability, because it compiles. A few words more, and it is less of a liability, because it accomplishes some small task (imperfectly). By the time you have committed some set of changes into version control, you've hopefully ironed out the liabilities. But, it's entirely possible that you've created more liabilities than assets. Code review hopefully refines it further, but things still sneak through. I could keep going, but I think this is clear?

Measuring the liability:asset ratio for a given piece of code is a challenge, and is more qualitative than quantitative. I believe that this is also an argument in favor of "new code is a liability", otherwise code review should catch all of our mistakes.

But yeah, I have found it to be useful "in the real world" as a heuristic for thinking about how code bases evolve over time. I do not think that it translates into a hard-and-fast rule to weaponize in code reviews. However, it does temper your expectations about the fallibility of code, and it is also a convincing argument for code review as a quality-control process.

<comment><USER26> Sure, but there are several arguments for doing code reviews/QA/etc that are already convincing. Its interesting.. but I guess I don't see how we can use this new way of looking at code transformations to our benefit.

<comment><USER27> The thing is even if QA and testing is fine now as the business or domain needs evolve over the years just the fact the context has changed can lead that code to be a liability. I'm kind of tired from work so I hope I can make my point: As an example, let's say you have a billing system that allows anonymous payment that works fine it has thus far been an asset, but new legislation is released that states that all purchases must have legal identity associated. Orwellian thought aside, some or all of that code has transformed into a liability depending on how deeply ingrained anonymous payment is and whether or no you can extend the existing code or you have to rip it out. Your code can be perfectly functional but a change to the domain need rendered it a liability.

<comment><USER25> Interesting. I like this a lot.

All Code implements a process. If the requirements for that process change (due to shifting regulation, for example), the process is a liability until it adapts to those requirements, at which point it can again become an asset.

If a process has no artifacts for implementing it, it can't be a liability.

That's why we see so many companies offering regulatory compliance as a service, in the healthcare space for example (AHIP, NIPR). Because if every insurer had to write code that integrated with regulation, they would be writing a lot liability. Using a vendor allows them to offset that liability to a third party, whose whole purpose in existence is to maintain a nice liability:asset ratio.

Perhaps we've found a utility for my theory, in contributing to the build vs buy discussion :)

</comment></comment></comment></comment></comment></comment><comment><USER28> I've been to Mexico DF once. I visited downtown and there was a literal mountain of garbage in the central plaza (easily two stories high). Maybe Mexico City engineers are shit (pun intended), at least article implies it as it's the only example they give.

<comment><USER4> You are being flippant. The Mexico City problem is the author's research study (do a little bit of googling on the author) and therefore it is the example he knows best. The article also does not denigrate Mexican Engineers; you are reading it through your own unwarranted biases.

And finally, just so you know this is a problem with all major urban centers throughout the world. Here is a scary report on India - [https://edition.cnn.com/2019/06/27/india/india-water- crisis-...](https://edition.cnn.com/2019/06/27/india/india-water-crisis-intl- hnk/index.html) This is a thorny problem for Govts, Politicians, Urban planners and Engineers which if not properly evaluated will have catastrophic consequences. That is why when people do research on this and point out problems and possible solutions, you listen carefully with gravitas.

<comment><USER28> To be clear, I was only talking about this particular problem, and engineers who might deal with it, not engineers in general. That was my experience when I visited, and apparently at the time the problem was not being dealt with properly. India is probably not a good example of how this happens in a lot of cities either, but I'll grant that Mexico DF has location problems from being on top of a lake etc.

</comment></comment></comment><comment><USER29> It seems like author is studying water crisis in Mexico City. Based on problems here - author states that no problems are solved - just transformed. Though one should think that bridges, tunnels, trains etc. was solving problems.

</comment><comment><USER30> Btr</comment>


Four Cups of Coffee Could Help Repair Your Heart, Study Finds - <AUTHOR> https://www.inverse.com/article/46253-coffee-heart-health-caffeine <comment> crooked-v I'm sure next week will somebody will publish the discovery that actually no one should be drinking coffee.</comment>


Why young men go to war - <AUTHOR> https://medium.com/war-is-boring/sebastian-junger-knows-why-young-men-go-to-war-f163804cbf6

<comment><USER2> I really enjoyed this article. imho The _quest /test for manhood_ theme is one of the most dominant in our media, yet it is also kind of a spoken taboo. _Breaking Bad_ and _Fight Club_ come to mind, where "castrated" protagonists fight back for their manhood... _The Big Lebowski_ is, among many themes, about how different people prove their masculinity in different ways too. The whole _damsel in distress_ genre... I've been writing an article about this topic, hopefully it will come out soon. Also, movie/tv male comic relief is often portrayed as asexual or incredibly dorky.

This is also incredibly timely, as I've spent the last weeks thinking about how joining the military would be like.</comment>


Ask HN: What are some good resources to learn network/app security on my own? - <AUTHOR> <comment><USER2> Penetration Testing: A Hands-On Introduction to Hacking [https://www.amazon.com/Penetration-Testing-Hands- Introductio...](https://www.amazon.com/Penetration-Testing-Hands-Introduction- Hacking/dp/1593275641)

Offensive Computer Security Spring 2014 Homepage Florida State University [http://www.cs.fsu.edu/~redwood/OffensiveComputerSecurity](http://www.cs.fsu.edu/~redwood/OffensiveComputerSecurity)

Offensive Security Certified Professional [https://www.offensive- security.com/information-security-cert...](https://www.offensive- security.com/information-security-certifications/oscp-offensive-security- certified-professional)

The Hacker Playbook 3: Practical Guide To Penetration Testing [https://www.amazon.com/Hacker-Playbook-Practical- Penetration...](https://www.amazon.com/Hacker-Playbook-Practical-Penetration- Testing/dp/1980901759)

MIT Course Number 6.858 :Computer Systems Security [https://ocw.mit.edu/courses/electrical-engineering-and- compu...](https://ocw.mit.edu/courses/electrical-engineering-and-computer- science/6-858-computer-systems-security-fall-2014)

More at [http://Learn.SharjeelSayed.com](http://Learn.SharjeelSayed.com)

</comment><comment><USER3>
        Reversing: Secrets of Reverse Engineering de Eldad Eilam
        Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation de Bruce Dang, Alexandre Gazet, Elias Bachaalany, Sébastien Josse
        Cryptography Engineering de Niels Ferguson, Bruce Schneier, Tadayoshi Kohno
        Applied Cryptography: Protocols, Algorithms and Source Code in C de Bruce Schneier

</comment><comment><USER4> I enjoyed this series of course and you can browse for free and see everything, you just won't get the certificate [https://www.edx.org/micromasters/ritx- cybersecurity](https://www.edx.org/micromasters/ritx-cybersecurity)

There is also this, but I haven't viewed it yet [https://www.edx.org/course/introduction-to- cybersecurity](https://www.edx.org/course/introduction-to-cybersecurity)

</comment><comment><USER5> [https://www.hacker101.com/](https://www.hacker101.com/)

</comment><comment><USER6> Few years back I went through free version of [https://www.coursera.org/learn/software- security](https://www.coursera.org/learn/software-security) and found it interesting and well organized.

</comment><comment><USER7> I've found the classic article "Smashing The Stack For Fun And Profit" to be an excellent introduction to the mindset, culture, and level of technical detail needed to be effective in security.

</comment><comment><USER8> Pick an iOS or Android app and MITM it. Then try to hook into methods and log their arguments. It's a good start and the problems you encounter will ensure you learn a lot along the way.

</comment><comment><USER9> OSCP, hacker playbook 2/3, and download kali.

</comment><comment> video-host Pentesterlab.com</comment>


Consider your naming schemes - a cautionary tale - <AUTHOR>

Recently we had a contract for a large company that required the code be put in escrow.  This isn't unusual, we're in an industry where if you have fewer than 10,000 employees you're regarded as small and a risky proposition.  We have succeeded despite that perception because we're very good at what we do.
So an agent for the appointed escrow company comes in to vet the software, check that we can do a full and complete build from the source provided, and then are about to take away the copy to put in safe storage.  It'll never be seen again unless we fail to meet our (fairly reasonable) obligations.
Then the agent doing the vetting asks for a break. He goes away and makes a phone call.  Then another.  Then another.  Finally he comes back and says that he has a legal responsibility to report us to the authorities.
Why?
We use a package called "upskirt" - https://github.com/tanoku/upskirt - and he has concerns not because it's open source, but because of the potential pornographic implications.
It takes a while, but we manage to explain several things:
* One - it's not actually part of the system we provide to the customer, it's just used in our internal documentation system
* Two - it's not what it seems.  Programmers (we've learned never to use the word "hackers") have an odd sense of humor.
* Three - under the legal agreement we have they are welcome to check our systems for "inappropriate" material.
* Four - it's not actually their responsibility, and they are over-stepping their bounds
* Five - but it doesn't matter, because it's not what they might have thought, and it's all OK.
Even so, I can just see federal agents coming in to seize material on the basis of something like this, and then we're screwed.  30 people out of work.
We've now purged our systems.  We've traced every filename, grep'ed every file, and generally undertaken the mammoth task of removing anything that someone not steeped in hacker culture might find questionable.
So by all means, continue to use clever and risqué names for your projects.  Just don't expect me to use them.
<comment>==
The above is not a true story, although most of the elements are true. We do put code in escrow, we have had to explain "questionable" names, and we have had to convince someone not to call the authorities.  I've put the components together into a single story for effect.
The result is real.  We won't, for example, use "upskirt" at work.
(edited to correct a typo - there are probably more) </comment><comment><USER2> I think it's entirely reasonable to expect "professional" developers (including those who share their code online) to use names which make them easy to find using a search engine. The name "upskirt" fails this test because a search for that term will return a lot of results which are not only unrelated but also NSFW.

</comment><comment><USER3> It occurs to me that Upskirt is released under an MIT License, and is hosted on Github. So it would take approximately one click to create a fork and rename it to something else. The names of the files under the src/ directory are things like "markdown.c" and "buffer.c", nothing pornographic there.

I agree that when creating an open source solution, you should name it something work-appropriate. On the other hand, picking a name that's unique tends to get it to stick in developer's minds (who read about lots of open source solutions on a daily basis).

I guess I'm just saying: it sounds like you spent a lot of work on a "mammoth" task that could have easily been handled a different way.

</comment><comment><USER4> _We're now purged our systems. We've traced every filename, grepped every file, and generally undertaken the mammoth task of removing anything that someone not steeped in hacker culture might find questionable_

If I was a federal agent, that'd be the reason why I'd get suspicious. Why are you destroying evidence that you did _not_ violate any laws?

As for avoiding upskirt (at least the name), you're in good company. The geek feminist community also hates the name (which I can understand of course).

</comment><comment><USER5> It's really unfortunate. Even working with small clients (for example, one guy testing the entrepreneurial waters), I'm just not going to tell them "Hey - I'm going to use upskirt." It makes _me_ look unprofessional. And yes, people do ask what I'm using.</comment>


Show HN: Ahoy – Twitter for Your Neighbourhood - serious-sam https://itsahoy.com/ <comment><AUTHOR> Add a geo input, not giving location access to any apps these days. Far too much abuse by the general app market to let anything have access at this point

<comment><USER2> That would defeat the purpose of the whole hyperlocal apps.

</comment></comment><comment><AUTHOR> How will you prevent the YikYak outcome (devolving into horrible, anonymous comments)

<comment><USER2> I don't think we can prevent horrible anonymous comments. Thats the truth.

Even Twitter & Facebook are fighting this even though they are not anonymous apps.

</comment></comment><comment><USER3> Amazing Idea!

Love it, but how can i increase my radius?

<comment> serious-sam You can click on the radius (number) in top text. It is an editable field.</comment></comment>


Show HN: Wordpress "Pharma Hack" Analysis - <AUTHOR> https://bitbucket.org/arianb/pharmahack/src

<comment><USER2> From decoded.php, for context:

        /**
         * ===WORDPRESS PHARMA HACK ANALYSIS</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=
         * </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>====
         *
         * Patrick Adair [ patrick AT ionpublications DOT com ]
         *
         * For the uninitiated, there's been a rather-nasty hack making its way across
         * a number of prominent websites hosted with Wordpress called the "pharma
         * hack"; named so because it hijacks your search results in Google, et al. to
         * show obviously-spoofed results for Viagra and other generic medications
         * that we see spammed all the time across the internet.
         *
         * As you, the reader, can rightly imagine, Wordpress blog owners were scared
         * out of their minds and worked quickly to remove the hacks from their sites,
         * finding the necessary codes sometimes hidden deep inside of their plugins
         * and striking only when search engines and automated crawlers of any kind
         * hit the site.
         *
         * On the 24th of November, 2010, we noticed that one of our sites, Science
         * and Supermodels [ http://www.scienceandsupermodels.com ] was hit by the
         * hack, and after a few times of playing cat-and-mouse with it (delete the
         * injected code only to have it re-appear in the same place 30 minutes later),
         * we were able to remove it entirely and all was well.
         *
         * But I had an interesting idea. To my knowledge, at the time of this writing,
         * all of the accumulated knowledge on this hack was simply removal techniques
         * for non-technical users (which, admittedly, is most of Wordpress' userbase
         * so far as I can tell - the consequences of making it so gorramn easy to
         * install). I decided that it would make an interesting project to break apart
         * and analyze the injected code to try and figure out what it was doing, and
         * see if any good can come of that.
         *
         * Fast forward to 24 hours ago (December 20, 2010), and I've finally cleared
         * up enough time to start meaningfully decoding and rewriting this script, and
         * I hope that something useful will come of this - perhaps a security company
         * can pick up on the groundwork I've laid here and figure out how to actually
         * stop the bastards doing this.
         *
         * What follows is a SIGNIFICANTLY re-written version of the script, edited for
         * clarity and also to test my programming chops - the original was compressed,
         * encoded in base64, and even then written in an absolutely incomprehensible
         * fashion.
         *
         * I've tried to include as much information as I can - since the control
         * servers are still active for this hack (at least at the time of this
         * writing), I was able to get pretty accurate debugging and data on what its
         * delivery method was, and those will all be included in my Mercurial repo
         * along with this file.
         *
         * Also, this is based off of only the version of the hack that our site got -
         * it remains entirely possible that other mutations of the hack exist and I
         * would be curious to see what they look like / do. If you have other samples
         * of the code, please email them to me and I would love to see.
         *
         * So without further ado, I present the Wordpress Pharma Hack:
         *
         */</comment>


Searching a 128B–node graph with BFS on a laptop - <AUTHOR> https://github.com/frankmcsherry/blog/blob/master/posts/2015-08-20.md

<comment><USER2> Done using sorting and stream processing, without loading all the 128B nodes simultaneously, of course.

The beginning of the story: [https://news.ycombinator.com/item?id=10085121](https://news.ycombinator.com/item?id=10085121)</comment>


Some performance tweaks - <AUTHOR> https://github.com/bitly/dablooms/pull/19 <comment><USER2> This is a fun example of the power of open source. Bitly releases software they use internally but which isn't secret sauce. Github comes along, uses it internally, improves the original software, and ends up benefiting both. Contributing to OSS is a non-zero-sum game and the sooner companies realise this, the better.

Not only that but the pull request is done in a fun and informal style -- a perfect example of Github's use by a Github employee =] He frankly admits that some of the changes are substantial and weren't requested or set out before hand, so there's no pressure for them to be merged into mainline if not appropriate.

It's important to note that this is an example where both sides work optimally though. I've contributed code to OSS projects backed by companies previously and it's not uncommon to end up with "dangling" pull requests -- no-one looks at it either for months or at all.

I'm still appreciative of these companies, don't get me wrong, but if it takes months for a short but critical bugfix to get through then you're not playing the OSS model properly. Either admit it's a "dump and release" or ensure your open projects are handled properly. Developers will look at you in the future and decide that's your attitude towards all your projects (see: Oracle). This ends up being a major problem when you need to win the trust of third party developers for your start-up/service/tool.

(I'm also really glad the dablooms library is getting more exposure due to this -- the initial Hacker News post fizzled out)

<comment><USER3> How could contributing to an OSS project be a zero sum game?

<comment><USER4> Imagine a simple market (if you're wincing already, I'm right there with you, but you asked for this right?). There are 100 customers, and two products. The products are interchangeable, save for the performance of their bloom filters.

This is a zero sum game from the perspective of the two companies providing the products.

<comment><USER3> Thanks for responding. I'm afraid my question was unclear. This was supposed to be an answer to how could contributing to an open source project be a zero sum game? You did not define what the open source project was and or the companies rationales fopr consoidering contributions to be zero-sum or otherwise.

<comment><USER4> If we further assume that the two companies who produce the two products only produce those products, then for those two companies it's zero sum for them to contribute in good faith to open source bloom filters. Any gain that one company gets in the quality of their bloom filter is likely to translate directly into fewer customers for the other.

It isn't globally zero-sum, notably the users of these companies' products are presumably better off, as are other software projects and their users who might benefit from any improvements made to open source bloom filters.

</comment></comment></comment></comment></comment><comment><USER5> Good grief, some of you folks take yourself way too seriously. No, his pull request wasn't groundbreaking, but it was useful. His presentation was whimsical and light-hearted. So what? Is dry and boring better because it seems more academic or professional? Bleh.

Life is too short not to have some fun in your day job and kudos to vmg for doing exactly that. For the rest of you..lighten up. Seriously.

<comment><USER6> Sometimes it feels like people always have to find a flaw to latch onto and take some meaningless stand on, no matter how irrelevant. I don't know if it's for the fleeting sense of superiority, for the sake of discussion, or (as you put it) because they take themselves too seriously. I value the importance of criticism, but not when its primary motivations are self-serving.

For what it's worth, this is a phenomenon you see in most tech communities -- it happened on slashdot, proggit, and it's present here too.

<comment><USER7> God help you if you attempt to defend the use of anything except statically typed languages on proggit.

</comment></comment></comment><comment><USER8> This is why, at a certain level, after a certain length of time, most software companies (including startups, although it could be argued you're transitioning from startup to real company at that stage) need the oft- maligned "neckbeard" type folks (vmg sports some stubble, perhaps he's a closet neckbeard? :D).

Yes, it's great to have the latest JavaScript ninja working on your front-end and whiz-bang Ruby folks on the back-end but eventually you're gonna run into problems that require RealHardComputerScience(TM) to fix. Or, you just throw more hardware at it and forget about it, and end up paying for that oversight over-and-over-and-over (it looks like it didn't take him much time to fix it)

<comment><USER9> Not to take anything away from vmg (what a great pull request!)... but "RealHardComputerScience" is _writing_ a hash function, not swapping out one hash function for another based on some profiling. ;-)

<comment><USER10> I'd argue that writing a hash function is RealHardMathematics.

<comment><USER11> It really involves both: particularly if you want high speed hashing, you need to pay close attention to how your hash function is executed by the hardware.

</comment></comment></comment></comment><comment><USER12> Could HN please, PRETTY please introduce some feature to parse well-known URLs so it could give you a little more sense of the source? This looks like it's going to be an announcement from github.com about some cool performance improvements. Not that I don't appreciate the actual article, but it was kind of a let-down.

I know this has been discussed before, but I'm honestly mystified why this is still an issue.

<comment><AUTHOR> The title was changed. It used to say: "Some performance tweaks -- 'this is the most amazing pull request ever'".

See <https://twitter.com/neha/status/233225033332445184>

</comment></comment><comment><USER13> When I initially saw this posted here, I was irritated. The tone grates with me, and yes - I would prefer a much drier, concise explanation if I were to receive such a pull request for my projects. I kept this to myself though, and had a look at the comments here, and I've had time to mull on why I think this is potentially dangerous behaviour.

The tone and humour in that post requires a large amount of confidence in the changes being made, in order to write about the humorously, but also in the author themselves to actually present their work in such a tone. vmg is perfectly entitled to do both of these; the pull request is detailed, shows clear motivation and research, and vmg seems to know his stuff. The problem is that GitHub encourages networking. The damage comes when other people who are less experienced, or frankly, less knowledgeable, copy his style and do produce noise.

I worry about a risk of imitation of this culture, but missing the crucial underlying detail and explanation that's hidden in vmg's writing. I worry reasoning with this people will be difficult because they have trained themselves to have such arrogance in their work.

I prefer a dry report not only because it is succinct, not only because it makes my life easier to understand, but also because it encourages a disciplined state of mind. If you aren't able to write about something in a mature dry tone and back it up (that is, not cover up with humour), then you should doubt your work until you can amply support it. Yes, life is short, but it's also so short that I would like to get things done; rather than have to potentially argue past people to get important points across. Lets put this creativity into making great stuff, not making great pull request comments, eh?

Finally, all of this stuff builds a record for the project. A succinct, yet detailed, pull request is much more accessible a year down the line to understand the changes in more detail. Of course, this detail should be in the commit messages (and I _do_ criticise vmg on poor commit messages here), but every bit of writing contributes towards project documentation, at some level. The more we can create a habit to create mature, if somewhat monotonous, technical writing, I do think the better.

So no, it's not just a "I HATE HIS FUN" argument; there are more reaching concerns, no matter how exaggerated you might think they are.

</comment><comment><USER14> Great engineering, but a little bit brogrammer in the presentation.

<comment><USER15> As long as the claims he is making are true, I wouldn't consider it brogrammery at all (just a bit fun/Internetty).

It's when unsubstantiated claims are being taken as gospel does brogramming get in the way. HEROKU AND ORM ALL THE THINGS~!!!! WHAAAAAT

</comment></comment><comment><USER16> One thing on my "bucket list" is to "use a bloom filter for something". They seem like such awesome data structures but I've never found a place to use one :-(

<comment><USER17> Next time you are caching a bit list with memcached and running out of space, you may replace that big list with a bloom filter.

<comment><USER16> Could you explain that a bit more?

<comment><USER18> This is exactly the scenario that a bloom filter is for.

You have an expensive lookup. You're caching information on success/fail so that you don't have to do the expensive lookup every time. But the caches are getting large.

What you do is replace the local caches with a bloomfilter. That data structure takes a bounded amount of memory. When it says, "No, I have not seen you before," you really haven't. And when it says, "I might recognize you," it is only sometimes right. However its mistakes will not really matter because you'll do the expensive lookup.

The tradeoff is that the more data you put into a bloom filter, the higher the odds are that it will think think you might have seen things before, and therefore the less useful it becomes. But in this caching situation, it saves you work even if the false positive rate is fairly high.

</comment></comment></comment></comment><comment><USER19> What a obnoxious write-up for a pretty straightforward optimization. I don't really see how this is worthy of any discussion, unless we want to discuss how some developers think they're a lot more clever than they really are.

"Developer profiles code; replaces slow library call A with faster library call B; ensures B does not change any important behaviour; writes self- congratulatory pull request."

<comment><USER20> Yeah, god forbid any of us actually have fun while working. _GASP_

</comment></comment><comment><USER21> "Hey, I just met you, and this is crazy, but I rewrote your bloom hashes, so merge me, maybe?"

</comment><comment><USER22> I find the style that this is written in to be annoying, distracting, and a little arrogant. It's not funny at all.

Just write the facts and let them stand for themselves.

<comment><USER23> All the facts are there. He presented them entirely clearly.

<comment><USER24> Agreed. It's clear, it kept me interested and I made sure I read it thoroughly instead of just skimming

</comment></comment></comment><comment><USER25> Cool speed hacks.

An an improvement though, you only need two independent hash functions to run your bloom filter[1]. Strangely enough, this isn't well known and as such isn't implemented anywhere near as often as it should be (ie. it's not implemented here).

[1] www.eecs.harvard.edu/~kirsch/pubs/bbbf/rsa.pdf

<comment><USER26> I was just talking with a colleague the other day about how to simplify the number of hash functions needed for a bloom filter. He recommended something similar to what the paper describes, but we both dismissed it as "probably won't work". Just goes to show you that sometimes the simple solution is worth closer examination. Thanks for the paper!

</comment></comment><comment><USER27> "MD5, being cryptographically sound"

Uh, not for a while now...

Which is not to say that the general point isn't sound - MD5 was aimed at generating high quality entropy while most non-crypto hashes are aimed at generating entropy-enough _fast_ \- but don't use MD5 for crypto stuff anymore.

<comment><USER28> That has nothing to do with the context of the conversation.

The point is that it was _designed_ to be cryptographically sound -- and therefore more heavily optimised towards entropy over performance -- whereas the need here is for the hypothetical entropy/performance slider.

</comment></comment><comment><USER29> This pull request has a LOT of attitude for something that just swaps out a hash algorithm and uses ftruncate(2).

</comment><comment> brown9-2 The quote in the title here doesn't appear in the actual pull request - am I missing a reference somewhere?

<comment><AUTHOR> It's how it's being passed around in Twitterland (<https://twitter.com/neha/status/233225033332445184>).

<comment><USER30> thanks for the attribution!

</comment></comment></comment><comment><USER31> I feel so stupid now you have no idea, shame on you, I now started reading about MurmurHash instead of working. And I write software for 12 years and have a CS degree.

<comment><USER32> The manual doesn't say you have to know any hashing algorithms. I think that _should_ be the desired behavior - if your hashes work, you shouldn't need to know their internals as long as a reputable specailized verifier and some form of peer review can authenticate their worth. You have more _important_ stuff to be doing!

... I also read up on Murmur though, since I know SHA and MD5 already. ~3 months out CS grad myself.

</comment></comment><comment><USER33> Impressive, considering this could have been an even better pull request without all the "like, white guy speak, yo".

</comment><comment><USER34> vmg clearly has a career in standup if this coding thing doesn't work out.

<comment><USER35> because he made some tired meme jokes?

</comment></comment><comment><USER36> Nice optimisation, but who thought it would be a good idea to use MD5 in a Bloom filter?!

MD5 is a cryptographic hash (even though it's not secure anymore for most purposes) and while it's _pretty_ fast, you don't need any of its crypto properties, just the properties of a good quality regular hash function. Such as Murmur, or even simply FNV.

</comment><comment><USER37> ye gods, another useful headline edited to meaningless moronicity. Seriously, mods, enough of this shit.

</comment><comment><USER38> "Glad you like the changes! Sorry it took me a while to answer, I was watching SCIENCE."

</comment><comment><USER39> Why the essay?

<comment><USER6> Because it's a clear description of the motivations behind the changes without restricting the discussion to an audience of a particular skill level. Also because, when possible, things should be fun - and he seemed to have fun with the essay, so why not?

<comment><USER39> I don't think that is a clear description by any measure. It could be summarized in a couple of paragraphs. It's perhaps good for beginner programmers to learn from, so I'd encourage him to write a blog post. Pull request motivations should be to the point, especially for small changes, because otherwise they just waste time.

<comment><USER6> Meh, to each their own I guess. While it is long, that does not in any way make it unclear. In fact, he explicitly states the motivations and repercussions of each decision. To persuade the master developers, who made the "mistakes" (for lack of a better word) in the first place, this seems like a worthwhile pursuit.

The only thing that would have made this more entertaining would be if he had submitted a similar pull request to Linus..

</comment></comment></comment></comment><comment><USER40> Cool. As we all know, ideas are worthless. It's the execution that matters.</comment>