I think the difference with Dolphin is that it now emulates an extinct system(s), so it cannot possibly compete with the actual thing. They did have a close call last year, if I remember, and they pretty quickly went into “jettison all illegal shit out of the code base NOW.” -mode.
This cannot be an coincidence. I may actually finished something this time.
I clicked the link with SUS knob set to 900% and the other hand on the main breaker. It did not disappoint.
That’s because people are now aware of all of this shit happening, and some discreet day, just flip off the power from the house, doing indescribable things, and listens to the voices in their heads. And nobody will know.
I had a similar debacle, when I managed to corrupt a btrfs file system to point it wouldn’t mount again…
I was preparing it to have as my main system on bare hardware. I had accidentally mounted the same block device simultaneously in the host and guest: kablamo silent corruption and all 5 hours of progress lost.* :(
*shred the guest VM, host was ok.
On arch, UEFI boot vars are mounted at /sys/firmware/efi/efivars. It’s unwise to rm -rf them…
X Y problems are absolutely crud when you have to ask first the stupid version to be able to ask the actual question about X.
GameBoy Color with a single game: Pokémon Red.
Next time I was able go to the shop they had upgraded to GameBoy Advance and no GB/GBC games were to be never found again. It was the best/worst thing I ever got. :'(
Please, never run plain “sudo make install” on a package managed system. With linux from scratch it might make sense… Doing so will “install” the thing (copy the files), but the copied files are foreign to the package manager. You cannot easily undo this, and can cause issues in future.
You had a compiler error about missing header file, libXft is from Xorg project. “devel” versions of packages usually provide these files.
st is from suckless project so it doesn’t need much to be “installed”: copy the built binaries into ~/bin/ or /opt/ and set your user PATH to look into those dirs. Check your user env if you need to modify the PATH.
I’m considering to replace the TIM (repasting) + thermal pads at some point… The card is now ~5 years old, and if the paste goes bad that would be end of it. The dust that all boards accumulate overtime is also a risk factor of how long components last.
Radeon RX 580 until the VRAM dies to the idle @50°C temps or the support is removed from the kernel…
More likely a group of neurons, and they fight the rest of the network to try get more basil. And within single cell that shit is hard-coded into the genome.
If you clicked, please purge YT history and apply amnestics to your ears and eyes.
The video link 100% cognitohazard. DO NOT CLICK.
The video link was surprisingly SFW. My expectation was piercing a nail through my skull make me UwU.
I almost posted comment about this but I had to keep it short. The Nvidia has an problem with their driver tainting the customers kernel/system which renders the customer in bad situation. (Of not being able to get support from kernel devs)
The proprietary taint is there for exactly for this reason:
Nvidia solution to this is breaking the kernel license terms and acting like illegal smugglers in-order to access those sweet sweet GPL-only kernel APIs as lazily as possible. I would say that this is just arrogant and greedy way of doing software development. On top of this the kernel devs get all the blame for their vigilantly of trying to exercise their own license terms.
I think if nvidia would not be this arrogant and vile to the kernel devs, they would already have an proper kernel module that could co-exist between the GPL and proprietary code. If the proprietary code is implemented only in user-space/firmware they can keep their secrets: The user-space <-> kernel-space is an boundary where kernel GPL ends. Implementing such thing would not be easy, but I don’t regard it being impossible: look at android.
In extreme: If the hostility continues, kernel devs just might be forced to go invent an corporate blacklist that goes against all principles of co-operation.
Others slightly more sane hw vendors, probably thought: fuck it. It is more profitable to push some FOSS code into the public than keeping the entire thing an trade secret. (I assume this results in the weirdly large firmware blobs that obfuscate and separate the actual hardware from the FOSS drivers)
EDIT: I read more about this issue. From proprietary code vendors viewpoint the current kernel is kind of “GPL or gtfo” situation. Linux kernel doesn’t really have an internal stable ABI for modules/drivers. Implementing such thing would require (partly) dropping the monolithic design of the Linux kernel… Such interface would be then able to added to the GPL exemption of syscall users. This would open such big can of worms that it looks to be impossible.
After 362879 wrong answers you will pass. Or after 2,0922789888×10¹³ tries if it’s a fancy 4x4 grid.