My development is mainly Windows and I prefer Linux host with Windows VM guests. The experience is more stable and I can revert to a snapshot when Windows or Microsoft product update brakes something or new test configuration does. It also allows to backup and retain multiple QA environments that are rarely used, like a client's Oracle DB. It is nice being able to save the VM state at the end of the week and shut it all down so you can start the next right where you left off. Cannot do that when your development environment is the bare metal OS. Windows has known issues of waking a sleeping laptop.
I too think it would be definitely more stable Linux Host with Win VM guests, but I can see the other way around being more convenient to get support for commercially. Though with the VMWare licensing changes, I think what is by default easier for commercial support options may be changing too.
I'm on Lenovo Yoga 6, Gentoo, 6.12 kernel, 4.20 Xfce. Sleeps works perfect. Same on my Asus+AMD desktop. I've not had sleep related issues for years. And last time I did, it was an out-of-tree Wifi driver causing the whole mess.
I discovered over the weekend that only 1 monitor works over HDMI, DisplayPort not working, tried different drivers.
Suspend takes a good 5 minutes, and on resume, the UI is either turn or things barely display.
I might buy a Windows license, especially if I can't get multi-screen to work.
This has been a pain point for us and our development process… not all versions of Nvidia drivers are the same… even released ones. You have to find a “good” version and keep to it, and then selectively upgrade… at least this has been the case the last 5 years, folks shout out if they have had different experiences.
Side note: our main use case is using cuda for image processing.
"Works on my machine!" is stupid when it comes to software running under an OS, because a userland program that is correct shouldn't work any differently from box to box. (Exceptions you already know notwithstanding.) It is very different when it comes to an operating system.
I know people here hate this, but if you want a good Linux experience, you need to start by picking the right hardware. Hardware support is far and away the number one issue with having a good Linux experience anymore. It's, unfortunately, very possible to even set out to pick good hardware and get burnt for various reasons, like people misrepresenting how well a given device works, or perhaps just simply very similar SKUs having vastly different hardware/support. Still, i'm not saying you have to buy something from a vendor like System76 that specifically caters to Linux. You could also choose a machine that just happens to have good Linux support by happenstance, or a vendor that explicitly supports Linux as an option. I'm running a Framework Laptop 16 and it works just fine, no sleep issues. As far as I know, the sole errata that exists for this laptop is... Panel Self Refresh is broken in the AMDGPU driver. It sorta works, but it's a bit buggy, causing occasional screen artifacts. NixOS with nixos-hardware disables it for me using the kernel cmdline argument amdgpu.dcdebugmask=0x10. That's about it. The fingerprint reader is a little fidgety, and Linux could do a better job at laptop audio out of the box, but generally speaking the hardware works day in and day out. It's not held together with ducktape.
I don't usually bother checking to see if a given motherboard will work under Linux before buying it, since desktop motherboards tend to be much better about actually running Linux well. For laptops, Arch wiki often has useful information for a given laptop. For example, here's the Arch wiki regarding the Framework 16:
It's fair to blame Linux for the faults it actually has, which are definitely numerous. But let's be fair here, if you just pick a given random device, there is a good chance it will have some issues.
I recall having a sleep issue with linux 15 years ago, I think its been fixed long ago, except maybe on some very new hardware or if you install the wrong linux on an M series Mac you could have issues with sleep.
The less coupled software is to hardware, the less likely it is tested in that hardware and the higher likelihood of bugs. Linux can run fine but arbitrary Linux distros may not. This is not the fault of hardware makers.
> The less coupled software is to hardware, the less likely it is tested in that hardware and the higher likelihood of bugs.
Yes, exactly! There are whole teams inside Dell etc. dealing with this. The term is "system integration." If you're doing this on your own, without support or chip unfo, you are going to (potentially) have a very, very bad time.
> This is not the fault of hardware makers.
It is if they ship Linux on their hardware.
This is why you have to buy a computer that was built for Linux, that ships with Linux, and with support that you can call.
Hardware support is more than just kernel support. Additionally, not every kernel release works well for every piece of hardware. Each distro is unique and ensuring the correct software is used together to support the hardware can be difficult when you are not involved in the distro. This is why vertical integration between the distro and hardware leads to higher quality.
ChromeOS, where sleep presumably worked, is also Linux. You just exchanged a working Linux for a distro with more bugs. The fact that you're able to do that is pretty cool.
That's not to detract from the larger point here though. It's pretty funny that all of the replies in this thread identify different causes and suggest different fixes for the same symptom. Matches my experience learning Linux very well.
Can you share more details of how you make that work well? What hypervisor, what backup/replication, for instance? I can only imagine that being a world of irritation.
It's been a few years since I used it, but Virtualbox (free) had perfectly good suspend/restore functionality, and the suspended VM state was just a file.