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.
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.
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
> 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.
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.
13 replies →
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?
2 replies →
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.
1 reply →
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.
2 replies →
> 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.
12 replies →
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.