What's Lurking in Your Showerhead - <AUTHOR> http://www.newyorker.com/tech/elements/whats-lurking-in-your-showerhead <comment><USER2> "You may have worms," Dunn told me. "There's even some evidence in the Netherlands of little crustaceans."

Ok so I have been living in the Netherlands for 46 years and I have never heard about crustaceans in our showerheads :) I can't find any sources about this on the Internet. Has anybody ever heard about this or is this just nonsense?

<comment><AUTHOR> The presence of crustaceans has nothing to do with cleanliness. New York City also has famously good water, and it has crustaceans: [http://www.nytimes.com/2004/11/07/nyregion/the-waters- fine-b...](http://www.nytimes.com/2004/11/07/nyregion/the-waters-fine-but-is- it-kosher.html?_r=0)

<comment><USER3> _New York City also has famously good water_

Not true! NYC does not have "famously good water". I found that out when I had to change my counter-top water filter after about one year of use.

It was more than gross. Imagine having to drink that water without the benefit of a water filter. By the way, I don't think water people drink in many restaurants are filtered.

<comment><AUTHOR> But couldn't that just be the pipes in your building? The water comes from the Catskills, and when it leaves there, at least, it's extremely clean.

<comment><USER4> The water towers on top of NYC buildings tend to not be maintained especially well:

      With their quaint barrel-like contours and weathered
      cedar-plank sides, rooftop water towers are a constant on
      the New York City skyline. And though they may look like
      relics of a past age, millions of residents get their
      drinking water from the tanks every day.

      But inside these rustic-looking vessels, there are often
      thick layers of muddy sediment. Many have not been
      cleaned or inspected in years. And regulations governing
      water tanks are rarely enforced, an examination by The
      New York Times shows.

[https://www.nytimes.com/2014/01/27/nyregion/inside-citys- wat...](https://www.nytimes.com/2014/01/27/nyregion/inside-citys-water-tanks- layers-of-neglect.html) (warning: autoplay video)

</comment></comment></comment></comment></comment><comment><USER5> "He suggested that the female reputation for making tastier bread may derive from the fact that the skin on women's hands is more likely to be colonized by fermentation-friendly lactobacilli from their vaginas."

This is the weirdest thing I've heard in a while and I wonder if there is even a slight possibility that this is true.

<comment><USER6> As a homebrewer who consumes the end product of microorganism processes, an unexpected infection almost always yields off-flavors that are counted as defects in the beer. That said, there are some beer types that are "spontaneously fermented" by environmental yeasts, that end up with a sour taste as a desirable characteristic, and the rest of the beer flavor profile is crafted to harmonize with it.

I think there is a slight possibility the claim is true, but only for sourdough breads.

</comment></comment><comment><USER7> Apparently the answer is "gross stuff". I didn't see much more usable detail than that in the article?

<comment><USER8> Gross stuff which is actually a collection of microorganisms. And reading further, there's the idea that our exposure to this gross stuff may be beneficial and one of the few ways we're still exposed to it. Or harmful.

Very interesting stuff in my opinion. Have studies like this been made more accessible due to cheaper sequencing?

<comment><USER9> And seeing as our bodies are colonies of microorganisms...

</comment></comment></comment><comment><USER10> Why the focus on showerheads only and not water faucets which people drink much more water from rather than bathe?

<comment><USER11> It's probably the fact that shower heads have so much more surface area for stuff to grow on and live in. One minute it's wet, and then it's drying for the rest of the day. A water faucet is less hospitable to growing gunk.

<comment><USER12> Hmm; I could see it being the exact opposite. The shower head, by drying out after a single daily use, could be less hospitable to organisms that need moisture. Meanwhile a faucet, used several times throughout the day, has areas which never dry completely.

</comment></comment></comment><comment><USER13> You can (mostly) sterilize your showerhead if you want.

Turn up your hot water tank to the highest setting (150F) and wait for it to finish heating, then just run straight hot water for about 10 minutes.

It won't kill everything, but it'll kill most things.

<comment><USER14> It sounds obvious, but this is incredibly dangerous scalding risk if someone else turns on hot water expecting it to be a reasonable temperature while you're doing this. Even if

Much easier to take your fixtures off and bleach/disinfect.

<comment><USER13> > Much easier to take your fixtures off and bleach/disinfect.

You have a very different definition of "easier" than me.

And I don't know about you, but hot water is HOT, and I never use it directly while expecting not to get burned - I always mix it with cold.

</comment></comment></comment><comment><USER15> > He suggested that the female reputation for making tastier bread may derive > from the fact that the skin on women's hands is more likely to be colonized > by fermentation-friendly lactobacilli from their vaginas.

Not really what you want to read while eating sourdough toast.

</comment><comment><USER16> Oh, I thought it was going to be the flow regulators. I keep meaning to remove mine.

</comment><comment><USER17> Click bait or not, now I have to clean my shower head. Thanks a lot! :(</comment>


Surprise Text Message Sent by Google Voice - <AUTHOR> http://dpb.bitbucket.org/surprise-text-message-sent-by-google-voice.html

<comment><USER2> It's the kind of surprise a person has when someone says they're going to hit you if you poke them one more time and then you poke them.

<comment><USER3> It's just another in a long, long line of examples of how the Android permissions model is flawed. iOS has plenty of problems as well, but is much better about this. Rather than a laundry list of permissions when you install, it prompts as the app uses each one, and most importantly, _gives you the ability to deny them in a granular fashion_.

I've heard Google is working on something similar for Android and I really hope it happens sooner rather than later.

<comment><USER4> Cyanogenmod already provides this via Privacy Guard. I wouldn't be surprised if this made its way to the next version of Android; a lot of Android features were in CM beforehand (it used to be a running joke that Google got its ideas for what to implement next by copying the CM developers).

The CM installation process has gotten way easier (you now don't even need to wipe your phone or lose any data - it installs right on top of the stock ROM), so there's really very little reason not to use it over stock if your device is supported, IMHO.

</comment></comment></comment><comment><USER5> After signing in to your google account from the gvoice app, google adds your phone's number and verifies it by sending a text; the message is the following:

"Google Voice will now verify your phone number by sending a text message from your phone to the Google Voice service. You will be charged your carrier's standard rate for text messages."

This happens the first time you log into the app, but it wouldn't surprise me that something similar happens from time to time to verify your phone number, a warning would be nice though.

</comment><comment><USER6> How did he find out that the message was sent?

<comment><USER7> The message was a text sent to his phone, if I read it correctly?

<comment><USER6> Yeah, it sends a message to that number so they can call you back and connect your call, presumably.

</comment></comment></comment><comment><USER8> Although interesting, I'm surprised blog post with so little content is on the front page.</comment>


Go is on a trajectory to become the next enterprise programming language - <AUTHOR> https://hackernoon.com/go-is-on-a-trajectory-to-become-the-next-enterprise-programming-language-3b75d70544e <comment><USER2> What do you mean by 'enterprise'? If you mean an organization in the Fortune 500 whose primary products do not include IT products and services then I seriously doubt it. Java has been #1 on the TIOBE index for the past 15 years. That's a HUGE amount of inertia in tooling, existing application portfolios, know-how, etc. such that Java will probably be the #1 enterprise language for at least the next 10 years. After that it's anyone's guess but odds are it won't be Go.

</comment><comment><USER3> I'm inclined to believe Go would be left to languish as Plan 9 and other projects from Bell Labs are, were it not for the support of Google. Go is certainly designed as other _enterprise programming languages_ are, though, which is to write they're designed to weaken programmer agency.

>Many languages are stronger in individual areas, but no other language scores so consistently well when looking at all of them combined, especially in regards to large-scale software engineering.

I use a number of wildly different languages, including Common Lisp, APL, and most recently Ada; each of these languages is lacking things the other has, but it also vastly more suited to other tasks than the rest. I've never used Go. Unlike these three languages I've mentioned, which have perfectly good reasons for lacking whatever it is they lack, Go very often has poor reasons or perhaps even no reasons, although I don't skulk around the mailing lists or whatnot.

>Go focuses on alleviating these large-scale engineering pains, sometimes at the cost of making engineering in the small a bit more cumbersome, for example by requiring a few extra lines of code here and there.

While reading this article, I've been left to wonder ''Why not Ada?'' and the answer seems to be that Google simply doesn't care about Ada. This is exactly the manner of thing Ada was created for.

>Many people are surprised that Go doesn't contain concepts they love in other languages. Go is indeed a very small and simple language that contains only a minimal selection of orthogonal and proven concepts. This encourages developers to write the simplest possible code with the least amount of cognitive overhead so that many other people can understand and work with it.

A more cynical view is that Go is designed to use programmers as unintelligent implementing machines, which is why it's so opinionated. Its opinions have little or nothing to do with good programs and apparently everything to do with preventing the damage any single fool they want to use can cause or, worse, prevent a new hire who isn't a fool from writing a good program that makes them more valuable than their peers and harder to fire. There's no macros in Go, only the same thing, everywhere, no matter how poorly suited it is to the problem. If everyone writes Go the same, it's easy to fire and interchange employees without friction.

>Good code is obvious, avoids cleverness, obscure language features, twisted control flow, and indirections.

I'd like an example of such ''good code''. Simple code for complex problems is often ''clever'' and may even take some time to understand. This seems to contradict with earlier parts of the article.

>An example is error handling. It would be easier to just let exceptions interrupt code at various points and bubble up the call chain. Go requires to handle or return each error manually. This makes it explicit exactly where code can be interrupted and how errors are handled or wrapped. Overall, this makes error handling more cumbersome to write but easier to understand.

I think Ada does it rather well. The entire point of exceptions is handling _exceptional_ circumstances and it's much more pleasant to have such handling in one place rather than everywhere it can happen. Not only that, but return values can be ignored by accident, which is a major issue.

Now, clearly, avoiding exceptional circumstances wherever possible seems to be the best option, but when that's not feasible, exceptions seem a rather good solution to this issue.

>Go is so small and simple that the entire language and its underlying concepts can be studied in just a couple of days. In our experience, after no more than a week of training (compared to months in other languages) Go beginners can make sense of code written by Go experts and contribute to it.

I'd think Forth is simple. Go doesn't seem to be. There's nothing wrong with new programmers being able to understand expert code, but this does betray that underlying feeling that Go is an attempt to de-skill programming.

A simple language isn't equivalent to a language that is good for writing programs in. Ofttimes, a lack of edge cases in the world of the language doesn't correspond to a lack of edge cases in real use. Take a look at Ada for a counterexample; the rules may not have a nice technical explanation, but the corresponding real world explanation is very simple, because it's usually to prevent some manner of error.

>The different programmers feel more at home in each other's code bases.

A major aspect of ''programming in the large'' is not needing to see other people's code, but just the interfaces to it that are exposed.

>Go was written in the age of multi-core CPUs and has easy, high-level CSP- style concurrency built into the language.

Multiple threads of execution is, again, something Ada has been doing rather well for decades, with its tasks and protected objects and whatnot.

>Taken as a whole, they position Go as an excellent choice for large development projects looking for a modern programming language beyond Java.

Sans the standard library (Does Go actually have a real standard?), every advantage of Go listed seems to reasonably apply to Ada, whereas Ada also lacks many of the disadvantages. Ada can run in a GCed environment, but is also suited to real-time computing, as two examples.

For a good example of my criticisms, take a look at this:

[https://tech.slashdot.org/story/17/01/03/1924218](https://tech.slashdot.org/story/17/01/03/1924218)

It's my understanding Go lacked a proper mechanism for determining time and many people critiqued this, but it wasn't considered an issue until someone important was hit by it. This is a good example of the problems caused by a language that is not only uncustomizable by the users, but is designed by people who don't care and won't care. Unless you're someone, Google doesn't care about what you think and the language certainly doesn't, considering it is designed at every point to take away programmer choice.

As is usual, here's the Rob Pike quote:

''They're not capable of understanding a brilliant language, but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.''

The only ''philosophy'' these things espouse is that the computer isn't a tool for leveraging the mind.</comment>


Dame Vera Lynn has died at 103 - <AUTHOR> https://www.economist.com/obituary/2020/06/27/vera-lynn-died-on-june-18th <comment><AUTHOR> [https://www.theoldie.co.uk/article/we-will-meet- again](https://www.theoldie.co.uk/article/we-will-meet-again)

</comment><comment><USER2> Does anyone remember Vera Lynn?

Remember how she said that we would meet again, some sunny day

Vera, Vera, what has become of you?

Does anybody else 'round here feel the way I do?

</comment><comment><AUTHOR> [https://archive.vn/dh0tu#10%](https://archive.vn/dh0tu#10%)</comment>


Oracle "sanitizes" Hudson's creator from wiki - <AUTHOR> http://jenkins.361315.n4.nabble.com/Hudson-Dev-Can-I-get-my-account-back-td3262992.html <comment><USER2> _Sure, I can fix it. I wanted to catch up with you on IM as we'd like to regain access to the hudson-labs infrastructure as well. There are a few other VMs we're not sure exactly where they are._

Do I read this as, "We deliberately locked you out and removed your attribution, and we hint we can fix things, and we want you to do certain things for us, but no we aren't actually saying we'll fix anything and no we didn't tell you about it in advance?"

Really, I would just walk away from anyone trying to deal with me on this basis. Come out and say what you did and what you're going to do. If you need my help with something, ask, and don't try to hint things are tied together when they aren't.

<comment><USER3> > Really, I would just walk away from anyone trying to deal with me on this > basis.

Agreed, with one exception -- to expose the other side to the public. I think Oracle is showing its face (again) and I think it is in the community's interest to _let_ it keep showing its face.

<comment><USER4> No. If he had started something about Oracle, what would have happened to Oracle? Some redditors and HNers would seize the opportunity to complain about how horrible Oracle is and then everyone would forget about it a few days later. On the other hand, what would have happened to Kawaguchi? Some potential employer could see him complaining publicly about one of his former employers and decide that it's a bad idea to hire him.

In all, there's little good that would come out of it and a _ton_ of risk for Kawaguchi.

<comment><USER3> That is why I emphasized the word _let_. He doesn't have to editorialize their actions and responses. Those speak for themselves. Just share them on his blog -- he is not complaining, he is just communicating to the open source community the state of the Jenkins project. Let others comment and let Oracle damage its own image.

> what would have happened to Oracle?

Well eventually the same thing that happened to SCO ;-)

They are losing credibility in the PR domain even more. This is not directed towards the general public or even Oracle's corporate customers, but towards the hackers, sysadmins, and other tech workers. The opinions of those people matter however, and eventually they will be consulted by those that make purchasing decisions. A general mistrust and dislike of Oracle will take its toll.

<comment><USER5> > Well eventually the same thing that happened to SCO ;-)

Oracle has some very good products. SCO had a Unix nobody wanted anymore (at least, nobody with two or more neurons).

<comment><USER3> For a while they had a Unix some wanted and nobody thought at the time that there will be a free better Unix variant one day. Then GNU/Linux came along...

<comment><USER4> Yeah, but Oracle's GNU/Linux came a long time ago in the form of MySQL and Postgres.

</comment></comment></comment></comment></comment></comment></comment><comment> brown9-2 Some recent tweets from Jazon van Zyl make it sound like he's holding Kosuke's request hostage:

 _This wasn't anyone at Oracle. It was me after a preliminary infrastructure audit, it's not malicious or permanent._ <http://twitter.com/#!/jvanzyl/status/34413629902168064>

_This is my request to @kohsukekawa (<http://bit.ly/fXsvd7>) to air everything in a conversation that everyone can see_ <http://twitter.com/#!/jvanzyl/status/34413629902168064>

So in other words... let's have an IM chat for questions I have about the core architecture of a project you built, and then I'll restore your account?

<comment><USER6> His second reply on the thread sounds even more like he's holding the account hostage:

[http://jenkins.361315.n4.nabble.com/Hudson-Dev-Can-I-get- my-...](http://jenkins.361315.n4.nabble.com/Hudson-Dev-Can-I-get-my-account- back-tp3262992p3263520.html)

</comment></comment><comment><USER7> This shouldn't be surprising at this point. Everyone should know by now that Oracle doesn't give two fucks about anything other than making money.

<comment><USER8> I happy that Oracle's goal is to make money, but they seem to only care about doing so in the short term. How much goodwill has Oracle blown with influential technical folk over what is really a very minor piece of software in the grand scheme of things? How much harder will it be for Oracle to promote a new technology/standard/whatever if the first thing everyone's thinking is "How are they going to screw me?"

<comment><USER9> This is what I do not get about Oracle. Are we (tech influencers, i guess) all commie hippies that can't make a damn difference at all to their long term business?

Because the answer is either yes or no, and if there is a good possibility that it is no (Oracle's behavior is long term financially detrimental) you might think shareholders would care. But I do not see $ORCL shareholders marching in the street in protest about the apparent pillaging of the company's future. Where are the pitchforks?

<comment><USER10> See rst's comment. $ORCL doesn't sell "technology". It sell's a "Business Solution".

// Which in itself is generally a good strategy for most startups to emulate.

<comment><USER9> This is effective in the short term, yes. But "businessmen" do not create the future, they sell (or buy) the present. And the people creating the future are almost entirely aligned against the Oracle ecosystem.

<comment><USER11> The next generation of business leaders for most companies is inthe same meetings with Oracle's salespeople. They will pick "solutions" for business over their IT staff's opinion. Oracle thinks like them, the IT staff doesn't.

</comment></comment></comment></comment></comment></comment><comment><USER12> Considering that the person who responded to Kohsuke is Jason van Zyl, creater of Maven, and not an Oracle employee as far as I know, I have to question the title of this story.

<comment><USER13> It appears van Zyl is with Sonatype, a company working with Oracle to continue Hudson under its original name:

[http://www.sonatype.com/people/2011/02/hudsons-bright- future...](http://www.sonatype.com/people/2011/02/hudsons-bright-future/)

<comment><USER3> Fantastic excerpt from it

\----

The Hudson lead, Winston Prakash from Oracle, is highly skilled, very thoughtful, and he cares about the community. He is also the first person to create detailed, comprehensive architectural documentation.

\----

So now the main accomplishment of the current project lead is writing detailed documentation. Those that can - code, those that can't - write very detailed documentation. Yeah, I think I'll stick with Jenkins...

<comment><USER14> >> So now the main accomplishment of the current project lead is writing detailed documentation. Those that can - code, those that can't - write very detailed documentation.

So we're now running people down for decent documentation? Seriously?

<comment><USER15> No, we are looking for a pretext to run down people who work for Oracle.

<comment><USER3> Because Oracle is behaving like bully we don't need much of a pretext.

<comment><USER14> Then go with that rather than picking on people for basic good practice.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> If this was just an honest mistake, the response should have been worded differently.

At this point, perhaps the account problem could be fixed immediately, and then a separate discussion started to address the hudson-labs issue. To do otherwise seems unnecessarily infantile.

<comment><USER16> ...assuming there really is any 'issue' on either side here, that is.

<comment><USER16> ...and reading through things, I guess there is. Awful.

</comment></comment></comment><comment><USER17> Ah yes, Oracle is carrying on the grand tradition of Pharaohs, ancient Rome's _damnatio memoriae_ , and Stalin's Great Purge.

</comment><comment><USER18> The removal was done by a Sonatype employee; company which could be potentially more vulnerable to this tactics as their products are subject to be chosen by developers. I would think twice before buying them a product after this.

<comment><USER19> Since Sonatype's offering is centered around Maven, you should think twice regardless of this issue and then look for something better (gradle or buildr, for example, or the old reliable ant).

</comment></comment><comment><USER20> I'm confused. Based on the second entry in the thread, it sounds like it was just a mistake. Am I missing something?

<comment><USER21> The response is bringing that into question. It sounds like Oracle is holding his account hostage.

<comment><USER5> Why would Oracle keep his account with full functionality _after_ he left the company, badmouthed it, and started a fork of the product the company paid him to develop?

I agree removing his name was dumb, but it could be an unpredicted side effect of modifying the account.

</comment></comment></comment><comment><USER22> The original thread [http://jenkins.361315.n4.nabble.com/Hudson-Dev-Can-I-get- my-...](http://jenkins.361315.n4.nabble.com/Hudson-Dev-Can-I-get-my-account- back-td3262992.html)</comment>


Secure your Docker container image and minify it by up to 30x - <AUTHOR> https://dockersl.im/ <comment><USER2> [https://news.ycombinator.com/item?id=21755871](https://news.ycombinator.com/item?id=21755871)

</comment><comment><AUTHOR> I don't yet now how this works, but for me it reduces a 900Mb image to 300Mb, very cool.

<comment><USER3> for Node.js a yarn cache clean or npm prune --production in your docker file does a lot already</comment></comment>


MtGox salted passwords cracked - <AUTHOR> http://pastebin.com/NDm7XihA

<comment><USER2> i suspect some people here don't really know in any detail how password cracking works.

you start with a dictionary. a good dictionary combines multiple passwords, slang, common patterns of keys on the keyboard, and old, known, passwords (so all the entries here will be added, for example).

but that's just the start. the cracking programs also have rules. in simple terms these can be "shift to upper case" or "combine two words from dictionary" or "reverse word" or "replace "e" with "3". and there are common sets of rules that people develop (and test) that do standard transformations like automatically making passwords "leet", or extending with common sequences (123), etc.

and you can automate this. so something like hashcat will generate _random_ rules and apply them to the dictionary. because the rules are written so that they can be composed this is surprisingly powerful and probably explains some of the "harder" cracks on this list.

the only way to beat this, then, is to use random passwords (for example, as generated by keepass) and to make them large enough that just running through every combination doesn't work.

on size: what is important is the number of available combinations. systematic cracking - trying every possible combination - still uses common characters first so "size" is a combination of character variety _and_ number of characters. again, something like keepass makes this easy.

finally, note that on some old or poorly maintained systems, you may be restricted (perhaps without knowing) to 8 characters. then using a wide range of characters is _critical_.

i know this is obvious to many, but some of the comments about "hard" passwords made me think it might be useful...

<comment><USER3> I have a tangentially related question. During this LulzSec situation, I stepped into 2009 and started using LastPass. I generated 16 character random passwords for every place that I've been visiting. As I understand it, these passwords are encrypted on my machine and then uploaded to LastPass servers. When I login with my master password, I have access to all of these passwords unencrypted.

My question: is there an intrinsic weakness in storing these passwords at a central location? E.g. would it be feasible that LastPass gets targeted by a complicated blackhat attack, and then instead of losing just one of my passwords I lost them all? Or is the manner in which they are encrypted and transmitted secure enough to prevent this?

Thanks.

<comment><USER4> Yes, it is. Use 1Password or KeePass because they aren't centrally hosted. 1Password even provides a little security through obscurity by using DropBox for its optional keychain syncing. People store a lot of uninteresting crap on Dropbox, filtering through to gather .agilekeychains would be a real PITA.

<comment><USER5> If only there were a device that could automate computational tasks, such filtering would no longer pose a challenge. Some sort of compute-er...

<comment><USER4> If it was simple as filtering for those files, you would have a point. It's not though. If you can't see the difference between a big compiled database of 1 million+ users password DBs vs a multiple petabyte mess of all types of files including a handful of agilekeychains, then it's not worth discussing further.

</comment></comment></comment></comment></comment><comment><USER6> So the entire user community is people with lots of hardware resources waiting to brute force passwords. What could possibly go wrong? :-)

</comment><comment><USER7> A few people seem to be commenting that the salt used for all of the passwords is the same.

This is not the case.

These are crypt(3) strings and the $1$ at the beginning signifies the _hash scheme_ used, _not_ the salt--$scheme$salt$hash. The 1 means that FreeBSD-MD5 is the algorithm used, which is basically MD5 with the salt iterated 1000 times.

<comment><USER8> Your comment that this is MD5 x 1000 is very informative and got me searching for the FreeBSD MD5 crypt function, and I found this gem from /usr/src/lib/libcrypt/crypt-md5.c:

       /*
       * and now, just to make sure things don't run too fast
       * On a 60 Mhz Pentium this takes 34 msec, so you would
       * need 30 seconds to build a 1000 entry dictionary...
       */
        for(i = 0; i < 1000; i++) {
          MD5Init(&ctx1);
          if(i & 1)
            MD5Update(&ctx1, (const u_char *)pw, strlen(pw));
            ...

... which seems to still be the default implementation in FreeBSD. I'd guess it's time to increase the iterations to 200000.

<comment><USER9> Ease of increasing how long it takes to compute the hash is the main idea behind bcrypt: <http://codahale.com/how-to-safely-store-a-password/>

<comment><USER10> Yeah, it's pretty easy to change this in Devise, a popular auth library for rails that uses bcrypt by default, and to have a custom value to speed up unit tests: [https://github.com/plataformatec/devise/wiki/Speed-up- your-u...](https://github.com/plataformatec/devise/wiki/Speed-up-your-unit- tests)

config.stretches = Rails.env.test? ? 1 : 10

</comment></comment></comment></comment><comment><USER11> A lot of them are just 6 characters. Even a random 6 character password can be brute forced in a few minutes. Many of the short ones were just single dictionary words, so wouldn't even get past the initial check for stupid passwords--they would fall in seconds.

Most of the longer ones seem to be simply combinations of a couple dictionary words, or a word and a number, or similar fairly low entropy combinations that would come early in a brute forcer's search.

Most of the ones that aren't like that are based on simple patterns on the keyboard, which would also be in a brute forcer's list of things to check early.

</comment><comment><USER12> This is a brute force / dictionary attack. Only "bad" passwords have been cracked.

My password isn't on the list—it's a randomly generated 17-char string of alphanumeric and mixed case character.

Btw, you should all check out 1Password. Automates the process, syncs with all my devices and dropbox, and integrates with all the major browsers.

<comment><USER13> It looks windows-only. Not going to work for me.

<comment><USER14> <http://agilebits.com/products/1Password>

Mac is the first platform listed.

<comment><USER15> Looks great but no Linux support. Since I use Ubuntu on my work (and home) laptop and netbook, this is largely useless for me.

KeePassX + Dropbox is a great way to go, but it's kind of more "DIY"-ish. Still not hard to set up, keeps all my passwords in sync, and KeePassX has some great features like "auto-type" which basically is a one-click website login.

I now use the max-length passwords on all the sites I use, and they're all crazy random ones. I don't memorize any of them because it's so easy to reset a password if I lost my KeePassX access (unlikely since it's on Dropbox + 4 computers + CrashPlan backups).

</comment></comment></comment></comment><comment><USER16> Hot damn some people have horrible passwords:

123456 -> 199 results. password -> 118 results.

Who would use such weak passwords for an account with potential monetary value?

<comment><USER17> On occasion when signing up for an account that I'm just testing out, I don't feel like creating a random password for it, so I just use a simple one. If it turns out I want to use the service, I will change it to a more complex one. This could be what happened here.

</comment></comment><comment><USER18> What you mean is that the ridiculously easy passwords have been cracked? Not really a surprise considering they have been out for so long.

While I'm glad I do not have a account there they would not have been able to crack my password :-)

Edit:

I am a fool, salted hashes are probably not in anyones rainbow tables :)

<comment><USER19> Rainbow tables do not exist for randomised salts.

<comment><USER20> But if the salt is global and its value is "1", it might.

<comment><USER21> The $1$ part of the hash is purely to indicate that MD5 was the encryption algorithm used. The salt used is the first 12 characters, so from "$1$" to the next "$"

For example, for "$1$JVf3ep..$uvo634QwxDsAuHMOZlKws1:riprip" the salt is "$1$JVf3ep..$" (although those periods may just be padding, IIRC).

<comment><USER20> Ahh. I misunderstood. Thanks.

</comment></comment></comment></comment></comment><comment><USER22> I take it straight up dic attack, i see no gen password with 32 chars in it. Guess this teaches you a lesson, 32 character generated password (or max pass size) as a requirement for 99% of sites. Now if only windows had a standard password storage API which programs can access using special rules and special admin programs can manage this way just like the web browser we can have password stores for windows + sync to cloud.

<comment><USER23> Does Windows not have something equivalent to OS X's keychain?

<comment><USER24> Windows does have a password keychain (and has since XP), but AFAIK the only programs that use it are Microsoft programs. Internet Explorer uses the Windows keychain to store saved passwords.

</comment></comment></comment><comment><USER25> What kind of impact would having used something like sha-512 with a 128 bit salt have had over md5? How many more cycles do those take to generate? I assume the attacker had to brute force the salt from a known password as well, if that's sufficiently random that should provide some security as well shouldn't it?

<comment><USER26> I'm pretty sure this article[1] is posted daily on HN. General purpose hashing functions are all _fast_ (which, for a password storage system, is synonymous with _bad_ ).

[1] <http://codahale.com/how-to-safely-store-a-password/>

</comment></comment><comment><USER20> Hmm it isn't complete; My password isn't on there yet. =\

<comment><USER27> Well, considering that 292 of the passwords contain mixed case, 79 of them are 12 characters or more (this one's nice: "qwe123QWE!@#"), 59 of them contain non-alphanumeric characters, and 6713 of the 8655 passwords posted are unique ... it's probably only a matter of time.

Nice. I think it's time to upgrade all my passwords.

<comment><USER28> "qwe123QWE!@#" is only nice until you look at the keyboard. First three qwerty letters. First three keys just above them. Then the same shifted.

<comment><USER29> I was surprised at how few randomly generated passwords there were in that list, if any. Like you mention, there's a lot of variants on qwerty/12345/!@#$%: 1qaz2wsx, Zaq1Xsw2, 1qazxsw23e, 1q2w3e, !@#$1234, etc.

"ZXasqw12!@" was about as random as it got from a quick scroll-through, and even that is basically just keys directly next to each other.

I assume randomness doesn't mean as much as sheer password length does when it comes to crackability, but I wonder if there's anything to be learned from this. Maybe only that random password generators tend to default to a safer (longer) length? :)

<comment><USER30> Random passwords are probably not going to be cracked by a run-through of John with a ruleset, which is likely similar to -- or exactly -- what was used to create this list.

These are salted FreeBSD MD5s (iterated hash); even with a powerful GPU, you're probably only going to be able to check a few hundred thousand per second at best.

</comment></comment></comment></comment></comment><comment><USER31> Anyone have a bitcoin exchange recommendation?

<comment><USER15> Tradehill is the new MtGox. They even copied the site design pretty much exactly.

</comment></comment><comment><USER32> My password isn't on that list, but it's on a different list. I found it by googling my email address. :/

<comment><USER23> I wonder how many people google their password to check if it's been cracked.

<comment><USER15> Yeah dude, mine was on the bigger list. It's a 10chr semi-random password (all lower case tho).

I pick passwords based on easy things to type and the memorize the pattern / commit it to muscle memory. I also try to use obscure but pronounceable patterns somewhere in the pass.

</comment></comment></comment><comment><USER33> neither of my accounts are in the list, because i used long random passwords

this list is just the low hanging fruit

</comment><comment><USER34> Couldnt find mine.. thats a comfort. =) Unfortunately most web based system ive encountered has 20char as most for key. My new passphrase model is based on 128 char key using two values piped through sha512. It works... but friendface probably wont accept it :)

</comment><comment><USER35> Could someone help this newbie understand why proper salting doesn't make this hard enough? And how does the cracker know they have the right password? Wouldn't they need to check it against the authentication mechanism or figure out the algorithm?

<comment><USER36> If the crypto method being used is strong enough, then there is no need to obscure the authentication algorithm or the salted value. That just provides a little bit of security through obscurity, it doesn't actually harden the passwords anymore. Thus, modern password hashing libraries just put the algorithm and salt information in the password string itself, so that the string of data you store in the database contains 3 pieces of data: The algorithm used to hash the password, the salt, and the password hash. The benefit of this is convenience: Different platforms/languages can all create/authenticate various password hash types with ease as long as everybody sticks to this format.

And because of this, if you choose a weak crypto method to hash your passwords (which is what MtGox did), then an attacker conveniently has the 3 things they need to attempt to crack the password: The algorithm, the salt and the hashed value all in the same place.

However, if a strong crypto is used (IE a computationally intensive and slow hash), then the fact that the algorithm, salt and hashed value are in the same place doesn't really weaken the passwords. With an expensive enough hash, even if the attacker has all the information about how to crack the password right in front of them, actually performing the necessary computation would be so expensive that a brute force attack is effectively protected against.

You can see more details about the format of the password strings and where the 3 parts of data are stored here: <http://php.net/manual/en/function.crypt.php> (the PHP page had the best explanation of my quick search, though this isn't just PHP specific)

</comment></comment><comment><USER37> What about public-private key authentication ? Isn't this demonstration enough ?

</comment><comment><USER38> the salt seems to be the same for all of the password. Not exactly useful this way, is it?

<comment><USER39> The purpose of salting is to prevent the use of "rainbow tables" (precomputed hashes). With salted passwords, the attacker has to compute the password hash for every password he tries (takes time), he cannot use pre-computed hash tables and just compare the password hash to the precomputed hashes (a simple string compare).

Using one salt defeats rainbow tables. Using multiple salts does not defeat it any better.

Using multiple salts would seem to help defeat brute forcing or dictionary attacks, but that is only true if the salts are secret... the problem is that they are _not secret_ because the at this point the attacker access to everything, including the salts.

<http://en.wikipedia.org/wiki/Salt_%28cryptography%29>

<comment><USER40> I accidentally up-voted parent, so felt I had to reply since this part is somewhat wrong:

> _Using multiple salts would seem to help defeat brute forcing or dictionary > attacks, but that is only true if the salts are secret_

If I have a dictionary of common passwords, I need to hash this with the salt used by MtGox and then I can test the hashes against _all_ the passwords from MtGox.

Had they used a different salt for each password, my work would be _n_ times as expensive ( _n_ being the number of passwords to test against).

<comment><USER39> Using multiple salts makes it more expensive, but it doesn't _defeat_ an attack unless it makes the attack impossibly expensive. My contention is is that multiple salts _by themselves_ will not make the attack impossibly expensive.

Better encryption, e.g. bcrypt <http://en.wikipedia.org/wiki/Bcrypt> attempts to make it impossibly expensive to crack passwords. Part of their technique is to use per-password salts to increase the time for _all_ passwords, but the key is to have an encryption algorithm that takes an "impossibly" long time _per password_ as well. Key is that it is "an adaptive hash: over time it can be made slower and slower so it remains resistant to specific brute-force search attacks against the hash and the salt."

Rainbow tables are O(1). Salts are O(n). Bcrypt is O(big), where "big" can be increased to keep it bigger than a "practical" attack will be willing to attempt.

<comment><USER41> Given that the bitcoin protocol adjusts the difficulty of block generation, it's kinda ironic that mtgox didn't use bcrypt.

</comment></comment></comment></comment></comment><comment><USER42> Here are the plain text passwords combined with their respective mail addresses: <http://pastebin.com/RhheV8Gj>

<comment><USER43> I guess you can argue that no more harm can be done to the poor users of Mt. Gox but I disagree.

Why would you post this? If someone really wanted to pair them up, they could have but that at least would have taken -some- determination.

Obviously you knew you were pushing it since you even went out of your way to create a new handle. For the "lulz"? Troll.

<comment><USER44> some determination? it's one invocation of john to pair them up.

releasing the cracked passwords at first was stupid and doesn't show any skill. it only shows that you have a strong cpu.

<comment><USER26> > cpu

Consumer-grade GPUs are better at this than even the highest end CPUs.

<comment><USER44> no shit?!</comment></comment></comment></comment></comment>


What would happen if you tried to hit a baseball pitched at 90% speed of light? - <AUTHOR> https://what-if.xkcd.com/1/ <comment><USER2> If the batter swings and is hit by a pitch its a dead ball and its a strike. If the pitch was in the strike zone then it would also be a dead ball and a strike. Otherwise If the ball hits the batter first it is a hit by pitch, if it hits the bat first its a strike. Lastly, If the batter hits the ball with one or two feet outside of the batters box he is out.

<comment><USER3> Welp, since the batter didn't move, and parts of the ball are exploding out in all directions, the nearest thing to the incoming ball-cloud would be a piece of the batter. So I'd say he's right. Hit by ball.

</comment></comment><comment><USER4> I'm convinced this wouldn't happen. At this speed, only direct collisions of nuclei would do anything. The ball would pass through the air and bat as if they weren't there... and I don't believe it would deposit an appreciable amount of energy at any particular place...

If you think I'm wrong, just think about how far high energy protons (cosmic rays) travel through our atmosphere before they lose their energy. Each atom of the baseball has a good probability of flying through the air for a substantial distance before interacting with anything at all.

</comment><comment><USER5> A number of years ago I read an idea (I think it might have been in James S.A. Corey's Babylon's Ashes) that I find very compelling; any object becomes a weapon given sufficiently high velocity.

</comment><comment><USER6> Randall's book "What If?," which is a collection of these absurd hypotheticals, is for sale on Amazon for $3 right now. I've got it, it's a fun read.

Edit: I should add that it's the eBook.

</comment><comment><USER7> And this is why I read xkcd. I salute you Randall

<comment><USER7> Also, I believe since the batter will have left the plate before being hit by the ball, it would be considered a strike... Or a ball, if no part of the ball makes it through the strike zone.

<comment><USER3> Ah, that's interesting! Would the X-Ray cloud be sufficient to completely blow the batter out of the box before any part of him is hit by the ball-cloud nanoseconds later? I expect some piece of batter is going to be hit by some matter that originated in the ball, within the batter's box.</comment></comment></comment>


What All the Major Surface Warships of the U.S. Navy Do - <AUTHOR> https://foxtrotalpha.jalopnik.com/heres-what-all-the-major-surface-warships-of-the-u-s-n-1832410625 <comment><USER2> "But can they sink ships?" \- This part seems a bit strange. While I agree that most surface ships don't carry anti-ship missiles, it seems like there are plenty of carrier based aircraft capable of launching their own anti-ship missiles, kind of like these being developed:

[https://www.gpsworld.com/u-s-navy-air-force-order-anti- ship-...](https://www.gpsworld.com/u-s-navy-air-force-order-anti-ship- missiles-from-lockheed/)

The exocet (certainly not a new anti-ship missile) can also be launched in flight:

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

</comment><comment><USER3> I realised why I hate such pieces: It's fanboyism.

In reality, the most recent conflict is/was against the Taliban/Al Quaida/randoms grouping, right? The Taliban's navy is no match for the US Navy, but the Taliban won against the US anyway. The previous was perhaps against those Somali warlords, who also beat the US. The US had better weapons, but the Somali found a near-suicidal tactic that eventually made the US cede. Around the same time, Saddam didn't exactly win but he didn't exactly lose either. Before that, Hezbollah forced the US out of Lebanon. The US had more bombs and weapon systems, but the Hezbollah had enough bombs and good- enough ways to deliver them.

This piece doesn't seem to even try to relate the warships and their abilities to any of these four conflicts. Fanboy crap.</comment>


Soviet scientists tried for decades to network their nation - <AUTHOR> https://aeon.co/essays/how-the-soviets-invented-the-internet-and-why-it-didn-t-work <comment><USER2> The Cybernetics angle is really interesting. I thought the Chilean Cybersyn project -[https://www.theguardian.com/technology/2003/sep/08/sciencene...](https://www.theguardian.com/technology/2003/sep/08/sciencenews.chile) \- led by Stafford Beer was an isolated case, but apparently not. An even more distant angle: I just read the autobiography of David Hilbert, and apparently he thought Norbert Wiener was an fraud of some sort. Cybernetics, Systems Science, Complex Systems - these draw a certain type person, and apparently a type of political system, too.

</comment><comment><USER3> This is a fantastic writeup. this quote really struck me and seems very apt to today:

'Glushkov's story is also a stirring reminder to the investor classes and other agents of technological change that astonishing genius, far-seeing foresight and political acumen are not enough to change the world. Supporting institutions often make all the difference. '

<comment><USER4> And:

"There is an irony to this. The first global computer networks took root in the US thanks to well-regulated state funding and collaborative research environments, while the contemporary (and notably independent) national network efforts in the USSR floundered due to unregulated competition and institutional infighting among Soviet administrators. The first global computer network emerged thanks to capitalists behaving like cooperative socialists, not socialists behaving like competitive capitalists."

<comment><USER5> Yet mobile networks flourished in heavily regulated Europe, largely due to enforced standardization, years before they became ubiquitous in the USA.

I worked in the Mobile industry in the late 90s. I remember being on a bus in Madrid airport taking us to our plane. Some young Spaniards were talking loudly on their mobiles while the two American tourists sitting near me gaped at them. One turned to the other and said 'Those things are everywhere. They use them all the time.' It was probably just a brief period of time, but I found it striking.

<comment><USER6> Look up the OSI standards. They were a horror to implement and use.

The telecom companies wanted those to be used instead of the US tcp/ip stack. They would have had much more control and could have been fat cats, taking a large piece of the slice.

Be damn happy they failed. :-)

A heterogeneous world is an advantage, it gets harder for oligopolies to charge at every gate.

<comment><USER7> There was a substantial overlap between the then Internet Activities Board and the committees associated with ISO/IEC 7498, and it was far from dominated by telecomms companies at the time. Indeed, Lyman Chapin of BBN was in ca. 1992 the chair of both! Other overlappers included Christian Huitema and IIRC Dave Katz.

The OSI reference model itself originated with Charles Bachman (Honeywell, then IBM).

So far, no telecomms companies to be seen.

Telecomms companies and agencies were more interested in EDI in the form of X.400(84) and to some extent X.500 directory services, rather than in the lower layers, and while they were heavily invested in X.25, they were not the biggest pushers for the connection-oriented lower layers -- there were plenty of private X.25 networks operated by government agencies (including many non- PTT ones; bear in mind that the CCITT of the time was national governments represented by their local postal-telegraph-and-telecommunications ministries; the U.S. and Canada were huge outliers in having privately owned commercial telcos). There were also research & education networks with X.25 underneath, including CSNET (largely based in the USA) which was definitely part of the TCP/IP-speaking Internet.

OSI's problems weren't in the people involved or in the (admittedly heavy) formalisms that go into ISO/IEC/CCITT/ITU standards, but rather that the idea was to redo TCP/IP "right", and that included supporting difficult to reconcile goals, like supporting both connection-less and connection-oriented protocols in most of the lowest of the 7 layers, and then mechanisms to provide interoperability between CO-only and CL-only talkers.

At the time, well before FPGAs and ASICs were accelerating routers, and when megabytes of RAM were expensive (and slow), OSI appeared too heavyweight compared to TCP/IP, and that is one of many reasons TCP/IP won. OSI reference implementations were expensive rather than free as in beer (sort-of); compiling up your OSI elements took considerably longer; an OSI-equipped kernel was fat (too fat if it was only really talking ES-IS and nothing else); and so forth. SMTP/TCP/IP was what members of the OSI subcommittees were using to communicate with one another, in spite of the existence of EAN for X.400 and some native OSI CLNP (AlterNet, UUNET's internetwork, in the very early 1990s carried real CLNP traffic between RAND and several other organizations).

Internet protocols did benefit from the OSI development work; good ideas from IDRP found their way into BGP4; IS-IS is still the IGP of choice for some large IP networks; LDAP, SNMP and others absorbed good ideas from X.500 and EFTAM; and of course DSL and OTN systems have a lot of OSI in their DNA.

Finally, the U.S. government's GOSIP and similar programmes for mandatory adoption of OSI networking elsewhere probably doomed OSI networking much more than politics (and personality conflicts) among people involved in actually making the standards in the various bodies, both international (and national) and in the IETF and its close relatives. Taking profile "short cuts" to roll out OSI networking rapidly in that way raised the real possibility of fully conforming OSI networks (and stacks) that would nevertheless be mutually incompatible!

Unfortunately many of the lessons learned in the failure of OSI networking were not applied in the process of choosing and standardizing a successor protocol for IP, and here we are a couple decades later with IPv6 being a compromise specification designed for speed of roll out... (In fact some of the wrong lessons learned in the very early 1990s of OSI networking are in IPv6 today: the expectation that being CPU constrained, routers must deal with relatively short, fixed-length, fixed-format fields (rather than, say, something self-describing) is front-and-centre in IPv6 addressing and headers generally. Concerns about overheads are also well-reflected in IPv6, and for terrestrial applications, those concerns were obsoleted by the turn of the century.)

"A hetereogeneous world is an advantage". Well, try explaining that on the IETF mailing list as a reason to support concurrent development of a successor protocol to IPv6.

<comment><USER6> Exhaustive, informative and insightful. Please don't write that stuff were people won't see it. :-)

(I'd add that X.25 was moved into the OSI standards, btw. But you certainly know that.)

But you agree with my point that you couldn't really implement all those protocols in a serious manner, at least not at the time. You saw specifications of buffer counters that were "infinite". OK, that is possible to implement -- and today maybe even efficiently.

Also, the ones pushing this were states and big corporations, typically telecom. The exact details motivations you seem to know more about, but you don't really touch it? The academic world felt pressure to conform and go OSI instead.

(I would argue that with IoT, protocol/processing overheads might again become an issue on Earth and outside of instruments in the oceans?)

<comment><USER7> Weirdly there was shortly after this, and totally coincidentally (since as you may suspect, nobody involved has seen my previous comment) a number of old grey beard networkers were having a discussion about what happened to OSI on a social media platform, and two observations stood out. Firstly, before Marshall Rose et al.'s ISODE there was no free-as-in-beer OSI networking implementation for any platform. Typically OSI networking was available at extra (and high) cost, and the official standards documents were both expensive and tightly access-controlled. Secondly, ISODE itself took a very long time to download and build even on the fastest platforms of the time. By comparison, UNIX systems were already talking TCP/IP out of the box (not quite "free", after all this was before the BSDI lawsuit) and RFCs were readily available and distributable, so free in most senses.

Telecomms companies were at the time largely state-owned agencies; deregulation and privatization were only happening in the UK and Sweden, and only by accidents of history did the USA and Canada have private for-profit companies doing telecomms business (and even in parts of Canada there was partial government ownership). Most of Europe still had monopoly incumbent carriers, state owned, and often directly part of (or even the whole of) the postal & telecommunications ministry. While some management may have been profit-minded, most of them were geared towards resisting competition, even mutual competition, until DG4 (now the Directorate-General for Competition) effectively forced open cross-border markets within Europe in the name of the single market in 1996-1997. Internal competition took longer in most member- states, and rules on state subsidy forced most of the PTTs to spin off their telecommunications (and postal) operations (one could hardly call them businesses in many cases) into separate entities with outside shareholders. That's when greed set in. :-) Before that it was merely monopoly pricing, terrible cost control, and long term views on investing in new technologies (do it slowly, because the old equipment has not yet been fully depreciated!).

By way of counter-example, at least one large U.S. telecomms company was actively supportive of TCP/IP, hosting an early IETF, and so forth, while still participating in OSI and other non-TCP-related networking standards bodies, including the ITU/IEC/ISO (however it is formally the U.S. State Department which attends the meetings; operators are invited to sit with and brief the full-time civil servants; this model is how ITU-T continues to operate, even though there is now no European or North American telecomms company with significant state ownership).

Moreover, the member-states of the international bodies were not really pushing OSI, they were facilitating it. Again, full-time government officials would be the formal attendees, but they would bring along academics and researchers from public and private institutions. The OSI networking process was deliberately a "smushed" together cooperation among several standards bodies, so that rather than say ANSI and its non-USA counterparts attending an ISO meeting, "the network nerds" could actually all meet together as peers and carry on work informally via (funnily enough) email mainly transported by SMTP.

Certainly some of "the network nerds" were working with large technology firms with vested interests in particular technologies -- IBM comes instantly to mind -- but they were a diverse bunch, much as in the IETF became (ignoring issues of number of IETF meeting attendees, which became large). Fronting for one's company happens, and the ISO/IEC processes were initially designed to avoid that. Indeed, there remains tension in the IETF about whether participants are supposed to be individuals or acting directly in the interests of their employers.

I agree with you that there were some crazy ideas in the OSI networking protocol suite, and there are good reasons to pick on CLNP as a networking layer in particular. However, I think that had the standards been freely available and redistributable like RFCs, and there was wider involvement early in the drafting process, both the Internet suite of protcols and OSI's would have improved, and likely converged substantially. Likewise, the ability to tinker with OSI networking even on hefty workstations or minicomputers arrived much later than things like Phil Karn's KA9Q NOS for personal computers(for example). There _was_ effort to try to make a lighter-weight ISODE, and it made some progress [0] but it was very late to the party, and was not obviously better than TCP/IP, so it was no more likely to be rapidly adopted (except by serious enthusiasts) than IPv6 was for its first dozen years...

The international standards bodies vs IETF-and-relatives story became very different a few years later, although not about OSI networking as such, but rather about how to do "broadband ISDN", with the general idea being that a stack of protocols built for ATM (which still sees wide use and utility in the last mile in DSL) should replace IP. ATM standardization was a mess with differing interests, and yes there was tension between the PTTs, computer networking academia, the radio & other wireless broadcast sectors, and so forth, and there are many compromises baked into the ATM standard suite at various layers. Moreover, there was telecomm-vs-telecomm conflict, and conflict among various equipment vendors. Additionally, ITU-T began its long civil war among fully commercialized telecomms agencies (with strong lobbyists convincing their governments of their rightness) versus government monopolies, particularly in the developing world. The latter didn't particularly dislike TCP/IP, they simply wanted to avoid losing the phone call termination fee scheme that in many countries were a noticeable portion of overall foreign earned income.

The processing overheads in networking today, for end systems, is almost wholly encryption and decryption in terms of energy and latency. It is likely that specialized low-energy implementations will arrive before anyone can define what "IoT" means at least as well as the UK Prime Minister defines Brexit. :-) Meanwhile, low-power systems can adopt strategies like talking more slowly or using slower but lower-power-consuming implementations of algorithms; TCP will properly throttle if a "Thing" is much slower than its counterparties (that's part of what TCP is for!). Even terrestrially there are remote end systems which are stuck talking mere hundreds of bits per second, and the Internet suite of protocols mostly scales down to those speeds (in part since many of the protocols started near there).

Consider that in 1993 the IETF rejected the use of a simple CRC in the IPv6 header on the grounds of processing cost and byte overhead, and that in 1991 people preferred SLIP to PPP because of the latter's overheads. I don't think they could honestly have been expected to imagine AES-NI or lz4 or the like managing hundreds of megabytes per second throughputs on personal computer grade equipment, but even at the time such "savings" decisions seemed shortsighted ...

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> "The distributed network was originally designed to nudge the US ahead of the Soviets, allowing scientists' and government leaders' computers to communicate even in the event of a nuclear attack. "

[https://aeon.co/essays/how-the-soviets-invented-the- internet...](https://aeon.co/essays/how-the-soviets-invented-the-internet-and- why-it-didn-t-work)

No no no, the Arpanet was never designed to survive a nuclear war, the originators are even quoted as saying so.

footnotes 5: [http://www.internetsociety.org/internet/what- internet/histor...](http://www.internetsociety.org/internet/what- internet/history-internet/brief-history-internet)

</comment><comment><USER9> As best i can tell, the soviet system dreamed up by Lenin and cooped into a personality cult by Stalin was pretty much a bastardization of what Marx was envisioning.

Not that communism and Socialism was more than far flung ideals even for Marx. For the most part he was appalled by the working conditions of factory workers at his time.

That said, ol' Marx was not completely against capitalism. He did see that it had the capacity to rapidly industrialize a nation.

What he did point out though was inherent flaws in the system, flaws not just relevant to worker exploitation but also the whole engine of spending money to earning even more money. In that he perhaps noticed a hint of something that even present day mainstream economics has problem noticing, the feedback loops related to the flow of money and goods.

Notice that the article mentions in passing equilibria. That is a notion that is persistent within economics, even though it introduced more to make the math easier to work with back when it was done by hand and pencil.

these days all but economics have abandoned any notion of equilibrium, instead using computers to model complex systems and their feedbacks. Something that was spearheaded by meteorologists trying to improve weather prediction.

To go back to Marx, what he envisioned was more a transition from capitalist owned factories to worker owned factories. Coops essentially. Things like trading would still remain, as they provide vital means of signaling along the supply chains.

He did btw have some nasty things to say about finance capital, perhaps forewarning both the great depression and out present situation.

His great lament in that regard was that industrial capitalists were more likely to side with finance capital in any three way struggle between them and the workforce, when industrial capitalists would be better off in the long run to side with the workforce against finance.

</comment><comment><USER10> A reminder that Soviet science used to rival the West's capabilities, or even surpass them.

A pity that Russia has fallen so far behind in this regard.

<comment><USER11> While true in some areas, computers and advanced electronics was not one of those things. I don't think Soviets really ever got very good at producing integrated circuits, and even less at designing them. By mid-70s when stuff like less-than-room-sized computers and internet really began to take form, Soviets were already almost exclusively trying to keep up with western microprocessor tech with straight up clones, with the gap consistently increasing.

</comment></comment><comment><USER12> Glushkov has build a unique PC too

[https://en.wikipedia.org/wiki/MIR_(computer)](https://en.wikipedia.org/wiki/MIR_\(computer\))

</comment><comment><USER13> the reason it failed abd the guy got fried was simple

if state company records were kept off-site on a computer, it will make quiet ledger rigging and stealing from state companies harder. That would be outrageous for every commie as every commie was stealing cash from the state one way or another.</comment>


Django 1.0 beta 1 released - <AUTHOR> http://www.djangoproject.com/weblog/2008/aug/14/10-beta-1/

<comment><USER2> This is great. A lot of big stuff has been merged into trunk recently (filestorage-refactor, singals-refactor, geo-django).

I hope newcomments (django.contrib.comments based on newforms) will make it before the 1.0 release.</comment>


How Healthcare.gov Botched $600M Worth of Contracts - <AUTHOR> http://www.bloomberg.com/news/articles/2015-09-15/how-healthcare-gov-botched-600-million-worth-of-contracts <comment><USER2> Hey HN! I worked on the "tech surge" to save healthcare.gov, and as many of you have noticed, this report gets everything backwards. A 96-hour training course would not have saved healthcare.gov, and you can't fix bureaucracy with more bureaucracy.

If you want to understand what went wrong on healthcare.gov and how it was fixed, Mikey Dickerson's talk here is the closest thing we have to a postmortem:

      https://www.youtube.com/watch?v=0albm_hhQzM

healthcare.gov has also given rise to new initiatives to fix the way the government writes software. Within the government, there is the US Digital Service, 18F, and the Presidential Innovation Fellows:

      https://medium.com/@USDigitalService/an-improbable-public-interest-start-up-6f9a54712411

      18f.gsa.gov

      http://www.jasonshen.com/2015/when-did-you-do-your-tour-of-duty/

      http://www.jasonshen.com/2014/everything-wanted-know-presidential-innovation-fellowship-afraid-ask/

There are also new types of government contractors, including Nava and Ad Hoc LLC:

      http://www.fastcodesign.com/welcome.html?destination=http://www.fastcodesign.com/3047856/innovation-by-design/meet-nava-a-startup-that-wants-to-fix-the-governments-crappy-design

      http://adhocteam.us/

<comment><USER3> This is one of many audits conducted as part of the IG's review of the healthcare.gov rollout. The purpose of this audit was to determine if existing rules regarding contract management were followed.

It in no way claims that taking a 96 hour training course would have fixed the rollout of healthcare.gov or even that the contract management failings were the primary reason for the failure of the rollout.

<comment><USER4> I hate to say that the (lousy) article claims exactly what you say the audit doesn't claim. It specifically describes "how shoddy oversight by the Centers for Medicare and Medicaid Services (CMS), which manages federal health programs including Obamacare, contributed to the website's early struggles."

<comment><USER5> "contributed to" ≠ "caused"

</comment></comment></comment></comment><comment><USER6> The solution proposed to fix this mess is insane. A '96 hour training course' at the end of which you are able to handle 100+ million projects? That's 2 weeks of work + change. Does anyone think that they could end up qualified to handle contracts of that size after a generic 2 weeks course?

Of the people that enroll in this program, what % fail? If it's serious, the % of people qualified should be at most 50% - yet it's obviously going to be just a rubberstamp where you put in the hours, then get the certification.

As someone who firmly believes in the power of the state to do good, these things make me go insane. The solution to failures of this magnitude are not to pile on more useless regulations and certifications, or to put even more emphasis on useless credentialism. Healthcare.gov got fixed when they gave carte blanche to highly qualified engineers and managers that gave up very lucrative jobs to help fix things.

I am convinced that lots more people would be willing to give up their cushy tech jobs for a job where they genuinely made a huge difference in the lives of people, provided you got rid of all this completely meaningless hoop jumping. Give clear lines of responsibility, take a serious look at your hiring process, and jesus, if your solution to a 600+ million dollar failure is to mandate a 2 week course... you really need to think things over.

<comment><USER7> Glad I wasn't the only one who balked at the idea it would have gone well if everyone had more training.

I think we really need intelligent, experienced people who have a proven record in large product management. However, they're rare and more expensive than the government will pay for. Compounding the failure is the fact that you can't get fired from government jobs for incompetence. These projects aren't going to get any better.

<comment><USER8> >you can't get fired from government jobs for incompetence. //

This seems highly unlikely, can you expand further, some proof? [I assume you're talking about US state and federal government?]

<comment><USER9> It seems to be a property not just of government, but any large organization that becomes driven by politics over results. I just quit a job in a large corporation where I had the displeasure of observing this up close. I have noticed several key dysfunctions in a political hierarchy.

1\. You cannot be smarter than your superiors.

After several layers of this, this cumulative effect is that the people on the bottom (those that do the actual work) are not allowed to be smarter than a sea sponge.

2\. Reporting bad news to superiors is punished.

Problems are covered up instead of solved. Reports up the chain must hide problems without being provable lies so they are incomprehensible - they must appear legitimate but be devoid of all fact. Using as much jargon and acronyms as possible is effective.

3\. Blame for failure will be placed upon the least popular person.

Typically this will be whoever is drawing attention to problems. The reason for project failure will be because of "bad attitude" and not being a "team player" leaving the next project with a greater proportion of ineffectual suck ups.

<comment><USER10> _1\. You cannot be smarter than your superiors._

At one company I worked for, you couldn't be taller than your superiors either.

<comment><USER9> I've seen that effect, but I don't think I've ever seen it as rigidly enforced as this. It does illustrate how most hierarchical organizations are nothing more than adult versions of king-of-the-sandbox.

<comment><USER10> It was never a formal policy - but it was common knowledge that you shouldn't even hire someone taller than yourself because they'd surely leapfrog you for promotion.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I find it interesting that this audit only covers administrative contract oversight. The failings uncovered seem to have been of the variety "Contractor A didn't submit monthly reports for February and March". I don't claim that contracts of that size should have poor administrative oversight, not at all. Even movies with big budgets mention the assistant producers and accountants in the credits.

But what about technical oversight? Were there design-review meetings where somebody said "our system emits data in HL7" and somebody else said, "we haven't defined the XML schema for our data acceptance module yet." In a meeting like that somebody in tech oversight should have said "wait! is it HL7 or XML? Who is going to sort this out?"

(I have no idea whether this actual issue came. Probably the stuff that actually came up, or should have, is far more intricate.)

The purpose of administrative monthly reports' "issues" section is to track stuff like like this. That's why contracts require them. If the government can make the Apollo program work, the government can figure out technical oversight. It just takes the will to do so.

<comment><USER12> I see it as a high/low level oversight. If people don't know who controls the project and how to measure the progress on it, then who would even care about technical reports? That's like checking the details on a body with a head missing - maybe the guts are OK, maybe not. He's dead anyway.

</comment></comment><comment><USER13> Lesson for government: Software is not a typical infrastructure project (e.g. bridge). It is almost impossible to specify all requirement upfront. That's why waterfall methodology is prone to spectacular failures.

Training government officials how to manage those project can help, but I doubt it will make a difference. It can rather give false sense of "fixing it" without actually fixing it.

I would rather focus on hiring competent ppl and give them freedom to do that right. Such as: [https://www.whitehouse.gov/digital/united-states-digital- ser...](https://www.whitehouse.gov/digital/united-states-digital-service)

<comment><USER14> I wouldn't lay blame at the government over this. I have seen countless large implementations fail within enterprise companies i.e. massive overrun in budgets, not meeting requirements.

And unfortunately waterfall is really the only approach for projects like this i.e. you are having to select different third party vendor products up front and integrate them with custom applications. You can't iterate in sprints when you don't control the software.

And if only hiring competent people was so easy. Really talented IT professionals are very hard to find and keep. The Digital Service you mentioned really is a great step towards retaining talent and long overdue.

</comment></comment><comment><USER15> I'm a bit shocked that anyone could believe there was actually $600M of software to build. I know prices are inflated by the whole federal contracting guidelines but I'd say these contracts were at least two orders of magnitude greater than what they would have been in the private sector. And nothing against our friends to the north, but why wouldn't we bid more of this out to US companies? Perhaps those that satisfy the WO-MO requirements?

<comment><USER16> Okay but aren't you implicitly assuming a sane set of specifications? I've seen it claimed that the input legislation was forty thousand pages. Can't confirm that of my own knowledge, but if it's true, far from criticizing the management of the implementation, we should be holding it up as a miracle that it was ever successfully implemented at all for any price.

<comment><USER15> I've seen that too ... and it probably cost many millions of dollars to come up with the ambiguous and likely contradictory specification. People always want to blame the waterfall method for this, but there are a couple aspects to BDUF that I think can help even the most agile project. From the DOD world, Interface Control Documents (ICDs) are a great way to make sure components (especially those developed by different teams) inter-operate. There should also be a reasonably cohesive architectural vision. From that starting point, write some user stories and adapt as needed for each sprint.

You need to know approximately where you're headed, but you almost certainly _CAN 'T_ know everything you'll learn ahead of time (as this sort of specification implies.

As an aside, contractors love ambiguities in specifications and it's actually in their best interest (unless operating on a fixed-price contract) to purposely produce something that meets the specification but is obviously not what the customer needs. There's good money in ECRs.

</comment></comment></comment><comment><USER17> This seems to put most of the blame on the gov workers managing the contracts, and very little on the contracted companies themselves. I would find it hard to believe that they also weren't absolutely sure what they were milking.

<comment><USER18> It sounds like the people hiring the contractors didn't exactly do their due diligence.

> unclear who is really in charge, sometimes it's no one

> vague deliverables from people who don't know what they're talking about

> tons of cash, regularly, with no end in sight

Sounds like an incredibly profitable and easy contract. It's an ethical grey area, but it's not surprising that companies took advantage.

<comment><USER11> "easy contract?" I doubt it. Ten million users on the go-live date? Interchange of health-care data from system to system? Getting Oracle's identity / authentication management system integrated as a door-one requirement? Hostile congresscritters doing everything in their power to torpedo the project? The only difference between this and a typical giant cluster#uck is the vast and visible scale.

</comment></comment></comment><comment><USER19> Looks like they should look at who stole the money.

Even a very generous 100 engineer team paid at 300k/year for 3 years only costs 100 millions.

If no one is looking into it, it's reasonable to assume that whoever is supposed to look into it is the one who stole the money.

<comment><USER20> > If no one is looking into it, it's reasonable to assume that whoever is > supposed to look into it is the one who stole the money.

While this isn't exactly unreasonable, I don't see why it's such a slam dunk compared to "whoever is supposed to look into it is lazy" or "there is no one who's supposed to look into it".

</comment></comment><comment><USER21> its a joke software and governments here in Australia checkout out this mess.

1.5 billion on a Public transport metro card system [https://en.wikipedia.org/wiki/Myki#Issues_and_criticisms](https://en.wikipedia.org/wiki/Myki#Issues_and_criticisms)

1.2 billion on a payroll systems WTF!! [http://www.theaustralian.com.au/business/technology/queensla...](http://www.theaustralian.com.au/business/technology/queensland- government-to-sue-ibm-over-health-payroll- disaster/story-e6frgakx-1227140553687?nk=43303f5167de2715cd9df22efb653154-1442751558)

<comment><USER22> UK's Connecting for Health System

> Originally expected to cost £2.3 billion (bn) over three years, in June 2006 > the total cost was estimated by the National Audit Office to be £12.4bn over > 10 years

Which is roughly 27bn Australian Dollars, when it comes to this stuff our Government is in a class of it's own.

<comment><USER8> IIRC the system was then abandoned as unworkable?

<comment><USER22> Most of it was, some bits where salvaged (I think, I followed it at the time) at huge cost and then they built a newer version which sorta works.

In any base £20bn over 10 years seems like quite a lot on an initial budget of 2.4bn over 3.

</comment></comment></comment></comment><comment><USER23> This will go into the big stack of incredibly large technology project failures, including the FBI case management system and the IRS modernization program.

From a systems point of view, the problem here is the publicity. For each public disaster, there are many more that never get that much attention.

Just got through reading a biography of John Boyd. Great narrative about how huge systems of people act politically to resist change and make decisions.

</comment><comment><USER24> Botched health IT projects aren't new The UK has had some horrifically overspent and underdelivering health IT projects. It's a shame that people don't appear to learn from other people's earlier mistakes.

[http://www.telegraph.co.uk/news/health/news/8780566/Disastro...](http://www.telegraph.co.uk/news/health/news/8780566/Disastrous-11.4bn- NHS-IT-programme-to-be-abandoned.html)

£11.4bn !

<comment><USER10> This is why I laugh when people complain about the cost of a Trident replacement... You could pay for it out of the NHS IT budget and neither patients nor medical staff would even notice.

</comment></comment><comment><USER25> You can watch a very entertaining talk from one of the Google engineers who went to fix the website at the time: [https://www.youtube.com/watch?v=GLQyj- kBRdo](https://www.youtube.com/watch?v=GLQyj-kBRdo)

<comment><USER26> The most ridiculous part, they didn't have a way to run distributed commands over ssh. When a filesystem mounted in read-only mode, somebody had to ssh into each of the 175 servers manually and run commands to fix it.

<comment><USER27> What do you mean by "distributed commands over ssh"?

<comment><USER28> Say you want to run a command on a group of machines using SSH. Rather than manually running the command on each remote machine you can automate their execution over the group using what is known as distributed commands.

[http://www.tecmint.com/using-dsh-distributed-shell-to-run- li...](http://www.tecmint.com/using-dsh-distributed-shell-to-run-linux- commands-across-multiple-machines/)

[http://www.ibm.com/developerworks/aix/library/au- satdistadmi...](http://www.ibm.com/developerworks/aix/library/au- satdistadmin/#N100E1)

</comment></comment></comment></comment><comment><USER29> 600m and the gov still has to take the contractor with the lowest bid still? Makes me think the requirements were so broken no one really wanted the work.

</comment><comment><USER30> Tangential question, how do software firms get contracts like this? Seems like a good business to be in.

<comment><USER31> Navigating the byzantine contracting system is the only skill these companies have. They can't do the job, but they can fill out the forms, which is a rare skill.

<comment><USER27> You mean reading and following the instructions manual is hard work beyond the reach of a normal human being??

<comment><USER31> If you think it's easy to win government contracts then I invite you to do so. It can be lucrative.

</comment></comment></comment></comment><comment><USER32> This is why I wonder how much we need more and better coders versus better managers?

<comment><USER33> You need both.

The biggest issue I take with good coders lead by non-technical managers is they invariably convince managment they need to rewrite everything in the flavour of the month or architect in requirements so they can use technologies they're interested in.

Inevitably, these guys are now qualified with a whole new bunch of tools, so they move on and hopping about the industry writing a whole bunch of software that relies on a datastore that doesn't actually save data consistently, for example.

</comment></comment><comment><USER34> Could this project have been completed by the likes of Google?

</comment><comment><USER35> I expect nothing less from the federal government.

</comment><comment><USER36> Disclaimer: Highly political rant.

You mean to tell me a company that got selected a no bid contract from their connections in the Obama administration couldn't do an adequate job?

Crony politics at its best.</comment>


Identifying Knowledge Graph Entities in Google Images Results - <AUTHOR> https://blog.google/products/search/knowledge-graph-google-images/ <comment><USER2> I performed various searches after reading this and I must say, I am impressed.

</comment><comment><USER3> I was thinking about knowledge graphs in the context of AI, and wondering if google's graph could be built into an agent... and then I realized that I am the agent and google's knowledge graph is incredibly useful!

<comment><AUTHOR> It's only useful when based on your interests, so creating artificial interest and means to convey it is the first step in building an agent.</comment></comment>