sethev

That's true. The protocol aware recovery paper [1] talked about the challenges of disentangling corruption in the middle of the log vs uncommitted data at the end of the log. This is an issue in other log-based systems as well.

The OP made it sound like an oversight rather than an implication of assuming that the filesystem won't return corrupt data that was successfully written and fsync'ed. Sqlite is pretty upfront about the tradeoffs: https://www.sqlite.org/howtocorrupt.html#_failure_to_sync

1: https://blog.acolyer.org/2018/02/27/protocol-aware-recovery-...

The checksum in the WAL is to detect incomplete writes (due to crash or power failure). That data was never committed successfully. Throwing an error for this scenario would mean that sqlite is unable to recover from a crash.

> Note that even though the goal, and end result, is that the file is smaller, this is not a compression scheme, since it only works when your values are distributed in one particular way

This statement doesn't sound right. I think he's trying to say it's not a general purpose compression scheme, but every compression scheme only works on certain patterns. In fact, most possible streams of bytes are not compressible at all. Even the general purpose approaches only work on very specific types of inputs (such as natural language) which contain a lot of redundancy.

It doesn't seem inconsistent to say "you can't put a price on a human life" and also believe that it's possible to calculate the economic impact of a human death.

For example, saying that a particular individual's life is worthless is very different from saying they have no dependents.

People's intuition is certainly off when it comes to wealth and this article exemplifies the confusion.

It argues that income is more important but ignores the connection between wealth and income, which is especially strong at the high end of the wealth spectrum. The Walton family is wealthy precisely because of the claim they have on the economic activity of Walmart. The fact that the company is publicly traded just helps us put a dollar figure on the that wealth more easily.

The oldest living person today was born the same year Thomson published The Corpuscular Theory of Matter in 1907. So a long time ago in one sense, but not so long in the scheme of things.

If 60 bytes per request is a material overhead, then your workload is unlikely to benefit from general purpose compression of any kind.

$1.5 million in 1912 is almost $50 million today, so he invested pretty heavily in electric before moving on. Without the benefit of hindsight, it's hard to imagine that going differently.

I wonder if anyone at the time had an inkling of the long-term downsides of gasoline powered engines?

Amazon wouldn't be worth less if someone else owned it and he only owns 10% of the company. So all of it.

You seem to be mixing up the file format with how it's used. An application that uses SQLite's file format would use SQLite's library as part of the application. Yes, it would be quite a lot of work to replicate that library but in the same way that replicating the code that uses OpenDocument's file format would be.

The file format itself is pretty straightforward.

There's a BFT version: https://www.scs.stanford.edu/17au-cs244b/labs/projects/clow_...

It shows the state of each replica's log. Click on the leader and select 'request' to simulate sending a command. If you take a replica offline, you can see that it falls behind and then gets caught up when it comes back.

It's a (selfish) issue for the landowner because previously they could treat this public land as if it was theirs effectively, since other people don't have access to it. This ruling doesn't change that for public land that doesn't share at least a corner with private property.

Oh, wow! This is the creator of Glypha (https://boredzo.org/glypha/). I spent countless hours playing that game in the mid-ish 90's. Like so many games back then, you could tweak things with ResEdit. Nobody would believe my high score because they knew i could modify it.

Everyone withdrawing their money ASAP is what caused the solvency problem. There's a big difference between warning people of a problem and encouraging them to behave in a way that creates it.

No bank could survive this kind of run. See https://en.wikipedia.org/wiki/Bank_run

Normally, yes. But in this case isn't it the upcoming payroll that's the problem? That work has already been done by employees, so the wage is already on the books. If they can't come up with the money, they'll have unpaid wages no matter how many people they fire. Right?

On it's face, it seems implausible that 1 in 50 investors were as successful as Warren Buffet.

John Carmack tweeted something that made me noodle on this too:

>It is amusing to consider how much of the world you could serve something like Twitter to from a single beefy server if it really was just shuffling tweet sized buffers to network offload cards. Smart clients instead of web pages could make a very large difference. [1]

Very interesting to see the idea worked out in more detail.

[1] https://twitter.com/id_aa_carmack/status/1350672098029694998

It's hard to imagine a timeline where SQLite was more successful.

Roaring bitmaps are integer sets with optimized set-wise operations, like intersecting two sets to find out which integers are contained by both. Judy is an associate array (so it's interface is similar to a hash table). There's a specialized case for word->bit, but no set-wise operations and no way to match the performance of roaring for those.

This doesn't quite answer your question, but if Roaring fits your case you should use it instead of Judy1 even if have Judy1 available.

This is similar to the argument that you shouldn't set a service-level objective of 100% availability. It's not achievable and people who claim that's the goal don't act as if it is - so it's better to talk about what amount of downtime is acceptable given the cost.

Some of this article reads like a criticism of people's second-hand impressions of the books. Their poverty and Pa's poor decisions that made it worse are right there in the books, they're just told from the perspective of a child who loves her father and doesn't know a different life.

Whether the real-life Laura is like the one in the book is kind of interesting, I guess, but anyone who didn't pick up on how poor they were and how little success they had at farming from the books was reading them superficially.

I think the headline is misleading. If you read the article, it sounds like they've increased the salary cap. It seems like a leap to assume they're offering anyone salaries at that cap.

The CEO isn't getting paid this amount.

While you're not wrong about nails vs screws for framing - this a 6x6 box, it's not going to matter.

The use-case for a more efficient JSON parser is exactly the same as the use-case for a less efficient one. They're doing the same thing.

Daniel Lemire does a ton of performance research like this. He's an unusual case of a professor who publishes fully working source code.

There's a good chance that your database of choice uses some of his stuff or was influenced by his research.

I think you missed the point of the example. Lemire's example isn't "the use-case" for this optimization, it's just a trivial motivating example. The use-case is more like, "assume you're currently using a Bloom filter in an appropriate context, here's a way that might be more efficient".

The point of the post is the optimization technique, not trying to describe when a Bloom filter would be appropriate.

Downtown? The entire county that this is in has fewer than 4k people living there. This would be for someone who wants to get as far away from activity centers as possible while still staying in the lower 48.

I really learned this the hard way over the last year. My company has a client that requires all scan findings to have a plan for fixing them. No assessment is allowed, if the scanner reports it we have to assume it's a real vulnerability. However, you can usually just close it if the vendor says they won't fix it.

I feel like there's an opportunity for a business where you can log a ticket with them for Debian issues and they just read the security tracker page and tell you whether it will be fixed or not.

The specifics are often not useful but one thing you'll notice is that people who made it work have some kind of a schedule that they stick to. 'Flexible schedule' can be misinterpreted as 'changing all the time'. When I see people trying that, they usually end up moving on.

'Stick to some schedule' is pretty portable advice. It sounds like you and your father both did that.

Yeah, people who invested any money in Berkshire in 1964 are very rich now (if they didn't sell). People who invested in S&P in 1964 are not as rich.