Yeah one nice thing about nixos is that their package search website is really good. You can also search for config options with examples.
jlh
joined 2 years ago
I mean the Arch wiki mostly works on NixOS too. The problem with NixOS documentation is that there aren't many examples for the Nix language itself.
The nice thing is that NixOS will keep your setup and all your tweaks if you ever need to reinstall. It's designed to solve that exact problem.
One way of switching over would be to carry over your homedir and just starting with migrating packages and config as a first step.
Yeah, it's a distro of kubernetes.
Most apps run best as a container, but for appliances and legacy apps they have Openshift virtualization which runs VMs in the cluster by running KVM inside of docker.
The open source tech there is called Kubevirt. All VMs are 1st class citizens in the kubernetes API, so it is actually easier to run than VMware/Proxmox if you already have a Kubernetes cluster and you're not doing complex stuff with qcow images or VM migrations.
I use both containers and VMs a lot with Kubernetes at work.
Everybody is moving to Openshift or public cloud
Hate is never needed
Try using the monado runtime instead of SteamVR.
See Kawane Rio's 15 minute lightning talk about VR on Linux from this year's FOSDEM:
Small detail, those are pdf metadata tags, not EXIF metadata.
EXIF is based off the Tiff format and is one of three ways to store metadata in a jpeg file. XMP looks pretty similar to PDF metadata tags, but the tags shown mention PDF.
Isn't cloning font legal though? As compared to copying floppies which is punishable by death?
Quick google search points out this blog post for tips and tricks for prototyping stuff like game features in Rust: https://corrode.dev/blog/prototyping/
Definitely something that I'm going to try when I have to time to get back into Rust. Probably good advice for most people who are unhappy with Rust. Being attracted by Rust's unique optimization tools too early on seems like a big beginner trap.
Not here to doubt their decision, they had good reasons to switch.
For the sake of discussion though, would it have been easier though if they had focused more on abstractions with their code architecture? I haven't done any serious projects in Rust, but those issues with low-level coding and API thrash seem like more of a code architecture problem. Like, that example of a function signature seems like they should have bundled up their paperdoll logic more into a single "PaperdollLoadout" struct and moved that into a separate game logic function separate from the view related code. It's more code to write, but that's the up-front cost of strict type checking.
Modding and learning definitely seem like a big barrier for Bevy overall though.
One decision i will question is picking Unity over Godot, though maybe they were still reeling from the learning issues on Bevy.
Deaf people drive just fine