skysight-inc/HackerNews huggingface dataset:
There's some typoes and broken links. I like the code, though, lots of work has been done.

It's worth bearing in mind that messages per second is important, but it's easy to get fixated on benchmark porn.

Different queueing systems have different guarantees, disciplines and semantics. These affect user-facing behaviour, which tends to be more important at first blush than throughput.

I like zillions of messages per second as much as the next fellow. But frequently you need to worry about things like:

* Are messages delivered once and only once?

* Are messages are messages delivered at least once?

* Can messages be dropped entirely under pressure? (aka best effort)

* If they drop under pressure, how is pressure measured? Is there a back-pressure mechanism?

* Can consumers and producers look into the queue, or is it totally opaque?

* Is queueing unordered, FIFO or prioritised?

* Is there a broker or no broker?

* Does the broker own independent, named queues (topics, routes etc) or do producers and consumers need to coordinate their connections?

* Is queueing durable or ephemeral?

* Is durability achieved by writing every message to disk first, or by replicating messages across servers?

* Is queueing partially/totally consistent across a group of servers or divided up for maximal throughput?

* Is message posting transactional?

* Is message receiving transactional?

* Do consumers block on receive or can they check for new messages?

* Do producers block on send or can they check for queue fullness?

And there's probably a bunch more I've forgotten.

The thing is that answers to these questions will fundamentally change both the functional and non-functional nature of your queueing system.

For example, a queue system giving best-effort, unordered, non-durable behaviour is going to run a lot faster. It also pushes a lot of work onto the application programmer. On the other hand, once-and-only-once, durable, consistent queues are lot slower and screech to a halt under most partition conditions. But they also fit what most application developers expect to happen upon the first encounter with queueing systems.

I work on a section of Cloud Foundry in my day job, and other teams have seen that different tasks require different queueing approaches.

For example, stuff like metrics is is still useful under conditions of dropping messages, out-of-order messages and so on, because what's interesting is the statistics, not any one single measurement.

But a message like "start this app" requires much higher guarantees of ordering, durability, delivery certainty. People get mad if your PaaS doesn't actually run the application you asked it to run.

So, just remember: queues are not queues. You need to compare delivered apples with lossy oranges.

As a note, the author observes that MQTT provides an option to select which delivery semantics you prefer (at-least-once, at-most-once / best-effort, once-and-only-once), but I can't see which one the benchmark is run for.
Sure, it could be objectification. It's pretty cut and dried in this case since the image was scanned from a magazine almost at random. The woman had no agency in the decision at all.

Of course I'm going to attack that. Women are required to be beautiful or they are deemed worthless, or failures. So they put a lot of work into it from a fear of failure. Men can be beautiful too, especially to a woman's eye which you've never seen through. If men were made to worry about their appearance as much as women, we'd be "fair" too.
Disney Research: High-Quality Capture of Eyes
You missed the point of the note. The point was to have the kernel balance what is on disk and what is in memory.

Varnish (w/MSE) still relies on the kernel for this. However, as you cannot atomically write a whole page through a mmap (thereby avoiding the page fault) we have to use write(). It still is read through mmap and the kernel still drop pages whenever it feels like it.
xml is technically a superset of JSON, just can't imagine any clear advantage of JSON vs XML - it's the same league, just some minor syntactic differences.
And what is the end of the story for JSON, is just a beginning in XML: the concept of namespaces is powerful and totally foreign to JSON. Then XML Schema - another job well done and poorly mimicked in some JSON libraries. XSLT just builds on these concepts and is not a general purpose tool - don't see a reason to have strong opinion about something so narrowly specialized.
We used them recently in nyc and user experience was great. However once you do the math, a 10 - 15% markup on most products in addition to delivery fees, tips, (or prime) is simply too much if you use them on a regular basis. The annualized cost for a small family is easily north of $2000.

Now I know that "price is what you pay and value is what you get". So there are definitely occasions when I will use them.
But I honestly doubt that most of their users realize the true cost of their service.
I think that actually the caption is "correct", and they must have simply included the wrong image, because the text says "Figure 2 shows the
original digital image of Balloon, which is of dimensions
512 pixels by 512 pixels, with 256
gray levels at each pixel."
I agree that stellar-like systems might have a role to play in the future, but surely a coin with an incident of corrupted transaction logs is inferior to one without such an incident, all else being equal.

EDIT:

To those pointing out the 2013 Bitcoin fork, good point.

However, in cryptocurrency land, 2013 is ancient history, and I'd argue standards are higher already.
>XML-hating JSON community

What are you even talking about? It seems like you think that XML and JSON are two mutually exclusive technologies and that if one is bad, the other is good. Or that if one is used, the other can't be? I don't understand why you even started talking about JSON; the article was about why XML and XSLT suck, not why JSON is superior to them.

I'm not really sure what point you're making. JSON is meant to make passing data in JavaScript easier. It's a necessary tool for interactive, JavaScript-heavy web frontends. I'm not sure why there's so much condescension in your post for JSON and its tooling. I'm just a bit confused; it comes off like you have a personal stake in XML and you find any mention of JSON, even obliquely, as offensive.

There's no reason that XML and JSON can't both be tools we use when the situation calls for it. This kind of dogmatic defense or condemnation of technologies offhand doesn't really do the HN community or the programmers at large any good.
In the central valley, some areas have sunk 30+ft over the past century due to aquifers collapsing.

http://www.watercalifornia.org/projects/projects_img/enid/fa...

http://www.capradio.org/articles/2013/11/22/usgs-study-1200-...
The article mischaracterizes the criticism agains PHP as boiling down to thinking that nothing interesting can be done with it. In doing so, it fails to respond to what criticism against PHP typically boils down to: PHP sucks.
Introduce stacked notification in ngN 1.2
> It is still far faster and easier to put together a website in PHP than any other language.

Faster than Node.js + Express?

> It has enabled millions of people to become web developers.

Factually (probably) correct, but irrelevant to the quality of the language itself. Bit of a pointless argument, as it wasn't the crappiness of PHP that made it popular; it was just the only accessible platform around and happened to be crappy.

> It powers about 90% of the web

Appeal to popularity, not a valid argument. Says nothing about language quality.
ZFS has a very advanced caching mechanism, I wonder how it would compare to standard file systems or the kernel's paging for something like this.

It's also pretty common for people to enable file system caching plugins in Wordpress, Drupal, etc. and forget to leave the system enough RAM to actually do its business. D'oh.
This might be a golden opportunity to switch to more drought resistant and low water consuming crops.
Now make that API agnostic so I can use package from any distribution (deb,rpm,pkg,static build) and I am in!

FYI we also know guix...

My main problem is that you repackage every lib and build it on your own, sometimes some patching is necessary to make it nix aware.
Deploying by hand is an extremely bad habit that novice developers should be steered away from at all costs. If they can learn how to use version control, they should have no trouble at all picking up an appropriate deployment tool for their chosen language (even if that language is PHP).
They knew this trick back in the time of the Roman Empire.
Bread and Circuses: bribe the population with free bread and distract them with circuses whilst the rulers do whatever they want.
Software hackers will come up with a single right solution. This solution is cemented in theory. Transforming one (message) tree into another must be done in the following way: http://www.usethetree.com

Don't just downvote me. Challenge me!

Edit: Maybe downvote & challenge me :-) ?
The whole mass spying seemed like a conspiracy theory to most of us just few years ago.
But XML does not map well to a database dump. A database is a set of sets of tuples. It is not generically hierarchical. It maps to a set of csv files say, as a transfer medium, but it is designed to be manipulated through relational calculus, which is not easily mapped to xslt.

You are using tools not because they map well to the problem space, but because they are the tools you have, which your customers want, and which you are familiar with, but that does not mean they are actually mapping well to the domain.
From a $4.95 ebook to a $12,000 course
Afghanistan: The Making of a Narco State
There was an IAMA on reddit a while back which was with JPL engineers. One of the engineers was asked what would happen if NASA had the funding of the pentagon. He said space colonies would be there and possibly an interstellar probe.
Decentralization is not overrated, just misunderstood. The primary concern should be whether a central entity can change the agreed-upon communication protocol at will (i.e. arbitrarily change the "rules" of the money)

With Bitcoin, such a change is very difficult. With stellar, it is easy for the central Corp to change the rules at it's whim.
I will risk that this will be an unpopular opinion, but if you are having problem with XML, you are using it to solve the wrong problem.

I understand writing XSLT and XML Schema can be difficult and I see how typing out XML namespaces can be a pain, but every sentence about XML in that article is a joke. Those quotes are all intended to be funny,
not objective. Noone actually brought an objective facts against XML. Because they can't.
The fact is it is widely used in many places. Anyone tell me an alternative to serialise an object tree
where you also need to preserve ordering and type information, you need to store text longer than one line,
or you just need to store any kind of formatting information. (and yes, you can use JSON to do that, but the resulting document will be 5x longer)

(meta: Funny quotes bashing useful technologies is the cat video equivalent of HN.
Last week's article beating OOP was the same pattern.)
Cold Storage for Colored Coins
Yes, but note that Bitcoin had a blockchain fork in 2013 http://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-bl.... Without knowing the details of Stellar's fork I make no comment on the relative severities/merits.
For the 10% hit, I agree with you. For one large French site (but with a national audience only), the efficiency of the route cache was more than 95%.
Is there a better way of showing a text message in a film?
Act with great Responsibility
You must talk to a lawyer about this, and you may not like what you find out. Because you didn't set up vesting, both of you will own 50% of the company no matter whether either of you leave. You plan on leaving and starting a new company, so that shouldn't matter. But it might if your cofounder shows up in a year and says that the IP belongs somehow to the company they own half of.

These are the worst kinds of problems: the ones that only matter if you get "lucky" and are "successful", but your success is counterfeited. You want to make sure that can't happen here, or else work on a different project.
Desalination can handle drinking water but 90% of water usage is usually for irrigation. It is not cost effective to do that with desalination.

As for Australia's 6 or 7 built/planned desalination plants: they are for backup and supplemental purposes only. They can't supply more than about 10% of the largest Australian cities' typical water usage. They would provide emergency water in a catastrophic drought and in low rainfall years can lessen the burden but they are not a replacement for good water catchment management.
Bitcoin had its incidents in the past as well!
I think I should collect a bunch of quotes espousing the virtues of XML and XSLT and put them on a web site so people can link to them.
Very little performance work has been done so far. Most of the effort has been in E5 compliance and more recently to support low memory environments (96-128 kB system RAM) better. But there's going to be performance work early next year.
Insights on How much you should pay yourself while bootstrapping
Teleconferencing while on high speed rail
No value: Investing, CEO pay and the economy
Well, you can do that too. However, how does "ftp index.php" work once you use dependency management?
I once worked on an embedded system with not a lot of RAM or code space, and we were ripping features out to put new stuff in and rewriting things to make new things fit (not a bad practice, re-writing, btw). I wrote some tools to do global optimization at the assembly language level and got back 40K because our compiler was one of those $5000 / seat pieces of crap, and we didn't have a debugger, so object-to-source-line mapping, who needs it?

Anyway, one of the PMs on the project insisted that this choice little hunk'O'hell communicate with the outside world -- at about 2K bits / sec on a good day -- using XML. Because it was standard. Because XML added to anything makes it better, no matter what it is. Because, well, nobody ever saw that traffic except other computers, but XML!

I wanted to kill, kill, kill, but instead I wrote an XML parser (kind of) that fit into about 1K of code. "Don't use entities or CDATA or namespaces," I said, and went away to a better place. I think the PM was happy. That group got sold to a company famous for its 60s-era radios and crappy teevees, and I assume everyone is happy there, because I have not heard a word from them, and XML!
What's fragile, insecure, and terrible about them? I've written C/C++ (among other languages) for years at work and it's quite rare that I see a bug that could be attributed to the language.
> Faster than Node.js + Express?

Absolutely, yes. Take a newbie and ask them to create a web page using express, then ask them to try in PHP. They are worlds apart in terms of usability and approachability. (I say this as someone who almost exclusively writes in node these days)

> it was just the only accessible platform around and happened to be crappy.

How can it be crappy if it's the only accessible platform around? An alternative view point is that PHP is the best, most empowering platform, because it's accessible to newcomers, and every other language is crappy in comparison because they have failed to match PHP's accessibility.

> Appeal to popularity, not a valid argument. Says nothing about language quality.

You seem to be talking about PHP the language. There is no doubt that PHP the language is flawed. That is totally irrelevant. What matters is how effective PHP the ecosystem is, and it is undeniably incredibly effective. That's why people use it, because it is a practical way to get things done.

So, if we're talking about PHP the ecosystem, then popularity is absolutely a valid metric here. It's easy to hire for, has tons of libraries etc, this stuff matters a lot more than the associativity of the ternary operator.
Yeah, people pointed out when Ripple launched that there was no reason to believe its consensus algorithm would reliably reach consensus, and the developers dismissed their concerns. I think someone even demonstrated that certain network topologies would result in a permanent fork in the transaction history, and they dismissed that too.

(Stellar was, of course, founded by a couple of the Ripple founders using exactly the same technology they used for Ripple. Also, we're talking about the new "decentralized" Ripple here; there was an older version of Ripple that was centralized but didn't have the same problem, and that's the version that predated Bitcoin.)
I think they're big enough for most of the developers that you might want to start hiring to care though. Finding and employing great PHP developers is really hard.

Ruby, Node.js/Javascript, Python are all excellent, mature languages with huge pools of good developers (at least in London). They simply lack the ease of bootstrapping (as you pointed out).
I'm always very impressed with Joey's work. I'm a heavy user of git-annex. My concern with Propeller is there's too much fragmentation around configuration management tools: this is something that only Propeller can do, and the impression I get is that most other projects support Chef or Puppet, while I'm currently using Salt, because I like its pattern of declaring the desired state of a system (and I picked it before Joey released Propeller).

It seems all to easy to jump on one technology stack, gain its improvements, but find that there's a whole lot of nice things you've locked yourself out of, because you can't really use more than one tool at once. And because implementation language seems to be a core feature, I'm not sure reusing modules is a feasible.

I don't have any suggestions, though :(.
> JSON is meant to make passing data in JavaScript easier.

No, its not.
"dependency management" doesn't really come into play with the scenario we are talking about which is:

"It's completely optimised for the scenario where you simply want to create a webpage." [for a novice programmer]

I recommend you read over the parent comment again: https://news.ycombinator.com/item?id=8709025
The fact alone that a particular conspiracy theory turned out to be true doesn't automatically lend credence to others.
What's the point of academic publishing?
Python was designed as a teaching language, you should check out django. I hack node all day but of you haven't done async before node can be tough.
Google admit advertisers wasted their money on more than 50% of Internet ads
That's the thing - you can call it controversial, but he hasn't shown anything illegal. He'd have a lot more support if he stopped with the cell phone metadata revelation. Section 215 was controversial to begin with (remember the Section 215 library records fiasco from a few years ago? [1]). It's been debated in Congress at length since the revelation.

Everything after that has been showing actual foreign intelligence collection or technical information on the NSA's capabilities, often times shown to the public with a warning that they could be used against ordinary citizens, but no evidence to show that they have. In fact, multiple independent reviews of the NSA's program all mentioned in their reports that they found no evidence of abuse[2][3][4].

If he's going to go up and make the claim that the NSA is spying on all of us, I what to see actual evidence of spying on regular people, not descriptions of how they spy with a warning that it could be used against us. That's like saying "the police have guns - they could use them to kill your children!" Instead of showing small number of revelations limited to actual abuse, he's instead given us this: [5][6].

He doesn't get to say that he has no responsibility for it or try to shift the blame over to the reporters. He dumped a huge trove of documents on them unrelated to abuse.

[1] http://www.ala.org/advocacy/advleg/federallegislation/theusa...

[2] http://www.whitehouse.gov/sites/default/files/docs/2013-12-1... (PDF page 78/labelled p. 76)

[3] http://www.pclob.gov/Library/215-Report_on_the_Telephone_Rec... (p. 16/12)

[4] http://www.pclob.gov/All%20Documents/Report%20on%20the%20Sec... (p. 7/2)

[5] http://www.lawfareblog.com/2014/01/the-extent-of-the-snowden...

[6] http://www.lawfareblog.com/catalog-of-the-snowden-revelation...
>I'm sure in some cases XSLT would be better for the job

In some (simple transformation) cases XSLT would be no worse, but mostly it would be worse. I can't see it being clearer or easier to maintain under any circumstances.

Once your code evolves toward doing anything mildly complicated you'll wish you never made your transformation in xslt.
What I normally do is swap between normal mouse and trackball, but I think sustained use of my phone has been bothering me more than recently. I've never been diagnosed with carpal tunnel, but I definitely have some kind of repetitive strain injury.

If it's an RSI and not getting better from breaks, I'd recommend Active Release Technique (http://www.activerelease.com/). I've been going to an ART provider for a knee injury, but since I'm there they also work on my wrist and it's been helping. The 2 places I've been are classified as chiropractors for insurance purposes, since they're chiropractors who also practice ART. This has its pros and cons - you don't need to get a referral to go, but you could be limited on sessions.
A planet of suburbs
You could just ftp the files directly from a particular branch, and keep the dependency management entirely off the production server.

You probably shouldn't do it that way, but that's one way it could be done.
> Lets not make it harder than it is.

Sure. Either your hosting provider supports your language of choice out of the box, or it doesn't. If it does, deployment will be simple. If it doesn't you still need to configure a web server and install whatever package you need (for comparison, here is how you configure Apache for the Flask Python framewrok [1], I don't see how that's significantly harder than configuring Apache for PHP).

> The limits of the language means nothing to 95% of it's users and even when they do as in the case of facebook it's a problem of success and has been solved.

Well, "Bobby tables" and XSS don't mean anything to a lot of people. It doesn't mean that PHP has acquired a sane templating system out of the box, that it's stdlib has acquired consistency or that it suddenly got hold of a type system. PHP is widely supported by hosting providers, and it does make it easy for inexperienced people to use it. That's, IMHO, its real strong point. Apart from that, it doesn't do anything better than other mainstream dynamic languages, and it does a lot of things considerably worse.

1: http://flask.pocoo.org/docs/0.10/deploying/mod_wsgi/
Just install an outdoor radiator (electric heater), perhaps with fans if outdoor temperature is very high, and burn off the excess electricity. Switch the radiator on or off by computer. Dirt simple and cheap.
I'd just like to plug Teleport [0] into the list of reinvented JSON-based solutions. It's in active development :)

[0] http://teleport-json.org
You say that 'John Smith' was able to connect to you, but you weren't initially able to connect to him. This sounds unsymmetrical, but I'm wondering if it is because you first searched for 'John Smith'. After this, he is allowed to connect to you since both parties would have shown interest in each other. I don't know if this is the case, but it might make sense to implement such a rule.

The unverified adoption of any job title of any company is still a pretty serious issue though.
America’s Toughest, Ugliest Warplane
isn't this simply solved by functional languages that support pattern matching?