Hacker News Reader

Comment by MrPowerGamerBR | Hacker News Reader

> Oh!, and the one thing I miss is Affinity Designer.

While I haven't experimented with it that much yet, Affinity (the new one, the one after the Canva acquisition) does work in Wine 10.20.

Now, I won't say it is a smooth experience, one of the workarounds that I needed to do is use Wine's virtual desktop so Affinity's tooltips are rendered correctly instead of being pure black, and the GUI does seem to not render correctly sometimes (it renders as white until something causes a redraw).

The Canva global marketing lead did say that Linux support is "being discussed seriously internally": https://techcentral.co.za/affinity-for-linux-canvas-next-big...

This makes you wonder: How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?

View on HN

  > How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?

First 80% of a job typically takes 80% of the allocated time. The last 20% of a job typically takes another 80% of the allocated time.

Yeah, the 80/80 rule. That made me smile.

> This makes you wonder: How hard it could be for a business that already has a 80% working application via Wine to patch the application/Wine to make it work 99+%, and then bundle the application with Wine and say that it has "native Linux support"?

CodeWeavers (developers of CrossOver and one of the main contributors and sponsors of Wine and related tools) actually offer something like this as a paid service for companies called PortJump:

https://www.codeweavers.com/portjump

Getting it running in linux is the easiest part dev wise.

It is the rest of the iceberg that causes problems.

- You need your support to be able to support linux which means they will need training and experience helping people in an entirely new system

- Linux comes in finite but vastly more combinations than OSX and Windows which means you are probably going to need to pick something like Ubuntu or struggle with the above

- Gotta track bugs in twice as many places

- Need CI / CD for more platforms

etc

And then people wonder, why electron became a thing.

But most of those issues are because Linux doesn't have enough market share. No one brushes off Windows because they need to support Windows and they need to add CI/CD for Windows.

The combination issue is a real issue though that (as far as I know) is mostly solved with Flatpaks, or in case of games, by using the Steam Runtime.

Of course, it is a "chicken and egg" problem of "we don't want to support Linux because there aren't enough users using it" but "we don't want to use Linux because there aren't enough business supporting it".

Thankfully with improvements in Wine the need of having "native" Linux support is shrinking, but at the same time there is still a looooong way to go (like the issues I said before with Affinity).

Windows userland compatibility is outstanding. I can run most 30 year old Windows applications on Windows 11 without a problem. This makes it easy for a commercial vendor to support their applications on Windows.

The same is not at all true on Linux.

Right now at work, I’ve got a bunch of commercial apps built for RHEL9 for which I’m chasing vendors for new builds that work on RHEL10, for a variety of reasons. Dependencies like libXScrnSaver have simply been removed, and so apps linked against that library no longer work.

Funnily enough there are old Windows applications that do work on Wine, but doesn't work on Windows 11

>- Linux comes in finite but vastly more combinations than OSX and Windows which means you are probably going to need to pick something like Ubuntu or struggle with the above

This is easily solvable by distributing the app via a distro agnostic mechanism, like as a Flatpak or AppImage. Using Flatpak also eliminates the need for rolling their own app update mechanism.

AppImage relies on the old, unmaintained and suid root fuse2. Not a wise choice in 2025.

Wine has some gaping holes in some of its API implementations. Direct2D, for instance, has existed since Windows 7 but is badly implemented in Wine -- there is no antialiasing and the ArcTo() function draws a line. The MS documentation is not that great either, so fixing Wine isn't necessarily easier than porting to native.

This. OMG Affinity is the ONE piece of software I actively miss. I tried the wine setup for it and it just doesn't work to a usable extent.

Yeah, I thought that Affinity would work pretty well in Wine because I've seen a lot of people pointing to the "just follow the guide (AffinityOnLinux repo) and it will work!" but in my experience it didn't work that well as people were saying.

And the guide itself seems to be outdated, the guide says that you need to install some stubs/shims but doesn't say that happens if you don't do it (I think that it would crash) but at least in my experience it did "work" without them when using an up-to-date Wine version.

Sadly Photoshop also doesn't work, if you want to follow the rules and use Creative Cloud it won't work at all, if you decide to sail the seven seas and download an older Photoshop version it will work but it also has some annoying bugs (sometimes the canvas doesn't update after an edit until you try to do another edit).

Don't get me wrong I do think that Wine is an amazing project and I hope that it continues to improve, but sometimes people don't seem to actually point all the issues that it exist when running an application in Wine.

I've had cases where running an app under wine worked better than the native linux port :/

Don’t they use Qt for their Win/macOS version already?

Reply on news.ycombinator.com