Search the Community

Actually because Linux is less than 4% of the market that is causing people who previously did Linux versions to stop. Asynchronously to this, a friend who uses Linux (also OSX and Windows) mentioned that one of the games he plays is no longer being supported on Linux. Apparently, when the Linux they primarily developed for broke the game: they said no more Linux. this is seems is not uncommon. As noted, there are many different Linuxes that are constantly and asynchronously changing. I know one Tool supplier that will add 10% as a line item to anyone using Linux for the additional support that it will require. Flatpak isn't a solution, though it may be in the future for some systems, The other problem is the Open Source and nature of Linux. Microsoft and Apple can sign legally binding NDAs with NVIDIA, ARM, Intel, AMD etc on roadmaps and advance information. They can also do deals for device drivers etc. There are differences between the Windows/Mac Resolve and the Linux version for this reason. There are Codecs and drivers that will never appear on a Linux system. That is the problem and why Linux will never hit mainstream.

to come back to ai Anyone in need of a good free Upscaler here is one: Try "UpScayl" (PC/MAC/Linux and Online) It works with AI, upscals 4 time and 8 times, ( 8 times, will "really" take some time ) and have different modes. Is pretty good in my opion Here the LInk: UpScayl

Dear friends, As you can see I'm a long time user of Serif products. When the Affinity line I jumped right in, and now I've upgraded to the universal license for V2. I'm very happy with the decision and actively engage in proselytism about the products. I mainly work in Linux, only booting into Windows when absolutely necessary. Stopping my work to boot into Windows is a nuisance, and Affinity is one of the few reasons. Linux for the desktop is very mature, and more often than not, much better and enjoyable than working in windows. Linux is steadily growing in number of users, and many segments are rising very rapidly, for example, gaming, which is turbocharging Llinux adoption. I have often read that Linux is still a minor player in the desktop space, but that may be misleading, and often due to a lack of serious software such as Affinity. Many people are in the same predicament as I am. We are both counted in the Windows and Linux statistics. Many of us have turned to Inkscape, Gimp and Scribus for our needs, but really need professional level tools, with a degree of polish that often commercial software provides. Part of the lower usage rate is due to the lack of this type of software, which leaves people like me having to dual boot to use your software. I believe that not having the option to natively install the software is keeping a higher number of user from adopting Affinity. Valve is a prime example of the success of the adoption of linux as a prime OS. There is also the fact that releasing for Linux would make Affinity the ONLY commercial player in the market, and could really give it an edge over Adobe, greatly enhancing the adoption of Affinity. I would like to request you consider the porting (does having a Mac version make it any easier?), especially now that Flatpak and Snaps exist, and removes the problem of distro fragmentation, or maybe in the mean time contribute and support the Wine effort? Thank you for offering such a great product, in the traditional non-subscription model, and providing such outstanding value, as always. Cheers, a long time user. Juan.

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

A bit of Linux news: the Wine 9 release seems to be right around the corner. This means some patches to improve Affinity compatibility might be coming to a stable release soon.

bump + just wanting to say I am adamant that I WILL purchase this software a third time when it gets Linux support (I say "when" because it has to). it is the only reason I spent the past week setting up a vm with gpu passthrough. I can handle every other open source alternative, but this one does not have an acceptable replacement yet. please and thanks @dev team

Hi all, thank you for your effort in trying to make these apps work on Linux. I've followed wanesty's guide on codeberg but get tripped up by this command: rum ElementalWarrior-8.14 $HOME/.wineAffinity wineboot --init I get this result (on EndeavourOS / Arch) Rumming /opt/wines/ElementalWarrior-8.14 (wine-7.9-8960-gc12ed146994) in: ~/.wineAffinity 002c:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (126). 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 007c:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 00d4:err:wineboot:process_run_key Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (126). [$ winewow64-build]$ 00f0:err:rpc:I_RpcReceive we got fault packet with status 0x1c010003 00e4:fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr" failed to start: 1053 00e4:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1115 00e4:fixme:service:scmdatabase_autostart_services Auto-start service L"winebus" failed to start: 1115 00e4:fixme:service:scmdatabase_autostart_services Auto-start service L"PlugPlay" failed to start: 1115 00e4:fixme:service:scmdatabase_autostart_services Auto-start service L"Eventlog" failed to start: 1115 00e4:fixme:service:scmdatabase_autostart_services Auto-start service L"nsiproxy" failed to start: 1115 00e4:fixme:service:scmdatabase_autostart_services Auto-start service L"NDIS" failed to start: 1115

You can also use afterwards tools like ExifTool in order to add some metadata to PDFs. ExifTool https://exiftool.org/index.html#related_mac jExifToolGUI (Win/Mac/Linux due to Java runtime) ExifToolGUI (Win only) ... etc.

Absolutely! And no, it is fairly standard. Google 7816, 61508 SIL4, Do178 DAL A, 50128/9, 60880. Apple and MS don't generally work at this level. Linux isn't even in the same country (let alone same field).

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?

That is how I read it. For Windows and Mac developers can sign up to a partner program and there are some fairly solid rules on the APIs and how they work. There is a also a roadmap developers can see about what is being added and what is being depreciated over the coming year or two. For Linux, it is still the wild west and anyone can do anything at any time. Also, anyone can (and they do) modify libraries and other things at any time. This can be a big problem for licensed software. The bigger problem is, as mentioned in the links posted above, is that the developer using flatpak has to do a lot of maintenance to keep flatpak up to date. Even then it lags behind the main updates on security and malware fixes. So flat pack far from being a solution looks like a lot of additional work for a developer for, in this case, a VERY small, if vocal, number of users. I can't see it being commercially viable.

I get that it is an executable file. I also read all the problems and pitfalls of Flatpak in the links posted above. Flatpak does not run on most Linux. Not by a long way. The links above show that for a companies like Affinity and BMD Flatpak is not the answer. Indeed BMD had to change Linux target a couple of years ago and went for a single Linux not flatpak. However, BMD have a small Linux user base that spend a huge amount of money with BMD. Usually in the order of 10's and 100's of thousands because BMD have a whole hardware infrastructure. The Linux market is still only 4% of the desktop market, and that 4% is heavily fragmented. In the real world it is simply isn't viable for Affinity to do a Linux version. There are far more lucrative things they could be doing. For example, a Lightroom competitor.

Your fundamental misunderstanding of what Flatpak is is not a Flatpak problem, it's a *you* problem. I don't know how anyone can make it any clearer and you still aren't comprehending. Flatpak is essentially the equivalent of a Windows exe file, or a Mac app package. A single application package, that runs on any Linux distribution. Or at least any that support Flatpak, but that's effectively all of them anyway, so that's a moot point.

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.

That is the problem with Linux. No two are the same. Re flat pack: AFAICS the user gets a "flatpak version" of the app and then compiles it with flatpak for their distribution. Is that correct?

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.

So what this does is the user compiles the app using flatpack, and it is automatically compiled to run on that user's Linux?

That would be interesting. The problem is, I have discovered over the last couple of days, Linux is being dropped as a target by some software producers rather than gaining ground. Mainly for the reasons Linus gave. The vast majority of Linux distributions are now obsolete and unsupported. There are some mainstream ones but even there the market is fractures in to multiple small markets that are changing asynchronously. Black magic effectively id their own Linux, but that was for systems costing £50,K upwards. (you could only use the Linux Resolve with the BMD edit hardware desks.) When they did a stand-alone Resolve that did not need their hardware to work, it was on Mac and Windows only. There was no Linux version until some years later. Because several major customers had the Linux version (with the edit desks so they were spending £/$ miilions with BMD) a stand alone Linux version came later and that was for one version of Linux only. Ie based on the original one they used. When this died, BMD swapped to one other target Distro. So if you want a Linux Resolve you use the one and only version of Linux they say. Of course, these are dedicated Video Edit computers. If you want a Linux Affinity, it is likely to be on one version of Linux and set up exactly as Serif say it should be set up. So you are likely to have to change the Linux you use and use the set-up serif, say just to use affinity.

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

Ok, I tried it again this morning, reset .wineAffinity, and started. After the --init I again made sure that Mono is not installed and removed it. For some reason, after I opted to install Mono once at a previous attempt, wine uninstaller always shows it after the init step. Not sure if this is relevant. Anyway, the installation of dotnet48 works now as well as Affinity 2 Publisher installation. I have no idea what I've changed to make it work. Unsure if that is good or not 😁 Thanks for any help, and especially to @Wanesty for the guide and effort. I just hope that Affinity will follow Valve's example with Proton and will enhance Wine to make Affinity installation a seamless experience for Linux users.

I didn't manage to get Wine to compile on Fedora with the steps in the guide. However, Daegalus - another forum member - has written a package that will compile Wine for you. You won't need to download the dependencies yourself; the package does it all automatically. These are the steps I followed: https://forum.affinity.serif.com/index.php?/topic/182758-affinity-suite-v204-on-linux-wine/&do=findComment&comment=1091579 Here's a link to the repo: https://github.com/daegalus/wine-builder

ImageMagick - another tool I hadn't heard of. I'm actually a UNIX and Linux engineer by trade so completely at home with command line tools. As for GraphicConverter, I prefer not to pay for Mac-only software as it's my least-used platform but great to know what exists. Many thanks for the suggestion!

You should be able to bulk convert them using the free ImageMagick utility. Alternatively, if you are on a Mac, GraphicConverter (can be found on the App Store or at https://www.lemkesoft.de/en/products/graphicconverter - about $40 for a new license) can do the same thing with a graphical interface (GraphicConverter has long been a "Swiss army knife" graphic file utility in the Mac world; ImageMagick is a command line utility which is cross-platform but which is probably best known in the UNIX/Linux world).

It's a sad deficiency in this forum (which probably stems from the forum software) that one cannot ignore an entire thread. That would probably be the most valuable feature the forum could be expanded with. It's endlessly exhausting when threads are expanded by the notorious giga-mega-posters here, with thousands of posts to their name, but amount to nothing more than bickering or endless assertions without anyone changing their mind or becoming wiser. It just results in a lot of valuable life being wasted. And, of course, when one has no stakes in Linux, those threads are also annoying to see popping up time and again. I still have yet to see someone here post something as delicious and attractive as click-bait; what I'm after is more relevance and noise-free content.

So a lot like managing a Linux distro, basically. Just more user-centric. Probably easier to update everything all at one time.