What is your evidence for this: "... because of structural problems that push them out, be that systemic misogyny in our educational systems ..." , "the toxicity present in the industry that pushes them out ... "?
They presumably didn’t write an entire literature survey in an HN comment because the CS pipeline problem has been written about so much in the past that it’s reasonable to assume basic familiarity:
I mean there's reams of women in tech or academia who talk about this shit. "I left my PhD program because I was constantly belittled and harassed by my advisor and labmates" "I left my position for a different company because I kept getting passed over for promotion after I had kids" "I switched majors from CS in college because most of my classmates were men who made me uncomfortable" "I was bullied in high school by boys because they thought I didn't get accepted into school based on merit". These are all stories I've heard and there are many of them. Go ask some women in your workplace and I'd bet money they've heard stories like this from other women they know or have experienced it themselves. I'm a man and I'm tired of hearing the contrarian denials regarding these problems from my peers in the industry. Maybe every woman I know in the industry experiencing sexism at some point in their education or career is too anecdotal for you I guess.
I'm sure there's studies in labor and education stats to show some quantitative evidence of this stuff but I'm not going to waste my time proving the obvious to you.
I don't think it's our responsibility to educate you about a phenomenon that has been discussed, analyzed, and written about extensively over the past couple decades. If you haven't seen evidence of this, then you've been living under a rock.
UV is super fast and great for environment management, however it's not at all well suited to a containerised environment, unless I'm missing something fundamental (unless you like using an env in your container that is).
uv works great in a container, you can tell it to skip creating a venv and use the system's version of Python (in this case, let's say Python 3.14 from the official Python image on the Docker Hub).
The biggest wins are speed and a dependable lock file. Dependencies get installed ~10x faster than with pip, at least on my machine.
> unless you like using an env in your container that is
A virtual environment, minimally, is a folder hierarchy and a pyvenv.cfg file with a few lines of plain text. (Generally they also contain a few dozen kilobytes of activation scripts that aren't really necessary here.) If you're willing to incur the overhead of using a container image in the first place, plus the ~35 megabyte compiled uv executable, what does a venv matter?
This is still a complete pain to work with. Virtualenv in general is a "worst of worlds" solution. It has a lot of the same problems as just globally pip installing packages, requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups. It's one of the reasons I would recommend against python for much of anything that needs to be "deployed" vs throw away scripts. UV seems to handle all of this much better.
I'm intrigued. I've been using virtualenv in numerous companies for about 8 years, traditionally wrapped in virtualenvwrappers, and now in uv.
UV doesn't change any of that for me - it just wraps virtualenv and pip downloads dependencies (much, much) more quickly - the conversion was immediate and required zero changes.
UV is a pip / virtualenv wrapper. And It's a phenomenal wrapper - absolutely changed everything about how I do development - but under the hood it's still just virtualenv + pip - nothing changed there.
Can you expand on the pain you've experienced?
Regarding "things that need to be deployed" - internally all our repos have standardized on direnv (and in some really advanced environments, nix + direnv, but direnv alone does the trick 90% of the time) - so you just "cd <somedir>", direnv executes your virtualenv and you are good to go. UV takes care of the pip work.
Has eliminated 100% use of virtualenvwrappers and direct-calls to pip. I'd love to hear a use case where that doesn't work for you - we haven't tripped across it recently.
Not quite; it reimplements the pip functionality (in a much smarter way). I'm pretty sure it reimplements the venv functionality, too, although I'm not entirely sure why (there's not a lot of room for improvement).
("venv" is short for "virtual environment", but "virtualenv" is specifically a heavyweight Python package for creating them with much more flexibility than the standard library option. Although the main thing making it "heavyweight" is that it vendors wheels for pip and Setuptools — possibly multiple of each.)
> It has a lot of the same problems as just globally pip installing packages
No, it doesn't. It specifically avoids the problem of environment pollution by letting you just make another environment. And it avoids the problem of interfering with the system by not getting added to sys.path by default, and not being in a place that system packages care about. PEP 668 was specifically created in cooperation between the Python team and Linux distro maintainers so that people would use the venvs instead of "globally pip installing packages".
> requires a bit of path mangling to work right, or special python configs, etc. In the past, it's also had a bad habit of leaking dependencies, though that was in some weird setups.
Genuinely no idea what you're talking about and I've been specifically studying this stuff for years.
> It's one of the reasons I would recommend against python for much of anything that needs to be "deployed" vs throw away scripts. UV seems to handle all of this much better.
This is actually what I'm talking about .. Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application? That model makes it significantly harder to manage multiple applications/utilities on a machine, particularly if they have conflicting package versions etc. Being able to scope the dependencies to a specific code base without having to duplicate the rest of the python environment would be much better than a new virtualenv.
> Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application?
If you haven't before, I strongly encourage you to try creating a virtual environment and inspecting what it actually contains.
"A whole new Python environment" is literally just a folder hierarchy and a pyvenv.cfg file, and some symlinks so that the original runtime executable has an alternate path. (On Windows it uses some stub wrapper executables because symlinks are problematic and .exe files are privileged; see e.g. https://paul-moores-notes.readthedocs.io/en/latest/wrappers.... .) And entirely unnecessary activation scripts for convenience.
If you wanted to be able to put multiple versions of dependencies into an environment, and have individual applications see what they need and avoid conflicts, you'd still need folders to organize stuff and config data to explain which dependencies are for which applications.
And you still wouldn't be able to solve the diamond dependency problem because of fundamental issues in the language design (i.e modules are cached, singleton objects).
When you make a virtual environment you don't do anything remotely like "duplicating the rest of the Python environment". You can optionally configure it to "include" the base environment's packages by having them added to sys.path.
> Why do I need a whole new python environment rather than just scoping the dependencies of an application to that application?
But… that’s what a virtualenv is. That’s the whole reason it exists. It lets you run 100 different programs, each with its own different and possibly conflicting dependencies. And yeah, those dependencies are completely isolated from each other.
I think his point is that you could have just had a situation where multiple versions of the same dependency could be installed globally rather than creating a new isolation each time.
I haven’t really had this issue. UV’s recommendation is to mount the uv.lock and install those manages package versions to the container’s global pip environment. We haven’t had much issue at my work, where we use this to auto-manage python developer’s execution environments at scale.
Nice tricks! I wasn't aware of the cache mounts, so I was building with UV_NO_CACHE=1. Cache mounts should also come handy when installing OS packages in multi-stage builds.
I still couldn't find the "global pip environment" part, unless by that you meant the "active pip environment", pointed by VIRTUAL_ENV during image building.
Mounting uv.lock doesn't actually work if you have intra-repository dependencies. UV can't deal with packages that lack metadata (because it's not mounted): https://github.com/astral-sh/uv/issues/15715
I am extremely skeptical about this sort of thing - I suspect that it's extremely challenging to reliably make assertions about the carbon cost of running a given website given that there are so many unaccountable-for variables; at best the very "edge" of any carbon usage is being guessed at.
Added to that the opportunities for charging the various parties for "certification" are simply too good to pass up it seems.
Yes, but one does not have to reliably make assertions to feed a meme.
People want to be good. The current agenda God says you are good if you sacrifice to the CO2 god. No need to make reliable assertions to feel good about it. Anyone who challenges the act of sacrifice is someone to burn. No challenge means no problems.
Anyone who wants to see both sides of the Co2 discussion is already sceptical at minimum. But it does not make you feel good. Therefore its rare. It feels good to sacrifice to the Co2 god. “Lemme sacrifice you fool.”
This project doesn't seem to care whether I'm sending data to someone else right near us-east-1 or whether I'm sending data to Australia. The energy costs will be very very different.
Not only is it measuring bytes blindly, it's counting rating your energy use as a % of bytes sent, versus total data-center consumption period. As though every byte is equally responsible for the total computing done. Absurdly wrongheaded model.
> In common with other on-premise servers, this terminal server was protected by firewalls and virus software, but access was not subject to Multi-Factor Authentication (MFA).
Not on board with this, other than the advantages that solutions like Pulumi have over 2nd gen IaC tooling like TF.
Pulumi is far more extensible and composable than anything else I've seen out there.
Pulumi is fantastic, just wish it was more popular honestly. That and how you have to handle async stuff with it feels kinda weird in the era of async await in JS.
But it's wild, our tech stack at the company I'm working at is Typescript all the way down. Frontend, Backend, Infrastructure is all typescript. Our team loves it. We also use serverless. Given the perspective in this thread I'm expecting downvotes but we love that too.
I think serverless is just like everything else. If you implement it poorly it can be slow, expensive, and pointless. If you implement it well it can be cheap, fast, and keep your team lean.
> Given the perspective in this thread I'm expecting downvotes but we love that too.
It's a sad commentary that this is the case on HN. People using down votes as lazy disagreements against an opinion they don't like is fundamentally anti hacker IMHO.
Absolutely insane amount of coordination and individual mission operations for each one simultaneously. I don't think enough gets said about SpaceX's launch integration systems.
“From a field near the village of Serooskerke, five V-2s were launched on 15 and 16 September, with one more successful and one failed launch on the 18th“
That must mean they launched at least 3 on either the 15th or the 16th.
That page also says “Beginning in September 1944, more than 3,000 V-2s were launched” and “The final two rockets exploded on 27 March 1945”, so that’s over 3,000 in at most 208 days, so there must have been days there were at least 14 “launches in a single day by the same entity”. I suspect the actual top number is a lot higher.
If you think that’s borderline “a single entity”, there’s “After the US Army captured the Ludendorff Bridge during the Battle of Remagen on 7 March 1945, the Germans were desperate to destroy it. On 17 March 1945, they fired eleven V-2 missiles at the bridge”
If I understand things correctly, this launch won’t (try to) complete an orbit, either. It will make a water landing after less than one time around the earth.
To be pedantic, this launch will have orbital velocity; if it was circular it would be orbital. IOW, it's an orbit that intersects the Earth. So it is orbital by some definitions but not by others.
Since October, Israel has launched at least 7,400 into Gaza.
Between June 1944 and March 1945 the Germans hurled 10,500 V-1s at Great Britain. Most of the missiles never reached their targets.
I couldn't easily find the # of rockets from the allies, though I'd guess it's a much smaller number, since they were delayed compared to Germany.
I couldn't find an easy # for the Ukrainian and Russian war.
So unless this latest disaster in Gaza ends soon, I'm betting they will handily beat the V-1 rockets.
Note: I'm not trying to side either way in this comment between any of the countries involved, All of the conflicts are a mess and I'm definitely not qualified to have an informed opinion.
A rocket that flies 50 km, or even 500 km, while reaching 2-3M and carrying 200 kg of payload, is a much, much simpler machine than a rocket that makes it to LEO and reaches about 26M while carrying several tons of payload. (And then deorbits and lands!)
The V-1 was not a rocket; it was a “flying bomb” powered by a jet engine, what we would today call a “cruise missile”, except cruise missiles tend to have guidance systems. The V-2 was the rocket.
If you’re going to count the rockets in the Gaza conflict (which are predominantly fired by Hamas and PIJ against Israel) or the rockets being used in Ukraine, those aren’t nearly as sophisticated as even the V-2. Those systems are more analogous to the Soviet “Katyusha”. There were different Katyusha variants, but one of the most common was the BM-13, which could fire a salvo of 24 rockets from a truck before being reloaded. Thousands of Katyushas were produced, so I’m pretty sure they account for hundreds of thousands of rockets overall. Very similar to the Katyusha rocket (in fact, basically the exact same rocket for the Soviets at the time) are the rockets fired by airplanes and later helicopters at ground targets, so you could add those in as well.
And if you want to get downright pedantic and count every type of rocket, there are also various shoulder launched rocket launchers like the RPG which are extremely common. Guided missiles are also technically rockets. So the actual numbers are much, much, much higher than you think.
reply