1. Be civil
No trolling, bigotry or other insulting / annoying behaviour
2. No politics
This is non-politics community. For political memes please go to !politicalmemes@lemmy.world
3. No recent reposts
Check for reposts when posting a meme, you can only repost after 1 month
4. No bots
No bots without the express approval of the mods or the admins
5. No Spam/Ads/AI Slop
No advertisements or spam. This is an instance rule and the only way to live. We also consider AI slop to be spam in this community and is subject to removal.
A collection of some classic Lemmy memes for your enjoyment
This is blatantly false, 99% of Gnu/Linux distros actually have systemd nicely asking the processes to terminate themselves, it just doesn't take longer than ~10 seconds usually.
This meme would imply a sigkill.
Edit: the distros that don't use systemd likely don't do any such thing either, I just don't know about them.
Kernel will happily kill processes if it's out of memory, regardless of systemd or whatever. But in general Linux first asks nicely for the program to shut down and if it doesn't comply then it's SIGKILL time.
Which IMO is a most reasonable order of operations
Except on the Linux systems I've used, when I ask it to shut down, it shuts down no matter what. Windows and macOS let programs stop the shutdown process indefinitely (when shutdown/reboot are invoked the usual way).
I think that's what the meme is trying to get at.
I wish that was the case, I'll often find my Linux desktop running because the os failed to shut something down.
poweroff and reboot work as advertised for me, but I'm running headless homelab servers and a laptop with i3. Maybe DEs/GUI shutdown is more subtle?
I've had containers which are locked up and won't respond to SIGKILL or any other signal. I don't think It should be possible with a regular process, though.
That would depend on the DE I suppose, on GNOME it'll show open programmes and wait 60 seconds for the user to intervene IIRC.
Still doesn't kill them though and asks them to properly terminate themselves which allows them to take care of everything.
Yeah, I run i3 and headless servers, so it's poweroff or reboot for me. Always works as advertised.
Yeah, I'm kinda sick of seeing this false information on ~~this sub~~ the linuxmemes community. It's a surprisingly common meme subject somehow
This ain't the Linux memes com
that's why I edited
ah I misunderstood you then, my bad 😅
*clicks shut down on windows
*goes to boot computer up into the morning... sees message 'attempting to close programs'
fu microsoft
WinKey+R
Shutdown -s -f -t 0
Can I get a breakdown of the meaning of this?
Win + R: opens run dialog to run the next command
shutdown -s -f -t 0: cli shutdown command where -s is poweroff, -f is force, and -t 0 is a timeout of 0
If you do shutdown -s -t 1 you can skip the -f and it'll shutdown after 1 second.
*clicks sleep on windows
*computer turns itself on in the middle of the night and starts playing YouTube
fuck you ms
That's almost certainly because you've got wake on LAN enabled in your BIOS settings and something else on your network wants to have a late-night chat with your computer.
yeah wake on lan is pretty hard to accidentally trigger.
Why would random software be sending packets with 0xFFFFFFFFFFFF + mac*16?
The MAC-specific magic packet is an optional mode for wake on LAN, not a mandatory one. Plenty of network adapters forward packets to the OS if wake on LAN is enabled and let the OS decide whether it only wants to respond to magic packets, and by default when wake on LAN is enabled, there are other kinds of packet Windows responds to, e.g. Address Resolution Protocol, which lots of routers use to check whether devices are still connected. It's not supposed to wake the machine, especially if S0 sleep is enabled, but it can, especially if it's done excessively.
A magic packet is any packet using any protocol with that string in it. And the os cannot respond to a wake-on-lan packet, because the os is not running at the time; the computer is powered off. The os is later informed, via acpi, of the reason it was woken up, should it bother to check. If you don't want a magic packet, then any packet will wake the system up. I am not aware of any alternatives. Extensions, yes. But not alternatives
It's not any packet that's waking up machines configured to wake on LAN without restricting it to magic packets, it's any packet addressed to the machine's MAC. Just like a regular packet when the machine's fully awake, it's specific to the network adapter with that MAC, and gets handled by that network adapter. Once it wakes the machine (either to fully on or a sleeping-but-still-doing-things state like S0), the OS starts/resumes and is told why it was started and can choose to access the packet and respond to it. From the perspective of the device on the other end of the wire, it sent a packet to a machine and got the response it expected. It doesn't have to know whether the machine was fully powered on or whether it woke up to deal with the request before going back to sleep again.
By default, for most network traffic that partially wakes Windows when the machine has wake on LAN enabled in the UEFI settings, Windows sees it's been woken by LAN activity, checks the packet, decides it doesn't care, and goes back to sleep before anyone notices (or remains in S0 sleep if it was in S0 sleep as it wouldn't need to wake up to deal with the packet). For a few other kinds of LAN activity, it opts to respond to the packet. If you've got your UEFI settings set to only wake on magic packets, these won't make it that far, though. There's also a Windows setting to force it not to respond to regular non-magic packets and immediately go back to sleep if it's woken by them.
I thought the "addressed to it" part was implied. you seem to keep saying that windows handles things. The computer is shut down, not in sleep mode. There is no windows to handle things. Windows is not loaded. It has not gone through the boot process. WoL still works if you rip out all the storage. WoL is handled by the network adapter hardware
You're describing what windows does after a computer is woken/turned on. That's irrelevant, by that point the WoL is long over. After the pc is turned on and booted then windows is free to do whatever, including putting the system back to sleep. Whether it does this fast enough for you to notice is irrelevant, that is not WoL functionality.
And no, systems are not constantly waking up and then re-sleeping. Again, if the pc was shut down it'd have to go through the whole boot process before windows can put the system back to sleep. And you would find a sleeping pc when you left a shutdown one. Not what happens. And if instead of sleeping it shut itself down that'd look like a boot loop. definitely noticable.
tldr: after the pc is turned on and the os has been loaded, the os is free to do anything
Or they're using S0 sleep and the computer is waking itself up to update
When Windows wakes itself up to do things like that, it wakes itself to a different sleep level where it can still do things but the machine isn't visibly on. That's the whole point of S0 sleep. If it's fully waking itself up to do things, then either S0 sleep is disabled or there's a firmware bug affecting the motherboard that means certain actions during S0 sleep will exit sleep (which is more common than it should be).
Mate, you’re lucky you still got that secure boot manager thingy… drops from my disks far too often.
Can I uninstall the bootloader Mr. Linux?
Hell yes you can! Let's try it and see what happens!
Happens all the time. Usually accompanied by installing an updated version at the same time. You can uninstall your kernel too, try it.
There are apps that don't close gracefully when asked by systemd in my experience. I've often forgotten to close one and been stuck waiting 90s for a watchdog to timeout so the app gets killed.
This is not a problem unique to windows.
I don't see an article linked for the relevant headline, but when I first installed linux (I use Arch btw) on my desktop, it didn't come with swap auto-configured by the install helper ArchInstaller, but did come with oomkiller and also with 4/16GB of zram preconfigured. With three displays and three different kind of browsers open I ran out of memory when launching a game fairly quickly, and of course oomkiller went to town. Not only that, but because of stupid zram it also seemed to be stuck on an endless loop of not being able to kill something.
Oomkiller you say? I've never used the installer...
I can attest to that. I've been trying to figure out why my Kinonite install is killing KDE repeatedly without mercy...........
Other unixes are over there like "hey, I kill just as much as Linux does!"
