raulk

Revel with me in the thought that we —humans— think we are center of the world.

That Earth is made for us and we have the power to shape it in whichever way we wish. That we own the planet.

But, in reality, we don't. We are here only temporarily. There are powerful organisms hiding out there who are perennial.

And they act like guards. If we push it too far, we set off the right conditions for them to spring to life, and restore balance on Earth by anhililating the threat — i.e. us.

What a time to be alive!

JBI déjà vu. I see some parallelism between this JSR and the Java Business Integration (JBI, JSR-208) JSR back in 2005.

Instead of building a standard for integration, they ended up specifying a standard for interoperability between integration components from different vendors, i.e. a "meta"-integration system (using the same term as the author).

The result was a spec that allowed an (a) HTTP adapter from Oracle to exchange data with a (b) File adapter from IBM – through (c) an ESB implemented by TIBCO, for example. Essentially something that nobody would even think of deploying (in the era of proprietary, expensive and lock-in middleware).

Obviously the standard was DOA and had very little traction. Not even the JSR members implemented it. The only memorable implementation was Apache ServiceMix, which later transitioned to OSGi, spinning off its kernel as Apache Karaf.

In hindsight, the vendors might have acted like trojan horses with JBI, steering the spec into a territory that would be ultimately worthless.

The lesson to learn is that commercial vendors don't gain anything by standardising on those elements they consider strategic differentiators (like their module system).

EDIT: minor edits for clarity.

That would defeat a major goal of isolation: security.

It also creates fragility. What happens if a process is buggy and rallies up to 100% CPU? It affects all others.

Although to solve these issues you could use cgroups and namespaces... Aaaand we're back to containers again.

Using VMs to isolate single processes is like owning multiple toasters, and buying a different house to plug each toaster in.

> If you're running 20-30 containers on a beefy VM, you're not really condensing anything. You're just moving from running hundreds of small VMs on a single server to running much less larger VMs.

Of course you are condensing. Those small VMs would have been running a full OS runtime each.

Assuming you relocate those workloads onto a single machine (1 process = 1 container), you no longer run 20-30 copies of an OS, just a single one.

And the container engine takes the place of the hypervisor.

Doesn't this article fail to consider the bigger, practical picture, i.e. overall resource efficiency/footprint in multi-component architectures?

Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources).

Example: consider you need to deploy not just a single instance of Wordpress, Redis, Postgres, etc., but a complex application consisting of many of those components.

You can either choose to (a) deploy each in a different machine [incurring in the overhead of OS + unused resources]; (b) in different VMs [incurring in the cost of OS, but being able to share a resource pool]; or (c) in containers, sharing the OS and incurring in the overhead of the container daemon.

I would love to see an article that takes these points into account.

> ... why not just use a h1?

Because the HTML tags you choose affect document structure and SEO. CSS classes don't; they only affect aesthetics.

The North Korean developers who worked on this must be privileged beings with access to the open Internet. I can't imagine developing such a complex system without documentation and references.

Maybe they even hang out in Stack Overflow...

The new coin is still called "pound", so indeed the statement makes no sense.

Whenever you create an ad on FB, it is also placed on Instagram by default. I wonder how many out of that 1M were people who didn't disable the default.

The "languages over time" section [1] is overrepresenting Javascript. It shows separate charts for JS and node.js, when the latter is not a language but a runtime environment.

I would love to see the chart for Go instead of Javascript twice.

[1] http://stackoverflow.com/insights/survey/2017/#technology-la...

All I'm saying is that it's unfair to discredit the argument that Haskell has been around for 25 years, hence its had more time to evolve a more complete tooling offering. It is a valid argument.

If Haskell didn't exist and had only been launched a few years ago alongside Go, what would the status of its tooling be today? That would be a fairer comparison.

Obviously one can't measure it objectively, but you do have a comparable case with Elixir, I believe. And it's clear that Go surpasses Elixir in traction.

So let's not discredit the merits of Go in such a long time. It definitely has more happening for it now than Haskell or Elixir.

When a decent software engineer builds a project, you not only take into consideration the status quo of the technology, but also its promise, momentum and community development speed. You don't want to pick a stack with weaning manpower because you'll soon be left with legacy software in your hands. Hence, I do think that, for most serverside projects, the "promise" (as you call it) is very relevant and a true factor of decision.

GraphQL is not a database.

Nice writeup! ZeroMQ is not written in Erlang. You probably confused with RabbitMQ, which is.

What determines if a technology is considered legacy is not if there exists someone out there using it, but rather whether there are people actively adopting it at present. In this regard, Mercurial has slowed down and Git has clearly won the game.

Ah, found a way! If you click on Download in the Podbay page, Podcast Addict recognises the file and allows you to open it.

I'd buy you a beer if you could find a way to open the podcast episode directly on Podcast Addict and other apps when you click on it.

This is awesome! I'm an avid listener of podcasts, because I can learn stuff, listen to great people and interviews, broaden my ideas... All during what would otherwise be downtime (walking the dog, grocery shopping, driving, etc.)

There are some podcasts which I consider vital, but for most I don't care about the podcast itself but for the content of a given episode.

This app is awesome because it detaches content from podcast and helps discover cool episodes.

Wish you lots of luck!

"Public key from server" is an ambiguous phrase. I took "from" to denote possession, not source.

After reading the other sources of information, it's clear it is a secure protocol. More so when designed by the Snowden-approved Open Whisper Systems team.

The article says: "With end-to-end encryption in place, not even WhatsApp’s employees can read the data that’s sent across its network."

But according to the diagram: http://www.wired.com/wp-content/uploads/2016/04/Whatsapp_Enc...

... A's message is encrypted with Whatsapp's public key, which means that Whatsapp's private key can (and has to) decrypt it on the server side to encrypt it in turn with B's public key.

If the diagram is truthful, the claims the article makes are incorrect.

Cheap labor != consultant. In fact, real consultants tend to be expensive. A real consultant is an expert in a field, not an asterisk or wildcard for anything.

So finally we understand Chandler's condition (Friends).

Actually, you can decode a stream as HTTP traffic in Wireshark. It assembles related TCP packets and puts together the conversation from the viewpoint of the application layer.