Veserv
The same one it always is, the finder of fact for that legal proceeding. This is really basic stuff. It is even more absurd that you did not even have the standard finder of fact amongst your options.
> That will never work, as the courts are already overloaded and you're talking about adding hundreds of millions of additional cases to the docket per year.
That is possibly the most inane argument I have heard in a long time. Adequate judgements against now illegal behavior will strongly disincentivize behavior relative to the past where it was legal. If running afoul of the new law resulted in a 100% of yearly revenue fine do you really think everybody would be chancing those odds resulting in hundreds of millions of additional cases? Obviously not; then my point is proven. Of course what you would actually do is scale the fine until it is commensurate with the desired degree of disincentivizing or until the undesirable behavior becomes unprofitable; the unreasonably gigantic fine I used as a thought experiment above is just there to demonstrate that your point is utterly inane.
As we know, false commercial speech is already, rightfully, not protected by freedom of speech. However, the standards for such have been so thoroughly blinded for the benefit of liars to the detriment of society as to fail to detect attempts to deceive so obvious that even children can tell let alone more subtle attempts.
Instead, the standard should be strengthened. Commercial speech should need to affirmatively “prove” it is non-deceptive and safe for consumption in reasonable proportion to the resources allocated to its production. Commercial speech should become more truthful and accurate and immune to misinterpretation the more resources that are allocated to it unlike the status quo where is becomes more deceptive.
This is a standard that is trivial to achieve for anybody with interest in the truth. Dry, informational statements that err on the side of caution are obviously acceptable. If you are producing a advertisement at substantial cost then instead of using your focus group budget on making sure the targeted consumer is thoroughly deceived, you will need to use it to make sure they only believe things you would also affirm in a court of law.
I colloquially call this the “Technically, your honor…” standard. If you say that you should probably lose.
This is not to say that the standard is that nobody in the entire world comes to a false belief, just that the overwhelming majority do not.
Reasonable defenses would be:
1. The false belief is not beneficial to the marketer.
2. The false belief is so small as to be immaterial.
3. The person with the false belief is not reasonably in the target demographic. (Nuanced statements might be misinterpreted if not in target demographic)
4. The interpretation leading to the false belief is unreasonable. (People can just be unreasonable and stupid)
5. The false belief is unexpected and could not have been reasonably detected given the resources allocated. (Minor mistakes and blindspots are acceptable, you can not account for everything, but you must account for more as more effort is used).
Why did they do that over a purely informational advertisement depicting the soft drink and explaining the taste and ingredients? I would consider such a advertisement clearly acceptable.
They have to demonstrate why their advertisement showing people having fun on the beach is intentionally truthful and non-misrepresenting relative to the consumer impression following the advertisement. I am sure they have focus groups who can answer your question. Ask them.
You know how they currently spend lots of money designing and focus grouping to see if the average consumer will get the wrong idea about the product? They have to do the opposite. If they spend lots of money on the advertisement (enough that you would reasonably focus group, etc.), then you need to focus group until their impression of the product is something you would not disagree with in a court of law.
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.
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 reasonably insecure.
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 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.
if (x > 0) {…}. But what if you entered the body when x <= 0?
if (false) {…}. But what if you execute the body?
These are “impossible”. What happens when the impossible occurs is “undefined”.
When the older standards said signed integer overflow for addition is undefined what they are actually saying is that the real definition of + is:
int +(int x, int y) {
assert(in_range(actual_math_add(x, y), signed_int_min, signed_int_max));
return machine_add(x, y);
}
But, in the interest of performance, “release mode” (which in this case is just any compilation) elides asserts since as a programmer you should not write code that asserts in much the same way that you should not write assert(false) in a normal code path that is supposed to run. Assertions are intended for “impossible” code paths and usually get compiled out in “release mode” though maybe your code is buggy and can actually hit them and then your program goes off the rails because it had a bug.
Put another way, if you did write assert(false) in a regular code path, would you find it unreasonable for the compiler to just delete the code after it? That is what undefined behavior is for.
Unless every intermediate link has more bandwidth than the sum of every flow that goes through it, you have this problem. Thinking about that more, that is literally just “congestion is possible”. But if congestion is not possible, then there is no bandwidth limiting and you can just blast away at full speed at all times.
I guess I would characterize this as congestion control/bandwidth limiting where your control parameter is “in-flight data allowed”, which is what TCP also does, results in exactly that. You get intermediate buffering due to no pacing mechanism unless you are giving rapid, continuous, precise congestion control feedback. The control parameter that avoids that is available bandwidth (or estimated available if you are not omniscient) which allows the Tx to interpolate between explicit congestion control feedback. This allows reduction in rapidity of congestion control feedback while neither stalling nor over-producing. You just tradeoff responsiveness to channel parameter changes in proportion to how rapidly you provide explicit congestion control feedback.
Data flow prioritization within your available bandwidth is, however, still necessary and largely orthogonal to the above.
1. Having multiple congestion control algorithms is already standard in both QUIC and TCP. As deploying Homa requires you to control both ends or at least understand both ends, in a comparable QUIC deployment you would know they are in a datacenter and can just link the corresponding implementation. Or you could use the configuration parameter handshake mechanism to switch at runtime for certain flows.
2. QUIC is stream-based, but they support fixed/final-sized streams which are logically equivalent to messages. You just generate a disposable fixed-size stream for each “message”. So, it is trivial for the Tx side to know the “message” size and thus do SRPT prioritization. The thing that would be more annoying to support is the Rx side knowing the stream size as size finalization is detected by the Rx side via the FIN bit when transmitted the terminal segment in a stream. You could transmit the terminal segment first, but that is awkward and Homa is superior in that respect. However, Rx size finalization would only really be important for avoiding over-allocation of Rx buffering in QUIC since they do not rely on MAX_STREAM_DATA for flow control whereas the equivalent concept in Homa, GRANT, is used for flow control and thus precise Tx sizing awareness by the Rx side is more important.
3. As mentioned above, Homa GRANT is very similar to QUIC MAX_STREAM_DATA which are basically just extensions of TCP window size to more than one data flow. The main difference is how they are used.
TCP and Homa both use it for Rx resource availability and bandwidth limiting. Homa uses it additionally for data flow prioritization as it has more than one data flow. QUIC uses it for Rx resource availability and implementations can use it for data flow prioritization. QUIC uses MAX_DATA or just plain congestion control bandwidth estimation for bandwidth limiting.
The fundamental usage is Rx resource availability. If you have no Rx buffers available to take the data, then no amount of data sent is meaningful. That is a hard cap. However, using that as a bandwidth limiting mechanism like TCP and Homa requires continuous tight feedback to avoid the Tx from determining there are no Rx resources available while not over-provisioning allowed bandwidth.
To illustrate, suppose I have a 10 GB/s NIC and generate a 1 GB request per second, but my end-to-end is a 1 GB/s link with 1 ms one-way latency. So, this link only handles 1 MB in-flight without buffering. For the sake of simplicity say we pack only 1 KB per packet, so the link can only have 1,000 packets in flight without buffering. How should we manage the GRANT flow?
If we do a initial GRANT of 10 MB, then the Tx will shovel 10 MB into its 10 GB/s NIC which will spit out into the network in 1 ms. This will clog up at the 1 GB/s bottleneck requiring ~10 MB of buffering at the bottleneck. The Tx will then wait for more GRANT as it just bursted it all. After 1 ms the Rx will get the first byte, what should it GRANT and when? If we wait 1 ms, we have received our first MB, should we GRANT 1 MB? Our steady state then looks like bursts of 10 GB/s with 10 MB of buffering at the bottleneck until the request completes.
If we do a initial GRANT of 1 MB then GRANT 1 MB when we get it all, then we stall.
If we do a initial GRANT of 2 MB, then 1 MB every ms then we get 2 MB of buffering at the bottleneck until the request completes.
What is the optimal flow? The optimal outcome is a continuous 1 GB/s flow with one 1 KB packet entering every 1 us. This results in minimal buffering as a result of the transport protocol. For the GRANT mechanism to do this would require a new 1 KB GRANT to arrive every 1 us.
Absent a separate point-to-point bandwidth control system to pace the DATA flow you are not getting that. But once you have that, the GRANT is no longer the bandwidth limiter, it becomes a Rx resource availability and flow prioritization mechanism, just like QUIC. It no longer becomes meaningfully distinct.
In a lossless RPC the client should expect the reply in 1002 ms. When should the client resend the request if it got lost?
Given that the client would not expect to see the first byte of the reply until 1002 ms and receives no other feedback until then, they should not issue a resend of their request until 1002 ms.
That means if the network lost their first request, they will not send a resend until 1002 ms and then get the reply to their resend at 2004 ms.
In contrast, in a ack based approach, the client would expect a server ack in ~2 ms as the server gives feedback on receipt rather than on processing completion/reply start.
That means if the network lost their first request they will not send a resend until 2 ms and then get the reply to their resend at 1004 ms, nearly half the latency.
In ack based approaches, packet loss requires one additional RTT latency to recover per repeated packet loss. But Homa incurs one additional RTT + processing latency to recover per repeated packet loss.
As a secondary downside, this requires the client to hold Tx resources for RTT + processing time since the client does not know when the server has received all of the data. In ack-based approaches, you learn the server has received all of the request when it acks all of the data in the request which is on the order of the RTT and thus can release Tx resources at that time. This is similar to the reason Homa has ACK/NEED_ACK packets except applied to client side resources instead of just server side resources.
The case you are describing is more like what if the server explodes, but you still need the results/modifications related to your RPC to occur. In that case, whether the Tx got through or not is irrelevant because your RPC still did not complete and you need it to complete, so there is no advantage to the ack-based approach. But by that logic, what if it explodes before persisting changes? Or what if all your servers explode? At some point we should call that out of scope for a transport protocol.
I prefer setting that line at “bytes got from one end to the other”. If you want higher guarantees then you can layer that. As you point out, it is easy to just layer a “server dead” timeout ping which basically solves the problem in the same way Homa needs to.
“Ultimate responsibility for RESENDs lies with the client: if it has not received the entire response message within an expected time then it MUST issue RESEND request(s) for the missing part(s) of the response.”
I retract my statement that it does not describe whole RPC loss in protocol.
However, even as someone familiar with network protocols and reading RFCs that is a very oblique and easy to miss way to describe the process. I would recommend a more direct and explicit treatment of the “request lost” case and make clear the “RESEND Length=-1” mechanism as this seems like the only case where that should be relevant. Likely also a state machine since the state flows are different than the regular data loss mechanism; Tx DATA, Tx Lost, Tx RESEND, Rx RPC_UNKNOWN, Tx DATA or something of the like.
Also as I mentioned in another reply [1] the described mechanism has many undesirable propertys.
2. My statement was more about explicit consideration as to how encryption integrates. Sure, you can just layer it below with IPSec or above with TLS, or any other myriad of ways as you could in literally any protocol for transmitting bytes, but TLS over TCP versus QUIC shows how much more painful it is if it was not in the original design.
3. I did not see that it was a duplex benchmark, but that is a very non-standard way to benchmark, so I can not comment as to comparability to standard one-way benchmarks. If a one-way benchmark is equivalent to the sum of the two-way flows, then I will concede that it is comparable to QUIC implementations.
However, my personal experience with designing and implementing transport protocols results in me finding 8 Gbit/s per core in software to be extremely slow which also applies to every QUIC implementation I have ever seen.
4. Congestion control in QUIC, like in TCP, is not fixed though there are recommended implementations. Furthermore, stream prioritization, something not present in TCP due to the single stream nature, is also not fixed. A implementation that offers prioritizing which streams to transmit data for by SRPT would likely see similar outcomes to Homa. I am not aware of any implementation that does so, but it is a freely configurable element of that protocol. I see nothing that would materially stop a comparable solution from being dropped in.
Mainly, unlike TCP, the design of QUIC has knobs in many of the right places so that you can reasonably configure the desired propertys with minimal design clashing.
Really, the main fundamental distinction in steady state operation is the resend mechanism being largely ack driven TCP and QUIC whereas Homa is largely nack driven.
I am of the opinion that ack driven is much superior technically, which is part of why I think Homa is a bad design, but likely for different reasons and considerations as to how it relates to transport protocol design than the designers of QUIC.
This is also not to say that I think QUIC is the best protocol, QUIC has a number of design and performance weaknesses, but it is overall a reasonable and material improvement over TCP and should be considered the standard to beat.
On a contiguous shared data area on the order of 1 GB, you are only tolerating a 2 MB overallocation on 1 GB of data area (~1/512 overhead), but saving ~2 MB of PTEs per process sharing the data (including the first) so you can come out ahead even if you are sharing at all.
At 300 GB you can even reasonably use 1 GB pages for a even more ridiculous ~1/128M overhead and effectively never run into the problem.