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.
It happened to me when I was configuring IP geoblocking: Only whitelist IP ranges are allowed. That was fetched from a trusted URL. If the DNS provider just happened to not be on that list, the whitelist would become empty, blocking all IPs. Literally 100% proof firewall; not even a ping gets a pass.
Technical debt means how much work it takes to update legacy solution to a modern solution. E.g. each time a new C++ standard is used, all code written with the old standard should be checked. The work time needed to do this is paying up the technical dept.
Now, if you are lazy, and didn’t clean up the code, used the easy and sloppy solution, next time you have twice the work to be done. So the dept gets worse, if you do nothing.
I touched a piece code that was +10 years old, according to git. Should I be scared? Will my change it survive??
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…
Me:
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.
It gets more cursed the more you look at it:
And you have bootstrapped an B compiler on that?