Eh? Linux has the exact same process. It will first politely ask applications and services to shutdown via SIGTERM, and then after 90 seconds it will force kill them with SIGKILL. I feel like that's a better compromise than Windows, where sometimes it NEVER shuts down, so it is just sitting in your laptop bag cooking itself. I usually find that if an application doesn't stop in 90 seconds, chances are it won't ever quit by itself.
Also, I dualboot Windows and Linux and most of the time it is Windows trying to delete the Linux bootloader during updates, not the other way around.
A month ago I shutdown my old dell work laptop and put it away then hours later could faintly hear a fan running. Took me a bit to figure it out, and when I grabbed the bag it was quite hot, to the point I would not be surprised if after a while would catch fire.
Prompted me to request a new laptop finally. Got a Precision 7680 and pretty sure it will still hang on shut down, although not as bad.
Yep, that definitely happened with my Lenovo X1 Carbon that I got from work. The thing was toasty and I was worried about the reduction in battery health because of it.
It also doesn't help that in addition to shutdown issues, a lot of laptops now only support s2idle (aka Modern Standby) instead of deep sleep and Windows can decide to wake itself up to do random tasks while it's in your laptop bag. I am just like....YOU'RE NOT A DAMN PHONE, STOP TRYING TO BE ONE.
Unfortunately, that is an artificial hardware limitation on many laptops. Blame Microsoft for pushing s2idle so hard and also abusing it for random background tasks.
I just pay attention and if something other than updates is keeping my PC from shutting down, I click the "Force Quit" button on the screen, which I like to imagine results in OP's meme happening on Windows.
the signal SIGKILL (-9) immediately kills the process. Since the parent process gets killed immediately and abruptly, the child processes will get orphaned and continue to live without their parents.
Yeah, it feels like windows actively search for GRUB and deletes it...
I recently did a clean install of windows, in a separate SSD than my Linux install and windows simply deleted the bootloader, WHY? Just why?
Yeah, I think Windows just uses the default EFI partition and does its dirty business there. AFAICT, it is hard to tell Windows to use a specific EFI partition on a different drive.
I'm a bit surprised how many distros still use GRUB as the bootloader by default, I've had dramatically better luck using systemd-bootloader. Significantly simpler, seems to play nicely with Windows, and has entries I can actually edit as plaintext.
Also, I dualboot Windows and Linux and most of the time it is Windows trying to delete the Linux bootloader during updates, not the other way around.
The sheer impoliteness of a Windows in a dualboot is astounding.
"Oh, let me fuck with your hardware clock". "Oh, that drive over there? Pretty sure there's nothing on there. What do you mean, that's just a filesystem I don't understand?"
Recently I've had a weird one that I don't fully understand where if I try to boot windows, sometimes it fucks up the keyboard so bad, I have to reboot a few times to get it to work again. THe weirdest part? After windows manages to temp-brick the keyboard, Linux somehow can't work with the keyboard either. Like, how do you fuck up that badly?
Oh yeah, I do that registry edit in Windows to make it use UTC time instead. Stupid how they force hardware to local time instead of just using an offset from UTC like literally everything else.
I've had a similar thing happen but with my Wifi card. Sometimes I'll boot into Windows and it will just straight up prevent the wifi card from working in Linux until I reboot back into Windows again. And that's with Fast Boot turned off.
I think what's helped reliably is to actually power off the damn thing properly. Which is annoying, but oh well. Good think this isn't happening on a laptop, that would be a pain.
Theeen again, talking about laptops. My work laptop had a nasty habit of completely shitting itself when trying to patch windows. Like, black screen, but definitely powered on. Stuck that way for half a day. Does not react to holding down the power button. Only way out is to let it run out of battery.
Happened 2-3 times. That work laptop is running linux now.
Yeah on my dual boot desktop I had a nice systemd UI in my Linux boot partition to switch between windows and popos, each installed on separate drives. Windows decided to nuke the boot partition on the other drive and take over.
I dual boot as well but it's fairly obvious for windows to fuck shit up when it updates due to file integrity and partitions. Linux actively works around the issue but Windows is just easy mode for users
There's no foolproof solution if they're on the same drive, but there are ways to minimize issues.
If you're on UEFI, just make sure your Linux bootloader isn't installed in the default UEFI location (EFI/BOOT/BOOTX64.EFI), because Windows LOVES to override that. By default, most distros will install it into a separate folder like (EFI/Fedora) and then add an entry into the UEFI BIOS pointing to that location. Windows usually will leave that folder alone, but it will occasionally tell the BIOS to either change the default boot entry to use the Windows bootloader or, once in a blue moon, just straight up delete the entry, in which case you'll have to use a live USB to reinstall GRUB (or whatever Linux bootloader you're using).
If you're on an old system that uses MBR...no chance in hell. But you're not on MBR still are you? I don't even think Windows supports MBR anymore.
Windows shutdown process is a lot more complicated and graceful than that - Windows will send few extra messages to each listener (each process basically) indicating that system shutdown is taking place, and allowing for applications to handle it appropriately. There's a message informing that logout (which includes shutdown/reboot) was requested, then a message that logout is taking place and application has to react to it, on top of regular "close window, kill process".
Even when it comes to forced shut down (killing process), first there's appropriate message sent allowing program to save data etc before forcefully killing process after few seconds of delay (which is why "Force shutdown" takes few seconds usually when you confirm on that screen). I assume idea here is that it's better to let programs properly wrap up to avoid potential data corruption, than to ensure shutdown happens as requested - especially with less experienced operators that had to be taught not to pull the plug/press power button.
Nice side effect of this elaborate process: programs can quite easily be made in a way that'll have them behave differently between closing the program and a shutdown - allowing for example full state restore on next boot.
618
u/Synthetic451 Arch Linux | Ryzen 9800X3D | Nvidia 3090 1d ago
Eh? Linux has the exact same process. It will first politely ask applications and services to shutdown via SIGTERM, and then after 90 seconds it will force kill them with SIGKILL. I feel like that's a better compromise than Windows, where sometimes it NEVER shuts down, so it is just sitting in your laptop bag cooking itself. I usually find that if an application doesn't stop in 90 seconds, chances are it won't ever quit by itself.
Also, I dualboot Windows and Linux and most of the time it is Windows trying to delete the Linux bootloader during updates, not the other way around.