chameleon

You're most likely booted, otherwise you might need a live USB. Hopefully, the system isn't in read-only mode. What I'd recommend doing is:

cp /etc/fstab /etc/fstab.backup

To make a copy once. Then, nano /etc/fstab to run nano, a basic CLI editor. You can use the arrow keys to navigate and type freely in it. The hints like ^O shown on the bottom mean ctrl+o.

You'd use the arrow keys to go down to the line that probably says /dev/md0 /mnt/raid morecrap, put a # in front of it, press ctrl+w then enter to save. If that worked, ctrl+x to exit and try a reboot again.

Obviously can't promise this is "the" error preventing the system from booting, but it's generally a good idea to disable broken stuff like this to get the system working again, then fix it from there. Hopefully, this does the trick. Your RAID setup will not be activated on reboot after you do this but it's not going to permanently delete data or anything.

The RAID1 seems to be failing according to that screenshot. That breaks the "Local File Systems" task and since quite a lot of things tend to depend on that, many things usually end up failing in an annoying cascade failure. It's also failing with a timeout instead of a strict error, which is odd.

Either way, I'd try commenting that line for /mnt/raid in /etc/fstab for now and seeing if that makes the system boot. It's possible that journalctl -u dev-md0.service or systemctl status dev-md0.service might tell you more, but it's 50/50 if it'll be anything useful.

No, it comes together with a CLA being required to contribute. In other words, Canonical (and only Canonical) is still allowed to sell exceptions to the AGPL.

Yes, the post says there is no copyright assignment. That's extremely carefully chosen wording to avoid mention of the CLA which was made required in the same commit as the license change. It's "just" a super extended license that lets them do whatever, not assignment.

Not that high. Spotify uses some pretty tight compression (not good, just tight); most users get 96-128kbit/s AAC, premium can go a bit higher if opted in. That works out to about 16KB/s or 58MB/hour, assuming nothing's cached.

Bandwidth pricing very much goes down with scale, not up. But even the non-committed AWS pricing at Spotify's scale is 2 to 3 cents/GB. You end up paying way less than that with any kind of commitment and AWS isn't the cheapest around to begin with.

Aww, okay. I'll just have to go back to licking Switch cartridges then...

You can hardcode a specific version of nixpkgs, instead of a branch. With the new Nix CLI & flakes enabled you can do something like this:

nix run "github:NixOS/nixpkgs/b4372c4924d9182034066c823df76d6eaf1f4ec4#cowsay" "moo mooooooo"

That's the commit I'm seeing for nixos-23.11 today, and it should still give you that exact version of cowsay years from now.

Of course, the better option is to make a dev shell with flakes. Flakes come with a lockfile builtin that accomplishes the same effect, and there's no problems having different projects on different lockfiles/versions. It's a bit more work to learn, the Zero to Nix tutorials are pretty decent at teaching and come with examples though (ultimately most things are ~30 lines of boilerplate and a list of packages that you want).

And they're also deleting/deleted all classic Minecraft accounts from before that. They invented an incredibly weird and needlessly obtuse process to extend the migration deadline by 3 months (true final deadline is now mid December 2023), but that's seemingly it. Everyone not paying too much attention to their email just gets $30 worth of game deleted because of a completely arbitrary decision.

A biggie you miss is the toolchain: the compiler/binutils/linux-headers/libc/libstdc++ combination. The libc and usually libstdc++ are key components of any install. The other parts usually don't make it to non-dev-desktops, but the distro couldn't be made without them, so they're virtually always available as packages.

Only exception is if the entire distro is cross-compiled or it's made exclusively for containers, but those kinds of special distros break every rule imaginable anyway. Some might not even ship a bootloader or a Linux kernel by themselves.

Don't bother "securing" directories like that. The meaningful permission bit is the write permission on the directory holding the file. cat ~/.bashrc > ~/.bashrc.new; put-malware-in ~/.bashrc.new; rm -f ~/.bashrc; mv ~/.bashrc.new ~/.bashrc or the like will still work if you have write permissions to /home/username at all. Marking the file immutable with chattr +i as root might be slightly more effective, but realistically still not enough in a lot of cases as the parent directory can still be renamed. Not to mention you've only found some of the low-hanging fruit; your text editor most likely also has a few ways to accomplish arbitrary code execution in its config/scripting/plugin files but it absolutely doesn't stop there.

Don't bother buying old systems because they can have free firmware. Ever since Spectre, CPU vulnerabilities have made old machines completely unsuitable for high-security purposes time and time again. Not all mitigations are equally effective and with mitigations on, performance takes a massive hit on those 10 year old machines. If you can get a reasonably new system with free firmware, that's good, though.

Yum, smells like microwaved 'microwave-safe' plastic!

DSP doesn't have builtin controller support, so I'd be leery recommending it for Deck unless you're used to more complicated manual input mapping. Hardware-wise, it's more than capable as long as you don't go megabasing postgame.

DSP also doesn't do cloud saves, so you gotta be careful with your wineprefix.

I think most people don't realize how unusual their company structure is. It feels like it's set up to let them do exactly that. As far as I can tell, once you look past the smoke and mirrors, the board effectively controls both the non-profit and the for-profit.