Search the Community

Good point, 10 years ago. A lot has changed in the Linux world since then. In terms of porting to Linux the underpinning of Macs are very linux like and WINE and STEAM let graphic heavy games made for PC run well on Linux. So unlike ten years ago, Linux is easy to install (Mint for one) and easy to use and already runs a lot of PC software under WINE and STEAM. So from a cost POV the question is not totally re-coding Affinity programs but to identify the hang points. Then some code changes and/or working with Codeweavers to add support into WINE. Will it happen? I hope so but am not holding my breath.

I have just read the links above you supplied. I can't see any commercial SW company distributing using flatpak. It raises a LOT of security issues and requires a lot of work to maintain. The security issues are not one a SW company would want to take responsibility for. In addition, I can't see Flatpak covering all Linux distributions. In which case, you are better off selecting a mainstream Linux and only supporting that. However, for a fraction of the 4% of the desktop market, it is not worth it. As you can see in many walks of life, a small, but vocal, group of evangelists tend to drown out the 90% majority who are quietly getting on with it. It is the same with Linux. A small number making a lot of noise.

I would be keen to see Serif put out a survey to determine who would buy a linux version. Affinity is the last bastion that keeps me locked into either Mac or Windows, everything else I use runs in Linux. And I love Affinity so much that I would buy it again on Linux. The work Wanesty and others have done is so incredible — I'm so grateful — but a native port of the software would be something I would pay for in a flash. I understand it's likely not commercially viable (but maybe it is, there is likely no data to make a determination at the moment).

Fair point. macOS is indeed a UNIX platform under the hood, and a certified one at that, but the graphical user environment it presents is sufficiently different from that presented by other UNIX platforms that for users who would be using it in the capacities described here, it would not be as natural of a jump as Linux would be. I would argue that it would be an improvement, but many apps are written against the X11 environment and would be harder to port and have come across in a way that makes them as straightforward to work with, etc. Most traditional UNIX workstation environments had graphical interfaces based around some flavor of MOTIF, which is also available on Linux. Newer ones are actually using GNOME or environments derived from GNOME, which went the other way (was popular on Linux first). This includes, for example, OpenIndiana, which is built on an updated version of the OpenSolaris kernel from back when the bulk of it was released as open-source. Not certified, but real UNIX nevertheless. Solaris had transitioned to GNOME as its desktop environment prior to that as well. How so? Personally I find it to be about the same in most respects. Each UNIX platform is different from the others, and Linux is different in largely the same ways.

This isn't even remotely true. The biggest advocate for NOT using Linux as a desktop OS is Linus Torvald. There are multiple videos of him at conferences saying this and explaining why. If Serif did do a Linux version of their tools, it would more than likely be on the same distro of Linux that BMD use for Resolve. As BMD say, use this exact version or you ar eon your own. BTW just because Affinity software runs on UNIX doesn't mean it could run on Linux.

For Windows, Mac and Linux https://www.qoppa.com/pdfstudio/

If you have a universal license, yes. This can be used on all supported operating system platforms (Windows, MacOS and iOS) and on as many devices as you manage yourself privately. With a single license, use is limited to the operating system platform and program for which the single license was purchased. Note: Devices with Linux/Android are not supported!

Linux is a kernel. this is not an issue anymore, you can either chose a single distribution to support like Davinci Resolve did with openSUSE, OR even better, you could use Flatpak (Flathub) like most developers are currently moving towards as a mean of distribution (it can bundle dependencies easily instead of relying on distro packaged ones). The codecs Affinity uses are available freely(i.e.ie libre) on linux. And i believe Serif is already paying for distributing Pantone colors. (please do tell me if i'm missing a codec that wouldn't be on linux.) Linux's userbase is small yes but again, growing, and non/small pro users are the ones asking for it because : companies that are already using linux will see and that serif, adobe, etc are distributing a linux version and they know that it's useless to waste company time trying to convincing them to port it. But as Sorn pointed out that yes, there is professional interested in a linux port.

Having spent 40 years in critical embedded systems, I know about the use of Linux in embedded systems and why its use is banned in critical systems., (see D0178, IEC 61508 etc the latter being one I worked on) Wikipedia is not a useable source for this sort of information. Actually Windows has improved a lot as it effectively moved to a VAX architecture. There is a very good presentation on this, though I am not sure if it is public. MS also, a bit late it is true actually got their act together on standards. According to Linus Torvld Linux is not a good choice for general desktop computing. As for MAC Vs Windows a lot of MAC users in the Video space, myself included have moved from MAC to Windows. Linux is a very distant third, as I said for the desktop Windows/Mac make up 98% Only the Linux Religious Devotees think otherwise.

I see you don't understand the market. BMD did a Linux version when they had about 100 clients all spending over $250K per set up for video edit studios. These were systems separate to their normal business IT set up that was on Mac and PC. Companies don't use Linux on the desktop in a business environment, or at least VERY few do. Graphics related companies use MAC primarily, though PC is now growing that market. This has been discussed in the professional graphics and video forums. As I said the Linux desktop market is less than 2% of the overall market. Most small companies won't touch Linux.

Ok, we hear you, but I don’t agree here. An example: If Serif Labs put a lot of resources and money to develop Affinity Suite for Linux, should everyone in the world who’s runs Linux get this for free also (if they earlier bought an licence for Mac or Windows)? Your argument isn’t plausible for a company like Serif Labs that pays the staff’s salaries from licence income…

That is the truth of the matter. As we keep saying for the desk/laptop 96% of the market is MAC/Windows. The remaining 4% is heavily fragmented and Flatpak is not the answer. Added to which the number of that 4% that might actually want and pay for Affinity tools is vanishingly small compared to the costs. Linux has been "about to take off" on the desk/laptop market for about 30 years and hasn't. It has in fact gone backwards from the high point 25(?) years ago.

I did a bit more digging. Resolve was first done for a BSD based UNIX. Not LINUX. The two are very different, even if some Linux are largely POISIX compliant. Later there was a custom Linux version that only worked on the computer supplied with the Hardware desks supplied and the Dongle. There were less than 100 Resolve users, and they were paying over $100,000 a seat. Then BMD got hold of it and in 2010 The first SW only version was for Mac OSX at $995, the Linux-HW version at $20,000 to $150,000 In 2010 there was Version 8 for both Mac OSX and Windows (without hardware). This is when the user base exploded from 100 users to over 2, million users over the next few years. It was not until 2017 that Resolve was made available for a standard Linux without HW So Resolve was developed for UNIX. As UNIX is POSIX compliant, they were able to do a custom OS based on Linux for <100 users. After a MaC OSX, also BSD based POSIX compliant UNIX, and Windows versions were released, the user base went to 2 million.

Wine doesn't use windows drivers. But OpenCL isn't going to be a direct mapping to windows drivers. Its a library that translates function calls to being called on your gpu. Linux has native OpenCL drivers, so in theory wine will take the windows OpenCL library calls, and call the linux native OpenCL library. Which will then utilize your gpu. Problems here could include: 1. Do you have the linux native opencl packages installed for your gpu. 2. How full is wine's implementation of opencl calls to native opencl libraries. 3. Is your wine version compiled with opencl support 4. Is linux opencl native supporting your graphics card? Does it support it well? 5. Does wine call opencl functionality that isn't supported by your card.

I will second this. I have purchased this software twice already. But know I'm 100% Linux. I will purchase a third time when it supports linux.

but... but... the Linux market has DOUBLED to "nearly" 4%!!!! The problem is how many of that 4% will want a Photo program, a desktop publishing program? Of that subgroup of the massive 4% how many would pay for affinity rather than follow their religion and use only Open Source/Free software? I suspect we are back under 2% of the market. As the Video above says the Linux market is too small. The distros far too fragmented to be worth the effort by a VERY long way.

The problem here is that Tanenbaum's primary argument is against a monolithic kernel design, an argument which applies equally to UNIX, as many UNIX systems are even more monolithic than the Linux kernel, which at least supports a form of modularity with its kernel modules. A possible exception is macOS, which does use something closer to a microkernel, though not a true one. The remainder seems to be more historic in nature, as it relates to things which have long since not been true. Point being, by your apparent interpretation of Tanenbaum's arguments, UNIX in general is even worse than modern Linux, with the catch being that most of the "debate" was related to things that are no longer true or are no longer relevant, as both Linux and the hardware landscape have changed significantly since that time.

Hello, I have a question about affinity, Why don't you build affinity app for website (like figma) or linux users?

I tried to run kron4ek-wine-9.0-rc3-amd64, but it fails to launch: What should I try? Unhandled exception: 0xe0434352 in wow64 32-bit code (0x7a9519f7). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7a9519f7 ESP:0062ea5c EBP:0062eab0 EFLAGS:00000246( - -- I Z- -P- ) EAX:0062ea5c EBX:00000000 ECX:00000010 EDX:0062eb18 ESI:0062eb18 EDI:00000001 Stack dump: 0x0062ea5c: e0434352 00000001 00000000 7a9519f7 0x0062ea6c: 00000005 80004003 00000000 00000000 0x0062ea7c: 00000000 77ee0000 0062eb6c 00000001 0x0062ea8c: 00000001 00000001 00000012 03620001 0x0062ea9c: 0062ea58 00000007 0062ea78 00b45d50 0x0062eaac: 00000005 0062eb4c 780970f1 e0434352 Backtrace: =>0 0x7a9519f7 in kernelbase (+0x119f7) (0x0062eab0) 1 0x780970f1 in clr (+0x1b70f1) (0x0062eb4c) 2 0x78097f96 in clr (+0x1b7f96) (0x0062ec14) 3 0x10a2ed35 in presentationcore.ni (+0xa2ed35) (0x0062ec28) 4 0x07190733 (0x0062eca8) 5 0x0529c5f7 (0x0062ece4) 6 0x052936ae (0x0062eecc) 7 0x568ddd86 in presentationframework.ni (+0x2cdd86) (0x0062eedc) 8 0x585bee42 in windowsbase.ni (+0xdee42) (0x0062eef4) 9 0x585bed85 in windowsbase.ni (+0xded85) (0x0062ef30) 10 0x585c10cd in windowsbase.ni (+0xe10cd) (0x0062ef78) 11 0x585bf56f in windowsbase.ni (+0xdf56f) (0x0062efe4) 12 0x03a13527 in mscorlib.ni (+0x3f3527) (0x0062eff8) 13 0x03a134e4 in mscorlib.ni (+0x3f34e4) (0x0062f014) 14 0x585c0f83 in windowsbase.ni (+0xe0f83) (0x0062f044) 15 0x585c0d80 in windowsbase.ni (+0xe0d80) (0x0062f07c) 16 0x585bd346 in windowsbase.ni (+0xdd346) (0x0062f0bc) 17 0x585bc57c in windowsbase.ni (+0xdc57c) (0x0062f0f8) 18 0x585be661 in windowsbase.ni (+0xde661) (0x0062f134) 19 0x585be94c in windowsbase.ni (+0xde94c) (0x0062f154) 20 0x585bee42 in windowsbase.ni (+0xdee42) (0x0062f16c) 21 0x585bed85 in windowsbase.ni (+0xded85) (0x0062f1a8) 22 0x585bcf62 in windowsbase.ni (+0xdcf62) (0x0062f200) 23 0x585be4b4 in windowsbase.ni (+0xde4b4) (0x0062f248) 24 0x00f1d08e (0x0062f27c) 25 0x7a1a270c in user32 (+0x6270c) (0x0062f2ac) 26 0x7a1a2b89 in user32 (+0x62b89) (0x0062f2ec) 27 0x7a1a4f31 in user32 (+0x64f31) (0x0062f328) 28 0x7a188b13 in user32 (+0x48b13) (0x0062f384) 29 0x7a18b12b in user32 (+0x4b12b) (0x0062f3f8) 30 0x585d7211 in windowsbase.ni (+0xf7211) (0x0062f434) 31 0x585bb3d7 in windowsbase.ni (+0xdb3d7) (0x0062f47c) 32 0x585bb319 in windowsbase.ni (+0xdb319) (0x0062f488) 33 0x568ddd50 in presentationframework.ni (+0x2cdd50) (0x0062f498) 34 0x568dd90e in presentationframework.ni (+0x2cd90e) (0x0062f4b8) 35 0x568dd702 in presentationframework.ni (+0x2cd702) (0x0062f4c8) 36 0x568dc7d6 in presentationframework.ni (+0x2cc7d6) (0x0062f4d4) 37 0x0529089d (0x0062f4e8) 38 0x77eef016 in clr (+0xf016) (0x0062f4f4) 39 0x77ef22ba in clr (+0x122ba) (0x0062f548) 40 0x77ef850b in clr (+0x1850b) (0x0062f5b8) 41 0x78091d0b in clr (+0x1b1d0b) (0x0062f6dc) 42 0x780923ea in clr (+0x1b23ea) (0x0062f948) 43 0x78092317 in clr (+0x1b2317) (0x0062fe2c) 44 0x78092498 in clr (+0x1b2498) (0x0062fe84) 45 0x780925be in clr (+0x1b25be) (0x0062fec4) 46 0x7808def5 in clr (+0x1adef5) (0x0062ff00) 47 0x786afa84 in mscoreei (+0xfa84) (0x0062ff38) 48 0x78747f16 in mscoree (+0x7f16) (0x0062ff48) 49 0x78744de3 in mscoree (+0x4de3) (0x0062ff68) 50 0x7acca813 in ntdll (+0x5a813) (0x0062ff80) 51 0x7accbc82 in ntdll (+0x5bc82) (0x0062ffec) 0x7a9519f7 kernelbase+0x119f7: mov -0x04(%ebp), %ebx Modules: Module Address Debug info Name (139 modules) PE 400000- 524000 Deferred setupui PE 3620000- 4a1c000 Export mscorlib.ni PE 52a0000- 5cf2000 Deferred system.ni PE 5d40000- 64b4000 Deferred system.xml.ni PE 64d0000- 64d8000 Deferred setupui.resources PE 6550000- 6582000 Deferred presentationframework.classic PE 10000000-10c3d000 Export presentationcore.ni PE 56610000-579f3000 Export presentationframework.ni PE 580d0000-582d3000 Deferred system.xaml.ni PE 584e0000-588fb000 Export windowsbase.ni PE 60370000-60475000 Deferred system.configuration.ni PE 61a00000-62218000 Deferred system.core.ni PE 63c00000-63d30000 Deferred system.management.ni ELF 71400000-73fe8000 Deferred libnvidia-glvkspirv.so.535.129.03 ELF 74000000-770dc000 Deferred libnvidia-glcore.so.535.129.03 PE 770e0000-771e5000 Deferred diasymreader PE 77200000-77521000 Deferred d3d9 PE-Wine 77540000-7754d000 Deferred dwmapi PE 77560000-77581000 Deferred wminet_utils PE-Wine 775a0000-7761b000 Deferred setupapi PE-Wine 77630000-77663000 Deferred winevulkan PE-Wine 77680000-7768d000 Deferred vulkan-1 PE 776a0000-778cd000 Deferred dxgi PE-Wine 778e0000-7791e000 Deferred wbemprox PE-Wine 77930000-77940000 Deferred wmiutils PE 77950000-779d9000 Deferred clrjit PE 779f0000-77ad3000 Deferred presentationnative_v0400 PE 77af0000-77b5b000 Deferred msvcp140_clr0400 PE 77b70000-77cfd000 Deferred wpfgfx_v0400 PE-Wine 77d10000-77d90000 Deferred dwrite PE-Wine 77da0000-77dd6000 Deferred rsaenh PE 77df0000-77e9b000 Deferred ucrtbase_clr0400 PE 77eb0000-77ec4000 Deferred vcruntime140_clr0400 PE 77ee0000-7868f000 Export clr PE 786a0000-7872d000 Export mscoreei PE 78740000-7878a000 Export mscoree PE-Wine 787a0000-787ac000 Deferred nsi PE-Wine 787c0000-787d5000 Deferred dnsapi PE-Wine 787f0000-78815000 Deferred iphlpapi PE-Wine 78830000-7886a000 Deferred uxtheme PE-Wine 78880000-78896000 Deferred winex11 PE-Wine 78d50000-78d65000 Deferred compstui PE-Wine 78d80000-78db6000 Deferred winspool PE-Wine 78ef0000-78f1a000 Deferred wintrust PE-Wine 78f30000-78f3d000 Deferred version PE-Wine 78f50000-78f78000 Deferred ws2_32 PE-Wine 78f90000-78fb0000 Deferred mpr PE-Wine 78fc0000-79048000 Deferred wininet PE-Wine 79060000-790f8000 Deferred urlmon PE-Wine 79110000-7911f000 Deferred sxs PE-Wine 79130000-79147000 Deferred shcore PE-Wine 79160000-791ae000 Deferred shlwapi PE-Wine 791c0000-79b02000 Deferred shell32 PE-Wine 79b20000-79c2d000 Deferred oleaut32 PE-Wine 79c40000-79c54000 Deferred coml2 PE-Wine 79c70000-79cf9000 Deferred rpcrt4 PE-Wine 79d10000-79d5f000 Deferred combase PE-Wine 79d70000-79e84000 Deferred ole32 PE-Wine 79ea0000-79eb4000 Deferred odbccp32 PE-Wine 79ed0000-79edf000 Deferred mspatcha PE-Wine 79ef0000-79f6c000 Deferred dbghelp PE-Wine 79f80000-79f90000 Deferred imagehlp PE-Wine 79fa0000-79fb6000 Deferred bcrypt PE-Wine 79fd0000-7a0a7000 Deferred crypt32 PE-Wine 7a0c0000-7a0dc000 Deferred imm32 PE-Wine 7a0f0000-7a121000 Deferred win32u PE-Wine 7a140000-7a301000 Export user32 PE-Wine 7a320000-7a3a6000 Deferred gdi32 PE-Wine 7a3c0000-7a516000 Deferred comctl32 PE-Wine 7a530000-7a54f000 Deferred cabinet PE-Wine 7a560000-7a647000 Deferred ucrtbase PE-Wine 7a660000-7a689000 Deferred sechost PE-Wine 7a6a0000-7a756000 Deferred msvcrt PE-Wine 7a770000-7a7b2000 Deferred advapi32 PE-Wine 7a7d0000-7a928000 Deferred msi PE-Wine 7a940000-7abd8000 Export kernelbase PE-Wine 7abf0000-7ac56000 Deferred kernel32 PE-Wine 7ac70000-7ad24000 Export ntdll ELF 7ccd4000-7ce00000 Deferred libglx_nvidia.so.0 ELF 7ce00000-7d205000 Deferred libcrypto.so.3 ELF 7d23d000-7d2df000 Deferred libnvidia-glsi.so.535.129.03 ELF 7d2df000-7d36b000 Deferred libvulkan.so.1 ELF 7d36b000-7d400000 Deferred winevulkan.so ELF 7d450000-7d500000 Deferred libssl.so.3 ELF 7d62b000-7d644000 Deferred libdrm.so.2 ELF 7d65c000-7d700000 Deferred libcups.so.2 ELF 7d805000-7d824000 Deferred libxcb-glx.so.0 ELF 7d824000-7d8a1000 Deferred libgmp.so.10 ELF 7d8a1000-7da53000 Deferred libunistring.so.5 ELF 7da53000-7dc00000 Deferred libp11-kit.so.0 ELF 7dc00000-7de3a000 Deferred libgnutls.so.30 ELF 7de83000-7de95000 Deferred libresolv.so.2 ELF 7de95000-7dea5000 Deferred libffi.so.8 ELF 7dea5000-7def1000 Deferred libhogweed.so.6 ELF 7def1000-7df48000 Deferred libnettle.so.8 ELF 7df48000-7df5f000 Deferred libtasn1.so.6 ELF 7df5f000-7dfb7000 Deferred libidn2.so.0 ELF 7e222000-7e227000 Deferred librt.so.1 ELF 7e227000-7e22e000 Deferred libnvidia-tls.so.535.129.03 ELF 7e22e000-7e233000 Deferred winspool.so ELF 7e233000-7e239000 Deferred ws2_32.so ELF 7e239000-7e23e000 Deferred dwrite.so ELF 7e23e000-7e247000 Deferred libxfixes.so.3 ELF 7e247000-7e254000 Deferred libxcursor.so.1 ELF 7e254000-7e269000 Deferred libxi.so.6 ELF 7e269000-7e277000 Deferred libxrandr.so.2 ELF 7e277000-7e2a7000 Deferred libxcb.so.1 ELF 7e2a7000-7e400000 Deferred libx11.so.6 ELF 7e501000-7e506000 Deferred libxcomposite.so.1 ELF 7e506000-7e514000 Deferred libxrender.so.1 ELF 7e514000-7e51b000 Deferred libxxf86vm.so.1 ELF 7e51b000-7e520000 Deferred libxinerama.so.1 ELF 7e520000-7e526000 Deferred libxau.so.6 ELF 7e526000-7e53d000 Deferred libxext.so.6 ELF 7e53d000-7e541000 Deferred dnsapi.so ELF 7e541000-7e547000 Deferred crypt32.so ELF 7e547000-7e553000 Deferred bcrypt.so ELF 7e555000-7e5e0000 Deferred winex11.so ELF 7e7a2000-7e7ce000 Deferred libexpat.so.1 ELF 7e7ce000-7e823000 Deferred libfontconfig.so.1 ELF 7e823000-7e8c0000 Deferred libpcre2-8.so.0 ELF 7e8c0000-7e8e3000 Deferred libbrotlicommon.so.1 ELF 7e8e3000-7e907000 Deferred libgraphite2.so.3 ELF 7e907000-7ea77000 Deferred libglib-2.0.so.0 ELF 7ea77000-7eaa0000 Deferred libgcc_s.so.1 ELF 7eaa0000-7eaae000 Deferred libbrotlidec.so.1 ELF 7eaae000-7ebfc000 Deferred libharfbuzz.so.0 ELF 7ebfc000-7ec3e000 Deferred libpng16.so.16 ELF 7ec3e000-7ec51000 Deferred libbz2.so.1 ELF 7ec51000-7ec6b000 Deferred libz.so.1 ELF 7ec6b000-7ed2c000 Deferred libfreetype.so.6 ELF 7ed2c000-7ee05000 Deferred libm.so.6 ELF 7ee1d000-7efa8000 Deferred win32u.so ELF f7c00000-f7e32000 Deferred libc.so.6 ELF f7ebc000-f7f78000 Export ntdll.so ELF f7f7a000-f7f7f000 Deferred libdl.so.2 ELF f7f7f000-f7f84000 Deferred libpthread.so.0 ELF f7f9e000-f7fd3000 Deferred ld-linux.so.2 ELF f7fd3000-f7fd7000 Deferred <wine-loader> Threads: process tid prio name (all IDs are in hex) 00000020 start.exe 00000024 0 00000030 services.exe 00000034 0 00000038 0 wine_rpcrt4_server 00000048 0 wine_threadpool_worker 0000007c 0 wine_rpcrt4_io 00000094 0 wine_rpcrt4_io 000000a0 0 wine_rpcrt4_io 000000b8 0 wine_rpcrt4_io 000000dc 0 wine_rpcrt4_io 000000f8 0 wine_threadpool_timerqueue 000000fc 0 0000012c 0 wine_rpcrt4_io 00000074 svchost.exe 00000078 0 00000084 0 00000088 0 wine_sechost_service 0000008c winedevice.exe 00000090 0 00000098 0 0000009c 0 wine_sechost_service 000000a4 0 000000a8 0 000000ac 0 000000f0 0 000000f4 0 000000b0 winedevice.exe 000000b4 0 000000bc 0 000000c0 0 wine_sechost_service 000000c4 0 000000c8 0 000000cc 0 000000d8 0 000000ec 0 000000d0 plugplay.exe 000000d4 0 000000e0 0 000000e4 0 wine_sechost_service 000000e8 0 wine_rpcrt4_server 00000100 conhost.exe 00000104 0 00000108 affinity-photo-1.10.6.exe 0000010c 0 00000110 explorer.exe 00000114 0 00000118 0 0000011c 0 wine_rpcrt4_server 00000124 rpcss.exe 00000128 0 00000130 0 00000134 0 wine_sechost_service 00000138 0 wine_rpcrt4_server 0000013c 0 wine_rpcrt4_server 00000140 0 wine_rpcrt4_io 00000148 (D) C:\users\aronkvh\Temp\AffinitySetup\66ea09bf-b0d0-11ee-2389-c86000c5c9ab\SetupUI.exe 0000014c 0 <== 00000150 0 00000154 2 00000158 0 00000160 0 00000174 0 0000016c conhost.exe 00000170 0 System information: Wine build: wine-9.0-rc3 Platform: x86_64 (guest: i386) Version: Windows 10 Host system: Linux Host version: 6.5.0-14-generic

I will add +1 for the Linux version. (If Serif ever changes their mind) (Redhat/Rocky/Nix compatible - https://vfxplatform.com/). And I can add another 30+ from the perspective of the VFX studio. Even long-based Windows postproduction shops migrate to Linux now (due to the M$ roadmap to turn Windows 11/12/13… into useless web/mobile ChromeOS-like adware). And Apple hardware doesn't provide the scale/compatibility for high-end VFX at a competitive cost. But I understand that VFX is probably a tiny segment of Serif's customers; thus, the Linux version might not pay off, especially if it was never designed for that platform.

As shown on that page, the full set of figures is: Windows: 72.99% OS X: 16.13% Unknown: 5.33% Linux: 3.77% Chrome OS: 1.76% FreeBSD: 0.01%

the numbers are from wikipedia CromeOS 1.76 % Linux 3.77 % they may not really exact while from 2019 but windows is 2023 worldwide still at ca 70 % and in the US ca 57 %, macOS are ca 29.62 % in the US

Hello..!! is affinity designer available for linux/void linux, i really hope it is available

This is why I said "essentially" because it's not "exactly" the same. But it is *essentially* the same. If you look a Mac app packages, often they DO contain libraries within them that may or may not already be installed on the OS. And similarly with Windows exe, if it's a standalone exe then yes it relies on the libraries it needs already being installed on the system or will require the user to install them if they're not already. But if it's an installer, often it includes those libraries that it needs, or at the very least automatically downloads and rolls their installations in with it's own. Or if it's a "portable" app, then it definitely includes any library that it needs, as well as keeping all it's settings and the user's preferences contained within it's own folder that can then be taken to any other computer and used with all the same settings applied. Which is what Flatpak and Appimage aims to alleviate, and to an extent Snaps as well. The particular dependencies that a program requires are included with the program, they are "fixed" at whatever version they need to be for the program to function as it was intended. When that program gets updated, if it needs a newer version of those dependencies, it will include those new dependencies with it's update. It doesn't matter if the dependencies are or are not installed on the OS directly, and even if they are installed it doesn't matter if they get updated/changed/removed/altered in any way that may break programs that depend on them. This is why Flatpack, et al, can run on effectively any Linux distribution. You keep saying they can't run on all of them "by a long shot"... what distributions can Flatpaks not be used on? Are there many that don't include support by default? Sure. But that doesn't mean they cannot be used. That would be like saying "oh, well, Firefox isn't installed by default on Windows or Mac so I guess it can't be used on them." The user can enable Flatpak typically with one command on effectively every Linux distribution, and often there's a 2nd, optional command to add a plugin to their distribution's package manager GUI, so they can then be searched and installed directly from that instead of the command line. No more than they do for Windows or Mac versions of their software. If they develop using a newer version of a dependency, they just include that dependency in their release. If they continue using the same version of the dependency when they're developing new updates, then they just continue using the same dependency in their release. This is no different from using system APIs on Mac, DLLs on Windows, other dependencies like .NET or Visual Studio & Xcode versions. What "maintenance" are you talking about?

My understanding is that flatpak combines all the parts and dependencies into one package that can then be easily installed and run on most linux flavors. It does not however deal with making a windows or mac file run on Linux.