Maybe we’re now at a point where it’s a good choice for more techy people to use, and that adoption will mean more work gets done on it.

I installed it because I wanted to see how well it would run games. But, I haven’t actually played many games on it, not because they don’t work (they work great), but because I’ve found it’s so good at everything else too. It made it easy to get around to some projects I’d been putting off.

My machine plays all kinds of fairly recent games extremely well, but Microsoft is ditching Windows 10 support in less than a year, and has decided this machine doesn’t qualify for Windows 11. I bet there are lots of other people in the same boat. Bazzite doesn’t have to be perfect, but if it can be better than throwing away your old machine, there could be a lot of people switching soon.

Yeah, +1 for Bazzite.

It looks like it’s really designed for Linux beginners. They’ve done a solid amount of work sanding off the rough edges.

As someone who has been using Linux for decades, I’m also impressed with it for a development system. I chose Bazzite because I wanted to be able to play games easily, but since I installed it a month or so ago, I’ve barely played any. I’ve installed a few to make sure they work, but I got interested in another project once I installed it, so for me it’s been a machine used to set up and administer a Kubernetes cluster, as well as doing some Go / Javascript development.

In the early 2000s, I was one of those guys who ran Gentoo and liked building all my own software on my own machine so that it was perfectly tweaked for what I wanted to do. But, these days, I really like having an OS that’s stable and gets out of my way, so I can focus on more interesting things.

Bazzite, a gaming-focused Linux distribution, is designed to work really well with Steam. One drawback is that if you have a game installed in Windows on a Windows drive, you can’t use it from Linux steam. But, there is a way to have games accessible to both operating systems. I haven’t done this, yet, but I’m probably going to try it this week.

It involves installing a Windows driver that supports BTRFS partitions.

Here’s the video guide I found.

If OP is a gamer and not too comfortable with Linux, Bazzite is a good choice of distribution.

It’s a so-called “Atomic” distro. Basically what that means is that it works more like Android / iOS than Windows or a traditional Linux distribution.

The base system including drivers and key applications is built as an image by Fedora. Every 2 weeks or so, they release a new one, and Bazzite users get the new one the next time they reboot. Everything in that base image is tested to work together, so you don’t get weird incompatibilities. You can still install all the other software you want, but you tend to do it using Flatpaks rather than rpms/debs. (For someone who doesn’t know what that means, Bazzite is a nice OS because that’s something you don’t need to learn right away.)

Bazzite is meant to be something that you can install on a SteamDeck, or another handheld gaming PC, but it also works great for desktop machines. But, because it’s meant for handheld machines, they’ve worked extra hard to sand away some of the rough edges.

If you’re a more advanced user, Bazzite is still good because you can still do almost everything you’d do on a normal distribution, you’re just discouraged from doing things that affect the base image because it makes updates slower and means they’re not guaranteed to work. I actually really like some of the things you’re encouraged to do in Atomic distros that you wouldn’t do normally. For example, using distrobox as a way to install certain kinds of dev tools. I currently have one project I’m running in an Ubuntu distrobox and another I’m running in a Fedora distrobox. It keeps some of the tools isolated to the “box” where they’re needed. I haven’t used Fedora much lately, so it’s fun to have the more familiar Ubuntu environment in one, and then the other one where I can experiment and learn.

For someone who doesn’t play games, Bazzite probably isn’t ideal, but I’d still recommend an Atomic build. There are downsides, but unless you’re the kind of person who really likes building their own kernel and making sure it’s optimal for their system, it’s so nice to have a stable base image so you can focus on the other stuff.

I hate these. You don’t need to program for very long before you see one of these. And, you get used to the idea that when it says there’s an error on a blank line, that it means something isn’t properly terminated on one of the previous lines. But, man, I hate these.

At the very least, you’d hope that by now compilers/interpreters would be able to say “error somewhere between line 260 and 265”. Or, more usefully “Expected a closing ‘)’ before line 265, opening ‘(’ was on line 260”.

Error on <blank line> just pisses me off because the compiler / interpreter should know that that isn’t true. Whoever wrote the compiler is a seasoned developer who has been hit by this kind of error message countless times. They must know how annoying it is, and yet…

Was it Jen? She was entrusted to take care of the Internet by Roy and Moss, and she did a piss-poor job of it.

My favourite story about aircraft design about some of the design mistakes on the F-16 fighter.

The F-16 was the first fly-by-wire fighter. They didn’t have much experience with it, and tried out some new things. One was that instead of having a stick between the legs of the pilot they used a side stick. And, since everything was fly-by-wire they didn’t need the stick to mechanically move. They decided they’d just use a solid stick with pressure transducers, since it was simpler and more reliable than a stick that moved.

The trouble was that the pilots couldn’t estimate how much pressure they were using. This led to the pilots over-rotating on take-off (pulling back too hard). Even funnier was that at early airshows, when the pilots were doing a high-speed roll, you could see the control surfaces twitching with the heartbeat of the pilots as they shoved the stick as hard as they could to get maximum roll.

That led to them adding a small amount of give to the stick, essentially giving the pilots feedback on how hard they were pushing the control surfaces.

Another more subtle issue with the design was that originally the stick was set up for forward, back, left and right aligned with the axes of the plane itself. But, they discovered that when pilots pulled back on the stick, they were pulling slightly towards themselves, causing the plane to also roll. So, they realigned it so that “pulling back” is slightly pulling towards the pilot’s body, rather than directly along the forward / backward axis of the plane.

There was a listener question on a science podcast recently that asked about how the temperature changed on the moon during the recent solar eclipse.

They almost got what a solar eclipse was, but not quite. During a solar eclipse, the moon gets between the sun and the earth, blocking the light getting to the earth and casting a shadow on the earth. The side of the moon facing the earth is completely dark because the thing that normally lights it up (the sun) is completely behind it. But, the back side of the moon is getting full sun and just as hot as normal.

I think part of the problem with understanding all this is that the sun is just so insanely bright. Like, it’s a bit hard to believe that the full moon is so bright just because it’s reflecting sunlight. It’s also amazing that the “wandering stars” (planets) look like stars when they’re just blobs of rocks or gases that are reflecting the insanely bright light of the sun.

It’s amazing if you think about it. Light comes out of the sun in every possible direction. A tiny fraction of it hits the surface of Mercury, and only some of that light is reflected back out. The light reflected from Mercury goes in almost every direction. A tiny fraction of it hits the earth. But, even with that indirect bounce, it’s bright enough to see with the naked eye.

When I first code something up, I think of it as a first draft, and I expect maybe 5ish typos / brainos per 100 lines. Only a few times in my life have I finished writing a few hundred lines of code, tried to compile / run it, and not seen at least a few errors.

When I don’t see errors, it’s almost always because somehow I managed to not compile / run the code at all. Like, one of my typos / brainos managed to cause it to skip that entire new block of code. Only once or twice has it happened because I actually wrote error-free code the first time. And, let me tell you, that perfect code sucked up so much more time than the more typical bad code.

With the bad code, I see the various errors, quickly fix them, and those errors convince me that the compiler / interpreter has actually seen all the new stuff and judged it. But, with perfect-from-the-start code, I now have to go in and throw in print statements, or step through a debugger to convince myself that yes, the system actually made it into that function and actually did execute those statements.