ayende

Here are good examples of the problem:

https://www.reddit.com/r/archlinux/comments/pjcnh0/power_out...

https://unix.stackexchange.com/questions/453074/power-loss-w...

https://bbs.archlinux.org/viewtopic.php?id=106441

To give context, what happens if you lose power midway through?

One of the things Windows will do is first lay out the work to revert all changes in that happens (across potentially thousands of files). It also need to flush them to disk (very slow, even on SSD) and then perform in a manner that would survive all sorts of failures.

That is pretty expensive.

Just for refence. C and non flat memory model used to be REALLY common. It was called MS-DOS, and Win16 https://stackoverflow.com/questions/8727122/explain-the-diff...

Except that then you have a list of common phrases that you can check.

How many passpharses would be: "in god we trust" or "I love you". Figure out song titles and book titles, and you have a great list to check.

See also: https://jbonneau.com/doc/BS12-USEC-passphrase_linguistics.pd...

That was interesting to read. RavenDB does something similar, if there isn't an index for the query, it will create one for you. The difference is that this is a persistent structure, which is reused across multiple queries and invocations.

That assumes that the application even know to check the "only valid if issued before" flag.

There is no API to actually handle trust. If you are asking `curl` or `openssl` to verify the chain, it needs to read it from somewhere. By convention, there is `OPENSSLDIR`, for example.

But that just tells us where the root certs are, not much more. In the API, I load the root CAs and check validity of the cert, nothing beyond that.

And I can do that in multiple different TLS engines.

Given that there is no API for this, all the TLS engines need to re-implement this logic. Hell, in most cases, even things like validity range checks are handled by the applicative logic.

On Windows, there is the builtin TLS API `schannel` which means that you have a lot more structure / order in this. Including the ability to express those sort of details.

There is another aspect, as well. You need to be able to express those issues as errors, otherwise the user is going to be left with a broken box and no idea what is going on.

This is a horrible implementation. To start with, this queue isn't concurrent. It has a lock (and make it easy to leak / stall) with it.

Second, it has a `O(N)` performance on inserts.

This is beyond unexpected for something that is supposed to be a queue.

You actually are doing dynamic memory allocations, you are just not allocating from the operating system.

A quick look shows how this is done: https://github.com/tigerbeetledb/tigerbeetle/blob/91a105875c...

You can see things like alloc / free, memory ownership, and everything that is associated with it.

The fact that you allocate from a startup buffer vs. a call to `mmap`/`brk` doesn't really change things.

RavenDB can do that

In Israel, for example, a lot of land is not "sold", but leased by the state to people. In practical terms, there is no real difference.

Technically speaking, the lease terms are 49 / 98 years. The problem is that when you reach the end of the lease, there is no real possibility of _not_ extending the lease. And the lease is for the _land_, not anything on top of that.

So it "sounds" nice, but in practical terms, it just adds another body that you have to go through.

From economic perspective, there is very little difference between the two. A bank will give you a mortgage to buy a house whose "land lease" expire next year, for example. Because there is no possibility of that not being extended.

There is _slight_ advantage to buying houses not leased, but mostly because that means somewhat less paperwork to go through.

What would this "penalize" US court look like?

And what do you think the US reaction to something like that would be?

I think that this is going to further the reputation damage for trusting Google with anything.

The fact that this was handled on such short notice is a huge problem, but who is going to want to invest in another Google technology with such a risk?

See also, trusting Microsoft with a new UI technology and how their reputation in this area is really bad.

You are off by a couple of orders of magnitude

I have run 500+ req/sec on a raspberry pi using 4 TB dataset with 2 GB of RAM, with under 100ms for the 99.99 percentile

A few hundreds req a second is basically nothing.

You don't

They mean fraud against them.

Assume you rent a GPU to do PoW mining, using a stolen credit card, they can't charge you, but you have your coins and can disappear

The impact of IO_Uring on the overall design is really interesting

Because it push you toward everything as async by default

I can easily imagine node.js implemented on top of that, for example

The move to async in modern languages also supports that very well

Note that this has major impact globally, not just for the IO portions of the system

In a way, this is function coloring all over again

There are also additional issues with this arrangements.

For example, social security payments. Pension plans, etc.

A simple example, Israel has mandatory pension plan requirement for all employees. If you are working remotely in Israel "as if in the US", you are now opened to a whole bunch of interesting questions. Employer isn't aware of that, in this scenario, so isn't paying the pension.

That creates:

* criminal liability for the company * criminal liability for the management team personally * the company is assumed to be "self-insured" and basically has to act as the pension provider for the employee.

You fall down and become invalid at the age of 27? The pension insurance will pay for that. Which is basically the company. Then you have to pay 60+ years of pension payments to that employee.

And that is _one_ aspect of this issue.

Others are related to laws. What is the minimum wage? How do you compute the allowable number of hours and overtime pay?

For fun, let's say that you are working for a few years in this mode. The employee then sues the company for overtime pay (200%) because that is the law where they are working.

Firing someone, also, is a totally different process across jurisdictions. In Israel, you have to pay a month's salary for every year that the employee worked for you (based on the last 3 - 6 months).

You have to fire a senior guy that worked for you for 6 years? Prepare to pay immediately a big chunk of money. Also, have fun with _another_ criminal liability (for the company & leadership) because you didn't pay insurance for this scenario.

The company in this question is going to be absolutely against this sort of exposure.

For that matter, it isn't even legal only that is going to object. If you are a public company, you need to put things like "liabilities in case we have to fire people" in the balance sheet. The CPA is going to have a field day with all those undisclosed issues.

Really hot, ACID rain. Not really

That amount of money is not even a rounding error.

And it is likely to be very obvious and public.

You will crash the market, so can't really do that multiple times.

And if you can Crack this there are better targets

The desire here is to avoid rebuilding a node if there is a single error in the disk no?

Because otherwise, it would make sense to just bounce the node entirely and let it build itself from the replicas.

As a database guy, the number of edge cases inherent in this model is pretty scary. I can think of several scenarios where this is really bad for your system:

* persistent data going back in time (lost the SSD, so you reload from network) * inconsistent view of the data - you wrote two pages in a related transaction. One of them is corrupted, you recover older version from the network.

That is likely to violate a lot of internal assumptions.

And to put that in context, 2.0 was around 2003, iirc

The idea is that you make holding a lot of cash much harder to work with on day to day life. That means the incentives for that are far lower.

It also complicate illegal activities in general.

The idea isn't that your typical criminal will say: "I'm okay with dealing drugs, but the law about 6K NIS is where I draw the line".

The idea is that once they get the money in cash, they have a problem actually using that. So they have to go into addition hurdles.

Basically, it makes illegal activities more expensive.

At which point you are probably guilty of "structuring". Which is a crime all on its own.

Also, that only holds up until someone actually looks at you.

RavenDB has this feature

https://ravendb.net/learn/inside-ravendb-book/reader/4.0/9-q...

RavenDB has this feature, but it will also go ahead and create the relevant indexes needed on the fly.

It is able to do so without harming production performance.

See: https://ravendb.net/learn/inside-ravendb-book/reader/4.0/9-q...

You show add a screen shot showing this off

Right now, no idea what this is for

Spectre & Meltdown had a huge impact of the performance of cloud computing. They are certainly putting pressure on the CPUs.

See: https://www.phoronix.com/scan.php?page=article&item=3-years-...

That is a killer for performance for databases

That was DirectTV, I think. See:

https://hardware.slashdot.org/story/01/01/25/1343218/directv...