3 ms·

> My recommendation for happiness with Linux is: Always use native apps. Don’t use WINE. Don’t try to be compatible to inherent hostile things. Don’t use VMs. A

> My recommendation for happiness with Linux is: Always use native apps. Don’t use WINE. Don’t try to be compatible to inherent hostile things. Don’t use VMs. And especially don’t use Dual-Boot. It sucks. Had I listened to your recommendation, I would've never tried Linux. Sorry, but Linux doesn't run Photoshop. Or Valorant. Or certain VPNs, certain educational software, and doesn't work with a bunch of hardware. Dual booting is still a hell of a lot better than trying to configure Wine in most cases, but if doing everything natively on Linux was an option, it would've have taken SteamOS so many years to become even remotely usable. And even then people install Windows on their Steam Decks to run certain specific programs or games. For the same reason native Linux isn't an option, native macOS wouldn't have been an option back when I first tried Linux. And even today, programs like Paint.NET are dearly missed on Linux and macOS (yes, I know about Pinta), and stock macOS is infuriating to use without all manner of tools and background programs reminding me of my XP. I use Windows for my Windows tools, Linux most of the time, and macOS for my macOS work stuff. I'm not getting rid of either non-Linux OS because that would make doing certain things simply impossible.

eek2121 1y ago
WINE has basically become a gaming wrapper at this point. There are not many (modern) apps outside of games that run on WINE. However, games run great! Last I checked, Office 365 didn't work, Basically anything modern Adobe didn't work, even the latest version of Visual Studio (not VSCode) didn't work. Things may have changed, I just learned to live without that stuff.
- heavyset_go 1y ago
  A niche Wine does suit well is running audio plugins for music production. Wouldn't have believed it if I didn't first see and then use it myself. Think it's because JUCE is relatively well-supported on Wine and natively on Linux, there are hardly any dependencies outside of system libraries and a DSP library.
  - camtarn 1y ago
    Yeah, it's pretty mind-blowing how well this works, even though the setup was a bit janky. Sadly, after moving my music production setup from Windows to Linux, I'm locked out of some of my expensive sample libraries because while the plugins run fine, the licensing programs do not. Very frustrating.
- array_key_first 1y ago
  That's because all those apps are purposefully hostile and actively do everything in their power to make sure they don't work without their authorization. Solution: don't use those apps and maybe people will learn. Eventually, apps and technologies like this die in our digital landscape. Rest in piece Flash, you will be missed. 3D max and Photoshop, you're next. Real solution (for now): just don't give these assholes money. If you need to run the software, fine, but at least have the decency to steal it.
  - dangus 1y ago
    Let’s be real, this “real solution” is a teenager in the basement solution. I’m not going to steal commercial software that I use to produce my own commercial work. I happily pay Autodesk their stupid $600 a year because I get that much value out of the application and then some. This idea that they are purposefully hostile because they don’t want you to steal their commercial product, or they don’t support an operating system with 2% marketshare is ridiculous. I totally understand why they don’t support Linux. It’s my choice to use an incompatible system.
    - array_key_first 1y ago
      > happily pay Autodesk their stupid $600 a year because I get that much value out of the application and then some. Yes, you will, but big picture: eventually the software will die. Software isn't just a product, it's an extension of education and expression. Using paid-for commercial software is risky. What happens is young, aspiring professionals get taught that software, and then it's ripped from their hands because of the price. A lot of these young professionals give up or, more likely, switch to OS alternatives. And they make up the industry of the future. Eventually, the commercial product is pushed out because it can't keep up. But even if this doesn't happen, the product still dies. Because commercial software is ultimately held hostage. The BEST CASE scenario is you're eventually bled dry and squeezed. The common scenario is that the software disappears or isn't popular anymore, and you've lost hundreds of hours of skills. This even happens in dev spaces. If you chose COM+ for an application, you fucked up. You're stuck with it and it's painfully behind, well, everything. Or maybe you were seduced by how cool Oracle is. And it was... 20 years ago. Now, it's not a competitive database. But you're stuck paying for it. Had you just used MySQL or Postgres from the beginning, this wouldn't have happened. And then flash. Oh flash. Great technology, but it doesn't matter. The world moves on. If you chose flash for your website, you fucked up. And now 3D max. I give it 10 years. Blender is already ahead of it and all the professionals of tomorrow have jumped ship.
- Forgeties79 1y ago
  > Basically anything modern Adobe didn't work Well that’s just Adobe badumtsssss
- rpdillon 1y ago
  Wine is great for running the old versions of stuff that weren't shackled to the cloud. Adobe and MS Office versions from ~2013 or so work great, and are more than enough of an escape hatch when native tools don't quite cut it. Agree that modern apps are hit and miss.
aperrien 1y ago
I didn't know about Pinta, and now I do. Thank you!
cyanydeez 1y ago
Wouldn't even dual boot. But a cheap mini PC and keyboard mouse monitor switch. Done
- fuzzfactor 1y ago
  You are all correct if it works for you :) I like using two identical miniPC's, one for each monitor. Well, actually each monitor has two inputs and each PC two display outputs, and I had a couple extra cables so they are cross-connected too but that's besides the point. Seems like RDP is almost intended to work like this from the beginning. Deficiencies are a lot easier to tweak side-by-side too. Decades ago I just had to accept that a key purpose of introducing multi-partitioning to HDD's was so that multibooting from a single HDD would be extremely straightforward. And once set up, very closely mimics the hardware behavior of having a dedicated HDD or SSD for each of Windows and Linux, on the same PC. Previously, with two different HDD's connected, each completely unaware of the other one upon power-up, when you reboot you can always use the motherboard's built-in BIOS boot menu to choose when you want to boot to a drive other than the one designated as the default choice. That way there is nothing related to Windows on the Linux HDD at all, and nothing having to do with Linux on the Windows HDD. You can physically remove either drive before powering up and everything works completely dedicated to a single OS as expected, because each HDD is complete including its own boot files, exactly the same as it is in a non-multibooting arrangement. As long as each HDD is capable of booting on its own, you choose the one you want, and that's the one that boots. Well it actually took a while in the '90's before most motherboards had a built-in BIOS bootmenu to choose between different HDD's, but this feature became universal so users wouldn't have to physically reconnect their intended boot drive to the Primary Master cable. Which was the only bootable connection before the BIOS bootmenu made Secondary-connected HDD's as bootable as Primaries, your choice. You don't really have to get the most out of the electronics, but some things like this are really nice to have. Now this was the time when it got real fancy, and both Windows and Linux bootloaders were crafted to accommodate "chainloading" from a Primary HDD to a non-Primary, so physical reconnection would not be necessary to accomplish the same behavior. This was ideal for all the remaining motherboards at the time which were not issued with a BIOS bootmenu. This is where you start to get a mixture of Windows and Linux on the same HDD, at least in the boot files. It doesn't have to be confusing, but it can be. Once one set of boot files can boot either OS from any HDD, then each HDD no longer needs its own boot files, however that also means that those HDDs not having boot files would not boot if they are the only HDD connected. I say the BIOS bootmenu is the fundamental that is best not abstracted too far. Fortunately, multibooting to various SSD's using one single (Linux) bootloader [0] can be configured to have the same hardware workflow as choosing separate HDD's through the motherboard bootmenu. And to be the most consistent I like to use the same workflow to choose from multiple partitions whether they are on the same HDD or not. Now you can figure it's all moot, with separate miniPC's for Windows and Linux. Which really could be considered more of a luxury than multibooting a single-drive PC at will, and even more versatile than having two SSD's in the same PC. But wait a minute, each one of these drives on each PC is a massive multibooter . . . [0] The Windows bootloader works as always on MBR-layout SSD's on PC's supporting traditional BIOS mode, but still too defective under UEFI, where Microsoft drops the ball completely since Windows 8 in the key area of multibooting Linux. Which for decades was as easy as intended by the hardware design. But negative progress is accepted as progress by those who are supposed to be experts, as we have been convinced.
dangus 1y ago
+1 for this, and I’ll add Autodesk to this list. I tried everything. I tried some dude’s GitHub project to get it to work with Wine. It’s just not working for me. Something like this seems perfect for that use case.

eek2121 1y ago

WINE has basically become a gaming wrapper at this point. There are not many (modern) apps outside of games that run on WINE. However, games run great! Last I checked, Office 365 didn't work, Basically anything modern Adobe didn't work, even the latest version of Visual Studio (not VSCode) didn't work. Things may have changed, I just learned to live without that stuff.

heavyset_go 1y ago
A niche Wine does suit well is running audio plugins for music production. Wouldn't have believed it if I didn't first see and then use it myself. Think it's because JUCE is relatively well-supported on Wine and natively on Linux, there are hardly any dependencies outside of system libraries and a DSP library.
- camtarn 1y ago
  Yeah, it's pretty mind-blowing how well this works, even though the setup was a bit janky. Sadly, after moving my music production setup from Windows to Linux, I'm locked out of some of my expensive sample libraries because while the plugins run fine, the licensing programs do not. Very frustrating.
array_key_first 1y ago
That's because all those apps are purposefully hostile and actively do everything in their power to make sure they don't work without their authorization. Solution: don't use those apps and maybe people will learn. Eventually, apps and technologies like this die in our digital landscape. Rest in piece Flash, you will be missed. 3D max and Photoshop, you're next. Real solution (for now): just don't give these assholes money. If you need to run the software, fine, but at least have the decency to steal it.
- dangus 1y ago
  Let’s be real, this “real solution” is a teenager in the basement solution. I’m not going to steal commercial software that I use to produce my own commercial work. I happily pay Autodesk their stupid $600 a year because I get that much value out of the application and then some. This idea that they are purposefully hostile because they don’t want you to steal their commercial product, or they don’t support an operating system with 2% marketshare is ridiculous. I totally understand why they don’t support Linux. It’s my choice to use an incompatible system.
  - array_key_first 1y ago
    > happily pay Autodesk their stupid $600 a year because I get that much value out of the application and then some. Yes, you will, but big picture: eventually the software will die. Software isn't just a product, it's an extension of education and expression. Using paid-for commercial software is risky. What happens is young, aspiring professionals get taught that software, and then it's ripped from their hands because of the price. A lot of these young professionals give up or, more likely, switch to OS alternatives. And they make up the industry of the future. Eventually, the commercial product is pushed out because it can't keep up. But even if this doesn't happen, the product still dies. Because commercial software is ultimately held hostage. The BEST CASE scenario is you're eventually bled dry and squeezed. The common scenario is that the software disappears or isn't popular anymore, and you've lost hundreds of hours of skills. This even happens in dev spaces. If you chose COM+ for an application, you fucked up. You're stuck with it and it's painfully behind, well, everything. Or maybe you were seduced by how cool Oracle is. And it was... 20 years ago. Now, it's not a competitive database. But you're stuck paying for it. Had you just used MySQL or Postgres from the beginning, this wouldn't have happened. And then flash. Oh flash. Great technology, but it doesn't matter. The world moves on. If you chose flash for your website, you fucked up. And now 3D max. I give it 10 years. Blender is already ahead of it and all the professionals of tomorrow have jumped ship.
Forgeties79 1y ago
> Basically anything modern Adobe didn't work Well that’s just Adobe badumtsssss
rpdillon 1y ago
Wine is great for running the old versions of stuff that weren't shackled to the cloud. Adobe and MS Office versions from ~2013 or so work great, and are more than enough of an escape hatch when native tools don't quite cut it. Agree that modern apps are hit and miss.

aperrien 1y ago

I didn't know about Pinta, and now I do. Thank you!

cyanydeez 1y ago

Wouldn't even dual boot. But a cheap mini PC and keyboard mouse monitor switch. Done

fuzzfactor 1y ago
You are all correct if it works for you :) I like using two identical miniPC's, one for each monitor. Well, actually each monitor has two inputs and each PC two display outputs, and I had a couple extra cables so they are cross-connected too but that's besides the point. Seems like RDP is almost intended to work like this from the beginning. Deficiencies are a lot easier to tweak side-by-side too. Decades ago I just had to accept that a key purpose of introducing multi-partitioning to HDD's was so that multibooting from a single HDD would be extremely straightforward. And once set up, very closely mimics the hardware behavior of having a dedicated HDD or SSD for each of Windows and Linux, on the same PC. Previously, with two different HDD's connected, each completely unaware of the other one upon power-up, when you reboot you can always use the motherboard's built-in BIOS boot menu to choose when you want to boot to a drive other than the one designated as the default choice. That way there is nothing related to Windows on the Linux HDD at all, and nothing having to do with Linux on the Windows HDD. You can physically remove either drive before powering up and everything works completely dedicated to a single OS as expected, because each HDD is complete including its own boot files, exactly the same as it is in a non-multibooting arrangement. As long as each HDD is capable of booting on its own, you choose the one you want, and that's the one that boots. Well it actually took a while in the '90's before most motherboards had a built-in BIOS bootmenu to choose between different HDD's, but this feature became universal so users wouldn't have to physically reconnect their intended boot drive to the Primary Master cable. Which was the only bootable connection before the BIOS bootmenu made Secondary-connected HDD's as bootable as Primaries, your choice. You don't really have to get the most out of the electronics, but some things like this are really nice to have. Now this was the time when it got real fancy, and both Windows and Linux bootloaders were crafted to accommodate "chainloading" from a Primary HDD to a non-Primary, so physical reconnection would not be necessary to accomplish the same behavior. This was ideal for all the remaining motherboards at the time which were not issued with a BIOS bootmenu. This is where you start to get a mixture of Windows and Linux on the same HDD, at least in the boot files. It doesn't have to be confusing, but it can be. Once one set of boot files can boot either OS from any HDD, then each HDD no longer needs its own boot files, however that also means that those HDDs not having boot files would not boot if they are the only HDD connected. I say the BIOS bootmenu is the fundamental that is best not abstracted too far. Fortunately, multibooting to various SSD's using one single (Linux) bootloader [0] can be configured to have the same hardware workflow as choosing separate HDD's through the motherboard bootmenu. And to be the most consistent I like to use the same workflow to choose from multiple partitions whether they are on the same HDD or not. Now you can figure it's all moot, with separate miniPC's for Windows and Linux. Which really could be considered more of a luxury than multibooting a single-drive PC at will, and even more versatile than having two SSD's in the same PC. But wait a minute, each one of these drives on each PC is a massive multibooter . . . [0] The Windows bootloader works as always on MBR-layout SSD's on PC's supporting traditional BIOS mode, but still too defective under UEFI, where Microsoft drops the ball completely since Windows 8 in the key area of multibooting Linux. Which for decades was as easy as intended by the hardware design. But negative progress is accepted as progress by those who are supposed to be experts, as we have been convinced.

dangus 1y ago

+1 for this, and I’ll add Autodesk to this list. I tried everything. I tried some dude’s GitHub project to get it to work with Wine. It’s just not working for me. Something like this seems perfect for that use case.