The content is nice and insightful! But God I wish people stopped using LLMs to 'improve' their prose... Ironically, some day we might employ LLMs to re-humanize texts that had been already massacred.
The author’ blog was on HN a few days ago as well for an article on SBOMs and Lockfiles. They’ve done a lot of work in the supply-chain security side and are clearly knowledgeable, and yet the blog post got similarly “fuzzified” by the LLM.
> PEP 658 went live on PyPI in May 2023. uv launched in February 2024. uv could be fast because the ecosystem finally had the infrastructure to support it. A tool like uv couldn’t have shipped in 2020. The standards weren’t there yet.
In 2020 you could still have a whole bunch of performance wins before the PEP 658 optimization. There's also the "HTTP range requests" optimization which is the next best thing. (and the uv tool itself is really good with "uv run" and "uv python".)
> What uv drops: Virtual environments required. pip lets you install into system Python by default. uv inverts this, refusing to touch system Python without explicit flags. This removes a whole category of permission checks and safety code.
pip also refuses to touch system Python without explicit flags?
For uv, there are flags that allow it, so it doesn't really "removes a whole category of permission checks and safety code"? uv has "permission checks and safety code" to check if it's system python? I don't think uv has "dropped" anything here.
> Optimizations that don’t need Rust: Python-free resolution. pip needs Python running to do anything.
This seems to me to be implying that python is inherently slow, so yes, this optimization requires a faster language? Or maybe I don't get the full point.
> Where Rust actually matters: No interpreter startup. ... uv is a single static binary with no runtime to initialize.
how they claim fetching from a single index magically solves dependency confusion attacks, when in reality it makes the attack much more trivial and able to succeeded. typical llm syncopation.
> uv picks from the first index that has the package, stopping there. This prevents dependency confusion attacks and avoids extra network requests.
As long as the "first" index is e.g. your organization's internal one, that does ensure that some random thing on PyPI won't override that. A tool that checks every index first still has to have the right rule to choose one.
It is, however, indeed a terrible point. I don't think I've even seen evidence that pip does anything different here. But it's the sort of problem best addressed in other ways
By "syncopation" perhaps you mean "sycophancy"? I don't see how musical rhythms are relevant here.
I used to rely on this, and still mostly do - but you’d be surprised how quickly this has entered the normal vernacular! I hear people using it in conversation unprompted all the time.
I definitely found the thesis insightful. The actual content stopped feeling insightful to me in the “What uv drops” section, where cut features were all listed as if they had equal weight, all in the same breathless LLM style
I would be able to absorb your perspective better if it were structured as a bulleted list, with SUMMARY STRINGS IN BOLD for each bullet. And if you had used the word "Crucially" at least once.
I have reached a point where any AI smell (of which this articles has many) makes me want to exit immediately. It feels tortuous to my reading sensibilities.
I blame fixed AI system prompts - they forcibly collapse all inputs into the same output space. Truly disappointing that OpenAI et all have no desire to change this before everything on the internet sounds the same forever.
You're probably right about the latter point, but I do wonder how hard it'd be to mask the default "marketing copywriter" tone of the LLM by asking it to assume some other tone in your prompt.
As you said, reading this stuff is taxing. What's more, this is a daily occurrence by now. If there's a silver lining, it's that the LLM smells are so obvious at the moment; I can close the tab as soon as I notice one.
> do wonder how hard it'd be to mask the default "marketing copywriter" tone of the LLM by asking it to assume some other tone in your prompt.
Fairly easy, in my wife's experience. She repeatedly got accused of using chatgpt in her original writing (she's not a native english speaker, and was taught to use many of the same idioms that LLMs use) until she started actually using chatgpt with about two pages of instructions for tone to "humanize" her writing. The irony is staggering.
It’s pretty easy. I’ve written a fairly detailed guide to help Claude write in my tone of voice. It also coaxes it to avoid the obvious AI tells such as ‘It’s not X it’s Y’ sentences, American English and overuse of emojis and em dashes.
It’s really useful for taking my first drafts and cleaning them up ready for a final polish.
https://ember.dev ’s deeper pages (not the blog, but the “resumelike” project pages) was written by claude with guidance and a substantial corpus of my own writing and i still couldn’t squash out all the GPTisms in the generation passes. probably net waste of time, for me, for writing.
It’s definitely partially solved by extensive custom prompting, as evidenced by sibling comments. But that’s a lot of effort for normal users and not a panacea either. I’d rather AI companies introduce noise/randomness themselves to solve this at scale.
The problem isn’t the surface tics—em dashes, short exclamatory sentences, lists of three, “Not X: Y!”.
Those are symptoms of the deep, statistically-built tissue of LLM “understanding” of “how to write a technical blog post”.
If you randomize the surface choices you’re effectively running into the same problem Data did on Star Trek: The Next Generation when he tried to get the computer to give him a novel Sherlock Holmes mystery on the holodeck. The computer created a nonsense mishmash of characters, scenes, and plot points from stories in its data bank.
Good writing uses a common box of metaphorical & rhetorical tools in novel ways to communicate novel ideas. By design, LLMs are trying to avoid true (unpredictable) novelty! Thus they’ll inevitably use these tools to do the reverse of what an author should be attempting.
Read our paper on de-slopping LLM outputs. It's far more than simply all having the same fixed AI system prompts. It's an overuse of post-training and contempt for pre-training.
That is correct for the collective as a whole, but in his instance, if this wasn't connect to a public github, it would have been substanially more difficult to prove he used a LLM.
You're supposed to also remove the fancy UTF-8 quotes that people can't normally type, the EM dashes, and reorder sentences/clauses because the paragraph level "template" slop is really obvious to people who use these models all the time. (I'm also pretty sure that the UTF-8 shenanigans with LLM responses was done very on purpose by those who have a vested interest in making it easier for mass surveillance of written communication.)
Or, use the "deep research" mode for writing your prose instead. It's far less sloppy in how it writes.
These people are amateurs at humanizing their writing.
To me, unless it is egregious, I would be very sensitive to avoid false positives before saying something is LLM aided. If it is clearly just slop, then okay, but I definitely think there is going to be a point where people claim well-written, straightforward posts as LLM aided. (Or even the opposite, which already happens, where people purposely put errors in prose to seem genuine).
> Ironically, some day we might employ LLMs to re-humanize texts
I heard high school and college students are doing this routinely so their papers don't get flagged as AI
this is whether they used an LLM for the whole assignment or wrote it themselves, has to get pass through a "re-humanizing" LLM either way just to avoid drama
We wrote the paper on how to deslop your LLM outputs and if you use our factory de-slopped versions of gemma3 you don't have to worry about this, similarly if you use our antislop sampler, your LLM outputs will look very close to human.
there is going to be a point where people have read so much slop that they will start regurgitating the same style without even realising it. or we could already be at that point
Sorry, I don't get it. The secret key has to be stored somewhere, right? If it's on the server, the attacker gets it together with the vault. If it's on the client, then you lose your phone → you lose your passwords, which is, while secure, very risky and I wouldn't expect it from a company focused on regular customers.
It’s generated locally when you create your account and not shared with 1Password. Various keys are derived from your master password and secret key.
The secret key is never sent to 1Password and is only used locally.
This is why it’s so much more secure than LastPass, and Bitwarden, and any other cloud hosted solution. I know, I just pissed off all the Bitwarden fans, but it is true.
You must save your Secret Key, but it’s also saved in Apple’s Keychain so there’s a copy there as well.
Finally, if you do lose your secret key, your account can be recovered using the Account Recovery process as long as there is someone else on your account with the appropriate permissions. If you want to know how that works, ask, but it’s sort of lengthy so I’ll skip it for now.
When you setup your 1password account you are provided an ‘Emergency kit’ in the form of a PDF containing this key and other info. You are supposed to save it somewhere secure or print it and place it somewhere secure.
You could save it in a local keepassXC database if you like.
This 128bit key is only saved locally, not on their servers. So contrary to you disbelief, 1Password does actually prioritise security in this manner over focusing on ‘regular customers’.
Its also fairly common to have more than one device, so you would have the key on more than one device as a result too.
It sounds like a public and private key pair, like in asymmetric encryption or public-key cryptography. The private key is stored on the client. The private key and users password are both required to authenticate against the public key stored the server.
An attacker would have no success with a dictionary attack (used in the article). Even if the password was in the dictionary, the private key is still missing.
No. It's symmetric, not asymmetric. The secret key is a 128-bit key that is effectively concatenated with the master password for master key derivation.
Imported an EPUB into the app. Really nice typography, so props to you on that!
The internal links seem to be not working, though. I mostly read books with a lot of footnotes, so I won't be able to try it as my daily reading driver right now, but good luck! There's not a single one good reading app out there, so the market is yours to take.
