Affinity for Linux

[Bog]

5 hours ago, Snapseed said:

Two words, "Market Share".

Among developers, Linux has about a 30%+ market share so it makes commercial sense for companies like JetBrains (creators of development tools and software) to make their products available for the Linux platform.

 

 

Yea as I said a few weeks a go- if a designer sends me an illustrator file (or pretty much anything else besides image files), what do I do?  I'm left with terrible options, nothing of the "native" set is any good.  And it's not just reading the file, I can't edit it as well to send it back. And that's a 30% market share).  That's why using "3%" is a terribly unfair number. 

[Bachu]

Though stats say one thing, there are people such as me, than can't move from OS because we don't have the apps we need.

I've been using OSX for the last 12 years. First with a mac, and 6 years ago I added a hackintosh. Why? Price
Why do I keep using OSX > I'm used to it, it's shortcuts, functions, etc., but I dislike new versions and it has been a tendency through out the latest versions.

I would love to switch and start using Ubuntu as my daily OS, but I can't. Im a web developer and graphic designer. I use Adobe illustrator almost every day. 
Adobe isn't aiming to work for Linux, and I'm searching for options. If Affinity suite was available with Linux, I would have changed inmediately to it... 

During 18 years working in design, I never meet anyone using Affinity. Adobe or Corel are the common options. 

I think decisions are made according to the stats you see, but are not keeping in mind that they could become THE OPTION in linux.

[Snapseed]

20 hours ago, Requester said:

But on the other hand, the percentage of the linux users interested in professional software like Affinity products, is for sure much higher than of the windows users, as most windows users use their pc to write a letter and surf the internet.

Much more linux users by percentage of all linux users are on a more professional level on using computers and have a need for more software in all directions.

Even more mac users by percentage of all mac users are especially (originally) more on a design level and working with photo editing, design and so on.

But as @Michael Tunnell told already, the facts we can only get by doing focused research and actions on this topic. So i don't like to talk about what could be ... but to talk about, what we can do right now.

What we could all do right now as an easy practical measure is act with our other Linux friends to get Affinity Photo moved up to at least 6th place in the Wine voting statistics to show that there is still an ongoing wish and momentum for Affinity Photo to work well with Wine/Crossover ===> https://appdb.winehq.org/votestats.php

 

17 hours ago, Bog said:

Yea as I said a few weeks a go- if a designer sends me an illustrator file (or pretty much anything else besides image files), what do I do?  I'm left with terrible options, nothing of the "native" set is any good.  And it's not just reading the file, I can't edit it as well to send it back. And that's a 30% market share).  That's why using "3%" is a terribly unfair number. 

In which case, you might try Inkscape or Gravit and they don't work well then try the non-subscription versions of Illustrator that work with Wine including the venerable CS2 version.

Even if a third of all known Linux users really want the use of all Serif Europe products then a third of Linux's current 3% market share is 1% and Serif Europe aren't going to even get out of bed for a tiny market share like that. At the present time, the most practical and realistic hope is to first get the Serif Europe products working well with Wine/Crossover.

[ekalb52]

I get the whole market share thing...but isn't Mac OS 10+ really Linux? It seems like making Affinity work on Linux wouldn't require starting over from scratch...I may be displaying naivete here.

On the demand side, between Adobe and Apple there are a lot of unhappy users out there. Apple's last 2 updates killed all my 32 bit programs and Big Sur is causing nightmares for a number of reasons (Like not working on iMacs that are totally happy running Catalina). Linux looks better to me every day except that I need my Affinity products!

[Snapseed]

37 minutes ago, ekalb52 said:

I get the whole market share thing...but isn't Mac OS 10+ really Linux? It seems like making Affinity work on Linux wouldn't require starting over from scratch...I may be displaying naivete here.

On the demand side, between Adobe and Apple there are a lot of unhappy users out there. Apple's last 2 updates killed all my 32 bit programs and Big Sur is causing nightmares for a number of reasons (Like not working on iMacs that are totally happy running Catalina). Linux looks better to me every day except that I need my Affinity products!

I think the best way to think about it is that macOS and Linux are Unix-like cousins but are not identical twins. Not only does macOS have separate BSD origins, its kernel and graphics stack are completely different so what will work on macOS will not work on Linux and vice versa.

Therefore, if someone really needs to have Affinity products for their work then the only options are Windows or macOS or Linux but only using either of the two other operating systems in a virtual machine which takes up extra system resources.

 

 

[Redsandro]

3 hours ago, ekalb52 said:

isn't Mac OS 10+ really Linux?

No. Mac OS X is officially Unix, and GNU/Linux is not. (GNU's Not Unix). So while some basics share a common ancestor, the higher level stuff needed to make an app today is very different.

More importantly, I suppose OS X software uses the Metal API where the art board needs to be implemented in the Vulkan or OpenGL API on Linux.

As for the interface, I assume that it also uses a Mac OS specific toolkit. So pretty much everything needs to be re-implemented, except for the render core, which the Affinity team explained is platform independent already, and likely shared between the Windows and the Mac OS X version.

[Aphelon]

On 8/16/2014 at 9:29 PM, TonyB said:

We would only make a Linux version if we were confident we would recoup the $500,000 it would cost us to build it.

So why not even try a Kickstarter-Campaign? If you raise enough Money you'll keep it to make a Linux Version and if not you'll just pay the backers back. No Risk for you or the backers, no confidence needed. Lot's of people would probably even be willing to back a lot more than the List-Price of the Software just to see it happen. I don't think it's unlikely to get >1.000.000 out of the Linux Community for such a Suite.

 

[Aphelon]

On 3/19/2021 at 4:47 PM, Snapseed said:

Even if a third of all known Linux users really want the use of all Serif Europe products then a third of Linux's current 3% market share is 1%

But that's 1% of ALL People owning a Computer. Serif would probably be happy to have that many customers.

[MeatRadiator]

13 hours ago, Aphelon said:

So why not even try a Kickstarter-Campaign? If you raise enough Money you'll keep it to make a Linux Version and if not you'll just pay the backers back. No Risk for you or the backers, no confidence needed. Lot's of people would probably even be willing to back a lot more than the List-Price of the Software just to see it happen. I don't think it's unlikely to get >1.000.000 out of the Linux Community for such a Suite.

 

I agree Aphelon. Sadly Serif just don't wont a linux version!

[Snapseed]

On 4/4/2021 at 7:58 AM, MeatRadiator said:

I agree Aphelon. Sadly Serif just don't wont a linux version!

 

On 4/3/2021 at 6:20 PM, Aphelon said:

But that's 1% of ALL People owning a Computer. Serif would probably be happy to have that many customers.

 

It's not that Serif Europe won't do a Linux version; the real issue is that it's just not economically viable to do so at the present time because of Linux's small, general market share on PCs and laptops for everyday use.

Personally, I would be very grateful if, for example, Affinity Photo could work well on Crossover/Wine and that would be fine for me. That would be a far more cost efficient way of delivering Affinity products to Linux users and that is what we should be politely asking for.

[Mr. John]

Also would like to see Linux version of Designer.
Ewen if it will require additional license.

Moving from Windows to Kubuntu.

Linux user base and popularity grows.
There is a lot of games available, more and more software, even M$ Edge will come soon (vscode already there).
Who will be first will take all profit.

Other way and trend as well - web applications. For example Figma.
It uses web assembly (C++ code) directly in browser (which already supports GPU acceleration).

[Snapseed]

17 hours ago, George M. said:

Also would like to see Linux version of Designer.
Ewen if it will require additional license.

Moving from Windows to Kubuntu.

Linux user base and popularity grows.
There is a lot of games available, more and more software, even M$ Edge will come soon (vscode already there).
Who will be first will take all profit.

Other way and trend as well - web applications. For example Figma.
It uses web assembly (C++ code) directly in browser (which already supports GPU acceleration).

In the meantime, you might like to look at VivaDesigner, Canva and PageStream that are Linux-friendly.

[Redsandro]

50 minutes ago, LondonSquirrel said:

They never mention the 'shared object hell' on Linux. Wrong version of a library? Forget it, your software won't run.

Do people still make such an outdated argument and think they are contributing constructively to a discussion? AppImage has becoming increasingly popular in the last 15 years to solve this problem. Their portability became so popular that both Red Hat and Canonical made commercial versions 6 years ago. You get 33 officially supported distro's (and more unofficial) for the price of one.

[Requester]

9 minutes ago, LondonSquirrel said:

That is another problem in itself: far too many distributions of Linux. These distributions exist for people who have time to try out new distributions. You've tried the top 3 distributions, now try 30 more...

They are officially supported. So you do not need to try any of them. That's the whole point behind official support.

 

 

Guys, keep up voting and ask for votings at wineHQ!

https://appdb.winehq.org/objectManager.php?sClass=version&iId=39311

Are there any Wine related news?

[Renzatic]

57 minutes ago, LondonSquirrel said:

Even Linus Torvalds could not find a reliable way to distribute Linux software without a third-party kludge. I rest my case.

How are appimages 3rd party kludge? Linux addressed it's problem with conflicting libraries in much the same way the other OSes have with snaps and flatpaks, and appimages simply the process even more by making your apps a single, self contained executable you don't even need to install.

[Renzatic]

14 minutes ago, LondonSquirrel said:

If you have 5 programs which depend on xyz version of the C++ runtime, you only need to install that runtime once.

That's true of Linux as well, provided you have that library installed.

The biggest strength and greatest weakness of Linux is that it's wide open. You have all these different distributions with different standards and upgrade schedules. Ubuntu, which updates every 6 months, may not have the latest version of Library X installed, while Arch, with it's rolling release schedule, gets it as soon as it's available. While it doesn't happen nearly so often as it once did, there are occasions when you run into a program that's been compiled against the latest version of Library X, which your distro may not have installed as standard yet.

It's fairly simple to get around, because all you have to do is run to your package manager, and update to the latest version (provided it's there, which it usually is from my experiences). Though it's still a pain in the butt, because it's a bit of extra unnecessary overhead you have to deal with. Flatpaks and appimages take away that potential pain in the butt, because they include all the libraries along with the binaries.

What you're arguing is basically a Linux purist standpoint, that all libraries SHOULD be handled exclusively by the OS. In the end, the only thing you're losing out on is having to deal with slightly larger app install footprints, so it's mostly an academic argument.  

[Redsandro]

1 hour ago, LondonSquirrel said:

Even Linus Torvalds could not find a reliable way to distribute Linux software without a third-party kludge. I rest my case.

It is an open source component. The entirety of Linux consists of open source components made by multiple parties. By calling it a third-party kludge, you indulge yourself to a mind trick that can be utilized to criticize every single Linux component.

Let's Torvalds directly: I finally got around to play with the "AppImage" version of +Subsurface, and it really does seem to 'just work'.

An AppImage is a self-mounting filesystem image conceptually like a macOS .dmg file. So if it's good enough for OSX, you're just really bending backwards to criticize a good solution to an ancient problem.

Hohndel: [Mac got] this right. I control the libraries my app runs against. [...] With an AppImage I can give them just that. Something that runs on their computer.

[m.vlad]

32 minutes ago, LondonSquirrel said:

The shared library problem is one that should be addressed in the operating system, as that is where most shared libraries are installed. AppImages are not part of the OS itself. Indeed, they deliberately do not touch the underlying OS. They work around problems in Linux.

Not so. For example in Windows, there are the various versions of the C++ runtimes which can be installed. These are entirely separate from any application which depends on them. If you have 5 programs which depend on xyz version of the C++ runtime, you only need to install that runtime once. Contrast that with AppImage, where you will have 5 copies of the same runtime. AppImage gets around the shared library hell by including 'standard' libraries with each AppImage. It's horrible and a kludge. It is one way of 'solving' a problem which is inherent in Linux.

but then you have bloat in your system, libraries that are only needed for a few applications that might not be needed anymore but are packaged in because of reasons. Otherwise you already have dependency installations with most distros, where installing via the package manager will install the dependent libraries with a "dependency" tag that is then uninstalled together with the app when that is not needed anymore. Sure AppImage isn't the best, but it's one of many solutions and while it won't work for everything, it will work for a few small apps. To me this just sounds like moving the goalpost. "we can't port this app because there's too many distros" "look, this is a way to port the app to many distros without testing for each one" "we can't port this app because the solution you provided would include redundant code". the point isn't to give the perfect solution, the point is to have a solution to start from, together with snap packages and the other solutions.

Piggybacking on what Redsandro said, if appimages are third party kludges, what is first party when it comes to linux? Where do you draw the line of first party and third party when it comes to an open source environment where everyone can contribute and fork and push changes and fixes and features?

[Renzatic]

4 minutes ago, LondonSquirrel said:

That is what operating systems do, in very large part. 

Yeah, but you do run into similar situations even on Windows, when you find yourself having to update to a later version of, say, .net. The only difference there is that Windows does a better job of making that upgrade process automagical, while Linux just tells you that you need a later version of the library, and leaves you to find out how to do it.

Like I said, it's mostly an academic argument, because at the end of the day, it isn't any more difficult for developers to implement, and doing so doesn't make the app any slower or less efficient. Literally the only difference is that your raw tar.gz version which only includes the binaries is 120 meg, while the appimage is 135 meg.

[m.vlad]

Just now, LondonSquirrel said:

Turning that on its head, it means that trying to get software to run on Linux "just doesn't work". That's a bit unkind, it's just difficult due to all the different versions.

No it is not.

I'm confused how you can stare right in the face of a solution to the "Different versions" argument and then claim there is no such solution.

also, yes it is.

Quote

AppImage does not install the application in the traditional Linux sense. Instead of putting the application's various files in the distro's appropriate places in the file system, the AppImage file is just the application's compressed image. When it runs, the file is mounted with FUSE. This behavior is consistent with AppImage's predecessors, klik and PortableLinuxApps.

 

[Redsandro]

42 minutes ago, LondonSquirrel said:

For example in Windows, there are the various versions of the C++ runtimes which can be installed. These are entirely separate from any application which depends on them.

For everyone else that's reading: Don't get rattled by this FUD.

Flatpak, the next generation of AppImage, works the same as described above. You can install multiple versions of the same components in Flatpak, and every other Flatpak can load them when needed.

AppImage just works everywhere. Flatpak is the same but allows separating often shared libraries. The latter is only beneficial if you are frugal about storage space. The former is beneficial if you don't care and want it to just work no matter what. Packaging one or the other is as simple as adding a line to your build script. For that reason, many software (e.g. the Non-Linear video Editor KdenLive) publish both, so people can choose.

[Renzatic]

2 minutes ago, LondonSquirrel said:

Turning that on its head, it means that trying to get software to run on Linux "just doesn't work". That's a bit unkind, it's just difficult due to all the different versions.

Like I said, it's a rare problem these days. Something you only clash against occasionally. In the 3ish months it's been since I slapped Pop OS on my machine, I've only seen it happen once, and that was from someone playing around with their own homemade complied version of an application, and wasn't too familiar with Linux norms.

[m.vlad]

Just now, LondonSquirrel said:

It isn't. Let's say you have five apps depending on a library. If that library has a trivial vulnerability, the library maintainer can update it. With AppImage you now have five more developers running around like blue-arsed flies patching their version of the library. Congratulations: what was one patch update has now become six.

app images are compiled versions of apps, if you update the library on the base app you can compile app images off of that, where in the app image description does it say that you're not forking the entire app and libraries and you have to patch your own things to follow the base fork? That is absurd, and I don't see how windows does this any better?

[German_Printer]

Don't hope that a Linux version will probably not come out

[Redsandro]

1 minute ago, LondonSquirrel said:

The final refuge of the Linux defender, warts and all, is the reference to FUD.

Or it's just the definition of what you're doing right now: spreading negativity while showing clear lack of understanding and ignoring the relevant parts of people who are trying to educate you towards more objective and uptodate ideas, even though your demeanor is straying.