Yep, I’ve had times where the debugger was hiding the race condition that was the actual cause of my problem.

I agree. This whole project deserves a good bit of skepticism, on political, social, and technical grounds.

Bluefin-dx user here. This is the way.

That’s kind of what the ublue project is doing. Bazzite is a part of that, of course. But it also has more “normal” versions like Bluefin (gnome) and Aurora (plasma).

Yes! This what I usually do. I will develop on the host using tools installed via Homebrew, then package/build/test via docker.

And to be clear, I really love the ideas behind Bluefin and use it every day. I’ve just kind of given up on devcontainers, specifically.

Honestly, even with VSCode, devcontainers are kind of just ok, at best.

They are very fiddly. The containers keep running when you close VSCode (which makes sense, and sure the resource usage is minimal, but it’s damned annoying) and you have to stop them manually. Meanwhile the commands in VSCode to work with/activate the containers are not super clear in terms of what they actually do.

Oh, what’s that? Need a shell inside the container you’re working in for testing things out, installing dependencies, etc.? Well, I hope you pick the right one of VSCode’s crappy built in terminals! Because if you want to use a real terminal, you are stuck with the crappy devcontainer CLI to exec into the container. A CLI that is NOT up to date with, or even includes, all the commands for devcontainers in the editor (which is what makes working with them in other IDE/editors such a pain in the butt…).

And this gets me…. What? A container I can share with other developers, sure, but it’s very likely NOT the container we are actually going to deploy in. So…

Yeah, I’ve also had a lot of frustrations with devcontainers in Bluefin. I really like what the Bluefin project is doing. The reasoning behind it makes a lot of sense to me. But devcontainers are kind of pushed as the way you “should” be writing code on Bluefin and it’s…. not great.

They do have Homebrew and Distrobox though, which helps a lot. I have ended up doing most of my development work on Bluefin on the host system with tools installed via brew, which is kept separate enough from the rest of the file system to still keep things tidy.

Overall, I think Bluefin is great and it, or something like it, may very well be the future of Linux… but the future isn’t here just yet and there are some growing pains, for sure.

I the context of Linux and self-hosting “prepping” is usually more about maintaining services you find useful in a way that you can do it yourself, as opposed to relying on Google or Amazon (etc) who could pull the rug out from under you at basically any time.

I might be in the minority, but I get more excited about the idea of maintaining/working on some creaky old legacy code base than I do about the idea of starting a new project from scratch.

I love doing that…

Hmmm, interesting. I like brew, for sure. And devcontainers worked ok for me when I was working on something by myself.

But as soon as I started working on a side project with a friend, who uses Ubuntu and was not trying to develop inside a container, things got more complicated and I decided to just use brew instead. I’m sure I could have figured it out, but we are both working full time and have families and are just doing this for fun. I didn’t want to hold us up!

Our little project’s back end runs in a docker compose with a Postgres instance. It’s no problem to run it like that for testing.

Maybe a re-read of the documentation for devcontainers would help…

Personally, I have found the developer experience on Bluefin-dx (the only one I’ve tried…) to be…. mixed.

VSCode + Devcontainers, which are the recommended path, are pretty fiddly. I have spent as much time trying to get them to behave themselves as I have actually writing code.

Personally, I’ve resorted to using Homebrew to install dev tools. The CLI tools it installs are sandboxed to the user’s home directory and they have everything.

It’s not containers - I deploy stuff in containers all the time. But, at least right now, the tooling to actually develop inside containers is kind of awkward. Or at least that’s been my experience so far.

I think the ublue project is fantastic and I really like what they are doing. But most of the world of developer tooling just isn’t there yet. Everything you can think of has instructions on how to get it going in Ubuntu in a traditional installation. We just aren’t there yet with things like Devcontainers.

I’ve definitely had the experience of something being broken in Prod… and no one can reproduce it in Dev.

Guess where we are fixing it!?

Yes, though traditional point-and-click GUI apps will also be rendered according to the same rules.

However, a lot of fans of tiling window managers also use things like terminal-based file mangers, have relatively well developed Neovim configs, etc.

So, it’s kind a whole THING that some folks really enjoy.

Veronica is awesome and deserves a bigger following, no doubt.

I use Aurora (the KDE version) as a software dev/ gaming machine. It’s great!

Yeah, I do all my development in WSL2 (Ubuntu) at work every day. I use VSCode on the Windows 11 host. It’s great!

Would I prefer to use Linux natively? Sure, but I also have to support some Windows-only legacy code and a D365 environment or two, so Windows makes sense.

I think that, in many cases, “what” and “why” are very similar to each other or are closely related.

I’ve had an experience like this on more than one occasion - I come into an established code base for the first time. I’m working on a new feature/refactor/bug fix. I am reading through a function that is relevant to me, scratching my head a bit, and thinking “I think I see what this function is doing, but why did they do it such a screwy way?” Often there are no comments to give me any clues.

In the past, I have foolishly changed the code, thinking that I knew better… But what often happens is that I soon discover why my predecessor did something that looked so weird to me. They weren’t stupid - there was a reason for it! And then I end up putting it back…

Point being, in a situation like that the “what” and the “why” are going to have a lot of overlap. So, personally, I try to write comments that highlight assumptions that won’t be obvious from reading the code, external constraints that matter but don’t actually show up in the code, and so on.

I am far from perfect at it and I probably don’t write enough comments. But when I do, I try to write comments that will be reminders to myself, or fill in gaps in context for some hypothetical new person. I try to avoid comments that literally explain the code unless it’s particularly (and unavoidably) complex.

Glory to you and your house!

“Why” comments make more sense as application complexity grows.

You also have to consider interaction of the code with other external systems - sometimes external APIs force you to write code in ways you might not otherwise and it’s good to leave a trail for others on your team (and your future self…) about what was going on there.

I know this may be an unpopular opinion on lemmy, which leans so heavily towards Linux and FOSS, and I’m a Linux user myself but….

I actually really like C# and .NET (the modern cross-platform version anyway).