4 ms·

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

• ramesh31 7mo ago
  >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.
  • user34283 7mo ago
    Personal attacks directed at people who build OSS are not cool, even if you take issue with their supposed use of AI or vendoring of dependencies.
    • bheadmaster 7mo ago
      Vibe coders are NOT programmers, they are leeches, feeding from the blood of the open source.
      • stavros 7mo ago
        Yeah yeah. This app is open source too.
        • bheadmaster 7mo ago
          That's even worse, they're polluting the open source space with AI slop. Anyone learning from open source will not learn anything useful from it.
          • stavros 7mo ago
            Man, nobody is learning anything any more, those days are gone. Programming with actual code is a niche hobby or a hyperspecialized profession now, like demoscene coders. Besides, even before LLMs, it's not like anyone ever said "you shouldn't have open sourced this, we can't learn from your code". We just didn't bother reading that code. Telling off people who contribute is not OK.
            • bheadmaster 7mo ago
              AI slop is not a contribution.
              • stavros 7mo ago
                [flagged]
                • bheadmaster 7mo ago
                  Nice detective work in an attempt to... ridicule my programming skills, I suppose? It's a useful tool and I built it myself, with my own ten fingers, using my brain. That's more than vibe coders will ever do. Meanwhile, your blog says in big text "I don't care for the joy of programming", so I don't consider your opinions on software development anywhere near relevant.
  • solvik 7mo ago
    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 missing system/compiler flags.
    • Gormo 7mo ago
      > 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 7mo ago
  • rzzzzru 7mo ago
    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 yet but might be added in the future. I've built this project out of passion and it's 100% open-source and free, so please keep this in mind when criticizing.
    • mentalgear 7mo ago
      While I can understand that, why not replace python deps with wasm versions ?
      • rzzzzru 7mo ago
        Simply because I was not aware of this option, that's it. Happy to consider it and also happy to receive contributions.
    • Gormo 7mo ago
      > 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 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.
      • rzzzzru 7mo ago
        noted, mate, and thanks for the feedback, really! 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!
• rzzzzru 7mo ago
  I'm just using cross https://github.com/cross-rs/cross https://github.com/cross-rs/cross to build cross-arch. you can still use `cargo build`, it will just work.
  • Gormo 7mo ago
    It did, but then the application didn't work because it couldn't find the Python interpreter that it itself downloaded into its own config directory.
• raincole 7mo ago
  > instead of checking for what's already installed 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.
  • throw_await 7mo ago
    All reasonable Linux distro will patch these stupid things to usw the system interpreter.
    • Gormo 7mo ago
      And even if the build scripts are downloading deps, having the application itself install dependencies to the user's home directory at runtime is unheard of.
    • raincole 7mo ago
      It's not how it works. You can just install whichever linux distro of your favorite, download blender or krita, and see it uses its own python by default yourself. And thankfully it's not how it works. If it were it'd break plugin ecosystems of many apps completely.
      • ajsnigrutin 7mo ago
        gentoo (a lot of lines removed): $ strace blender-4.4 .. openat(AT_FDCWD, "/usr/lib64/libpython3.13.so.1.0", O_RDONLY|O_CLOEXEC) = 3 ... openat(AT_FDCWD, "/usr/lib/python3.13", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12 ... No issues with plugins
• bityard 7mo ago
  This is unfortunately becoming more common. 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.
  • LtWorf 7mo ago
    I would, for safety, run the whole thing under a different user.
• jsjshsshhs 7mo ago
  welcome to the millenial way of doing things always assumes internet is connected always assumes everything is trusted
• ravenstine 7mo ago
  > 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. I've been sympathetic to your viewpoint, and I can see why this kind of thing is becoming more common. The idea that users can reliably supply their own vendor libs/execs for applications is a bit of a fantasy. Devs working on fixing issues caused by the user having a strange issue due to the version of Python or whatever that they have installed is largely a waste of time when the application can "simply" ship with the exact dependencies it expects. This is especially true when it comes to open source work. Dealing with weird edge cases because the user has a version of FFMPEG installed that, for whatever reason, is missing h264, is work that nobody asked for. Given that the audience of this kind of app is a general one (not specific at all to devs) then it doesn't make sense to require other system packages to be present; if things like Python and FFMPEG are not required and will be downloaded anyway as part of the app install process, then there's no point in not always doing that. If you think about it, it's hardly different from any other sort of software dependency. The dependencies are just relatively bigger. Personally, I have no desire for my applications to use other executables on my system unless I request that they do so explicitly. I'm sympathetic to the idea from a mere efficiency perspective, especially when it comes to developer tooling. But a karaoke app? No offense, but why care? A Python interpreter will be anywhere between 50 and 200 megabytes. FFMPEG is even smaller, especially if you don't enable every single feature and codec. Compared to how ridiculously bloated your average basic mobile app is (without anything like a built in JIT), bundling a desktop application with something like Python provides a lot of power relative to the number of bytes added.
  • Gormo 7mo ago
    > The idea that users can reliably supply their own vendor libs/execs for applications is a bit of a fantasy. That's why package managers and OS repos exist. Users shouldn't have to even be aware of this sort of stuff. In this case, though, when the application starts trying to download and install its own dependencies at runtime, instead of everything already being sorted out at build time, the user is made aware of dependency resolution, and now has to deal with the issues involved. > This is especially true when it comes to open source work. Dealing with weird edge cases because the user has a version of FFMPEG installed that, for whatever reason, is missing h264, is work that nobody asked for. And that's what config tests at build time solve for, and have solved for decades.
• HWR_14 7mo ago
  > How come this is trying to install its own vendored dependencies "Why does this new software do X?" is probably answered by "the vibe worked on my system"
  • selcuka 7mo ago
    Not trying to sound like a luddite (I don't "vibe code" but I use LLM assistance), but after learning that Claude Code is a React app, I'm not surprised by anything anymore.
• mft_ 7mo ago
  It's probably pertinent to mention that the Python installation ecosystem is a hot mess, with multiple ways of installing Python (e.g. standard Python installer, multiple different packages managers on different OSes, Conda, and myriad package managers which can also install Python. And of course, these can all be in different locations, and may have different approaches to installing libraries. Which is to say, I don't blame the author for wanting a single installation that his app can manage and rely on, even though I wish it was different.
  • cynicalkane 7mo ago
    The app is vibecoded. The author isn't making decisions about these tradeoffs and possibly wasn't aware of the implications of these decisions at all. The robot they used tried to fulfill its given prompts at the expense of everything else, which is why it's looking in bad directories and trying to install Docker environments in the build script. I suspect that some of the author's comments in this thread are vibe-written, also. They are LLM-flavored and contrast strongly vs. their regular commenting.
    • selcuka 7mo ago
      > The app is vibecoded. The author isn't making decisions about these tradeoffs and possibly wasn't aware of the implications of these decisions at all. The I agree, but to be fair this is how I would code it, too. I would have probably bundled the Python interpreter and only downloaded the FFmpeg binary (because of its license), but that's a relatively minor difference.
      • cozzyd 7mo ago
        Do.. people not already have ffmpeg on their machines? In that case it should use the system package manager.
        • selcuka 7mo ago
          Not all people do. Also it may be a different version that doesn't support the command line arguments that you use, or it may not have been compiled with the flags that you want. It's just less headache to vendor it.
• ljm 7mo ago
  This guy just discovered static linking. May he enjoy an eternal debate about static and dynamic linking, strong types and duck types, tabs and spaces, vim and emacs, less and more, and Kickers and Rockport.
  • mghackerlady 7mo ago
    there's a difference between static linking and downloading your dependencies over the net
    • ljm 7mo ago
      What dependencies, these days, are not downloaded over the net? If someone put this app on CDs and gave them out at a supermarket, well, it worked for AOL 30 years back but not now.
      • gbin 7mo ago
        You don't want to add untrusted binary download sources in your Linux system. Your distrib is already doing that. This is not strictly about "downloads from the internet" of course
  • Crestwave 7mo ago
    Static linking packs the dependencies into the executable. This is basically dynamic vendoring.
• canibal 7mo ago
  I mean... Sounds pretty clearly vibed from this description. Funnily enough this is touted as a feature, not a bug: > Single binary > ffmpeg, Python, PyTorch, and the ML models are all bootstrapped on first launch. Nothing to install.