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?
All of them? I've always liked (and preferred) Linux for dev work, as I'm just so comfortable around working with the commandline and installing packages that I might need. For that end, any of them would work, you'd just need to set them up with what you want. If you wanna be "cool" and "hacker" you could install Arch and install every last package manually handpicked, or you could go with the most bog standard Ubuntu or Fedora or OpenSUSE. All of them work, it's only down to your tools.
If you like Kali, stick with it.
Not that I know of, but I kind of feel like Nixos could be. The way you can use nix flakes or shells so each project has its on version of nodejs, go, rust, or w/e you use. Instead of having them installed system wide. And you can put the flake.nix and flake.lock in your git repo so any other Dev with nix can use it to DL the exact same packages.
yep came here to say NixOS - once I was used to it, the advantages for programming are immense. I commit my shell.nix to Git and use Lorri to automagically install the right environment tools and it feels magical being able to work on multiple machines and never encounter dependency oddness
The "DX" stands for developer experience.
It's a variant of uBlue/ Fedora Atomic (Silverblue) with a lot of added programming tools like Brew, Nix, IDEs, local LLMs, and more.
There's also Aurora, which is the same, but with KDE instead of Gnome.
The dx-images are meant to be a plug-and-play solution for developers.
You just install it, share your container config to your project colleagues, and go. Don't worry about not being able to work because of a bad update or some misalignments in your package manager broke your OS. Most stuff is containerised, and if your host breaks, you can just roll back, because the system is basically powered by git.
I'm no developer, but I use the regular variant for casual purposes (no specific tasks, mostly browser) on my laptop, and Bazzite (also very similar, but gaming focused) on my desktop, and both are wonderful!
They're the most boring distro/ OS I've used yet, and that's great. They're immutable/ image based and always work reliably.
I can really recommend them for a lot of people, from ranging from IT professionals to my mum.
I've done the horrible deed of updating Debian, for example.
Distros like Arch get a pass, but Debian screwed me over several times. For example a few years ago, some driver decided to make itself clinge onto old kernel versions. So the boot partition got full and left me in a weird start where I had to manually remove old kernels and track down the driver at fault.
Recoverable, but annoying, and on a system I use for work it would be really really expensive.
Fedora used to nuke itself sometimes if you upgraded an install from version n to n+1, n+2, .... Like a config not being migrated properly, a package conflict because of renamed packages and versions, yada yada yada.
If you didn't experience that, you either were very lucky, only used enterprise distros, or simply reinstalled often enough for it not to be an issue.
I've had bad tinkering break my system before, but never had an update break it irreversibly. The closest would actually be on Silverblue itself, when an update to the kernel was using different signing keys that cause the system not to boot. Fortunately it was simple, I selected the previous deployment and I was in (on a non versioned OS I would have selected the previous kernel which most are configured to retain the last few). A quick Google revealed Ublue had a whole kerfuffle and after verifying it was legit, I enrolled the new certs into my MOK.
Although one time on Arch I had installed an experimental version of Gnome from one of their repos, and was pleasantly surprised when that version finally released and I removed the experiment repo and did an update absolutely nothing at all broke. Nothing.
I've had this happen more often than I'd like to admit.
There were quite a few instances where I just couldn't game in the evening after turning on my PC, mostly because of my power supply (outages while updating, unstable grid, damaged PSU and hard drive, etc.) and my ability to shoot myself in the foot in regards to my IT skills.
I imagined spending my friday evening differently than chrooting my install from another USB more often than I'd like to admit.
At least Linux is repairable, good luck trying that with Windows...
Now, thankfully, I live in another house with a landlord that actually cares that I don't get electrocuted in my shower, and I don't have those problems anymore. I also don't tinker as much with my OS anymore, at least not much.
Still, Fedora Atomic feels way more robust and less buggy than regular Fedora, especially KDE.
And the QoL tweaks from uBlue are great too!
UNIX was kinda designed to be an IDE (of its time) by itself. Desktop/Server Linux (whether GNU or non-GNU) mostly continues this tradition; you are provided with some powerful tools for text manipulation, development, debugging and deployment out of the box in most distros. As such, any modern Linux distro is pretty good for development even out of the box. However, you must learn to use this power, and I'm not claiming it's easy (I still regularly look up various manpages despite doing development on Linux for 10+ years in various forms).
With that said, I myself prefer NixOS. It really feels more developer-oriented that other distros, as you get the power of Nix out of the box, and integrated into the system. With Nix you get easy access to the biggest software repository in the world. You get per-project development shells, so that you never have to worry about different toolchain versions for different projects, or your system being contaminated with bloat you no longer need. You get the power of reproducible packaging, to eliminate a lot of (but unfortunately not all of) "Works on my machine"-type of problems. It's also got a hell of a learning curve, but I think it's worth it.
Short answer is no, I think because what tools you need for programming change so much based on the development you're doing. C++ developers need compiler toolchain stuff that Javascript developers would never need to look at and vice versa.
Curveball answer is that modern extensible IDEs with the power of language servers and plugins have kind of become this. I'd massively recommend properly getting into one of the following and learning how to configure new languages and plugins:
VScode
Neovim
Emacs
Helix
(Sure I've probably missed some great options, feel free to flame me on why notepad++ should be OPs first choice)
I mean pretty much any distro that isn't locked down will be good for programming. All you really need is a package manager with a selection of at least somewhat modern dev tools, which almost all of them have.
language specific tool chains for building, running and testing your code
This doesn't seem to be something a distro can solve beyond making it possible to install this stuff.
Maybe the closest is nixos, because it allows a lot of flexibility in setting up different development environments that are fully reproducible. Gentoo is also close, as it allows the same but in a different way (without the extent of reproducible guarantees).
I feel like there's just too many different programming workflows, to try to pre-install them.
Here on openSUSE, there's 'patterns' you can install, which are basically just groups of packages, and they've got some pre-defined patterns for programming:
I feel like that kind of goes in a more useful direction, although it's still partially questionable what those contain. For example, the Java development pattern comes with Ant as the build system, when Maven and Gradle are more popular, I believe.
I also have to say that I often prefer installing programming tooling in distro-independent ways, and ideally automated in the project repo, to avoid works-on-my-machine situations.
Of course, something like Git, Docker, VMs etc. tend to be stable across versions, and I might not care for having the newest versions, but even with those, I think it's good to install them on demand, rather than having them pre-installed. If the distro simply makes it a breeze to install them, that's ideal IMHO.
You could try Bluefin (Gnome) or Aurora (KDE).
https://projectbluefin.io/
It's an immutable OS based on Fedora.
They have a developer version with certain developer tools pre-installed.
The development environment is largely based around containers and virtual environments. eg. Using DevPod to run your software projects within developer containers instead of installing the tools directly on your host operating system.
Why? Well, because it's small. So Alpine isn't the programming distribution itself but rather the distribution for the container your run whatever you build inside of just because it's very VERY small (like... 5MB?!).
Obviously that makes sense only in some cases. For example for a frontend Web developer or a game developer (or a WebXR dev like me) it might not help much but otherwise,... maybe?
Anyway if you are into this kind of things check also Gitpod, it's about wrapping your dev environment inside a container then having it anytime, anywhere, including for other developers and facilitate their onboarding.
Not disagreeing, but if you're just looking for a small Docker image, might as well build a static binary and ship it without any distro at all. Or, if you really need shared libraries and other dependencies, you can build a docker image with Nix and not get anything other than the dependencies.
In my view, you need a distro that has up-to-date packages. It also helps to have repos that have all the obscure tools you are going to want to ensure compatibility with everything.
Those two criteria eliminate a lot of distros. Arch or an Arch derivative like EndeavourOS are my picks for these reasons.
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.
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.
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.
NixOS. It's really good for building multiple discrete environments specific to a development project, and it's done via a functional declarative language that's right up a programmer's alley. You can specify everything precisely to what you want for that environment including all dependencies and not have them pollute each other when you switch builds.
But it's a steep learning curve and the documentation could be better, but it's probably fine if you're used to learning new languages.
What I've learned is that using distro packages for dev always bites me in the ass at some point. Absolutely need v4.0.1 of something but your distro only has v4.0.0 ? Congrats you've entered upgrade dependency hell.
The best dev distro should be just be a kernel and sh. ;)
Gentoo. Literally the entire system is a build environment. Imagine a single environment that's capable of compiling thousands of different packages and managing dependencies etc.
No, but some are better suited for programming, because each distro has different packages in their repositories. I find Fedora to be very good when it comes to having basically every dev tool available in their repos. Arch is good too but too unstable for actual work. But keep in mind in most distros you can add separate repositories that contains the software you want. You can also use Homebrew that contains lots of dev tools as well
The last time I used arch it worked fine for 6 months then it needed to be scrapped because the network fully stopped working after an update. I've been on fedora ever since without a single issue. Arch is fine for personal devices where you can afford to spend half a day on troubleshooting a package that is too recent and straight up doesn't work because there's no real testing being done. I wouldn't put it on a work device simply because it's not a just works distro
Not that I know of. I do a lot of native development mostly on Mint and Endeavor. I use pretty much the same tools on both and get a nearly identical experience. I'd say just go with what feels good to you.
I think you’re better off finding tools which work for your particular language, application, workflow etc. For me I use nix and direnv to create directory based declarative package sets that load upon cd’ing to a project’s folder. This allows me to have exact versions of the packages I need regardless of system packaging or versions used in other projects. Some people prefer spinning up containers for this role, often using tools like distrobox. If the language you’re working in has good version management tooling then you can also just use that
Well, not exactly.
Any distro COULD be used for development and excel at it, but there are a few intresting options out there.
I personally use Fedora with KDE, but if you want to take it to a more advanced level, use arch or nixos.
If you want to make your OS, use gentoo or linux from scratch, but very niche and not recommended.
There's nothing like it, nor will it ever be, for a couple of reasons.
Programming is a long running task
Distros like Kali are meant to be used for quick tasks where you don't need data preservation (or when data preservation is a bad thing). Programming is the opposite of this, it's only about data (the program) preservation. Programming something that will get erased on the next boot is pointless on the long run if you need to program that again, and if you don't then what you're doing is not programming but something else that requires some programming.
Programming is a wide term
There are multiple languages/IDEs/Workflows/etc, ranging from fully free and open source to paid closed source, whichever you will use depends entirely on you, having all of that pre installed would be 99% garbage since you will only care about 1 or 2 of them.
Programming requires setup
Even if you had whatever workflow you use pre installed, to work on something you would need to setup git keys, install dependencies, compile the first version, etc... and that's all before you can start doing stuff. And you would have to do this again and again since distros like Kali are not meant to be installed (if they were they wouldn't need to come with all those packages pre-installed because you could just install the ones you cared about)