5 ms·

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 Solid

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.

0xfeba 1y ago
> 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.
- bunderbunder 1y ago
  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.
  - the__alchemist 1y ago
    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!
    - jchw 1y ago
      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 https://github.com/jchv/winemon just an experiment though.
      - trelane 1y ago
        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!
        jchw 1y ago
        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.
  - damion6 1y ago
    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.
  - nrclark 1y ago
    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.
  - realusername 1y ago
    Same about windows upgrades nowadays really, there's a ton of software which just stopped working.
  - amlib 1y ago
    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.
    - trelane 1y ago
      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.
      - amlib 1y ago
        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.
    - guappa 1y ago
      No, if wine itself breaks a bottle won't save you.
- 1oooqooq 1y ago
  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
  - nrclark 1y ago
    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: 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?). If I do it with Wine instead, all I need to do is: 1. Install some pinned version of Wine. 2. Install my tool into Wine. 3. Run it directly.
- russfink 1y ago
  They named it “Forscan?” They really named it that, not thinking it could sound close to something else entirely unrelated?
  - skyyler 1y ago
    Surely you don't think the executives at Ford expect us to Power Stroke without FORScan?
    - bigfatkitten 1y ago
      Ford’s own software is called FDRS. Forscan was developed independently by some Russian gentlemen, probably with plenty of reference to FDRS/IDS internals.
  - xxpor 1y ago
    Volkswagen's equivalent is VAG-COM
therein 1y ago
Did you know that Forscan works flawlessly under Wine if you're not using Bluetooth?
- ActorNightly 1y ago
  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.
lolinder 1y ago
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.
- jacobr1 1y ago
  And you also can just run a windows VM when needed for a few apps if that works for your use case.
- oasisbob 1y ago
  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.
  - bee_rider 1y ago
    That’s interesting; I’d expect something techie like that to have good Linux programs.
  - grujicd 1y ago
    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.
    - 1y ago
yndoendo 1y ago
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.
- dv_dt 1y ago
  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.
- wpm 1y ago
  > Windows has known issues of waking a sleeping laptop. Doesn't Linux as well?
  - edoceo 1y ago
    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.
    - nevi-me 1y ago
      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.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
bigfatkitten 1y ago
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.
- zeppelin101 1y ago
  I suggest looking into Windows LTSC. It has solved most of the annoyances for me.
  - mrguyorama 1y ago
    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.
    - bigfatkitten 1y ago
      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.
robomartin 1y ago
> 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.
op00to 1y ago
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.

0xfeba 1y ago

> 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.

bunderbunder 1y ago
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.
- the__alchemist 1y ago
  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!
  - jchw 1y ago
    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 https://github.com/jchv/winemon just an experiment though.
    - trelane 1y ago
      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!
      - jchw 1y ago
        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.
- damion6 1y ago
  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.
- nrclark 1y ago
  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.
- realusername 1y ago
  Same about windows upgrades nowadays really, there's a ton of software which just stopped working.
- amlib 1y ago
  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.
  - trelane 1y ago
    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.
    - amlib 1y ago
      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.
  - guappa 1y ago
    No, if wine itself breaks a bottle won't save you.
1oooqooq 1y ago
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
- nrclark 1y ago
  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: 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?). If I do it with Wine instead, all I need to do is: 1. Install some pinned version of Wine. 2. Install my tool into Wine. 3. Run it directly.
russfink 1y ago
They named it “Forscan?” They really named it that, not thinking it could sound close to something else entirely unrelated?
- skyyler 1y ago
  Surely you don't think the executives at Ford expect us to Power Stroke without FORScan?
  - bigfatkitten 1y ago
    Ford’s own software is called FDRS. Forscan was developed independently by some Russian gentlemen, probably with plenty of reference to FDRS/IDS internals.
- xxpor 1y ago
  Volkswagen's equivalent is VAG-COM

therein 1y ago

Did you know that Forscan works flawlessly under Wine if you're not using Bluetooth?

ActorNightly 1y ago
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.

lolinder 1y ago

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.

jacobr1 1y ago
And you also can just run a windows VM when needed for a few apps if that works for your use case.
oasisbob 1y ago
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.
- bee_rider 1y ago
  That’s interesting; I’d expect something techie like that to have good Linux programs.
- grujicd 1y ago
  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.
  - 1y ago

yndoendo 1y ago

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.

dv_dt 1y ago
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.
wpm 1y ago
> Windows has known issues of waking a sleeping laptop. Doesn't Linux as well?
- edoceo 1y ago
  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.
  - nevi-me 1y ago
    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.

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

bigfatkitten 1y ago

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.

zeppelin101 1y ago
I suggest looking into Windows LTSC. It has solved most of the annoyances for me.
- mrguyorama 1y ago
  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.
  - bigfatkitten 1y ago
    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.

robomartin 1y ago

> 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.

op00to 1y ago

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.