> I'm surprised their work was ever MIT-licensed instead of GPL.
The intent was for their work to be usable on non-GPL distributions and OSs (including the BSDs).
The new licence is pretty restrictive — proprietary platforms will just regurgitate it with LLMs, but other open ecosystems will have to re-invent things from scratch.
sudo.rs is a really weird direction for an evolution — it re-implements a complex piece of security dropping some arbitrary choices but keeping it pretty complex. It has the exact same security model. I honestly can't understand the appeal.
If you want something similar but simpler, go for doas.
If you need all the features in sudo, keep using sudo.
If you want to try new security models, try s6-sudo, or any other of various tools out there.
sudo-rs keeping the same name is actually a worse breakage — because it doesn't have the same API as sudo (as described by op), but has the same name and pretends to be a drop-in replacement while also not being a drop-in.
The virtues being signaled are trust, reliability, and generosity. The mechanism is rust-washing. Like greenwashing, rust-washing has the appearance of and takes credit for the virtues without actually delivering on them.
People who work at Facebook and complain about this strike me as incredible naive. They work for the devil in exchange for huge sums of money, but are then shocked that the devil partakes in devious acts.
Neither leaving in protest nor staying would really change much. As long as someone is willing to do the dirty work, it'll continue to get done.
In Russia, all banks I tried, are usable via web app (because smartphone apps live only 1-2 months before they are detected and removed from app stores). The disadvantage of a web app is that it is not always-on, doesn't allow tracking users are well as a real app, and cannot display advertisement notifications.
EU regulations require banks to require confirmation in an app with device and app integrity verification. They don't specify what that means but they have to do it. SMS 2FA is temporarily allowed for the transition period.
Apps are not required to use the Play Integrity API or a similar attestation API. The details of what they're required to do are unspecified and open ended. Many are interpreting it as meaning they use the Play Integrity API and we have to convince each one to permit GrapheneOS via the Android attestation API. It's not good and we would greatly prefer if this wasn't happening even if we were managing to convince most apps to permit GrapheneOS.
I'm don't see "allow GrapheneOS" as a great difference: the bank is still only permitting transactions on devices controlled by a third party and not by the owner. I don't want to change the third party that controls the device. I want to use my own device.
I dislike the idea of these separate tools being blended like this. ty is currently perfectly usable on non-uv projects. uv has *a lot* of opinionated quirks, its custom lockfile lockfile, and other nuances which many of us dislike — ty being a separate tool works fine with plain pip plus any other dependency manager (e.g.: pip-tools).
Of note though, ty doesn't NEED to be integrated into uv, nor vice-versa; keeping them as standalone tools seems most natural.
This shouldn't be surprising. Astral has wanted to create lock-in with uv for years and obviously they'll want to bring everyone into their "ecosystem" as much as possible. Stand by for more divergences from main python or use of their "market" capture for leverage over it.
It's not something I really relate to, having working on a fairly large project with significant dependencies that is used as both a library and an application. I see uv often used just to try to paper over bad dependency and compatibility management, which ends up being self-reinforcing. I guess if it's being used strictly for final deployment, sure, but that doesn't (shouldn't) remove the need to pay attention. It's hard for me to see it as anything but an attempt to eventually make the state of Python tooling be "everything breaks, unless you use uv by Astral™"
Maybe? I still don't really fully understand what issues people had with it unless they'd only ever used the system python installation for everything.
I found Python tooling completely ok before uv. I quite liked it when it was rye, the features are good, and they’re better now in uv no question. But ultimately I was getting everything I needed using asdf to install python versions and then python -m venv to create virtual environments. Then I’d activate and just use pip.
The uv workflow is better but if the day comes when it becomes a problem due to astral lock-in or whatever may happen it’s ok (as long as those old tools exist..)
uv just turned 3, so "years" feels like a stretch. And I think lock-in is not and has never been a goal of the project. uv generally bends over backwards to conform to Python packaging standards because the people who work on uv also tend to work on those standards. The places where it doesn't (like uv.lock) are because the standards can't express exactly the things uv wants.
(Note: I work on both uv and Python packaging standards.)
I'd imagine that, for a substantial percentage of these, part of it is to avoid negotiating and bargaining over an additional tool in your CI arsenal, especially in bigger corporate environments where these sort of conversations are dragged through layers of non-technical middle management.
Ty isn't a compelling option. If you want support for dynamic libraries, mypy is king. If you want speed and strict conformance, Pyrefly and Zuban are better.
Ty's original pitch was that it would have strong inference and be useful for gradually typing existing, untyped codebases, but AI made that moot. Adding types to existing code is now trivial.
I think part of ty's pitch is also that it's very simple to set up. I think only Pyright compares in this regard. I tried Pyrefly once and recall it being a bit more involved to start using.
They're all CLI tools and they all support LSP. The only setup advantage here is Pylance's, by virtue of shipping with VS Code. Other tools take two clicks to enable, plus or minus typing the tool's name into a search bar.
> keeping them as standalone tools seems most natural
It's natural to us, purists, but I doubt people care. Everyone wants a single tool that allows them to `uv check` and `uv run` in every project without having to install anything.
It depends. A lot of popular software is relatively new and is subject to frequent upgrades: the rust ecosystem, uv, and mise to name a few. Even the distro’s own Python, Ruby, and Java runtimes are rarely used for software development.
Old timer here: uv is not the first opinionated tool to manage Python packaging. It is build learning from other tools right and wrongs. I now use uv for everything because its quirks are less disruptive than quirks from previous tools that I also tried and disliked for being a bit too much for a very small gain.
What you call "dumpster fire", I call "steps towards uv", maybe even better tools in the future.
The only major opinionated tools that were in use prior to uv were Conda, Pipenv and Poetry (- ignoring pip here, as it's mainly a package installer). None of them contributed towards PEP 518 (Conda significantly predated it, and Pipenv actively created a competing format even though the PEP already was accepted).
Most of the lessons that make uv good can be directly traced back to Cargo (which in turn can be traced back to Bundler). The main portions from the Python side that helped it have a good foundations were standards work (PEPs), none of which were driven by the people behind any of the three "major" package managers.
Until uv, I used docker to run python projects locally. Got so fed up with venvs and versions and slowness and lack of wheels and spending so much time mucking around with it when cloning or updating a repo.
Uv hasn't fixed all issues, but made it far less painful.
When you do apt install, the maintainer made sure that the correct versions of whatever dependency was indeed available. That's the entire point of a distribution.
And pipenv, or just literally manually creating a venv. Uv didn't invent that, it's winning on speed mainly, and then capitalising on starting with a base that includes multiple general improvements in the Python ecosystem.
You can also just do "uv run", and it will automatically sync as necessary!
I think that's one of the things that uv does great and often goes unnoticed: It's hard to use wrong for a layman. Forgetting to run the equivalent sync command in most other Python package mangers could have resulted in a myriad of different bugs caused by out of sync packages, leading to hours of wasted debugging.
> In a uv project I can just git clone, cd, uv sync and I am ready to go. Nothing in the python ecosystem offered that before.
`poetry install` does the same thing except for downloading Python.
I transitioned from Poetry to uv. Other than being mildly faster and providing workspaces, uv doesn't really change at all how one interacts with and manages a project. And in fact, uv just adds additional quirks and gotchas and limitations, including storing authorization keys in plain text.
uv also duplicated things in the Python ecosystem but then didn't implement the same feature sets, so you often end up needing to call the existing tool, just like you did in Poetry.
I suspect, that lots of people hyping uv didn't have any proper reproducible project setups beforehand and didn't have to find solutions to that before uv. If they had, they would know about Poetry and how to use it.
I am of the same opinion, that uv didn't actually change all that much, if you have a sane project setup. I don't do anything with it, that I didn't do before with Poetry and before that with Pipenv. What I need is a way of installing dependencies, checked against a lock file, reliably. Poetry does that. If uv disappeared today, I would go back to Poetry and wouldn't miss all that much.
But there are the people who want to write one-off scripts with loosely defined dependencies inlined into the scripts. I don't do that. I would just copy my Makefile and pyproject.toml file from another project and adjust it and then run the script just as well with locked dependencies. Why do anything less. If I want to be really sloppy, I can just pip install.
I tried really hard to do things the right way before uv, but it was just a major PITA. Poetry in particular looked really exciting when I first discovered it, but I eventually just got bogged down with the speed and its inability to resolve dependencies even for recent versions of pretty mainstream packages. It didn't 'just work' once you got beyond toy projects.
I admit I hadn't really realised astral was a private company before though. What is their roadmap for monetising all this work?
Hm, that's strange. I have used Pipenv and Poetry years ago, to reproducibly build data science environments that people used to learn about data science and data analysis. I don't think you can call that "toy projects". I guess you just had bad luck with some specific dependencies. What I do remember though is, that Poetry had far fewer problems than Pipenv had. Pipenv was still a fight, though I won every time one way or another.
Yea, it's interesting. My comment is negative in votes, but I went back to it to see. Everything I said is factual, so I don't know. People are endlessly impressed by uv's whizbang speed, it seems. In reality, it's _yet another tool_ trying to reinvent the Python ecosystem.
While I agree in spirit, this also makes the resolver away from being able to claim they're just a neutral service which just delivers existing records without being opinionated
Fair point. I'd say "We're neutral, unless you attack us, in which case we stop being neutral about you, in particular". I'd still use them if this were the policy.
I can't help but imagine that the sort of user choosing to use a service like this in lieu of their ISP default is also likely to support this bit of pain.
...also, it's probably their own PlayStation, that their kid uses. Speaking from personal experience.
I mean if they're getting sued for failing to block proxy/vpn services they're being told to be opinionated and they can't be a neutral service. "You asked us to be opinionated about traffic, so we're doing that. Do you want us to go back to being neutral?"
That ship sailed. The court unequivocally determined that the resolver is not a neutral party, and their ruling explicitly demands that the resolver not be neutral.
A domain owner can publish DANE DNS records with details on the certificate and/or CA used for the domain. With DANE, if a misbehaving CA emits a certificate for your domain, it won't be valid since that certificate doesn't match what you're declared as permitted. This is further solidified with DNSSEC.
Regrettably, none of the major browsers implement DANE, so if any CA emits a certificate for your domain, they'll trust it implicitly.
> Amazon's Fair Pricing Policy lets it remove the Buy Box (the "Add to Cart" button), or even suspend a seller, if they're offering their item cheaper elsewhere.
This kind of abusive practice needs to be banned in whichever countries it's still legal.
You can't really aspire to improve the situation if such things continue to be legal.
Isn't this like Costco requiring manufacturers to offer SKUs at Costco that are not sold anywhere else? Or mattress stores offering to match price knowing full well that the SKUs in their store are not sold elsewhere?
This policy feels like incentive enough for Chinese manufacturers to not build behind a single brand, so the policy will not apply. Materially the same product, different SKU under a different brand name.
Yes, Costco's proprietary program has different rules from Amazon's proprietary program. This is obvious.
I am suggesting that for a manufacturer larger than the very smallest, compliance is simple. They just create another SKU (or brand) and sell it for less off Amazon. Voila, the customer cannot purchase the same product for less money off of Amazon.
Why should it be illegal? Its their platform. If enough sellers don't like it and leave then Amazon will have to change their policy. There's several other platforms people can sell their stuff on.
Yes, because “free” market deregulation has worked out so well for consumers over the last 30 years.
“Don’t like the monopoly? You’re free to go elsewhere. No wait, there is no elsewhere. Oh well, I guess you must like it here then since you keep coming back. “
That part is fine. The fact that Amazon controls their vendor's pricing across the rest of their channels is a major issue though. It's price fixing tbh.
I really don't understand this monopoly argument at all for Amazon. What category of product is sold there, but nowhere else? Between big box stores, Wal-Mart, Target, eBay, B&H, local stores, independent online stores. I don't feel at all that I'm forced to shop at Amazon for lack of choice. Is this an American thing?
Because its a collective action problem. Being on Amazon is the least bad option for any individual business even though they would all be better off if they left simultaneously. IMO a primary purpose of market regulation should be to counteract these types of problems so that the market can move itself out of a local maxima and become more efficient overall.
mkdocs still uses "web fonts" for icons. This hack was required for compatibility with Internet Explorer, but is just cargo-culting these days. It's an accessibility issue in that users who disable web fonts (for readability) don't see icons, they just see unicode placeholders everywhere ("tofu").
It's mostly the default ssh-agent that has a different security model.
reply