I did that on purpose, i. e. I wanted to confirm your thoughts about uv, drifted off into a general rant, remembered OP’s original question and later realized it would have been better framed as a top level comment. In my defense, I was in an altered state of mind at the time.

pyenv and uv let you install and switch between multiple Python versions.

As for uv, those come from the Python build standalone project, if I remember correctly, pyenv also installs from there, but don’t quote me on that.

I moved all our projects (and devs) from poetry to uv. Reasons were poetry’s non standard pyproject.toml syntax and speed, plus some weird quirks, e. g. if poetry asks for input and is not run with the verbose flag, devs often don’t notice and believe it is stuck (even though it’s in the default project README).

Personally, I update uv on my local machine as soon as a new release is available so I can track any breaking changes. Couple of months in, I can say there were some hiccups in the beginning, but currently, it’s smooth sailing, and the speed gain really affects productivity as well, mostly due to being able to not break away from a mental “flow” state while staring at updates, becoming suspicious something might be wrong. Don’t get me wrong, apart from the custom syntax (poetry partially predates the pyproject PEP), poetry worked great for us for years, but uv feels nicer.

Recently, “uv build” was introduced, which simplified things. I wish there was an command to update the lock file while also updating the dependency specs in the project file. I ran some command today and by accident discovered that custom dependency groups (apart from e. g. “dev”) have made it to uv, too.

“uv pip” does some things differently, in particular when resolving packages (it’s possible to switch to pip’s behavior now), but I do agree with the decisions, in particular the changes to prevent “dependency confusion” attacks.

As for the original question: Python really has a bit of a history of project management and build tools, I do feel however that the community and maintainers are finally getting somewhere.

cargo is a bit of an “unfair” comparison since its development happened much more aligned with Rust and its whole ecosystem and not as an afterthought by third party developers, but I agree: cargo is definitely a great benchmark how project and dependency management plus building should look like, along with rustup, it really makes the developer experience quite pleasant.

The need for virtual environments exists so that different projects can use different versions of dependencies and those dependencies can be installed in a project specific location vs a global, system location. Since Python is interpreted, these dependencies need to stick around for the lifetime of the program so they can be imported at runtime. poetry managed those in a separate folder in e. g. the user’s cache directory, whereas uv for example stores the virtual environment in the project folder, which I strongly prefer.

cargo will download the matching dependencies (along with doing some caching) and link the correct version to the project, so a conceptual virtual environment doesn’t need to exist for Rust. By default, rust links everything apart from the C runtime statically, so the dependencies are no longer neesed after the build - except you probably want to rebuild the project later, so there is some caching.

Finally, I’d also recommend to go and try setting up a project using astral’s uv. It handles sane pyproject.toml files, will create/initialize new projects from a template, manages virtual environments and has CLI to build e. g. wheels or source distribution (you will need to specify which build backend to use. I use hatchling), but thats just a decision you make and express as one line in the project file. Note: hatchling is the build backend, hatch is pypa’s project management, pretty much an alternative to poetry or uv.

uv will also install complete Python distributions (e. g. Python 3.12) if you need a different interpreter version for compatibility reasons

If you use workspaces in cargo, uv also does those.

uv init, uv add, uv lock --upgrade, uv sync, uv build and how uv handles tools you might want to install and run should really go a long way and probably provide an experience somewhat similar to cargo.

Oh, please skip it. I watched the first season and I wish I could erase that experience from memory.

Yeah, no lubricants and the look / style factor - that was my conclusion as well.

As for maintenance, while a belt might last 3 times as long, that’s not really a factor, given the price difference between belts and chains.

Exactly, which is why I was trying to think of any actual reasons I might want a belt, except style.

Are there any other reasons I’d want this apart from the lack of oil and the decreased noise levels, the coolness factor and the tinkering itself?

Every single one is a valid reason in itself of course, but maybe there is more.

I’ll post some links, but it’s a pretty busy week for me already, so give me some time.

An interrupt is an input that can be triggered to interrupt normal execution. It is used for e. g. hardware devices to signal the processor something has happened that requires timely processing, so that real-time behavior can be achieved (for variable definitions of real-time). Interrupts can also be triggered by software, and this explanation is a gross oversimplification, but that information is what is most likely relevant and interesting for your case at this point.

The commands you posted will sort the interrupts and output the one with the highest count (via head -1), thereby determining the interrupt that gets triggered the most. It will then disable that interrupt via the user-space interface to the ACPI interrupts.

One of the goals of ACPI is to provide a kind of general hardware abstraction without knowing the particular details about each and every hardware device. This is facilitated by offering (among other things), general purpose events - GPEs. One of these GPEs is being triggered a lot, and the processing of that interrupt is what causes your CPU spikes.

The changes you made will not persist after a reboot.

Since this is handled by kworker, you could try and investigate further via the workqueue tools: https://github.com/torvalds/linux/tree/master/tools/workqueue

In general, Linux will detect if excessive GPEs are generated (look for the term “GPE storm” in your kernel log) and stop handling the interrupts by switching to polling. If that happens, or if the interrupts are manually disabled, the system might not react to certain events in a timely manner. What that means for each particular case depends on what the interrupts are being responsible for - hard to tell without additional details.

It’s not like Bluetooth started demanding location permissions, the conceptual model of the permission was revised: having access Bluetooth means an app could determine your location via a form of lateration.

In earlier versions of smartphone operating systems, this was not transparent to users lacking the technical background, so Bluetooth also requiring location access is actually an attempt at making users aware of that. I’m not an iOS developer, so I can’t comment on iPhones, but on Android versions prior to 11, having access to Bluetooth meant an app would be able to determine your location.

Today, you can require the permission ACCESS_FINE_LOCATION, which expresses that your app might use Bluetooth to obtain location information on Android. Also, if you’re just scanning for nearby devices to connect your app to, but don’t want users to be confused why your smart fridge app needs to know your precise location, you can declare a permission flag (neverForLocation) and Android will strip beacon information from the scan results, better asserting your intentions.

So, overall: no, there is nothing nefarious going on, it was always possible to determine your location via Bluetooth, and the update to the permission model was an honest improvement that actually benefits you as user.

Now, there are still plenty of shady apps around, and apps that are poorly written - don’t use those.

honey bees are bad for pollinators

Hm? What do you mean?

From this paper:

A. mellifera appears to be the most important, single species of pollinator across the natural systems studied, owing to its wide distribution, generalist foraging behaviour and competence as a pollinator.

This is a genuine question btw.

From the article:

AMD also confirmed the vulnerability and said that the flaw had already been documented and tracked as CVE-2022-23824. It is worth noting that AMD’s advisory includes Zen 3 products as beeing affected, which are not listed in ETH Zurich’s paper.

If I remember correctly, you should be able to just install the GitHub version.

Honestly, if you’re in the audience for Thunderbird on Android, you probably also want to have a look at FairMail instead.

Edit: phrasing

I shudder to think OP’s post was written by an actual person…

What’s a good way to financially support artists directly, without involving shady corporations, and without resorting to piracy?

Jokes on you, I look her up once a year to see what she ended up doing. I’m 100% her name is Danielle.

Yes. You have to go and look for business display panels, e. g. those used for menus in restaurants, fast food chains, display stands etc.

But it’s not just information, someone sat in front of their computer and put the work in to design it, then print it and iterate.

You’re paying for that process, and for the time and effort the person took to acquire the necessary skills.

However, there should be a noticeable price difference due to the easy scaling / replicatibility when distributing digital goods.

I’m with you insofar as the final product feels like it should be 3 bucks, not the file.

This, however, is about diagnostics, i. e. annotating delete with a reason (message) to express developer intent when deleting a function, not about memory management.