The Debian stable model of having a distro handle common dependencies with a full system upgrade every few years looks more and more sane as years pass. It's a shame some ecosystems move waaay too fast, or don't have a good story for having distro-specific packages. For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects. I might be wro…
The stable model usually implies that your app has to target both the old and the new distro version for a while. That is a bit too much to ask for some, unfortunately
I think there’s a much stronger argument for policies that both limit the number and complexity of dependencies. Don’t add it unless it’s highly focused (no “everything libraries” that pull in entire universes of their own) and carries a high level of value. A project’s entire dependency tree should be small and clean. Libraries themselves should perhaps also take a page from the book of Linux distributions and offer…
The lower level the dependency is, the more unjustifiable it is for it to have its own dependencies. This ought to be a point of competition between libraries and often is, at least in the c++ world
Isn't this more or less what the Microsoft Long-Term Support (LTS) versus Short-Term Support (STS) is meant to do? LTS only receives critical updates but eschews all experimental/beta features. STS gets everything for the people that couldn't care less if their app gets hacked (e.g. apps like calculators, sandboxed internal tools, etc). I know Ubuntu and others do the same but I don't know what they call their STS eq…
Depends which Microsoft products you're referring to. If you're talking about .NET versions, MS explicitly says "The only difference is the length of support."
> we should all Except if everyone does it chance of malicious things being spotted in source also drops by virtue of less eyeballs Still helps though in cases where maintainer spot it etc
(Author of the post.) The underlying premise here is that supply chain security vendors are honest in their claims about proactively scanning (and effectively detecting + reporting) malicious and compromised packages. In other words, it's not about eyeballs (I don't think people who automatically apply Dependabot bumps are categorically reading the code anyways), but about rigorous scanning and reporting.
Maybe it's more about mileage (attacks that actually happen) than eyeballs.
Also interesting to note that the author is involved with the uv python package manager, homebrew and is a member of pypa (Python Packaging Authority). Very impressive!
> No one can think that js has progressed substantially in the last three years Are we talking about the language, or the wider ecosystem? If the latter, I think a lot of people would disagree. Bun is about three years old. Other significant changes are Node.js being able to run TypeScript files without any optional flags, or being able to use require on ES Modules. I see positive changes in the ecosystem in recent y…
That is motion not action. The point of javascript is to display websites in the browser. Ask yourself, in the last three years has there been a substantial improvement in the way you access websites? Or have they gotten even slower, buggier and more annoying to deal with?
No but the devs can push slower, buggier, more annoying websites to prod, faster!
And after all, isn’t developer velocity (and investor benefits) really the only things that matter???
Some scattered thoughts on that: * If everybody does it, it won't work so well * I've seen cases where folks pinned their dependencies, and then used "npm install" instead of "npm ci", so the pinning was worthless. Guess they are the accidental, free beta testers for the rest of us. * In some ecosystems, distributions (such as Debian) does both additional QA, and also apply a cooldown. Now we try to retrofit some of…
"If everybody does it, " is rarely a good argument, because the premise rarely becomes reality.
So true.
Things that everybody does: breathe. Eat. Drink. Sleep. And a few other things that are essential to being alive.
For some reason everyone wants to talk about all the solutions to supply chain attacks except designing languages to avoid them in the first place. Austral[0] gets this right. I'm not a user, just memeing a good idea when I see it. Most languages could be changed to be similarly secure. No global mutable state, no system calls without capabilities, no manual crafting of pointers. All the capabilities come as tokens o…
One guy I vaguely know (only know him online, never met him IRL) often says "If you're using NPM you deserve what's going to happen to you one of these days." (He means the package ecosystem, so he would say the same thing about PNPM). I don't agree with him — he goes way too far with his opinion — but I can't deny that he's at least partly right. Two major supply-chain attacks in the past month (Shai-Hulud, and that tea-farming attack earlier this month which AFAIK doesn't yet have a clever name) have served to demonstrate that he definitely has a point in there, even if he takes it too far. NPM has a long way to go in terms of hardening (they've started doing so, thankfully), and is a very popular target.