My experience is similar to BD139; Linux is very finicky when suspending to RAM or Disk. I suspect that, most of the time, the video subsystem is the one to blame.
I agree. I have an HP EliteBook 820 G2 and a 840 G4 (the latter has a much nicer display BTW), using built-in Intel graphics with the in-kernel drivers, and they suspend (to RAM or to disk) just fine. (Four, five years of active use now.)
In both, the built-in touchpad (Synaptics SynPS/2) has occasional glitches waking up, somehow dropping multi-touch support and acceleration/speed profile, but unloading and reloading the driver (
psmouse) fixes those. The 840 G4 is now running on its second battery (the first one started expanding), and a replacement keyboard (25€ off eBay, seems OEM or equivalent quality, but couldn't find Finnish layout, so now my keycaps have a few Norwegian caps instead of the Finnish ones (Ø instead of Ö, Æ instead of Ä, plus three caps with partially incorrect glyphs near the corners of the keyboard). Just make sure you have a fast SSD when using a Linux laptop; that makes the most difference user-experience-wise.
Suspend to disk (hibernation) is a bit weird case, because there are two completely separate ways to do it. One is to let the kernel handle it, putting the image into swap. This has the downside that depending on the swap size and state, the suspend may actually fail occasionally. The other is to use userspace tools like uswsusp (µswsusp) or hibernate. Some tools like commonly used pm-utils can support all three (kernel, uswsusp, hibernate). On many machines, all three work fine; but on some, depending on the hardware, only two or one of them works reliably. On some systems, a kernel driver (especially video drivers) can prevent suspend-to-disk, because they do not provide the power manager hooks the kernel needs to do this. In some cases, (privileged) userspace applications or services can prevent suspend and hibernation.
In the last five or so years, I do have observed more and more issues that can be traced to internal systemd interactions, that really need a reboot to solve. The common thing seems to be when a component gets updated during runtime (say, a security patch). These often look like kernel issues (except that if one has a console terminal open with root logged in, simple testing shows that the kernel is still operating normally, while userspace is seriously glitching), and are treated as such by most users and distribution maintainers, so the true impact of systemd to stability is unfortunately hidden. (One of my hobbies is tracking the root cause of these problems, and I'm skilled in this enough to have done e.g. kernel runtime patching and discovering rare bugs in standard libraries. It is dull drudge work, unless like me, you're addicted to problem solving.)
Now, I'm not as anti-systemd as PKTKS, but I see its impact on system stability and versatility, and I'm not happy about it, because as a completely optional userspace component – there is e.g.
Devuan, a Debian fork without systemd; and many embedded distros like OpenWRT also do not use systemd – with severe stability and security deficiencies it negatively affects systems, but its effects are usually ascribed to the Linux kernel. I hate that kind of blame-shifting.
For those who shut down and boot their Linux machines often enough, systemd tends to work without issues, so I am not saying it is useless. For some, it works just fine, and that makes it useful and worthwhile to such users. For organizations with lots of Linux machines, it may be a necessity, because finding support personnel for Linux that are familiar with systemd tends to be cheaper than finding those who can maintain a better customized system; and most bosses are unable to calculate the actual cost-benefit ratios of the two approaches, and prefer to go with the flow and not take any risks (that they cannot blame on someone else).
My main gripe is that in Linux, we have enough headaches by having a monolithic kernel (in that using proprietary video drivers makes it impossible to debug kernel issues, as those drivers' bugs can affect any part of the kernel, since there is no isolation at all between drivers); and now a lot of developers are trying to consolidate base system userspace services into a similar monolithic blob suffering from numerous single-point failure scenarios. It just makes no sense to me why they want that, and don't see the serious negative aspects at all. Like they've forgotten the decades of useful Unix paradigm experiences, and are shifting towards the Microsoft Windows model of operation.
To tie the above to this particular thread, just the other day I stumbled into another serious WSL2 issue wrt. Microsoft's current "Linux" support:
DNS issues. In short, the WSL2 DNS component completely fucks up some name lookups. In the case of "baidu.com", it inserts the results for "ns
X.baidu.com", causing e.g.
getnameinfo() C library function call to provide those too as the results for "baidu.com".
I'm sure this is to work around some kind of bug in the way Windows itself processes name service queries; probably somehow it needs those results for reverse lookup support, and internally filters them out. It is exactly the sort of fuckwittery MS did with OOXML (by defining certain properties as "model borders like Word 7", "model borders like Word 6", instead of defining their effects directly), which killed that "standard". They do say Microsoft is today much better wrt. its free/open source competitors, but this kind of stuff indicates old habits are deeply embedded within their corporate culture.
Which is the reason I personally still don't trust Microsoft. I mean, I don't trust them to do the best thing to their shareholders; the above kind of fuckwittery is too deeply embedded in their middle management, no matter what their board and chiefs and the design and programming teams intend.
Home
Help
Search
Login
Register
