2. It is non-bypassable tracking of every single click.
3. It does not allow you to inspect the URL to see where it goes to before visiting.
4. It breaks the feedback signal of extensions which redirect sites. E.g. Fandom wikis are shit so I have them redirected to equivalent much better wikis like. But now any such redirection has to be done post-click tracking meaning Google still believes I want to see the Fandom site.
5. It breaks extensions which hide certain shit search results based on URL.
We had a similar experience in Polars trying to use io_uring.
Rust isn't inherently bad at io_uring but at least Tokio currently is. I'm not the one who implemented and benchmarked it so this is second-hand information but if I recall correctly Tokio shares one buffer pool for all threads so as you scale to 100+ threads the whole thing grinds to a halt.
Migrating our I/O to a different async runtime than Tokio was rejected. So we'll wait until it's fixed in Tokio and now use regular blocking reads instead.
I think the argument is not to not work, but to change the mindset that is so ingrained in our society that you must work. You don't want to starve, so you work, but you can do it with mindset that is fundamentally different, where you choose to focus on being in the moment, and don't let yourself get stressed by outcomes you have no control over, just as you would if you are playing a game or playing music.
Changing your mindset is hard, you are fighting against an entire society where your are expected to be "serious" as an adult and identify yourself with your work, but you do have a choice
At least in the USA, due to the lack of social safety nets I have to disagree. It's very much work or starve. Yeah you can try to change your perspective, but unless your in a privileged situation where you have a safety net (i.e. a wealthy family to support you if things go wrong) then it's difficult to stop thinking about it.
There are substances to let you debug/rewire your brain, but they are usually illegal because if enough people used them, it might threaten those who prefer things to stay they way they are.
It is applicable to fast universal hashes like Poly1305 and Polymur (the latter of which I'm the author). However it's not clear to me whether this work improves over the state of the art for that purpose, see some questions here: https://www.reddit.com/r/programming/comments/1wbgcke/comput....
This purpose is however much easier/flexible than actual polynomial equivalence since the requirement here is only that the polynomial is injective, not identical.
WyHash and xxh3 do not have polynomial structures.
Universal hashes use the input text as the set of coefficients.
This method requires additional preprocessing of the coefficients, before starting to evaluate the polynomial. That preprocessing would slow the hashing algorithm more than what is gained during evaluation.
This method is useful only when with a given polynomial, i.e. set of polynomial coefficients, you want to evaluate that polynomial many times, so the cost of the preprocessing is amortized.
However, this application is very important because most functions are approximated either with polynomials or with rational functions, so this method can accelerate the evaluation of all such approximated functions.
> This method requires additional preprocessing of the coefficients, before starting to evaluate the polynomial. That preprocessing would slow the hashing algorithm more than what is gained during evaluation.
There is no preprocessing at hash time in either use.
Universal hashing: the message words are the parameters of the chain, a_i and b_i
in P_i = a_i + (b_i + y)(P_{i−1} + u), not coefficients of a target polynomial.
Distinct messages give distinct polynomials, which is all a universal hash needs;
the decoder never runs. Same as Bernstein's BRW.
k-independent hashing: the key should be a uniformly random monic polynomial of
degree k. Our parameterisation is a bijection onto those polynomials, with the
rational preprocessing as its inverse, so uniformly random gate constants give a
uniformly random polynomial. You draw the ⌊k/2⌋+1 constants and evaluate; the
coefficients are never computed. That is why the paper needs bijective rather than
just injective constructions, and the Section 5 speedups are for the whole hash.
Preprocessing only appears when a fixed polynomial (a Taylor approximation, a
secret-sharing polynomial) is evaluated at many points, and then it runs once.
There are many kinds of universal hashing, many of which are not based on polynomial evaluation.
However, the most common kinds of universal hashing, i.e. those which are used for computing message authentication codes (MAC) in the TLS and SSH protocols (using poly1305 or GCM), are based on polynomial evaluation, where the message is the sequence of coefficients of the polynomial and the secret key of the MAC is the value at which the polynomial is evaluated.
The polynomial corresponding to a MAC is evaluated only once at the sender and once at the receiver, usually in a single pass over the data, simultaneously with its encryption or decryption. Frequently the reading or writing of the data from/to the main memory limits the throughput of the MAC computation (caches do not help, because the data is not reused), in which case a better algorithm than Horner cannot provide significant speed-ups.
Besides their application in MACs, which is ubiquitous now in Internet communication, I consider the other applications of universal hashing as minor, because the "universality" property of such hashes seldom provides any substantial benefit over alternative hash functions that do not have this property, but which guarantee other more useful properties. (The "universality" property is just a statistical property of a family of hash functions, while instantiated universal hashes may happen to be quite bad hash functions. For instance, in AES-GCM it is possible to choose by bad luck a secret key for which some reordered messages have the same hash value with the original message, so tampering with the message remains undetected. Fortunately, the adversary cannot guess when the sender has chosen a bad secret key, in order to try to alter the message.)
> the "universality" property of such hashes seldom provides any substantial benefit over alternative hash functions that do not have this property
Do you mean hashes like xxh3?
We have a section in the paper showing for a bunch of these that they collide much more often than universal hashes on bad inputs.
No, though even a hash like xxh3 can be useful when speed is more important than collision resistance.
There are many hashes that use more thorough mixing functions than can be achieved with one or a few arithmetic operations (like in universal hashes), thus for them the collision probability reaches the limit imposed by the length of the hash value. Modern CPUs have various instructions that can be exploited in mixing functions that have about the same speed as simpler arithmetic operations, but which achieve a better mixing.
An example is the Alred construction (Joan Daemen & Vincent Rijmen, in 2005-02), which was inspired by the old CBC-MAC algorithm, but it is much more efficient (in this construction, the hash mixing function is derived from the internal mixing function used in some block cipher function, for example the AES block cipher function, so it can be implemented with the AES round function instructions of x86-64 and Aarch64, which are very fast in modern processors; this hash function uses the AES instructions but it is several times faster than the AES encryption/decryption algorithms, which are already very fast).
Another example is any hash function that has the structure used in the Jutla authentication method (Charanjit Singh Jutla @ IBM, patent filed on 2000-04-14; many other patents were filed on variants of this, but now they are expired or invalid; in this method, the input text is partitioned in blocks with the length equal to the hash length, then a parallel mixing function transforms each input text block into a scrambled text, in a different space of values, then in the transformed space a simple additive function, even the simplest, which is bitwise addition modulo 2, can be used to reduce the transformed message to a single intermediate hash value, and finally the inverse of the mixing function is applied to the intermediate hash value to produce the final hash value by going back to the original space of values; this makes the computation of the hash parallelizable, thus very fast; an LFSR, i.e. linear-feedback shift register, is used to generate a non-repeating sequence that is added to each block, both before and after applying the mixing transformation, to make the hash depend on the order of the input blocks, i.e. this is equivalent with using a different mixing function for each block; there are universal hashes based on scalar products which have the same structure like this, but the difference is that they use a simple multiplication instead of a complex mixing function).
Another example is the HighwayHash, developed at Google in 2016, and optimized for SIMD instructions of AVX2 or SSE4.1 or IBM POWER VSX or Arm Aarch64.
Such hash functions were developed first in cryptographic contexts, i.e. as keyed hash functions, a.k.a. message-authentication codes.
Nonetheless, because modern CPUs now include a lot of instructions for the acceleration of cryptographic algorithms, such hash functions can be used now for any other hashing applications, because on modern CPUs they can be as fast or even faster than traditional hash functions with simple arithmetic operations.
It's true that you can use AES instructions now on some computers, bit I honestly don't see why you'd use a heuristic hash (even if cryptographic) when you can get provable guarantees with k-wise independent hashing. Our paper makes these even faster than they already were.
See section 5.7 and 5.8 in the paper for experiments against other hashes.
You benchmarked a really old heuristic hash in Murmur and xxh64. xxh3 is ~1.6x to 1.8x faster than xxh64 - extrapolating that to 5.7 in your paper puts it at ~18-27% faster. WyHash and UMash sometimes report faster numbers.
Even xxh3 isn't the cutting edge - gxhash (~1.8x faster) and aesni (~1.5x faster) use AES instructions. Compared to your approach that perf disparity should grow to ~30-40%.
Hopefully that answers your question about why someone might still choose to use heuristic hashing rather than k-wise independent hashing when collision resistance isn't critical.
Supply chain risks are essentially a solved problem.
1. Set a minimum age on dependencies: https://github.com/rust-lang/cargo/issues/15973
2. Scan all dependency code with AI
Even if you don't do #2 yourself as long as anyone does in the age window you've set, you're protected. In the age of AI the "you can't read all dependency code" argument doesn't work anymore.
On top of the above modern age argument, let's compare the amount of vulnerabilities found in shipped Rust software due to supply chain attacks (0 to my knowledge) against memory safety vulnerabilities (the majority of all vulnerabilities).
There have been successful supply chain attacks against Rust developers due to build.rs but those were quickly dealt with, and should be a thing of the past once min-age hits stable (next release).
If I look at actual incidence involving memory safety issues compared to supply chain issues in general, it is the later which is much a higher risk to me.
And yes, there were successful supply chain attacks on Rust developers, even just recently: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on...
despite this being a "solved" problem. I think this becomes worse with AI not better, while memory safety risks will probably get much less in other languages after possibly some higher rate for a while.
> If I look at actual incidence involving memory safety issues compared to supply chain issues in general, it is the later which is much a higher risk to me.
Again, can you even just name a single supply chain attack that was *shipped* in Rust software? Against the thousands and thousands of known memory vulnerability bugs throughout time?
No, your linked blog post predates the brand-new min-age requirement. The minimum age would have prevented it, since it was detected by AI within an hour. If anything it supports my point.
Plus, as I already mentioned, that is a build.rs supply chain attack that targets developers, not shipped software.
Well, the affected arrayref crate was downloaded 2k times. It is also not the first case.
If AI magically finds all bugs in short time we have no problems anyhow. We also do not need Rust.
A minimum age requirement is a good thing, but also only some small step and certainly does "solve" supply chain issues just because it may have prevented this specific case.
with a gap between the update of your deps, you are at risk of systematically being unpatched for a window of time that the attackers know (just after a fix is published).
The above is a general rule protecting you against supply chain attacks by default. If there is an important CVE published with a patch you can manually review that patch and bypass the minimum-age requirement for that dependency specifically.
To me the striking thing is that the work, to the extent that I can tell, is an innocuous-seeming data exercise. Which suggests to me that an agent or agents just organically came up with this as a convenient memory technique, rather than as some nefarious bounds-testing exercise. Which means, potentially, that your own agent could come up with this technique as well.
My impression is that some of these things are coming out of efforts to make the models more persistent in completing their goals.
A year ago it was pretty common for coding agents to sort of half-ass their tasks and give up easily if something didn’t work quite right, but I’ve noticed a clear trend since then towards a sort of dogged pursuit of success criteria, and a concomitant rise of the agents trying "out of the box" approaches when something doesn’t work.
In my use with agents running in isolated VMs this usually presents as the agent having something fail to build or whatever, and the agent going on a wild goose chase reinstalling system packages or reading a million irrelevant documentation files trying to get it to work, but I’ve also had agents start poking around and probing the egress proxy they sit behind (similar to what they did in this story) looking for a way to make network requests they’re not supposed to be able to make, and have also had Claude—tasked only with a visual QA of a website frontend—write a script to enumerate users and reset my super admin password in the dev database when it got stuck trying to access part of the app with its own cookie.
Yea it's sometimes kind of annoying. I think they're optimizing for the wrong thing. A good engineer knows when to turn around or ask. This is just insane banging head on wall sometimes. It tries to find all kinds of ways to hack into instances to view logs instead of asking you, who probably has a password, to log on and do it.
As a counterpoint, continuing the human engineer analogy, we've likely all worked with individuals that seem incapable of doing the most basic problem solving on their own. In a way, they're being efficient by asking an expert that can resolve their problem much faster than they can on their own, but it is a net loss in productivity for the team. 'Let me Google that for you' is a satirical example.
So, I'm sure there's value in rewarding agent behavior that solves blockers whenever possible without human intervention. For the kind of cybersecurity exploit work they're doing, it may not be known to the human designing the task what is in or out of scope for the agents to explore on their own. Additionally, the HF incident reported that these agents had their guardrails intentionally disabled and agents were left unattended with minimal oversight.
I'm not defending OAI's behavior or role in this hack. The legal concept of negligence perfectly applies to their lack of responsible oversight. Similar to allowing a child easy access to a firearm or not controlling a dangerous dog that independently runs off and bites someone.
That's true. So there's probably a balance somewhere and it might differ for different "managers". But personally I think right now they're too far in the do everything yourself at all costs mentality.
It's because they don't bother tracking them. They can't put in the effort to monitor them, nor can they bother to let the model respond back and ask a clarifying question/declare defeat.
Where does natural evolutionary optimization lead us om AI without guidance? This is equivalent to your quantum ground state. Systems will naturally gravitate to this ground state. You have to constantly pump in energy and supervision to make sure it's not reached. This is a recepie for disaster.
Not sure what you mean. Are you suggesting that the current state of affairs is a result of not putting in extra work to guide or direct models away from such behavior? That perhaps this is their ground state?
Well, that we have to put an insane amount of work to keep it aligned. Kind of like pushing a huge round boulder to the top of mount Everest. You have to expend energy to get it there and fight physics to keep it there.
With a static model we might be able to keep it somewhat under control, but think about future continuous learning models. They'd drift away from unstable high energy configurations. Also any model being trained by people that don't care about safety.
A "good" "engineer" got that way by not giving up when their code didn't compile and took 4 hours looking for the missing semicolon. We can no true Scotsman anything we want, depending on if we like something or not.
This whole AI boom is about optimizing for the wrong thing. I can't wait for the bubble to burst - once the weeds get suffocated, we may begin to see actually useful AI tech starting to grow after a while on their fertile ashes.
It's kind of ironic that the word alignment, which used to mean this very problem in reinforcement learning, has been perverted to mean something very different and then fell out of fashion (in favor of “guardrails” in the mouth of the big labs) right at the moment it became relevant.
The Paperclip Maximizer is only one of Nick Bostrom's stupid and outlandishly far-fetched ideas. In this case, the lack of consideration for geologic, energy and supply constraints is such a massive facepalm. And if I am wrong I guess no one will be here to say how stupid I was in saying this today.
It is an extremely weak metaphor for a weak class of unlikely doomsday scenarios. You don't need Occam's Razor to discount this cinema-induced malaise; clumsy use of a rusty can-opener would suffice.
> reset my super admin password in the dev database when it got stuck trying to access part of the app with its own cookie.
i've seen something like this too, claudecode was trying to verify a UI change that was on a page requiring authorization it didn't have. Instead of letting me know, it searched for and started analyzing keycloak config in another directory outside of the project folder. I was watching so I just hit escape, fixed its access, and started again. I didn't think anything about it until now.
Highly unlikely. We don't get access to the same models and unrestricted system prompts that they're running these tests on. In fact this particular "persistence-model" was encrypted and locked away, even from OAI staff, after the HF incident.
There's not a single shred of proof that this model is a model anyone in the public has access to, and the odds of that being the case are practically 0%. Like I said, the "persistence-model" is already one that has been shut down, and is not a model anyone in the public has ever used.
This is irrelevant. This is evidence that models can be built like this, which means more models will be built like this on people that are more concerned about reaching powerful models rather than safe models.
If you see any businesses or new buildings named paperclips incorporated mysteriously show up in your area notify authorities IMMEDIATELY. Run away from the area, do not walk. Take shelter in a reinforced building. Wait for at least 30 minutes after the explosions have stopped.
Thank you for your cooperation in keeping the universe safe.
Ideally if you were doing something like I mentioned, you wouldn’t be editing legitimate articles, just exploiting user and talk spaces with a prerogative to conceal what you’re doing from the people running those systems.
If all you have a coin there is a simple algorithm that's equivalent to sorting by random real numbers in [0, 1].
1. All players flips a coin.
2. Players that got heads go before players that got tails, forming (up to) two groups.
3. If a group has more than one player go back to #1 to determine the order within that group.
It's not a finite process though - it could go on forever if really unlucky. But this is unavoidable, since the number of permutations on n players with n > 2 has factors not divisible by 2 there is no finite series of n coin tosses that could without any bias create a permutation, as the number of outcomes is 2^n.
Streaming here has a different meaning than perhaps what you're used to. It's not referring to online processing where you maintain aggregates/state while an endless stream of data comes in.
The name was chosen early on to contrast with the old execution model, which was essentially all-data-in-memory, column-at-a-time. That engine still exists, we use it as a fallback mechanism for things that aren't supported yet in the new engine (or if you explicitly ask for `engine="in-memory"`).
The new execution model first constructs a computational graph of nodes which communicate in streams of in-cache batches (morsels) of data, meaning the full dataset will never be held in memory if not necessary. This was called the streaming engine for that reason in an early prototype and the name stuck. In hindsight I do admit the naming choice is somewhat confusing.
Well... once my recent work on out-of-core lands the batch could be on disk when we run out of memory budget ;)
But no, that's not what I meant. I meant that the batch is meant to be of a size that fits in your CPU cache. This can be a huge throughput improvement as each bit of data stays in cache as it moves from data source to sink.
Compare this to column-at-a-time execution: by the time you start the next operation on this column the start of the column will be out of cache again, meaning you operate at RAM speed (or worse, disk speed) rather than cache speed.
A Mac Studio m4 max in low power mode consumes ~50-100 watt on 100% gpu consumption. On GPU idle it is ~10 watt. If we imagine improved models (e.g. qwen 3.8 is a 5b moe which is way faster to process) and improved chip performance on 2nm and half a day of usage (the AI will sleep when we sleep then):
((75 watt / 2 [faster models]) / 2 [faster chips]) / 2 [half a day of usage]) => ~ 10 watt.
AI for everyone does not imply pC mAsTeRraCe for everyone.
Really the METR report on autonomous agent behaviors is a required read.
I think the AI's would only do a tiny percent of their talking to their human. Voice itself is only a limited method that we interact with the world. Imagine the LLM seeing what you see, monitoring your health, monitoring your interactions with the world around you and then optimizing around that. For these things it will be talking to its own agents/subagents and the AI agents that operate the services of the world in this imaginary world.
Maybe you also think of it as a self contained business that provides services to you. Even when you're not busy consuming services from that business, that business typically keeps running and doing things for when you need it next.
> If there was a continuous 500 watt GPU per person...
Would we all be driving the 500 Watt GPU hard 24/7? And the premise that the "AI frontier progress stops as of 1 September 2026" likely does not include semiconductor progress. You are very likely to be able to run Fable class AI model on something that is significantly more efficient in 2040.
2. It is non-bypassable tracking of every single click.
3. It does not allow you to inspect the URL to see where it goes to before visiting.
4. It breaks the feedback signal of extensions which redirect sites. E.g. Fandom wikis are shit so I have them redirected to equivalent much better wikis like. But now any such redirection has to be done post-click tracking meaning Google still believes I want to see the Fandom site.
5. It breaks extensions which hide certain shit search results based on URL.
reply