thaumasiotes

It also includes everything in the world under the umbrella of "stealth bot". That leaves you with criminalizing "anything, that causes harm, if the harm was predictable".

You can have a law like that. In fact, we already do have laws like that. This is the general concept of a tort.

But the work of the law is being done by the discussion of harm, not the definition of "stealth bot".

In my experience a lot of people use 'capitalism' to mean 'anything that the United States does'. That would fit pretty well here. But I'm always curious whether there's something else going on.

> wholistically

You made me curious about the spelling of 'holistic', given that it really is based on the concept of wholeness. It turns out:

- Holistic is formed from the Greek root hol-, meaning "whole". Like hologram.

- It's even closer to the English than it looks; modern whole descends from Old English hal (cognate to the Greek word), which also gives us hale and health. The W in the modern spelling is a spurious addition unrelated to the etymology of the word. You'd expect "hole".

- Who is different, and the W in that word is etymologically correct. (Old English hwa.)

No, the definition of 'stealth bot' is a disaster. The proposed text criminalizes altering your user-agent string. It arguably criminalizes all existing user-agent strings, since their whole purpose is to lie about which browser you are.

Taking the first thing I could find, geekflare.com informs me that the current user-agent string for Google Chrome running on Windows 11 is

    Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/155.0.0.0 Safari/537.36

What's doing the work in the proposed text is the prohibition on using software "in a manner that is reasonably likely to damage, impair, or burden the technical or commercial operation of" a service.

> Someone who is using a residential proxy network, headless browsing, and/or TLS fingerprint manipulation to evade rate limits and other controls to issue large volumes of automated requests under a deceptive UserAgent string isn't difficult to describe and differentiate versus a normal user using a UA.

Note that someone who's scripting a headless browser doesn't need to use a deceptive user-agent string. They can use the user-agent string for their browser, which isn't deceptive except to the degree that all user-agent strings are 90+% lies.

> Not to say a rewrite is necessary right, but avoiding rewrites of working code is how we ended up with more COBOL code than COBOL programmers in 2026.

Surely we have more code than programmers for every language in existence?

Except for the part where the concept isn't even well-defined, this sounds like a complaint that the world contains more bricks than bricklayers. Of course it does.

Do you have reason to believe that the article knows something about the origin of this practice that no one else in the world knows? The claim is set in the past, not the present. And it has to be, since there is no present significance to unpainted wood in English-speaking cultures.

> Couldn't they just admit the problem with capitalism is that you run out of other people's money

What do you mean when you say "capitalism"?

> Armitage wisely avoids rhyme, unlike some recent versions – there is no evidence of rhyme in the original text

No rhyme in the original doesn't mean there should be no rhyme in the English. Akkadian and English are different languages. English verse rhymes.

pyon is basically correct.

--- technical details ---

CLRS (3rd edition) defines three types of amortized cost analysis. The first type ("aggregate analysis") requires us to show that for all sequences of n operations, the total actual cost of performing those operations in that sequence is less than some function T(n). We can then say that the amortized cost of all such operations is T(n) / n. This makes it necessary that cheap operations precede expensive ones.

The second type ("the accounting method") is different: we assign potentially-inaccurate prices to all operations. These prices will be constant regardless of the actual cost of performing those operations. Conceptually, an operation is in "credit" if its actual cost is less than its assigned price, and it is in a state of owing if its actual cost is more than its assigned price.

We must then assign prices that make it possible to show that, for all sequences of operations, the total actual cost of all operations from the start of the sequence to point n within it is less than the total amortized price assigned by our price schedule. (Stated another way, while an individual operation is free to "owe", a sequence of operations may never be in an "owing" state.) If we can prove that, we are justified in making a claim about the amortized cost of the operations we considered. (Under this method, the amortized cost of an operation is equal to the price we assigned it.) This also makes it necessary that cheap operations precede expensive ones.

The third type ("the potential method") defines a potential function which evaluates the state of the data structures maintained by the algorithm. ("Potential" in the sense of potential energy, which can be stored and later released.) It then says that the amortized cost of an operation is equal to the actual cost, plus the difference in "potential state" caused by the operation. Conceptually, if potential is raised, the amortized cost was higher than the actual cost (and has built up a buffer that later operations may draw down), and if it is lowered, the amortized cost was lower than the actual cost.

As before, we must show that no sequence of operations can place the data structure into a state of negative potential. Cheap operations must precede expensive ones.

------

Now, why was pyon telling you you should be ashamed of your post? It's almost certainly these two paragraphs:

>> If you read more about big-O, you may see the word “amortized” thrown around. That’s a fancy word for “average,” meaning that individual occurrences don’t all behave exactly the same, but over the long run, averaging over many operations, the behavior has a certain characteristic.

>> The analysis we’ve been doing is for the average behavior. Lots of operations can behave much worse in unusual circumstances. Adding a key in a dict and looking up a key are O(1), which is true for typical data. But if you understand the internals of dicts, you can carefully craft a set of keys that will perform terribly, with O(N) behavior. Filling that dict would take O(N²) time.

Your post has confused average-case analysis with amortized analysis. (And it makes this problem worse by implying that the two terms refer to the same concept.) The point of amortized analysis is that you cannot see worse performance than the amortized cost.

An amortized analysis is deterministic and averages runtime costs over the different operations that are present in a sequence of operations beginning from a given initial state; an average-case analysis is stochastic and averages runtime costs of a single operation over many different performances of that operation against different initial states. These two terms are not synonymous and they don't belong to the same universe of terminology; if we're thinking about "average-case analysis", then an amortized analysis is a type of "worst-case analysis", not a type of average-case analysis.

The first paragraph I quoted tells us that you're talking about amortized analysis, but you aren't: the example you provide is of an average-case analysis. If the amortized cost of adding a key to a dictionary were O(1), it would be impossible for adding a sequence of N keys to that dictionary to take more than O(N) time. (As is in fact the case for the Python list.append example you mention beforehand.)

> I am a software developer and software is staffed with males with low social intelligence at a much higher rate than the population at large. My wife works in education and its the same thing there for females.

Female teachers are disproportionately unable to perceive the emotional communication of others?

So what? Why do you want your database viewer to run in the browser?

> That is for example relevant, if you want to be able to run trains at full speed <1m tolerance, so that you can have more than one train stopping at a station <60s.

...is that something you'd ever want? In general, it is, but the way it's handled is by having those trains stop on separate tracks.

Running multiple trains through the same station track in under 60 seconds means that all passengers must embark and disembark in under 30 seconds. That's very tight. I would venture to say it's too tight and meeting this goal would make the trains worse.

(And if passengers aren't getting on or off the train, then the train isn't stopping at a station.)

Any lessons in HPMOR are also going to be found in traditional works.

I was interested to find a discussion of the trolley problem in a book of out-of-copyright Norwegian-region folk tales (in English translation) that Amazon recommended.