If you set up flatpak as --user, bringing your home directory over would be 99% of the job.

Huh, I thought that the initial run of Copilot systems were required to use a Qualcomm processor (with advanced NPU technology).

My solution is "have a large game collection, and move on to the next game". The odd bad game will likely get better in a future version of Wine. Proton 9-something even picked up support for some of the fussier Japanese VNs (but not well enough for IMHHW, alas).

I would gander that a "gaming distro" is more aggressive at chasing the latest video drivers, stability be damned.

Twitch dot tv

Snaps (and flatpaks) have a much better way of handling DLL hell than good ol deb/rpm/pacman. As such, each app is better able to chase the latest version of all of its dependencies, without worrying about messing up the libraries for anyone else.

Snap/flatpak also sandbox their apps, reducing the blast radius of exploited or bad apps.

My personal preference is to use flatpak, and set it up so that it is all --user. With a --user install, you don't need sudo to update anything. Use Flatseal to tighten up or loosen the sandbox, use Warehouse to roll back any broken updates. I don't think snap has any tools like Flatseal or Warehouse, which makes it the weaker packager.

Anything that can be installed as a flatpak, I do it there first. Then I can just pick up my home directory, drop it in a different distro, and almost all of my stuff follows. A distro becomes little more than "a kernel, a compositor, a baseline desktop environment, and some background daemons".

It's a miracle that the battery is still working at ten years. The most realistic thing is to just keep up with your backups, and be ready to dispose of that laptop the moment the battery starts swelling.

The fix is to make it a Ctrl key.

Btrfs. Just format as one big partition (besides that little EFI partition of course) and don't worry about splitting up your disk into root and home. Put home on its own subvolume so that root can be rolled back separately from it. You can have automatic snapshots, low-overhead compression, deduplication, incremental backups. Any filesystem can fsck its own metadata, but btrfs is one of the few that also cares if your data is also intact.

I would like to install a distro on a USB stick, without it doing something stupid to my internal drive's EFI.

Snappy Snake features -

Everything is now a snap. Your kernel and initrd? They're snaps now (requires an updated grub with snap mounter. An /efi partition of less than 20GB is no longer supported). Apt is now a symlink to snap. Procfs and device nodes are all snaps. Instead of "perusing the legacy web2.0 internet with an html browser", the new Canonical Snapium snaps you into modern digital snap-eriences powered by the Snapchain. The Linux CLI has been replaced with Gnome's "Drag-n-snap Editor".

Tell the drive to do a secure erase. If there are still bad blocks after that, it is absolutely garbage

Frankly you should never see bad blocks, but sometimes minor bad things happen and the drive has to tell you that this data is gone forever. If you write over those bad blocks at some point, the drive is supposed to remap them to spare blocks and carry on as if everything is okay. If it has run out of spare blocks, then the bad blocks stay forever. A secure erase might give the drive more wiggle room to re-allocate around a larger bad spot, IDK.

The most addictive game is "getting more games". Follow Wario64's discord, check prices at isthereanydeal, get the Epic freebies, mix and match bundles at Fanatical.

I think the best assurance is - even spies have to obey certain realities about what they do. Developing this backdoor costs money and manpower (but we don't care about the money, we can just print more lol). If you're a spy, you want to know somebody else's secrets. But what you really want, what makes those secrets really valuable, is if the other guy thinks that their secret is still a secret. You can use this tool too much, and at some point it's going to "break". It's going to get caught in the act, or somebody is going to connect enough dots to realize that their software is acting wrong, or some other spying-operational failure. Unlike any other piece of software, this espionage software wears out. If you keep on using it until it "breaks", you don't just lose the ability to steal future secrets. Anybody that you already stole secrets from gets to find out that "their secrets are no longer secret", too.

Anyways, I think that the "I know, and you don't know that I know" aspect of espionage is one of those things that makes spooks, even when they have a God Exploit, be very cautious about where they use it. So, this isn't the sort of thing that you're likely to see.

What you will see is the "commercial" world of cyberattacks, which is just an endless deluge of cryptolockers until the end of time.

In the coming weeks, you will know if this attacker recycled any techniques in other attacks. People have furiously ripped this attack apart, and are on the hunt for anything else like it out there. If Jia has other naughty projects out here and didn't make them 100% from scratch, everything is going to get burned.

How do you know there isn't a logic bug that spills server secrets through an uninitialized buffer? How do you know there isn't an enterprise login token signing key that accidentally works for any account in-or-out of that enterprise (hard mode: logging costs more than your org makes all year)? How do you know that your processor doesn't leak information across security contexts? How do you know that your NAS appliance doesn't have a master login?

This was a really, really close one that was averted by two things. A total fucking nerd looked way too hard into a trivial performance problem, and saw something a bit hinky. And, just as importantly, the systemd devs had no idea that anything was going on, but somebody got an itchy feeling about the size of systemd's dependencies and decided to clean it up. This completely blew up the attacker's timetable. Jia Tan had to ship too fast, with code that wasn't quite bulletproof (5.6.0 is what was detected, 5.6.1 would have gotten away with it).

*removed externally hosted image*

My $0.05 reading of it is that they want to hose down the build servers* and start clean, in case if the attacker escaped the sandboxing there.

* (the computers that compile all of the new packages from source, not web servers that are handing out finished deb binaries to the public.)

It can then go from a snap to a superior flatpak real quick.

"Oh, did I need to rebuild the initrd too? Shhheeeeit, can I do that in a chroot from a livedisk or something?"

apt info xz-utils

Your version is old as balls. Even if you were on Mantic, it would still be old as balls.