STRML

Just Business Support, we're not that large of a shop.

There's an open support ticket, but I've reached out as well.

Our particular use case involves a few processes that are heavily serial, while yet memory-intensive; the fastest possible processor would be a boon to us (for instance, if someone would guarantee an overclocked Xeon, we'd take it in a heartbeat for almost any price).

AWS is indeed behind the curve more often than not, but they also have some amazing hosted products. That was a bigger deal in 2014 than it is now (Kubernetes will eat the world) but it's still a reliable offering, and reliability is our most important criteria.

Agreed re: being multi-cloud in the end. It's the only responsible choice above a certain scale.

Worse still, we spent weeks on the phone with AWS insisting there was no throttling - just to find out there was throttling. And that would have been discoverable if a single engineer had looked at CloudWatch.

That's more helpful. That's a lot of special cases - and thought - to put into each time we look at a C5-attached volume as opposed to any other. It also does not include any mention of Average Read Latency and Average Write Latency, which appears to be incorrect in all dimensions (average, min, max, sum).

While the new C5 instances are certainly welcome - I've been hoping for their release since their announcement in November 2016 (and they were already late for Skylake at that point) - we have encountered a number of show-stopping problems that point to this project being just a bit too ambitious.

To name a few:

1. EBS volumes attached to C5 instances show completely bogus CloudWatch metrics, over an order of magnitude higher than reality (e.g. average read/write latency prints at 100-60,000ms depending on load)

2. C5 instances don't work - at all - behind an NLB with a Target Group pointing to it as an "instance". You have to put it in "IP" mode.

3. OpsWorks, as always, lags way behind AWS offerings. You can't launch C5 instances. This was true of even R4 instances for a while, but you could at least change them via API. Not so with the C5 instances; unless you want to lose track of their type completely, you just have to abstain for now.

3a. As a result, we have to run R4 instances for some of our web tier - despite not needing the memory - because they have the highest network allocation. To make matters worse, AWS won't tell you the network allocation. You don't know until you start dropping packets.

4. ZFS on C5 instances can behave strangely. We've been unable to resize drives (zpool online -e <pool> <drive>) if they're identified by ID ("unable to read disk capacity"). Moving the instance back to any other type fixes the issue.

As always, you expect a couple of quirks with a new architecture, but I found myself wishing they had just stuck a new board with a Skylake chip into a rack and launched it.

Compared to this, GCE has a far more attractive offering: even ignoring all these issues, we simply can't get the instance size we want (a few fast CPUs + lots of memory). It just doesn't exist.

Bare `await` (REPL-only) came in Chrome 62 - and it's on the way to Node soon. https://github.com/nodejs/node/pull/15566

Not a lot of notable changes in here, but it's nice to see the v9 branch moving quickly. The sheer velocity of NodeJS - even now after all the ES6 features & async/await are finally available without flags - is something to behold.

Looking forward to v10 once the churn has settled.

Waiting for them as well. Most of all, we really need fast-CPU instances with the ENA, not the Intel NIC.

I've used Loopback for a while as well. IMO, TS is a welcome change, I'd be happy to write APIs in it and I'd prefer it to untyped libraries.

It's hard to understate how nice it is to have your editor autocomplete functions, argument order, object shape, etc. It's a real productivity booster, gets you sanity checking out of the gate and makes the framework discoverable. This is a good decision. I can't make any cogent argument against it, aside from dependency bloat.

Couldn't you just turn off FileVault (decrypts the drive), let that finish, then turn it back on again?

Phenomenally detailed article and interesting subject matter. Thanks for sharing. Of particular concern to the community should be the issuance and solvency of Tether. An audit is long overdue.

As mentioned, our CEO, Arthur Hayes, wrote on Chinese exchanges running their customers' deposits in local bonds & stocks back in 2015 [1]. It's worth a read. We at BitMEX have brought a full-time writer into our employ just to bring more of these stories to the fore and help create the facts-first, inquisitive atmosphere crypto desperately needs. [2]

1. https://blog.bitmex.com/crypto-trader-digest-nov-30/#shadow-...

2. https://research.bitmex.com

At BitMEX we do 100% offline multi-sig. Unfortunately, that also means any form of live proof-of-reserves is quite difficult to do, as the keys are offline.

Early in our history, we thought once-a-day withdrawal would be a problem customers would be quite vocal about. Instead, we found many of them appreciate what it means - that the keys aren't hooked up to a hackable webserver, but are actually protected. Accessing funds should be difficult and should require human interaction.

It depends. It could be very useful for React/React Native, for one.

Event loops are great for handling work that can be handed off occasionally to worker threads (like how Node works with libuv), but are awful when doing consistent CPU-bound work, such as with games, 2D/3D visualizations, finance, and the like.

SharedArrayBuffer is a nice primitive that allows multiple Threads (or WebWorkers) to work on data in parallel. The additional primitives they're proposing offer quite a bit of flexibility. For one, I would really like an easy `new Thread(fn).asyncJoin()` to create a Promise to do expensive CPU-bound work. There are a few npm modules that do some version of this but it can be slow.

As for the concurrency model, it should be possible to delegate tasks to a pool in this one. Map an array of input data and functions to an array of promises, then Promise.all() or Promise.race() on them.

Yes, you're correct, it's not a changelog - rather, it is the changes.

Click "Files changed" for an actual diff. I am not sure what makes it v2.0.0, however.

See https://github.com/mojombo/semver/compare/v1.0.0...v2.0.0 for the changelog.

Edit: Changes, that is, not a changelog.

We only set really obvious filters, as to filter too little than too much. But of course, it's not perfect every time.

We do it anyway. It's easy enough to filter those types of emails. I think it's a huge plus for customer service to be able to say "Have a problem or question? Just reply..."

There was a native NodeJS module called "toobusy" that I rewrote a few years back to remove the native dependencies:

https://www.npmjs.com/package/toobusy-js

It's worth checking out - and helps you achieve this goal without necessarily having to come up with a req/s magicnum; instead you measure actual event loop latency to detect a slowdown.

> The hacks at Defcon all took a long time to do

90 minutes or less, from unprepared attendees, some of which didn't even know they would be seeing a voting machine that day [1].

> Also voting machines generally have paper copies that print off the back of the machine

This wasn't always the case, and a few bad elections happens from 2004-2006 as a result. There is also not a guarantee the voter has checked/understood the paper receipt. Overall the concept helps quite a bit.

> The only plausible hack would be an inside job

Polling station staffers are volunteers, and there are lots of them. Not particularly difficult.

Voting machines themselves are known to store results in unencrypted, easily editable MS Access databases. This allows editing/suppression of votes en masse with no trail. If said attacker can find a way to also tamper with the paper receipts (print a different result that the voter doesn't notice, or don't print at all, or make the printout unreadable), mass shenanigans could ensue.

All this just to say, "hey, it uses paper for verification on the backend, so it's fine." But we're paying companies to develop insecure machines, training voters to trust them, and bringing the integrity of our democracy into question along the way.

Just fill out a piece of paper. It's not that hard to count the votes.

1. http://fortune.com/2017/07/31/defcon-hackers-us-voting-machi...

To be clear to those reading, that's 2% to 3%, not two-thirds percent.

And yet - it can be used as one. "If you actually tried using it" is a wholly inappropriate thing to say to someone you don't know. We used it in a large application indexing & faceting millions of documents, and it works just fine for the practical purpose of querying & retrieving those documents. Of course, we did mate it with Postgres to build the full app. Each tool to its strength.

There's no need for the vitriol.

That's a matter of opinion and implementation. Not everyone uses JWTs. What if you want to invalidate all logged-in tokens for a user? You either need to store a blacklist (that's a relation) or set extremely short expiry times.

Yes, this was an incredible development, and lead to hilarious projects like ToroDB (MongoDB API on top of Postgres), which ended up being faster and safer, with relations when you need them.

JSON columns can be incredibly useful and easy to understand for things like user preferences, without the hassle of a metatable.

> I think document stores are a great thing; the only problem is that MongoDB isn't a good document store.

To add to that - you know when you need one. If you don't know you need a document store, you don't need it.

When you try a good document store, like Solr, you realize how appallingly limited Mongo really is. It's not suited for any practical use outside of demo apps.

The hype is the real issue. Even today, the CTO appears to claim that 90% of apps aren't relational enough to need Mongo.

I did a startup in 2011/2012 where we bought into the hype and used MongoDB & Node + Mongoose. It was horrific.

Your app is relational, full stop. You would know if it wasn't. Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Do those users need to create anything at all? You've now related those owned objects back to the user. We're talking the very basics of any application, and Mongo's support for it is basically nil.

We went down the road of embedding relations inside the model (e.g. an "user" has multiple "tickets" to "events"), and then we'd just filter through the "events" table to find the related one. But what if the admin running the event wants a list of all the tickets for his event? We're talking webapp 101 stuff, but we had to write some really gnarly application logic and duplicate a bunch of data to make it fast.

It was a complete waste of time.

At the crux of this is a fallacy that easier is always better. It's not. There is a reason SQL databases are a little complicated to use - they have evolved over many decades to fit the needs of real applications. MongoDB is only barely removed from writing raw JSON arrays to disk, which is probably the simplest "database" imaginable.

When you so callously discard the common wisdom on how to store data, you rediscover why it exists, the slow, hard way.

10gen made a business - and a fortune - out of misleading new developers.

This is hilarious!

We ran across @kornelski yesterday asking about some old babel code (1.) and were wondering what the angle is. Kornel's an accomplished coder: he did pngquant and imageoptim.

The author himself calls it the "stupidest project I've ever done". But it's probably a nice way to get 90% of the way there when converting PHP fns (such as validation et al) into the browser. Also, and perhaps most importantly, it's a great exercise in writing Babel plugins.

I really enjoyed this. Thanks for writing it, @kornelski.

1. https://twitter.com/kornelski/status/884485913627295744

That does seem like a nice stack. Do you have an idea of the actual pricing past 10 nodes? I can't seem to find it anywhere.

This is very important, because it removes some of the most prevalent criticisms about Freenet. If you don't agree with some content (re: legality or any reason you wish), don't access it/share it. Freenet doesn't give you that choice, but IPFS does.