Comment by vineyardmike | Hacker News Reader

Comment by vineyardmike | Hacker News Reader

My experience is pretty similar for my projects but I think generally we shouldn’t point too many fingers. When it comes to public projects, I’ve found a lot of trouble regardless of its JavaScript-proximity. I think we’ve been blessed by a growing ecosystem of projects that are clean to build, and eschew problematic dependencies. Try building anything Linux and C related and you’re worse than JS because now you need to modify libraries across your operating system not just NPM project.

Tonight, I tried simply compiling an example super-high-profile project that recently reached 1.0 (Matter protocol impl). It took me an hour of chasing down Linux dependencies to build on my Ubuntu server, while I gave up on building on my mac altogether after comments on issues suggested sym-linking various homebrew packages around my system.

We are still new at experiencing docker-packaged projects, and there’s few heavily used tools that work well. Many big companies have solved this problem internally, but not out in the wild. HN has often discussed GUIX or NIX systems, but I’ve yet to see a “real” open source project that uses anything but make/docker or language specific tools (npm, cargo, etc).

Yeah, people are jumping the horse to claim any dev environment is superior and free of issues like this. I've contributed to some open source C++ projects and a lot of js/node projects, and in my experience, every C++ project is an adventure just to get the project compiling (it can be smooth running if the maintainers have a recently-updated guide specifically for your exact OS/distro version and the right versions of all the dependencies are in your distro's package manager, but anything off of this happy path is an ordeal, especially the case where you're working on another C++ project that wants a different version of the same dependency) while nearly every js/node project was up and running after just "npm install". Sure, it can go wrong and harder than that sometimes but it's worth appreciating that the standard case is pretty good.

Every project using native binary dependencies is prone to running into the kinds of dependency issues described in the OP article. I've run into similar situations with Java, PHP, and Python where there was some mismatch with a language library, a native binary, and my OS. I'm a fan of it when projects try to minimize their native binary dependencies for this kind of reason. Some js/node projects that have previously used a native binary dependency now use non-OS-specific WebAssembly binaries instead, which is great for how it removes potential issues.

My experience matches this.

If there is a native dependency, then moving major node versions or moving to arm can cause difficulties or straddling the python version the gyp build system is based on.

It's worlds easier than trying to insure your C/C++ build environment is prepped properly to build a binary.

Updating libraries is usually not too bad, even across major versions. But that can be a bit of a wormhole trying to get everything squared away and all versions updated. This seems to be particularly true since all major frameworks I've used have gone from snake case deps (framework-module) to @framework/module.

> I gave up on building on my mac altogether

osx is not linux. It has a gazillion of incompatibilities and most developers never test for it, so even if the code compiles, it's no guarantee it will work.

> Try building anything Linux and C related

"apt install libwhatever-dev" does it in most cases.

> docker-packaged projects

You mean completely insecure projects that most likely run an old and vulnerable openssl?

Yea macOS is never a guarantee but I’m always hopeful when they include Mac instructions in the readme.

I’ve found projects that use C++ or other older languages and meant for Linux still have a nightmare with building. The project I looked at had a bootstrap script, an initialization script, a pip installation, and 3+ different make-alternatives. Not uncommon even when apt works.

Docker is great but it’s only as secure as Linux can be. Yea it can have outdated SSL, but it’s just as likely that the thing you need depends on a particular version. Most projects don’t get versions updated unless it’s broke. IMO if something is a web service or generally at risk, you should not depend on the good-faith security being vended. Put it bend a secure network or proxy, Audit, etc. As the advice goes, don’t run your server on port 80 as sudo, but instead run behind NGINX.(modify for risk)

> The project I looked at had a bootstrap script, an initialization script, a pip installation, and 3+ different make-alternatives. Not uncommon even when apt works.

Seems like it was created by noobs. It happens. I guess it's not packaged in a distribution for a reason. A distro maintainer would tell them to fix that crap.

> but it’s just as likely that the thing you need depends on a particular version

No it's not likely. Openssl is a shared library that you can just replace with a version that has whatever fix. Unless you do rust/golang/docker/static linking… and the standard is to dynamically link.

Running vulnerable software is always a risk. You might think you secured it, but vulnerabilities can get chained.

Anyway I'm sure there are crappy softwares being written in any language. But the problem with js seems to be that even a state of the art one incurs such problems continuously because all dependencies are crappy.

Reply on news.ycombinator.com