61–70 of 175 posts
The homepage still exists, but it looks like many of the other pages like the blog and wiki are long gone. It hasn't been active in probably over a decade.
Earlier quoted context omitted.
>How come this is trying to install its own vendored dependencies, including executable binaries, instead of checking for what's already installed? That approach can lead to both security and performance issues. Because the person who vibecoded this had no idea they should have been doing that.
hey both! thanks for your feedback and reports, I'd be happy if they are added as issues on github. as said in the separate comment, I really wanted an app to be as "grandma-proof" as possible, therefore I really wanted to have one binary that does the magic for you. it's a karaoke app, not a tool that is aimed at engineers. we can indeed look at the local packages before downloading an executable, it's just not done…
Earlier quoted context omitted.
hey both! thanks for your feedback and reports, I'd be happy if they are added as issues on github. as said in the separate comment, I really wanted an app to be as "grandma-proof" as possible, therefore I really wanted to have one binary that does the magic for you. it's a karaoke app, not a tool that is aimed at engineers. we can indeed look at the local packages before downloading an executable, it's just not done…
While I can understand that, why not replace python deps with wasm versions ?
Earlier quoted context omitted.
>How come this is trying to install its own vendored dependencies, including executable binaries, instead of checking for what's already installed? That approach can lead to both security and performance issues. Because the person who vibecoded this had no idea they should have been doing that.
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 said, an optional “use system environment if available” mode could make sense for advanced users. 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 mi…
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.
Just downloaded source and built this to play around with it. I was a bit surprised that the first thing it did when I ran it was to start downloading binaries from the internet. It went off to fetch FFMpeg from some remote server, but I already have FFMpeg installed. Then it tried and failed to install its own Python interpreter, which is another thing that's already present on the system. How come this is trying to…
Just downloaded source and built this to play around with it. I was a bit surprised that the first thing it did when I ran it was to start downloading binaries from the internet. It went off to fetch FFMpeg from some remote server, but I already have FFMpeg installed. Then it tried and failed to install its own Python interpreter, which is another thing that's already present on the system. How come this is trying to…
Plenty of software come with their own Python runtime. Even Blender uses its own Python runtime. I can name so many apps with embedded Python runtime: Blender, Houdini, Bitwig, Substance Painter, Krita, etc. Checking for what's already installed isn't the norm. In Krita's case, it uses installed Python to build it... and in the building process it builds another Python runtime for its own!
This app should have probably bundled the runtime instead of downloading a new one though.
> install its own vendored dependencies
> lead to both security and performance issues
npm install and pip -r theoretically have the same kind of security issue. How many projects on github run this kind of command during build process? My guess is in the order of millions.
Just downloaded source and built this to play around with it. I was a bit surprised that the first thing it did when I ran it was to start downloading binaries from the internet. It went off to fetch FFMpeg from some remote server, but I already have FFMpeg installed. Then it tried and failed to install its own Python interpreter, which is another thing that's already present on the system. How come this is trying to…
Just yesterday, I went to try out some cool new AI thing that was here on the front page of HN. It's written in Python. Great, I thought, that means I can put it into a virtualenv and just rm the whole tree when I'm done and my system will be exactly in the same state it was previously.
But sadly... no... the first time I ran it, this Python program started downloading and installing Node/NPM, and all kinds of other stuff to my machine WITHOUT even asking for permission. Sorry app developers, but my machine and my home directory are my workplace. They are curated property, you are NOT allowed to just install whatever you wish.
I expect this kind of behavior from programs whose only supported installation method is a curlpipe. (And I do avoid those.) I do not expect it from programs that claim to be installable by pip, or ship their own binaries. These NEED to be called out as vulnerable to supply-chain attacks at worst and extremely disrepectful to users at best.
Earlier quoted context omitted.
>How come this is trying to install its own vendored dependencies, including executable binaries, instead of checking for what's already installed? That approach can lead to both security and performance issues. Because the person who vibecoded this had no idea they should have been doing that.
hey both! thanks for your feedback and reports, I'd be happy if they are added as issues on github. as said in the separate comment, I really wanted an app to be as "grandma-proof" as possible, therefore I really wanted to have one binary that does the magic for you. it's a karaoke app, not a tool that is aimed at engineers. we can indeed look at the local packages before downloading an executable, it's just not done…
Probably the best way to do that is to design, build, and distribute it like any other normal desktop application, and not come up with idiosyncratic and experimental methods for invoking bog-standard libraries and language interpreters.
On Windows, just include the necessary binaries as part of the application distribution itself, in hardcoded paths, without any runtime download of executables from unclear sources.
On Linux, use system defaults resolved at build time through a normal config script -- any "grandma users" on Linux will end up installing from distro repos, AppImage, Flatpak, etc, all of which have their own methods for handling dependencies, and is definitely not something the application should be trying to do by itself post-install.
I've been working on a karaoke app called Nightingale. You point it at your music folder and it turns your songs into karaoke - separates vocals from instrumentals, generates word-level synced lyrics, and lets you sing with highlighted lyrics and pitch scoring. Works with video files too. Everything runs locally on your machine, nothing gets uploaded. No accounts, no subscriptions, no telemetry. It ships as a single…
Earlier quoted context omitted.
hey both! thanks for your feedback and reports, I'd be happy if they are added as issues on github. as said in the separate comment, I really wanted an app to be as "grandma-proof" as possible, therefore I really wanted to have one binary that does the magic for you. it's a karaoke app, not a tool that is aimed at engineers. we can indeed look at the local packages before downloading an executable, it's just not done…
> I really wanted an app to be as "grandma-proof" as possible, therefore I really wanted to have one binary that does the magic for you. Probably the best way to do that is to design, build, and distribute it like any other normal desktop application, and not come up with idiosyncratic and experimental methods for invoking bog-standard libraries and language interpreters. On Windows, just include the necessary binari…
I'm not experienced in building desktop apps per-se, so I went with the thing that looked reasonable to me. all your comments are valid tho. I'll take a look how can I resolve this in the future.
cheers!