Some great points here, thank you!
Now that I have more time to post I can add more color to this. So basically we looked at, what does a cloud developer need?
Since Brian Ketelsen was one of the architects of DX we basically just literally copied his set up and decided “ok if someone were to get started in cloud native what do they need?”
Ok so bottom up, container runtimes. Podman is a critical component so it has to be there. Docker has to be there, one of the primary reasons is you should be able to copy and paste install instructions from existing READMEs on GitHub without needing to do anything special. We don’t want a “And on fedora atomic/bluefin systems do this” because people hate that.
Every single time I’ve copied and pasted a docker command from all the TONs of stuff on github it has worked fine on Bluefin. That’s a huge feature for us.
It’s also part of the reason for Homebrew, which does cause gnashing of teeth. I get it, we have gcc on the image just for this. Some day an ancient UNIX god will reawaken to claim my soul. It’s also the number one feature people tell me about in the survey and in real life. The fact is, so many Linux sysadmins use Mac and they are highly skilled people, the kind of people we need around here. So I cater to them with homebrew. And it’s also good, I always have the latest version of every command line tool I care about, and it’s automatic. Just about every cool tool I see trending on hackernews is already in homebrew and at the latest upstream version. This is a solved problem for me.
For the developer warts of homebrew, I agree, that’s why we strongly invest in devcontainers and just decoupling the entire thing from the OS.
Here is the top half of the page of tags from the official docker python container.
Like, done. My python needs are done. These things have over a billion pulls and lots of people use them. At the end of the day, I wanna use the thing that most people use. I want to be on the well trodden path.
On this previous point from the earlier in the convo:
Can’t install multiple versions of a package easily which forces separate environment managers like uv, rvm, etc, - You can skip all that stuff with nix.
I do not see the need to install multiple versions of a package on the same system because that’s an antipattern here. We use containers and tools like uv
. Whatever works for you. The reality of the world is that people specialize in separate ecosystems and those ecosystems will have package managers.
And those ecosystems will have specialists, and they are the ones creating the tools I need. So when they say to use pip, I use pip. When they say use brew, I use brew. Python people are loving uv
right now. And the things people use get tested the most. And on top of that these ecosystems are taking those same base images I showed above and making more specialized things on top of that.
One magical meta language to wrap that up just doesn’t line up with that world view, and it takes about 20 minutes for someone to make a bluenix with the image template so for us it’s more a matter of what we want our product to be. Also supporting nix turned our support structures into L1 nix support and we’re not willing to do that, we have our direction and mission set.
But to get back to the point (finally lol!) we provide a flexible system. I spent the first 2 years trying to get my distro packages just perfect with distrobox only to find later that I don’t ever want distro packages for my command line tools. I want the latest (like all my mac friends have) so now I roll with homebrew and I’m set. A python developer who doesn’t care about containers can also just use vscode with uv
or poetry
or whatever and be totally happy.
A Jetbrains user can install its toolbox and it comes with a copy of everything under the sun if you ask for it. And so on. Traditionalists can use distrobox, and the people who want to dnf install nodejs
on their OS will just never be happy here, so we don’t cater to that. Traditional distros will continue to exist for those folks.
The font thing is easy. We love fonts, but we don’t love setting up all this stuff, so for a developer experience feature we spent space on curated, high quality monospace fonts that the team loves.
People are going to complain about “bloat” for what amounts to like 2% of a modern disk for an entire OS. If we’re going to stare at our screens all day we might as well be happy. That’s an easy decision, and also another one of the things people tell me they love about Bluefin.
I mostly concentrate on the happiness of our core audience because many of our decisions were already made, which is why I started interviewing and writing down all the feedback for Bluefin way before we actually started. But it also evolves. uv
wasn’t around when we started, and developers move fast. So we can always adapt as needed over time.