Fluentd: a high performance unified logging layer - <AUTHOR> http://www.linux.com/news/enterprise/high-performance/147-high-performance/847237-fluentd-a-high-performance-unified-logging-layer <comment><USER2> Heka by Mozilla is another alternative - [http://hekad.readthedocs.org/en/latest/](http://hekad.readthedocs.org/en/latest/). I have been running in production to ship docker logs to our Elasticsearch cluster.

<comment><USER3> Heka's really nice, and the lua sandbox makes it easy to write new codecs.

We (OVH) recently tried Heka to push syslog data into Kafka, but it eventually kept crashing under load. Other alternatives were way to slow for our needs.

So we ended up writing a simple tool, not as flexible as Heka but about 10 times faster [https://github.com/jedisct1/flowgger](https://github.com/jedisct1/flowgger)

</comment></comment><comment><USER4> > We will go through the installation process, basic setup, listen to events > through the HTTP interface, and look at a simple use case of storing HTTP > events into a MongoDB database.

...and I'm out.

<comment><USER5> One of the maintainers of Fluentd here. Care to elaborate?

<comment><USER6> step1: build useful tool for serious people

step2: mention mongo

step3: enjoy having the room to yourself

:-P

<comment><USER5> I'm not here to really defend MongoDB, but the amazing thing about MongoDB is that, despite all the vitriol against it, it continues to be used at companies and projects that are far greater than what many naysayers ever touch: Stripe and Wish.com immediately come to my mind.

Also, I am giving MongoDB the benefit of the doubt per Curt Monash's law of databases:

Rule 1. It takes at least 7 years to build a database

Rule 2. You are not an exception to Rule 1.

<comment><USER7> I worked at bitly for a couple of years, we used mongodb for one of our secondary datastores. We had the expertise to keep it working, but we really hated it.

It's this funny situation where some engineer starts off using it because it's very convenient to run, and maybe the data model is convenient. You scale it up a bit, debug it, tune it, stuff you'd have to do with any system. At the point when you're sure mongo really sucks, it's too late. The business and even technical management side always prioritizes some other project over replacing it, even though you spend a surprising amount of time each month maintaining the mongodb cluster (performance degredation that compaction doesn't completely fix, and other stuff...).

I get the sense that with 3.0.3 or so, mongodb is a real database now. But it's been years of pain and false advertising. I'd still always vote against it. (Even though at my current place some people started using it for a service... :(

</comment></comment></comment></comment></comment><comment><USER8> I'm just starting to adopt fluentd but I'm scared by the fact that the "official" drivers have different interfaces and unclear leadership.

e.g.

[https://github.com/fluent/fluent-logger- php](https://github.com/fluent/fluent-logger-php) [https://github.com/fluent/fluent-logger- python](https://github.com/fluent/fluent-logger-python)

and a bit of drama

[https://github.com/fluent/fluent-logger- php/issues/36](https://github.com/fluent/fluent-logger-php/issues/36)

<comment><AUTHOR> note: I am one of Fluentd maintainers.

There is nothing to be scared:

\- Fluentd is an enterprise solution already adopted by thousands of users.

\- Fluentd is sponsored and made by Treasure Data[0] where we collect around 800k events per second.

\- You have to make a difference between what is official and what is third party. Fluentd have more than 300 plugins and is likely that you will find some differences on how each extension is used, but at the end everything is compatible. We make sure to maintain a clean list[1] of functional and maintained extensions.

\- We lead the project and we invite you to reach us anytime through our mailing list or other communication channel[2]

reach us anytime :)

[0] [http://www.teasuredata.com](http://www.teasuredata.com)

[1] [http://www.fluentd.org/plugins](http://www.fluentd.org/plugins)

[2] [http://www.fluentd.org/community](http://www.fluentd.org/community)

</comment></comment><comment><USER9> > Its built-in reliability through memory and file-based buffering to prevent > inter-node data loss have...

I wonder if we can expect "Call me maybe - fluentd" from Aphyr soon. ;)

</comment><comment><USER10> This feels like they are trying very hard to avoid calling their syslog a syslog, probably with good reason. A lot of distributions provide a very minimalist build of whichever syslog daemon they've decided to use, and as such, people get the idea that syslogs can't write to databases, or parse json, or listen on pipes or any other number of things modern syslogs can do.

<comment><USER5> >This feels like they are trying very hard to avoid calling their syslog a syslog

I _wish_ rsyslog and their friends were really that easy to extend, and I say this as a maintainer of Fluentd. Fluentd came about precisely because syslog family of data collectors fall short in certain ways:

1\. tag-based data routing: as you get more and more data sources, it becomes very important to keep track of what goes where. In my view, this is one of the key reasons Fluentd is used at many companies, and why Kafka has become popular on the message queue side (topic-based stream modeling)

2\. Extensibility: afaik, it's not all that intuitive for most programmers and sysadmins to extend and add new inputs, outputs, filters, etc. for rsyslog and/or syslog-ng. Admittedly, this is a subjective point, but looking at both Logstash and Fluentd's vast lists of plugins [1][2], I feel justified to make this claim.

3\. Configurable transport logic: I've never met anyone who is happy with syslog's buffering and/or failovers. Because we've heard so much about this particular problem, when we were building Fluentd (...4 years ago), we took extra care to make buffering and failover easy to configure and extensible.

Happy to answer more questions =D

[1] [https://www.fluentd.org/plugins/all](https://www.fluentd.org/plugins/all)

[2] [https://github.com/logstash-plugins](https://github.com/logstash-plugins)

</comment></comment><comment><USER11> For years I've been considering coding a tamper proof logger, something where each entry has a hash that depends on the entry's log and the hash of the previous entry. This could help detect potential system compromise.

I haven't really taken the time to look for a logger with such a feature, it would be nice to know if fluentd has something like this.

<comment><USER7> systemd's "journald" does this, it's called "Sealing", and it's enabled by default.

I turn it off on my stand-alone systems, it's a waste of processing on them IMHO (particularly if you don't backup the sealing key)

</comment></comment><comment><USER3> I've been using Fluentd for years, and it's a super useful tool.

It initially had some memory leaks that prevented us to use it in production, but it's now very stable. Writing new input/output plugins is extremely simple. And yes, it's written in Ruby, but give it a spin before judging; it's fast enough for most needs.

</comment><comment><USER12> Is there any benefit/disadvantage between fluentd and logstash ? I am not using either one, but I'll need to centralize my logs soon. My understanding tells me that these are two very similar projects, but I might be wrong.

<comment><USER13> They are similar but fluentd has cleaner conf IMO.

Interesting that graylog (an endpoint for fluentd) are providing their own log collector now.

</comment></comment><comment><USER14> Isn't Fluentd in Ruby though? It's 2015 and we need something like this in Go [0] [1] or Rust [2].

[0] Heka: [https://hekad.readthedocs.org/](https://hekad.readthedocs.org/)

[1] Chainsd: [https://github.com/mikeszltd/chainsd](https://github.com/mikeszltd/chainsd)

[2] Flogger: [https://github.com/jedisct1/flowgger](https://github.com/jedisct1/flowgger)

<comment><USER15> Why does the language it's written in matter? If it has the features you want, the reliability you want, and performs well given the load you're applying - that should be enough, no? It's not like we're embedding it into an app we're writing.

<comment><USER16> Well, in terms of maintenance it's a little bit more work.

Sure, it has the features and reliability. But does that really justify having to maintain a completely new environment? Maybe it does, maybe it doesn't; it depends.

No you may not be embedding it in your app, but it's now a part of your stack. You'll need to keep an eye on updates, etc for a completely different environment.

Plus there are other factors, like approved languages. Certain companies only allow using languages X and Y. Don't even think about language Z. I had to re- write an 80loc Python script to a much larger Perl one because I just didn't grok Perl all too well at the time. It didn't matter that Python was installed on the system. All that mattered was that Perl was approved and Python was not.

<comment><USER15> Valid points.

I'd like to address the "completely new environment" issue though. That should only be considered if you're thinking of owning and modifying the component. There are many software packages that you're going to use as-is, and interact with only via an API or CLI. In those cases the depth of the API/CLI, the quality of its documentation and the strength of its community matter way more than implementation language. (For example - who cares if nginx is written in C although your entire stack is Python or Java?)

If you're thinking of continually making changes in a package however - that's a different matter.

</comment></comment></comment></comment><comment><USER17> I started building something of similar concept a while ago. But had to pause the development for some time. It is written in Go, so much easier to install etc. It has plugins for Hadoop, Mongo, RabbitMQ, File and stdout :) Can take data from tail, HTTP, RabbitMQ, heartbeat and other chains.

[https://github.com/mikeszltd/chainsd](https://github.com/mikeszltd/chainsd)

<comment><USER3> "much easier to install etc."

Fluentd is extremely easy to install. They provide packages with everything you need; you don't even have to install Ruby beforehand.

<comment><USER17> Sure, that is not the best point, but I like to have as little stuff as possible installed and polluting servers with Ruby doesn't feel right to me. Of course this is just a personal taste.

</comment></comment></comment><comment><USER18> We'd love to use a ruby-based solution like this, but the docs say it will lose data whenever the receiving end crashes. Any plans to fix that?

The way it was described in the docs gave me the impression there is no acknowledgement of network writes - if that's true won't even clean shutdowns lose data sometimes?

<comment><USER19> ACK of network transfer is available ("require_ack_response" option). This option ends up choice of at-most-once semantics vs. at-least-once semantics. You need to choose and you can choose.

Fuentd provides "buffer_type file" to buffer records on disk. Shutting down won't loose data. If you need to choose memory buffer for performance reasons, fluentd enables "flush_at_shutdown" option by default.

You would also want to use <secondary> feature. This lets you to write a buffer chunk to another storage if the primary destination is not available "retry_limit" times.

Those concerns would be solved by the document: [http://docs.fluentd.org/articles/out_forward#buffered- output...](http://docs.fluentd.org/articles/out_forward#buffered-output- parameters)

<comment><USER18> Ah, thanks - require_ack_response sounds like what I was missing. Some blogs are from before this was added in 0.12 so I didn't know about it.

I am still interested in forwarder failure cases - I have replied to kiyoto's comment talking about the HA docs, which still talk about some other cases that can lose messages.

In this case:

* The process dies immediately after receiving the events, but before writing them into the buffer.

Is it possible to require acknowledgement that the log event has been written to the buffer? Is that separate to what require_ack_response does?</comment></comment></comment>


Next crash will be 'worse than the Great Depression': experts - <AUTHOR> https://nypost.com/2018/09/22/next-crash-will-be-worse-than-the-great-depression-experts/ <comment><USER2> Perhaps a better title might be "Economic commentator Peter Schiff thinks an economic crash is due."

"Experts," might be misconstrued to imply consensus, when this article doesn't appear to cite a representative sample, but two individuals.

<comment><USER3> Don't disparage the opinion of the man who predicted 11 of the last 3 recessions

</comment></comment><comment><USER4> I can't be the only one who thought this would be an internet of things article.</comment>


Ask HN: Can Google aggregate everything you've ever posted anonymously online based on writing style? - <AUTHOR> I'm just asking about Google because they're in such a good position to do it.
Is any private company doing it? It'd be neat if there was a web site that you could submit some writing samples (emails or whatever) and then see everything else that person has posted online (regardless of whether it was anonymous or not).
I'm sure there's no way to do it with total accuracy, but with enough input shouldn't it be possible to be highly accurate?
Anyone know of any software that can take a large number of writing samples and determine who wrote which ones?
If not, how would you go about creating it? <comment><USER2> I did really simple analysis in an AI class with several thousand posts of a forum I post frequently at, tagged "me" and "not me" (I figured that way it would be minimally invasive to people not participating -- plus, hey, easy naive Bayesian). Got fairly decent results with pretty trivial sample inputs. Numbers elude me, it has been years.

Everyone thinks "Aha, you have some catchphrases" (I do) or "Aha, you were one of the only Republicans and thus someone saying 'death tax' was more likely you" (true) or "You cited nationalreview.com more than the rest of the forum together" (true), but it turns out the distribution of really stupid stuff (stopwords, essentially) works better.

This is ironically the same they've discovered for making female/male authorship decisions, although I never went the next step and said "So what relationship does my distribution have with the average guy distribution?"

Incidentally, here's the reason you'll never have to worry about this in the context of "Google the Internet for everything Patrick McKenzie has ever written": imagine I have a 99.9% effective filter for you, and I dragnet an Internet filled with 5 billion documents of which you've written 1,000. I then identify 5 million documents as written by you... but you only wrote 1,000 of them.

This sort of "don't search the haystack unless you're bloody sure it is packed full of needles" thing is why you never want to test a population not known to be at risk for the disease, etc. (Or why you retest in the event of a positive using a different test.)

<comment><USER3> I down-voted you for the use of the term "death tax". The correct term for it is the "trust fund baby tax". This is not merely a matter of rhetoric, but of accuracy. The dead person isn't being taxed. Being deceased and presumably having no use for wealth past that point, he or she doesn't care. The living heirs are being taxed.

To quote _Salute Your Shorts_ , get it right or pay the price.

It cost you 2 karma points, because I'd otherwise have voted you up for an otherwise high-quality post.

<comment><USER4> That was an odd thing to do... If he had used your "correct" term in his post, it would not have been a good indicator of Republican behavior and would therefore ruin the example. His post uses the term in a description of other posts -- just as your post does.

<comment><USER3> You make a good point. I just have a knee-jerk negative response to phrases like "death tax" when not used with bitter irony. (I have Republican relatives.) I probably deserve my -5 for being obnoxious.

Rash, knee-jerk reactions are often a social liability, which reminds me of a funny bar anecdote:

Guy: So, you're waiting for someone?

Girl: Yeah, some college friends. They're an hour late. Oh _my... Boy, friend_ s can be really rude sometimes.

Guy: Tell me about your sister. How old is she?

Girl: What?

Guy: Sorry, I heard the words "my boyfriend" and--

(Girl walks away.)

<comment><USER3> Yaaaouch! Seafood soup is NOT on the menu!

</comment></comment></comment></comment></comment><comment><USER5> You can imitate someone's writing style with a travesty generator but that doesn't mean everyone has a "writing fingerprint". Very few people have a distinct enough writing style to weed out false positives, and since it's so easy to imitate you'll never really know your precision.

I have a few writing ticks (parens, the '--', certain words like 'certain') but it's much easier to just search on "aristus" to start exposing my shame.

I played with this a few years ago with a project called unmaskr. Heuristics can help precision a lot but does not help with recall. People generally:

      * use similar usernames, or a "constellation" of usernames

      * have semi-regular posting times

      * post in one place at one time

      * use similar place names, nicknames for things

      * write fluently in one language

      * link to a "constellation" of domains

</comment><comment><USER6> It is no doubt possible. I've done something similar to this on a single forum 3 or so years ago and had reasonably interesting results.

Basically, I scraped the site, removed formatting/spacing/dead-words, stemmed (using a modified porter), constructed a matrix of word-frequencies per post. After which I did several various analytical techniques (statical, geometric, etc). The net result from using a blended method was able to identify several most aliases of board posters However, the issue google would no doubt have is sampling size. In a small enough sampling size quirks work as identifying characteristics, in a larger dataset you would no doubt see clusters of people who have similar backgrounds (e.g. education).

</comment><comment><USER7> When I was packing up my college dorm room at the end of senior year, I found a typed short story and started reading. It was the most peculiar sensation, because it read like I had written it, but I didn't remember writing it. Then I realized (i.e., noticed the heading and saw) that it was my brother's story. Three years apart, we'd picked the same kind of IB senior English project and attempted to write in the style of the same author, and our writing (though in very different stories) was very, very similar.

</comment><comment><USER8> Donald Foster (<http://en.wikipedia.org/wiki/Donald_Foster_(professor)> ) is sometimes known as a "forensic linguist" for his use of computers to analyse texts. Famously, he figured out the (formerly anonymous) author of the bestselling novel "Primary Colors" using computer analysis. If you're interested in this kind of thing, I highly recommend starting with the Wikipedia article, which describes a lot of Foster's work.

</comment><comment><USER9> I believe I can offer some help because this is in the rough area of my Ph.D thesis (see <http://33bits.org/> for more on that.)

Everyone does have a writing fingerprint, contrary to what another person claimed. However, it is an open question whether it can be efficiently extracted.

The basic idea for constructing a fingerprint is this. Consider two words that are nearly interchangeable, say 'since' and 'because'. Different people use the two words in a differing proportion. By comparing the relative frequency of the two words, you get a little bit of information about a person, typically under 1 bit. But by putting together enough of these 'markers', you can construct a profile.

The beginning of modern, rigorous research in this field was by Mosteller in Wallace in 1964: they identified the author of the disputed Federalist papers, almost 200 years after they were written (note that there were only three possible candidates!). They got on the cover of TIME, apparently. Other "coups" for writing-style de-anonymization are the identification of the author of Primary Colors, as well as the unabomber (his brother recognized his style, it wasn't done by statistical/computational means).

The current state of the art is summarized here. [http://www.stat.rutgers.edu/~madigan/AUTHORID/bibliography.h...](http://www.stat.rutgers.edu/~madigan/AUTHORID/bibliography.html) If you're going to do any work on this, you should read as many of those papers as you can. Or else you'll invent something feindishly clever only to find that some academic already wrote about it 20 years ago and showed why it doesn't work.

Now, that list stops at 2005, but I'm assuming there haven't been earth shattering changes since then. I'm familiar with the results from those papers; the curious thing is that they stop at corpuses of a couple hundred authors or so -- i.e, identifying one anonymous poster out of say 200, rather than a million. This is probably because they had different applications in mind, such as identification within a company, instead of Internet-scale de- anonymization. Note that the amount of information you need is always logarithmic in the potential number of authors, and so if you can do 200 authors you can almost definitely push it to a few tens of thousands of authors.

The other interesting thing is that the papers are fixated with 'topic-free' identification, where the texts aren't about a particular topic, making the problem harder. The good news is that when you're doing this Internet-scale, nobody is stopping you from using topic information, making it a lot easier.

So my educated guess is that Internet-scale writing style de-anonymization is possible. However, you'd need fairly long texts, perhaps a page or two. It's doubtful that anything can be done with a single average-length email.

Another potential de-anonymization strategy is to use typing pattern fingerprinting. The timing between our keystrokes fingerprints each of us (yes, this works even for non-touch typists.). This is already used in commercial products as an additional factor in password authentication. However, the implications for de-anonymization have not been explored, and I think it's very, very feasible. i.e, If google were to insert javascript into gmail to fingerprint you when you were logged in, they could use the same javascript to identify you on any web page where you type in text even if you don't identify yourself. Now think about the de-anonymization possibilities you can get by combining analysis of writing style and keystroke dynamics...

By the way, make no mistake: the malicious uses of this far overwhelm the benevolent uses. Once this technology becomes available, it will be very hard to post anonymously at all. Think of the consequences for political dissent or whistleblowers. The great firewall of China could simply insert a piece of javascript into every web page, and poof, there goes the anonymity of everyone in China.

As for who's doing this? Google would be the least likely candidate, IMO. The PR consequences of such experiments, were it ever to come out, blow up in proportion to the size of the company. Not a good idea. On the other hand, I do know a guy who was trying to start an 1-person company based on similar ideas when I last heard from him. Well, de-anonymization of web sessions, although writing style was not involved. That's the closest I can think of.

I am myself very, very interested in looking into this. My main interest is to write a paper and possibly build tools to take a chunk of writing and try to remove your fingerprint from it, i.e, protect anonymity, but if in the process of collaboration someone else were to build a de-anonymization tool, I have no problem with that. I've built (if I can say so), some of the current best de- anonymiztion tools/techniques (check my website), so if you're interested feel free to drop me a line.

<comment><USER10> Maybe someday it will be illegal to copy and paste to avoid being authenticated.

<comment><USER11> Humm... maybe this is why iPhone's don't allow copy paste! ;)

</comment></comment></comment><comment><USER12> All of the methods require a decent amount of text. So unless someone is writing hundreds of words in each sample, they're unlikely to be distinguishable from the crowd. That, to me, rules out typical comments on threads. Lots of little samples seem to be just too noisy with too much overlap among authors to allow for unique information-based fingerprints.

However, if the data is sufficiently large - in number and length (say, lots of essay-type blog posts) I'd expect some classifier-based machine learning techniques could match authors. That is, take a sample of 100 bloggers, split their data in half, train the classifiers on one half then test to match up the other half of the data. Under those conditions you could probably get 90-95% accuracy.

The question, I think, is how small you could push the training set in terms of the fewest words and the fewest posts.

</comment><comment><USER13> I doubt this is possible with current technology - so many people share the same or similar writing style that, even with a skilled human analyzing, you probably can't do much better than attribute it to a large bucket of perhaps thousands or tens of thousands of individuals.

<comment><USER14> Even if you couldn't narrow it down to an exact person, it seems like you could get good accuracy on socioeconomic status, cultural background, political slant, etc. Once you had that data it might be valuable from a marketing standpoint. It might not be useful for sites where there is a very specific user group, but for sites with incidental user generated content-- even if it isn't anonymous per se, you could get a more accurate picture of your audience.

</comment></comment><comment><USER15> Doubtful, its not something you can automate to be reliable, and w/o reliability whats the point?

</comment><comment><USER16> I always wanted to run that experiment on the Hacker News data...

<comment><USER17> I think that we all sound alike.... at least compared to the rest of the web.

Actually, I think if someone really tried to do what the original question asked, then it would end up with under 100 different "people" who all seemed to cluster together. All of HN would be something like 2 or 3 different clusters.

</comment></comment><comment><USER10> Search for "text fingerprinting" - there's a lot of info.

</comment><comment><USER18> No.

<comment><USER19> I'm assuming the question was

        It'd be neat if there was a web site that you could submit some writing
        samples (emails or whatever) and then see everything else that person has
        posted online (regardless of whether it was anonymous or not).

to which I agree with tptacek's answer.

</comment></comment><comment><USER20> In conjunction with ISPs, the (US) government or a large private company like Google or Microsoft could aggregate posts based on IP address. In fact, according to a report by Frontline (" _Spying On The Homefront_ "), Homeland Security started implementing such a system for monitoring all phone and Internet communications after the passage of the Patriot Act. I was going to say that it would probably be political suicide for a private company to participate but I just remembered Homeland Security actually contracted a private company to do this work for them. I can't remember the name of the company but you can watch the whole show online:

<http://www.pbs.org/wgbh/pages/frontline/homefront/>

Using writing style seems a little far fetched given the limited scope of variations in language relative to the large number of people using language. Otherwise it would not have taken so long for effective speech recognition software to appear - even the current incarnations are more fragile than one would expect relative to how long the best minds have been looking at the problem and relative to the high economic value of an effective solution.

</comment><comment><USER21> I want my privacy :(</comment>


Reality as a service - <AUTHOR> http://www.roughtype.com/?p=8078 <comment><USER2> If reality is a service, some people unsubscribed long ago.</comment>


Binary 1.0.0: Easy binary and SI unit conversion (kibibyte, kilobyte, etc.) - <AUTHOR> https://github.com/ofek/binary <comment><USER2> GNU units can do this conversion natively (although it's harder to integrate into another program, because as far as I know its interface is only stdio).</comment>


How do you cut a monolith in half? - <AUTHOR> http://programmingisterrible.com/post/162346490883/how-do-you-cut-a-monolith-in-half <comment><USER2> After reading Enterprise Integration Patterns [1] a few years ago, I've been under the impression that message queues are the holy grail for decoupling systems that you want to pull apart, but this offers a really nice perspective on where they might not be a panacea. Thank you!

There's a couple of nice ideas in here (the "message pump" for one at least) that I'm going to steal and use at work. It's also comforting to know that we're not completely crazy for using a DB to store tasks/processes that need to be run and retried if necessary instead of a message queue.

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

<comment><USER3> I know what you meant by saying you use DB _instead_ of message queue but I think it kind of points to a broader point - message queue is a concept and the technology used to implement it is just implementation detail. It just turns out that databases have all kinds of useful and powerful operations that make implementing message queues relatively easy.

<comment><USER4> If you don't need high throughput and otherwise don't have a reason to add a separate technology to the stack just to have a queue, SQL can make a great, simple and reliable queue!

* Postgresql and Oracle with skip locked

* MS SQL Server with readpast

* DB2 with skip locked data

If you use MySQL, it's going to be a bit more difficult.

<comment><USER5> I hadn't heard of skip locked before, and very much enjoyed this article walking through it for postgres: [https://blog.2ndquadrant.com/what-is-select- skip-locked-for-...](https://blog.2ndquadrant.com/what-is-select-skip-locked- for-in-postgresql-9-5/)

<comment><USER6> Love the headline "Most work queue implementations in SQL are wrong". That kind of stuff makes me read an article...

This short screencast was also very helpful [https://www.pgcasts.com/episodes/7/skip- locked/](https://www.pgcasts.com/episodes/7/skip-locked/)

</comment></comment></comment></comment></comment><comment><USER7> I've been working in a related space for a few years and wanted to offer a few counterpoints to the article.

First, if you're doing request/response using messaging, you're probably doing it wrong. Pub/sub and request/response are totally different animals. I for one, consider it both reasonable and necessary to use both side-by-side, in the same infrastructure. (Is this view uncommon?)

In our technology stack, which is a monolith-becoming-microservices, we use both pub/sub and request/response side-by-side. The general rule is that if service A calls service B, if the nature of that interaction is such that service B's response can preempt/interrupt/influence service A, the call needs to be done inline, in service A. If the nature of the interaction is more "advisory", use pub/sub.

Examples (from the hotel booking space): (a) When a reservation gets canceled, we publish a cancellation event. The reservation is then CANCELED, officially. A separate service sees the cancellation event and frees the associated held room inventory; that's a pub/sub interaction. (b) When a reservation wants to check in to a room, we check whether the room is already occupied. This has to be done using request/response (in our case, gRPC) because if the room is occupied, that's a hard gate on the success of the checkin.

Second, pub/sub != work queues.

Pub/sub is about distributing small bits of information all over the system and letting things be advised of stuff. Using a messaging system as a work queue is overall pretty stupid. I know it's common to use a message broker like RabbitMQ for task distribution, but it's silly. It's _really_ silly when the tasks themselves contain huge binary objects inline, as part of the message payload. Store that shit in S3 or a proper system, and keep the message payloads light.

I guess that's all for now.

<comment><USER8> What do you use for task distribution?

<comment><USER7> Surprisingly, we don't any long-running tasks.

</comment></comment></comment><comment><USER9> This article is not just very well written, it's also very funny. Some gold:

> a message broker is a service that transforms network errors and machine > failures into filled disks

...

> mark it as required in the database, and wait for something else to handle > it. > > Assuming that something else isn't a human who has been paged.

...

> Systems grow by pushing responsibilities to the edges

...

> A distributed system is something you can draw on a whiteboard pretty > quickly, but it'll take hours to explain how all the pieces interact.

I love when you can mix technicals and not taking yourself seriously.

Although be careful with using DB as a task queue. Concurrency is a b* and message brokers are very good at it. AMPQ has been created because the authors started with a BD message broker and it didn't work.

A task queue is message broker + persistance + status. Celery does that very well in the Python word, and works with rabbitmq, redis, postgres, etc.

What amaze me the most is autobahn + crossbar.io. It does PUB/SUB, RPC, load balancing and all the stuff for Python, JS, PHP, C#, Java... And it works even in the browser. Cool stuff.

<comment><USER10> > Concurrency is a b*

I have to say. I spent way too much time trying to understand what b* trees have to do with concurrency, and what system you are using that implements them.

<comment><USER11> I interpreted that as, "Concurrency is a bitch...".

<comment><USER10> Yeah, that's the correct interpretation. I got there, eventually.

</comment></comment></comment></comment><comment><USER12> A follow up from a reader on this article: [http://bravenewgeek.com/smart- endpoints-dumb-pipes/](http://bravenewgeek.com/smart-endpoints-dumb-pipes/)

</comment><comment><USER13> It seems to me that there are great benefits to be had if you can keep the transactional integrity of direct connections to a relational database like PostgreSQL. The performance and scalability is often better than people expect because the data stays closer to CPUs and it avoids moving too much across multiple nodes on the relatively slow and unreliable network.

In a lot of cases, there are natural separation lines such as between groups of customers you can use to shard and scale things up. Unless you are building something like a social network where everything is connected to everything, you don't need a database that runs over a large cluster or clustered queues in between components. These are often just more moving parts that can break.

<comment><USER14> The benefits of transactional queues in your database are hard to overstate; commit the result of the task in the same transaction as you commit the queue update. Don't worry about idempotency, lost messages, or duplicate messages.

I suspect the advice to avoid it because of performance has become invalid for all but extreme use-cases. My company has dozens of high activity 1-100M item queues in single postgresql databases. It works great.

</comment></comment><comment><USER15> Queue is not the holy grail, especially if you want to put something on the queue during the db transaction. Be aware, that once you do I/O (some RPC or queue interaction) you loose the ACID in the db, you will make the system much less reliable this way.

The way to do this, it to publish on queue _after_ transaction, but also be sure that the action won't be lost in the process.

[https://martin.kleppmann.com/2015/04/23/bottled-water- real-t...](https://martin.kleppmann.com/2015/04/23/bottled-water-real-time- postgresql-kafka.html)

[http://dataintensive.net/](http://dataintensive.net/)

</comment><comment><USER16> The term SOA is always mentioned with the underlying connotation that a client requests a resource and somehow there is an extra step of "service discovery" which has it's own set of problems that branch out into various fields of physics and mathematics.

When I see such branching complexity, I often think that the architecture is somehow wrongly backwards and try a simple reversal of responsibilities. In this case, the services would be looking for a job to complete, in effect turning the afromentioned step into "job discovery" which is indeed the kind of architecture I've been applying the past decade.

Seems to be working well so far. Back pressure is handled at the front gate as none of the services pick up on the job, involuntary synchronization is still a problem, but avoidable by cleverly re-ordering the job queue. The job completion is communicated back to the front gate through pub/sub and the anecdotal evidence so far has been great.

<comment><USER17> Isn't your architecture exactly what the author is arguing against?

<comment><USER16> Because I use pub/sub instead of polling the database? I thought that was just common sense.

</comment></comment></comment><comment><USER18> Dealing with fairly low-volume stuff, my concern about using the database alone has to do with who owns what schema and how changes are managed.

Being able to send off a rich asynchronous message is nice because it means you do not need to have some co-owned table in a shared database that two different components are reading and writing from.

Or, worse, a widespread pattern of every service exposing a piece of its database to other services with an unsatisfying level of logging or control for what really happens.

<comment><USER19> not all databases require rigid schemas. a filesystem, for instance.

<comment><USER18> I don't understand what distinction you're trying to raise.

My point is that a message-queue allows you decouple systems, whereas having two systems share the same database tables has its own kind of peril.

</comment></comment></comment><comment><USER20> Money quote in my humble opinion:

> In practice, a message broker is a service that transforms network errors > and machine failures into filled disks.

<comment><USER18> Of course, the alternative before that may have been "any network error or machine error brings everything down".

When it's asychronous, it's easier to tolerate random errors or downtime, but the cost is that you have to store the message _somewhere_...

</comment></comment><comment><USER21> Expected story about 2001, was disappointed.

Good overview from my perspective of not knowing much about such systems.

<comment><USER22> I was expecting a geometry puzzle about subdividing a 1:4:9 monolith into smaller 1:4:9 monoliths. :)

</comment></comment><comment><USER23> just before the "l"

</comment><comment><USER24> Hmm, I submitted this yesterday, but it got lost in the scrum.

It's always interesting to hear real reports from the trenches that aren't essentially ads for technology XYZ. I'm afraid that all too often, we make things more complicated for bad reasons; whether ignorance, chasing the latest trend, or resume-driven-development...

<comment><USER25> Message-oriented stuff has been around a long time, so I don't think it's a fad.

It's basically taking the concept of "integration" (or API) itself and creating a product for it, just as a database is a product for the concept of persistence. Thus just as not every application has to reinvent a database, with a messaging product not every product has to reinvent queueing up integration calls if the target system isn't available.

The article also mentions request-reply being "what you really want", I think that this is a) not true, as a lot of the time you can fire and forget, and b) when you need it the products generally provide a request-reply API on top of their lower-level APIs. No need to reinvent.

<comment><USER26> I got the impression that the author didn't really want a message based system at all, but rather a request response system that they tried to impliment within a message broker. Of course that's going to create more headaches than it solves; it's the wrong solution.

Both message brokers and request-response code have their places in distributed systems, but they really need to learn when each is appropriate.

I agree, saying that request-reply is "what you really want" was kind of silly, especially after the opening paragraph that states "it depends".

<comment><USER27> Can you elucidate the differences between message-broker and request-response use cases in your eyes?

<comment><USER10> In my eyes (where the GP makes perfect sense), a message broker is asynchronous, there's no implicit wait while your consumers work on our request. A request-response interface will stop the producer until the consumer is done.</comment></comment></comment></comment></comment>


Jeff Hawkins on the Limitations of Artificial Neural Networks - <AUTHOR> http://thinkingmachineblog.net/jeff-hawkins-on-the-limitations-of-artificial-neural-networks/

<comment><USER2> "I am certain that HTM networks applied to applications like vision will not exhibit the problems talked about in this paper. Brains won't either."

Put up or shut up, I say. If you have a model that works better, demonstrate it. ANNs simply crush every competitor in real-world performance.

Modeling brains is a cool idea but it doesn't have any practical advantages unless it improves learning performance or has medical applications. Neither is true of any ANN competitor so far.

Honestly, I think we're much more likely to eventually understand the brain by first focusing on building working AI systems of our own design and then comparing them to the brain (with the help of our AIs!), rather than reverse engineering the brain first and building systems that mimic it.

<comment><USER3> He has "put up".

He's been doing and funding neuroscience research for over a decade and has built some impressive predictive systems. Leading researchers, such as Andrew Ng (the Director of the Stanford Artificial Intelligence Lab), have stated that Jeff's publications have directly influenced their thinking.

That said, I agree machine intelligence will initially be the equivalent of building machines that fly without flapping, but Jeff's approaches don't forbid this (he often deviates from nature in his models, but tries to stay close).

<comment><USER2> > has built some impressive predictive systems

Do you have any links to examples? I'm not aware of any systems built with HTMs that I'd consider "impressive" relative to what ANNs are doing these days, e.g. learning to play Atari games by watching the screen [1], approaching human performance on object classification in unrestricted images [2], or learning to execute simple python programs by reading the source code [3].

[1] [https://medium.com/the-physics-arxiv-blog/the-last-ai- breakt...](https://medium.com/the-physics-arxiv-blog/the-last-ai-breakthrough- deepmind-made-before-google-bought-it-for-400m-7952031ee5e1)

[2] [http://karpathy.github.io/2014/09/02/what-i-learned-from- com...](http://karpathy.github.io/2014/09/02/what-i-learned-from-competing- against-a-convnet-on-imagenet/)

[3] [http://arxiv.org/abs/1410.4615](http://arxiv.org/abs/1410.4615)

<comment><USER3> Oh don't get me wrong, the things being done with ANNs are incredibly impressive. Far more so than anything I've seen with HTMs to date. I was just pointing out that Jeff _is_ putting his money where his mouth is. Also, much of the resurgence in interest in AI came about 12 years ago in large part due to Jeff's thinking and writings (which was mostly consolidating existing ideas into a cohesive theory), as Andrew Ng and others have stated[1]. Jeff helped kick AI out of a plateau and avoid another AI winter.

For interesting things that Numenta has done, just check their website[2]. Their most popular product is likely Grok[3], which predicts things like server loads. It's nothing that ANNs couldn't do, and ultimately isn't that impressive at face value, but the implementation is interesting and has far reaching implications (w/regards to things like energy efficiency and other areas).

I think the future holds incredible things for ANNs and we'll continue to see great breakthroughs with them, but HTMs hold a lot of promise too. ANNs have been around quite a bit longer and have orders of magnitude more researchers working with them, so I'd argue it's premature to dismiss HTMs just because a handful of researchers in Redwood, CA haven't solved every AI problem within 12 years.

It was only 15-20 years ago that ANNs were considered to have peaked and been surpassed by bayesian networks and support vector machines. How times have changed since then!

[1] [http://www.forbes.com/sites/roberthof/2014/08/28/interview-i...](http://www.forbes.com/sites/roberthof/2014/08/28/interview- inside-google-brain-founder-andrew-ngs-plans-to-transform-baidu/)

[2] [http://numenta.com/](http://numenta.com/)

[3] [http://numenta.com/grok/](http://numenta.com/grok/)

</comment></comment></comment></comment><comment><USER4> I noticed that Jeff Hawkins quite frequently lacks details and scientific backing on his claims. I read his book "On Intelligence" and followed his talks and I have been inspired by them because his explanations are highly intuitive but when it comes to demonstrating the awesomeness of his approach it's less tangible.

</comment><comment><USER5> I have chosen deep learning as the topic of my graduation thesis and lately and I had the opportunity to study the evolution of artificial neural networks. I think deep learning is having it's descending period on the hype curve in an interesting way, it is interesting because the prominent figures of the field are delivering it. If my memory serves me well, this is the third article brought to HN within last month on the topic of "deep learning does not represent how real brain works and is actually unsuitable for artificial general intelligence".

On one of his seminars Andrew Ng talks about "the algorithm": he pointed out that human brain may re-wire itself to handle different tasks, for example one part of the brain which is responsible for sight might take up the task for hearing. The idea of ANN undisputedly inspired from research investigating how brain actually works, and now it has set the state-of-the-art on many areas it has been applied, but to do this we had to resort to "ugly hacks" in the perspective of "the algorithm", to name some of them would be Autoencoders and Restricted Boltzmann Machines. It works, yes it works very well, but we had to pay a price of taking a detour from finding "the algorithm".

In my opinion, such banterings as in OP should not be taken as an aggressive stance against deep learning. Just because it is not "the" method doesn't mean it has no value whatsoever, but it has a point; after the limitations of deep learning is explored well, we will need a new idea to push the field further.

<comment><USER6> State-of-the-art results no longer require unsupervised pretraining with autoencoders or RBMs, but back when unsupervised pretraining was more popular, top researchers were rationalizing that it was consider more biologically plausible than the standard nets trained with back prop, since brains generalize through observing a large amount of data over their lifetime to quickly recognize new objects and since the nets aren't trained for a specific task, they would hopefully generalize better and be a step closer to general intelligence.

</comment></comment><comment><USER7> I met with the head of the Data Science institute at NYU a few years ago (not LeCun). I don't remember the specifics of our conversation, but I remember at one point I mentioned Jeff Hawkins (I had just read his book "On Intelligence") and I remember he responded with some comments that were politely dismissive of Hawkins.

Some of the other comments here seem to share the same sentiment. I really loved his book, but I haven't really followed his work for the past few years. Anyone know what he's been up to in ML/AI lately?

<comment><USER8> NuPIC, the Open Source project upon which Grok (Numenta's commercial product) is built has an active community at [http://numenta.org/lists/](http://numenta.org/lists/). We had a workshop and hackathon a few weeks ago, more details can be found at [http://numenta.com/learn/](http://numenta.com/learn/) and [http://numenta.org/blog/2014/10/30/2014-fall-hackathon- outco...](http://numenta.org/blog/2014/10/30/2014-fall-hackathon- outcome.html), respectively. See, also, [https://github.com/numenta/nupic.research](https://github.com/numenta/nupic.research) for the latest research efforts, [https://github.com/numenta/NAB](https://github.com/numenta/NAB) for forthcoming benchmarks, and of course [http://numenta.org/](http://numenta.org/) for overall details about NuPIC and [http://numenta.com/](http://numenta.com/) for Numenta, the company.

</comment></comment><comment><USER9> I am by no means an AI professional or neurobioligist, but I have read recently that a major problem with neural networks is that they do not have glial cells which, among other things, move synapses around and helps with synapse growth.

There are around 100 billion neurons in the brain and 100 trillion synapses. This indicates to me that synapses may be more important to biological neural networks than neurons are, and yet most ANN research has been focused exclusively on neurons (I once asked my teacher which neurons to connect to each other and recommended using a GA, which is not a bad idea but it indicates to me we have a very poor understanding of how synapses aught to work to make better ANNs.)

I disagree with the overly pessimistic view of this article however. To say that our standard neural networks are not nearly as complex as biological ones would be accurate, but this hardly means that ANNs are doomed forever, we just need more research into the things that matter.

</comment><comment><USER10> Hawkins has no credibility in machine learning so I don't think people should really care about what he says. To the extent that anything he _does_ say about the field makes sense, it isn't novel. Unfortunately our society reveres the super wealthy and treats them as experts on everything.

<comment><USER11> >Hawkins has no credibility in machine learning so I don't think people should really care about what he says.

Says the most respected name in the field of machine learning, Teodolfo.

Srsly. Why the hate Teo? He merely said exactly what everyone from Michael Jordan to Andrew Ng has said; There's nothing very 'neural' about ANNs.

ANNs work. No doubt. But they are limited in what they can do. Jeff is merely pitching a new approach that is intended to solve some of those limitations.

But since you don't care what he has to say, I doubt you have a very firm understanding of what he has said.</comment></comment>


Top football team ditches tablets, goes back to paper - <AUTHOR> https://twitter.com/ZackCoxNESN/status/788411998006603776 <comment><USER2> And they're still not calling them Microsoft Surface tablets.</comment>


TCPTuner: Congestion Control Your Way - <AUTHOR> http://arxiv.org/abs/1605.01987 <comment><USER2> Sources on GitHub:

[https://github.com/Gasparila/TCPTuner](https://github.com/Gasparila/TCPTuner)

</comment><comment><USER3> Neat. It's disappointing how TCP congestion control is one of the main limiting factors of modern broadband connections. Even downloading from S3 or something it takes up to a minute before TCP discovers the link bandwidth, when the transfer could have been finished in seconds if it was more aggressive. There doesn't seem to be much practical development in the area either. Is congestion collapse still a concern in today's internet?

<comment><USER4> The problem isn't a lack of research, it's lack of deployment. OS vendors aren't turning on ECN and they largely aren't enabling their new congestion control algorithms by default. Slow-start of some kind is still absolutely required, because with an initial window of 10 packets a single new connection can swamp a 5Mbit or slower link for 24ms or more, and that occurs far too often in the real world to ignore. Interactive usability is more important than shaving a few seconds off bulk downloads.

If ECN and fair queuing were generally supported on the internet at large, then senders would get quicker feedback about congestion and the negative side effects of overly-aggressive senders would be greatly reduced. Even without deployment of those throughout the network, delay based congestion control at the endpoints helps, if the sender turns it on.

</comment></comment><comment> blue-- This would be great for a simple classroom demo on congestion control!</comment>


Ask HN: Web Developer looking to move to Systems Programming seeking advice - <AUTHOR> I've been working as a PHP developer for almost 7 years now. I started doing small PHP projects while still studying for my CS degree and it sort of progressed from there. This career path worked more or less fine for me as it always provided decent income, jobs were fairly easy to find and at times projects were fairly interesting too. However at a personal level I was never really interested in the subject and on my free time I always found myself hacking on something else.
At this point I feel that to continue working as a programmer I need to change my field. Programming can be very interesting and rewarding experience to both programmer and surrounding community, but it can also turn the other way around if you lose your motivation.
My real passion lies in systems programming I believe as I was always interested in operating systems, programming languages, algorithms and related stuff.
I would be very interested to hear if anyone did a similar transition to systems programming and how did it go. How long did it take for you to learn everything? Did you take a more general approach or did you target a very specific area? How long did it take to get your first job as a systems programmer and what it was?
Any kind of related experiences would be very helpful to me when making this decision. Thank you. <comment><USER2> You need to understand that systems programming is _very_ different from PHP. You have to worry about many more conditions. (What if another thread calls function X, just before someone calls this function? I need a mutex to protect this data structure. But what are the performance effects of that? Do I need to think about how multiple cores affects this? Etcetera...)

<comment><AUTHOR> Yes, I'm aware of what is involved in systems programming and what kind of problems I might end up solving. However my knowledge is mostly theoretical or based on spare time hacking or university classes practice. The point you are raising is valid though. One should be aware where he is going to stick his nose :)

Based on your previous post I see that you are an embedded developer. Would you mind to shortly tell how you started and what you found most difficult or most important in the beginning or even later in your career?

<comment><USER2> How I started: I got hired right out of college (with a math and physics degree, not CS) for an embedded position. From that start, I've been in embedded for almost all of my career.

What I've found to be important/different: Debugging can be really hard. You can't always run a debugger; you can't always print something out. Sometimes bugs can come from interaction between different threads, which is something that you don't run into in many kinds of programming. You have to watch for multiple threads accessing the same data, and you have to figure out what you need to do if it happens. You need to remember that any thread can stop running between any two assembly instructions - a C statement is _not_ atomic.

I've never done system programming, but in ignorance I think it's harder than what I do. It's got all of my problems, plus a bunch more...

<comment><AUTHOR> What would be the situation in which you can't run debugger? Is this when the issue can't be reproduced in dev environment?

<comment><USER2> You can't run a debugger when you don't have room on the embedded device for the debugger. You can't run one if you don't have communication with the device (if you're installing code by physically inserting ROM chips in sockets, and don't have a serial port or ethernet connection to it.

And you can only run a debugger with great difficulty if your system is handling real time events, and if the debugger hits a breakpoint, you mess up the timing so that the behavior from that point on is completely changed. You might be able to get the information that the breakpoint triggered, and what the variables are at that point in time, but you can't continue from there and see how execution proceeds.

</comment></comment></comment></comment></comment><comment><USER3> I am not a systems programmer myself, but if you are looking for resources, I can recommend the book "Computer Systems: A Programmer's Perspective". We used this textbook in some systems classes I took in school, and I thought it was pretty helpful and informative.

<comment><AUTHOR> Thank you. I will definitely have a look at that book.

This is what I have on my list so far:

The C Programming Language

C Interfaces and Implementations: Techniques for Creating Reusable Software

Expert C Programming

Algorithms in C, Parts 1-5 (Bundle): Fundamentals, Data Structures, Sorting, Searching, and Graph Algorithms

Structure and Interpretation of Computer Programs

Introduction to Algorithms

Compilers: Principles, Techniques, and Tools

Hacker's Delight

Cracking the Coding Interview: 150 Programming Questions and Solutions

Advanced Programming in the UNIX Environment

<comment><USER4> I am familiar with maybe half of the books you mention, and the selection seems quite solid. I would however recommend to spend less time reading and more time hacking. Also, try to approach this as a series of steps, not everything in one go:

1\. Learn C, the Language: You should already know the basic components of structured programming (functions, loops, conditionals, etc). As PHP user you probably are somewhat familiar with C standard library (with PHP just puts a thin layer on top of), but you are a false beginner here because you need to learn to be much more careful with manual memory management, compiler erros vs warnings. Just pick some project whose specification is dead simple (a little console based game like sudoku might do) and build it from the bottom up.

2\. Learn C, the Runtime: Get deeper into standard library functions. Pick something more sophisticated in terms of I/O. Learn the difference between static vs dynamic linking, and try to work around it just for the sake of it (make your own malloc is a classic).

3\. Learn C, the Unix's companion. Figure out what a system call is and how it is unlike a regular function call. Learn Linux (I know you mentionen MINIX elsewhere, and it would be valuable in a 4th or 5th step, but for the sake of employability it is better to be a power user of a mainstream system than an expert in an academic one). Figure out stuff like virtual memory, how it works and how to affect it at the C level (which should be transparent, and mostly is but not 100%).

<comment><AUTHOR> I was thinking somewhere on the similar lines when deciding how to approach this. I split the process into 3 initial steps as well.

1\. Learn the C language. Read K&R book, then get my hands dirty with some relatively simple problems. Here I'm actually deciding between practicing with algorithmic problems and doing a simple project or I can probably do both. Anyway I'm leaning towards algorithms because they normally are short enough to be possible to work on with the minimal amount of knowledge on the standard library and are complicated enough to be a good practice, particularly when it comes to performance and memory usage. This approach would also make me learn how different data structures are handled in C and how to deal with memory management.

2\. Learn systems programming. At this step after some initial reading I would like to join a relatively small open source project and try to fix some bugs or contribute some small changes to it. I didn't decide yet what particular project it could be so any suggestions are welcome :) At this step I should become comfortable with writing C and gain some basic knowledge on systems programming.

3\. Get deeper into systems programming. This is were I'm deciding between taking on Linux/BSD or MINIX. I suppose MINIX should work very well as a learning tool for OS design and implementation. So it could make transition to Linux/BSD easier. At this stage I could probably join some open source OS project.

What comes after that I'm not quite sure. There may be more steps involved or I may be ready to look for a job at this point.

I may also need to decide what exactly I want to work on which leads me to the difficult question I raised to myself when thinking about this. Should I specialize from the very beginning or can I be a generalist with a strong general systems programming knowledge and then get to the details when the need arises based on particular job?

</comment></comment></comment></comment><comment> Hattori-1 Advanced Programming in the UNIX Environment is a very detailed book which will refresh a lot of concepts. Needless to say C skills need to be polished (K&R). Or you can go the hard way and start contributing to the testing of Linux kernel.

<comment><AUTHOR> Joining an open source project will probably be necessary for me in order to get decent level of hands on experience. There is also a possibility of getting some mentoring which would be really good for me.

What do you think about MINIX as a learning tool? It seems to look as a good place to start but I don't know much details about it's internal design except that it's using a microkernel which is different from most operating systems in use today. So I'm not sure about the practicality of spending time on MINIX. My other open source project choices would probably be Linux or one of the BSDs.</comment></comment>


North Korean Revolutionaries Turn to Crypto to Oust Kim Jong-Un - <AUTHOR> https://finance.yahoo.com/news/north-korean-dissidents-using-crypto-163908150.html <comment><USER2> Only semi-coherent. The article jumps from stating that a revolutionary group exists in the first sentence, to saying that a new country exists without any antecedent or explanation.

Also, the article merely partially paraphrases another article on a site named "ccn.com", which is mainly a blockchain news site, as near as I can tell.</comment>


Sync to Paper - <AUTHOR> http://robertgreiner.com/2013/03/sync-to-paper/

<comment><USER2> Huge fan of paper as well. I think Merlin Mann called it the "ultimate ubiquitous capture".

A lot of people just keep thick journals, but I like A6 cards that I compile into slim exercise books. I just capture anything that comes to mind on a card[1] and let them sit on a pile. Then, after some time, enough stuff has accumulated and I review the cards and compile them.[1]

It has the sweet spot of not having to commit to something big (meaning it circumvents the urge to make it perfect, usually preventing you from writing it down in the first place), is reasonably flexible if you use masking tape to glue in the cards (there are some books that I could take apart completely and reuse) and can be stashed and sorted easily.[2]

[0] [https://plus.google.com/photos/111011776153281260419/albums/...](https://plus.google.com/photos/111011776153281260419/albums/5774980113163525217/5774980173127280498)

[1] [https://plus.google.com/photos/111011776153281260419/albums/...](https://plus.google.com/photos/111011776153281260419/albums/5833097033292752561/5833097035081483170)

[2] [https://plus.google.com/photos/111011776153281260419/albums/...](https://plus.google.com/photos/111011776153281260419/albums/5833327148912323025/5833327151210469890)

</comment><comment><USER3> The other part of this that I find helpful is that using paper is faster for many things, like small UI sketches, than using a PC. I also find that writing things down makes me think about the problem, whereas I can type up notes without paying attention to what I'm doing.

<comment><AUTHOR> Yeah, that's a great point. The guys at 37signals also recommend using a fat- tipped pen or marker to prevent you from trying to get too detailed.

<comment><USER4> Using ink forces the ideas out, too. No erasing and fiddling with things.

</comment></comment></comment><comment><USER5> Whiteboards are my preferred method for this sort of thing. The building I work in is actually awesome for this; the safety shields (mol bio lab) at the end of everyone's desks double as whiteboards and the windows are write-on- able as well.

I also know a guy who used to have a piece of whiteboard paper glued the back of his laptop so he could close it and quickly sketch something out if he needed to, his desk is also covered in the stuff.

<comment><USER6> I wonder if there's a market for a dry-erase iPad case.

<comment><USER7> Apparently, yes: [http://www.ubergizmo.com/2012/04/bowden-sheffield- minimalist...](http://www.ubergizmo.com/2012/04/bowden-sheffield-minimalist- ipad-cases-are-an-ipad-lovers-delight/)

</comment></comment></comment><comment> dan-g I am a huge proponent of this -- I rarely start a project without sketching something out on paper first. It helps me get my thoughts straight.

In a similar vein, I was reading an interview with Donald Knuth the other day, and while I can't find that exact instance, he was quoted saying:

> "The speed at which I write by hand is almost perfectly synchronized with > the speed at which I think. I type faster than I think so I have to stop, > and that interrupts the flow."

\-- from (PDF warning) [http://jmlr.csail.mit.edu/reviewing- papers/knuth_mathematica...](http://jmlr.csail.mit.edu/reviewing- papers/knuth_mathematical_writing.pdf)

</comment><comment><USER8> Having some paper and a pen can certainly do wonders - just last week I was working on something involving a lot of trigonometry (collision detection in a game), and being able to visualize and think about it on paper helped _a lot._ Quick visualizations are probably one of the best use-cases in general.

</comment><comment><USER6> For me at least, part of it is getting a fresh start on the idea. Rewriting stuff usually makes it clearer. Temporariness and the unlimited feeling of paper help with freeing up your mind to just let stuff loose.

Among other problems though is that sometimes the stuff you write turns out not to be that temporary, and that's often the times when rewriting it in digital form is useless. I'm trying to figure out how to design a digital tool that's better than paper in these respects.

</comment><comment><USER9> > Writing things down on paper is also painful

Training helps here definitely.

> You can also see more of it at one time.

And this is probably the most important property of paper to me. You can have five to six full A4 pages easily visible, which, with appropriate handwriting, cover the content of ten to twelve 1.5 x 3 m² blackboard or God-knows-how-many notebook displays.

</comment><comment><USER10> Paper is great for thinking because it doesn't distract you or interrupt you.

<comment><USER11> Paper might not distract me, but paper and a pencil can keep me distracted for hours.

<comment><USER12> Can you explain this? I will sit for hours with just a pen and paper and not be able to come up with anything worthwhile ideas or thoughts. What do you do?

<comment><USER10> I sometimes try using pencil and paper when I'm stuck on a specific problem. For example, if I'm trying to debug an algorithm, I might draw examples of the possible states the data structures could be in to make sure I've figured out all the edge cases.

Also, if I'm working on a project and can't figure out which of a dozen possible things to do next, I write down lists of tasks. These will eventually get transferred to digital form, but I find that circling important things and drawing arrows between them is a lot quicker on paper than messing around with some user interface on a computer, and this lack of friction promotes a state of flow.[1] If I get bogged down with data entry, it's easier to forget an item that came up while writing down another item.

[1] <https://en.wikipedia.org/wiki/Flow_%28psychology%29>

</comment></comment></comment></comment><comment><USER13> i was thinking that this article would be about dropbox and 3d printing! agree with the author about his points, however, the title really got me thinking, what if you could store things to paper, it's a relatively cheap medium, take qr codes as an example, stored to paper (or image file), reproducible via bit for bit. tun out of hd space? print

<comment><USER11> I'm not sure printing data is as cheep as you think it is. I did a quick back of the envelope calculation: From [1] I got an upper bound of 1,800 DPI in printers From [2] I got that ink costs 0.0062 $/in^2

Using those numbers, the cost of ink comes out to be about $5.83 per megabyte.

On the other hand, a quick Google search for "hard drive" got a sponsored result for $80 1-terabyte drive from Newegg, comming out to $0.0000762 per megabyte.</comment></comment>


Your Job Is Not to Write Code - <AUTHOR> http://usersknow.blogspot.com/2015/02/your-job-is-not-to-write-code.html?m=1

<comment><USER2> It's great that people are cognizant of the value we _really_ provide to a company! We improve your product tremendously - we're not just code monkeys! Now that we're on the same page, can we also get a salary that is more in-line with the value we provide?</comment>


Migrating a 10,000-line legacy JavaScript codebase to TypeScript - <AUTHOR> http://www.pgbovine.net/migrating-legacy-codebase-to-typescript.htm <comment><USER2> This is kind of a random Typescript tip, but when migrating regular Javascript, there is an alternative to adding the type 'any' to every object to 'silence' the compiler.

That is to introduce a preliminary type definition. Instead of:

      const oldVar: any = { field: 1, ... }
      function foo(bar: any) { ... }

You can write:

      declare type OldVarType = any

      const oldVar: OldVarType = { field: 1, ... }
      function foo(bar: OldVarType) { ... }

This way, you can signal that it's not just any kind of any, but a particular kind of any, which is now trackable in your codebase.

When you're ready, you can gradually update the OldVarType declaration and solve the compiler type check warnings from there. Union types [1] can be quite useful then too.

[1] [https://www.typescriptlang.org/docs/handbook/advanced- types....](https://www.typescriptlang.org/docs/handbook/advanced-types.html)

<comment><USER3> Ah, that's a neat idea. I wonder if there's any easy way to then scan your code for type aliases that are `any` to make sure you've caught all of those.

<comment><USER4> Common prefix or suffix? I know in the RxJS community it's not uncommon to suffix an Observable variable like `fooBar$`

<comment><USER5> I think that would be more trouble than it's worth. Since "any" is a keyword, you wouldn't even need regex to search for it. Something like this would work:

" = any"

This would _only_ show types that are aliases of the "any" type. As a side note, the following would create a compiler error ("cannot find name 'any'") because types are metadata and can't be used as program data.

const something = any;

</comment></comment></comment></comment><comment><USER6> I'm about halfway through migrating a ~30kloc ES5 codebase to ES6 with a transpiler (Babel), linter (ESLint), and fast test suite (Mocha) [1]. Once all files are going through the transpiler I'll probably add TypeScript or Flow. We already had RequireJS in place so the conversion from AMD to ES6 module format has been pretty straightforward, but I'm continually amazed with every file I convert I usually find a couple real bugs with the linter. The most common have been:

* Undefined variables referenced in a seldom-traveled conditional branch.

* Leaked globals due to missing `var` keyword.

Every bug I find is immediate feedback that this is a worthwhile use of our time.

[1] [https://medium.com/@kevanahlquist/evolution-of-javascript- at...](https://medium.com/@kevanahlquist/evolution-of-javascript-at- bluestem-285e4fc5ca26#.f9mn885tm)

<comment><USER7> I can't recommend flow highly enough for gradually typing existing code (as it requires far fewer code changes than TypeScript). Not sure what your timelines are like, but it takes no time at all to set flow up, and you might find it makes the task of migrating a little more varied.

<comment> a-saleh How does flow stand now?

I have tried to use it ~6 months ago and the tooling felt kind-of wonky and I didn't feel like maintaining the interface files if so much of it seemed to be in flux.

<comment><USER8> Based on a quick play recently, I'd say still slightly wonky. Nuclide has improved a lot but autocomplete etc. is noticeably sluggish compared to the atom-typescript plugin. On my travel 12" Macbook, Atom with Nuclide it's too slow to comfortably use and the Sublime plugin for Flow seems to be quite buggy, whereas the Sublime TS plugin is pretty solid.

In terms of type definitions available for third party libraries, Typescript is way ahead. I also think the documentation and community around Typescript is stronger, and will only get more so with the move to use TS as the default in Angular 2. Also the stability is great and the roadmap looks promising.

Nothing against Flow, I think it is great and definitely has some advantages (and anything which adds types to JS is a winner in my book!), but it feels slightly more like an internal Facebook tool that happens to be released to the public versus Typescript, which is more of a release quality product.

But yeah, either is great improvement over plain JS and I'd definitely consider Flow for a personal project, but in a bigger company/team environment I think the stability, tooling and community of Typescript would make me push for that.

</comment></comment></comment></comment><comment><USER9> I curious how using Typescript makes the project more "structured" compared to using plain JS.

Typescript just gives you static types and classes. I can understand "classes" make the code more modular and thereby more structured, but can't you already do that using ES5 "class"? Types help in catching errors early and can help in documenting the interface of the methods etc.

Also, if the other problem was isolating the scope of modules and dependency injection, it could be easily done using Requirejs and all the modules could be concatenated during build time. Webpack is a cool tool, but given the nature of its documentation, the maintenance would be really costly in the long run. Requirejs is just more established and satisfies all the author's requirements.

It would've been really helpful if the author had included additional reasoning behind the choices made.

<comment><USER10> The types are what give it structure. Types are the structure. When you create a type, you are saying in concrete terms "this is exactly how things happen and nothing else".

This is _very_ useful information for a large project. Think of it like a map. You don't need one for your house, but you need one to walk cross country. Or like NASA procedural manuals for something normal people don't need a guide for...like an astronaut taking a shower or something.

<comment><USER9> I don't understand.

> Types are the structure. When you create a type, you are saying in concrete > terms "this is exactly how things happen and nothing else".

Types make the interface concrete - which is better for compiler/interpreter (catch bugs) and better for developers (easy to understand instead of guesswork)

But when I think about "structure", It is usually about how the codebase is organized. How different modules interact with each other and is the flow of the code easily understandable. This could be easily achieved without Types.

Maybe it's just my interpretation of the term "structure".

<comment><USER11> It is pretty much impossible to have any sort of inferred structure from plain javascript. The reason you can use super powerful tools to refactor, rename, and find all references across files in typescript is because the IDE can build a 100% accurate data model of your code base when it's written in typescript.

<comment><USER12> You can do that kind of stuff in dynamic languages like JavaScript, Python and Ruby. Check out JetBrains' editors.

<comment><USER13> To do things like that in a dynamic language, you need to either infer types somehow, or rely on metadata like JSDoc, beyond the language itself, and that sucks – if another developer works on the project with a dumber IDE, their code will probably lack such metadata or it will not be entirely correct.

I have been using IntelliJ daily for the last five years for PHP, JS and TS development. For PHP, I write typehints and PHPDoc wherever possible to help the IDE make sense of things. For JS, I tried doing the same with jsdoc but it didn't work out, and I have decided to avoid any automated refactoring or even autocomplete, it's far too fragile. For TS, using the types in my code makes the IDE smart and reliable, although IntelliJ's support for type inference in TS is still far behind VSCode.

Special mention here goes to Magento developers, whose PHPDoc, 98% of the time, is either lacking or outright incorrect (referencing classes that don't exist – incredibly frustrating).

</comment></comment></comment></comment></comment></comment><comment><USER14> TLDR: rename files to .ts, download type definitions for external libraries, silence TypeScript compiler warnings using 'any'

<comment><USER15> Maybe initially, but that `any` type really defeats the purpose of having types in the first place. Where I work we have several 100% TS apps and we've banned the `any` type except for very rare exceptions. It's always better to define a type so that it can be easily used elsewhere, and it also helps prevent typos.

<comment><USER16> for data objects (no methods) you could at least use Object instead of any, this should prevent anyone from calling methods on it.

</comment></comment></comment><comment><USER17> By using haxe he could have started now transpiling some of those 10k lines also to the python backend just for free plus all the additional prepocessor and type checks that are common for typescript and haxe.

I don't really understand why people jumps to typescript and not haxe, which in my opinion has more strategic advantages and warranties (with very few exceptions).

Is perhaps just a marketing topic?

<comment><USER5> You're talking about two different things. Haxe is a different language, while TS is a superset of JS (all JS is valid TS).

JS -> Haxe requires rewriting 10k lines before the program will run.

JS -> TS requires changing the file names, doing some imports, and adding "any" in a few places. The program will then run, and type information can be added gradually.

<comment><USER17> I do not see that much of differences between Haxe and JS, mostly because Haxe is a superset of EcmaScript. However the process is not that automatic because TypeScript is more permissive I would say (though there is already a convertor from typescript to haxe: ts2hx).

But that said, I am not really that much experienced with TypeScript.

<comment><USER5> According to Wikipedia, Haxe is not a superset of ES:

"Haxe is similar to ECMAScript, although almost no ECMAScript code will run on Haxe without modifications."

</comment></comment></comment></comment><comment><USER18> I've always wondered if you could create a runtime inferrer of types for these sorts of projects. As in, attach something that observes function calls and sees over the course of some amount of time what types are passed into them, and have them make a best guess of what arguments are what types. While of course it couldn't be perfect, it could save a lot of grunt work.

I made a quick version of this idea in Python 3.4, where it was much easier since I could modify the AST on import, but I never quite got it where I wanted it and sort of lost passion.

<comment><USER19> You could probably do 80% of the inference statically as well. For instance, given something like this:

      function incrX(obj) {
        obj.x += 1
      }

We can infer incrX expects an object with property x, which is probably an integer. And therefore, a call like `incrX({x: "hello"})` is probably incorrect. In fact, I think this is how type inference in languages like OCaml works.

That said, I do wish statically-typed languages generally had runtime type checking built in. For instance, I can tell Typescript what type of response we're expecting to get from an API call, but that doesn't mean the compiled Typescript will warn me if the API call ends up with a different type.

<comment><USER20> > We can infer incrX expects an object with property x, which is probably an > integer. And therefore, a call like `incrX({x: "hello"})` is probably > incorrect. In fact, I think this is how type inference in languages like > OCaml works.

Except OCaml's typing is much stricter than JS's, in JS `obj.x += 1` is perfectly valid if `x` is a string. In fact due to all the runtime type conversion protocols you can have pretty much anything as `x` and have `obj.x += 1` succeed.

So that requires a strict break and separation with JS semantics and treating JS (or whatever) as an implementation detail and "assembly", which is the opposite of Typescript's purpose (it's more of an Elm or Purescript or ocaml_in_js thing)

> That said, I do wish statically-typed languages generally had runtime type > checking built in.

Statically typed languages with lots of holes (at the type-system level) like Java or C# do have runtime checks. Those with less holes like OCaml or Haskell don't as the only way to get the "wrong" types at runtime is to have wilfully undermined the type system in which case the developer is on the hook for making sure they do that correctly.

> For instance, I can tell Typescript what type of response we're expecting to > get from an API call, but that doesn't mean the compiled Typescript will > warn me if the API call ends up with a different type.

That would require TypeScript having its own runtime rather than compiling to regular Javascript, or it would require that TypeScript inject a fuckton of type checks which would make the output orders of magnitude slower (both from the overhead of javascript-level type-checking and from the increase in code size and decrease in JIT optimisation opportunities).

<comment><USER21> To expand, with regard to (GHC) Haskell: you can perform run-time type checks with the Typeable typeclass, and you can forgo compile-time checks in favor of runtime checks with Data.Dynamic. You can also replace compile-time detected type errors with "if this is executed, explode", with the -fdefer-type-errors flag. And of course, in any typed language you can apply sufficiently general types that you need to perform manual checks for safety.

</comment></comment></comment></comment><comment><USER22> A machine is faster and more reliable than a human at comparing. Matching types for verification is one of those things.

</comment><comment><USER23> Nice article, and I am going to give webpack a try. I took an eDX class in Typescript a year ago and really like the language but decided modern JavaScript was getting "good enough." I regret that decision sometimes because Tyoescript really is better IMHO.

<comment><USER24> Typescript is ridiculously easy to learn. The only hard part is getting your typings/build/environment set up, the actual semantics of the language are a breeze.

There are some subtle nuances to structural typing and interface definitions if you want to write really slick code, but for the most part you can get by without them.

</comment></comment><comment><USER25> Lots of intelligent replies here (like much of HN); having a Java & C/C++ background, I picked up Javascript some yrs ago for web work.

Now, I don't know how/if to move to Typescript or ES6? And any resources/books/vids you all highly recommend? (I built some corp stuff in Angular 1 but guess I'll have to move to TS for Ang 2 or learn React?)

Many commenters in this thread seem experienced in TS so thanks in advance for sharing any advice

</comment><comment><USER26> > Since globals defined in different JavaScript files share a common > namespace, I often found it convenient to reference globals...I knew all > along that these were bad habits

This line resonated with me. In my first CS course (Intro to programming), I learned about why using globals can be problematic.

A good reminder that engineering is all about trade-offs. Sacrifice future maintainability for present day productivity.

</comment><comment><USER27> I feel that academic code is generally more prone to bad-smell pressure than industry code, since people generally produce for papers and deadlines and "just get it working for now." It's good to see that it's possible to produce some semblance of order in the constant grind.

<comment><USER28> Right, and "just get it working for now" never happens in non-academic projects.. :)

<comment><USER27> I don't know, but outside of large CS systems projects, I haven't seen much incentive to "build things right", especially from the higher-ups.</comment></comment></comment>


You build it and the users will come. - <AUTHOR>

Just to scratch my itch, I developed a service for all immigrants (http://ismyprioritydatecurrent.iklavya.com/). The service does not even show up on google results since I didn't market it at all. The only thing I did for marketing was to include it as an external link on wikipedia. And I was happy to see that 10 users signed up for the service. Just wanted to share with the community :). <comment><USER2> Well you scratched an itch which every immigrant who has come to the US to work has! So you actually did customer development but you did it subconciously :) ...

I used to check the damn website everyday 2 years ago before I got my g.c.

Get a designer to work on your site for a day and you'll be the top hit for this particular pain point. You need to show the relevant data you used to figure if someone is current. This will make it more trustable.

If you put a email form at the bottom for people interested in getting SMS updates for $5 a month, it'll be interesting to see if anyone signs up.

<comment><AUTHOR> yeah, i got to enable sms as well. thx for the encouragement.

</comment></comment><comment><USER3> How long did it take to get those 10 users?

<comment><AUTHOR> It took about a month I guess. So yeah, it's been very slow.

</comment></comment><comment><USER4> aren't attempts of marketing through wikipedia being quickly removed by some frustrated people?

And yes, the website needs to get styled up a bit ;) Good luck!

</comment><comment><USER5> So go get listed on google, what are you waiting for?

<comment><AUTHOR> Yeah, that's definitely the next step.</comment></comment>


Stamp design errors - <AUTHOR> http://www.edbmb.net/stamps/index-1A.php <comment><USER2> I love it when articles HN takes me down a rabbit hole. These stamps are interesting but the one from Pitcairn caught my eye.

I had no idea that Pitcairn existed, it's a little island inhabited by descendants of the mutineers of a famous English ship called the Bounty[1]. It's inhabited by only 60 people[2] and the only settlement is the 2nd smallest capital in the world.

It's even got it's own TLD: .pn[3]

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

2\. [https://en.wikipedia.org/wiki/Adamstown,_Pitcairn_Islands](https://en.wikipedia.org/wiki/Adamstown,_Pitcairn_Islands)

3\. [http://www.government.pn/](http://www.government.pn/)

<comment><USER3> Here is a application to be a teacher dated 2016. Seems relevant considering the stamp [http://www.government.pn/EO%20Ad%202017.pdf](http://www.government.pn/EO%20Ad%202017.pdf)

</comment></comment><comment><USER4> > A Rubick's cube with 3x3x4 levels is technically impossible

Nope, you can buy fully functioning ones, from several manufacturers even.

<comment><USER5> Can you link to an example? I know that 4x4x4 is thing, but 3x3x4 does seem impossible.

<comment><USER6> [https://www.youtube.com/watch?v=yrVCUBfOGNg](https://www.youtube.com/watch?v=yrVCUBfOGNg)

</comment></comment></comment><comment><USER7> The weird step in the bore of the Denmark 1976 horn is covered by the hand so you can't be certain that it won't produce a sound. But it is certainly being played wrong. Brass instruments are pressed against the lips, not placed into the mouth. The vibration of the lips is the origin of the sound.

</comment><comment><USER8> If you've not seen it, there's a fantastic children's movie from the 80s called "Tommy Tricker and the Stamp Traveller" where all the kids collect stamps, and it's a great stamp movie. Do check it out.

<comment><USER9> Agree, in the stamp movie genre, it's easily top 10. :)

<comment><USER8> Wait, there are others?! Top 10? That means there are 9 more - share!

</comment></comment></comment><comment><USER10> I would guess that many of these were intentional since the clarity without magnification is more important than zoomed in accuracy.

<comment><USER11> Which of these errors would improve clarity at the macro scale? I doubt any of them would.

<comment><USER12> Off the top of my head, the German bird probably does. It probably gets muddled if the cage bars overlap it.

<comment><USER11> There are other birds on the same stamp and they're all behind bars. Only in that one cage is the bird in front of the bars.

<comment><USER10> This is still a good example. The bird he is holding is a more important object than the other birds. It's a focal point. This is also true with the ship ropes cutting through the moon, if they don't the moon shape stands out more. Omit a toe so the foot looks like a foot, otherwise the toes are too small and look jumbled anyways.

There's even the building with the tree shadow. If the tree shadow was in the foreground it would not even be visible on the stamp. If the light source was really respected, the building would be casting a shadow on the entire scene and the building would probably look poorly lit itself. More than likely, the image was drawn based on a view where the light source created the best light on the building thus the shown shadow of the tree. However, that left the sky empty - so let's just draw in the sun and it looks great. Is it photo accurate? No, but it doesn't make it an error.

<comment><USER11> I don't know why you're trying to rationalize this. It's much more likely that all of these examples were genuine errors than that someone decided to introduce something that is _obviously_ incorrect because they thought it was somehow more aesthetically pleasing.

<comment><USER10> Seriously? How about because you asked for examples.

And it's something I personally do all the time. I'm in photoshop zoomed in to perfect some detail, then I zoom out and it looks like garbage. So I purposely make an "error" so it looks better at 100%.

I don't know why you insist on having such a literal photo realistic illustration or else the only rational explaination is that artist must have made an error. Error implies unintentional, which many of these are. But many are not.

<comment><USER11> I get the concept of introducing tiny errors to make it look better, but I disagree with almost all of the examples you cited.

For the bird one, the shape of the bird in that cage is different than the other yellow birds, but is identical to the black one. So that bird was probably originally black, then was edited to be yellow but they forgot to restore the black bars over it.

For the moon one, that's extremely implausible. It's a tiny rope, right next to a large shape that clearly cuts across the moon. Having it go behind the moon doesn't make the moon stand out any more, it's simply an error. In addition, the moon isn't even the focal point of that image, it's a fairly incidental detail (hell, it's almost hidden behind the house).

The toe one is the only one that I think is plausibly intentional.

For the tree one, I agree that the scene was likely drawn without a sun, then the sun added in after. But that _does_ make it an error, because they decided to stick a sun somewhere that clearly contradicts the lighting on the rest of the stamp.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> > Can anyone explain why the two skis are exactly in line, and not the left > and the right foot

this is completely compatible with telemark skis, where the toe is anchored but the heel is free.

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

</comment><comment><USER14> Am I mistaken or the Copernicus one, they say Venus is missing, when it's actually Mercury?

</comment><comment><USER15> May I suggest this one too?

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

</comment><comment><USER16> Pretty sure the Belgian Congo one from 1949 is just eyes playing tricks on you. I see it blowing the proper direction looking at it immediately. If I stare hard enough, I can see the perception of it being backwards, however.

Fun read though!

<comment><USER17> I'm not sure there is a perception issue if one flag is waving backwards, and the other three forwards. Wind doesn't really work that way (at least not within a few meters of height). The sails also indicate that the wind is coming from behind, which makes the flag at the stern impossible.

<comment><USER16> Ah! I just saw what was being pointed out. The focus of the picture made it seem like it was the top sail of the middle mast, not the flag at the stern. :D

</comment></comment></comment><comment><USER18> In "Four inverted N in one sentence" the `W` is inverted as well

</comment><comment><USER19> Damn, I have two of those errors in my own collection..sweet</comment>


A Two-Miles-per-Hour World: the speed that news traveled to Venice, 1500 to 1765 - <AUTHOR> http://pages.uoregon.edu/dluebke/301ModernEurope/Space-Time%2016thC.html <comment><AUTHOR> I should add that this submission was inspired by the discussion yesterday about the 1914 map of travel times from London:

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

Fernand Braudel is one of those people who specialists in a field all recognize as a revolutionary figure but the general public doesn't seem to know about. In my view he's probably the most influential historian of the 20th century, not least because of his innovative way of thinking about data visualization and mapping. His work ended up leading to some very early experiments with what we now call digital humanities among his various acolytes in France and the US, back in the punched card era. Interesting guy.

Edit: forgot to mention a famous bit of lore about the book these maps came from - he actually wrote the original draft of it when he was a member of the French Resistance imprisoned in a Nazi POW camp.

</comment><comment><USER2> The degradation of service from some areas (particularly France and the Iberian peninsula) between the second and third maps is interesting. I guess that it was a consequence of deteriorating political relations (the War of the Austrian Succession, perhaps?)

<comment><USER3> An interesting point: but the distances over land don't vary that much. I suspect it is insecurity of sea travel between Italy and Spain, but from what? Anglo-French conflict, North African corsairs?

</comment></comment><comment><USER4> A 1TB drive going 2 miles in one hour would still be a decent transfer rate.

<comment><USER5> Over what distance?

<comment><USER6> Trade off between (physical space = delivery cost, ping) and bandwidth. A suit case can easily fit 20 1TB drives. A 20 hour journey from Sydney to London, would mean a transfer rate of 1TB per hour, or 2000+ megabits per second, or 300x faster than the internet in my own home. Even carrying only 1 terabyte over 20 hours is a decent 111 megabits/second.</comment></comment></comment>


Eclipse Kepler 4.3 released - <AUTHOR>

<comment><USER2> This would have been more useful if you told us what it was, what it could do.</comment>


IE9 Downloaded 2.35 Million Times in First 24 Hours - <AUTHOR> http://www.pcmag.com/article2/0,2817,2382120,00.asp

<comment><USER2> I like this one better:

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


Useful resource for rails developers - <AUTHOR> http://mike.bailey.net.au/2011/02/json-with-ruby-and-rails/

<comment><AUTHOR> I need this kind of input I'm developing a web server REST-oriented using json for rails. every kind of resource is well appreciated this gave a useful introduction to play around with json in irb</comment>


Social News Reddit Alternative - <AUTHOR> http://www.duno.com <comment><USER2> The front page is covered in people seeking dating or sex. I don't think this is a viable Reddit alternative.

<comment><AUTHOR> thank you for the comment... of course its not yet... i am pushing all kinds of people in there it will take maybe 6-12 months before the traffic is reasonable

<comment><USER3> One of the underestimate things of building a reddit alternative is the effort to moderate. You must moderate aggressively to give the site the feel you like. For example, HN is extremely heavily moderated in spite of the plain look.

Do you like to build a site that your family would use? Will they like the current mix of stories there?</comment></comment></comment>


Hank Azaria Won't Play Apu on 'The Simpsons' Anymore - <AUTHOR> https://www.nytimes.com/2020/02/25/arts/hank-azaria-simpsons-apu.html <comment><USER2> Sad. Apu is one of the coolest and most heroic characters on The Simpsons. And for Americans who have never met someone from India, a gentle introduction to the unfamiliar.</comment>