RIP S3 sleep... Took years to get it to work reliably under Linux, then we had a good decade+ run of it "just working" like this, now back to trying to weed out all the wacky platform quirks and weird hardware/firmware behavior that make the S0ix states be just barely unusable.
Linux used to be able to do S3 sleep well, and now it can't because... new platforms removed S3 for S0ix? Or S3 became even more complicated with mroe platform quirks and weird hardware?
The problem is platforms moved away from S3 sleep. I've heard people claim it was mostly so managed Windows laptops could force updates with the lid shut and the laptop suspended.
Now I have to worry about my laptop randomly overheating itself in my backpack and even catching fire.
I've heard people claim it was mostly so managed Windows laptops could force updates with the lid shut and the laptop suspended.
That, but probably also to compete with Mac's Power Nap feature (2012) that updates Mail, Messages, and other applications during sleep (so that when you open up the laptop messaging apps are immediately up to date):
Hold on, Apple used the same intel chips as everyone else when Power Nap was introduced. In fact, it was implemented via S0ix state. It's just almost no one except Apple figured how to utilize it correctly.
Now i'm wondering if it's Apple fault that S3 got removed.
My Macbook Pro lasts about two days on battery while doing work (in clamshell mode, with the screen off). My Thinkpad drains its battery in less time than that in sleep. The removal of S3 is a travesty.
I believe it came about during the "Windows must run on tablets" era. They needed a way for WiFi to stay on during sleep so things like notifications would continue to work. It also enabled media players to continue playing audio in sleep mode, similar to iOS and Android.
I tried a few times as some BIOS have a hidden or disabled setting but I never got past a plain crash. Device and CPU vendor support for classic S3 is shrinking. E.g. on framework laptops the Intel CPU(!) does not officially support S3 sleep.
So I can understand that there is no option for it if all you can get is out of spec behavior and crashes.
Also note that it is incompatible with some secure boot and system integrity settings.
> It also enabled media players to continue playing audio in sleep mode
Is that actually a thing? On my Windows machine media stops playing when I put it to sleep. The machine is clearly not completely off, though, judging by the fan spinning like crazy from time to time.
Also, the whole "keep checking for e-mails" and whatever is clearly broken, since after waking up Outlook needs a while to come back to life and show new messages.
weirds me out since acpi etc. is uaed to control power qnd such states why would devices even need to do such things to support some OS.. the OS should be able to manage states, its the controller and hw should listen... in this case, windows could simply not put the devices to sleep?
i know it didnt end up with this logic but it melts my brain as to why... is it cheaper to implement the hw without support for deep sleep?
most specifications have it included (pcie, nvme, ahci etc. etc.) so you'd expect most devices working via pc platform would implement these things :(
cant wait to push my OS onto real hardware and burn my fucking house down
FreeBSD and Suspend/Resume… About 10 years ago, I switched from FreeBSD to Linux because I couldn't get suspend/resume to work reliably (i.e. suspend/resume cycle succeeds and it doesn't drain my laptop battery in between) on FreeBSD on my Thinkpad.
And this was only Suspend to RAM. Suspend to Disk is really nice to have, especially if coupled with hybrid standby, as on macOS and Windows by default.
I really appreciate that people still maintain FreeBSD on the desktop, though.
I recently bought a new laptop because I could only resume to work on OpenBSD, but not Linux. Suspend worked great under Linux, but without resume, the experience was sub-par.
It's unfortunate that I needed Linux to get some of my work done.
Odd that you would say "only Suspend to RAM", because that is far more difficult to reliably implement in terms of hardware compatibility than Suspend to Disk.
AFAICT "Suspend to RAM" is basically stopping the CPU, powering down the peripherals, and keeping the DRAM unchanged and refreshed. It should be the easier option since very little state needs to be saved explicitly, the OS and apps should just receive a signal that they were interrupted, so some peripherals have to be re-initialized, and things like network and USB connections need to be re-established.
AIUI, these things actually way more hard than it sounds because hardware developers live in their own world, apparently. There's been articles here on HN from mjg59's blog (who's one of the guys maintaining all this power management stuff in the Linux kernel) like this one [0] about how some hardware simply chooses to do things that make this "re-initialization" impossible to do reliably.
The main difference is that in S3 many (internal) peripherals are put to sleep but not entirely unpowered. So when the system is resumed, it's not an entirely clean slate like it would be from a fresh power up from hibernation. Unfortunately sometimes pulling down the reset line doesn't always do as thorough job as a power cycle.
Windows used to work about this well back in the XP days, possibly Windows 7 as well. Plenty of times I hit the "sleep" button that Logitech put right next to the esc key (....) and resumed the system to find everything working as expected.
Not sure if the embedded video is suspend to RAM or disk. Also not sure why there wasn't a PW prompt upon resume, but I'm not a BSD person, just someone who is paranoid about PW prompts.
feel lucky. s3 suspend quit working on my thinkpad in -CURRENT some months ago after having worked for like a decade. i didn't notice until i pulled a molten hot slab of locked up laptop out of my bag
I think it's highly dependent on the particular hardware.
I have two HP EliteBook G8s, one AMD one Intel. Both work perfectly with Linux, although they don't support S3, only the "modern" standby.
The AMD one randomly craps out if suspended in Windows. No idea what it does, but it gets extremely hot and doesn't respond to anything but a hard reset. Sometimes it reboots on its own. Maybe because it gets too hot? No idea.
The Intel one also sometimes gets fairly warm for no reason (I keep it up to date, so it can't be random updates - also happens in my bag, so while unplugged). But sleep now mostly works fine. For the first year or so it would sometimes wake up with a garbled screen.
Those are both your regular basic enterprise laptops, no dedicated GPUs or anything fancy.
> Why not FreeBSD 14.2 as its already available? Because pkg(8) packages are built against ‘oldest’ FreeBSD version in the current tree – which means FreeBSD 14.1 – and that often breaks kernel related packages such as really important drm-kmod or virtualbox-ose-kmod packages.
FreeBSD still lacks basic LTS functionality and keeping distribution coherent.
May be one day some vendor will create LTS distribution based on FreeBSD with at least 5 years support cycle?
unluckily, FreeBSD project uses misleading info here - your apps are OUT of equation here, they do split "base" system (if traffic router is your appliance of choice, you may be fine with that), but all useful stuff is in "ports"/"packages" and is rolling updates.
> I will upgrade from 14.1 to 14.2 shortly after 14.1 runs out of support – which would guarantee having working pkg(8) packages on FreeBSD 14.2.
The way I'm reading this, you can just move between minors when they expire rather than when the new minor is available:
- stable/14 was released Nov 2023
- 14.0 support ended Sep 2024, move to 14.1
- 14.1 support ends Mar 2025, move to 14.2
Rinse and repeat. stable/13 was released Apr 2021 and the last minor (13.4) is still supported until Jun 2025, it's four years just like the previous major releases. I don't see how any of this shows an operating system that "lacks basic LTS functionality" or "keeping the distribution coherent" -- especially the latter point is strange considering FreeBSD by design is a lot more "coherent" than Linux (whether that's a good thing or not is completely a matter of taste).
The only reason I still buy and rely on first-party hardware is how well (and fast) the suspend/resume works. Never a single problem.
Completely opposite experience with Linux/*BSD though, across dozens of different hardware setups, almost all of them have had some kind of quirk/bug that made it unusable.
Yes, but they are all way out of my price range. I have also read reviews and many posts online that show that even these Linux-focused companies cannot support 100% of their own hardware lineup with working drivers.
I have had very mixed experiences when suspending a laptop using Windows, various Linux distributions, MacOS and Windows 7-11. MacOS is the most polished yet, but Linux (kernel 2.4 to 6.8) has never nailed this. Often times the kernel refuses to sleep and the laptop will hotbox in the bag until the battery runs out. The same has happened on the other OSes, but less often.
It looks like this particular FreeBSD installation (we don't know if it's out of the box or customized, and haven't seen it side by side with another hardware setup) works very well. Wonder if the results are the same if they closed the lid rather than remembering to press the button. Also, I wonder why this doesn't trigger any authentication when starting back up. Anyone could snatch that laptop and still be logged in.
> It looks like this particular FreeBSD installation (we don't know if it's out of the box or customized, and haven't seen it side by side with another hardware setup) works very well.
All the settings I use are documented here - and its nothing special really - most people using FreeBSD on laptops use them:
> Wonder if the results are the same if they closed the lid rather than remembering to press the button.
I often just close the lid and DO NOT want the laptop to go to sleep - that is why I do not use it - but it works the same with hw.acpi.lid_switch_state=S3 in /etc/sysctl.conf file - it does not matter for FreeBSD if zzz(8) commands triggers S3 state or something else.
> Also, I wonder why this doesn't trigger any authentication when starting back up. Anyone could snatch that laptop and still be logged in.
The purpose of this videos were to show only the suspend/resume process of FreeBSD system.
In my daily life I have two shortcuts related to this:
- [SUPER] + [L] - locks the system and leaves it running - and it requires to enter password
- [SUPER] + [CTRL] + [ALT] + [L] - locks the system AND PUTS IT INTO S3 SLEEP - and it requires to enter password if you wake it up
To echo the other comments - I'm reasonably confident that the Linux kernel is perfectly capable of handling sleep, the problem is varied hardware support. Consider that every Chromebook and Android device on the planet is running a Linux kernel, and they have no trouble. Likewise, I don't think I've ever had Linux struggle with sleeping on a thinkpad, and the best suspend/resume experience I've ever had was Linux on a random Lenovo laptop a while back.
Having been on linux laptops for ~20 years, I've found this to be really h/w dependent.
I've mostly run thinkpads, and they've mostly worked. My current T16 not only suspendds/resumes well, I also successfully use full disk encryption recovery on boot from hibernate.
This is my experience too. Even though we don't hand off control to the (often buggy) BIOS anymore, there is still a fair bit of hardware support that needs to be in place to have a smooth suspend/resume. Even on the Windows install that shipped with the laptop I've had machines that fail to suspend properly and turn into bagwarmers or that fail to restore the graphics when waking back up or any number of potential issues. I've even had machines that brick their SSDs the first time you put them to sleep. Permanently bricked, can't even be wiped or factory reset bricked.
Concur. I have seen issues with suspend on Linux in the past, but my last three Dell laptops suspend just fine. Usually the only weirdness is with laptops that don't have an S3 state anymore, or when you add/remove hardware in between being awake and asleep.
That said (and it pains me to say it), the experience is still nowhere near as flawless as MacOS on Silicon hardware.
For the record - this FreeBSD installation from videos also uses Full Disk Encryption in the form of GELI under the ZFS - its really brain dead simple to setup - just use 'Auto (ZFS)' option in the FreeBSD bsdinstall(8) installer and set Encrypt Disks to YES - nothing else required.
> Wonder if the results are the same if they closed the lid
This is a default setting that I never understood.
Nearly all laptops/keyboard have a sleep button, power button is often configured by default to also go to sleep. Additionnally you can configure to go automatically to sleep if inactive and on battery for a few minutes. Why would I want my laptop to go to sleep immediately when I close the lid?
Half of the time when I am closing the lid, it is to move from one space/room to another. I don't want my git pull/push, my music or my video call to stop for 20-30 seconds because I am just going from my sofa to my kitchen or from my desk to a meeting room.
And I don't want to be that dummy project manager who moves awkwardly from one place to another with his coffee cup in one hand and an opened laptop on the other hand nearly hitting everyone or the office plants in the process just because he is too dumb to configure his laptop correctly.
Now if we can make FreeBSD to dual boot with Windows or Linux with UEFI SecureBoot enabled (corp IT requirement), that would be a blast... Maybe one day I will be able to try it by booting from a USB drive...
I made a minimal debian wrapper installation on an nvme drive in an usb enclosure that add support for secure boot, encryption, bluetooth, wifi and start whatever OS I want to run on qemu. The thing check total memory and cores of the machine and start the VM with VM CPUS = TOTAL CPU CORES - 2 and VM MEMORY = TOTAL MEMORY - 1GB. The sway compositor is configured to automatically start virt-viewer in full screen at boot connecting to the chosen VM as well as bluetooth/pavucontrol/nm-tui in a hidden virtual desktop.
I initially built it to have a portable yet as close to bare metal experience as possible with operating systems such as Haiku that do not necessarily have all features + best hardware support but this could be totally done for a BSD. Although you rely on it to connect a new bluetooth device, wifi network, the idea is to spend the less time possible on the underlying debian host OS.
I did it manually but I should really do an ansible playbook that people can adapt to their distro of choice.
What's the point here?
Suspend on my Lenovo T480s works great on Linuxmint (which is just an Ubuntu compiled kernel).
It doesn't have that jarring boot into console mode with output, it just wakes up into X again.
My Mac Laptop is still far and away the best experience (Because Apple controls every bit of hardware). You open it up and within a minisecond it's ready to work. My linux laptop takes at least 5 seconds before you can login - same as shown in this video.
RIP S3 sleep... Took years to get it to work reliably under Linux, then we had a good decade+ run of it "just working" like this, now back to trying to weed out all the wacky platform quirks and weird hardware/firmware behavior that make the S0ix states be just barely unusable.
Maybe in another five years...
Can you explain a bit more? What happened?
Linux used to be able to do S3 sleep well, and now it can't because... new platforms removed S3 for S0ix? Or S3 became even more complicated with mroe platform quirks and weird hardware?
The problem is platforms moved away from S3 sleep. I've heard people claim it was mostly so managed Windows laptops could force updates with the lid shut and the laptop suspended.
Now I have to worry about my laptop randomly overheating itself in my backpack and even catching fire.
I've heard people claim it was mostly so managed Windows laptops could force updates with the lid shut and the laptop suspended.
That, but probably also to compete with Mac's Power Nap feature (2012) that updates Mail, Messages, and other applications during sleep (so that when you open up the laptop messaging apps are immediately up to date):
https://www.engadget.com/2012-06-11-apple-introduces-power-n...
Apple managed to do it without setting your laptop on fire. Meanwhile Dell recommends you to switch off a laptop when you put it in your backpack:
https://www.dell.com/support/kbdoc/en-us/000124304/notebook-....
Hold on, Apple used the same intel chips as everyone else when Power Nap was introduced. In fact, it was implemented via S0ix state. It's just almost no one except Apple figured how to utilize it correctly.
Now i'm wondering if it's Apple fault that S3 got removed.
Nah. Apple's Intel implementation at least was equally crap. I've had my 2018 MBP cook itself in my bag a couple times.
Perfect "we have PowerNap at home" moment for Dell and friends. Well played, Apple.
My Macbook Pro lasts about two days on battery while doing work (in clamshell mode, with the screen off). My Thinkpad drains its battery in less time than that in sleep. The removal of S3 is a travesty.
I believe it came about during the "Windows must run on tablets" era. They needed a way for WiFi to stay on during sleep so things like notifications would continue to work. It also enabled media players to continue playing audio in sleep mode, similar to iOS and Android.
Would be great to have a bios switch for it then.
I tried a few times as some BIOS have a hidden or disabled setting but I never got past a plain crash. Device and CPU vendor support for classic S3 is shrinking. E.g. on framework laptops the Intel CPU(!) does not officially support S3 sleep.
So I can understand that there is no option for it if all you can get is out of spec behavior and crashes.
Also note that it is incompatible with some secure boot and system integrity settings.
Thinkpads do. It's poorly named but they let you choose Windows (S0x) or Linux (S3) sleep.
No, not on modern Thinkpads.
Every XPS and Thinkpad that I owned, had a bios setting to "enable linux compatibility" which was enabling S3 state.
> It also enabled media players to continue playing audio in sleep mode
Is that actually a thing? On my Windows machine media stops playing when I put it to sleep. The machine is clearly not completely off, though, judging by the fan spinning like crazy from time to time.
Also, the whole "keep checking for e-mails" and whatever is clearly broken, since after waking up Outlook needs a while to come back to life and show new messages.
weirds me out since acpi etc. is uaed to control power qnd such states why would devices even need to do such things to support some OS.. the OS should be able to manage states, its the controller and hw should listen... in this case, windows could simply not put the devices to sleep?
i know it didnt end up with this logic but it melts my brain as to why... is it cheaper to implement the hw without support for deep sleep?
most specifications have it included (pcie, nvme, ahci etc. etc.) so you'd expect most devices working via pc platform would implement these things :(
cant wait to push my OS onto real hardware and burn my fucking house down
FreeBSD and Suspend/Resume… About 10 years ago, I switched from FreeBSD to Linux because I couldn't get suspend/resume to work reliably (i.e. suspend/resume cycle succeeds and it doesn't drain my laptop battery in between) on FreeBSD on my Thinkpad. And this was only Suspend to RAM. Suspend to Disk is really nice to have, especially if coupled with hybrid standby, as on macOS and Windows by default.
I really appreciate that people still maintain FreeBSD on the desktop, though.
I recently bought a new laptop because I could only resume to work on OpenBSD, but not Linux. Suspend worked great under Linux, but without resume, the experience was sub-par.
It's unfortunate that I needed Linux to get some of my work done.
Odd that you would say "only Suspend to RAM", because that is far more difficult to reliably implement in terms of hardware compatibility than Suspend to Disk.
AFAICT "Suspend to RAM" is basically stopping the CPU, powering down the peripherals, and keeping the DRAM unchanged and refreshed. It should be the easier option since very little state needs to be saved explicitly, the OS and apps should just receive a signal that they were interrupted, so some peripherals have to be re-initialized, and things like network and USB connections need to be re-established.
What am I missing?
> powering down the peripherals
> some peripherals have to be re-initialized
AIUI, these things actually way more hard than it sounds because hardware developers live in their own world, apparently. There's been articles here on HN from mjg59's blog (who's one of the guys maintaining all this power management stuff in the Linux kernel) like this one [0] about how some hardware simply chooses to do things that make this "re-initialization" impossible to do reliably.
[0] https://news.ycombinator.com/item?id=38095276
The main difference is that in S3 many (internal) peripherals are put to sleep but not entirely unpowered. So when the system is resumed, it's not an entirely clean slate like it would be from a fresh power up from hibernation. Unfortunately sometimes pulling down the reset line doesn't always do as thorough job as a power cycle.
Windows used to work about this well back in the XP days, possibly Windows 7 as well. Plenty of times I hit the "sleep" button that Logitech put right next to the esc key (....) and resumed the system to find everything working as expected.
Not sure if the embedded video is suspend to RAM or disk. Also not sure why there wasn't a PW prompt upon resume, but I'm not a BSD person, just someone who is paranoid about PW prompts.
> Not sure if the embedded video is suspend to RAM or disk.
Its Suspend to Disk (S3).
> Also not sure why there wasn't a PW prompt upon resume, but I'm not a BSD person, just someone who is paranoid about PW prompts.
The purpose of this videos were to show only the suspend/resume process of FreeBSD system.
In my daily life I have two shortcuts related to this:
- [SUPER] + [L] - locks the system and leaves it running - and it requires to enter password
- [SUPER] + [CTRL] + [ALT] + [L] - locks the system AND PUTS IT INTO S3 SLEEP - and it requires to enter password if you wake it up
Hope that helps.
Regards,
vermaden
Its Suspend to Disk (S3)
S3 is suspend to RAM. Suspend to disk is S4.
You are right - its Suspend to RAM - I wanted to reply fast ... which did not ended well.
Because there is usually a graceful period before forcing to authenticate.
Also, if it's Xorg lockscreen, then it's probably not very secure to begin with.
feel lucky. s3 suspend quit working on my thinkpad in -CURRENT some months ago after having worked for like a decade. i didn't notice until i pulled a molten hot slab of locked up laptop out of my bag
The only laptop I ever had in my entire life where sleep works is my current XPS 17 running win10.
I want to update my hardware to a Lenovo. Not looking forward to new "sleep won't work no matter what you try" adventures.
That sht is like printers: should always work, never does.
Weird. I haven't had a problem with my System76 laptops.
I think it's highly dependent on the particular hardware.
I have two HP EliteBook G8s, one AMD one Intel. Both work perfectly with Linux, although they don't support S3, only the "modern" standby.
The AMD one randomly craps out if suspended in Windows. No idea what it does, but it gets extremely hot and doesn't respond to anything but a hard reset. Sometimes it reboots on its own. Maybe because it gets too hot? No idea.
The Intel one also sometimes gets fairly warm for no reason (I keep it up to date, so it can't be random updates - also happens in my bag, so while unplugged). But sleep now mostly works fine. For the first year or so it would sometimes wake up with a garbled screen.
Those are both your regular basic enterprise laptops, no dedicated GPUs or anything fancy.
The thing is that modern hardware is super complicated and you have to have a good vendor that specifically targets the OS you want.
> Why not FreeBSD 14.2 as its already available? Because pkg(8) packages are built against ‘oldest’ FreeBSD version in the current tree – which means FreeBSD 14.1 – and that often breaks kernel related packages such as really important drm-kmod or virtualbox-ose-kmod packages.
FreeBSD still lacks basic LTS functionality and keeping distribution coherent.
May be one day some vendor will create LTS distribution based on FreeBSD with at least 5 years support cycle?
Basically each FreeBSD MAJOR version - like 13.x or 14.x had 5 years lifetime/support (like LTS) - it was shortened to 4 years only recently.
Details:
- https://lists.freebsd.org/archives/freebsd-announce/2024-Jul...
unluckily, FreeBSD project uses misleading info here - your apps are OUT of equation here, they do split "base" system (if traffic router is your appliance of choice, you may be fine with that), but all useful stuff is in "ports"/"packages" and is rolling updates.
Just read the next sentence:
> I will upgrade from 14.1 to 14.2 shortly after 14.1 runs out of support – which would guarantee having working pkg(8) packages on FreeBSD 14.2.
The way I'm reading this, you can just move between minors when they expire rather than when the new minor is available:
- stable/14 was released Nov 2023
- 14.0 support ended Sep 2024, move to 14.1
- 14.1 support ends Mar 2025, move to 14.2
Rinse and repeat. stable/13 was released Apr 2021 and the last minor (13.4) is still supported until Jun 2025, it's four years just like the previous major releases. I don't see how any of this shows an operating system that "lacks basic LTS functionality" or "keeping the distribution coherent" -- especially the latter point is strange considering FreeBSD by design is a lot more "coherent" than Linux (whether that's a good thing or not is completely a matter of taste).
The only reason I still buy and rely on first-party hardware is how well (and fast) the suspend/resume works. Never a single problem.
Completely opposite experience with Linux/*BSD though, across dozens of different hardware setups, almost all of them have had some kind of quirk/bug that made it unusable.
Have you ever considered using Linux laptops sold by companies focusing on Linux computers like system76, tuxedo, slimbook, starlabs and others?
Yes, but they are all way out of my price range. I have also read reviews and many posts online that show that even these Linux-focused companies cannot support 100% of their own hardware lineup with working drivers.
Consider a Chromebook. They are well supported,and therefore work well despite being Linux based.
What are those games being run?
In the background its Balatro game running on WINE64.
Rally game is Colin McRae Rally 2.0 on WINE32.
Top left is Sensible World of Soccer 96/97 game running on DOSBox.
> I leave You with a dilemma on how a Windows or macOS or Linux system running on the laptop/desktop behaves differently then FreeBSD here...
Not sure what the point is? Is it better, or is it as good as those other systems?
In terms of suspend/resume case I believe the experience is generally the same - it just works on FreeBSD.
I have had very mixed experiences when suspending a laptop using Windows, various Linux distributions, MacOS and Windows 7-11. MacOS is the most polished yet, but Linux (kernel 2.4 to 6.8) has never nailed this. Often times the kernel refuses to sleep and the laptop will hotbox in the bag until the battery runs out. The same has happened on the other OSes, but less often.
It looks like this particular FreeBSD installation (we don't know if it's out of the box or customized, and haven't seen it side by side with another hardware setup) works very well. Wonder if the results are the same if they closed the lid rather than remembering to press the button. Also, I wonder why this doesn't trigger any authentication when starting back up. Anyone could snatch that laptop and still be logged in.
Hi,
> It looks like this particular FreeBSD installation (we don't know if it's out of the box or customized, and haven't seen it side by side with another hardware setup) works very well.
All the settings I use are documented here - and its nothing special really - most people using FreeBSD on laptops use them:
- https://vermaden.wordpress.com/2022/04/14/freebsd-13-1-on-th...
- https://vermaden.wordpress.com/2018/11/28/the-power-to-serve...
> Wonder if the results are the same if they closed the lid rather than remembering to press the button.
I often just close the lid and DO NOT want the laptop to go to sleep - that is why I do not use it - but it works the same with hw.acpi.lid_switch_state=S3 in /etc/sysctl.conf file - it does not matter for FreeBSD if zzz(8) commands triggers S3 state or something else.
> Also, I wonder why this doesn't trigger any authentication when starting back up. Anyone could snatch that laptop and still be logged in.
The purpose of this videos were to show only the suspend/resume process of FreeBSD system.
In my daily life I have two shortcuts related to this:
- [SUPER] + [L] - locks the system and leaves it running - and it requires to enter password
- [SUPER] + [CTRL] + [ALT] + [L] - locks the system AND PUTS IT INTO S3 SLEEP - and it requires to enter password if you wake it up
Hope that helps.
Regards,
vermaden
Excellent clarifications. Thank you!
To echo the other comments - I'm reasonably confident that the Linux kernel is perfectly capable of handling sleep, the problem is varied hardware support. Consider that every Chromebook and Android device on the planet is running a Linux kernel, and they have no trouble. Likewise, I don't think I've ever had Linux struggle with sleeping on a thinkpad, and the best suspend/resume experience I've ever had was Linux on a random Lenovo laptop a while back.
Having been on linux laptops for ~20 years, I've found this to be really h/w dependent.
I've mostly run thinkpads, and they've mostly worked. My current T16 not only suspendds/resumes well, I also successfully use full disk encryption recovery on boot from hibernate.
This is my experience too. Even though we don't hand off control to the (often buggy) BIOS anymore, there is still a fair bit of hardware support that needs to be in place to have a smooth suspend/resume. Even on the Windows install that shipped with the laptop I've had machines that fail to suspend properly and turn into bagwarmers or that fail to restore the graphics when waking back up or any number of potential issues. I've even had machines that brick their SSDs the first time you put them to sleep. Permanently bricked, can't even be wiped or factory reset bricked.
Concur. I have seen issues with suspend on Linux in the past, but my last three Dell laptops suspend just fine. Usually the only weirdness is with laptops that don't have an S3 state anymore, or when you add/remove hardware in between being awake and asleep.
That said (and it pains me to say it), the experience is still nowhere near as flawless as MacOS on Silicon hardware.
For the record - this FreeBSD installation from videos also uses Full Disk Encryption in the form of GELI under the ZFS - its really brain dead simple to setup - just use 'Auto (ZFS)' option in the FreeBSD bsdinstall(8) installer and set Encrypt Disks to YES - nothing else required.
> set Encrypt Disks to YES - nothing else required.
Plus "Encrypt Swap" should ~always be used even on non Root-GELI-Systems ;)
I thought root-on-ZFS did not work well with hibernate, for some reason? Did I misunderstand something?
FreeBSD - from what I know - does not support Hibernation (S4) - it supports Suspend/Resume (S3) - as shown in video.
The difference:
Suspend/Resume (S3)
CPU is powered off. RAM maintains power and data. Very low power usage. Sometimes referred to as 'Save to RAM' or 'Standby'.
Hibernation (S4)
CPU is powered off. RAM is powered off. Data/RAM/files wrote to disk. Power is off. Sometimes referred to as 'Save to Disk'.
Got it, thanks!
> Wonder if the results are the same if they closed the lid
This is a default setting that I never understood.
Nearly all laptops/keyboard have a sleep button, power button is often configured by default to also go to sleep. Additionnally you can configure to go automatically to sleep if inactive and on battery for a few minutes. Why would I want my laptop to go to sleep immediately when I close the lid?
Half of the time when I am closing the lid, it is to move from one space/room to another. I don't want my git pull/push, my music or my video call to stop for 20-30 seconds because I am just going from my sofa to my kitchen or from my desk to a meeting room.
And I don't want to be that dummy project manager who moves awkwardly from one place to another with his coffee cup in one hand and an opened laptop on the other hand nearly hitting everyone or the office plants in the process just because he is too dumb to configure his laptop correctly.
Login?
The purpose of this videos were to show only the suspend/resume process of FreeBSD system.
In my daily life I have two shortcuts related to this:
- [SUPER] + [L] - locks the system and leaves it running - and it requires to enter password
- [SUPER] + [CTRL] + [ALT] + [L] - locks the system AND PUTS IT INTO S3 SLEEP - and it requires to enter password if you wake it up
Hope that helps.
Regards,
vermaden
Now if we can make FreeBSD to dual boot with Windows or Linux with UEFI SecureBoot enabled (corp IT requirement), that would be a blast... Maybe one day I will be able to try it by booting from a USB drive...
I made a minimal debian wrapper installation on an nvme drive in an usb enclosure that add support for secure boot, encryption, bluetooth, wifi and start whatever OS I want to run on qemu. The thing check total memory and cores of the machine and start the VM with VM CPUS = TOTAL CPU CORES - 2 and VM MEMORY = TOTAL MEMORY - 1GB. The sway compositor is configured to automatically start virt-viewer in full screen at boot connecting to the chosen VM as well as bluetooth/pavucontrol/nm-tui in a hidden virtual desktop.
I initially built it to have a portable yet as close to bare metal experience as possible with operating systems such as Haiku that do not necessarily have all features + best hardware support but this could be totally done for a BSD. Although you rely on it to connect a new bluetooth device, wifi network, the idea is to spend the less time possible on the underlying debian host OS.
I did it manually but I should really do an ansible playbook that people can adapt to their distro of choice.
What's the point here? Suspend on my Lenovo T480s works great on Linuxmint (which is just an Ubuntu compiled kernel). It doesn't have that jarring boot into console mode with output, it just wakes up into X again.
My Mac Laptop is still far and away the best experience (Because Apple controls every bit of hardware). You open it up and within a minisecond it's ready to work. My linux laptop takes at least 5 seconds before you can login - same as shown in this video.
I believe FreeBSD is usually treated as a 'server' operating system 'useless' on the desktop/laptop pattern usage.
The point is to show that FreeBSD is a general purpose operating system and also works great on the desktop/laptop scenario.
Ahh right. Makes sense. Thank you. I know lots of people that use FreeBSD as their desktop so I hadn't clocked this aspect.