• collapse_already@lemmy.ml
    link
    fedilink
    English
    arrow-up
    13
    ·
    9 hours ago

    My issues are not install, but uninstall. Why do I have so much crap installed? I used it on a project once 7 years ago and haven’t since. Why not uninstall it? It is useful, just not currently. It took less than a minute to install when you installed it the first time and your connection is faster now? But what if the archive goes down or it is retired or obsolete? It is small, keep it!

    Turns out lots of small adds up to big.

    • nek0d3r@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      2
      ·
      6 hours ago

      And yet some linux devs look at me using containers for development like I’m the Demon Lord of Overhead

      • jj4211@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        4 hours ago

        If you use it to make sure your deployment is sane and that your dev system didn’t have an invisible component that you assumed as a dependency, great. Containers are a great tool for simulating minimalist clean setups and not incurring surprise hidden dependencies.

        If your application carries a whole container with it for the user to use and that’s the only way to use the software, that’s going to be annoying. ‘docker style’ for bloat, flatpak/snap depends on the app but sometimes the application functionality is broken by the container boundaries. Admittedly flatpak/snap is frequently acceptable, really depends on if the program has a lot of interoperability features that get broken in the flatpak/snap runtime model.

        If your application only is deployable as a pod… I’m almost certainly going to want to avoid it if at all humanly possible. Pods as a self-hosted approach to do what you want, ok, fine and I own all that. If a third party pod is happening, I tend to see some part of it fall over it and no one can figure it out because the application is microserviced into oblivion and no human actually understands the whole flow… It’s possible also to do this with ‘traditional’ application delivery, but a pod is a very high sign that no one even bothered thinking hard about how it should come together and play nice with others.

        • nek0d3r@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          2 hours ago

          Yeah, all of mine are usually just there to spit out binaries to use locally and alert me to any new dependencies slipping by. I once worked at a company that would ship web apps with databases that only ran in a container so that they could make each layer of its image a migration. It made CI take upwards of 40 minutes for just regular PR builds.

          And then there’s people who are just allergic to containers. If you want me to work on your C project, I’m not leaving dev libraries lying around or wondering why something works on my system and not on others. I’m building a Dockerfile that has only what should be needed to build and feeding make through a container and volume binding the output.

          Edit: I hate flatpak and snap so much actually lol. Most of the Dockerfiles I write are just building apps from source that don’t distribute any other way. I’ll even accept AppImages, but if you make me use flatpak, I will not hesitate to start building from source.

    • ulterno@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      7 hours ago

      Specially for rolling release distros.
      I had fun installing everything I thought of just checking out once, including games and stuff (assets tend to be large).
      But after a few updates and not actually using most of them, I realised how much load I was putting on the network and removed many of them.