Star Trek interfaces are great…. If the tech is there to back them up.

In this case… not so much.

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.

Subtitle: An Autobiography

Not only that, but raw horsepower and battery life are always in a delicate balance in any portable device.

There are practical limitations when it comes to current battery technology. Not to mention heat generation and dissipation that comes with more powerful hardware.

If only there were some easily identifiable common denominator…

The real question is…. WHY DOES AZURE DEVOPS STILL EXIST?!?!?

Personally, I use the very technical method of listening for the buzzer to go off…

I hate that everything has WiFi for no reason…

Which is why I often look at my 6 year old son and just say “Behave!”

He knows who I’m talking about.

“Kirk to Enterprise…”

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).

You know all those Cyberpunk books and movies?

Apparently we thought those were a suggestion instead of a warning…

I mean, that’s what the marketing folks at the hyperscalers would have us believe…

Amen

As someone else who was a kid in the 80s, I promise you that almost no movie that you or I saw in that entire decade was a kids movie.

I assume you mean fascist propaganda over and above the right wing rabbit holes that already exist on YouTube….

Ugh, this is terrible.

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.

Yep, my birthday is very early in April. Having two Easters in the same year of my life happens from time to time.