pytorch causes many headaches in the ecosystem, and a better handling of it is one thing their commercial offering, pyx, wants to fix: https://astral.sh/blog/introducing-pyx
Millenials here. We did. A lot of a lot. And nobody cared.
Even today on HN most use chrome instead of firefox and mac instead of linux and. If you can't even convince the biggest nerds that supporting alternatives is important, what chances do you have?
No single app has access to any data thanks to hardware-assisted virtualization. Last time a VM escape in the modern Qubes implementation was discovered in 2006 by the Qubes founder: https://en.wikipedia.org/wiki/Blue_Pill_(software).
I always wondered if, instead of using solar panels in the deserts, we could use very long and black pipes running water, heated by the sun. Then the heat is moved to the ground for storage, and once there is enough heat, we use a turbine to generate electricity.
I don't think you ever get enough of a temperature difference just by having a passive black pipe in the sun, to do any useful work besides potentially keeping someone warm in the winter. You could do useful work if you concentrate the energy from the sun somehow, like with mirrors.
Heat pumps do magic by changing the pressure at which a working fluid changes phase, so you can boil the fluid over here, have it absorb an enormous amount of energy then compress it back to a fluid elsewhere and push that heat back out -- this works pretty well because you're just moving the heat and only pushing the temperature on the "hot" side up a relatively small amount. I don't think, for instance, you could make an oven with heat pumps.
To do useful work you need a _substantial_ energy gradient -- it's hard to live in the sun even though its got lots of free energy floating around. The sun is very useful to the earth because the energy it provides is so much more energetic than the ambient environment.
Edited to add:
There are discussions of using exotic working fluids like compressed CO2 -- that'd allow you to manage the phase change maybe to a region where you could concentrate the energy in the fluid then expand it elsewhere at "room temperature" temperatures -- but I think things like compressed (to a _fluid_) CO2 are really hard to work with.
It's done a bunch, all over the place: https://en.wikipedia.org/wiki/Solar_thermal_energy. Most commonly people use them either for batch pre-heating of hot water or for full heating. I looked in to getting something like that for the hydronic heat in my house because currently it's propane-fueled and the deliveries are quite expensive in the winter.
Projects using AI are the best documented and tested projects I worked on.
They are well documented because you need context for the LLM to be performant. And they are well tested because the cost of producing test got lower since they can be half generated, while the benefit of having tests got higher, since they are guard rails for the machine.
People constantly say code quality is going to plummet because of those tools, but I think the exact opposite is going to happen.
The difference today is the docs are being read. In the before times, unless you were building a foundational library, docs would get updated when a presentation was needed to announce a great success, or maybe not even then. Nowadays if you want coding agents to be efficient, doc quality is paramount.
IOW there’s very clear ROI on docs today, it wasn’t so earlier.
Please don't berate other community members on HN, no matter how right you are or feel you are. HN is for curious conversation, not battle. Please make an effort to observe the guidelines in future.
uv run is using virtual envs, that's the de facto standard, and those are sandboxes for python deps. So it already is.
Plus inline deps mean you can pin python versions and 3rd party modules using pyproject.toml syntax in a comment of your script. This is not perfect locking, as it doesn't pin sub dependencies, but it's already more that any other tool out there.
If you want perfect locking, create a project, and use uv lock. You are already in a different category of code.
OP isn't talking about virtual environment style sandboxing, they're talking about sandboxes that prevent arbitrary code from deleting or stealing any information your user account has access to on your computer.
This has been attempted many times with python, and always been a failure because of the dynamism of the language, even by big actors.
The solution, therefor, as always been to use the OS tooling for that. Even the .Net ecosystem eventually went into that direction.
The JS ecosystem is making that mistake right now, and will of course, deprecate this API in 10 years after they realize they can't make it secure either unless they basically reimplement BSD jails entirely.
Docker isn’t a sandbox and shouldn’t be treated like one. Admittedly if I’m going to run untrusted code I’ll run it in Docker, but I’m aware that whatever I’m running could break out. I wouldn’t blindly run some bullshit even in Docker unless I’m 90% sure it’s safe already.
Docker's primary purpose is to give applications their own namespaces in which they can run without conflict. It does confine applications to their own root filesystem, own process namespace and so on, but this isn't intended as a security boundary. cgroup escapes happen.
Firecracker and gVisor provide much stronger isolation. Both are battle tested; clouds run millions of multi-tenant workloads on these every day. Docker would simply never even be a candidate for this purpose.
>but I’m aware that whatever I’m running could break out
If you have a working docker escape exploit at hand, that works on unprivileged containers, you can earn some good money. Just saying.
Docker was not created as a sandbox, but people rely on it for security and it is a sandbox at this point. Hell, containerd is one of kuberbetes backends and it absolutely relies on it being a secure sandbox.
