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?
Doesn't Linux as well?
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.
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.
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
In my experience, it has zero issues. I use nvidia binary build. I have since 2006 through various nvidia GPU's.
Side note: our main use case is using cuda for image processing.
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.
Unfortunately, most (almost all) hardware is Windows hardware. So far, System76 is the only one that I've had actually work.
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.
You can either get hardware that works or you can deal with breakage.
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.
Sorry you have had such bad luck.
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).
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.
* 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.
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.
(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'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.
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.
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.
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.
> 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 all said, I haven't tried CodeWeavers in almost 10 years so it might have improved a lot.
Forscan was developed independently by some Russian gentlemen, probably with plenty of reference to FDRS/IDS internals.
If I were to do it with a Windows VM, I'd need to:
1. Create the VM image and figure out how to build/deploy it.
2. Sort out the Windows licensing concerns.
3. Figure out how to launch my tool (maybe put an SSH server into the VM).
4. Figure out how to share the filesystem (maybe rsync-on-SSH? Or an SMB fileshare?).
1. Install some pinned version of Wine.
2. Install my tool into Wine.
3. Run it directly.I’ve got an airgapped Toughbook that I use for the few Windows apps I really need to talk to strange hardware.
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 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.
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.
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.