this post was submitted on 08 Jan 2025
87 points (97.8% liked)
Privacy
32654 readers
469 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It is slow. Syntax & community idioms suck. The package ecosystem is a giant mess—constant dependency breakage, many supply-side attacks, quality is all over the place with many packages with failing tests or build that isn’t reproducible—& can largely be an effect of too many places saying this is the first language you should learn first. When it comes to running Python software on my machine, it always is the buggiest, breaks the most shipping new software, & uses more resources than other things.
When I used to program in it, I thought Python was so versatile that it was the 2nd best language at everything. I learned more languages & thought it was 3rd best… then 4th… then realized it isn’t good at anything. The only reason it has things going for it is all the effort put into the big C libraries powering the math, AI, etc. libraries.
that's an oversimplification.
python is slow because it's meant as glue; all the important parts of the ml libraries are written in other languages.
all the dependency stuff is due to running outside of a managed environment, which has been the norm for 10 years now. yes venv/bin/activate is clunky, but it solves the problem.
also, what supply-side attacks?
lua is probably a better first language though.
Meant to be glue but is used in all sorts of places it probably shouldn’t. The way libraries are handled & pinned leads to lots of breakage—a couple applications I have overlays to disable testing since stuff gets merged into Nixpkgs with failing tests so frequently that I is better to just turn it off & deal with failures at runtime.
The ultralytics thing was massive last month https://snyk.io/blog/ultralytics-ai-pwn-request-supply-chain-attack/. These have been coming with regularity—even worse than npm.
I would at least agree Lua is a better place to start—at least for a dynamic scripting language. It is not a complicated language & it even supports tail recursion which you can’t say about far too many languages.
python dependencies, like all scripting language dependencies, must not be installed via the system package manager. yes python's package management is bad, but if package maintainers for nix are not following best practices then honestly that's their problem, not the tooling's. this is python packaging 101.
also, malicious PRs being accepted due to ml people being famously bad at actual software engineering is not a "supply chain attack". and they are definitely not worse than npm, because the problem wasn't in pypi. pypi is historically really good at preventing this sort of thing, but what can you do when the actual, well-formed release approved and pushed by the actual maintainers has a cryptominer in it?
Wat. You are saying you can’t package Python application on a system level? That means the language’s package managament is broken. Nix unlike most package managers can do a reasonable job juggling multiple version of packages at the same time & stuff still breaks, & more frequently than anything in any other language other than Haskell.
There was also the SolarWind attack, Colorama, JarkaStealer, Cobo, pywx, Dropbox, PyTorch 2023. Zero-days galore.
you can, you just need to use the built-in tooling to build a self-contained application like a zipapp. if package maintainers did that it would break less. but they don't, and the problem there is how big the packaging tooling is.
like, imagine trying to install a js-based program the same way as you describe, pulling each dependency from apt. it would break immediately.
also, none of those listed ones used the package index as the vector. solarwind had their own infrastructure compromised, colorama was a typosquatting attack, jarkastealer was malicious from the word go. the list goes on, none of these are packaging system failures.
he problem npm has had for ages is that people are taking over legitimate packages and adding malicious code into them downstream from development using npm, and that the js ecosystem favours many small dependencies which makes the attack surface huge.
now, if all of those you listed was due to revival hijacking it would be pypi's problem, but that only works if the original dev removes their package. as it is, all of it is upstream of pypi. it's bad opsec by the devs.