Parsing JSON is a Minefield - <AUTHOR> http://seriot.ch/parsing_json.php <comment><USER2> While this is true of JSON, it's also true of any other non-trivial serialization and/or encoding format. The main lessons to learn here are that:

1) implementation matters

2) "simple" specs never really are

It's definitely important to have documents like this one that explore the edge cases and the differences between implementations, but you can replace "JSON" in the introductory paragraph with any other serialization format, encoding standard, or IPC protocol and it would remain true:

"<format> is not the easy, idealised format as many do believe. [There are not] two libraries that exhibit the very same behaviour. Moreover, [...] edge cases and maliciously crafted payloads can cause bugs, crashes and denial of services, mainly because <format> libraries rely on specifications that have evolved over time and that left many details loosely specified or not specified at all."

<comment><USER3> No, this is not true of many reasonable formats. You don't have to make an obtusely nontrivial format to encode the data JSON does.

<comment><USER4> JSON is fairly trivial. The post is a nonsensical rant about parsers accepting non-JSON compliant documents (as the JSON spec specifically states that parsers may), such as trailing commas.

In the large colored matrix, the following colors mean everything is fine: Green, yellow, light blue and deep blue.

Red are crashes (things like 10000 nested arrays causing a stack overflow—this is a non-JSON-specific parser bug), and dark brown are constructs that should have been supported but weren't (things like UTF-8 handling, which is again non-JSON specific parser bugs).

Writing parsers can be tricky, but JSON is certainly not a hard format to parse.

<comment><USER3> As a question of fact, programs put out JSON that gets misparsed by other programs. Some simply parse floating point values differently, or they treat Unicode strings incorrectly, or output them incorrectly. Different parsers have different opinions about what a document represents. This has a real world impact.

Accepting invalid or ambiguous or undefined JSON is not an acceptable behavior. It means bugs get swallowed up and you can't reliably round trip data.

<comment><USER5> > Accepting invalid or ambiguous or undefined JSON is not an acceptable > behavior

Just to make it explicit (and without inserting any personal judgement into the conversation myself): JSON parsers should reject things like trailing commas after final array elements because it will encourage people to emit trailing commas?

Having asked the question (and now explicitly freeing myself to talk values) it's new to me -- a solid and rare objection to the Robustness Principle. Maybe common enough in these sorts of discussions, though? Anyway, partial as I might be to trailing commas, I do quite like the "JSON's universality shall not be compromised" argument.

<comment><USER3> Postel's Law or the "Robustness Principle" is an anti-pattern in general.

Accepting trailing commas in JSON isn't as big a deal as having two different opinions about what a valid document is. But you might think a trailing comma could indicate a hand-edited document that's missing an important field or array element.

</comment></comment></comment></comment></comment></comment><comment><USER6> This is interesting and important in one way: anything poorly specified will eventually cause a problem for someone, somewhere. That being said, my first response was to complete the title, ". . . yet it remains useful and nearly trouble-free in practice." There's a lot of, "You know what I mean!" in the JSON definition, but in most cases, we really _do_ know what Crockford means.

<comment><USER7> If your API takes json input, some of those issues are potential security or DoS issues.

For example, if you validate your json in your web front-end (EDIT: I used the wrong term. What I meant here is the server-side process that's in front of your database) and then pass the string received to your json-aware database, you're likely using two json implementations that may have different ideas about what constitutes valid json.

For example, a caller might pass in a dictionary with duplicate key names, and the two parsers might each drop a different one, or one might see json where the other sees a comment.

<comment><USER8> Reminds me of last years CouchDB bug (CVE-2017-12635) which was caused by two JSON parsers disagreeing on duplicate keys: here it was possible to add a second key with user roles, allowing a user to give admin rights to itself. JSON parser issues are real.

<comment><USER9> One of the benefits of serialization technology (like Codable+JSONEncoder in Swift or DataContract in C#) is that you get a canonical representation of the bits in memory before you pass the document on to anyone else.

By representing fields with enums or proper types you get some constraints on values as well, eg: If a value is really an integer field then your type can declare it as Int and deserialization will smash it into that shape or throw an error, but you don't end up with indeterminate or nonsense values.

This can be even more important for UUIDs, Dates, and other extremely common types that have no native JSON representation, nor even any agreed-upon consensus around them.

You get less help from the language with dynamic languages like Python but you can certainly accomplish the same thing with some minimal extra work. Or perhaps it would be more accurate to say languages like Python offer easy shortcuts that you shouldn't take.

In any case I highly recommend this technique for enforcing basic sanitization of data. The other is to use fuzzing (AFL or libFuzzer).

</comment></comment></comment></comment><comment><USER10> It would be great if programmers learned from markdown and json.

Here is the lesson:

1\. We need something simpler, so I will make a simple solution to this problem 2\. Simple should also mean no strict spec, support for versioning or any of those engineer things. All that engineer shit is boring and I can tell myself this laziness is "staying simple" 3\. OH SHIT, I was totally right about #1 so this got popular and having been designed as just a toy is causing a lot of problems for a massive number of people ... now my incompetence regarding #2 is on display and there is nothing I can do about it

I'm not saying "Thou shalt always add bureaucracy to your toy projects", but look at what happened and think about how Gruber and Crawford will be remembered, partly if not mostly, for being "the asshole who screwed up X". If you go the other way programmers will think "damn I hate these RFCs, these suits are messing up the beautiful vision of Saint [your name here]".

<comment><USER11> Oh yes RFC process always keeps things from having compatibility issues.

I definitely never saw any issues with all those XML based standards like SOAP or XSLT.

<comment><USER12> A lot of that is because XML is objectively insane: it's a monumentally over- specified version of something that a sane community would have sketched out on the back of a cocktail napkin. XML is S-expressions done wrong. It's a massive amount of ceremony & boilerplate, IMHO due to the pain of dealing with dynamic data in static languages. It's basically the Java of data-transfer languages.

And it shouldn't even be used for data transfer: it's a _markup_ language, for Pete's sake!

<comment><USER13> Please. XML specification is much shorter than that of YAML, for example, even though XML 1.0 includes a simple grammar-based validation spec (DTD). "A markup language"? What does it mean? Are there any special "data-transfer languages" we neglect? :) Data gets serialized; we need to mark different parts of it; XML can totally do it. For some cases it's not the best fit, but nothing is.

</comment></comment></comment></comment><comment><USER14> I think the idea of humans sharing a language with computers is problematic at a fundamental level.

(the whole $dataformat "easy to read for humans")

It becomes a source of never ending lose-lose compromises where the more points you give to human convenience the more points you take away from machine convenience and vice versa.

Then you end up having to "settle" for something in between that is just ambiguous and problematic for machines to be able to deal with it and just noisy enough for humans to be able to cope looking at it and edit it. That's basically what JSON is.

If we accept to use a transformation step and better tooling we can free the representation from this tension of "friendly for computers vs friendly for humans".

It's also a bit odd that we apply this readability obsession only to these data formats.

I don't hear people wanting a human readable text representation of their audio, video or images.

<comment><USER15> >> _I don 't hear people wanting a human readable text representation of their audio, video or images._

This is, in fact, a huge concern for people who think about accessibility.

<comment><USER14> Ok but what I'm talking about is a little more specific.

Talking about "human readability" of JSON and XML is a little bit like talking about human readability of JPEG or MP3.

Chasing after it creates a lot of problems.

Formats like JSON and XML often carry lots of textual information so it's tempting to want them to be like "just like text but with some extra stuff" but that creates its own problems.

So it would be interesting to have something like JSON but philosophically treat it like MP3. Meaning, don't assume that humans must fiddle with the bytes in a text editor with great ease so that the representation can be designed without the influence of "would the raw bytes look pretty to people?".

<comment><USER16> What you're proposing sounds like cbor and/or messagepack (which are virtually identical in their design), or argdata[1].

I agree it's a pretty solid spot in the design space.

[1]: [https://github.com/NuxiNL/argdata](https://github.com/NuxiNL/argdata)

</comment></comment></comment></comment><comment><USER17> This is the one thing that the JSON-against-XML holy warriors need to understand properly. Yes, JSON's less verbose; yes, it's just "plain text" (in as much as there is such a thing); yes, XML makes you put closing tags in - but if you need reliable parsing and rock-solid specifications (and it's reasonably likely that you do, even if you think you don't...), then XML, for all its faults, is very likely the better way.

<comment><USER18> Disagree.

I can always make my JSON act like XML if I want to. When I'm following something like JSON API v1.1 I get a lot of the advantages that I'd get from XML with 99% less bloat. You want types? Go for it! There are even official typed JSON options out there. The security / parsing issues with XML alone are enough for me to rule it out.

How many critical security issues are the result of libxml? Nokogiri / libxml accounts for 50% of my emergency patches to my servers. ONE RUBY GEM is the result of _half_ of my security headaches. That's insane. I only put up with it because _other people_ choose to use XML and I want their data.

How many issues are the result of browsers having to deal with broken HTML (a form of XML)?

JSON isn't perfect, and I wouldn't use it absolutely everywhere, but it's dead simple to parse[0], readable without the whitespace issues of YAML, and I can't think of one place I'd use XML over it.

[0] [http://json.org/](http://json.org/)

<comment><USER19> HTML isn't XML. It's close, but it isn't. There's XHTML for that.

<comment><USER17> Just for the record - XML and HTML are both subsets of SGML, somewhat overlapping, but by no means coterminous with each other (at least until HTML 5 - I'm honestly not sure what it's relationship to SGML is).

And, speaking from experience, the XML nay-sayers should largely be glad if they never had to deal with SGML :)

<comment><USER20> HTML pretended to be a subset of SGML, but never really was, and the illusion quickly dispersed as time went on, since HTML was strictly pragmatic and ran in resource-constrained environments (the desktop), while SGML was academic, largely theoretical, and ran on servers, analyzing text.

XML, on the other hand, was more of a back-formation – a generalization of HTML; it was not, as I understand it, directly related to SGML in any way. The existence of XML was a reaction to SGML being impractical, so it would be strange if XML directly derived from SGML.

<comment><USER21> > _XML [...] was not [...] directly related to SGML in any way_

That's incorrect. XML is by definition a proper subset of _WebSGML_ , the SGML revision specified in ISO 8879:1986 Annex K. These two specifications were published around the same time and authored by the same people.

In a nutshell, XML added _DTD-less_ SGML (eg. such that every document can be parsed without markup declarations, unlike eg. HTML which has `img` and other empty elements the parser needs to know about) and XML-style empty elements. The features removed from SGML to become XML were tag inference/omission (as used in HTML), short references (for things such as Wiki syntax, CSV, and even JSON parsing), uses of marked sections other than `CDATA`, more complex use cases for notations, and link process declarations ("stylesheets") plus a couple others.

</comment></comment></comment></comment></comment></comment><comment><USER22> > For instance, RFC 8259 mentions that a design goal of JSON was to be "a > subset of JavaScript", but it's actually not.

Actually, it's really close [https://github.com/tc39/proposal-json- superset](https://github.com/tc39/proposal-json-superset)

This is a stage 3 proposal likely to make it to the next version of the spec. At which point JSON would truly be a subset of JavaScript.

<comment><USER23> Better late than never ...

</comment></comment><comment><USER24> This brings to mind the old internet motto (someone correct me on the actual source): "be liberal in what you accept, and be conservative in what you send".

JSON is pretty clear on what certain things should mean, strings are Unicode plus escape sequences, objects map keys to values, arrays are ordered collections of values, the whole serialized payload should be Unicode, etc. Even those things can be relaxed further. This IMHO is what makes JSON so robust on the internet and the perfect choice for a non-binary communication protocol.

<comment><USER25> > "be liberal in what you accept, and be conservative in what you send"

This is commonly known as Postel's Law, and comes from one of the TCP RFCs [1].

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

<comment><USER26> This is also widely considered a bad idea now. Making liberal consumers allows for sloppy producers. Over time this requires new consumers to conform to these sloppy producers to maintain compatibility.

Just look at the clusterfuck that HTML5 has become. You need to have extremely deep pockets to enter that market.

<comment><USER27> Do you have a survey or other citation for it being a bad idea? I get that it enables bad behavior, per see. However, the idea of rejecting a customer/client because they did not form their request perfectly seems rather anti customer.

Ideally, you'd both accept and correct. But that is the idea, just reworded.

<comment><USER28> The Harmful Consequences of Postel's Maxim - [https://tools.ietf.org/html/draft-thomson-postel-was- wrong-0...](https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00) (HN from 2015 [https://news.ycombinator.com/item?id=9824638](https://news.ycombinator.com/item?id=9824638) )

Wrestling with Postel's Law [https://techblog.workiva.com/tech-blog/wrestling- postel's-la...](https://techblog.workiva.com/tech-blog/wrestling-postel's-law)

<comment><USER27> The discussion was fun. And seems evenly split, at a quick reading.

More, I think it split on how you read it. If you view it as an absolute maxim to excuse poor implementations, it is panned. If you view it as a good faith behavior not to choke on the first mistake, you probably like it.

This is akin to grammar police. In life encounters, there is no real place for grammar policing. However, you should try to be grammatically correct.

<comment><USER29> > This is akin to grammar police. In life encounters, there is no real place > for grammar policing. However, you should try to be grammatically correct.

That's because most humans have feelings. But most machines don't. So that's not comparable.

<comment><USER27> I meant that grammar policing does little to help the exchange of information. Feelings aside.

<comment><USER30> A lack of enforced language standards does end up producing a language full of difficult-to-learn inconsistencies, though.

<comment><USER27> It makes difficult to codify inconsistencies. Most aren't that difficult to learn, oddly. Especially if you are just trying to be conversational.

Edit: I'm specifically going off evidence of teaching my kids. They have basically picked up language completely by talking to us. Even pronouns, adjectives, adverbs, etc. What they have not learned, is the reasons some words are used when another could have worked.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> This seems like more of a problem with parsers _not following the spec_. It's a simple spec, but so strict and restrictive that it's a bit of a pain to give to humans, and small extensions (like comments) are immensely useful for its (ab)uses as configuration "DSL"s. And some edges like that the string format isn't specified - that's (basically) fine, it's not a connection-negotiation protocol.

So JSON parsers tend to implement some weird, unspecified, inconsistent superset of JSON. I haven't encountered one yet that fails to parse _valid_ JSON though. That doesn't seem to imply that parsing JSON is a minefield. Only that parsing _human input_ , _nicely_ , is a minefield. No spec avoids the human ergonomic problem simply.

</comment><comment><USER32> In my opinion most parsers are just too lax. They support some fancy extension at the beginning (like comments, which are not a good idea), get more and more "feature-rich" and then support syntax that is not specified in the standard.

Other parsers now have to lower their "standard" (no pun intended) to compete which leads to more complex edge-cases that we also find in undefined behaviour and compilers.

E.g. if your HTML is broken, it mostly renders somehow in your browser, which is in my opinion bad design - the same is probably true with JSON.

<comment><USER33> I totally agree. JSON to me is actually pretty straight forward, it's the parsers that interpret it differently.

</comment></comment><comment><USER34> There are many things in tech which have caused great grief in my life as a programmer. JSON is not one of them.

</comment><comment><USER35> This document is missing the XMLHttpRequest/Fetch JSON profile. ECMA operates on a sequence of Unicode code points (really code points, not scalar values!). WHATWG defines how you go from bytes over HTTP to something you can pass to the ECMA-specified JSON parser.

</comment><comment><USER36> Previously:

[https://news.ycombinator.com/item?id=12796556](https://news.ycombinator.com/item?id=12796556)

</comment><comment><USER37> We had a nasty liberal-in-what-you-accept JSON problem: using JSON to communicate between services written in various languages (Python, Java, Javascript, C++): the python client was simply writing maps out which were automatically serialized into something _almost_ JSON: {'label': 123} (using ' to delimit the label strings, not "). The Javascript JSON parser would silently accept this, as would some of the Java libraries, while both the C++ parsers we used would reject it. This was a pain to debug since some of the modules communicated seemingly perfectly, and of course those developers didn't see why they should change.

<comment><USER38> JSON is mostly a strict subset of Python. That's not unexpected, but it makes me question how something like this actually happened. Your bug likely resulted from someone doing a `str(obj)` instead of `json.dumps(obj)`. Hardly the fault of JSON for being very similar to Python's default string serialization.

<comment><USER37> That is precisely what they did, yes, and some of the client code (e.g. JavaScript) DWIMed it (accepted it)

</comment></comment></comment><comment><USER39> It's inevitable, nothing is perfect ... there is only popular things that everyone complains about and things that nobody cares about :D

We're not machines we're more comfortable with messy and forgiving systems.

Do you want to build successful products? be liberal on input and conservative on output. You need to reduce entropy and give people a feeling of magic. It's when you're old and have enough scars on your skin when you learn to hate magic and become control freak :D

</comment><comment><USER40> i wish there was a chance for EDN[1] to replace JSON. it's a shame the industry defaulted to a subset of javascript as a data notation format considering all it's shortcomings =/

yeah, i get it, "but it has native support in all browsers" is a valid argument, i just wish it wasn't.

[1] [https://github.com/edn-format/edn](https://github.com/edn-format/edn)

<comment><USER41> In what regard EDN is "better" than JSON? the point of the post was the RFC specification is not tight and there are corner cases. I don't see any rigor in the given link either..

<comment><USER40> it is better in regard that:

\- there exists single reference implementation, which rules out points like scalars not being valid JSON in some parsers despite being part of the spec

\- it is extensible in a manner that never invalidates the syntax for parsers that do not use corresponding extensions (this is huge actually)

\- comments are part of the spec, so it essentially replaces both json and yaml

\- richer set of primitive types

\- commas are whitespace (best feature ever)

the rest should definitely be handled in BNF spec, but the above makes EDN immediately _much_ better than JSON

</comment></comment></comment><comment><USER42> If parsing JSON is a minefield, what about YAML? :D

<comment><USER31> A minefield where the mines hunt you down, rather than waiting for you to step near.

</comment></comment><comment><USER43> Parsing JSON is not a minefield. It is technically trivial and pretty secure. Compared to other specs it's not that bad, but of course there are still some security concerns, esp. in the last two JSON RFC updates, which made it worse and not better.

But most other commonly uses transport formats are much worse, and much harder to parse. Start reading at [http://search.cpan.org/~rurban/Cpanel-JSON- XS-4.02/XS.pm#RFC...](http://search.cpan.org/~rurban/Cpanel-JSON- XS-4.02/XS.pm#RFC7159)

<comment><USER44> I don't think it's a rule that JSON parsers are, in general, "pretty secure." Even if the parser itself is not vulnerable (to say, hitting recursion limits), how duplicate keys are handled between parsers has led to security vulnerabilities in the past for other things such as GET parameters. Or suppose an attacker gets a message through a few layers and that then causes a backend server to fail, like with the Swift errors he talks about, causing data loss.

</comment></comment><comment><USER45> Try RSS.

Having built a system years ago, to try an parse tens of thousands of feeds, there's a huge amount of 'fuzzy logic' required to put it all in order.

Despite the spec.

<comment><USER46> There were nine different and incompatible versions.

[http://web.archive.org/web/2004/http://diveintomark.org/arch...](http://web.archive.org/web/2004/http://diveintomark.org/archives/2004/02/04/incompatible- rss)

</comment></comment><comment><USER47> In a different realm, there are people that find even ol' JSON annoyingly strict, and we prefer to just grab JSON5 instead ([https://github.com/json5/json5](https://github.com/json5/json5)) at least for system-local configs.

..there was a wise saying about how you gotta "stop worrying and love the bomb" ;)

</comment><comment><USER48> Im happy to say that my own JSON parser ([https://github.com/ryanbalsdon/cerial](https://github.com/ryanbalsdon/cerial)) passed a lot more of these tests than I expected! It isn't a general parser though (requires a pre-defined schema) so is probably cheating.

</comment><comment><USER49> I just noticed that the recursion depth test mentions 10000 opening brackets, while the test code uses `'['*100000` (one order of magnitude more). I am curious about the actual recursion depth they can handle but don't have access to xcode myself.

</comment><comment><USER50> Reminds me of some JSON I got from an API.

It was always malformed and I always wrote the dev that he should fix it.

He always did, but every new endpoint was malformed again.

One day I looked at the code and it was full of string concatinations of DB results...

<comment><USER30>
      select '{ "user": { "name": "' || u.name || '", "email": ' || u.email || '" } }' as json from users u;

oh my.

<comment><USER51> ...I don't know if it was intentional or not, but you're missing a comma.

</comment></comment></comment><comment><USER52> If you think parsing JSON is hard, try parsing/generating streaming JSON while limiting memory bandwidth requirements. Fun exercise, with a push-down automaton.

</comment><comment><USER53> Parsing UTF-8 in the presence of errors is a huge headache in itself.

UTF-8 with "byte order marks"? That makes no sense.

</comment><comment><USER54> Why can't there be a subset of JSON or XML called like strict mode and it's a much more sane version of the ddl?

<comment><USER55> Why can't there be?

</comment></comment><comment><USER56> Before JSON, XML and standard binary formats, there were just CSV/TSV and random binary formats which was a bigger minefield. Simply exchanging data was a project in itself.

At least JSON and XML are text based when it comes to data exchange. Back in the day before APIs that needed to exchange data cleanly, without JSON/XML, exchanging data was not only a minefield but one with constant carpet bombing. The fact that edge cases that are rarely run into is all that is left of data exchange issues is a huge advancement.

What is great is in most cases JSON works fantastic and simplifies data exchange and APIs all the way to front ends and backends. XML is available if needed. So are binary standard formats now for really compact areas like messaging for performance that humans may never see or you may never have a third party that needs to parse it. The task of parsing xml in client side javascript is not fun especially, neither is binary parsing where adding a value can break the whole object, JSON keys can come and go.

The engineer can choose the tool for the job but there better be a good reason to use anything over simple JSON, almost any problem can be solved with it. Engineers should aim to take data complexity and make it as simple as possible, not take simple and make it complex for job security, real engineers always move more simple when possible and away from vogon ways.

For data that is exchanged between services and front-end/backend, JSON is the simplified format that makes things move faster. XML got tarred and devolved into vogon sludge with SOAP services and nested namespacing/schemas but still is needed in some areas. Binary standard formats when you control both sides or noone else needs to connect to it or you don't need it on the front end maybe or possibly you need performant real-time messaging. There is also YAML if you need more typing or BSON where binary needed but still simple. All formats have good uses and bad but using binary when JSON will suffice is not being as simple as possible.

JSON is easy to get around and is more lightweight, if you run into a problem you can just restructure your JSON to make it work where binary or XML take more work to change without breaking changes, especially downstream causing many more versions and conversions. JSON is a data messaging format meant to simplify. Most of the issues in the OP article could be solved storing the values in a string with a "type" or "info" key that allows conversion in the backend i.e. long numbers or hex etc or storing binary as base64 etc.

JSON is based on basic CS types in objects, lists, simple data types like string, number, bool, date, this makes for a simplifying of all systems that serialize and deserialize to it. JSON helps spread simplicity while being dynamic.

JSON works best with ever changing dynamic data/code/projects we build today and in seconds you can be consuming data from third party APIs faster than any other format and more simplistically, that is why it won.

<comment><USER12> > Before JSON, XML and standard binary formats, there were just CSV/TSV and > random binary formats which was a bigger minefield.

S-expressions predate both, are simpler to parse than either, are more legible than both and are cheaper than either.

Here's a JSON example from [http://json.org/example.html](http://json.org/example.html):

        {
            "glossary": {
                "title": "example glossary",
        		"GlossDiv": {
                    "title": "S",
        			"GlossList": {
                        "GlossEntry": {
                            "ID": "SGML",
        					"SortAs": "SGML",
        					"GlossTerm": "Standard Generalized Markup Language",
        					"Acronym": "SGML",
        					"Abbrev": "ISO 8879:1986",
        					"GlossDef": {
                                "para": "A meta-markup language, used to create markup languages such as DocBook.",
        						"GlossSeeAlso": ["GML", "XML"]
                            },
        					"GlossSee": "markup"
                        }
                    }
                }
            }
        }

In XML it'd be:

        <!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
         <glossary><title>example glossary</title>
          <GlossDiv><title>S</title>
           <GlossList>
            <GlossEntry ID="SGML" SortAs="SGML">
             <GlossTerm>Standard Generalized Markup Language</GlossTerm>
             <Acronym>SGML</Acronym>
             <Abbrev>ISO 8879:1986</Abbrev>
             <GlossDef>
              <para>A meta-markup language, used to create markup
        languages such as DocBook.</para>
              <GlossSeeAlso OtherTerm="GML">
              <GlossSeeAlso OtherTerm="XML">
             </GlossDef>
             <GlossSee OtherTerm="markup">
            </GlossEntry>
           </GlossList>
          </GlossDiv>
         </glossary>

And as an S-expression it'd be:

        (glossary (title "example glossary")
                  (div
                   (title S)
                   (list
                    (entry (id SGML)
                           (sort-as SGML)
                           (term "Standard Generalized Markup Language")
                           (acronym SGML)
                           (def (para "A meta-markup language, use to create markup languages such as DocBook.")
                                (see-also GML XML))
                           (see markup)))))

Which is, I believe, a huge improvement.

<comment><USER57> The S-expression has cleaner whitespace and field names than the JSON, which makes it harder to make an apples-to-apples comparison.

But the biggest problem with that S-expression is that I don't know how to parse it. Is SGML a symbol, identifier, a quoteless string? How do I know when parsing the 'entry' field that what follows is going to be a list of key/value pairs without parsing the whole expression? Is 'see-also GML XML' parsed as a list? How do we distinguish between single element lists and scalars? Is it possible to express a list at the top level, like JSON allows? How do you express a boolean, or null?

Of the problems outlined in the OP, S-expressions solve one: there's no question of how to parse trailing commas because there are no trailing commas. They do not solve questions of maximum levels of nesting. They have the same potential pitfalls with whitespace. They have exactly the same problems with parsing strings and numbers. They have the same problem with duplicated keys.

My point here isn't that you can't represent JSON as S-expressions. Clearly you can. My point is that in order to match what JSON can do, you have to create rules for interpreting the S-expressions, and those rules are the hard part. Those rules, in essence, _are_ JSON; once you've written the logic to serialize the various types supported by JSON to and from S-expressions, you've implemented "JSON with parentheses and without commas".

<comment><USER12> > Is SGML a symbol, identifier, a quoteless string?

It's a sequence of bytes — a string, if you like.

> How do I know when parsing the 'entry' field that what follows is going to > be a list of key/value pairs without parsing the whole expression?

You wouldn't, and as a parser you wouldn't need to. The thing which accepts the parsed lists of byte-sequences would need to know what to do with whatever it's given, but that's the same issue as is faced by something which accepts JSON.

> Is 'see-also GML XML' parsed as a list?

(see-also GML XML) is a list.

> How do we distinguish between single element lists and scalars?

'(single-element-list)' is a single-element list; 'scalar' is a scalar. Just like '["single-element-list"]' & '"scalar"' in JSON.

> Is it possible to express a list at the top level, like JSON allows?

That whole expression is a list at top level.

> How do you express a boolean, or null?

The same way that you represent a movie, a post or an integer: by applying some sort of meaning to a sequence of bytes.

> They do not solve questions of maximum levels of nesting.

They don't solve the problem of finite resources, no. It'll always be possible for someone to send one more data than one can possibly process.

> They have the same potential pitfalls with whitespace.

No, they don't, because Ron Rivest's canonical S-expression spec indicates exactly what is & is not whitespace.

> They have exactly the same problems with parsing strings and numbers.

No they don't, because they don't really have either strings or numbers: they have lists an byte-sequences. Anything else is up to the application which uses them — just like any higher meaning of JSON is up to the application which uses _it_.

> They have the same problem with duplicated keys.

No, they don't — because they don't have keys.

> My point is that in order to match what JSON can do, you have to create > rules for interpreting the S-expressions, and those rules are the hard part.

 _My_ point is that JSON doesn't — and can't — create all the necessary rules, and that trying to do so is a mistake, because applications do not have mutually-compatible interpretations of data. One application may treat JSON numbers as 64-bit integers, another as 32-bit floats. One application may need to hash object cryptographically, and thus specify an ordering for object properties; another may not care. _Every_ useful application will need to do more than just parse JSON into the equivalent data structure in memory: it needs to validate it & then work with it, which almost certainly means converting that JSON-like data structure into an application-specific data structure.

The key, IMHO, is to punt on specifying all of that for everyone for all time and instead to let each application specify its protocol as necessary. The reason to use S-expressions for that is that they are structured and capable of representing anything.

Ultimately, we can do more by doing less. JSON is seductive, but it'll ultimately leave one disappointed. It does a lot, but not enough. S-expressions do enough to let you do the rest.

<comment><USER57> I hope you understand that those questions were rhetorical -- they're questions that do not need to be asked about the equivalent JSON representation. Questions developers don't have to ask each other about the data they're sending each other.

The canonical S-expression representation solves some of the problems JSON has, true, but the example you provided is not a canonical S-expression. It wouldn't make sense for it to have been, because canonical S-expressions are a binary format and not comparable in this context to JSON or XML.

Application developers voted with their feet for serialization formats with native representations of common data types (strings, numbers, lists, maps, booleans, null). There's a lot of reasons that JSON has supplanted XML, but one of them is that JSON has these types built in and XML does not. A lot of real-world data interchange and storage can make good use of those primitives. Many problems boil down to "how do I pass around a list of key/value records". There is a lot to say for not having to renegotiate that kind of basic detail every time two applications need to communicate.

You can represent S-expressions as JSON strings and arrays. I've done it. It was the best way to represent the data I was trying to store, but that's because the data was already represented as S-expressions. I've never seen anyone else do it, and that doesn't surprise me. For most purposes JSON is used for, it is more useful than S-expressions -- not necessarily more powerful, but more useful.

<comment><USER58> Interpreted as a Rivest S-expression, the example given above conforms to the "advanced transport representation" [1], and so can automatically and straightforwardly be converted to the "canonical representation" [2].

In an important sense, then, I'd claim that it _is_ a "canonical S-expression".

The reason this works is because SPKI S-expressions aren't just a grammar for a syntax, they also come with [3] a total /equivalence relation/, which is exactly what JSON lacks and which is what makes JSON such a pain to work with.

In other words, SPKI S-expressions have a semantics. JSON doesn't.

Lots of other "modern" data languages also lack equivalence relations, making them similarly difficult to use at scale.

[ETA: Of course, your point about lacking common data types is a good one! My fantasy-land ideal data language would be something drawing from both SPKI S-expressions and BitTorrent's "bencoding", which includes integers and hashes as well as binary blobs and lists.]

\---

[1] Section 6.3 of [http://people.csail.mit.edu/rivest/Sexp.txt](http://people.csail.mit.edu/rivest/Sexp.txt)

[2] Section 6.1 of [http://people.csail.mit.edu/rivest/Sexp.txt](http://people.csail.mit.edu/rivest/Sexp.txt)

[3] The SPKI S-expression definition is still a draft and suffers a few obvious problems - ASCII-centrism and the notion of a "default MIME type" being two major deficits. Still, I'd love to see the document revived, updated, and completed. Simply _having an equivalence relation_ already lifts it head and shoulders above many competing data languages.

</comment></comment></comment></comment></comment></comment><comment><USER59> I'm always saying that I can't understand how do we have a new hipster programming language/framework every year, but we still struggle dealing with JSON

</comment><comment><USER60> Damn, the people that work on these kind of things are heros.

</comment><comment><USER61> Gson is the best one out there

</comment><comment><USER62> TOML is supposed to be easy to parse.

</comment><comment> your-nanny Doing God's work, man. Helluva job</comment>


Inter-thread communications in Java at the speed of light (2013) - <AUTHOR> http://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications

<comment><USER2> Reading that, I can't really see much difference between a much older approach called Multiple Buffering? ([http://en.wikipedia.org/wiki/Multiple_buffering](http://en.wikipedia.org/wiki/Multiple_buffering))

Happy for someone to point out the error of my thinking though..</comment>


Ask HN: Did you succeed after struggling to build something people want? - <AUTHOR> What was your journey?
How did it feel when finally people started to use your service?
I've been trying for so long to build something people want, without success so far.  I may never.....
I'd love to know how it feels though to go from trying and trying and trying to finally building a software product that people want to use. <comment> sras-me I made this reader that you can use to read both HN and reddit, after seeing people ask for a better interface for HN, and ofcourse ended up with no one else using...

[https://sras.me/reform/#/setconfig;reddit=programming%2Cscie...](https://sras.me/reform/#/setconfig;reddit=programming%2Cscience%2Caskscience;hackernews=topstories%2Cbeststories%2Caskstories%2Cshowstories)

EDIT: I know this was not much of a journey. But ultimately, what I have learned is that you need to come to terms with failure even before you start. But at the same time, work like failure is not an alternative...

</comment><comment><USER2> I started writing this free task manager ([http://abstractspoon.weebly.com/](http://abstractspoon.weebly.com/)) in 2003 and it proved to be quite popular. I still work on it on a semi-daily basis because I enjoy it but users can be soooooo demanding. I've received some emails that I've allowed to spoil my day, and some people have tried to ride on my coat-tails but overall it's been a very rewarding experience and it kept me sane after my divorce. I wish you luck in your adventures.

</comment><comment><USER3> Really helpful things are provided here. [http://www.friv.gold/](http://www.friv.gold/) I really happy to read this post,I did a search on the subject and found nearly all anyone's will agree with your blog post. [http://www.juegosfriv2018.link/](http://www.juegosfriv2018.link/) You have completed certain excellent points there.

</comment><comment><USER4> Build a very small thing that would provide value. I've built quite a few products. However, the most successful product to date has been one that I wrote in a week to solve a problem I had for my websites. So, my take away from that is to try and build simple things.

</comment><comment><USER5> Build things you need and that will help you to discover services other might need.</comment>


Show HN: No-code CSS editor for any website. - <AUTHOR> https://eazycss.com/ <comment><AUTHOR> Hey Hacker News,

My name is vigneshwarar, I am the creator of EazyCSS, The Simple no-code CSS editor for any website.

🟥 Problem 1:-

Testing new design ideas or delegating a change to designers/developers, for a no-code person with back and forth emails, would cost time and money.

🟥 Problem 2:-

Even from a developer's perspective, using a lot of different sites from a box-shadow generator, picking color code, and switching back and forth from codebase to live preview for pixel changes is time-consuming and less productive.

🟩Solution:-

Simple looking, slider approach to most of the CSS properties where anybody can instantly change the design of a site without a prior CSS Knowledge and get your changes in CSS code.

Features:-

1) Don't Calculate pixel values, select a property and just slide

2) Edit text on the webpage (Hover + press e)

3) Change color or background with our inbuilt color picker

4) If you make a mistake, you can reset changes to default

5) All your design changes will be converted into CSS code

I would love to know your feedback

<comment><USER2> Just tried it on desktop. I would not have the demo on the front information page. Instead navigate to another dedicated demo page. I understand your approach is clever but it's a distraction on the splash page when this should instead be dedicated to providing info on the product, not a playground for CSS.</comment></comment>


It's Your Data, It's Your Bot: It's Not A Crime - <AUTHOR> http://www.eff.org/deeplinks/2010/06/its-your-data-its-your-bot-its-not-crime

<comment><USER2> It is past time to start awarding prodigious damages against corporations who egregiously and willfully write unlawful provisions into their terms of use, consumer contracts, etc. etc.

Parsing and correctly interpreting pages upon pages of legalese presents an undue burden on a well functioning market economy. Corporations can slip clauses into agreements that can give them vast power over their customers who do not understand the full ramifications of what they are agreeing to. There is very little cost involved to the corporation that tries to get away with this. There is a very great cost to our society in tying up our court systems with stupid crap such as this.

The only solution is to make the cost of writing illegal provisions into contracts greater to the perpetrator than the potential reward. I know there will be unintended consequences to what I propose. But surely there must be a way to send a stronger signal to corporations who willfully push legal boundaries and seek to obfuscate exactly what it is that consumers are agreeing to?

<comment><USER3> One relatively simple way to do this might be to pass legislation saying that the terms and conditions can only be up to a maximum number of words which must be from a standard dictionary, with no links or supplemental articles permitted. This would encourage companies to be concise with their ToS, and discourage the use of "hidden clauses".

<comment><USER4> How about 140 chars ToS, Twitter style ...

         You give us the right to publish your data and you don't have access to
         anything else other than what the Facebook UI and APIs provide.

There, problem solved. Of course, writing this in legalese isn't so straightforward ... otherwise legions of lawyers and judges would be jobless. And they wouldn't be able to ban crawlers, other than search-engines ... and where's the fun in that?

</comment></comment></comment><comment><USER5> I can't believe that Facebook is attempting to go after people through criminal law, rather than civil law.

Wasn't the CTO of Facebook just saying less than a week ago that : "users have complete control over their data, and as long as [the] user gives an application explicit consent, Facebook doesn't get in the way of the user using their data in your applications beyond basic protections like selling data to ad networks and other sleazy data collectors?" [1]

I sure hope I'm missing something here.

[1] <http://news.ycombinator.com/item?id=1440154>

<comment><USER3> Facebook shouldn't be attempting to go after anybody, with any kind of law, if all they are doing is downloading their own data from the site.

</comment></comment><comment><USER6> We're making a tool for scraping websites, <http://siteparse.com>

As good web citizens we honor robots.txt, but these frivolous lawsuits make me think we shouldn't form a US corporation just to leave a much higher barrier to suing us. Which incidentally means no YC for us.

</comment><comment><USER7> So they expect what? A sort of proxy for the legislative process? Laws selected by the legislative branch of our representative government _ooorr_ anything we happen to put in our TOS. Same diff.

</comment><comment><USER8> So I'm an old guy who is hard of hearing and stubborn. But I'm also a programmer.

Being who I am, I write a bot that scans my FB profile and checks for birthdays in the family. If one is approaching, it flashes a light, yells at me, and calls me names until I buy a present.

According to FB, I'm a thief, no?

What if I'm a blind guy who made his own browser-helper because the standard tools don't work so well for me? Or I wrote a special FB access device that helps people with ADHD? Or I just like the color blue and want to see everything in the world in blue? Or what if i just write my automation on top of a standard browser that highlights any text that has my friends' names and downloads the surrounding paragraph to my desktop. Just because? Seemed like fun? What if I filmed myself (or a trained monkey) accessing my Facebook account? What if I took the film and extracted data from it?

I would argue that I am accessing FaceBook via HTTP and GET and POSTS. I use standard nomenclature and the standard stack from the O/S outward. Anything beyond that is none of their damn business. (Not trying to play to the crowd, but this is preposterous. The entire purpose of HTML is to separate the data from the way we access it)

<comment><USER9> Yes, you are are a criminal (not necessarily a thief), according to facebooks terms of service.

Of course, facebook would not prosecute you, but this is not the point. Facebook has been going after services that make it easier to delete your account, or move information to another service. This is what FB does not like.

Of course, what they are doing is completely disgusting, but facebook seems to be able to do whatever they want, and their users do not mind, as long as they don't change the profile screen too much. Then there is an uproar.

<comment><USER10> Or... what if you use a different browser? What's not automated about a browser? The line seems utterly absurd...

<comment><USER8> Yes. Even assuming FB is correct, they would then have to create a list of which browsers they consider "non-automating". Would GreaseMonkey installed on FF count? How about some VBA on top of IE? If I travel outside of net range and my browser caches up lots of FB pages overnight, does that count? Beats me. We'd all have to use pre-approved tools to access our FB accounts -- or face criminal prosecution.

It's not just that it is non-intuitive. Lots of legal things are non- intuitive. It's not even that it completely breaks the idea of HTML, even though that's pretty huge. It's not even that somehow by using FB I have given up my right to purchase and use my own equipment to browse the web, thereby limiting competition, although that is huge also. FB is actually trying to reserve the right to criminally prosecute me unless I use tools that are on a list that they preselect, and presumably update. So, logically, the first thing I'd like to do is see this list and find out how it is created and updated.

The entire purpose of software in this setting is to automate the retrieval and display of HTML based on my particular preferences, and in the time and configuration of my choosing. That's the way the web has worked ever since there was a web. That's why the the web is structured the way it is. That's why the web can continue to expand and grow.

I'm growing tired of attorneys on fishing expeditions.

</comment></comment></comment></comment><comment><USER11> I normally like to play devil's advocate, but in this case I simply can't come up with a decent argument to justify Facebook's position that they "own" your data. They can own the expression of your data on a Facebook page, but they can't own the data itself.

That's my understanding at least - am I in the wrong here?

<comment><USER12> That's not Facebook's argument. Their argument is that a contract exists with their user. In that contract, the user agreed not to use 'automated' means of access.

Then, when the user has Power perform automated access, Facebook claims that a criminal law violation has occurred, because that's unauthorized access under their terms. They want that to be treated just like other California Penal Code unauthorized access -- access like exploiting a bug or stealing someone's password to view or change info never intended for you.

EFF says only a contractual violation has occurred; violating some arbitrary company-chosen 'terms of use' shouldn't be enough to trigger criminal enforcement.

It's an interesting and difficult distinction. So many of these systems and terms are defined by the arbitrary choices of coders and lawyers. At one level of abstraction, it's against the will of the system provider -- Facebook -- so it could be seen like a break-in.

But at another level, it's just a contract, and Facebook has other contract- enforcement options short of criminal prosecution: cancel the account, sue for actual damages, and so forth. If Facebook can define what's a 'crime' via arbitrary clickthrough terms, suddenly users and Power staff could wind up in jail for a terms-of-use violation that had no other economic damages.

So the issues are tricky, but important.

<comment><USER13> I don't understand this bit about automated access. Isn't anything using their "Open Graph" accessing it automatically then?

<comment><USER14> The idea is that there is "unauthorized access" to Facebook's computers, that is, the user accessed Facebook's systems in some way that Facebook didn't like. Facebook wants absolute jurisdiction over who and what can see information stored on their servers and they want the civil justice system to enforce this will on their behalf after-the-fact.

Under Facebook's claims, people could get arrested for something as small as using a browser or operating system that Facebook didn't like. If this idea is accepted, then Facebook can pretty much say anything and if you violate that thing and then access Facebook, Facebook would seek criminal penalties for your violation. For instance, if Facebook says "no person that doesn't own a pair of Nikes can access Facebook, under our new Nike sponsorship deal", and someone who doesn't own Nikes still accesses Facebook, Facebook would consider this "unauthorized access" and get mad. Or, if Facebook decides it doesn't like born in Florida, and they write "No one born in Florida may access Facebook", and you still access Facebook after being born in Florida, Facebook will try to get the police to come and arrest you.

Open Graph API is not unauthorized access because Facebook allows people to use it.

<comment><USER15> _Under Facebook's claims, people could get arrested for something as small as using a browser or operating system that Facebook didn't like._

Under Facebook's terms, you could retrieve some Facebook pages from your cache, write a parser to parse your data and use it to harvest your data to a CSV file, and even this would be a violation.

</comment></comment></comment></comment></comment><comment><USER16> Please, somebody, create a facebook competitor! Don't wait for Diaspora; I don't think their idea will work for the average user. This market desperately needs competition!

<comment><USER17> Facebook only works because everyone is on the same site.

A competitor would never gain enough traction to reach critical mass (defined as when the average person has an account on both) without some help from facebook in the form of a stupid business decision. Or if they managed to think of some killer feature.

But simply a copy will never work.

And BTW, the main reason you hate facebook is because they are big. So adding a competitor will not help you - eventually they will get big too, and you will hate them as well.

<comment><USER2> "So adding a competitor will not help you - eventually they will get big too, and you will hate them as well."

Two big competitors are much better than just one.

<comment><USER18> not in this case. (Not for the users)

In one sense - facebook becomes a natural monopoly. Back in say 2007/8 I had to log in to both facebook and myspace to see what my friends were up to. Now I just have to use facebook. That is much simpler and easier for me as a user.

<comment><USER19> Maybe now, but a new competitor could do two things:

Be better in some way than facebook (not selling users private information would be an easy one) Make it so that you could see what you friends were upto on facebook, but without being a user yourself.

Suddenly you cracked the chicken and egg problem, which is exactly why facebook goes after this with the force of the law.

A monopoly based on technology never lasts, but if you can build one on some kind of legal issue, you are golden.

</comment></comment></comment></comment></comment><comment><USER15> How about a business opportunity? Modify an open source browser so that it lets someone navigate a website without being able to read anything on it or look at any pictures. Set up a Mechanical Turk style application that lets workers execute browsing sessions using the modified browser via VNC. The modified browser will save off all of the pages, which can then be parsed for information. The server will match up retrieved information with particular users. No worker will ever see any actual user data.

</comment><comment><USER20> I guess that this relates in some way to cases where newspapers complain about companies like Google indexing their sites and effectively repackaging their news stories - and where violating terms of service (civil issue) crosses into unauthorised access (criminal issue).

It all comes down to what precisely am I allowed to do with a publicly available web page? I'm allowed to use a web browser to access it (presumably), but when does something stop being a web browser and start being an automated tool? I'm not familiar with the tool in question here, but could it be argued that in some ways it's no different than a web browser that pre- fetches linked content?

</comment><comment><USER21> I need to give the EFF some money.

</comment><comment><USER15> Some outlaw hacker needs to make a name for him/herself by distributing a Facebook scraper desktop application that perfectly simulates user browsing.

</comment><comment><USER22> Everyone keeps saying that Google will become the "evil next Microsoft." I'd argue that Facebook is racing to that department a whole lot faster.

</comment><comment><USER10> I'm a gnu/eff booster most of the time. However, it's worth looking at more of the details here: [http://www.niallkennedy.com/blog/2009/01/facebook-vs- power-v...](http://www.niallkennedy.com/blog/2009/01/facebook-vs-power- ventures.html)

 _"Collecting Facebook usernames and passwords is at the heart of the dispute. Power.com impersonates a Facebook user after collecting their username and password."_

I would still side with power BUT a TOS that says "you can't give your password to third parties" is a bit different from "you can't use any automated processes at all".

<comment><USER23> That's interesting, but:

a) They are going after the third party, not the people that gave them their passwords, and

b) I believe Facebook also harvest passwords for other sites (hotmail etc)

c) In practice, there's not much difference between "Nobody can create a service that uses user's passwords to automate their Facebook access" and "You can't use any automated processes to access Facebook".

<comment><USER10> Uh sh __t...

I forgot the _Facebook harvesting passwords_ thing...

NOW that's _rich_... my qualms are gone....</comment></comment></comment>


Argyria: drink colloidal silver every day + turn yourself blue - <AUTHOR> http://en.wikipedia.org/wiki/Argyria

<comment><AUTHOR> Honestly, I can't believe my eyes: [http://www.youtube.com/watch?v=ahihGKZC5Kk](http://www.youtube.com/watch?v=ahihGKZC5Kk)

</comment><comment><USER2> Learn you some chemistry for great good.

Silver Chloride causes Argyria. Not colloidal silver.</comment>


Announcing O'Reilly's New Book: "NGINX: A Practical Guide to High Performance" - <AUTHOR> https://www.nginx.com/blog/announcing-oreillys-new-book-nginx-a-practical-guide-to-high-performance/

<comment><USER2> Of note: they're giving away free copies in exchange for contact info.

<comment><USER3> Plus, it's only a sample of the first 5 chapters.

<comment><USER2> Welp. That's what I get for not opening the PDF yet, I guess.</comment></comment></comment>


Funds Run by Robots Now Account for $400B - <AUTHOR> http://www.bloomberg.com/news/articles/2015-03-16/smart-beta-etfs-attract-billions-with-critics-blaming-dumb-money

<comment><USER2> "Run by robots" in roughly the sense that McDonald's is "run by minimum wage workers".

They're not talking algorithmic trading or any particularly sophisticated investment methodology (in a lot of cases their methodology is in their prospectus); it's just a slightly different programmatic weighting scheme. This has existed for a long time.

<comment><USER3> Agreed. The math for portfolio weighting maximization can be implemented in an Excel Solver. The bread and butter lies in identifying which specific market sectors to target.

</comment></comment><comment><USER3> Apologies in advance for hijacking this thread with a solicitation, but I'm currently seeking mentorship in this exact area. If anyone has experience in starting an ETF, getting it funded, listed with exchanges and distributing it to clients I really need to pick your noggin. Email in my profile. Thanks!

<comment><USER4> You'll need a lawyer specialized in the field. Check the SEC filings for ETFs similar to the one you want to start, they have the law firm listed.

It costs a lot of money and is a slow process, usually performed by professionals with many years of experience in finance. It's almost certainly a bad idea for you to pursue the idea.

</comment></comment><comment><USER5> What would happen if someone were to resolve the whole networks of debts, funds and obligations between all market entities? With such enormous amounts of cash (Apple has enough to buy entire countries, and these funds have more than enough money to buy out Greece) everything seems possible...

<comment><USER6> I'm not sure I follow.

What exactly do you mean by: '...resolve the whole networks of debts, funds and obligations between all market entities?'

<comment><USER5> Let's take a simple network of three parties A, B and C. A owes B 100$, who in turn owes C 100$, who in turn owes A 100$.

In theory, the debts cancel out each other... and the same can be done e.g. with debts of states. What I don't get is why we prefer to pay debts and especially interests when we could just take the debts and cancel them out where possible.

<comment><USER7> > What I don't get is why we prefer to pay debts and especially interests when > we could just take the debts and cancel them out where possible.

Working capital.

Perhaps you borrowed $100,000 and are obliged to pay that back at 10% interest. If you happen to have $100,000 in your pocket, perhaps you're better off using that $100,000 to generate additional revenue, which would hopefully show a better return that 10%, thus effectively covering the 10% interest on the loan and a small profit margin.

If you used the $100k cash to pay off the $100k loan you'd have no working capital, which would likely stymy cashflow and hamper further growth.

That's the theory anyway. You need money to make money and the one way to obtain money is borrowing.

<comment><USER8> If you cancelled out the cyclical/reciprocal debts then you'd still have the same amount of working capital as you'd pay back $X but also get $X back as a creditor.

</comment></comment></comment></comment></comment><comment><USER9> It seems that a group of humans have discovered how to automate vampirism.</comment>


Show HN: developeragents.com – curated newsletter promoting remote developers - <AUTHOR> http://www.developeragents.com/

<comment><AUTHOR> Highly appreciate HN community feedback!

We are building this site to give local communities a channel to promote local talent.

Eg. Meetup organizers who vouch for developers who are looking for a new remote gig.</comment>


Ask HN: Write tests for your infrastructure automation - <AUTHOR> I use Ansible to automate infrastructure configuration and deployment. Take graphite as an example. Graphite is made up of UI (in Django), Carbon (metrics processing daemon) and whisper (database).
Ansible created the instance, installed the necessary packages, templated the configuration files, created appropriate directories, added Nginx (access to the UI), configured supervisord to manage the django web app and carboon daemon, and a bunch of other things.
Each task/step in Ansible should tell me the state of the deployment (has config file A been changed? Have we reloaded carbon? Is carbon running?). I can also use Ansible to tell me whether or not http://graphite.internal.company is accessible and whether or not I can see the data coming through. I can also write a test in Ansible by sending dummy metric to Graphite over socket (to verify that I can actually send things to carbon and the data is then saved into whisper).
I also want to know if we rotoate our logs or not (yes sure we deployed logrotate config file yesterday and my policy is rotate daily, so the next day I want to check if rotation happened).
See, Ansible can do that. I can write plugins/modules to handle all the above.
But the question is, to what extend do people write tests for their infrastructure? There are probably a lot of things I question myself after deployment. Another thing is, sure I can write everything in Ansible, but would my tests be better off writing in my favorite language, and yes perhaps run using Ansible (especially if I need SSH access).
Because my end goal is to reassure myself, and eventually produce my own Chaos Monkey. How can I run Chaos Monkey if I only have the tests for applications, but no tests for infrastructure?
Thoughts? <comment><USER2> I like to think to myself "If I had to verify this server manually what would I check?" and write automated tests for those. Usually, it's a few high level/important checks for critical services, ports, packages, and users. For configuration files I check for one setting and if it's there assume the rest are correct. Ultimately, it's mostly going by gut and balancing level of effort in maintaining a test vs increased level of confidence in the deployment from having said test.

Some tools out there:

* [https://github.com/aelsabbahy/goss](https://github.com/aelsabbahy/goss) \- YAML, simple, self-contained binary, extremely fast.

* [https://github.com/indusbox/goss-ansible](https://github.com/indusbox/goss-ansible) \- Ansible module for goss, never used this, but you might find it useful

* [http://serverspec.org/](http://serverspec.org/) \- Ruby, most popular infra testing tool

* [https://github.com/chef/inspec](https://github.com/chef/inspec) \- Ruby, looks like an improved serverspec, almost same syntax, made by the chef guys

* [https://github.com/philpep/testinfra](https://github.com/philpep/testinfra) \- Python, don't know much about it, but mentioning it since Ansible is Python.

Spend a little bit of time experimenting with all of them, see which one you like.

Full disclosure: I'm the author of goss.

</comment><comment><USER3> I have similar thoughts. In the new SRE book[0], there is a history of Google's infrastructure automation, and in a way it started with tests:

First they had Python scripts to do things on various machines. (It actually sounds a lot like Ansible: lots of little scripts that all ran over ssh.) But because of high configurability, these didn't always work right.

So they wrote a bunch of tests, e.g. ClusterExistsInMachineDatabase, DNSTestHasBeenAssignedMachines, so they could find out what wasn't right when a new machine had been provisioned.

Then they realized that fixing the tests could usually be automated, so they wrote code for each test, to correct the issue if it was failing.

It seems like they sort of backed into a declarative idempotent configuration management solution like Chef or Puppet, where you say what you want the machine to look like, and the config management is responsible for getting you there.

As I think you are feeling, in config management, the redundancy of tests and automation code is a bit more ... redundant ... than with automated tests for development.

I think monitoring/alerting is another kind of test: Is the database up? Is the web site responding?

Another good story from that book is how one internal database never went down, so teams became lax about designing systems that would still work without that component. So Google decided they'd just take the database down for a bit. :-) It sounds a bit like their version of Chaos Monkey.

[0] [http://www.amazon.com/Site-Reliability-Engineering- Productio...](http://www.amazon.com/Site-Reliability-Engineering-Production- Systems/dp/149192912X/)

</comment><comment><USER4> Depends on the criticalality of getting this right without errors is, how often this deploy is going to be run, and how much time is needed to deliver this.

I'm not sure what Chaos Monkey is, but I come from an operations background, where I moved to a devops role, and automating the infrastructure builds. Testing is essential. There is no need to differentiate best practices if you're coding for the application or the infrastructure.

As you said, checking each state of the deployment should be done, I'll do pre-checks to make sure the filesystems have the needed space for the MW component, etc. I'll check each phase, and break down the phases via functions much like a developer would for application development. This helps keep my code reusable, and easy to read for other admins. It's much easier to rerun/correct one function that fails on a deployment than have to go through the entire setup again.

I'd write the test in whatever language is doing the deploy, as I test while it's deploying.

From there, it's good to have some type of audit you can run against your infrastructure, to check versions, mount points, and changes. It can be a mess when someone updates one server, but the rest are slightly different. You'd be surprised how often this happens and eventually development environment looks different than prod, and people are wondering why the applications behaving differently.

I can go into more detail later on, but hope that gives you a feel for it!

BTW, I'm at a large enterprise so these deployments and installs are on an enterprise scale, which makes it worth getting it right in the automation piece, as the person running it isn't always an expert on the automation, or the infrastructure itself. Get it right the first time or log what broke will save a lot of head aches later on.

</comment><comment><USER5> I write tests for my own servers, via the ruby gem ServerSpec. It's generally something I let lapse over time, but I always ensure that I update the tests before I'm applying a distribution update.

Allowing myself to validate that a Wheezy installation of Debian has all the services running that I expect after I upgrade it to Jessie is very useful and reassuring.

I wrote a brief introduction to the process here:

[https://debian- administration.org/article/703/A_brief_introd...](https://debian- administration.org/article/703/A_brief_introduction_to_server- testing_with_serverspec)

</comment><comment><USER6> I wrote this tutorial on infrastructure automation and it uses py.test for things, but honestly I don't think the tests are very good...

[https://amfarrell.com/saltstack-from- scratch/](https://amfarrell.com/saltstack-from-scratch/)</comment>


How broadband pay-per-use will change web apps - <AUTHOR> http://gigaom.com/2010/12/12/predictions-2011-if-pay-per-use-comes-to-broadband-then-what/

<comment><USER2> Almost the entire article is BS.

We've ALWAYS had tiered broadband in Australia, and none of these things have happened. The one exception is Peak/Off-Peak usage. Yes, we schedule downloads after hours...but now with every ISP offering fairly healthy download caps, even that is a non-issue for most of us.

It hasn't made me want to "buy" instead of "rent" video content. Peer to Peer is not sending us all broke. We aren't all caching our data at our front door. We don't expect every website to suddenly start compressing their JS scripts. We don't all project our monthly usage. And I most certainly aren't concerned about streaming.

Most of the article is nonsense. The only REAL implication is that people who don't need to 500Gb of data, don't pay for 500Gb of data. Everyone else can.

Probably the only side-effect of the limited downloads is certain ISPs offering "quota free" downloads. E.g. Bigpond customers can download Bigpond movies without being charged for the data. IINet has streaming TV, also without data being counted. But these are nothing more than "value adds".

<comment><USER3> The other important quota free value add that is fairly unique to Australia is ISP run game servers. Most of the major ISPs run large numbers of free game servers. These are historical benefits though, I think we're reaching the kind of bandwidth costs where people are less concerned with whats on the quota free list.

</comment></comment><comment><USER4> Am I the only person who thinks we're getting screwed in the US? I mean, I keep reading about how Asian countries have internet that is 100x faster than ours after we dumped billions of dollars into helping them upgrade their networks (which they didn't do), and now the big internet companies want to put restrictions on our use of broadband, or in effect, charge us more for the same crappy thing we've always gotten.

Maybe I'm being emotional, but maybe it's just bullshit.

<comment><USER5> I don't know about broadband, but as far as I can tell, you _are_ absolutely getting screwed on mobile phone and internet rates. They're _so_ much cheaper in much of Europe, and probably even more so in Asia. Competition is so fierce that calls here tend to be cheaper than the termination fees the network operators pay each other for routing the calls to one another. And they're still making massive profits.

I don't know why this is, by the way. A big problem is that the frequency bands are a finite resource which rarely makes it back onto the market once sold. The other issue is that a network with limited geographical coverage isn't as competitive; these two facts caused the "land grabs" when the GSM and 3G frequencies were being sold in various European countries. New players haven't joined the fray outside those periods; LTE doesn't seem to have introduced any new players, probably because the markets are now oversaturated and well served. The infrastructure investment would be immense. There _are_ new resellers who rent access to the big networks, though.

Still, most countries seem to have 3-5 national operators, and competition among them is alive and well in many cases. No idea why it's stagnated in the US. You'd think one of the operators would slash prices to try and eat away market share from the others.

<comment><USER6> Density plays a big role in the cost of the last mile deployment. In urban Japan you can reach thousands of customers in a square mile as compared to a few hundred (or less) in typical suburban America.

Though that still doesn't account for places like New York costing just as much.

<comment><USER7> Without knowing the details, is it possible that internet in NYC cost as much as in the 'burbs because the ISP is a regulated utility? Are they allowed to charge different rates within a state?

</comment></comment></comment></comment><comment><USER8> Some of these seem actually well thought out, but some of them feel pretty unrealistic. I don't think most of these are actually going to happen. My guess is that the bandwidth tiers will be somewhere pretty high so that it only causes problems for big downloaders. Most "Web 2.0" (think Google Docs) apps are already pretty modest with their bandwidth usage - you can use them pretty well even in mobile data networks, so I don't think that's going to affect people's behavior that much. I'd say streaming video and bittorrent would suffer the most from these caps.

<comment><USER9> I doubt much/any of this will come to pass, speaking as someone who has always had to deal with download limits, it's really not THAT big a deal.

We here in Australia have been subject to tiered broadband pricing since day 1 - I feel pretty comfortable in saying that whatever pricing US carriers come up with, it will be much lower than here in AU, simply because you don't need to haul most of your data thousands of KMs via undersea cables. My ISP has a range of ADSL2+ plans from AU$50/month for 150GB data through to AU$120/month for 1TB data. (There's also an entry level 30Gb for $30 plan for your grandparents)

<comment><USER10> >(There's also an entry level 30Gb for $30 plan for your grandparents)

I managed to find a real unlimited connection (here in England) so I might be a little out of touch with broadband allowances, but I think 30GB is on or above the high end of what you can get here in most places without spending a mint. Of course, they all label it as 'unlimited', which apparently is legal despite being very blantantly fraudulent advertising.

Hell, T-Mobile recently sent me some blurb trying to persuade me to replace my ADSL with their 'unlimited'* mobile broadband.

* Fair use policy applies. Bandwidth is limited to 3GB/month.

<comment><USER11> 30Gb is pretty low end here (Australia). Eg, here's a price list for Internode: [http://www.internode.on.net/residential/broadband/adsl/easy_...](http://www.internode.on.net/residential/broadband/adsl/easy_broadband/plans/). The base plan is 30Gb/month for $40, the high end is 1Tb/month for $130.

iiNet's base plan is 20Gb/month for $30: <http://www.iinet.net.au/broadband/plans.html>

Telstra has a 2GB/month plan for $10, but that is really just there so they can price gouge people who don't know better: [http://go.bigpond.com/broadband/?ref=Net-Head-Int-Plans- Broa...](http://go.bigpond.com/broadband/?ref=Net-Head-Int-Plans-Broadband)

I don't know what lets T-Mobile sell 3Gb as "unlimted", but they wouldn't be allowed to call it that here.

</comment></comment></comment></comment><comment><USER12> There's a really easy solution to all the noise ISPs are making about bandwidth.

If a provider wants to sell me a 384kbps line, they should offer 120 gb per month. If they want to advertise a 20 mbps line, they should sell me 6.3 tb per month. If they can't provide the capacity, sell me a slower line and I'll be happy when I get bursts of speed. Regional monopolies should be compelled to have transparency in pricing.

<comment><USER13> That kind of "transparency" would likely require US ISPs to reduce advertised speeds 10x overnight, enraging millions of customers.

<comment><USER14> Isn't that a good thing? I mean, if the ISP can't actually satisfy the demands of every user at a given level of service, then why is it allowed to advertise that level of service at all? Its a bit like a sports stadium saying, "Yeah, we can seat 50,000 people, provided they don't all want to see the same venue."

<comment><USER15> It's called oversubscription and it's a very common practise. Statistically, not all of the ISP's customers are going to use all of their quota every month, so why should the ISP provide enough bandwidth to allow them to? That just means they're spending far more on infrastructure than is really necessary to service their customers' actual requirements.

Also, why should the quota be tied to the speed? When I want to download a movie, I want to download it as quickly as possible, but that doesn't mean I want to max out my bandwidth continually.

</comment></comment></comment></comment><comment><USER16> The problem with metered internet billing is that the service isn't treated as a utility like power and water are. There would be no restrictions on service providers violating customer rights - and they generally have a defacto monopoly wherever they operate (a single provider to a building, etc).

</comment><comment><USER17> Here in Australia we've always had data caps. You have to take this in to consideration every time you use a streaming service (still never stopped us).

</comment><comment><USER18> I pay $120 a month for 40 gigs of admittedly quite fast internet here in NZ. WTF is this guy talking about. Bloody americans

</comment><comment><USER19> One place where this is the case is when developing Kindle apps using the SDK. From <https://kdk.amazon.com/>:

"Active content applications that are smaller than 1MB and use less than 100KB/user/month of wireless data may be offered at no charge"

How apps are priced takes into account their data usage over their lifespan.</comment>


Defense Primer: Military Use of the Electromagnetic Spectrum - <AUTHOR> https://crsreports.congress.gov/product/pdf/IF/IF11155 <comment><USER2> That's an interesting read...</comment>


Show HN: CouchSurf.in a passive way to surf the web - <AUTHOR> http://www.couchsurf.in/next

<comment><USER2> Good work. I almost got hooked to it. But there are many out there doing the same job.</comment>


Quick hack to focus all parts of a Lytro image - <AUTHOR> http://nirmalpatel.com/hacks/lytro.html

<comment><USER2> Great hack, nirmal. I've been wanting to tear apart the Lytro image in depth as their own software for it is pretty... well, you've used it. :)

</comment><comment><USER3> Very cool hack. I've always wondered what format the Lytro data was in.

<comment><AUTHOR> Sadly I haven't had time to dig into the full data file. Hence the quick hack using a few jpegs instead of all of the data. :)</comment></comment>


Ask HN: What is the current best-practice for authentication for Apollo/GraphQL? - <AUTHOR> <comment><USER2> 1\. Create a login mutation which creates a session and sends back a cookie.

2\. Use resolver middleware to check whether the user is authenticated.

I like to use express-session ([https://github.com/expressjs/session](https://github.com/expressjs/session)) for part 1 and graphql-middleware ([https://github.com/prisma/graphql- middleware](https://github.com/prisma/graphql-middleware)) for part 2.</comment>


Mozilla hiring Aza Raskin and two others from Humanized - <AUTHOR> http://www.techcrunch.com/2008/01/15/breaking-mozilla-buying-humanized/

<comment><USER2> Ohh Humanized! That's one small company I admire for quite some time. I guess I'm a sucker for their Human centered interfaces and designs.

</comment><comment><USER3> I think this holds great promise for browser users and, by extension, web developers. The closing line of a blog post by Guido came to mind:

<http://www.artima.com/weblogs/viewpost.jsp?thread=4790>

 _"I'm looking forward to Jef's Humane Browser!"_

Let's see..

<comment><AUTHOR> Just as long as it doesn't replace the mouse with holding down the caps lock key and typing commands...

</comment></comment><comment><USER4> That's odd. A foundation buying a software co?

<comment><AUTHOR> Erick Schonfeld was a little off; he edited the article after a statement from the Mozilla CEO.

 _Mozilla has hired 3 of the principals from Humanized. They will be joining the Mozilla Labs team on January 16, 2008. We expect a lot of innovation work from them, some Firefox-related, some broader, just like everything else in Mozilla Labs. This was not an acquisition. No premium was paid and no intellectual property was acquired by Mozilla._

 _The work done by the Humanized principals speaks for itself -- there are lots of great, web-relevant ideas in their work and we're excited to have them join Mozilla._ \--Mozilla CEO John Lilly</comment></comment>


Wikipedia is Adding a Love Button Next Week - <AUTHOR> http://www.readwriteweb.com/archives/wikipedia_to_add_a_love_button.php

<comment><USER2> Couldn't editors be equally motivated by a demonstration that people are finding and reading their articles? Wikipedia could release unique-visitor and time-on-page metrics, and instantly make editors feel super valued.

WikiRank used to be a super useful tool for this. I've no idea where they got their data from, but it was fascinating.

<comment><USER3> Yeah, also maybe some ownership to, to most reading wikipedia it appears as a data source that all comes from an unknown source. Sure you can dig a bit and see who added what to each article, but maybe it would be good to list contributors, especially if something is primarily the effort of one person somewhere prominent in the articles.

<comment><USER4> One of the central tenets of Wikipedia is that there is no ownership. This is intended to mean that no editor had any authority over any other editor when it came to article content, and anything like what you're suggesting would conflict with that.

</comment></comment></comment><comment><USER5> "Like" on facebook

"+1" on google

"Check-in" on foursquare

"Tweet" on Twitter

Have we become binary? It seems everything is done to lower the barrier of creating content. NFC will drop that barrier further down and we will live our lives while creating data.

<comment><USER6> I think the logical conclusion will be a YC '13 startup that aggregates and streamlines all your different karma/points/favs/likes/checkin accounts and implements NFC into it all for points across the board. Integrate it IRL by giving points for things like "I brushed my teeth twice", "I filed the TPS report", "I got my sister a birthday present". And by then, IPv6 would be fully rolled out and everything (right guys?), even your toothbrush, would have its own IP and small nano chip with a minimal TCP/IP stack to tweet/checkin/+1 your life-game account on namb.ly (YC '13). The line between what is Real and what is part of the great RPG of life we all become part of gets further blurred with the further advancement of augmented reality and its ubiquity in our phones, glasses, contact lenses, electric car windshields, and holographic advertisements everywhere. The future is going to be a blast.

But as always, things progress and get amazing and we live in yesterday's future, yet no one is _that_ impressed. I fear the day we go meh to the RPG of life that will inevitably develop in the future. Only then will we reminisce and wonder, "what was it like to be truly human?".

<comment><USER7> If mediocrity is your thing, then collecting karma (for brushing your teeth? haahhaha) sounds great! Or if you're a herd animal for that matter.

I hope the future will be more than just decadence and the denial of life.

<comment><USER8> Some of my friends make fun of me for having as much faith in humanity as you do.

</comment></comment></comment></comment><comment><USER9> Awesome. I feel appreciation is one of the main reasons why I'm much more willing to write content on Quora than Wikipedia. Hopefully this will change that!

</comment><comment><USER10> It seems to suggest that only registered users can 'love' an article. If it could be done by anyone you just know it would be organized so that the most loved articles were child porn, nazis, santorum and similar.

<comment><USER11> I was thinking that it was going to be about 'love'-ing an article or topic, too, which would mean awkward pledges like 'I love bone cancer!'. Being interested in a topic does not mean you 'love' or 'like' it.

However, upon reading the article, this is not about marking articles, but rather a way to send accolades to fellow Wikipedia editors.

</comment></comment><comment><USER12> "Wikipedia is Adding a Love Button Next Week"

like, a clitoris? let's hope not, men will never be able to find it.

</comment><comment><USER13> Good, this must mean they've solved the deletionist problem and have moved on to other things more important...oh wait, they haven't.

 _sigh_

</comment><comment><USER14> And next up is the "gotta have it" button.

 _please, someone get this joke._</comment>


Speeding Up Your Python Code - <AUTHOR> http://www.maxburstein.com/blog/speeding-up-your-python-code/ <comment><USER2>
        Not only is it slightly faster but you also avoid storing
        the entire list in memory!

Actually that won't help when you need a big list and need to store it in memory. Python is really akward with this kind of scenario. Doing calkulations with Maps of Lists is definitiv (extremly) faster in the JVM, C++ whatever. Python is good however some use cases are definitv not in favor of Python. I mean some could drop to C/C++ for that and pass Pointers around so not the biggest problem.

</comment><comment><USER3> Writing the first examples in a more idiomatic style would better demonstrate the timing differences. The list construction isn't really noticeable at that size.

      def generate(num):
          for i in xrange(num):
              yield random.randrange(10)

      def create_list(num):
          return [random.randrange(10) for i in xrange(num)]

Also worth noting that functional programming in Python (e.g. inlining loops) is often faster.

      from future_builtins import map
      import itertools

      def generate(num):
          return map(random.randrange, itertools.repeat(10, num))</comment>


Portrait of the Author as a Historian: Fernand Braudel (2016) - <AUTHOR> https://www.historytoday.com/archive/portrait-author-historian-fernand-braudel <comment><USER2> Reading about historians referenced from HN took me to Henri Pirenne who is mentioned in this piece. I will definitely read Braudel next, the scholarship/erudition/opinion balance looks like what I'm looking for.

</comment><comment><USER3> great review of one of his books here: [https://www.reddit.com/r/slatestarcodex/comments/8bypq0/read...](https://www.reddit.com/r/slatestarcodex/comments/8bypq0/reading_notes_civilization_capitalism_15th18th/)</comment>


Reproducing Bloomberg Featured Article about Bitcoin Using VueJS and Axios - <AUTHOR> https://radicalrafi.github.io/cryptominal/ <comment><AUTHOR> Source Article : [https://www.bloomberg.com/features/bitcoin-bulls- bears/](https://www.bloomberg.com/features/bitcoin-bulls-bears/)

Scroll down to see the preview ,I loved the fresh design they made using ReactJS (apparently) and decided to reproduce it using VueJS</comment>


Special PROMOTION  Formsfield.com // First product sale GUARANTEED up to 10€ - <AUTHOR> http://www.formsfield.com/page/join-our-community <comment><USER2> For 10€ I guess you'll get a lot of spam. How do you filter spammers?</comment>


First class graduates Kurzweil's Singularity University - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/08/27/BUUQ19EJIL.DTL&type=tech

<comment><USER2> Is is just me or did the project seems a bit mundane? The introduction is about biotech and nanotech, etc, and the projects are mobile apps, scaling up 3D printing, and smart traffic. Anyone else underwhelmed? Maybe I had unreasonable expectations.

</comment><comment><USER3> Kurzweil articulated many of his early ideas on Singularity at an AI symposium held in 2001. RealPlayer video of all the sessions used to be available through Dr. Dobb's Journal's TechNetCast feature. I watched them all and they were very, very interesting -- both for and against. Great stuff.

I tried to locate a link to them for this post but TechNetCast seems no more and DDJ's site doesn't bear fruit either. If anyone here knows where they might be found please share -- they are definitely worth the time.

Since then, Kurzweil has certainly pursued his beliefs (books, speeches, press, etc.) with these graduates being the latest expression of those ideas.

<comment><USER4> My introduction to Kurzweil was this lecture he gave at MIT in 2005:

<http://mitworld.mit.edu/video/327/>

I then read The Singularity is Near.

I tend to agree more with Eliezer Yudkowsky and Michael Anissimov than Kurzweil about this stuff, but the video above is still worth watching (much much better than his TED video, which was too short to allow him to make his main points).

</comment></comment><comment><USER5> My first reaction was that if you're going to live forever, why rush to graduate, there's plenty of time. Then when I read the article, I saw that they are looking at all kinds of other opportunities. Good stuff.

<comment><USER6> Not everyone expects that the singularity will be survivable. Extinction still seems the most probable outcome.

<comment><USER7> this is why I don't understand the "nerd utopia" line. it seems that the vast vast majority of possible non-human intelligences would have goals directly harmful to human goals (even modest ones). It seems like the best we can hope for is a _really_ nice zoo.

<comment><USER8> If you said that about a topic you're familiar with, it sounds silly: it seems that the vast vast majority of possible computer programs would have goals directly harmful to human goals (even modest ones). The vast majority of possible medical treatments, proteins, DNAs, etc. would be directly harmful to human goals, and yet we keep on trying, cognizant and wary of these ramifications.

Granted, there are "irresponsible" researchers who don't understand that an AI might not have "gratitude" that prevents it from rm -rfing humanity like a bad shell script, but others work on 'Friendly AI' to mitigate or eliminate this concern.

[http://en.wikipedia.org/wiki/Friendly_artificial_intelligenc...](http://en.wikipedia.org/wiki/Friendly_artificial_intelligence)

<comment><USER7> the things you mentioned would be harmless, not harmful. at worst they would waste some resources. they certainly wouldn't requisition resources by force (unless you want to talk about ideology as a "technology" :)

<comment><USER6> Er, prions, viruses, bacteria, runaway breakout of monoculture -- these things use up resources, and have the potential to cause great harm. It's just that few of them are likely to rise to the level of existential threat, while in the field of recursively self-improving AI, the likelihood is strongly the other way.</comment></comment></comment></comment></comment></comment>


Travelers Fear TSA's Groping...Almost As Much As Losing Five Minutes - <AUTHOR> http://blogs.forbes.com/andygreenberg/2010/11/22/travelers-fear-tsas-radiation-and-groping-almost-as-much-as-losing-five-minutes/ <comment><USER2> USA population is concerned about privacy much less than let's say European population. No wonder they do not see this a serious issue. I personally firmly believe - no privacy => no freedom.</comment>


Ask HN: Can early adoptors be large companies? - <AUTHOR> Im drawing out my lean canvas now, and wondered for anyone who has done it - has anyone had large companies as an early adopter (say large meaning fortune 1000 or 2000)?<p>Are large companies always considered to be part of "late majority" How did you do it? <comment><USER2> You want to read the book "Crossing the Chasm" if that's who you're thinking of targeting. And just keep in mind you're going to need funding to go after that market.</comment>


Why People Who Sleep Longer Achieve More - <AUTHOR> http://michaelhyatt.com/sleep-longer-to-achieve-more.html

<comment><USER2> And most importantly, sleep helps clean "brain junk" (layman terms intended)

See [http://www.sciencemag.org/content/342/6156/373](http://www.sciencemag.org/content/342/6156/373)</comment>