But if those modifications were known to cause the system to brick after you update, wouldn’t it be really nice if it stopped you from doing it?
And not just “yeah we know having done x will cause a bootloop after update, if you don’t know to uninstall/fix it it first, too bad.”
Lets take VLC from this Windows example, the one that blocks windows updates is a really old version of it. If you have that, you need to either uninstall VLC or remove it to get Win 11 to update.
If there was a bug where having a really old version of VLC on your system would somehow break if you updated the kernel, would a complicated workaround patch be integrated into the kernel just in case for forever?
Or would the patch work exactly the same way as windows, where it would check for that version of VLC and tell you to remove or update it first?
I see you’re unaware of the number one rule of the Linux Kernel : DO NOT BREAK USER SPACE
The patch would be distributed the exact same way that we distribute every single other patch in Linux.
the exact same way that we distribute every single other patch in Linux.
Which is?
I see you’re unaware of the number one rule of the Linux Kernel : DO NOT BREAK USER SPACE
For sure, my linux experience is limited to playing around with raspis and the Steam Deck, and running apt-get update / upgrade and accepting everything at once. I haven’t actually even had a need to refuse updating something individually so I have no idea what the protocol is if I wouldn’t want to update some application.
What I do know is that basically every single linux application has dependencies and if you don’t install, update or remove exactly what that application demands you to do, most of them refuse to install or update themselves - blocking updating because you have or don’t have something else on your system seems to be basically the norm with Linux.
But if those modifications were known to cause the system to brick after you update, wouldn’t it be really nice if it stopped you from doing it?
And not just “yeah we know having done x will cause a bootloop after update, if you don’t know to uninstall/fix it it first, too bad.”
idk maybe if you can detec the specific issue, you should maybe like, tell the user.
Linux devs would just make a patch to work with that configuration as it’d be considered a bug.
How would that patch be distributed?
Lets take VLC from this Windows example, the one that blocks windows updates is a really old version of it. If you have that, you need to either uninstall VLC or remove it to get Win 11 to update.
If there was a bug where having a really old version of VLC on your system would somehow break if you updated the kernel, would a complicated workaround patch be integrated into the kernel just in case for forever?
Or would the patch work exactly the same way as windows, where it would check for that version of VLC and tell you to remove or update it first?
I see you’re unaware of the number one rule of the Linux Kernel : DO NOT BREAK USER SPACE
The patch would be distributed the exact same way that we distribute every single other patch in Linux.
Which is?
For sure, my linux experience is limited to playing around with raspis and the Steam Deck, and running apt-get update / upgrade and accepting everything at once. I haven’t actually even had a need to refuse updating something individually so I have no idea what the protocol is if I wouldn’t want to update some application. What I do know is that basically every single linux application has dependencies and if you don’t install, update or remove exactly what that application demands you to do, most of them refuse to install or update themselves - blocking updating because you have or don’t have something else on your system seems to be basically the norm with Linux.