I set up a very straightforward Godot dev environment yesterday using toolbox which is built on top of rootless Podman.

• Create a new fedora toolbox
• Enter toolbox
• Install DotNet dependencies, git, etc with dnf
• Install Godot binary from release page
• Turns out there were other dependencies I needed
• Godot wanted a few Wayland libs on the container, so I installed Weston (maybe overkill)
• Godot wanted libxrandr so I added that too
• Godot just works ™

The nice thing about toolbox is that it uses my native host Wayland compositor. So whatever I have running in the toolbox can be interacted normally through sway (my host WM).

You can either distribute a container image with your given toolbox configured, or just document the setup steps.

I once had a directory in /tmp called etc which contained subdirectories for something I was migrating.

I thought that I was in /tmp when I ran rm -rf etc… I was actually in /

Proliant G9 is an EoL server that hasn’t been sold since 2018. Meanwhile, Debian bookworm released last year. I’d be surprised if the problem were that your installer gave you a kernel that’s too old.

What is the output of ip addr show?

It might also be worth ruling out low-level issues:

• Check for anything strange in the BIOS related to disks (fwupdmgr can automatically install BIOS updates from a live Linux session. I don’t know if Bazzite does this)
• Try using a different SATA port
• Run some SMART tests on your drives

To be pedantic, Ford’s threat is to “rearrange [the computer’s] memory banks with an axe”

The countdown is until he starts doing it.

A much better idea than when I tried to organize my restaurant with hashtables.

It was too much for the waitstaff, who had to reindex the floor plan every time they added or removed a plate.

On the plus side, delivering the right food was always O(1).

The problem with chromebooks is that the base specs are pretty shit. A lot of them have 4 GiB of RAM and maybe 16GiB of disk if you’re lucky.

They were designed to be thin clients to connect students to the internet, and little else. Maybe they could be hacked into something useful, but I don’t think it’ll ever make a good PC. They were always destined for the landfill.

Meanwhile, the best thinkpads were quality machines back when they came out. IMO, that’s why they’re still so versatile today. Free software can’t fix bad fundamentals.

Not sure what motherboard you have: Most consumer boards only support “FakeRAID”, which requires a kernel driver to actually function. Good luck finding a vendor who wrote a driver for Linux.

I’d definitely recommend software RAID instead, as you’ll have better support. I like btrfs, so I’d recommend you set up your new drives to use a btrfs RAID configuration. mdadm is another option, if you really like ext4.

Are you an emacs user?

Try org-roam. It’s a similar system to obsidian, but fully open source. You have all the note taking techniques of org-mode, and all the scripting power of emacs.

As an emacs user, I use M-x man. All my standard keybindings make finding what I need very easy.

Of course, it’s not so fast if you aren’t already in emacs.

Barony is fun as hell. Engine is FOSS, but the default game assets require purchase.

You’ve laid out one potential development cycle: FOSS from the get-go, and open collaboration welcome.

However, that’s not the only way that a FOSS game might be developed. The code could be freely licensed, but the upstream developers refuse to accept outside patches. In that case, there’s one “original” and then if you don’t like it, build your fork.

Alternatively, a game could be developed entirely in-house under proprietary licenses, and then only made FOSS upon commercial release. Contributor patches could improve the project, but conception of the game would be entirely the domain of its original developers.

How about writing a script to automate the deletion, thus minimizing the chance of human error being a factor? It could include checks like “Is this a folder with .git contents? Am I being invoked from /home/username/my_dev_workspace?”

In a real aviation design scenario, they want to minimize the bullshit tasks that take up cognitive load on a pilot so they can focus on actually flying. Your ejector seat example would probably be replaced with an automatic ejection system that’s managed by the flight computer.

It would have to iterate over all saved keys, which sounds rather inefficient to me and potentially unsafe (timing attacks etc.)

sshd only checks for matches in the user’s authorized_keys file, not system wide.

Reminds me of an early Uni project where we had to operate on data in an array of 5 elements, but because “I didn’t teach it to everyone yet” we couldn’t use loops. It was going to be a tedious amount of copy-paste.

I think I got around it by making a function called “not_loop” that applied a functor argument to each element of the array in serial. Professor forgot to ban that.