251–260 of 460 posts
And how’s the situation with Bun?
> Packages on npm can define lifecycle scripts in their package.json. These scripts are arbitrary shell commands that the package manager is expected to read and execute at the appropriate time.
> But executing arbitrary scripts represents a potential security risk, so — unlike other npm clients — Bun does not execute arbitrary lifecycle scripts by default.
Earlier quoted context omitted.
Which operating system lets an application have "free reign of all the files on the file system by default"? Neither Linux, nor any BSD, nor MacOS, nor Windows does. For any of those I'd have to do something deliberately unsafe such as running it as a privileged account (which is not the "default").
How many software installation instructions require "sudo"? It seems to me that it's many more than should be necessary. And then the installer can do anything. As an administrator, I'm constantly being asked by developers for sudo permission so they can "install dependencies" and my first answer is "install it in your home directory" sure it's a bit more complexity to set up your PATH and LD_LIBRARY_PATH but you're…
% sudo ls ~/Pictures/Photos\ Library.photoslibrary
Password:
ls: /Users/n1503463/Pictures/Photos Library.photoslibrary: Operation not permitted
Earlier quoted context omitted.
That is an impossible task in practice for most developers. Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a developer to depend on every possible variation of such packages, across many distros, is a tall order. Postgres and Nginx might be able to do it, but those are established projects with large teams behind them and plenty of leverage. They might even be able to inf…
You do not depends on a package, you depends on its API. Implementation details shouldn't matter if behavior stays the same. Why do you care if the distro reimplemented ffmpeg or libcurl, or use an alternative version built with musl? Either the library is there or it's not. Or the minimum version you want is there or it's not. You've already provided the code and the requirement list, it's up to the distro maintaine…
laughs in elixir
Claude code is by all accounts a revolutionary tool for getting useful work done on a computer. It's also: - a NodeJS app - installed by curling a shell script and piping it into bash - an LLM that's given free reign to mess with the filesystem, run commands, etc. So that's what, like 3 big glaring vectors of attack for your system right there? I would never feel comfortable running it outside of some kind of sandbox…
I definitely think running agents in sandboxes is the way to go. That said Claude code does not have free reign to run commands out of the gate.
"It's dangerous to just deploy code that you didn't write and you haven't verified!"
....
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 simpl…
We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained. If y…
Earlier quoted context omitted.
That is an impossible task in practice for most developers. Many distros, and Debian in particular, apply extensive patches to upstream packages. Asking a developer to depend on every possible variation of such packages, across many distros, is a tall order. Postgres and Nginx might be able to do it, but those are established projects with large teams behind them and plenty of leverage. They might even be able to inf…
> distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain. That's not the idea. If a software is packaged for a distro, then the distro will have the libraries needed for that software. If you're developing a new software and wants some new library not yet packaged, I believe you can figure how to get them on your system. The thread is ab…
This is also much easier for the user, since they only need to download and run a single self-contained artifact, that was previously (hopefully) tested to be working as intended.
This has its own problems, of course, but it is the equivalent of vendoring build time dependencies.
The last part of my previous comment was specifically about the practice of distros carrying build time libraries. This might've been acceptable for C/C++ that have historically lacked a dependency manager, but modern languages don't have this problem. It's a burden that distro maintainers shouldn't have to worry about.
Periodic reminder to disable npm install scripts. npm config set ignore-scripts true [--global] It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script. I know this isn't a silver bullet solution to suppl…
This sucks for libraries that download native binaries in their install script. There are quite a few.
Earlier quoted context omitted.
> distro package managers carrying libraries for all programming languages is an insane practice that is impossible to scale and maintain. That's not the idea. If a software is packaged for a distro, then the distro will have the libraries needed for that software. If you're developing a new software and wants some new library not yet packaged, I believe you can figure how to get them on your system. The thread is ab…
It's not reasonable to expect every software in existence to work with a compatible set of dependencies. So no, the distro can't supply all the libraries. What happens is that distro developers spend their time patching the upstream so it works with the set included on the distro. This has some arguable benefits to any user that wants to rebuild their software, at the cost of random problems added by that patching th…
That is not what it's being asked.
As a developer, you just need to provide the code and the list of requirements. And maybe some guide about how to build and run tests. You do not want to care about where I find those dependencies (Maybe I'm running you code as PID 1).
But a lot of developers want to be maintainers as well and they want to enforce what can be installed on the user's system. (And no I don't want docker and multiple versions of nginx)