Essentially all modern high speed hardware is batched and asynchronous. The way to get high speed performance is to batch and asynchronously submit operations then wait for batchs of asynchronous completion. In addition to being more efficient to process, batching also enables "smart" hardware to more efficiently schedule the operations if needed since it has more context.

Batching many of the reads you want upfront reduces the need for as much speculative read buffering because you are more capable of telling it "all/most" of the information you actually want instead of it having to guess that you are going to do linear reads. The reads being asynchronous, which is what the hardware does, allows you to issue speculative reads explicitly. If you intend to read a 1 GB file then the userspace I/O library can fire off 1,000 1MB reads and then you can wait until the "next" desired portion of the data comes back before continuing your processing. This is in contrast to issuing a 1 GB synchronous read followed by your processing which delays your processing by the time of the entire read even though the hardware I/O can happen in parallel.

Essentially, the only remaining case where you then want meaningful speculative read buffering (beyond the default efficient block size of the hardware) is that you either do not understand your access patterns enough to batch them, or you have a data-dependent load pattern which happens to regularly resolve to something within the speculative read buffer. For instance, you read 8-bytes which tells you the offset into the file where the desired record is and that record happens to be nearby almost all of the time.

For writes, what you want is a data-or-time flush strategy which is actually just the flush strategy you should use in basically all cases where you do buffering. Data-based flushing exists to achieve efficient batching. Issuing large amounts of small operations kills you with overhead, so you buffer the operations to attempt to coalesce them into larger operations where the overhead is amortized away. However, if inadequate data is generated to reach the data-based flush condition, then you get large or potentially unbounded latency. You resolve this by also targeting a worst-case acceptable latency in low throughput conditions. In that case your overhead has been "amortized" away as a percentage of your processing time since the processing time was long enough to reach the time-based flush condition. What you are effectively doing is allocating N% of your time to completion to overhead which either fires if you generate enough data to amortize it away or if you generate enough time to amortize it away.

Writes being asynchronous also allows you to resolve the data loss issue (if the hardware cooperates). You fire it off and wait for the hardware to signal persistence of that write. Until you see a asynchronous completion for that asynchronous write, you can not assume it is persisted. You achieve ordering by issuing a write barrier which tells the hardware to signal completion of the write barrier when all writes earlier in the asynchronous queue have signaled completion. This can also be further extended to other layers if desired to allow the detection of various levels of "persistence".

Unfortunately, Linux and other Unix derived systems use the awesomely terrible fsync() model which is antithetical to efficient I/O. Instead of you issuing a write barrier and then getting notified when it completes, allowing you to continue to asynchronously issue subsequent writes, you synchronously wait for all earlier I/O to complete. This serializes execution as you wait ensuring that any attempt at ordering or persisting data is monstrously expensive. In fact, this is so horrible that hardware manufacturers realized they could massively improve their throughput benchmarks by lying about when data is persisted so the fsync() would complete faster ensuring that their throughput benchmarks would not get shot due to data persistence latency which is a different property. With a asynchronous model you can just rapid-fire the operations and the write barriers (which is the way the hardware is designed to operate) allowing you to evaluate both read/write throughput and data persistence latency without confounding them. This is both dramatically more useful and more efficient.

Every target is worth attacking, but there are not enough bears to eat everybody. Sure, the bears are breeding, but exponential growth does not look threatening until it suddenly is.

My bridge that collapses is adequate and acceptable because other people make even worse bridges that collapse even easier? No, the bridge still collapses, everybody gets a F.

Let us look on the front page and see if there are any, oh look here is one: https://www.binarysecurity.no/posts/2026/10/one-root-case

It is a mechanism that is far more practical and likely to succeed at broad reform than their plan of convincing magazine editors and instagram models.

All it would need to do is not highlight “improved spellings” as incorrect in “English 20xx” mode at the start. Then it could slowly turn the knob as they see increasing usage.

If you want to do even more then you can implement speech-to-text and transcript generators that default to “English 20xx”.

The output program does what the input source code does. The abstraction is a precise translation and non-leaky, it just admits multiple possible internals. That does not make the translation any less precise.

All observable and defined side effects should be identical otherwise you have a compiler bug. Optimizations that are not generically semantics preserving may be used, but should only be used where the program is semantically identical for your use case otherwise you have incorrectly used the options available in your compiler.

Thankfully, legal systems are not that inhumanly stupid.

[1] https://en.wikipedia.org/wiki/Negligence

I am pointing out how that is a absurd moral argument deriving from the rule of thumb. If anything, the corollary is the literal opposite.

Any stupidity indistinguishable from malice should be treated the same.

The usage as a epistemological rule of thumb just points out how great harm is usually caused by stupidity, intentional or otherwise, rather than intentional desire to cause the specific harm. If you aim to reduce great harms targeting just malice is not merely inadequate, it is likely missing the overwhelming majority.

If harms are excused because they were not made with evil intentions then the Nazis who just liked making the numbers go up in a orderly fashion should be considered blameless.

> Every Tesla ever made has a door release that doesn't require any electricity.

Was a valid response to the comment you replied to:

> Like the people who get trapped in case of accident when the electricity fail and is burned inside?

Implying others are making untrue statements by making intentionally deceptive statements is very rude.

As for the ad provider, it is trivial to not deliver criminal payloads if your business starts from the assumption that doing so is costly instead of something you can foist on society for your own benefit.

Why would they feel the need to handle garden variety illegal behavior like school speed limits?

The only advantage is that cloud services provide VM tenants so you are already stuck with a VM substrate and you want to minimize layers from that point on.

However, as a practical matter, the design of the Linux kernel is grossly insecure and basically impossible to make even remotely safe as evidenced by the unending sprawl of LPEs. Hypervisors are generally designed and configured in a way that is only mostly insecure instead of grossly insecure; a bad is better than terrible situation.

However, there is nothing stopping you from designing a kernel in a similar way and providing shared tenant processes with similar guarantees. You just need to port your applications to the new operating system, but you would also need to port them to a unikernel anyways if you wanted to go that route.

The only free action is lumping your applications with the full OS and dumping it onto a hypervisor. Anything else has porting work which is why the multi-tenant VM model is advantageous at all in the first place.

I was explaining why undefined behavior as a concept is a very sensible idea. Whether the expansive interpretation of the optimizations you are allowed to do when encountering the “impossible” are reasonable is a different question.