lbradstreet

I'd like to stress the point in the article about how important the . is to efficient vim use. https://pragprog.com/book/dnvim2/practical-vim-second-editio... completely changed how I use vi in this respect.

It's not that I wouldn't recommend it, I would just think twice recommending it for very small ops teams for certain use cases. It's not so hard to manage, but having it be managed by Confluent is a great option.

I love Kafka and the log orientated streaming model, but I often have to think twice before recommending it to clients who would have to manage the ops themselves. Having a managed service on GCP, and Confluent's existing cloud offering on AWS really brings down the barrier to entry. There aren't really any AWS/GCP serverless equivalents (Kinesis has 7 day retention maximum, no key compaction, and less surrounding tooling such as KStreams/KSQL).

Yes, I like to think of it as as the transaction log without any of the logic. If you’re interested, I can highly recommend Martin Kleppmann’s talk “Turning the database inside out” https://www.youtube.com/watch?v=fU9hR3kiOK0

PubSub is fundamentally a different abstraction than Kafka which is log orientated. With Kafka you can maintain the ability to replay your log/stream, in order, at any time.

This enables different kinds of use cases, and can be easier to reason about.

Our approach archives topics to cheap, highly durable and available object stores, while keeping the data available for blending between warehoused and live data sets.

This reduces operational complexity significantly vs scaling nodes up, dealing with rebalancing, under replicated partitions, etc.

We will be launching support for native excision and data anonymization soon, as these are extremely important to storing streaming data for the long term.

Workarounds for excision in Kafka, such as key compaction, are often not possible to use as they depend on the key scheme used.

As a side note, we provide tooling to maintain Amazon Athena/Hive,Presto support over your Pyrostore archived data in S3, while maintaining its ability to be streamed in-order.

Pyrostore co-founder here. When practitioners archive their data from Kafka to other storage products (S3, SQL database, etc) today, they are giving up on the log ordered structure of the data their ability to consume their data in its original ordering, with its original offsets and timestamps. Pyrostore structures and indexes your data in S3 in order to provide a consumer that implements the Kafka consumer interfaces, ensuring you are always able to stream from hot and cold storage alike.

On the face of it, the lender has no more incentive, but having an unforgeable trail of ownership and payment may improve the value of the loan as it passes from hand to hand.

That all said, a blockchain is not really required. Better standards and a trusted third party would do fine.

You still need to be able to transfer the loan from party to party, and allow parties to prove ownership of the loan. That's not a complex contract obviously, but it's important.

I'm not a huge proponent on smart contracts, and I agree that it's a big problem enforcing payback, but that's no worse than regular loans. At least the ownership/transfership and payback of loans could be tracked, which is a far cry from the current method of debt ownership. It's extremely common for spreadsheets full of loans to be passed from owner to owner with no real ownership trail, accounting, etc, which I find disgusting.

Often fighting these loans is as simple as asking the owner to show proof of the loans in court, at which point they often evaporate, however it can be a long winding road to get there and often people just don't show up in court, or don't know, and get judgements against them that they might not otherwise owe. If the debt status was easily verifiable, it would be better for all sides (other than the bad actors) when it ends up in court.

If that's true, third party middlemen with quantum devices could work around this until it becomes more mainstream. At least it would allow it to not wither on the vine until everything is restructured. It's not really obvious what would happen in any case, but humanity has a way of papering over things.

You can trade odd lots pretty cheaply these days.

I wholeheartedly approve of the new licensing. The previous licensing was incredibly restrictive for microservices and for scaling out reads in an elastic way. The new model is much easier to understand and use in the ways that datomic was intended to be used.

Especially this financial magic "The deal also promises to help CenturyLink by giving it access to about $10 billion in tax credits that Level 3 is carrying on its books"

A fantastic library. We switched Onyx Platform www.onyxplatform.org over to it from Netty, and it was a lot easier to write than the netty messaging layer that we had, which required a lot of tuning and thought to get right.

I learned a lot by reading the code, and it generally forces you to use good patterns that changed how I thought how to build a messaging layer.

It's striking how many of these issues cause panics because of assertions that were already in the code. Without good assertion use, I would assume that many of these would have been much worse.

Even the top of the line Mac Pro is not good enough. I've used it with the DK2 in Windows, and judder was still a huge problem.

The repo was updated 13 days ago.

Interesting. That's a bit counter intuitive - thanks for the counter argument.

One theory is that electric cars look distinctively ugly because their owners want them to stand out as an eco friendly car. The Prius tail is an example of this.

I think that it limits how mass market you can go, however it seemed to work for the Prius.

It was a lot of fun testing Onyx using Jepsen, though it did take some time to get things right. If anyone has questions about testing a distributed system in this way I'd be happy to answer them.

Just a side note. After some benchmarking, I recently discovered that c3.2xlarge does not actually have 8 cores, rather it had 4 real cores = 8 hyper threaded cores. I was very surprised by this and suspect most other AWS users would also be surprised. This is not to say that AWS is a bad deal, but I think Amazon could be a little more transparent about it.

See http://www.pythian.com/blog/virtual-cpus-with-amazon-web-ser... for more details.

I'm one of the lead developers of Onyx, if anyone has any questions they'd like answered.

Most of the drugs he was gouging for were already out of patent, but they were low volume and it takes a while to bring a generic to market. During this time, he makes a lot of money.

This is more of a market failure.

You're right, it's still an amazing deal. I'm just pointing out that it likely can't be produced and sold at retail for a profit for $10.

The article was updated with the correct results before you saw it.

Apple times the new iOS release to coincide with their next iPhone release (usually slightly prior). Therefore many users upgrade to the latest iOS at pretty much precisely the time of the new release.

It doesn't mean that they deliberately slow down iPhones. New software is usually more bloated. Apple often does improve performance in the minor releases that follow, however.

Leaving aside the fact that Android users barely get updates, they don't usually coincide with new releases. I'd like to see how slowness questions coincide with Android software updates for corresponding phones.

How can the 99th percentile latency be lower than the 90th? That must be a mistake or the result of multiple test runs?