Paywalled, so how did it go to the frontpage if most people can't read it?

> if most people can't read it?

By reading the headline

This.

Many HN users don't read the articles. Some are even unapologetic about it, explicitly admitting that they're here only for the comments.

Some of us rarely read the articles. They're often, frankly, a waste of time. And it's hard to tell just by the headline whether it's worth reading or not. The comments often tell me whether the article is worth reading faster than the article would. (And some of the time the article is paywalled, and some of the time it's a video, which makes it harder to skim.)

And often I learn more from the comments than I would from the article.

See the archive.is link that someone also provides.

Most paywalls are easy to bypass. Most HN readers know this.

Some of us also have FT subscriptions though.

That'd be an interesting poll. What % of HN readers (poll participants) subscribe to the big paywalled story sources? NYT, FT, The Economist, ...

Clicking the link hits a paywall, but copy-pasting it gets me the article.

uv has been introduced as cargo for python: https://astral.sh/blog/uv-unified-python-packaging

The whole explaination is here: https://www.bitecode.dev/p/a-year-of-uv-pros-cons-and-should

The td;rd is that is has a lot less modes of failure.

With all due respect, the link you’ve linked to is reddit, and the underlying story is a 500. Can you provide an available source or alternative, since this one seems broken?

Updated link but it's getting hard to find them.

Eg: I can't find any link about the home button scandal anymore.

People will forget about all the wrong doing and the PR will enventually win.

Your link does not contradict his.

The link is still relevant, because apple's statement is posted in a manner antithetical to the article when, in fact, apple does the same thing.

The main difference is that apple didn't allow its users to have such a setting in the first place, so amazon used to be better. Until now, when they're equally bad in this respect.

Plus webusb is a 0 day waiting to happen. Browsers should not become os, they are exposed to the entire web.

Say what else you will about browsers, but they do offer a sandboxed execution environment across all major OSes, only limited by browser capabilities.

There's an argument to be made for limiting some of these permissions to "installed" PWAs, but these beat random Electron apps running with full user permissions in terms of security.

If random electron apps is not connecting to the entire internet, loading completely random code from any website in the world, not they don't.

Before USB4, USB came with DMA. If your sandbox has ever an exploit, that's close to instant rooting capabilities exposed to the entire web.

USBC an hold a ton of power. One sandbox exploit, and the entire web can fry your machine.

This is too dangerous of a capability to be exposed to a public network with tons of malicious actors and bots.

> If random electron apps is not connecting to the entire internet, loading completely random code from any website in the world, not they don't.

Why not? Nothing in terms of sandboxing prevents them from doing so, unlike webapps.

> Before USB4, USB came with DMA.

DMA is mainly a threat to the host, not the device, isn't it?

> USBC an hold a ton of power. One sandbox exploit, and the entire web can fry your machine.

How so? There isn't a "fry this device" USB protocol command. Obviously you could drain a printer's ink etc., but that's just another facet of "don't give random websites/PWAs access to sensitive hardware" that the browser UX indeed has to get right.

Browsers have been OSes for the past decade.

An OS designed by no one and implemented piecemeal through a thousand disconnected RFCs.

And targeted by tens of millions of developers for billions of users.

Isn't webusb almost a decade old at this point? Downloading sketchy flashing software is also a good way to get malware. I trust Chrome more than I do 5 separate toolchains and eclipse clones lol.

I'm expecting nobody will do that anymore in the US.

First, those heroes were treated as enemies, then their revelations lead to nothing for the country, and great pain for them.

Finally, I doubt they would be proud of what their country is today and think it's worth the sacrifice.

Tablets and phones have been criticized for a decade for being limited artificially, locked down and more oriented consumption than production.

Mac products are especially famous for restricting the users in what in can do in exchange for whatever peace of mind that brings.

If you are going to spend hundred of dollars on a product without doing even a basic research about it, you are 100% responsible of the outcome.

Note that despite the title, the author is not switching from pyenv to uv, but from pip, pyenv, pipx, pip-tools, and pipdeptree to uv, because uv does much more than pyenv alone.

It replaces a whole stack, and does each feature better, faster, with fewer modes of failure.

If the libraries are meant to be used together, you can get away with one venv. If they should be decoupled, then one venv per lib is better.

There is not much to know:

- uv python install <version> if you want a particular version of python to be installed

- uv init --vcs none [--python <version>] in each directory to initialize the python project

- uv add [--dev] to add libraries to your venv

- uv run <cmd> when you want to run a command in the venv

That's it, really. Any bonus can be learned later.

There's also workspaces (https://docs.astral.sh/uv/concepts/projects/workspaces/) if you have common deps and it's possible to act on a specific member of the workspace as well.

That's one of the bonus I was thinking about. It's nice if you have a subset of deps you want to share, or if one dep is actually part of the monorepo, but it does require more to know.

Thanks. Why is the notion of run and tool separate? Coming from JS, we have the package.json#scripts field and everything executes via a `pnpm run <script name>` command.

Tool ?

Maybe you mean uv tool install ?

In that case it's something you don't need right now, uv tool is useful, but it's a bonus. It's to install 3rd party utilities outside of the project.

There is no equivalent to script yets, althought they are adding it as we speak.

uv run exec any command in the context of the venv (which is like a node_modules), you don't need to declare them prior to calling them.

e.g: uv run python will start the python shell.

I was looking at https://docs.astral.sh/uv/concepts/tools/#the-uv-tool-interf...

Edit: I get it now. It's like npm's `npx` command.

uvx is the npx equivalent, it's provided with ux, and also has some nice bonuses.

uv sync if you clone a github repo

uv run in the freshly cloned repo will create the venv and install all deps automatically.

You can even use --extra and --group with uv run like with uv sync. But in a monorepo, those are rare to use.

Thanks for the info.

I looked at the group documentation, but it's not clear to me why I would want to use it, or where I would use it:

https://docs.astral.sh/uv/concepts/projects/layout/#default-...

(I'm a JS dev who has to write a set of python packages in a monorepo.)

sync is something you would rarely use, it's most useful for scripting.

uv run is the bread and meat of uv, it will run any command you need in the project, and ensure it will work by synching all deps and making sure your command can import stuff and call python.

In fact, if you run a python script, you should do uv run python the_script.py,

It's so common uv run the_script.py will work as a shortcut.

I will write a series of article on uv on bitecode.dev.

I will write it so that it work for non python devs as well.

Did you mean group and not sync?

Really looking forward to the articles!

Sorry i misread and stayed on sync. Group and extras are for lib makers to create sets of optionals dependenacies. Groups are private ones for maintainers, extras are oublic one for users.

I miss dukto r5.