Windows corrupting UDP datagrams - <AUTHOR> http://blog.geeky-boy.com/2015/10/windows-corrupting-udp-datagrams.html <comment><USER2> I honestly think the theory of the NIC messing up one of the offloaded tasks is a likely one, if I remember other strange errors that have happened in this context. To bad that he doesn't have access to the machine to do more thorough tests.

<comment><USER3> My money's also on a NIC checksum/segmentation offloading bug. Even though it apparently isn't controllable via the exposed parameters, the card does have these features. "TCP/UDP checksum and segmentation offload (IPv4 and IPv6)" on the spec sheet [https://www-ssl.intel.com/content/dam/doc/product- brief/8257...](https://www-ssl.intel.com/content/dam/doc/product- brief/82579-gbe-controller-brief.pdf)

</comment></comment><comment><USER4> should this not be "Windows corrupting UDP Datagrams in some (possibly lower chance) cases"? The list of circumstances for the bug to occur (from the article):

1\. UDP protocol. (Duh!) 2\. Multicast sends. (Does not happen with unicast UDP.) 3\. A process on the same machine must be joined to the same multicast group as being sent. 4\. Window's IP MTU size set to smaller than the default 1500 (I tested 1300).

5\. Sending datagrams large enough to require fragmentation by the reduced MTU, but still small enough _not_ to require fragmentation with a 1500-byte MTU.

<comment><USER3> > should this not be "Windows corrupting UDP Datagrams in some (possibly lower > chance) cases"?

I mean, I guess, but I kinda assumed as much, since if Windows was corrupting UDP at any significant frequency certainly it would have been noticed by now.

<comment><USER5> It is a fairly unusual situation, but yeah, I would expect someone else to have seen this by now.

I might have to try this myself to see if I can replicate it.

</comment></comment></comment><comment><USER6> I don't know why you set the MTU to a lower value... What I do know, is that I've set it to 65535; my machine now transmits 64KB instead of just 1.5KB (per packet)... Can you imagine what would happen if I set this to UInt32.MaxValue...?

<comment><USER7> Its generally a terrible idea to increase UDP MTU. There's no reliable reassembly in UDP. If you miss a single packet (out of say 1000) then all are simply discarded silently.

In fact, some versions of Linux didn't do UDP reassembly properly until a year ago (was a topic here on HN). Reordered UDP wasn't dealt with properly if I recall.

There are routers that drop UDP for any reason or no reason. And so on. So UDP is the red-headed stepchild of protocols, with little testing going on and lots of issues.

I recommend putting a protocol on top of _any_ UDP transfer you code, and never increasing the MTU.

<comment><USER6> Man, you know, it's just a packet, not 1.500, but 65.535 bytes. There could be 4.294.967.295 bytes!!! :-)

For basically everything TCP is used. UDP is just used by DNS and they usually weight 100 - 200 bytes.

Look into your wireshark!

<comment><USER7> The UDP packet, and what goes out on the wire, are different things. IP-over- Ethernet for instance does not send out data in units larger than 1500 bytes; often smaller over WiFi. So UDP packets larger than 1500 bytes will be divided up, and reassembled on the receive end.</comment></comment></comment></comment>


Games For Thinkers - <AUTHOR> http://www.gamesforthinkers.org/ <comment><AUTHOR> There's a discussion[0][1] going on about whether programming is math, and it got me thinking about how I so disliked math in grade school until I got into a class that taught a different kind of math.

We played assorted "math" games and it was a lot of fun. I taught me to see math in a new light.

After some Googling I found that all those games are available from the same company, hence this post.

In particular I recall playing WFF'n Proof, Tac-tickle, and The Propaganda Game.

0: [https://news.ycombinator.com/item?id=8052957](https://news.ycombinator.com/item?id=8052957) 1: [https://news.ycombinator.com/item?id=8038631](https://news.ycombinator.com/item?id=8038631)</comment>


Getting Started with Dart and React - <AUTHOR> https://www.leejamesrobinson.com/blog/getting-started-with-dart-and-react/ <comment><USER2> I'm obviously a little biased (see the name) but I believe Dart is an excellent language to work with. Personally I prefer Angular, but I enjoyed this post. Nice work.</comment>


Head of Product is More Valuable than 5 Engineers - <AUTHOR> http://www.mikekarnj.com/blog/2011/02/07/head-of-product-is-more-valuable-than-5-engineers/

<comment><USER2> Only if they're exceptional at their job.

<comment><AUTHOR> I'm assuming that companies only higher rockstars right? Why else would you add someone to your team?</comment></comment>


Is the Kickstarter bubble bursting for celebrities? - <AUTHOR> https://medium.com/i-m-h-o/c9761921192d

<comment><USER2> This is a terrible analysis that fails to understand why veronica mars was so successful.

As discussed here when the VM kickstarter succeeded, there was a very loyal fanbase to the series and there hadn't been a new show or movie in years (since 2007). There was a ton of latent demand for a product.

If I were doing this analysis, I'd try to separate established brands from new concepts. Bell's project to a great extent was driven by the brand and Braff's project leveraged Garden State. Since Spike Lee's project was entirely driven by his name, I'd look at his with a different lens

The best part of this article is the quote "Judging a trend from 3 data points isn't the wisest thing to do"

<comment><AUTHOR> That's a fair point on VM's loyal fanbase that was lingering since 2007. But Braff's project leveraged Garden State as much as Lee's Leveraged Malcolm X and others of his past films. Your argument is biting its own tail: You're saying Lee's project was entirely driven by his name, but that's because Lee made it so. He could have made a more convincing video or written a better text giving more info (just like Braff did) but he didn't. My point is that he could have been more successful if he had put in more effort.

That's the whole point: Spike Lee's past films should outweigh Braff's effort with Garden State when it comes to convincing people about their respective ability to make good films, but it didn't.

<comment><USER2> Braff pitched "Wish I Was Here" as a spiritual successor to Garden State:

> I was about to sign a typical financing deal in order to get the money to > make "Wish I Was Here," my follow up to "Garden State." It would have > involved making a lot of sacrifices I think would have ultimately hurt the > film.

[http://www.kickstarter.com/projects/1869987317/wish-i-was- he...](http://www.kickstarter.com/projects/1869987317/wish-i-was-here-1)

Spike Lee isn't pitching the latest project as a continuation of Malcolm X

<comment><AUTHOR> Maybe it's a language thing on my part, but for me "my follow up" means "my next project after", which doesn't imply any continuation when it comes to the movies' contents. (It's possible I got that wrong but at least you know where I'm coming from)

</comment></comment></comment></comment><comment><USER3> _But when Kickstarter's founders have to defend their own platform, a platform that once was nominated idea of the year by TIME, you know something must be rotten in Denmark._

The fuck kind of logic is this? When somebody defends their company, you know something must be wrong? That's some astute analysis there.

 _Judging a trend from 3 data points isn't the wisest thing to do, and this descending slope may only be coincidental._

And yet that's what you lead with, huh.

<comment><AUTHOR> When they _have to_ defend the very values and purpose of their company, I think it show something's wrong yes.

<comment><USER3> Whether they _have_ to or not is clearly conjecture. And why would anybody in their situation not be defending their company?

</comment></comment></comment><comment><USER4> "So, naturally Strickler won't pull the plug on celebrity projects, and he's going to defend their right to exist for as long as he can."

Just because it's a big direct revenue source, that doesn't mean Kickstarter can't pull the plug on something. They recently banned hardware projects that just showed simulations without an actual product built yet. They're playing the long game and don't want to hurt the trust the community has in the platform -- so they're not in it for a quick buck at any chance, and they reject a lot of projects that don't meet their somewhat strict guidelines.

That being said, where do you draw the line on 'celebrity'? At some point, if hypothetically they banned celebrity projects, who determines the level of celebrity? It's so ambiguous to the point where it doesn't make sense to address it. I think the celebrity stories are a non-issue and the press always wants "controversy" to talk about even if it's drummed up by them.

<comment><AUTHOR> These are two excellent points you're raising here. About the 1st one: My intent with the sentence wasn't just to focus on the added revenue these projects provide, but also on the increased visibility they give to Kickstarter as a whole, which very much carries a long term impact for Kickstarter (SEO benefits, better brand awareness, etc). But I see what you mean: If these projects were truly hurting Kickstarter as a platform for everyone, they probably would have figured a way to make them stop.

Which brings me to your second point. It's true that the celebrity status is extremely tough to define and even tougher to measure in order to apply fair rules for everyone. But if there's a need for it, that is: if the existence of some projects start being detrimental to others, then I trust Kickstarter will work on it, crunch some data to figure out a way to prevent that from happening while remaining fair to project creators. Maybe by blocking projects a-posteriori, as they already did in the past.

</comment></comment><comment><USER5> I see a pattern - it is the level of quirkiness. I think the more quirky a show the more likely it is to generate major fan loyalty. The show has to be good as a baseline.

Veronica Mars fans are legion, there is even a slight overlap with Joss Whedon (of Buffy, etc fame) as he had a very rare bit-part in one episode. Braff is known for somewhat quirky stuff too, Garden State was offbeat. Spike Lee is very mainstream hollywood nowadays, working with a-list actors and directing some very profitable movies.

So from the perspective that good-quality quirkiness generates fan enthusiasm it makes sense that these three particular projects would draw interest and dollars in the proportions that they did.</comment>


The story of a little DNS easter egg - <AUTHOR> http://blog.cloudflare.com/the-story-of-a-little-dns-easter-egg <comment><USER2> It reminded me of this clever hack used to store the source code of DeCSS (CSS descrambler that let you bypass the DVD DRM) in DNS records: [http://decss.zoy.org/](http://decss.zoy.org/) (method 9).

"Mark Baker noticed that you could do the request to any nameserver. Which means for instance that the DeCSS source code is available from the DVDCCA's nameservers !"

Classic.

</comment><comment><USER3> Wish they would open source it. I would have preferred if they would have contributed to PowerDNS instead of reinventing the wheel. Was PowerDNS so awful it required a compete rewrite if so fair enough.

<comment><AUTHOR> The other day CloudFlare's CEO stated the plan is to open source RRDNS: [http://blog.cloudflare.com/cloudflares-new-waf-compiling- to-...](http://blog.cloudflare.com/cloudflares-new-waf-compiling-to- lua#comment-1015638026)

"We're planning on open sourcing RRDNS, the authoritative DNS server we built, when it gets to a state where it could be used by others."

</comment></comment><comment><USER4> One of the reasons they originally chose PowerDNS was that "it seamlessly allowed us to add new records without rebooting."

Can someone explain? What DNS server requires a reboot (or even restart) instead of a simple reload?

<comment><USER5> (I also chose PowerDNS years ago.)

I'm not sure about "rebooting" \-- if this was just a language error -- but PowerDNS can run with a MySQL or Postgres backend with instant updates to records. i.e., no reload or other configuration re-read required.

With DB replication up and running, you can get a fairly robust domain name server pool going without the usual headaches associated with copying updates to multiple servers.

<comment><USER6> CF engineer here. The main pain point of pdns and CloudFlare was all the additional logic needed to support CloudFlare's cdn product. For example, for a given record, should this resolve to the origin server's IP or CloudFlare's edge node? In the case of an edge node, what particular set of CloudFlare's IPs should be returned. These are both user settable options, and need to be propagated to all dns servers in real time. Supporting this meant supporting an increasingly hacked up fork of pdns, with logic scattered though the code base. Eventually it became less work to build rrdns as a clean platform.

In terms of dns updates, see the blog post [http://blog.cloudflare.com/kyoto_tycoon_with_postgresql](http://blog.cloudflare.com/kyoto_tycoon_with_postgresql) for details on how CF does it now.

</comment></comment></comment><comment><USER7> I'm curious if cloudflare will ever just sell its anycast dns as a service.

Don't really need the other stuff but from what I can see their dns performance is on par with dnsmadeeasy/dyn/ultra

<comment><USER8> Wouldn't that obviate the need for third party CDN's?

</comment></comment><comment><USER9> While playing these kinds of games on security sensitive services might not seem like a good idea, it lets someone take ownership of its development, and gain experience with its codebase.

</comment><comment><USER10> I imagine the switch over to TCP is more because the response is likely to be larger than a UDP packet (which IIRC is why DNS-over-TCP exists) (looks to be the case [1]), as opposed to stopping an amplified reflection attack, but it's a nice side effect.

[1] [http://serverfault.com/questions/404840/when-do-dns- queries-...](http://serverfault.com/questions/404840/when-do-dns-queries-use- tcp-instead-of-udp)

<comment><USER11> Nope. Normal DNS behaviour is to send the first few records over UDP and set the response truncated flag, which would still allow amplified reflection. They're intentionally sending no records at all in order to protect against this.

<comment><USER12> Some name servers include partial rrsets in truncated responses, some decide it's best to omit the entire rrset, some decide it's best to omit that entire section. All of those behaviors are valid (RFC2181 section 9 is about as detailed as it gets). I think there's enough variety that really there's no "normal" for this.

</comment></comment></comment><comment><USER13> I remember listening to a podcast where Steve Gibson mentioned that he uses a DNS TXT record to publish the current version of SpinRite. That way the program just does a DNS look-up to see if there is a newer version available.

Thought that was a clever trick. Saves a centralised server getting hit all the time (although you then miss out of usage information I guess.)

</comment><comment><USER14> "For an even more useless, albeit fun Easter Egg, try querying for the CH record for whois.cloudflare against one of our name servers."

        $ dig ch whois.cloudflare @emma.ns.cloudflare.com
        whois.cloudflare.    86400    CH    TXT    "                                  IIIIIIIIIIIII                              "
        whois.cloudflare.    86400    CH    TXT    "                               IIIII,,,,,,,,,IIIII                           "
        whois.cloudflare.    86400    CH    TXT    "                             III?::::::::::::::::III    I                    "
        whois.cloudflare.    86400    CH    TXT    "                            III:::::::::::::::::::::III I      I             "
        whois.cloudflare.    86400    CH    TXT    "                           III<comment><comment><comment><comment><comment><comment><comment>~~III II I I   I          "
        whois.cloudflare.    86400    CH    TXT    "                         II?</comment></comment></comment></comment></comment></comment></comment></comment><comment>=IIIIIIIIIII</comment><comment>==III? ???I  I           "
        whois.cloudflare.    86400    CH    TXT    "                 III    III+++++IIIIIIIIIIIIIIIII++++++II????????   I        "
        whois.cloudflare.    86400    CH    TXT    "              IIIIIIIIIIII????IIIIIIIIIIIIIIIIIIIII????III?????? ??I         "
        whois.cloudflare.    86400    CH    TXT    "             III,::~=++IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII???????? ?III     "
        whois.cloudflare.    86400    CH    TXT    "            III:~=+IIIIIIIIIIIIIIIIIIIIIII?IIIIIIIIIIIIIIII??????????        "
        whois.cloudflare.    86400    CH    TXT    "            II==+IIIIIIIIIIIIIIIIIIIIIIIIIIIII???IIIIIIIIII++++????????II    "
        whois.cloudflare.    86400    CH    TXT    "            II??IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII????IIII~:~++????         "
        whois.cloudflare.    86400    CH    TXT    "        IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII+=:,.IIIIIIIII?II        "
        whois.cloudflare.    86400    CH    TXT    "       IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII??++++~~=+I~~::,IIII     "
        whois.cloudflare.    86400    CH    TXT    "     IIII=====++IIIIIIIIIIIIIIIIIIIIIIIIIIIII??????IIIIIIIII???+===~~::III   "
        whois.cloudflare.    86400    CH    TXT    "   III</comment><comment>IIIIIIIIIIIIIIIIIIIIIIIIIII???IIIIIIIIIIIIIIIIIIIII?III++==~III  "
        whois.cloudflare.    86400    CH    TXT    "  III===IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII?IIIII+++III "
        whois.cloudflare.    86400    CH    TXT    "  II==777777777777777777777777777777777777777777777777777777777777I77777??II "
        whois.cloudflare.    86400    CH    TXT    " II=777777777777777777777777777777777777777777777777777777777777777777777III "
        whois.cloudflare.    86400    CH    TXT    " II$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$II "
        whois.cloudflare.    86400    CH    TXT    " IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII "

</comment><comment><USER15> Easter eggs? In something as crucial as an authoritative DNS server? Is that wise?!?

<comment><USER16> There are easter eggs in many of the crucial services on the Internet. The HTTP status codes are the first that come to mind.

After all, what's the point of running a massive service if you can't have fun with it?

<comment><USER17> 418 I'm a teapot

</comment></comment></comment><comment><USER18> I'm wondering how RRDNS compares to Unbound (unbound.net) ?

<comment><USER19> You're probably thinking of NSD, not unbound. RRDNS is an authoritative DNS server.

[http://www.nlnetlabs.nl/projects/nsd/](http://www.nlnetlabs.nl/projects/nsd/)

<comment><USER20> We originally considered building of off Unbound. It is great product and plan on switching our internal recursors from PDNS Recursor to Unbound in the future. The decision to build our own was because we are heavy user of Nginx and really like the concept of being able to easily create new modules that can be inserted at different points in DNS response pipeline. We will be blogging a lot more about the technical aspects of RRDNS in the future.</comment></comment></comment>


Lets talk about the H1-B visa - <AUTHOR> https://medium.com/@fwiwm2c/lets-talk-about-the-h1-b-visa-6e5d5def2b00#.y3hx5twkq <comment><USER2> Re: H-1B

The author scapegoats foreign outsourcing firms, but gives "domestic" (i.e., non-outsourcing firms) a pass. This is a common mistake. The H-1B visa legislation is what is at fault here, and ALL companies use and abuse the weaknesses of the legislation.

While lobbying Congress for more H-1B visas, industry says H-1B workers are "the best and brightest". Come payday, however, they're entry-level workers.

The GAO put out a report on the H-1B visa that discusses at some length the fact that the vast majority of H-1B workers are hired into entry-level positions. In fact, most are at "Level I", which is officially defined by the Dept. of Labor as those who have a "basic understanding of duties and perform routine tasks requiring limited judgment". Moreover, the GAO found that a mere 6% of H-1B workers are at "Level IV", which is officially defined by the US Dept. of Labor as those who are "fully competent" [1]. This belies the industry lobbyists' claims that H-1B workers are hired because they are experts that can't be found among the U.S. workforce.

So this means one of two things: either companies are looking for entry-level workers (in which case, their rhetoric about needing "the best and brightest" is meaningless), or they're looking for more experienced workers but only paying them at the Level I, entry-level pay scale. In my opinion, companies are using the H-1B visa to engage in legalized age discrimination, as the vast majority of H-1B workers are under the age of 35 [2], especially those at the Level I and Level II categories.

Any way you slice it, it amounts to H-1B visa abuse, all facilitated and with the blessings of the US government.

The National Association of Colleges and Employers (NACE) has never shown a sharp upward trend of Computer Science graduate starting salaries, which would indicate a labor shortage (remember — the vast majority of H-1B visas are granted for computer-related positions). In fact, according to their current survey for Fall 2015, starting salaries for CS grads went down by 4% from the prior year. This is particularly interesting in that salaries overall rose 5.2% [3].

The visa laws need an overhaul so that the visa is only used for it's stated purpose — to attract (and pay accordingly) TOP talent.

References: [1] GAO-11–26: H-1B VISA PROGRAM — Reforms Are Needed to Minimize the Risks and Costs of Current Program [2] Characteristics of H-1B Specialty Occupation Workers Fiscal Year 2014 Annual Report to Congress October 1, 2013 — September 30, 2014 [3] NACE Fall 2015 Salary Survey, NACE Salary Survey — September 2014 Executive Summary

</comment><comment><USER3> Another improvement would be to allow a H1B worker to change company more easily. Today, it is not difficult per se, but there are some legal procedures that often scare companies. Basically, it is as simple as filling a H1B petition that is guaranteed to be approved since the worker is already in the US (i.e. no lottery, it's a sure thing). We're talking a few grands in legal/processing fee. Much cheaper than a recruiter but a lot of companies just don't want to deal with this.</comment>


What Does Haskell Have to Do with C++? - <AUTHOR> http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/

<comment><USER2> I see (and it is certainly highly subjective) one large similarity between Haskell and C++: Haskell and C++ code looks similar to me aesthetically, as in indentation patterns being similar and so on, it's certainly weird :)

Also it is interesting to note, that both Haskell and C++ world is full of discussions about how to do something remarkably complex to get nice syntax for something. You don't see that in lisp world, where such problems are simply solved by macros and nobody goes into great lengths to (ab)use some random language feature to get nice syntax for his library.

<comment><USER3> This happens in a ton of languages, e.g. Ruby (method call syntax and blocks), Scala (idem), C# (LINQ syntax), etc.

</comment></comment><comment><USER4> This is why I hate C++

        template<template<class> class f1, template<class> class f2> struct or_combinator

Incidentally, his or_combinator example is more simply expressed thusly:

        or_combinator f1 f2 x = (f1 x) || (f2 x)

This has the same type signature. Anonymous functions are more useful in Haskell when you have some lexical context which needs to be captured and passed around. If partial application suffices, simply use partial application.

I suppose he was trying to demonstrate that the evaluation does not occur until the value is applied though, if the audience was more familiar with C++.

<comment><USER5> When you get templates working, it does feel pretty good - you can get an approximation of the power of functional languages, all the while knowing that your code has been directly mapped to assembly.

I don't know if it's as good as writing some neat functional code, but for me it's still fun!

<comment><USER6> If you get a decent Haskell compiler working, say ghc, you get the same warm- fuzzy assembly-feeling.

</comment></comment></comment><comment><USER7> _The nice thing about single-paradigm languages like Haskell is that they have very simple syntax (think of Lisp that does everything with just a bunch of parentheses)._

This statement suggests the author has limited exposure to Common Lisp, which supports the widest variety of programming paradigms in one language that I can think of. Simplicity of syntax seems to be mostly orthogonal to allowing the use of many paradigms, though it's probably hard to have a very complex syntax with a semantically simple language.

<comment><USER8> _Common Lisp, which supports the widest variety of programming paradigms in one language that I can think of_

Allow me to introduce you to Mozart/Oz and AliceML. Seriously, those two twin languages are the most epic out there.

You would have to hack CL extensively, and bundle various libraries to make it on par with Oz or Alice. Maybe CL + Screamer + FSet + Heresy + pcall + cl- store would be a pale, distant imitation.

For the last 50 years, PL research has been done with minimal kernel languages, implementing few features. Don't know what mental mutation caused the Oz team to go the opposite way and implement "everything imaginable" in a tiny language, but I like it. The core of Oz is no larger than Scheme, btw.

<comment><USER9> Oz is an interesting language. I only learned it because I was reading Peter Van Roys excellent _Concepts, Techniques and Models of Computer Programming_ , but I'm glad I did.

Having said that, I've never actually used it for anything substantial.

<comment><USER8> I couldn't either, til I discovered Alice, which is feature compatible but is an SML.

I have "ported" my knowledge to Common Lisp and use it there; but I have been actively re-learning ML for the past few months.

</comment></comment></comment></comment><comment><USER10> Clearly the rational thing to do is to create a Haskell DSL that compiles to C++ template metaprograms.

<comment><USER11> That wouldn't fly. The IO monad makes Haskell too conceptually impure to express well in the elegant functional language that is C++ template specialization.

</comment></comment><comment><USER12> I'm loving Haskell more and more.

</comment><comment><USER13> Great insight into the relationship between C++ MP and Haskell!</comment>


Google Glass Is Dead; Long Live Smart Glasses - <AUTHOR> http://www.technologyreview.com/featuredstory/532691/google-glass-is-dead-long-live-smart-glasses/? <comment><USER2> I think the fundamental issue with Glass was putting a camera on it. Imagine if it _didn 't_ have a camera but was otherwise unaltered. It would have been a forcing function to actually find out more things to do with it than be a head mounted camera. Most of the social stigma would have been gone and it might be a thriving device now.

Get it going, add the "obvious" camera functionality on some models and off it goes.

Instead the camera was fundamental to the design, and to my knowledge represented about 90% of the use-cases demonstrated for the device...without even offering AR.

<comment><USER3> The fundamental issue was the geekiness of it all. Look at the lengths Apple was going to show Apple Watch as something fashionable when introducing it. Google failed and projects a worse image than a bluetooth headset or a Segway.

The camera doesnt help and helps to rationalize it as a failure but was not the main factor.

<comment><USER4> The fundamental issue is that glass is a blatantly obvious design, with no sophistication whatsoever, one that couldn't even get close to being charmingly _anything_. It's an ugly stick in front of some (admittedly ugly/geeky) glasses, with touchpad (!) and voice controls crammed together. No amount of functionality can account for the design and usability horror that this device has unleashed since it's conception.

<comment><USER5> Agreed. It's awfully awkward to operate.

</comment></comment></comment></comment><comment><USER6> In the very first batch of paragraphs this article gets a very fundamental thing about Glass and the backlash to it wrong.

The article tries to claim that owners became known as glassholes because they wore computers on their face, and then tries to argue that less conspicuous implementations will be accepted more easily.

Meanwhile in reality people got upset because Glass owners had a camera on their face the entire time.

Edit: Turns out the entire article is in fact trying to claim that Glass is disliked because it's too obvious, and that it'll be just fine when it's near invisible.

<comment><USER7> I feel one must question why people are upset about glass-cameras but are perfectly fine with omnipresent CCTV or NSA data collection. The Surveillance Camera Man video series highlights the same issue.

Do people genuinely care about privacy, but only think about it when the breach is obvious and in their face?

<comment><USER8> I think they are two different things.

Having a friend filming your conversations feels a lot more personal and tangible in my mind. A dumb example, but let's say you talk to your friend about how you hate your boss or how you cheat on your partner. Your friend can very easily cause you a lot of problems by just emailing that conversation to someone else.

While CCTV and the NSA are terrible in their own right the damage that they can do is at a whole different level. (Except on particular cases) they don't care too much about the specifics of your personal life.

<comment><USER9> Your friend can repeat what you've said to others without any device at all. He can also make an audio recording of your comments while pretending to fiddle around on his phone. Hell, he can do it without taking his phone out of his pocket. People are a-ok with this state of affairs, but are appalled at the idea of being "surreptitiously" recorded by someone wearing possibly the least stealthy device ever created by man.

Why? Because a legitimate fear of being recorded isn't what lies at the heart of mainstream hatred toward Glass.

</comment></comment></comment></comment><comment><USER10> It's dead with consumers. Business use cases can make sense, though. If you can make a warehouse picker 5% more efficient you can easily save the cost of the device, etc..

<comment><USER11> 5% x $15/hr = <$1/hr savings.

$1500 + software + support = >1 year payback. And if they break, you lose entirely.

In my warehouse, chromebooks and used Dells run the show.

<comment><USER12> No doubt the price today will be the price forever, and nothing survives longer than a year,

<comment><USER13> I know you are being sarcastic.

</comment></comment></comment></comment><comment><USER14> I like Thad Starner's other designs[0] a lot more than Google Glass.

Granted, they are bulky and dorky, but at least they had a keyboard and a hackable operating system (linux with an emacs-based ui if I remember well).

I wouldn't mind a setup with a tiny screen, a wire running from the back of my glasses to my pocket, connected to a raspberry pi or similar (heck, even my cell phone) and some sort of chorded keyboard that I can use without looking at it.

[0] for example [http://www.innovations.gatech.edu/wearable/photos/ThadStarne...](http://www.innovations.gatech.edu/wearable/photos/ThadStarner.jpg)

<comment><USER15> They had Bluetooth keyboard support, and ripped it out in a (forced) update. They almost had a hackable operating system - it was possible to set up a Linux install in a chroot and use that - but they went around breaking things, and since there's not much point without the keyboard, no one's gotten it working again.

</comment></comment><comment><USER16> This a bit of an aside, I have slight astigmatism, and I have some prescription glasses in a drawer somewhere that I haven't put on in ten years. Fixing my less than perfect vision is not worth the hassle of having to wear a device on my head all the time. I haven't worn a watch on my wrist since...probably elementary school--so the 70's. For a few years I carried a pocket watch, now my cell phone is my pocket watch, and that is a significantly better situation than wearing a piece of tech on my wrist. So it seems like the all the tech companies are trying to make me wear something that I have already concluded I don't want to wear.

In the case of watches it seems less strange--plenty of people love watches on their wrist. So Apple and Motorola can sell to them. But the only people who wear glasses are people with vision problems. They do their best to make them comfortable and fashionable, both I don't know anyone with good vision wishing they could wear glasses. So if Google can make a version that works with prescription lenses, and sell to people that need them, but it seems like it's going to be a much harder push to get people who don't wear glasses every day to commit.

<comment><USER17> Plenty of people wear glasses for fashion.

<comment><USER18> Plenty of people wear contact lenses.

<comment><USER17> Yep, athletes, cyclists...

<comment><USER19> Many many people wear contact lenses rather than glasses for style reasons. I probably know more people who have contacts than glasses, and none of them are athletes.

<comment><USER17> It's not exactly a non-starter though. These days few people in the first world wear glasses or watches out of necessity, but some do wear watches or glasses for fashion.

</comment></comment></comment></comment></comment></comment><comment><USER13> Google Glass's biggest problem is really wrong timing. In fact, all of the wearables that are coming out now have the problem of wrong timing. We hardly have exhausted the applications of mobile computing. And the applications that do exist are only a version of desktop and big computing devices retrofitted onto mobile.

The true vision of what "a computer in every pocket" can do has hardly been scratched. Things like accepting credit cards on the spot with an iPhone or barcode scanning with mobile cameras are true examples of that kind of vision. 3D scanning, whenever it arrives, will be another example. Flashlight, pocket camera, video conferencing, and digital level are also great examples.

One of the great ways I hacked my life to use a "pocket computer" was using it as a digital briefcase where the phone would sync all my work files on my work computer the moment I connected to work wifi and sync it again to my home computer the moment I connected to home wifi. (I know it's not needed anymore.)

That kind of true innovation where you give the mobile phone actual _mobile_ purpose is what makes the phone a great device. Retrofitting apps from desktop to mobile fits only in some (venture capital)/(mobile frontier)/(developing country) scenario.

To immediately warp speed to wearable computing and to retrofitting desktop or mobile apps onto wearable platforms is immature. There are some great uses of wearables like Google Glass in the areas of augmented reality. But very few companies are even thinking about it. Other uses for Google Glass are hindered because of privacy alarmists who cannot stop thinking about sinister uses. And of course there is the cultural stigmatism of having a computer on your face.

</comment><comment><USER20> Wait, "dead"? Last I checked, the only thing you can get right now is the explorer edition (read: beta) device at the "no random consumers" price point of $1500. Google is on record as saying this is supposed to get another refresh and a lower price point in the future.

Seems mighty premature to call the device dead when it's both not out yet and the beta users are still getting updates.

<comment><USER15> > Seems mighty premature to call the device dead when it's both not out yet > and the beta users are still getting updates.

The updates that have gone out to beta users have been extremely minimal; there can't be more than a couple devs working on them. And on net, they've removed more features than they've added, and broken about as many things as they've fixed.

</comment></comment><comment><USER21> I think it's easy to dismiss Google Glass because it's never been "necessary", in the entire history of human civilization, to have a computer on your face.

But in order to test the "is this a fad or is this truly transformative" question, my guess is that at its core there is no question this is a transformative technology. Here's how I've reasoned to this conclusion.

Having an unobtrusive computer on your face, where you get no-friction, continuous access to the user's basic senses of sight and sound while they're out living their lives (far more time than your typical person spends sitting in front of a computer), is what this is all about. If you can't imagine uses for computers unless we're sitting in front of them or holding them in our laps, my hunch is you're not very bullish on human innovation.

</comment><comment><USER22> Hmm, as a techie I think its somewhat of a shame that Google Glass is dead. But as a person concerned about privacy I'm glad it's dead. Meeting people and speaking to those wearing them was just too non-human to be comfortable.

</comment><comment><USER23> I don't necessarily think launching/announcing it in its beta state was the wrong thing to do (as opposed to launching a finished product like Apple does). Imagine if they spent all the resources to "finish" the product and then find out it was a failure?

They obviously learnt a lot from the initial public reactions and I am sure that a lot of Glass technology has made its way back to smart phones and smart watches (especially voice recognition).

</comment><comment><USER24> A company I consult with has done a lot of research on Glass users over the past several months. I won't, and can't, share any of those insights, but I can say this: the office still has 40 glass devices sitting in boxes because not one of the employees is tempted to use one or take one home.

Most interestingly, Google is willing to simply write off "$70,000" in devices. Their budget is unbelievable.

</comment><comment><USER25> I think the problem has more to do with mass production and marketing than it is with privacy concerns, etc.

If Google glass sold for $100~$200 price range and could be purchased everywhere (like Chromecast which I got in India for $40) it would have been a big hit.

</comment><comment><USER21> I think the "killer apps" for Google Glass will require pairing the glasses with a Project Tango device.

I just hope the Google Glass project remains alive for long enough to see this happen.

</comment><comment><USER26> Google is a search advertising company not a consumer products company. They haven't had one successful product in hardware yet.

Which makes the thought of Google actually executing on a driverless car pretty laughable.

<comment><USER27> Huh? What about all the nexus devices or the Chromecast?

<comment><USER28> What about them? Have you ever peeked into how much market share do they have? Let me guess, no. And Chromecast? Nobody knows what that is aside from geeks obsessed with Google.

<comment><USER29> Chromecast is currently the 2nd best seller product on Amazon in the Electronics category, having recently dropped from 1st where it stayed for months. On what exactly do you base the idea that nobody knows what it is?

<comment><USER28> If you compare the reach of AirPlay against the reach of Chromecast there's a difference of at least TWO orders of magnitude; that's my basis. And I'm not an apple fanboy (gohrt), I'm more of a reality fanboy.

<comment><USER29> AirPlay is not a device, it's a technology implemented by multiple devices, and it's four years old (compared to Chromecast, which is barely one). Comparing the two directly is nonsensical.

</comment></comment></comment></comment></comment></comment><comment><USER30> I think this post is falsely trying to accuse Google of something.

Remember Google is a company that doesn't make money out of its products and a lot of their stuff are open sourced like Android for people to be able to keep them alive.

What happened with Google glass and its on the makings documentary about it, is that they wanted to make some breakthrough in technology. They never planned on making the glass work 100% or become and iphone that everyone would kill to acquire, because they are not looking into that kind of profit.

I find that post being on some short of a steak with google and wants to blame them for their own product and how its doing...

<comment><USER31> it might of been a breakthough technology-wise, but it hit a massive horrible wall social-wise. I'd say that the social barrier is probably the more important breakthough at the current moment than the tech one, and it does seem google is falling a bit short on that.

It doesn't help that google is a data company as well, probably not the most pleasant brand-name to stick on such a device</comment></comment>


Show HN: House Prices in England by Postcode - <AUTHOR> https://quicksold.co.uk/house-prices <comment><USER2> Great website! really puts in persepective the change over the year, for example:

[https://quicksold.co.uk/house-prices/cb58qu](https://quicksold.co.uk/house- prices/cb58qu)

Over 20 years the price in this post code (residential area in Cambridge, not luxurius) went from ~40k to ~250k

I am also always excited about how well the UK handles it's open data. There is just so much and it's all well available.

<comment><USER3> What's super interesting to me is the differences in flat prices for my particular building. My building is mirrored, but the flats on my saide of the building are cheaper than the other side by a huge margin. I wonder if people overpayed because they didn't have tools like this to inform them.

</comment></comment><comment><USER4> I got an Internal Server Error when doing a search. I am not on the same continent as your target audience so maybe it's denying my request due to heavy load. Just a guess.

I recommend providing an example of an England post code in the placeholder text so that anyone can see your work without knowing any of the poastal codes.

<comment><AUTHOR> Thank you for your suggestion, it's a great idea.

</comment></comment><comment><USER5> Would you mind saying a bit about what value you hope the user of the site will get from this?</comment>


The systemd fallacy - <AUTHOR> http://monolight.cc/2011/05/the-systemd-fallacy/

<comment><USER2> It's obvious that the author of this article has never actually used systemd. For example, he complains that the startup sequence is "written in C," so the only way to change it is to recompile systemd itself. This is utter nonsense; systemd uses tiny config files called units to configure everything, so there is no reason to recompile. It's hard to take these complaints seriously when the author clearly hasn't used the thing he's complaining about, or ever read the man page.

A few months ago, I actually installed systemd on my laptop to see what the fuss was about. It was one of the best things I've ever done. Before systemd, system bootup was controlled by a bunch of shell scripts that made no sense to me; if I wanted to add a new daemon, my only hope was to copy-paste a similar- looking script from /etc/rc.d. Now, my bootup is controlled by a bunch of trivial config files like this:

      [Unit]
      Description=My Daemon

      [Service]
      ExecStart=/usr/bin/mydaemon --some --flags

So, this idea that systemd somehow makes the system more complicated is utterly false; systemd is a great simplification from an admin's point of view. Sure, the systemd daemon might be a bit larger than the classic init daemon, but RAM is cheap these days and admin's time is not. I think this is a good tradeoff.

<comment><USER3> > system bootup was controlled by a bunch of shell scripts that made no sense > to me

And this is the problem. You're guilty of the very thing you're accusing the author of.

Some of those shell scripts are very simple and can be easily replaced with a configuration type file. Most are not. They do a ton of stuff, like create lock files, pid files, check for dependencies, check for existing processes, etc etc and couldn't be properly replaced by a configuration block.

Using shell script gives you unbelievable flexibility in how you start a daemon that can never be replaced by a configuration script.

So what happens? All that complex stuff stays in that script you can't understand and now you've added an additional layer of complexity that wasn't necessary.

Every additional layer adds a point of failure and in my humble opinion, isn't worth the additional user-friendliness.

<comment><USER4> My personal experience with writing sysvinit scripts agrees pretty well with s_tec's view. Those shell scripts would easily have been replaced by trivial .ini files and contained several bugs before I managed to figure out how to use start-stop-daemon correctly and fix some typos.

I have not used systemd myself but it seems trivial in comparison to my experience writing sysvinit scripts.

</comment></comment></comment><comment><USER5> It really matters for servers how long they take to boot, particularly when you look at virtual machines / clouds, where they are thrown up and torn down rapidly.

</comment><comment><USER6> Switching from shell to C is a problem from DoD users - you aren't allowed to have a compiler installed on a production machine, so to edit your init process (I guess they aren't scripts anymore!), you'd have to have a separate machine to do the compiling.

<comment><USER7> Not installing compilers on production machines is a relic from 1990 that doesn't impact security in any meaningful way. If I have access to your machine I can upload a compiler and/or I can upload binaries generated by a compiler at my end of the pipe.

<comment><USER8> Relic or not, that's the way things are in many businesses and governments.

</comment></comment></comment><comment><USER9> I can't take this rant seriously when it dismisses the importance of fast startup. "You shouldn't care if your system starts up slowly" is just untenable.

<comment><USER6> The multi-second difference in software start time, after waiting 5+ minutes for my RAID to initialize and all the onboard crap to check out is really negligible.

<comment><USER8> Except if you're using ksplice on Linux to start a new kernel, you won't be waiting for RAID to initialise, which means those seconds do matter. (Or fast reboot on Solaris.)

In many SLAs, the amount of time the system is unavailable can count against the company providing the server. Minimising the amount of downtime is a win for everyone.

<comment><USER6> If you're basing downtime avoidance on 'how fast I can boot', you're doing it wrong.</comment></comment></comment></comment>


The Mystery of the Deterministic Super Shotgun - <AUTHOR> http://two-wrongs.com/the-mystery-of-the-deterministic-super-shotgun <comment><USER2> I guess he could have searched for the word "shotgun" instead of spending 3 paragraphs explaining how he found the right method.

<comment><USER3> Eh. It may have worked correctly in this particular case, but it also would have been a poor lesson in grokking big unfamiliar codebases. In my experience, hail-mary grepping for words of interest is a pretty poor strategy: if it turns up anything at all, it is usually something totally unrelated, while the code you wanted to find uses some synonym you didn't think of. Even when you are lucky enough to hit the code you're looking for, you don't have enough context to understand it.

Tracing a related input from ingestion to the point of interest is a very good strategy: it's reliable, and you pick up important context on the way.

<comment><USER4> It's not your fault but I wish the word "grok" would disappear.

<comment><USER5> Why? It seems a perfectly cromulent word for a concept which has no other succinct description

<comment><USER6> How do you think it's being used here? That is, how is it being used here differently than "come to grips with", "apprehend", "understand", or "comprehend"?

Another dimension is its use as a shibboleth. In this case, the origins from a science fiction novel that was popular in the counter-culture of the 1960s and made its way into the hacker culture of the 1970s and 1980s. Its use indicates membership in this group, even if the meaning duplicates words in common practice. Similarly, your use of cromulent indicates your alignment with a TV series.

If you mean to include that dimension as well, then you are right; using 'grok' embiggens the distinction between ingroup and outgroup in a way that those words do not.

<comment><USER7> 'Grok' usually has a stronger meaning than the words/phrases you mentioned. It means to comprehend something deeply, gain intuitive and thorough understanding.

<comment><USER6> Agreed. I gave a similar definition in a parallel thread. My question is, is it being used in that sense _here_ by Nacraile. My followup question is, is that's how it's usually used? I get the stronger sense that it indicates that one is a hacker, than that it's being used for an otherwise missing concept.

<comment><USER8> I find people usually use it to mean the point where they could modify the code and expect it to probably work. I might not really understand all the details, but I know it well enough to become part of it. Which really fits the origional definition far more than understand.

<comment><USER6> The original definition is "to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience. It means almost everything that we mean by religion, philosophy, and science—and it means as little to us (because of our Earthling assumptions) as color means to a blind man."

Your description here is nothing like the original meaning.

<comment><USER8> To use more flowery language. You merge your thoughts with those who came before allowing for synthesis, extention, or improvement. Nothing in the book suggests grocking is total understanding just the point where there ready to act. So, being able to follow the thought process of the coder(s) who came before instead of just reading the logic is a deeper understanding. Sum=54; Foreach(int x in Dalist) sum += x;

The logic is easy to follow. But WTF is 54. Until I understand why 54 is there I don't grock the code even if I understand what it does. Again I might not agree with the coder but I need to understand what they where thinking before I can change anything.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


MySQL is bazillion times faster than MemSQL - <AUTHOR> http://dom.as/2012/06/26/memsql-rage/ <comment><USER2> MemSQL CTO here. Great article- Domas has done a good job of digging into the internals of MemSQL! A few questions/comments:

1.) The range query issue you pointed out can be explained by a well known limitation of skip lists. Unlike B-Trees, skip lists are unidirectional. By default, our indexes are ascending, so indeed you have to skip to the end to run a MAX() or "ORDER BY id DESC" query. To fix this, just change the primary key to be descending in your schema:

        CREATE TABLE x (id int, ..., PRIMARY KEY id (id) DESC, ...)

This is explained here [http://developers.memsql.com/docs/1b/indexes.html#skip- list-...](http://developers.memsql.com/docs/1b/indexes.html#skip-list- indexes). If you want both behaviors in your app, you'll have to create two skip list indexes (for now).

2.) The transaction-buffer > 0 setting is really where we shine. Synchronous durability is something we have for flexibility, but I'll be the first to admit that it's not really optimized to perform well. The customers that we're working with are okay with this. And it's inspired by what modern companies do. Maybe it's changed in the time since I've left (Domas?) but Facebook certainly does not write comments synchronously to disk.

3.) Our synchronous durability does indeed flush in 50 MS cycles, so you'll see poor performance on single threaded inserts. However, as you pointed out, we're optimized for the case with multiple concurrent writers. Since MemSQL implements group commit on high parallel load throuput picks up. Sure, writing your own very specific benchmark you can show us writing poorly, but we've never worked with a customer that's needed single threaded, synchronous writes to shine. If this is your use case, unless you need substantial read performance, MemSQL is not the database for you.

<comment><USER3> You seem to be missing the main reason why people have an issue with MemSQL. The issue are quotes like this on your website and video:

"MEMSQL IS 30 TIMES FASTER THAN MYSQL."

It's an extremely invalid and biased comparison. You're quite literally comparing the speed of writing to RAM versus the speed of writing to disk. If you didn't make such ridiculous assertions, people would accept your product for the actual awesome things it does and not focus on refuting your bullshit claims.

<comment><USER4> Tim, if you want to talk substance, you have to peer deeper under the covers. And if you do that, then you just can't overlook the fact that the query execution model used by MemSQL is significantly different than that used by old school relational databases, including MySQL. And what's different is that MemSQL translates you SQL query into extremely efficient C++ code. Code that is compiled and executed natively. Whereas MySQL, SQL Server, Postgress, Oracle - all of these products evaluate queries by interpreting their respective tree representations of your SQL queries. So which database do you expect to be faster? The one that runs native code or ones that interpret?

This is a huge differentiator we are talking about here. For someone who has been around databases for quite some time (of which I had spent about 5 years working on SQL Server engine) this is very exciting. Is it not?

<comment><USER5> >And what's different is that MemSQL translates you SQL query into extremely efficient C++ code. Code that is compiled and executed natively. Whereas MySQL, SQL Server, Postgress, Oracle - all of these products evaluate queries by interpreting their respective tree representations of your SQL queries.

This sounds like absurd cargo culting. I've never designed a database but parsing the SQL can not have ever been the bottleneck; the fact that you rarely write to disk is where any speed improvements can be found.

<comment><USER4> You are asserting that databases are always I/O bound and never CPU bound. Your assertion is wrong. A properly tuned database will become CPU bound (whether it's MemSQL or MySQL). At that point hyper-efficient execution results in higher throughput and lower latency.

<comment><USER5> > At that point hyper-efficient execution results in higher throughput and > lower latency.

I don't get excited for 1% decreases in latency. I'm willing to bet money that the performance penalty behind parsing the sql queries is asymptotically a constant - or at least, a tiny fraction of the time spent computing the data set.

I feel especially confident in this because memsql never brags about the specific increase in speed. This can't be hard to measure.

<comment><USER4> Phill, parsing has little to do with what goes on at query execution time. Parsing is typically done once for a given parameterized query (and MemSQL automatically parameterizes queries with constants). After parsing comes compilation which produces a query plan. The query plan is cached and that is the thing that is actually used to evaluate the query when it's re-submitted again. We are discussing the differences in how MemSQL handles executing compiled queries. Executing compiled queries is what a (well tuned) database spends most of its time doing. It is the hot code path. And if you cut the instruction count in half you can expect latency to decrease proportionally and throughput to increase.

You are making all these skeptical claims that are technically wrong. I suggest you download MemSQL, compile a query and read the generated C++ code. Then download MySQL source and look at that too. At that point you will be coming to your own conclusions and I'll be happy to resume this debate.

<comment><USER6> I've actually written a compiler from database queries to native code (JIT'ed bytecode actually, but doesn't make a difference here) once.

Some queries in databases are indeed CPU bound, but the general statement that well-optimized databases turn to be CPU bound is not correct like that. It all depends on the use case.

If you're thinking full table scans with complicated processing on a database that's entirely in memory, then yes, you'll be CPU bound. But many (most?) databases are not entirely in memory, and there's no reason they need to be. With reasonable memory and indexing, most queries boil down to only a few IOs/disk seeks, so you're looking at <50ms, which is entirely fine for your average web request.

That's the case for the majority of "get by ID" style queries, which in my experience really are the lions share of queries, and in particular are also what needs to be fast. A complicated reporting query can take a couple of seconds, but your "main page/item view" must be fast.

If you have random reads on a large database that cannot be kept in memory, this will be the majority of your workload. Those queries will spend all their time waiting for the disk, and more or less none interpreting your query tree, so optimizing the query tree processing part makes no sense at all.

TL;DR, in my experience optimizing query tree interpretation does not yield significant benefits for the majority of queries, and IMHO won't be a significant differentiator for MemSQL outside of marketing.

<comment><USER7> @Nitramp: Fortunately for all of us this world is full of unsolved problems many of which exist outside of consumer web.

There are use cases where 50ms is way too long, and where jitter associated with disk I/O is not acceptable. Capital markets for example. You are looking for sub-millisecond latency to be in the intraday post-trade game, and single digit milliseconds for quote-to-trade. The number of instructions in the hot code path (and cycles per instruction) actually starts to matter. Lock-free sturcutres utilized for storage are also important. This combination gives MemSQL some rather unique low-latency properties that certain folks can exploit to their delight.

To your other point, random reads and key-value lookups is where MemSQL shines. Since you never wait on I/O and don't take locks, optimizing execution makes a lot of sense actually. All that's left is execution and network.

<comment><USER8> _Since you never wait on I/O and don't take locks, optimizing execution makes a lot of sense actually. All that's left is execution and network._

I'm not sure where you are getting this information. According to the MemSQL documentation, they have one and only one isolation level, READ COMMITTED. But READ COMMITTED takes write locks and blocks reads, but doesn't take any read locks. Blocking behaviour still (and should!) still occur.

It sounds like you are looking for dirty read behaviour, but from the literature MemSQL doesn't support READ UNCOMMITTED.

 _Update:_ Read a later FAQ on the MemSQL website. They are using MVCC, so write locks are irrelevant. My apologies to the MemSQL team.

<comment><USER7> Chris, MemSQL utilizes versioning to implement READ COMMITTED. In this implementation readers are never blocked.

It is addressed in this FAQ: <http://developers.memsql.com/docs/1b/faq.html#c1-q4>.

<comment><USER8> OK, didn't see that you are using multiversion concurrency control.

I didn't realise you had a new FAQ up on the website - I'll have a look.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Whenever one sees a claim about new database technology outperforming standbys like MySQL and Postgres by factors of 10x or more, it's a good idea to suspect the out-of-the-box configuration isn't really durable. What kills write performance in databases is the time it takes to write to disk, not the software overhead.

<comment><USER10> For what it's worth SQL Server doesn't meet his definition of "durable." It writes a transaction log and then writes those transactions to disk on a checkpoint [1]. Typically, that checkpoint automagically happens, but you can also force it to clear the buffer with a "checkpoint" command.

InnoDB also does this, too [2]. I don't know if MemSQL actually has checkpointing or what, but it's just worth noting.

[1]: <http://msdn.microsoft.com/en-us/library/ms189573.aspx>

[2]: [http://dev.mysql.com/doc/refman/5.0/en/innodb- checkpoints.ht...](http://dev.mysql.com/doc/refman/5.0/en/innodb- checkpoints.html)

<comment><USER11> This is a little misleading; an internal checkpoint happens upon transaction commit[1]. The comment makes it sound as if one or more transactions can commit before a checkpoint writes them to disk.

[1]: [http://msdn.microsoft.com/en- us/library/ms186259(v=sql.105)....](http://msdn.microsoft.com/en- us/library/ms186259\(v=sql.105\).aspx)

<comment><AUTHOR> The transaction is actually written to disk twice. Once when it is written to the transaction log, and then again when a checkpoint happens and it's written to the underlying data blocks. Transaction log writes are sequential and fast, writes to the underlying data blocks are random and slow. The whole point of the checkpoint is to convert this sequential i/o to random i/o in an efficient manner.

Still, that's not what we're talking about. We're talking about the difference between writing data to the transaction log, and writing data to the transaction log _and then flushing it_. Once you call fsync() and the data is flushed you know for a fact (provided the hardware isn't lying to you) the bytes are on the damn platter, and not in some OS buffer cache.

<comment><USER6> ... you'd think.

However in practice most operating systems and/or file systems and/or disks cheat. fsync() is usually buffered in the hard disk itself. You can disable that and force the hard disk to truly write out on fsync, but that is so prohibitively slow that people rarely do that.

If you want absolute durability, you'll have to have hard disks running on some battery buffered power supply, which is a common configuration.

On the other hand, in a proper database system, at least the data files won't be corrupted by a missing fsync, so it'll come up. Figuring out whether that one commit did or did not go out in the very rare event of a fatal power failure and a just pending fsync() and the commit making it out of the network stack in time is probably a Heisenberg-esque inquiry into obscure realms of uncertainty.

<comment><AUTHOR> First of all, ext(2|3|4) and XFS filesystems honor fsync. That's what all the noise about Firefox and SQLite was all about. Secondly the HP RAID controllers I'm familiar with disable the drive write cache by default, and throw dire warnings if you try to turn it on, and make you ACK your choice like:

 _Without the proper safety precautions, use of write cache on physical drives could cause data loss in the event of a power failure...._

The bottom line is that Database pros insist on and get actual durability, and with a battery backed write cache, it's not painful.

<comment><USER6> The file system does, but does the hard drive?

But I agree, getting battery backed write caches is not that hard, it's just not a default config.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> From MemSQL's home page: "MemSQL writes back to disk/SSD as soon as the transaction is acknowledged in memory."

From the article: "See, MemSQL also has "transaction-buffer" setting, which, in default "full durability mode" will asynchronously return "ok" until 128M buffer is full (or background log flusher thread writes it out)."

So which is it?

<comment><USER13> In MemSQL transaction buffer is flushed continuously as long as it is not empty. Default value of 128M is there just to absorb bursts in workload.

<comment><USER14> So you could lose up to 128MB of updates if the machine crashes at the wrong time. NOT DURABLE.

</comment></comment></comment><comment><USER15> Whenever I read an article like this, I often end up feeling that on the 'truthiness' spectrum the scale goes like this: lies, damn lies, statistics, benchmarks ;-)

<comment><USER16> Every public benchmark is a horrible blasphemous lie. The only benchmarks that are honest are the ones you conduct in private, with your very specific use case. There is no point in publishing them, because they're useless to everybody but you. Public benchmarks, on the other hand, are crafted as advertising for your favorite [fill in the blank].

<comment><USER17> If you generate some data which would be dishonest when published, it is also dishonest in private, except that you are only being dishonest to yourself and nobody can review your dishonesty.

If you generate data which are honest in your use case, then you can publish them honestly as long as you are specific about your use case.

</comment></comment></comment><comment><USER18> This reminds me of some early MongoDB benchmarks. Claims of extremely high write throughput when really it's writing to memory and relying on mmap to eventually sync the data to disk.

Making write speed claims when you're not touching the disk is like bragging about how fast you can cat a file to /dev/null.

</comment><comment><USER19> When debating a fresh new database project - benchmarks aren't really the way to go, because those can be improved. What should be debated is what underlying fundamental has the new project gotten right. Almost every successful database project got something fundamentally right - MySQL, Redis (in-memory), MongoDB(page based storage), Riak(Distributed).

On that note, here's my take on MemSQL - People who love MySQL, almost never want to migrate. People who hate MySQL, usually hate it because of SQL. People who are far along in the projects enough that decision of database is no longer a matter of taste, don't use a brand new untested DB.

Therefore, I am unsure how a brand new, in-memory, SQL based solution fits.

<comment><USER20> > People who hate MySQL, usually hate it because of SQL.

Or because of the shortcuts it has taken to avoid the "hard stuff", which results in developers taking shortcuts by using MySQL to avoid the "hard stuff".

Love or hate SQL for what it is, not the MySQL implementation of it.

<comment><USER21> > Or because of the shortcuts it has taken to avoid the "hard stuff", which > results in developers taking shortcuts by using MySQL to avoid the "hard > stuff".

I am deeply interested in what you think this is

<comment><USER20> Avoiding RI (in part due to poor FK support depending on version / storage engine), designs that avoid simple schema changes because they can't be done online, point version migration difficulties.

Consider unsupported SQL constructs from other engines (CTEs, window functions, better join and subquery support), and the effort and mess to accomplish what should be straightforward tasks generates SQL hate.

Some NOSQL projects have merit as they provide mechanisms for working with data structures that do not map well to rows and columns. However, difficulties faced with MySQL have also pushed some projects to use equivalently broken data storage technology, when a "better" RDBMS would be more appropriate.

</comment></comment></comment></comment><comment><USER22> Writing in a volatile storage is not "durable by default" you asshats.

</comment><comment><USER23> Can we say they're deceiving us with this "MemSQL is 30 times faster than MySQL"?

<comment><USER24> that and the claim that it's a durable db

</comment></comment><comment><USER25> Why is "written to hard disk" considered to be "durable"?

Isn't that just a higher likelihood of "durability"?

<comment><USER26> This is actually a fair and valid point. On all but the most delicately configured systems, the standard configuration of basically all SQL databases does not occlude committed data loss during power failure due to the hard disk's write cache. See for example [http://www.postgresql.org/docs/8.3/static/wal- reliability.ht...](http://www.postgresql.org/docs/8.3/static/wal- reliability.html):

        When the operating system sends a write request to the disk
        hardware, there is little it can do to make sure the data has
        arrived at a truly non-volatile storage area. Rather, it is the
        administrator's responsibility to be sure that all storage
        components ensure data integrity. Avoid disk controllers that have
        non-battery-backed write caches. At the drive level, disable
        write-back caching if the drive cannot guarantee the data will be
        written before shutdown.

Which almost nobody does, because performance falls through the floor unless you're pimping a $500 RAID card (don't even mention software RAID).

The SQLite documentation goes into further detail surrounding the atomicity of writing a single 512 byte sector during a power failure (on old drives, on 4096 byte drives, and on SSDs). Few people seem to account for any of this stuff, yet sleep soundly at night regardless.

<comment><USER27> While backup power might be expensive in a hard drive situation, it looks like even cheap SSDs are available with power loss protection. And as far as I'm aware you're better off using SSDs for databases anyway.

</comment></comment></comment><comment><USER28> I think this whole conversation is making a mountain out of a molehill. When you're building sites which have enormous performance requirements, you take what you have and you force it to scale. You don't need to compare one tool to the other and find the perfect benchmark. Whatever you use, I promise you, you can make it perform as fast and scale as far as you need it to.

So just pick the tool that fits your requirements the best and stick with it. That being said, I also urge you to pick something free and open-source if you can. Some of the ways big sites have leveraged MySQL to the extent they have is due to the custom patchsets they apply. Closed-source solutions may not provide similar hotfixes or customization (and when it comes it's months later than they claimed they'd have it ready)

</comment><comment><USER29> Simple solution:

[1] Someone create a project on GitHub [2] Upload an amply sized CSV full of data [3] Publish list of queries needed to "gauge" speed [4] Allow anyone to post their metrics to see how well tuned any database can be in comparison

The only other criteria would be to ask them to all use the same form factor. EC2 makes the most sense.

<comment><USER30> Shared environments with virtualized IO are not good places to run benchmarks.

<comment><USER29> I couldn't agree more, but its the closest to standardized testing we can get that everyone can use.

I HATE the idea personally, but I cannot think of a better way to start comparing apples to apples.

<comment><USER30> I'd opt for the TPC workloads on standardized hardware: <http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp>

</comment></comment></comment></comment><comment><USER31> Hey Nikita having a colorful html5 home page is not enough for a project to be performant

</comment><comment><USER32> People should also look at - and benchmark - tokudb with its fractal tree indices.

<comment><USER33> Sadly for the development of databases their fractal tree technology is patent encumbered.

</comment></comment><comment><USER34> I demand a free lunch.

</comment><comment><USER35> When someone writes on their intro "... and now in return I want to waste your time a bit." it's a sign that someone isn't being serious.

Domas' main criticism is that our video, <http://vimeo.com/44087431>, uses a MySQL with standard defaults. Since tuning a database is by definition a custom process, we wanted to demonstrate what performance you'd get "out of the box." The video speaks for itself. MemSQL can push 80k/sec vs 3.5k/sec for MySQL on EC2.

Domas actually demonstrates MemSQL's robust durability controls: he bounds MemSQL to disk. If you want to throw an anchor behind a speed boat, you can do it, though we don't recommend it.

Even Domas agrees his article isn't serious: "I do agree, that its execution speeds for table scans are not bad – 8M rows scanned a second (for SELECT COUNT(*) query) from single thread is sure a great achievement."

If that's the highest praise I can get from Domas, I can live with it.

<comment><USER36> How do you feel about the reported performance of "SELECT * FROM table ORDER BY id DESC LIMIT 5;"? Is this something that needs to be improved there, or are you happy with that being one of the built-in anchors?

Additionally, I'm not sure that the implementation of the hard reliable case sounds very mature or even well thought-out. Having a syncer running at 20hz and waiting for it even in the synchronous path seems a bad idea. That's kind of like adding an anchor to your anchor so your speedboat can crawl while it crawls. Or was that a misrepresentation?

And who cares if the tone is serious? The criticisms seem to be valid, and ones that anyone releasing software making bold claims should expect. Statements about performance need to be qualified. Out-of-the-box behavior is not a reasonable point of comparison if (1) that's not what people do in the real world (2) the tests you use are ones that one piece of software is tuned for and the other is tuned against. Some kind of sorted index by field is necessary for some very common and desirable queries. Some of the performance gains come at an unacknowledged cost. The durability just isn't there (and for trivial reasons that could be fixed by making a few more parameters tunable, it sounds like), but is implicitly lauded by claiming to be ACID.

I don't know if you need to go looking for praise in that article. It really seems like there are some criticisms it would be beneficial to take seriously, even if you object to the author's tone or lack of praise. Even-handedness is not a marker of honesty, and honest criticism is worth the headaches it causes and the growth it spurs if you're willing to take it seriously.

<comment><USER13> "How do you feel about the reported performance of "SELECT * FROM table ORDER BY id DESC LIMIT 5;"?"

Index was missing on ID column in MemSQL's case, so MemSQL was running entire table scan instead of using the index as MySQL.</comment></comment></comment>


Ask: Why it's so difficult to find a job in New York? - <AUTHOR>

I'm Front-End Web designer, have applied for hundreds of jobs online. But no result. Anyone can help me to find one? I'll be very pleased! <comment><USER2> What do you mean by front-end web designer? Do you design and code front-end as well? There are plenty of jobs in NYC looking for front-end devs with design chops. Check out nytm.org/made-in-nyc/ for a list of hiring companies.

On your resume, be sure to link to your portfolio and github as well. Be prepared to do mini-code projects as a interview test.</comment>


Iran pumps up "massive" offensive exercise with over 50 drones, maybe - <AUTHOR> https://arstechnica.com/information-technology/2019/03/iran-pumps-up-massive-offensive-exercise-with-over-50-drones-maybe/ <comment><USER2> >Iran has been accumulating captured US and Israeli drones and attempting to reverse-engineer them for years.

Well, if they capture a drone in Iranian airspace it is by definition Iranian drones. The easiest way to stop this is not fly drones around Iran. One could almost think someone wanted to piss them off.</comment>


ImageNet-trained CNNs are biased towards texture (2019) - <AUTHOR> https://openreview.net/forum?id=Bygh9j09KX <comment><USER3> They are, and it is not that new; the interesting part is how to solve that.

For image classification, this bias for textures may be passable. For image generation, it would produce atrocious results, especially for faces. To the point, that people devised some methods to overcome this, especially with progressive networks (e.g. proGAN). See [https://towardsdatascience.com/progan-how-nvidia- generated-i...](https://towardsdatascience.com/progan-how-nvidia-generated- images-of-unprecedented-quality-51c98ec2cbd2) for the proGAN explanation - <USER2> starts from training on 4x4 pixel images, to get the overall shape.

</comment><comment><USER4> Texture is area-filling, while silhouette is "just a line", so it sounds natural that texture areas would weigh more in an image? If there is both texture and contour "signal" in the labeled inputs, how to pick what get's weighted more? This is supposed to be learned by training.

<comment><USER5> I think, this is one of the reasons to use much more video-based training sets and these in time-correct frame order. A moving boundary is something quite significant, but these should possibly not exclusively inspected through a hole ('convolutinal')

<comment><USER5> Oh, forgot an 'o'.

<comment><USER6> Did you know you can edit your comments for two hours? Click "edit" above the comment.

[https://github.com/minimaxir/hacker-news- undocumented](https://github.com/minimaxir/hacker-news-undocumented)

<comment><USER5> This is actually new to me. Thank you!

</comment></comment></comment></comment></comment><comment><USER7> My favorite titled ml article [1], from 2015, seems to argue for the same conclusion - that it is textures not shapes that drives recognition in CNN

[1] "Suddenly, a leopard print sofa appears", [http://rocknrollnerd.github.io/ml/2015/05/27/leopard- sofa.ht...](http://rocknrollnerd.github.io/ml/2015/05/27/leopard-sofa.html)

<comment><USER8> > it is textures not shapes that drives recognition in CNN

This is a misinterpretation of the paper. It's not CNNs that are biased toward textures, it's the ImageNet dataset. As they prove by training a CNN biased toward shapes, using a modified dataset.

</comment></comment><comment><USER9> I'm curious if stereo vision and eyepoint movement has a benefit for humans in distinguishing shape vs texture, and perhaps that could be a promising approach for ML, but are there any databases for that? There are car focused ones like KITTI, but any more generalist ones?

</comment><comment><USER5> Quanta article:

[https://www.quantamagazine.org/where-we-see-shapes-ai- sees-t...](https://www.quantamagazine.org/where-we-see-shapes-ai-sees- textures-20190701/)

</comment><comment><USER10> Style transfer is done using neural networks, so it should be natural that the resultant image fools a neural network classifier. On the other hand, for the filled silhouette, the classifier network was pretty close to human.

<comment><USER11> I don't think that's what's happening here.

</comment></comment><comment><USER12> What would be a better dataset to train CNNs?

<comment><USER13> Pro tip: read more than just the headline.</comment></comment>


Coming to America?  - <AUTHOR>

Hello again guys. I see alot of posts by persons wanting info about move to San Francisco , and stuff. But I was wondering for the international persons among us, ( I am from Jamaica) on what bias do international persons come to properly develop their startup. I mean like, will I need work permit? Can I come on a Visitor's visa? etc.

Thanks much.. <comment><USER2> It's not too difficult. It's what the E-2 visa was designed for.. for people to come to the US and start (or, rather, "invest in" businesses). All you need is to invest about $100,000 into a company, either one of your own creation, or one you're going to take over, and you're in for two years (and then indefinitely if the business continues to make reasonable revenue). There are no quotas on this visa and application times are very quick, whereas the H-1B ties you to an employer (totally useless for your own company), etc.

The L-1 visa is another option if you have a company and you want to set up a US office while maintaining the company in your home country, which can be harder to do but is most likely "cheaper".

<comment><USER2> Ah, I just realized this probably won't work for you. I don't now for sure, but Jamaica probably isn't a "treaty" country, which E visas demand applicants have citizenship of.

</comment></comment><comment><USER3> You can come with visitor visa, but if you want to work in US, you need to start with H1B visa, which is now kind of a "lottery" (the annual limit is too small and no guarantee if you can get one).

</comment><comment><USER4> We have talked a lot about this before.. <http://news.ycombinator.com/item?id=40208></comment>


A General Neural Network Hardware Architecture on FPGA [pdf] - <AUTHOR> https://arxiv.org/ftp/arxiv/papers/1711/1711.05860.pdf <comment><USER2> This paper was extremely devoid of content beyond a basic summary of what neural nets are, what an FPGA is, some basics about both (forward propagation, back propagation, usage of HDL modules, usage of LUTs), and a statement that the author created a thing.

As a machine learning guy and total closet FPGA geek, this was sort of a disappointment. I would have liked to see topics addressed like floating point precision, actual benchmarks, how the FPGA can pipeline things better than best known CPU or GPU algorithms due to a lack of pipeline stalls, issues with I/O of training data and predictions, and probably a discussion on LSTM gates or GRUs (which I think the FPGA is particularly suitable for).

<comment><USER3> This might interest you: [http://neuromorphic.eecs.utk.edu/publications/2014-07-14-dyn...](http://neuromorphic.eecs.utk.edu/publications/2014-07-14-dynamic- adaptive-neural-network-array/)

(Disclaimer --- I was a student working on this project)

<comment><USER4> Oh damn. Paywalled. It would be great if someone could throw their VHDL etc on Github

</comment></comment></comment><comment><USER5> Are there performance numbers for this, on e.g. resnet-50?</comment>


Professor Who Called Trump's Win Predicts Trump Will Be Impeached - <AUTHOR> https://www.washingtonpost.com/news/the-fix/wp/2016/11/11/prediction-professor-who-called-trumps-big-win-also-made-another-forecast-trump-will-be-impeached/ <comment><USER2> Let me get this straight. He claims his system has correctly called every presidential election since 1984. But he predicted a win for Gore in 2000. He says that was correct since Gore won the popular vote. In 2016, he called the election for Trump. And that too is correct even though Clinton won the popular vote. Okay... Sounds like someone is "moving the goalposts" to suit their model...

<comment><USER3> 9 fully random coin flips in a row have a 1 in 512 chance of also being right for all nine elections from 1984 through 2016.

</comment></comment><comment><USER4> I'm not sure about impeachment - but I do think that's the most likely outcome is Trump derailing his own Presidency with injudicious remarks. Bill Clinton lost two years of his legislative programme due to the furore created by a comment he made about gays in the military while out jogging at dawn.

I'd say that it's more or less inevitable that Trump is going to say something on Twitter that is going to blow up in his face in a big way. People are able to say all sorts of things when they're running for the Candidacy / Presidency (H Clinton the first time round had several such mishaps). Do that when you're President and there's a good chance you'll run out of political capital before you've managed to achieve anything meaningful.

<comment><USER5> Or he'll do the opposite, as in he'll shoot his mouth off so often people will give up trying to hold him accountable, making him an unpredictable wild card that can pretty much do anything he wants. (In fact I'd say he crossed that point a long time ago.)

<comment><USER4> It's also fair to say the media has gone into full-blown self flagellation these past few days about the job they did holding Trump to account. Whether it will go back to business as usual in two weeks remains to be seen.

</comment></comment></comment><comment><USER6> "This one is not based on a system; it's just my gut."

Just a reporter scraping for a story.

</comment><comment><USER7> I actually think Trump may do his best as president. He may do some really dumb things (really what president hasn't?). Unless he decides to do some really really illegal stuff, he probably won't be impeached. Let's just all hope Trump doesn't hurt us. I doubt Trump's presidency will turn out as bad as many people are predicting.

<comment><USER8> He's egotistic and wants to be the best. Which is great, it means he'll try to be the best President that he can be.

</comment></comment><comment><USER9> The article reports this regarding the source of the predictions:

" _It 's worth noting that Lichtman's predictions use very different methods than pollsters and data-based prognosticators. Some statisticians take issue with the structure of his system, a set of 13 true/false questions, saying that the binary nature of his keys leads to what's called "overfitting," which is basically creating a system that fits the data but has little statistical significance. But Lichtman counters by saying that the system has correctly predicted every election since 1984 (specifically, his predictions have picked the next president correctly in all of those elections but 2000, when he picked Al Gore, who won the popular vote). And Lichtman has his own criticism of data-based predictions._

" _"Polls are not predictors," he said Friday in an email. "They are snapshots that simulate an election. They are abused and misused as predictors. Even the analysis of polls by Nate Silver and others which claimed a probable Clinton victory with from more than 70 percent to 99 percent certainty are mere compilations that are no better than the underlying polls."_

" _And he has particular disdain for prediction systems that assign a likelihood of winning._

" _"For all his acclaim, Nate Silver is only a clerk, not a scientific analyst," Lichtman said._ "

There is no source for the impeachment prediction; that may be pure, but possibly well grounded, cynicism.

The "keys" on which the prediction is based can be found in: [https://www.washingtonpost.com/news/the- fix/wp/2016/05/12/th...](https://www.washingtonpost.com/news/the- fix/wp/2016/05/12/this-professor-has-predicted-every-presidential-election- since-1984-hes-still-trying-to-figure-out-2016/)

</comment><comment><USER10> When enough people are making predictions, a few are bound to be right through chance alone. The same phenomenon occurs with the stock market. The question is, how do you distinguish correct predictions made by chance from those made by correct analytical methods? This task may be as difficult as the original prediction itself.

</comment><comment><USER11> Great, he's using his newfound fame and credibility in one area (a lucky coin toss), to make grand assertions on what Trump's presidency will be like. Where can I buy the crystal ball he is using?

</comment><comment><USER12> I had a similar thought. The GOP establishment is clearly not happy with Trump. If given a serious enough opportunity, the GOP may be willing to impeach their own President, to replace him with Mike Pence.

<comment><USER13> Word on the street is that's actually been the plan all along.

<comment><USER14> That would be a tremendously bad idea. Suppressing popular votes for hope (in this case by poorer people without college degrees) is what causes revolution.

</comment></comment></comment><comment><USER15> The GOP electorate went 90% for Trump.

This would be asking for a coup.

But then I suppose we are at that point in the arc of Empire now.

</comment><comment><USER16> I don't think he has much data to work off to create a model for impeachment.

<comment><USER11> Right, he's clearly just abusing his limelight to make a statement here.

</comment></comment><comment><USER17> Mark Blyth is a professor who predicted Brexit and Trump's victory. If you want a global perspective on these things, Mark Blyth is a very interesting person to listen to.</comment>


Five Ways To Write Better Code - <AUTHOR> http://www.brandonsavage.net/five-ways-to-write-better-code/

<comment><USER2> It is widely recommended that learning a new language will improve your skills with languages you already know, and I've never heard anyone contradict this.

But I've never noticed this in my experience. Moreover, whenever I come back to a language after any time away from it, I'm amazed how much time I spend remembering (or looking up) superficial differences.

Stuff like looking up whether I get the length of a vector with "len" or "length" (for a language I already knew) just feels like a distraction.

<comment><USER3> One thing I'd suggest is to learn a vastly different language. If you use ruby all day, learning python probably won't give you the type of insight that learning C would. Or learning a lisp.

So much is looking at things in a different way, and a quick way to do that is by picking something across the metaphorical language town, rather than the language next door.

<comment><USER4> Exactly. Although I've found it helpful to learn similar languages too (i.e. more than one scripting language). Seeing how subtle differences in the languages play out (beyond the superficial len/length type differences) has helped me understand some of the more subtle concepts of computer science. That said, you probably get the most bang-for-the-buck by picking up a language with a fundamentally different programming paradigm or at a lower or higher level than what you already know.

<comment><USER5> Languages exist to solve certain classes of problems. PHP, for example, is primarily designed as a web language. Learning ANY language designed for other uses will teach the developer something new. Once you have learned something like Python or Ruby, learning C would probably be the next logical step.

</comment></comment></comment></comment><comment> adam-a > 3\. Fix bugs in the open source projects you use.

> I've never taken a hard look at the Apache source code before, but I have > found a few bugs in Apache that I'd love to have fixed

How can you take this advice if the author doesn't even follow it himself? Seems like a shallow recycled piece designed to promote the author's eBook.

<comment><USER6> What's the Apache source code?

You mean Apache httpd? :)

Realize "Apache" means the Apache Software Foundation, which is made up of a large collection of open source projects.

(disclosure: Apache CloudStack contributor and PPMC member)

<comment><USER7> I understand and generally agree with your point. However, if we're going to slide and dice, it should be pointed out that the Apache Software Foundation (founded in 1999) was named after the Apache web server (1995), not the other way around. So, if the context clearly suggests the web server, as it does here, I think he's OK.

</comment></comment></comment><comment><USER6> I've become jaded with "top 5" style lists recently, but this one's pretty nice. I'm doing a few "secure development" training sessions with development teams in the next week, will be referencing this for sure.

I'm not sure writing tests makes you a better developer...gives you better habits, but not sure it results in your code being better, compared to things like fixing bugs in others code and learning a new language.

The learning a new language holds true past software development - when I learned Spanish in high school, my understanding of some of the stranger forms of English (say, past participle) improved.

<comment><USER5> I have to disagree with one point: that writing tests doesn't make you a better developer. Here's why:

Writing a test requires you to think about your code in different ways than just creating it. TDD requires you to plan your code. And the more code you write, theoretically, the better your skills will be.

Now, will it make you the best developer? Probably not. I doubt writing tests is the most productive use of time. But for the practice of software development, writing tests is critical.

</comment></comment><comment><USER8> Also, write lots of code! If you're stuck with legacy-code, start a hobby project that you think might be useful to someone (if you're not stuck with family that is, then there's really no hope).

</comment><comment><USER9> How about getting into the habit of writing tests? First, they're code themselves. Second, it really forces you to think about interfaces and coupling.

Third, it's a nice habit to have if you work on a larger project.</comment>


Morgan Stanley CEO On Facebook IPO: Blame Nasdaq, We Did Nothing Wrong - <AUTHOR> http://www.forbes.com/sites/halahtouryalai/2012/05/30/morgan-stanley-ceo-on-facebook-ipo-blame-nasdaq-we-did-nothing-wrong/

<comment><USER2> From the OP: [http://dealbook.nytimes.com/2012/05/30/technical-trading- iss...](http://dealbook.nytimes.com/2012/05/30/technical-trading-issues-to- blame-for-facebooks-fall-meeker-says/)

An equally interesting read. NASDAQ had some technical flubs, but blaming NASDAQ for FB losing 25%+ of its value in one week is ludicrous.</comment>