It has better specs than the 2008 laptop I retired last year (I was running Gentoo on that, but I don’t entirely recommend that unless you’re experienced with Gentoo and know what kind of setup to go with). Anyway, SNES emulation is less demanding than running a modern web browser, so your little beastie should be fine for that.
Eudev wasn’t spun up and then maintained for several years for no reason (it spun down again as the pressure dropped off). And you still can’t get the udev source from upstream as a separate tarball—you have to download the entire systemd tarball, even if you don’t want any of the rest of the contents.
Gentoo, across multiple machines. Started there, stayed there. Yes, it’s a bear to install, but once you’ve got everything sorted out, it’s rock-solid.
Heh. I’m old and my reflexes are dropping off. Plus, as a Gentoo user, I tend to reach for the command-line tools first.
That sounds like bad data got written to some config files, because a reboot should have corrected a simple bad handoff and restored the preconfigured state. Might have been interesting to see what xrandr had to say about those monitors at the time, and whether it could have fixed them.
Anyway, sounds like your side monitors got disabled, and rather than re-enabling them when you exited WINE, something in the stack decided they’d always been that way . . . but because they were still powered and connected, the monitors still said “hi” every few minutes, and then got identified and swatted down again. I doubt I would have had the hand-speed to re-enable them through the GUI the way you did.
Careful there, WINE Is Not an Emulator (yes, really, that’s what it stands for—back in the 90s, we thought that recursive acronyms were cool. See also GNU).
What you saw could indeed have been a bad handoff, assuming it didn’t persist through a reboot. If it did, then it sounds more like a KDE (or Wayland?) bug.
How would I blacklist the nouveau driver?
Create a file in /etc/modprobe.d/ containing the text blacklist nouveau (worked for me on Gentoo and for a friend on Ubuntu) or add a kernel parameter module_blacklist=nouveau to your bootloader. However, if you don’t have the correct proprietary driver, that won’t help.
After 20 years of Gentoo, I don’t see myself switching in the next five. Comfortable, capable, flexible.
I switched from KDE 3.5 (whenever that was current).
Terrifyingly, I think someone is still maintaining KDE 3.5 proper for OpenSUSE. Then there’s TDE, which is widely available. (But you probably mean 15-20 years ago.)
Not the same distro, but on my system, the relevant file is located at /etc/default/grub. Find the line that says GRUB_CMDLINE_LINUX, uncomment it if necessary, and add your kernel parameter to it (mine has GRUB_CMDLINE_LINUX="acpi_enforce_resources=lax", for historical reasons). Then run grub-mkconfig with appropriate arguments to regenerate your grub configuration.
Per the contents of my /usr/portage/distfiles, the original undivided package is ~500MB, making it the largest single package I’ve got on my system. Splitting it seems like a very good idea . . . but Gentoo generally prefers not to alter upstream tarballs, so I’m likely stuck.
If you’re getting a grub command line, then it’s finding the grub efi payload itself now, but can’t locate the kernel (or possibly the initram or something that’s supposed to be in it). Check your grub.cfg and try to confirm that it’s looking for the correct partition on the correct drive.
One possibility is that it has a degenerate UEFI implementation that will only recognize the efi “payload” if it’s in the fallback location—I had this problem with an older HP laptop. You can force grub-install to place the needed file in this location by passing the --removable switch (you may also need to pass --efi-directory=[dir]), or you can manually copy the file to EFI/BOOT/BOOTX64.efi on your EFI partition if it was already installed elsewhere.
If you dare, you can try temporarily killing the system’s swap (using the swapoff command) and see what happens. With no swap, the standard OOM reaper should trigger within a couple of minutes at most if it’s needed, and it should write an entry to the system log indicating which process it killed.
Note that the process killed is not necessarily the one causing the problem. I haven’t had the OOM trigger on me in many years (I normally run without swap), but the last time it did, it killed my main browser instance (which was holding a large but not increasing amount of memory at the time) rather than the gcc instance that was causing the memory pressure.
Hmmm. Random guess: does your machine have another audio output, possibly via HDMI, that you’re not using? This could be ALSA selecting the wrong device as a default, which would then propagate up through the stack.
Used to be that KDE would let you run other window managers than the default kwin. If that capability still exists, you might just be able to borrow Cosmic’s WM and implant it in your KDE session.
Had to look into this recently for similar reasons. My conclusion was that once you have macros involved, you can’t use anything but an actual copy of Excel. I’ll be spinning up a qemu VM with Windows to support Excel and the full version of Visual Studio when I get that far.
Not quite. Those are trackers: lists of bugs. If you open one, you’ll see a list of individual package bugs that are blocking these ones—up to a couple of dozen unresolved in some cases. Still, it isn’t that long a list, and a lot of the packages are minor or obscure.
Gentoo also offers it as an option. If you’re very bored and curious about what doesn’t work under specific versions of musl, you can peruse the Gentoo compatibility tracker bugs..
If using OpenRC is all it tales to be on the dark side, then I’ve been there since before it was cool.