> It’s a desktop app for mostly non-technical users, so bundling the runtime is a deliberate tradeoff to reduce setup friction and machine-specific breakage.

That's not a very reasonable justification, considering that dynamic linking of dependencies has been industry standard in software designed for "non-technical users" for the past thirty years or so, and is basically a solved problem.

I can understand having a downloadable archive that already includes things like FFMpeg and Python for Windows users (with everything already included in appropriate locations, so no runtime downloads necessary).

But this is an especially bad practice for Linux, since most of the vendored dependencies are already installed by default on pretty much every Linux distro, and package managers are designed to sort out and install appropriate dependencies on behalf users, so that the "non-technical" among them aren't exposed to the massive risks of having application software retrieve and execute arbitrary binaries from the internet.

The only thing it somewhat makes sense for would be the AI models it's retrieving, but even that ought to be implemented via a separate download/update script and not just baked into the main application runtime without even prompting the user that it's about to download a huge dataset.

> A PR for that would be welcome, as long as it also handles the real complexity involved: platform differences, Python package compatibility, GPU backends, and missing system/compiler flags.

These are the sort of things that config scripts at build time are designed to handle. It's already using Cargo here, which should be able to handle all of this just fine, so it's very perplexing to see that it isn't being used for this purpose, and what should be build-time dependency resolution is instead being palmed off to the application itself at runtime. That is an extremely strange -- and potentially dangerous -- approach.

▲

marssaxman 3 hours ago | parent [-]

> dynamic linking of dependencies has been industry standard

So it has, and I've been hating the excess complexity it brings for most of that thirty years! I'm glad to see the recent swing back toward self-contained executables. Where this author went wrong was not in vendoring the app's exact dependencies, which is a good idea, but in trying to download them and install them separately on first launch, rather than including them in the app bundle, where they can remain isolated from the rest of the system.

	▲	Gormo an hour ago \| parent [-]
		> So it has, and I've been hating the excess complexity it brings for most of that thirty years! It reduces complexity compared to the administrative and security mess of every application having its own version of every library, let alone its own version of external tools and interpreters. > I'm glad to see the recent swing back toward self-contained executables. I wish there was one. Static linking is a great solution for this. Instead, we're seeing dynamically linked libraries being bundled alongside of executables in a way that increases complexity vastly. > Where this author went wrong was not in vendoring the app's exact dependencies, which is a good idea, but in trying to download them and install them separately on first launch, rather than including them in the app bundle, where they can remain isolated from the rest of the system. Agreed. Dependency resolution at build time is normal. Dependency resolution in user mode at runtime is crazy.