Hacker News Reader

Comment by j1elo | Hacker News Reader

Easy example that I know of: the Mediasoup project is a library written in C++ for streaming video over the internet. It is published as a Node package and offers a JS API. Upon installing, it would just download the appropriate C++ sources and compile them on the spot. The project maintainers wanted to write code, not manage precompiled builds, so that was the most logical way of installing it. Note that a while ago they ended up adding downloadable builds for the most common platforms, but for anything else the expectation still was (and is, I guess) to build sources at install time.

View on HN

Believe such build tools and processes should be run inside a container environment. Maybe once all OS have native, cheap and lean containers and permit dead simple container execution of scripts, this will be possible.

Google's OS, Android, has sandboxes. It's some Linux problem that they do not want to backport it.

It just has Linux user IDs. They're in every Linux.

I think that was long time ago, because this doesn't allow to request permissions in runtime.

Permissions are not granted through Linux itself. Permissions are something checked by separate processes when you connect with those processes.

how hard would it be to say "upon first install, run do_sketchy_shit.sh to install requirements"?

People want package managers to do that for them. As much as I think it's often a mistake (if your stuff requires more than expanding archives different folders to install, then somewhere in the stack something has gone quite wrong), I will concede that because we live in an imperfect world, other folks will want the possibility to "just run the thing automatically to get it done." I hope we can get to a world where such hooks are no longer required one day.

yes that's why npm is for them. I'd rather download the libraries that I need one by one.

But most users would do that without inspecting it at all, and a fair number would prefix it with “sudo” out of habit.

But that’s at least a conscious and explicit action the user chooses to make and is explicitly aware of making.

That's fine, and it's still better than doing it on install.

you can always add --am-an-idiot as a switch to npm install.

Hard. In npm land you install React and 900 other dependencies come with it. And how ok are you reviewing every single one of those scripts and manually running them? Not that it is good that this happens but realistically most people would just say “run all” and let it run instead of running each lifecycle script by hand.

My solution is to bypass React entirely. I'd much rather have a smaller, possibly less functional or pretty front end than to have to worry about this stuff continuously. I would not get any work done. There is no way I'm going to take on board 900 dependencies which I will then inflict on the visitors to my website.

the only way I'd use react in a project is to download the react.js build. I don't see why people want to download 900 dependencies.

I am people and I don’t want to download 900 dependencies. But if I want to use React or Vue or anything but the most trivial JS libraries or frameworks I am held hostage by the fact that their dependencies have dependencies.

Surely there are ways to just stick to absolute basics and you can get quite far with what is built in or some very small libraries, but I guess it depends on where you would be most productive.

rpm and dpkg both provide mechanisms to run scripts on user machines (usually used to configure users and groups on the user machine), so this aspect is not an NPM-specific. Rust has the same thing with build.rs (which is necessary to find shared C libraries for crates that link with them) so there is a legitimate need for this that would be hard to eliminate.

Personally, I think the issue is that it is too easy to create packages that people can then pull too easily. rpm and dpkg are annoying to write for most people and require some kind of (at least cursory) review before they can be installed on user's systems from the default repos. Both of these act as barriers against the kinds of lazy attacks we've seen in the past few months. Of course, no language package registry has the bandwidth to do that work, so Wild West it is!

rpm and dpkg generally install packages from established repos that vet maintainers. It's not much but having to get one or two other established package authors to vouch for you and having to have some community involvement before you can publish to distro repos is something.

I agree, that is what I talk about in the second paragraph! ;)

You see, when you treat everything as a "product", this is what you end up with.

Running a C compiler on everyone's machines to avoid a bit of work is extremely dumb.

Modern internet is build on premise of repeatedly running megabytes of javascript on everyone's machines to avoid a bit of work.

Reply on news.ycombinator.com