Yeah if you are working with Linux only, its better to go full linux.
WSL2 is really handy when you want to run other software though. For example, I use Solidworks, so I need to run windows. Forscan for Ford vehicles also has to run under Windows. Having WSL2 means that I can just have one laptop and run any software that I want.
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.
> Windows has known issues of waking a sleeping laptop.
Doesn't Linux as well?
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'm on Ubuntu 25.04, 128GB RAM, pcie 5 SSD, NVIDIA 5080, 9950X3D.
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.
Be pragmatic, use the binaries provided by nvidia and not the ones provided by Ubuntu.
Or use Suse, only distro that manages that well. Forget PopOS. Really, either binaries or Suse.
If someone else here is entrenched on Arch, do this: https://github.com/Frogging-Family/nvidia-all
If on Fedora, just use the binaries... trust me.
Hope this helps someone.
Try a lower version of the Nvidia driver. The newer version was causing me and folk I work with a lot of problems.
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.
In my experience Ubuntu has the worst issues with displays of any distro.
To be fair I stay away from NVIDIA to, I would probably run a separate headless box for those GPU workloads if I needed to
Yeah, Ubuntu used to be the distro that "just worked" while nowadays that crown has passed to Fedora.
> In my experience Ubuntu has the worst issues with displays of any distro.
In my experience, it has zero issues. I use nvidia binary build. I have since 2006 through various nvidia GPU's.
Install Pop_OS! for better OOTB NVIDIA support.
Make sure your device is compatible with WSL this way, its very fragile and prone to breaking
Ahhh, the famous "Works on my machine!" stamp of truth.
"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:
https://wiki.archlinux.org/title/Framework_Laptop_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.
I had these issues with Windows, but with Linux Mint it works perfectly.
Not of you don't buy Windows hardware and slap Linux on it.
Unfortunately, most (almost all) hardware is Windows hardware. So far, System76 is the only one that I've had actually work.
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.
Tell me how its not their fault ?
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.
Firmware also plays a huge role these days (fan curves, ACPI, power management, etc.)
But saying it can vary largely by distro is overstating it by a lot. Mostly, distro issues are going to be based on how old their kernels are.
But definitely, modern hardware is much too complex to just slap Linux on Windows (and vice versa).
I have Linux on MacBooks from 6 different years. They all work flawlessly. I also have a Lenovo that works well.
Sorry you have had such bad luck.
I am running ChromeOS with Debian 'slapped on it' and that also experience sleep related issues.
Big fan of Linux, but saying that Linux works on system76 while they have a tiny sliver of the Linux market share seems like a nonstarter.
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.
Turns out you get what you pay for.
You can either get hardware that works or you can deal with breakage.
System76 seems janky though if you use anything but PopOS
I run Gentoo on all but one of my system76 boxen, and have not seen any jank
You can force it to behave on Linux ;)
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.
I use virt-manager and suspend/restore for the same feature, doesn't using an oracle product (with all the side-effects that brings).
I use libvirt/kvm/qemu. It works fine to do all the things mentioned like snapshots.
> My development is mainly Windows and I prefer Linux host with Windows VM guests
I've tried this in the past but I was unable to get the debugger to work from within a VM.
Has this improved, or is there a trick, or are you just going without a debugger?
In the same spirit if "it depends", there are other options that may work for people with different Linux/Windows balance points:
* Wine is surprisingly good these days for a lot of software. If you only have an app or two that need Windows it is probably worth trying Wine to see if it meets your needs.
* Similarly, if gaming is your thing Valve has made enormous strides in getting the majority of games to work flawlessly on Linux.
* If neither of the above are good enough, dual booting is nearly painless these days, with easy setup and fast boot times across both OSes. I have grub set to boot Linux by default but give me a few seconds to pick Windows instead if I need to do one of the few things that I actually use Windows for.
Which you go for really depends on your ratio of Linux to Windows usage and whether you regularly need to mix the two.
And you also can just run a windows VM when needed for a few apps if that works for your use case.
I'm struggling to find an option for running x86 Windows software on MacOS/Apple Silicon performantly. (LiDAR point cloud processing.)
The possibilities seem endless and kinda confusing with Windows on ARM vs Rosetta and Wine, think there's some other options which use MacOS's included virtualization frameworks.
Have you tried CloudCompare? Native Mac ARM support.
https://www.cloudcompare.org/
(Edit: just so you know, the UI is a bit weird, there is a bit of a learning curve. But the app behaves in a very sane manner, with every step the previous state is maintained and a new node is created. It takes time to get used to it, but you'll learn to appreciate it.
May your cloud have oriented normals, and your samples be uniformely distributed. Godspeed!)
I like cloudcompare, but it's not really in the same space. I'm trying to achieve bulk tile processing of large datasets using LASTools
That’s interesting; I’d expect something techie like that to have good Linux programs.
Have you tried to install Windows 11 ARM under UTM on Mac? UTM is a kind of open source Parallels. Then you'll run x86 software using Windows' variant of Rosetta. Probably slower than Rosetta but perhaps good enough.
In case others were similarly confused, I thought that UTM was commercial but it is Apache 2 https://github.com/utmapp/UTM/blob/v4.6.5/LICENSE
I wanted to play around with Windows 11 for a while now. It boots in UTM just to the degree that I can confirm my suspicions that Windows 11 sucks compared to Windows 10, but is not otherwise usable. (MacBook Air M3, slightly outdated macOS)
Try Whisky: https://github.com/Whisky-App/Whisky
> Forscan for Ford vehicles also has to run under Windows.
I've successfully run it with WINE. Thought, my Forscan executable was 3 years old or so and that may have changed, but I doubt it.
The thing about WINE is that it's not necessarily solid enough to rely on at work. You never know when the next software upgrade will break something that used to work.
That's always true, of course. But, compared to other options, relying on WINE increases the chances of it happening by an amount that someone could be forgiven for thinking isn't acceptable.
In my mind, I almost feel like the opposite is true. Wine is getting better and better, especially with the amount of resources that Valve is putting into it.
If you want a stable, repeatable way to wrangle a Windows tool: Wine is it. It's easy to deploy and repeat, requires no licenses, and has consistent behavior every time (unless you upgrade your Wine version or something). Great integration with Linux. No Windows Updates are going to come in and wreck your systems. No licensing, no IT issues, no active directory requirements, no forced reboots.
You can fix this issue by using a wine "bottle manager" like... Bottles. This allows you to easily manage multiple instances of wine installations (like having multiple windows installations) with better and easy to use tooling around it. More importantly, it also allows you to select across many system agnostic versions of wine that won't be upgraded automatically thus reducing the possibility of something that you rely breaking on you.
Or pony up for CodeWeavers. Their code goes into WINE, and they are (the?) major WINE devs. They've had bottles for years, if not decades now.
I used to a long time ago but even back then I was getting more value out of q4wine (a defunct project now) than from CodeWeavers stuff. Granted, I was perhaps too "enthusiast" using git versions of wine with staging patches and my own patches rolled into it, so q4wine (and I guess now Bottles) more DIY approach won me over.
That all said, I haven't tried CodeWeavers in almost 10 years so it might have improved a lot.
No, if wine itself breaks a bottle won't save you.
Same about windows upgrades nowadays really, there's a ton of software which just stopped working.
When I hear cases of using Wine etc as a substitute, I can't help but think of the "We have McDonald's at home" meme!
Wine is fantastic, but it is fantastic in the sense of being an amazing piece of technology. It's really lacking bits that would make it a great product.
It's possible to see what Wine as a great product would look like. No offense to crossover because they do good work, but Valve's Steam Play shows what you can really do with Wine if you focus on delivering a product using Wine.
Steam offers two main things:
- It pins the version of Wine, providing a unified stable runtime. Apps don't just break with Wine updates, they're tested with specific Proton versions. You can manually override this and 9 times out of 10 it's totally fine. Often times it's better. But, if you want it to work 10 out of 10 times, you have to do what Valve does here.
- It manages the wineserver (the lifecycle of the running Wine instance) and wine prefix for you.
The latter is an interesting bit to me. I think desktop environments should in fact integrate with Wine. I think they should show a tray icon or something when a Wineserver is running and offer options like killing the wineserver or spawning task manager. (I actually experimented with a standalone program to do this.[1]) Wine processes should show up nested under a wineserver in system process views, with an option to go to the wineprefix, and there should be graphical tools to manage wine prefixes.
To be fair, some of that has existed forever in some forms, but it never really felt that great. I think to feel good, it needs to feel like it's all a part of the desktop system, like Wine can really integrate into GNOME and KDE as a first-class thing. Really it'd be nice if Wine could optionally expose a D-Bus interface to make it so that desktop environments could nicely integrate with it without needing to do very nasty things, but Wine really likes to just be as C/POSIX/XDG as possible so I have no idea if something like that would have a snowball's chance in hell of working either on the Wine or desktop environment side.
Still, it bums me out a bit.
One pet peeve of mine regarding using Wine on Linux is that EXE icons didn't work out of the box on Dolphin in NixOS; I found that the old EXE thumb creator in kio-extras was a bit gnarly and involved shelling out to an old weird C program that wasn't all that fast and parsing the command line output. NixOS was missing the runtime dependency, but I decided it'd be better to just write a new EXE parser to extract the icon, and thankfully KDE accepted this approach, so now KDE has its own PE/NE parser. Thumb creators are not sandboxed on KDE yet, so enable it at your own risk; it should be disabled by default but available if you have kio-extras installed. (Sidenote: I don't know anything about icons in OS/2 LX executables, but I think it'd be cool to make those work, too.) The next pet peeve I had is that over network shares, most EXE files I had wouldn't get icons... It's because of the file size limit for remote thumbnails. If you bump the limit up really high, you'll get EXE thumbnails, but at the cost of downloading every single EXE, every single time you browse a remote folder. Yes, no caching, due to another bug. The next KDE frameworks version fixes most of this: other people sorted out multiple PreviewJob issues with caching on remote files, and I finally merged an MR that makes KIO use kio-fuse when available to spawn thumb creators instead of always copying to a temporary file. With these improvements combined, not just EXE thumbnails, but also video thumbnails work great on remote shares provided you have kio-fuse running. There's still no mechanism to bypass the file size limit even if both the thumbcreator and kio-fuse remote can handle reading only a small portion of the file, but maybe some day. (This would require more work. Some kio slaves, like for example the mpt one, could support partially reading files but don't because it's complicated. Others can't but there's no way for a kio-fuse client to know that. Meanwhile thumb creators may sometimes be able to produce a thumbnail without reading most of the file and sometimes not, so it feels like you would need a way to bail out if it turns out you need to read a lot of data. Complicated...)
I could've left most of that detail out, but I want to keep the giant textwall. To me this little bit of polish actually matters. If you browse an SMB share on Linux you should see icons for the EXE files just like on Windows, without any need to configure anything. If you don't have that, then right from the very first double-click the first experience is a bad one. That sucks.
Linux has thousands of these papercuts everywhere and easily hundreds for Wine alone. They seem small, but when you try to fix them it's not actually that easy; you can make a quick hack, but what if we want to do things right, and make a robust integration? Not as easy. But if you don't do that work, you get where we're at today, where users just expect and somewhat tolerate mediocre user experience. I think we can do better, but it takes a lot more people doing some ultimately very boring groundwork. And the payoff is not something that feels amazing, it's the opposite: it's something boring, where the user never really has any hesitation because they already know it will work and never even think about the idea that it might not. Once you can get users into that mode you know you've done something right.
Thanks for coming to my TED talk. Next time you have a minor pet peeve on Linux, please try to file a bug. The maintainers may not care, and maybe there won't be anyone to work on it, and maybe it would be hard to coordinate a fix across multiple projects. But honestly, I think a huge component of the problem is literally complacency. Most of us Linux users have dealt with desktop Linux forever and don't even register the workarounds we do (anymore than Windows or Mac users, albeit they probably have a lot less of them.) To get to a better state, we've gotta confront those workarounds and attack them at the source.
[1]: https://github.com/jchv/winemon just an experiment though.
If you (or whoever is reading this) want(s) a more refined Wine, I highly recommend CodeWeavers. Their work gets folded back into open source WINE, no less.
> To get to a better state, we've gotta confront those workarounds and attack them at the source.
To my eye, the biggest problem with Linux is that so few are willing to pony up for its support. From hardware to software.
Buy Linux computers and donate to the projects you use!
That's true, but even when money is donated, it needs to be directed somewhere. And one big problem, IMO, is that polish and UX issues are not usually the highest priority to sort out; many would rather focus on higher impact. That's all well and good and there's plenty of high impact work that needs to be done (we need more funding on accessibility, for example.) But if there's always bigger fires to put out, it's going to be rather hard to ever find time to do anything about the random smaller issues. I think the best thing anyone can do about the smaller issues is having more individual people reporting and working on them.
If your at work, it's probably a Windows shop. Use windows. At home you can chance a bad update, and probably also have access to windows. Can always use a VM, wine is great in some cases, like WSL. Both don't meet every use case.
They named it “Forscan?” They really named it that, not thinking it could sound close to something else entirely unrelated?
Surely you don't think the executives at Ford expect us to Power Stroke without FORScan?
Ford’s own software is called FDRS.
Forscan was developed independently by some Russian gentlemen, probably with plenty of reference to FDRS/IDS internals.
Volkswagen's equivalent is VAG-COM
why bring wine into a vm discussion? just run windows in a vm too. problem solved without entering the whining about wine not being better than windows itself
I work in embedded systems. In that space, it's pretty common to need some vendor-provided tool that's Windows-only. I often need to automate that tool, maybe as part of a CI/CD pipeline or something.
If I were to do it with a Windows VM, I'd need to:
If I do it with Wine instead, all I need to do is:> For example, I use Solidworks, so I need to run windows.
Right. One of the things a lot of people don't get is the extent to which multidisciplinary workflows require Windows. This is particularly true of web-centric software engineers who simply do not have any exposure to the rest of the engineering universe.
Years ago this was the reason we had to drop using Raspberry Pi's little embedded microcontroller. The company is Linux-centric to such an extent that they simply could not comprehend how telling someone "Just switch to Linux" is in a range between impossible and nonsensical. They were, effectively, asking people to upend their PLM process just for the sake of using a little $0.50 part. You would have to do things like store entire OS images and configurations just to be able to reconstruct and maintain a design iteration from a few years ago.
WSL2 is pretty good. We still haven't fully integrated this into PLM workflows though. That said, what we've done on our machines was to install a separate SSD for WSL2. With that in place, backing-up and maintaining Linux distributions or distributions created in support of a project is much, much easier. This, effectively, in some ways, isolates WSL2 distributions from Windows. I can clone that drive and move it from a Windows 10 machine to a Windows 11 machine and life is good.
For AI workflows with NVIDIA GPU's WSL2 is less than ideal. I don't know if things have changed in this domain since I last looked. Our conclusion from a while back was that, if you have to do AI with the usual toolchains, you need to be on a machine running Linux natively rather than a VM running under Windows. It would be fantastic if this changed and one could run AI workflows on WSL2 without CUDA and other issues. Like I said, I have not checked in probably a year, maybe things are better now?
EDIT: The other reality is that one can have a nice powerful Linux machine next to the Windows box and simply SSH into it to work. Most good IDE's these days support remote development as well. If you are doing something serious, this is probably the best setup. This is what we do.
Did you know that Forscan works flawlessly under Wine if you're not using Bluetooth?
Im sure with enough tinkering I could get Solidworks to run. The thing is I don't want to spend time tinkering, I want to spend time doing. WSL2 gives me the optimal solution for all of that + dev.
I really want to like Windows 11, and I enjoy using WSL, but Microsoft treats me too much like an adversary for me to tolerate it as a daily driver. Only a complete scumbag of a product manager would think pushing Candy Crush ads is a good idea.
I’ve got an airgapped Toughbook that I use for the few Windows apps I really need to talk to strange hardware.
I suggest looking into Windows LTSC. It has solved most of the annoyances for me.
You don't need LTSC, you just need Windows Pro versions.
Lots of people bitch and moan about Windows problems that only exist because they buy the cheaper "Home" or whatever license and complain that Microsoft made different product decisions for average users than for people who have bought the explicitly labeled "power user" version.
Remember, the average computer user IS a hostile entity to Microsoft. They will delete System32 and then cry that Windows is so bad! They will turn off all antivirus software and bitch about Windows being insecure. They refuse to update and then get pwned and complain. They blame Microsoft for all the BSODs that were caused by Nvidia's drivers during the Vista era. They will follow a step by step procedure in some random forum from ten years ago that tells them to turn off their entire swap file despite running with lots of RAM and spinning rust and then bitch that Windows is slow.
Don't expect Microsoft to not deal with morons using their software. Buy the Pro versions if you don't want the version meant for morons.
I’m on Enterprise.
I shouldn’t need to spend this much time and energy turning off AI rubbish, bypassing cloud features, or knobbling telemetry and ads because some shitbag at Microsoft decided this was a good way of getting a promotion.
My computer is supposed to work for me, not the other way around.
Windows is only free if you don't value your time, it seems :-)
You do need to get Win 11 pro to be able to disable all of those features.
I run Windows in a VM where I need windows. It’s so much easier to fix a broken Linux installation than a broken Windows installation.