Hey all,

I was looking for a Youtube downloader to self-host, and when I found one that looked really great, it was no longer functional. So, I vibe-coded a new one.

Hermes is a front end app and a REST API for yt-dlp.

This is fully functional but I just got it on Github so give me a few days to publish images. But, feel free to clone it down now and build it yourself!

https://github.com/TechSquidTV/Hermes

  • papertowels@mander.xyz
    link
    fedilink
    English
    arrow-up
    11
    ·
    edit-2
    8 hours ago

    When you run a self-hosted application, do you first go through and read all the code? I don’t, I’ll tell you that. I’m going to assert that most folks don’t, and unless I hear otherwise I’ll assume you don’t read all the code for every self-hosted application you use.

    No one is complaining about Docker, they’re complaining about AI

    Correct. Saying you “vibe-coded” something up suggests that you didn’t do it yourself, or at least was only loosely invested in it. If you didn’t put much time into it, then it’s not as vetted for folks. Running your code on someones homelab is then akin to pushing the new grads vibe-coded refactor into prod, which I think we all know is a bad idea. The mitigation for that is for the user to vet the code themselves, which we already asserted earlier doesn’t really happen in practice. So we have two options, either push the vibe-coded refactor into prod, or acknowledge that we’ve introduced an additional requirement onto the users to vet the code themselves. Both are not ideal. I’m proposing that it is that friction that you’ve introduced that folks are upset about. The docker issue was just brought up as an example of what could go bad by running poorly vetted code on a machine.

    Also idk where you heard Docker is like giving root

    If I’m not looking through all the code, then as a user I’ll just be following your included instructions, of which the recommended method is to fire up docker-compose. If docker-compose bind mounted mounted /, my understanding is that the container now has default write-access to the entire host - am I mistaken?

    • TechSquidTV@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      7
      ·
      8 hours ago

      It would, but that *would only work/be possible if *you are running docker as the root user. Though people OFTEN create a docker user that runs docker as root, which is a bad practice and source of confusion. Docker is plenty safe, but I don’t even want to argue that, it’s completely irrelevant. I don’t actually care how you run it. Docker compose is by far the standard for home server applications. You can use podman with it, it’s fine. You can skip it entirely and run it directly. These are merely options provided.

      Here is the install instructions for Sonarr, arguably the most famous example of something people self host. https://sonarr.tv/#downloads-docker

      They have non-docker instructions too of course, as do I. Am I correct that a few of you are mad that I included dockerfiles and docker compose examples in the repo? Where did I go wrong?

      • papertowels@mander.xyz
        link
        fedilink
        English
        arrow-up
        8
        ·
        8 hours ago

        Am I correct that a few of you are mad that I included dockerfiles and docker compose examples in the repo? Where did I go wrong?

        No, we’re not upset about docker. Did you read the majority of my last comment?

        Correct. Saying you “vibe-coded” something up suggests that you didn’t do it yourself, or at least was only loosely invested in it. If you didn’t put much time into it, then it’s not as vetted for folks. Running your code on someones homelab is then akin to pushing the new grads vibe-coded refactor into prod, which I think we all know is a bad idea. The mitigation for that is for the user to vet the code themselves, which we already asserted earlier doesn’t really happen in practice. So we have two options, either push the vibe-coded refactor into prod, or acknowledge that we’ve introduced an additional requirement onto the users to vet the code themselves. Both are not ideal. I’m proposing that it is that friction that you’ve introduced that folks are upset about. The docker issue was just brought up as an example of what could go bad by running poorly vetted code on a machine.

        • TechSquidTV@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          7
          ·
          edit-2
          8 hours ago

          I don’t care what you do but you are placing a lot of assumptions on the word vibe coded. If you’re interested, look at the code and see for yourself, that’s why it’s open source. If you aren’t that’s fine, because nothing is for sale here.

          • papertowels@mander.xyz
            link
            fedilink
            English
            arrow-up
            8
            ·
            7 hours ago

            Do you understand why folks are upset though?

            I have not had to look at the code for any other self-hosted application when considering whether or not to use it. You can say that this is a self-levied requirement due to the suspicions of vibe-coding, and I’d fully agree.

            I took a quick peek at your github profile, and you’ve been working on FOSS stuff before LLMs were a thing (thank you!), suggesting that you are more likely to actually know what you’re doing. However when you say you vibe-coded up an application, you’ve placed yourself in the same bucket as the vibe-coder who’s ai agent deleted a database despite being instructed that there was a code freeze. Yes, it was a developing product, and not prod, but yeah you’ve advertised that you use the same tools and techniques as this guy, which does not inspire confidence.