←back to thread

441 points longcat | 1 comments | | HN request time: 0s | source
Show context
f311a ◴[] No.45038992[source]
People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year.

This week, I needed to add a progress bar with 8 stats counters to my Go project. I looked at the libraries, and they all had 3000+ lines of code. I asked LLM to write me a simple progress report tracking UI, and it was less than 150 lines. It works as expected, no dependencies needed. It's extremely simple, and everyone can understand the code. It just clears the terminal output and redraws it every second. It is also thread-safe. Took me 25 minutes to integrate it and review the code.

If you don't need a complex stats counter, a simple progress bar is like 30 lines of code as well.

This is a way to go for me now when considering another dependency. We don't have the resources to audit every package update.

replies(17): >>45039115 #>>45039225 #>>45039464 #>>45039724 #>>45039994 #>>45040021 #>>45040056 #>>45040113 #>>45040151 #>>45040162 #>>45040972 #>>45041479 #>>45041745 #>>45044165 #>>45045435 #>>45045983 #>>45052913 #
coldpie ◴[] No.45039464[source]
> People really need to start thinking twice when adding a new dependency. So many supply chain attacks this year.

I was really nervous when "language package managers" started to catch on. I work in the systems programming world, not the web world, so for the past decade, I looked from a distance at stuff like pip and npm and whatever with kind of a questionable side-eye. But when I did a Rust project and saw how trivially easy it was to pull in dozens of completely un-reviewed dependencies from the Internet with Cargo via a single line in a config file, I knew we were in for a bad time. Sure enough. This is a bad direction, and we need to turn back now. (We won't. There is no such thing as computer security.)

replies(12): >>45039683 #>>45039767 #>>45039803 #>>45039880 #>>45042370 #>>45043322 #>>45043362 #>>45045627 #>>45045717 #>>45046052 #>>45046055 #>>45046709 #
rootnod3 ◴[] No.45039683[source]
Fully agree. That is why I vendor all my dependencies. On the common lisp side a new tool emerged a while ago for that[1].

On top of that, I try to keep the dependencies to an absolute minimum. In my current project it's 15 dependencies, including the sub-dependencies.

[1]: https://github.com/fosskers/vend

replies(2): >>45039849 #>>45039853 #
skydhash ◴[] No.45039849[source]
Vendoring is nice. Using the system version is nicer. If you can’t run on $current_debian, that’s very much a you problem. If postgres and nginx can do it, you can too.
replies(4): >>45040065 #>>45040128 #>>45040130 #>>45042347 #
exDM69 ◴[] No.45040130{4}[source]
The system package manager and the language package/dependency managers do a very different task.

The distro package manager delivers applications (like Firefox) and a coherent set of libraries needed to run those applications.

Most distro package managers (except Nix and its kin) don't allow you to install multiple versions of a library, have libs with different compile time options enabled (or they need separate packages for that). Once you need a different version of some library than, say, Firefox does, you're out of luck.

A language package manager by contrast delivers your dependency graph, pinned to certain versions you control, to build your application. It can install many different versions of a lib, possibly even link them in the same application.

replies(1): >>45040379 #
skydhash ◴[] No.45040379{5}[source]
But I don’t really want your version of the application, I want the one that is aligned to my system. If some feature is really critical to the application, you can detect them at runtime and bailout (in C at least). Most developers are too aggressive on version pinning.

> Most distro package managers (except Nix and its kin) don't allow you to install multiple versions of a library

They do, but most distro only supports one or two versions in the official repos.

replies(1): >>45044828 #
1. rcxdude ◴[] No.45044828{6}[source]
Maybe you want that, but I generally want the version of the application that the devs have tested the most. I've dealt with many issues due to slight differences between dependency versions, and I'd rather not provoke them. (That said, I do like debian for boring infrastructure, because they can keep things patched without changing things, but for complex desktop apps, nah, give me the upstream versions please. And for things I'm developing myself the distro is but a vehicle for a static binary or self-contained folder)