You can't "just patch it" to make snap work with another store. Instead what you've done is invented an entirely different store, which you're now going to have to maintain. It is never going to be upstreamed to Canonical. You are going to be in a perpetual tug-of-war with Canonical driving snap development towards their own needs and not your own.
rotopenguin
joined 2 years ago
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.
Valve was using Debian way-back-when, but the pace of getting new stuff into debian proper is too glacial for Valve. Valve is putting a lot of work into "making the linux graphics stack rather good for games", and having those improvements integrated upstream quicker means that Valve can get to work on the next set of improvements.
Valve is still using Debian as the basis for their runtime environments for games (pressure vessel). Debian's slowness is great for providing a stable ABI for the parts that come into contact with (seldom maintained) game code. There is some amount of magic that goes into gluing the stable runtimes with rapidly changing stuff like Mesa.
It's not like it's terribly uncommon for some Earth species or other to go from sexual reproduction, to giving asexual reproduction another try. What invariably happens is that the daughters only sub-species does well for a few generations, and then gets completely wiped out by some disease. We're not having sex for fun, we're having it because "applying combinatorics to our genetics (particularly the immune system genes)" is the best tool we have to try to stay ahead of microbes.
Aha, thank you! That's just a weird enough concept to "attach to" a local QEMU user session (where virt-manager will be the guy spinning it off anyway) that I would never have seen it.
Every newbie article about virt-manager starts with a filled list of connections, so I was down to figuring that it's cleverly detecting a missing dependency or permission and silently eliminating list entries for me.
When I run virt-manager on Bookworm, all it does is tell me that "xen is not connected". There is nothing to indicate that KVM is anything that virt-manager might support, or why it currently doesn't.
The best I can do is to make a VM in gnome boxes, use "ps" to capture its command line to qemu, re-format that into something that I can put into a bash script, and edit in additional options that Boxes/libvirt absolutely refuse to support.
Most of the host integration features are better in Virtualbox. On the other hand, with qemu I don't have to look at VB filling the journal with ubsan errors (and wonder if its crappy driver is corrupting shit). If VB supported KVM, I would go right back to it.
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.
Oh god, the design of classic game controllers were all war crimes lol
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.
hint
It is one singular character. Everything else is fine.
This is a sliver of one patch, there is a bug here that disabled a build tool that breaks the attack. Can you find it?
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".