cakoose

Huh? The example is for PostgreSQL's "serializable" isolation level, and that's what I'm confused about.

Serializability should ensure that the outcome is equivalent to some serial execution. What serial execution of those five transactions yields [1], [1, 10], [1, 1, 10]?

But also, I just read that prior to PostgreSQL 9.1 (released in 2011), the "serializable" isolation level was actually just snapshot isolation (now called "repeatable read"). So maybe that's what benmmurphy is referring to?

Even without external consistency, a I'm having trouble coming up with an ordering of the transactions that yields [1], [1, 10], [1, 1, 10].

Is that because PostgreSQL's "SERIALIZABLE" doesn't follow the "some serial order" definition? Or maybe I'm missing something else?

> monolithic databases like CockroachDB (SQL) or FaunaDB (NoSQL) trade off extensibility

The CockroachDB documentation says their SQL implementation is layered on top of their K/V interface: https://www.cockroachlabs.com/docs/stable/architecture/overv...

This would make it similar to TiDB/TiKV and FoundationDB.

Here's and old article from VoltDB insisting that layering SQL on pure K/V forfeits too much performance: https://www.voltdb.com/blog/2015/04/01/foundationdbs-lesson-...

Edit: And a response: https://news.ycombinator.com/item?id=15505194

Does Cassandra hash the primary key to get a more even distribution?

If you have a sorted data store, you can get the same distribution by keying off a hash of the "real" primary key, right?

> The way TypeScript was designed is in fact more promising than older systems like Java. Those systems inadvertently broke type soundness instead of making it a deliberate action.

Not sure what the article is referring to here...

Java soundness issues like array covariance, final field mutability, unchecked generics casts, etc were definitely surprises to many users, but the Java language designers were well aware. They added runtime checking to make sure those soundness holes didn't cause the JVM to crash or violate the security guarantees.

Sure, there were some additional surprises, but I'm sure TypeScript has had many more. (Partly because the TypeScript type system is more complicated, but also because it's not important to get it 100% right -- JavaScript runtimes don't perform optimizations that rely on the soundness of TypeScript.)

The memory safety checking (or more generally, the type checking) isn't what makes the compiler slow. That part is pretty fast because it's intentionally modular.

It's the cross-module optimizations that make the compiler slow. Those optimizations are in service of C++-inspired ideal of being able to use layers of abstraction to make your code cleaner, but having the compiler flatten them down so your program still runs fast.

> PS: If a web page wants to crash, it easily do so by allocating memory in a loop, so making web pages that crash isn't as exciting as it is in Core Text in general.

To allocate memory in a loop, you need some control over the JS. Websites try hard not to serve untrusted JS.

But websites serve untrusted text without a second thought. For example, I could post a comment on a news article and cause the article to be unviewable by anyone with a vulnerable browser.

JSON is not "fully typed". It just happens to have different syntax for strings, numbers, and booleans. But the application code still needs to come up with a way to distinguish between timestamps, enums, different object types, etc.

XML uses the same syntax for strings, integers, and booleans, but it has mature schema/typing tools that make it easy to apply more precise typing, which you'd want to do anyway to identify timestamps, enums, and different object types.

In short, there are multiple ways to represent the same character in Unicode: https://stackoverflow.com/questions/16173328

@ademarre's RFC link looks like a good place to look for guidance.

This is surprisingly lower quality than what you'd expect from Google.

> Your service should instead store a cryptographically strong hash of the password that cannot be reversed — created with, for example, PBKDF2, SHA3, Scrypt, or Bcrypt.

Not distinguishing between plain cryptographic hashing and password hashing is a newbie mistake.

> With that in mind, you should allow your users to use literally any characters they wish in their password.

You can't just say this without making sure people understand Unicode normalization, or they're going to get bitten later.

I realize this post is from GCP evangelism, but it's still the "Google" brand, which has a good reputation for security so a lot of people are going to trust it. I wonder if an internal product security person even reviewed it.

In the "Compression Speed vs Ratio" graph, the Y-axis doesn't start at zero. If it were changed to start at zero, it would be easier to evaluate the magnitude of the compression ratio change at a glance. IMO, that's probably worth the extra whitespace in the graph.

None of those are recent innovations in programming language design. Higher-order functions, in particular, have been part of mainstream programming for so long.

"many recent innovations in programming language design, such as higher-order functions, non-strict semantics, algebraic data types, object oriented programming and sophisticated type inference engine"

These lies are unnecessary.

Where do they say it's not transactional?

LLVM started out as a research project at the University of Illinois, but Apple hired the lead developer in 2005 and put a ton of work into making it good enough to replace GCC. Apple also originally wrote Clang, LLVM's C/C++/Objective-C frontend, though Rust doesn't directly rely on this part.

Calling it "Apple's" threw me off too, but it's not entirely misleading because without Apple, it might not have become a production-ready compiler. At the least, I would say Apple did more than "just use it".

The Fortress programming language was a research project at Sun that incorporated mathematical notation.

See page 24 of http://www.oracle.com/technetwork/systems/ts-5206-159453.pdf

They also had an ASCII-only representation for everything, so you could use a regular text editor if you wanted, kind of like Markdown.

> This is possible exactly because Java is statically-typed.

Are you saying that Python can't make "a"+1 become "a1" because it lacks static typing? That's not true. If they wanted to, they could have added an overload for the string+integer case.

> Java might be able to yield the same kind of result as Python if it had operator overloading.

Not necessary. They would have just had to omit the built-in overload for string+integer (and perhaps also for string+object, given the newish auto-boxing feature).

Yeah, my initial reaction was "I can see how these design decisions might make sense, but the blog post is horrible."

These kinds of designs typically emerge over a long and windy history and, for someone who was part of that process, it's difficult to coherently describe the final state to an outsider. Good textbook authors have this skill. Most tech blog authors do not. (I think that part of the problem is that people don't respect just how difficult it actually is.)

My guess: restarting a large fleet of processes is a pain. The rollout will typically be throttled to avoid connection churn, among other things. For risky code changes, you probably want a slow rollout anyway, but if you're just tweaking abuse detection rules (almost just a config change), it's nice to have your changes take effect more quickly. Dynamic loading seems like one reasonable way to achieve that goal.

Tangent: people, please stop making analogies to mechanical engineering feats that are WAY more difficult than what you did [1]. People have been loading shared libraries forever; it's like adding an AUX port, not swapping out the engine. It's not even in the same league as Ksplice or as the JVM's dynamic loading/deoptimization.

[1] http://jensimmons.com/post/jan-4-2017/replacing-jet-engine-w...

I think "server-side projects" is maybe too broad a term. Yes, there are plenty of server-side software where concurrency pervades the codebase. But if you're making a web app, for example, it's common for all of the code you actually write (the "business logic") to be single-threaded.

Things like the core request loop and the DB connection pool will need to handle concurrency, but a few people will have figured out how to get that stuff working and you can just use their libraries.

EM radiation and power draw patterns from your device can leak information about what the device is doing. The NSA takes this stuff seriously: https://en.wikipedia.org/wiki/Tempest_(codename)

There are situations where an attacker doesn't have full physical access to a device but can still observe EM radiation. For example, someone sitting next to you with an EM receiver, observing emissions from your 2FA token.

Yes, there are diminishing returns. But people who are frustrated with Go's type system aren't just blindly pushing for more precise types. They have experience with generics and have decided that the cost/benefit is worth it.

Also, the optional static type systems for languages like Python and Javascript are more precise than Go's. So when you actually decide to apply types to your code, you get more checking than you could ever get in Go.

The article describes solutions that use Redis so that multiple app servers can share rate limits. The article's second solution is basically what you're describing, except adapted to work with Redis.

Also, what do you mean by "fixed" memory? Sure, the memory doesn't grow over time, but neither does the memory of the other solutions. Of the solutions listed in the article, this is the most memory-hungry.

What? These are different things.

This article is about the server deciding which requests to reject. Exponential backoff is a strategy clients use deciding when to retry after their request is rejected. (Plus, the article is about malicious clients; they're not going to follow your preferred backoff strategy.)

More concretely, how would exponential backoff ensure that you don't allow more than 10 requests/second per user?

What do you mean when you say Avro doesn't let you "cleanly update or track schema"?

From what I've read about Avro 1. It can transform data between two compatible schemas. 2. It can serialize/load schemas off the wire, so you can send the schema in the header.

If schema serialization causes too much overhead, you can set things up so you only send the schema version identifier, as long as the receiver can use that to get access to the full schema.

Yeah, in this case, Hypothesis uses programmer-provided input specs, which are similar but not quite the same as type declarations in a typed programming language.

I'd still consider this to be essentially "static" information, since they don't change as the program executes.

There's another distinction besides the "level" at which they operate. They use different techniques to generate test inputs.

QuickCheck-style tools typically generate inputs based on high-level static information, like types or programmer-provided specs. To reach the sophistication of modern fuzzers, you need to be smarter.

For one, you should inspect the code of the function. If you know how the code branches, you can more efficiently generate inputs that exercise both sizes of the branch.

But since you can't always figure out how to exercise both sizes of a branch just based on static analysis, fuzzers also observe the dynamic execution behavior of the program. This allows them to randomly adjust inputs until they know both sides of a branch have been hit.

I imagine that lifting fuzzing techniques to a higher level could have efficiency benefits. Maybe someone builds a fuzzer that runs on Rust MIR? Or maybe Rust can dumps out additional metadata (alongside the LLVM bitcode) to help the fuzzer figure things out?

Like I said, I don't think it's unreasonable to trust Apple or the Tahoe LAFS download server. I think they're improving the state of security and I would use those products. I just want people to be clear about the actual security properties of the whole system.

For example, people should know that blanket statements like "Apple cannot read your messages" are false. And your client/server protocol can be state of the art, but you still rely on the much-maligned HTTPS certificate infrastructure (among other things) to get the client bits.

Like OP said, having that design is valuable, but you're still running someone's software on your computer.

With Tahoe LAFS, you're either downloading the pre-built binary or compiling from source. Either way, you're trusting the person who signed the binary/source or the person who hosts them.

This is similar to when Apple says they can't read your messages. Sure, they may not able to decrypt the data on their server, but they're in total control of the client software. They can get access to your messages.

I do think it's in Tahoe/Apple/etc's interest to NOT be able to see their data. For one, they said they can't and reputations are important. It may also be beneficial when dealing with law enforcement requests. So trusting them isn't totally unwarranted, but there's a lot there that isn't mathematics.

(You're never going to get to 100% math, but there are ways to get further. For example, someone might eventually write a Tahoe LAFS client that comes with a machine-checkable proof that it doesn't leak plaintext. You now need to trust the proof checker, but it's progress.)

> Is paragraph 2 of the post not upfront enough? I clearly stated our goals of the project

That paragraph says your connection to S3 is slow. Your solution doesn't fix general S3 slowness. However, it does make S3 slowness less of a problem for your application.

That's why it would have been useful to describe how your application accesses S3, so others can quickly determine if their applications would also benefit from a similar solution.

For example: "90% of our S3 reads are of blobs that were read in the last 30 days."

Many applications might upload data to S3, then quickly download it for processing. For those applications, this solution won't work.

> But I never set out to mitigate S3 failures like this.

We know. It's just that some people might read the title and think this is a more general solution than it is. OP was just warning people against that.

OP is a little abrupt, but it isn't downplaying the system's usefulness to you guys; just warning other readers that this isn't a general solution for, as the post is titled, "dodging S3 downtime". It's a "fluke" precisely because it "just happened" to help with something it wasn't designed for.

It's not uncommon for applications to have MRU access patterns and be able to keep partially functioning during partial data availability. For these applications, a cache will lower costs and mitigate S3 outages. It would have been nice for the article to give the criteria up front.