No, it’s not different, I just use Arch and have no power menu anymore, nor did I usually close my laptop lid while I was still planning to use it. I usually just powered it down fully because it used to start very fast, but I think the laptop bios battery is dying or something, because it turns on much slower now than it did before. So finding the actual command that triggers the suspend state was so epic, because I can script and bind it now.
You may find another systemd command helpful: systemd-analyze. It has different subcommands you can use to figure out what exactly is slowing down your boot times.
You have only yourself to blame then. You’ve chosen a distribution which expects users to learn how the system works and it’s on you to figure out how to suspend the system.
I think the laptop bios battery is dying
This is unlikely. If the battery was dying, you’d be loosing BIOS/UEFI settings including time. Once the computer starts up, the battery is unused.
Yes, that’s why I chose the distro I chose, and why this was not a serious post were I was actually upset, I enjoy learning and reading, I just wanted to make a post about suspend bc it has made me happy. I am also aware the bios battery does nothing once it’s booted, once it’s booted the performance is the same as it has always been. So I assumed the cmos battery is dying, but not dead enough to lose settings yet.
The CMOS battery only maintains the data in the bios’ volatile memory and runs the RTC when the system has no power, it is completely out of the picture when data is being read from said volatile memory.
Is
systemctl suspenddifferent than closing the lid or clicking “sleep” on your DE’s power menu?No, it’s not different, I just use Arch and have no power menu anymore, nor did I usually close my laptop lid while I was still planning to use it. I usually just powered it down fully because it used to start very fast, but I think the laptop bios battery is dying or something, because it turns on much slower now than it did before. So finding the actual command that triggers the suspend state was so epic, because I can script and bind it now.
You may find another systemd command helpful: systemd-analyze. It has different subcommands you can use to figure out what exactly is slowing down your boot times.
Thx, I’ll check it out
Sweet, that’s awesome. 🥳
You have only yourself to blame then. You’ve chosen a distribution which expects users to learn how the system works and it’s on you to figure out how to suspend the system.
This is unlikely. If the battery was dying, you’d be loosing BIOS/UEFI settings including time. Once the computer starts up, the battery is unused.
“I take full responsibility for my Arch install” is one of my favourite lines from a linux youtuber.
This quote has been yoinked. I need it on a shirt tbh.
Yes, that’s why I chose the distro I chose, and why this was not a serious post were I was actually upset, I enjoy learning and reading, I just wanted to make a post about suspend bc it has made me happy. I am also aware the bios battery does nothing once it’s booted, once it’s booted the performance is the same as it has always been. So I assumed the cmos battery is dying, but not dead enough to lose settings yet.
The CMOS battery only maintains the data in the bios’ volatile memory and runs the RTC when the system has no power, it is completely out of the picture when data is being read from said volatile memory.
The CMOS battery does nothing from the moment computer is turned on. If you’re saying booting takes longer, that’s not battery’s fault.
That’s not how CMOS battery work. It’s even good enough or you’re loosing the clock.
I like wlogout, I’ve mapped the power button to launch it.