I know there choice of distro is really meaningless as you can install almost any program on almost any distro. But I have been playing with kali which is for security people and pen testers. Is there a similar distro for programmers? Like a few ides installed some profiling tools some virtual environment tools etc?

  • ouch@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    28 days ago

    Distro packages don’t really matter much in my experience. You either use project-specific package management or install stuff with Homebrew or Nix package manager. Sometimes maybe even containers.

    One problem with distro packages is that you can only install one version. And in practise a lot of software projects have outdated dependencies. Sometimes you have multiple projects with conflicting version dependencies.

    • nyan@sh.itjust.works
      link
      fedilink
      arrow-up
      3
      ·
      28 days ago

      One problem with distro packages is that you can only install one version.

      This isn’t technically true for all distros—Gentoo has a mechanism that will allow multiple package versions to be installed in parallel. I have multiple distro-packaged Python and Lua interpreter versions on my system, for instance. But it does require some extra work by the packager, so it isn’t done universally for all packages.

      • ouch@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        28 days ago

        Are these made similarly to how Debian handles python2 and python3 for instance?

        I’m not sure that anything short of a package manager that would compile everything from sources would be able to provide capability to pick and mix specific package versions.

        • nyan@sh.itjust.works
          link
          fedilink
          arrow-up
          2
          ·
          28 days ago

          I don’t know how Debian’s solution works, so I couldn’t say for certain. Gentoo usually installs the different package versions to their own directories, and there are methods for selecting a “system python” (or lua, etc) which is the target of the /usr/bin/python symlink. Other versions have to be called with qualifiers (for instance, python3.10). Python libraries installed through the package manager may install to one or several versions depending on the content of a couple of environment variables, and applications that need python can request a specific version if they need to, or accept the system python if they don’t care. (Note that python2 is no longer eligible to be the system python—you need at least one python3, although 2.7.18 remains in the package repository and can be installed as well if you really need it.)

          Of course, if you’re not a programmer, you can leave the defaults for everything alone, and most of the time it should Just Work.

          • ouch@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            28 days ago

            Sounds pretty close to Debian as far as I remember. In Debian those symlinks are called alternatives, and can be configured with update-alternatives. Not sure about the Python libraries though.

    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      28 days ago

      Well, now you are hitting on my real recommendation which is to use Distrobox. Distrobox allows you to install multiple userlands that are all isolated from each other but all seem native on your system and give you full access to shared files and resources ( even the GUI desktop ).

      It is very common to work on something not that just has outdated packages but that targets a specific distribution. If you are building something that will target an Alpine container in the cloud, it is handle to create an Alpine Distrobox to have all the same libraries. Similarly an app might target a specific version of Ubuntu. One of the products I worked on last year was based on Ubuntu 18.04. I could easily create an Ubuntu 18.04 Distrobox to work on that.

      Distrobox also means I can prevent the build-up of cruft from all the little specialty tools and dependencies that projects require that I will not need long term. Remove the Distrobox and remove all the junk.

      This is different than pure Docker to Podman though since Distrobox still gives you full access to your base system. You only have to install what you uniquely need in Distrobox. So i am not necessarily installing all my tools in Distrobox. Just the specialty ones.

      Anyway, this is a more complicated answer and setup. In my view, the host environment still matters a lot and what I said above still stands.

      • ouch@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        28 days ago

        Heh, Distrobox came to my mind when writing my comment. I haven’t used it enough to recommend it yet though.

        I recall there are some other development container projects, but can’t remember the names right now.

        Development containers are nice in theory. In practice, sometimes development environments are so complex that it might not be worth the trouble. But it’s good to have options.