There are lots of problems here. First, if you have to “hack” something to get the code, then it likely invalidates your own defense that you thought you were allowed to release it. Second, even if you can prove that nVidia knows that they should have to GPL their code, you still have no legal right to hack something to get it. If the hacking is illegal, then it’s illegal, even if it’s done to enable an otherwise legal activity.
For most people, principle takes a backseat to pragmatics. If your livelihood is training ML models on thousands of nVidia cards or whatever, you care less about who to be mad at and more about not laying off your staff and shutting the doors. You can’t replace nVidia. You can replace the latest kernel.
The userland differences are not too great, but I would assume a kernel module as significant as a modern GPU driver is pretty deeply tied to Linux’s kernel internals.
That’s definitely not the norm. Used to be that installing Windows would wreck Grub, but you just needed to but a rescue disk and reinstall Grub one time to fix it. Most people dual booted for decades without any issue there.
It’s been a while since I’ve had a Windows machine, but doesn’t Windows index the content of files as well as their names? If so, that would have fairly profound differences from slocate.
I think the main issue with Arch comes if you try to use it like Debian Stable. Like, if you don’t run pacman -Syu for a year, you probably won’t have a bootable system the next time you try. How about six months? My guess is you’d still be stuck fixing shit. Where is the safe “X” in “as long as I update every X, I’ll be fine?” Who knows. That’s not a very well-defined problem.
I sort of understand the issue here. I use Arch because I’m picky about system things, and it seems to require going against the fewest strongly held platform opinions in order to get it the way I want it. In an ideal world, I’d get it set up that way and not need to touch it very much afterwards. Arch requires frequent touches. Fortunately, almost none of them require any real mental energy, and I’m willing to do the occasional bit of “real work” if needed to keep it going, but that’s a trade-off that may be more painful for some than others.
So your solution on Windows requires me to move all my files out of where they belong to process them? How do I get them all back when I’m done?
I knew how to write that find command. Didn’t need to search for anything. And because I know how to do that, I can also search for every pdf file modified since last month. I can spit out a list of the gps coordinates for every photo I’ve taken, ordered by latitude. I can find every Python script on my computer that uses Pandas. I can do a million things that boil down to “find every file that matches some complex filter and do something to it”, and I learned one tool. I don’t need to learn one point and click app that converts comics, one that messes with photo metadata, etc.
I can sympathize with the idea that there’s a high learning curve. And there’s nothing wrong with trying to provide ways for people to use their computer that require less knowledge. But recognize that you’re asking for a crutch here.
I accept that I’m in the minority on these things, but I value simplicity really highly, and I mean “simple” as a very specific concept that’s different from “easy”. It can be harder to resolve library dependencies on a system where everything is installed using the native package manager and common file systems, but nothing is as “simple” as ELF binaries linking to .so files. Nested directories branching off of / is “simpler” than containers.
Do I have any practical reason for preferring things this way? Not really. There are some ancillary benefits that come from the fact that I’m old and I already know how to do more or less anything I need to do on a Unix system, and if you tell me I need to use flatseal or whatever, I’d rather just use users and groups and tools that have been fine for me for 25 years. But that’s not really why I like things this way. I have no issue with embracing change when it otherwise appeals to me --I happily try new languages and tools and technology stacks all the time. What it really is is that it appeals to the part of my brain that just wants to have a nice orderly universe that fits into a smaller set of conceptual boxes. I have a conceptual box for how my OS runs software, and filling that box with lots of other smaller little different boxes for flatpack and pyenv and whatever feels worse to me.
If they solved practical problems that I needed help solving, that would be fine. I have no problem adopting something new that improves my life and then complaining about all the ways I wish they’d done it better. But this just isn’t really a problem I have ever really needed much help with. I’ve used many Unix systems and Linux distributions as my full-time daily use systems since about 1998, and I’ve never really had to spend much effort on dependency resolution. I’ve never been hacked because I gave some software permissions it wouldn’t have had in a sandbox. I don’t think those problems aren’t real, and if solving them for other people is a positive, then go nuts. I’m just saying that for me, they’re not upsides I really want to pay anything for, and the complexity costs are higher than whatever that threshold is for me.
As an internal implementation detail, it's fine and pretty standard. Exposing it to the end user so that they have to know whatever janky-ass domain and capitalization you picked to run your application is braindead.