> Honest question. Commons, Guava, Spring, and more seem to take this approach successfully (as in, the drawbacks are outweighed by the benefits in convenience, quality, and security) in Java.
Commons and Spring have spent significant effort to break themselves up in the past, and would probably come as aggregations of much smaller pieces if they could be started today with the benefit of hindsight.
Selling support/services as the maintainer of an open-source service was never a hard-nosed business proposition in the first place. It's like Amazon undercutting your fire station's bake sale.
Sealing is really not that difficult if you have access to the high pressure side. The hard part is identifying the location of the leak. In sum, this means that they have to absolutely nail it, on the first attempt, for the bottom part that is resting on the sea floor. If they can to that, the rest of the circumference will also be so good they don't have to even think about fixability.
> Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
Can you even imagine pypi or npm compromising ssh this way?
> Can you even imagine pypi or npm compromising ssh this way?
Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different?
I don’t even know the last time I exposed ssh to the open internet.
But the fact with npm or pypi you can be exploited just by running the software you’ve already installed because the dependencies are everywhere on your system?
> Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different?
I see ssh as a very fundamental part of the system - in BSD terms it's in base not ports. Random packages from npm or pypi, sure, if you installed some slop off the internet and got exploited that's not so surprising. (Even those package managers themselves are not part of the base system, much less anything you install with them). But ssh should be safe!
No. Decent packaging systems like used in the Java world have deterministic or mostly-deterministic dependency resolution; semi-decent packaging systems like the ones you mention have lockfiles. Pre-uv Python packaging is uniquely awful.
You don't need them. Maven has deterministic dependency resolution (unless you use version ranges, but don't do that), so you just write your dependencies. (The flipside is you may want to get in the habit of doing something like versions:use-latest-releases as a regular housekeeping task so that you pick up any security updates, but that tends to be less of an issue in Java-land for other reasons)
Why don’t I need them? I can’t make every third-party package do exact version pins and it’d be miserable if I could because then I couldn’t patch a transitive dependency faster than the upstream even if there’s a drop-in patch release which is 100% compatible.
Even if that worked, I’d also want hashes to avoid file modification, although that’s less of a concern for anything on Maven Central where the releases are immutable.
> I can’t make every third-party package do exact version pins
Every third-party package already uses exact version dependencies, you don't need to do anything.
> then I couldn’t patch a transitive dependency faster than the upstream even if there’s a drop-in patch release which is 100% compatible.
You can always override the transitive dependency version if you want to.
> I’d also want hashes to avoid file modification, although that’s less of a concern for anything on Maven Central where the releases are immutable.
It's not just Maven Central, there's a strong norm of releases being immutable everywhere. If you're worried about attacks, there's a plugin you can enable to check the GPG signatures.
> I ask because someone once told me this was illegal in the US; that a shop was allowed to display the sale price only for a larger quantity, but they had to honor the same price per unit if you only bought one.
No, WTF? That's not a thing, why would you even credit such obvious nonsense?
> If you do the research and decide you would benefit from a robot vacuum, compare different models to decide on the best fit for your needs, and then check prices at different stores and find that it's cheapest at Costco - then yeah I'd say you're saving money.
That sounds like you might well be spending more time than the money you're saving.
Or the bubble he was pumping hasn't popped yet. We won't be able to say how much of this capacity was actually "needed" until 10 years in the future, if ever.
People are getting real stuff done with the internet. But there were also a whole lot of overhyped companies that rightly crashed back in '99.
Once we've gone through the AI equivalent of the dot.com crash, will Anthropic still be scrambling for more capacity, or will they have more than they can profitably use, like the dark fiber we were left with last time?
Depends when it happens. I'm sure they'll take up whatever capacity is available.
At the moment computer providers are charging more for outdated H100 capacity now than when the H100s were new. That capacity is going to the smaller labs, not the frontier labs.
That hardware has already been depreciated financially so even if all those small labs disappeared it's not sending computer providers bankrupt - they can just cut prices and so long as they can charge more than electricity and maintenance they'll just keep them running.
Commons and Spring have spent significant effort to break themselves up in the past, and would probably come as aggregations of much smaller pieces if they could be started today with the benefit of hindsight.
reply