I'm quite sure that all gigabit+ ethernet auto-negotiates. There is no shared ether, there are no dedicated tx/rx pairs anymore. It's all point-to point and constantly negotiating to make the most of every wire it's got.
rotopenguin
joined 2 years ago
A dumb little stick is fine for the occasional "fix something up" or "take a snapshot of a Windows drive because dd is objectively better than anything that Windows itself could do". A live iso distro precludes me from adding a handful of other useful tools.
Late breaking edit : What I ended up doing was formatting a stick as small EFI / 5GB btrfs / rest exfat. Chattr +c the btrfs, and debootstrap in there. Put rEFInd on the efi and tell its conf file about the stick (or maybe it'll detect). Put non-free-firmware & stable-security into apt's sources.list. In a chroot shell, apt get live-task-non-free-firmware-pc gdm3 systemd-timesyncd linux-image-amd64 locales gnome-terminal. Add other tools to suit taste. Fix up the fstab, make /tmp tmpfs, make the exfat mount nofail. With btrfs compression, I can have a gnome environment inside of 2.5GB. It would be even more smol if I could figure out booting directly into Weston.
I would like to install a distro on a USB stick, without it doing something stupid to my internal drive's EFI.
I can kinda see "shot an old horse or two" as being a positive thing, okay you got over the squeamishness of it and did a sick animal a mercy.
Winging a goat and gosh I gotta go get more ammo to finish this one off, well that's starting to get a little peculiar.
LIKING IT SO MUCH THAT YOU WENT OUT AND GOT A NEW PUPPY SO YOU COULD DO IT AGAIN, well hoooly fuck we are getting into something entirely else now aren't we?
The magic missile knows where it is at all times, because it knows where it isn't.
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".
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.
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.
I think that the Deck is able to connect as a device (MTP or CDC?), but there has been trouble with that so the current OS disables it.