evanweaver

This was a big value point for Twitter in the early days (2008 and 2009 era). Identity is fluid.

I wonder if you could do this with an HDFury Vertex or Integral. All the hardware is there (including dealing with HDCP), but I don't think they have devkits available that would let you add features to the firmware.

I worked there at the time and ending up running the software infrastructure teams that fixed all these problems. The beer wasn't a reward, it was because people were stressed and morale was low. Nobody brought the site down on purpose.

What really made me mad was when we hired consultants and the contract would end, usually without much success because Twitter's problems were not normal problems, and then they would send us a fancy gift basket with our own wasted money.

Maciej, we are still waiting for you to ship the executive dashboard.

I just wanted to go from my house in Berkeley to Palo Alto and back without having to stop and recharge for an hour at Whole Foods.

It was an ok car if you never, ever needed to use a highway.

No number of additional premium features can compensate for an overall worse driving and ownership experience. It’s basically a new class of car. I was very skeptical but that’s the truth.

Of course, some won’t value what it can do, but the hate over minor details is not justified.

As someone who has owned both the Leaf and the Model S I agree with this. The only value of the Leaf was it was a very inexpensive but embarrassing way to get a carpool lane sticker in the Bay Area. It could not drive at highway speed for any material distance so “commuter’s golf cart” is accurate.

But now the Model S is the best sedan on the road at any price, and I’ve driven the 2019 BMWs and others. The interiors are cluttered up with incoherent “luxury” features to try to justify the price point, but nothing works that well together except for the drivetrain itself. I don’t want a crystal shifter knob and eight different buttons to lower the rear seats and a head-up display that occasionally knows the speed limit and iPads protruding from the seat backs and a lane-keeping feature that randomly jerks the wheel. This stuff makes the retracting door handles on the Tesla seem almost practical.

I do want a car that drives great and looks great and minimizes maintenance and running costs. No ICE drivetrain can deliver the same acceleration thrill as the Tesla drivetrain, so what’s the point? The only thing left is range and hauling power, so pickup trucks, vans, and for now, SUVs.

At this very moment I am sitting in a dealer-provided loaner car by a strip mall, because I have to wait for my own car to be repaired and I need to make phone calls. There is no other space nearby where I can do that for love or money, including the dealership waiting room.

I asked for the loaner vehicle for this purpose specifically. The car has AC and privacy. I get it. I wish it also had a desk.

> In reference to Kanye's password choices: "Password" and all zeros are the most secure passwords these days. Not even brute force decryption engines use them. The reasoning: no-one could be that stupid, so why waste processing power looking for them. Kanye is on the leading edge. - John McAfee

https://mobile.twitter.com/officialmcafee/status/10508093668...

So, where is it, and how was it found? The article and even the source it links are extremely vague.

I remember that article...it was the second one.

I had this same setup and it was just as awesome as you say.

Cut your losses and let your winners run.

Maybe you should start; it would be a good A/B test.

Netlify Dev also includes support for accessing FaunaDB GraphQL Cloud, launched in beta today (https://fauna.com/blog/getting-started-with-graphql-part-1-i...).

We are working on adding support for a 100% local development workflow in Netlify Dev. It would be lovely to know what you think is missing from stateful local workflows in both Zeit and Netlify.

So you are saying they should do it for the “exposure”.

The example here: https://apple.github.io/foundationdb/developer-guide.html?hi...

suggests that serializability is violated when atomic ops are mixed with regular ops on the same key.

Note that transaction pipelining in Calvin does not have this issue.

Just because Percolator was implemented to provide transactional isolation in an OLAP system doesn’t mean that the algorithm doesn’t apply to OLTP contexts.

FoundationDB and Percolator were developed independently, but the fundamental principal is the same.

See other comment re. phantoms.

It seems like it should be able to offer strict, but the official docs suggest otherwise and clearly distinguish it as different than serializable:

“FoundationDB provides the strongest possible consistency model, sequential consistency (closely related to serializability from the database literature), providing the greatest possible ease of development.”

https://apple.github.io/foundationdb/consistency.html

In other places it says “serializable” but not strict.

Also, read conflicts are not added automatically on dependent reads of conflict-free operations, violating serializability of conflict-full operations.

Finally, if you query range offsets, is the entire prior range locked with a read conflict or just the key at the offset? My understanding is the latter which allows phantoms.

There’s a lot going on here and I would appreciate any clarification you can offer.

At Twitter in the early days it was janky/jankiest. “Jankest” is also new to me.

The opposite of janky was prostyle. There was no middle ground.

We are working on new benchmarks.

This is a very good question, and to a substantial degree, this is what we did. We have internal QA systems that overlap Jepsen that catch most issues. We also ran our own Jepsen tests on the core product properties last year, fixed some issues and identified others, and reported the results on our blog.

However, correctness testing is fundamentally adversarial, like security penetration testing. Building a database is not easy, and testing a database is not easy either. It is a separate skill set, as anomalies that lingered for decades in other databases reveal. The engagement with the Jepsen team is explicitly designed to explore the entire product surface area for faults, not to apply Jepsen as it currently stands. Thus, a lot of custom work ensued on both sides to make sure that the database was both properly testable, and properly tested. The result of that work is what you see in the report.

The typical Jepsen report implicates not just implementation bugs, but the entire architecture of the system itself. Jepsen usually identifies anomalies that cannot be prevented even with a perfect implementation, which didn't happen here.

Some vendors restrict their engagement with the Jepsen team to only what they have tested themselves already, although those tests are not always valid. This was not our mindset—we wanted to improve our database by taking advantage of Kyle’s expertise, not present a superficially perfect report that failed to actually exercise the potential faults of the system.

If only this were the case! Unfortunately it is not practical to reliably maintain single-digit millisecond clock tolerances in the public cloud as an end user via NTP. The entire software/hardware/network stack has to be tightly controlled, not just the clock source itself. And atomic clocks across multiple cloud providers are not in sync with each other, either.

Thus, databases that rely on clock synchronization recommend configuring tolerance windows of 500ms and above, and cannot reliably detect if those windows have been violated. Additionally, this window affects latency for serializable local reads all the time, even if the clocks actually fine, because there is no way for the system to know.

> One thing that seems to fall by the wayside frequently is a followup.

Yeah, I agree. We worked very hard to fix all major issues during the evaluation period so that Kyle could test the fixes himself, and we are a planning a formal followup on the remaining items and some planned improvements as well, once we are ready.

FaunaDB can tolerate the loss or partition of a minority of replicas (datacenters, AZs, or racks) in a cluster, so if you want to tolerate more concurrent failures, just add more replicas.

For example, a 7 replica FaunaDB cluster can lose 3 replicas and maintain availability for reads and writes; better than Aurora in your example.

Yes, for sure. They are both distributed object stores and share inspiration from the Linda/tuplespace lineage, as well as relational and document databases in FaunaDB's case.

FaunaDB supports function execution in the database, if the functions are written in FQL. It has a much more powerful index system and consistency model than Gemstone/Gemfire/Geode and is designed for synchronous global replication.

However, unlike Geode it is not an in-memory system, so it is not appropriate to use as a cache.

Hmm, when did you try it? FaunaDB and the cloud service have changed a lot in the last few years, and performance is always improving.

Typical write latencies in Cloud are in the 100ms range because the data is globally replicated. Typical read latencies are the 1ms-10ms range, because global coordination is not required, discounting the additional latency from the client to the closest datacenter.

If you experienced something worse than that recently, maybe there is some other issue going on.

See our blog post as well: https://fauna.com/blog/consistency-without-clocks-faunadb-tr...

Well, it is a general-purpose database with a document-relational programming model. It's a good choice when correctness, high availability, and flexible data modeling matter, like the core business objects of a service or app.

Currently it supports its own native DSL similar to LINQ or an ORM, and if you want compatibility with existing query languages from other databases, we will be rolling those out over time.

It's not a good choice for analytics or time series data which is redundant or aggregated, and doesn't need the high availability or performance overhead of transactional isolation.

So excited to see this; this is the culmination of three months of very hard work by both teams.

FaunaDB 2.5 passed the core linearizability tests for multi-partition transactions immediately. To my knowledge no other distributed system has done this. Zookeeper was the strongest candidate on initial testing in the early days, but it does not offer multiple partitions at all, as discussed in the FaunaDB report. And Jepsen itself was much less comprehensive at the time.

All other issues affecting correctness were fixed in the course of the analysis, and FaunaDB 2.6 is now available with the improvements.

We're happy to answer questions along with @aphyr. Our blog post is here: https://fauna.com/blog/faunadbs-official-jepsen-results

I just bought a bunch of these; how can you tell?