Yep. At one place I worked, we did a big off-site disaster recovery exercise every year.
Most of the time it went fine, but there were multiple years where a restore didn’t work due to an issue with one or more tapes. Either the data and/or indexes couldn’t be read, or the tape physically failed during the restore.
Backups aren’t backups unless they’re tested.
I guess that heavily depends on the games you’re playing
I think this is the key thing.
If you’re always buying the newest GPU to play the latest tech- envelope-pushing AAA title that requires the latest greatest driver, then you’re probably not going to have a good time with gaming on Debian.
But some of us don’t care about those types of games, or maybe in some cases we do but are willing to wait a while to play a particular title (hello Patient Gamers). In that case Debian is a nice, rock solid gaming platform.
Anecdotally, I probably do 85+% of my gaming on Debian (the rest being my steam deck). And it works fine for me because of the types of games I play and/or how long I tend to wait before getting new titles (giving Debian time to catch up).
It’s definitely not for every gamer, but I don’t think it’s as unusable for gaming as people often suggest.
If you want true for empty strings, you want -z not -n
if [[ -z "VARIABLE1" && -z "VARIABLE2" ]]; then
echo "OK"
fi
8 is Clean Code by Robert C Martin (Uncle Bob)
19 is Introduction to Algorithms (commonly referred to as CLRS,)
If you don’t have an Intel CPU, then you shouldn’t need it. At least, I think it’s only for CPUs and not for other intel-based devices (NIC, graphics, whatever).
It’s prompting for upgrade because it’s already installed. It’s recommended (but not required) by initramfs-tools, so that’s probably why it’s installed (recommended packages are installed by default). oops, read that wrong. Intel-microcode recommends initramfs-tools.
You may want to run
apt-rdepends intel-microcode
to see what pulled it in.
But you should be able to uninstall it, and then it won’t prompt you any more.
This is what happens Larry, when you find a stranger in the alps.
This pic made me smile.
I haven’t been to DebConf since before COVID, but I definitely recognize a few people in that pic.
I’ve been using Debian since 2000 (potato).
I’ve occasionally had to use other distros for work (Red Hat or Ubuntu, typically), or to verify/troubleshoot bugs reports in upstream packages.
But my preference is Debian all the way, for servers or workstations.
It’s stable, and it has a great community. Also ideologically speaking, it has the Debian Social Contract and Debian Free Software Guidelines.
Ah, ok. I guess I misunderstood.
I’m afraid I don’t have any other suggestions that haven’t already been made elsewhere in the thread.
Best of luck, and I hope you get it figured out.
Shot in the dark here…
You said that blacklisting the module brought back your device, but not the sound. Is it possible that pulse is selecting the dummy as the default interface?
Before reloading alsa and restarting pulse - If you go into pavucontrol and change the input/output devices to your sound card, does the sound start working?
If that’s the case, then you should be able to edit your pulse config to force your audio device to be default, regardless of whether or not the dummy is present.
(No idea about the dummy device, sorry)
Back in the 90s, Windows NT had a POSIX compatibility layer that you could enable (it wasn’t enabled by default).
I have sort of had enough of copy and pasting commands I find on the internet without having a good understanding of how they actually work.
One thing you could do is start trying to understand those commands.
Read the man pages or the documentation to figure out what the commands are actually doing. Once you have the “what” , you can dig deeper to get to the “why” if it isn’t obvious by that point.
After enough of that, you’ll go to copy/paste and already understand what it’s doing without needing to look it up again.
Then from there, it’s a matter of building the instinct to be able to say “I need to do X, so I’ll use commands Y and Z.”
Caveat: I’ve used LUKS quite a bit, but never to do exactly what you’re trying to do, so the following is a guess.
If the root disk was the encrypted one, the tooling would add scripts to your initramfs to handle the prompting and unlocking at boot.
Since it’s not the root, those scripts may not be getting added.
I’m not sure about the “right” way to force it to add them, but you should be able to manually tweak your initramfs setup to add them.