Suggestion :Developers please try to also create Appimages for linux

[firelord]

I know how much work you do and thank you.


My suggestion is to try -every now and then- to create an appimage of your emulator/program for linux. . It's an extra effort but I think it might worth it.

1. This will allow non advanced used with low knowledge in compiling to try and use your linux program in their OS flavour.
2. The main advantage of an appimage is that you have a single executionable file that contains everything needed and you don't have to install/update/modify a ton of files/libraries in your system.
3. The appimage can be copied to your next system (or other PCs) and will keep working (this might depend on what you have included in your appimage). No need to recompile each time.
4. An appimage will make your program live long after major distribution channels decide to drop support for your program.

I know how complex can Appimage creation get if you try to make it 100% portable. I'm not suggesting that much work.
Even a simpler Appimage could make people try your program. There are even tools that can convert a DEB file to Appimage.
I use Debian Dog and in the past puppy linux. These linux distributions are based in portable file containers (SFS/SQUASHFS*). Appimage is similar but the single file can also be executed.

For debate purpose I want to say that I prefer to download a single 2GB single file program and run it without messing with my system than download a 48k program that replaces/updates/modifies half of my system and do not know if I can uninstall it without leaving a trace.
Also, I know that it it better to have a program compiled for your system. Using Appimages is like having a Frankestein system... (but for me it works).

Spoiler

Even if it seems irrelevant this is what happened in android last week:
I have the android Chaos version which is very good. My tablet got a system upgrade . Chaos played ok until, by mistake, it was deleted. I tried to find Chaos in play store and it is not supported (yet) in the new android version. So, we have a game that worked 100% ok but the OS says that it is not compatible... In linux I have this kind of issues many times.
In linux (and even in windows) I have used many long lost & unsupported programs with techniqies similar to AppImage ideas.

Alternatives to AppImage are Snap and Flatpak but they are not single file and not portable.

*Squashfs/SFS files are like ZIP files. The difference is that they are merged (like a layer in a drawing program) in your file system. When you delete the file all it's files are removed.

[Timmy]

I also use Linux, and I have found I don't like building stuff. But that's mostly because I don't use a regular distribution and sometimes half of the things they require are just not available.

For example, I never managed to compile Zesareux (or whatever it was called) so I ended up with Fuse. Which is nice most of the times.

But if you want my opinion, the most compatible target in 2024 would be Win32. Just do that and I can use it with Wine.
I believe I can now use Spin and Basin this way too, so no worries. And with those 3 I have all my needs covered.

Appimages are probably too big for its intention, but it's a good alternative.

Also thanks in advance, but it's fine if you don't want to do it. Developing something alone is already a good job.

[firelord]

But if you want my opinion, the most compatible target in 2024 would be Win32. Just do that and I can use it with Wine.

I've followed this step in the past. This is correct and win32 apps might run better BUT they are much heavier. Basin is almost imposible to use in my lab PCs or in an old chromebook.
The problem here is speed/memory.

Appimages are probably too big for its intention, but it's a good alternative.

As i mentioned even an appimage that is a direct conversion from a deb file might be useful (I know if you have different glibs then it won't cover you)
For example I made very quickly these 2 appimages without any libs. Their only advantage is that if you have a chance to try these programs without messing with your system. A good appimage will require to include all the libraries needed in their correct versions but the increased file size will save you in the future from a lot of work.
https://app.prismdrive.com/drive/s/HF3s ... ivTXBM9Ku9 (note: I warn you AVOID buying prismdrive. It is CHEAP but it DELETES files every few months. I use it only for temporary file sharing)

Btw, I currently have many win32 appimages . They require Wine in your system (I mean your OS not your body ) but other than that they are portable. (example of wine32 appimages I've made are : Heroes of might and magic3 , Diablo1 , Rebirth/Rubberduck ) .

Spoiler

I use wine from an appimage -even that isn't installed .
At this time I'm experimenting on using conty.sh wine for win32 apps

[AndyC]

The problem with Linux is, and has always been, the myriad of different distributions all of which are almost the same but not quite. It makes the platform an enormous headache to support with rapidly diminishing returns for each different variants you try and cover.

When you're doing something like a Spectrum emulator, which is already a pretty niche use case it is literally not worth the effort involved. It makes much more sense to target Win32 and then just let those who exist on the fringe of the fringe deal with the pain of things like Wine.

[firelord]

The problem with Linux is, and has always been, the myriad of different distributions all of which are almost the same but not quite. It makes the platform an enormous headache to support with rapidly diminishing returns for each different variants you try and cover.

I agree . AppImages were created to solve this problem - they didn't quite make it but they are close...

[firelord]

I wanted to add something about win32 apps.
I the last years I have tried many tools with wine (I also went and tried their older version to find a working 32bit ). I noticed in many of the the issues that O had with Lantern.
While the developer was compiling his app using 32bit target some of the "subprograms" were 64bit (eg AGDx Studio -if I remember correctly) .
I remember at some time all the 32bit IDE i tried with wine had at least one 64bit compiler.

I remember I had some problem with DAADReady when I was making Top Gun MaveRick Dangerous and I was working on linux and compiled in windows (not 100% sure that if it was a win64 issue though)..

[Timmy]

So what you're saying is that win32 isn't the magical solution for everything. We didn't say that.

There will always be something that might not be working. It's like emulators (wine isn't an emulator), just because there is an emulator it doesn't mean it can handle everything.

I also have some win32 stuff that doesn't work on wine. But I have much more problems with linux stuff.

It's still a lot easier, and more compatible than an Appimage alternative though. There are also more tools that generates for win32 than for all kinds of linux distributions.

Even though I haven't found a good tool that generates good win 32 applications right now on Linux. Maybe one day, but I'm very busy right now. (I also don't have time right now doing any z80 stuff either, so even if I have time it's still a dilemma.)

[ZXDunny]

But if you want my opinion, the most compatible target in 2024 would be Win32. Just do that and I can use it with Wine.
I believe I can now use Spin and Basin this way too, so no worries. And with those 3 I have all my needs covered.

Would be interested to hear how SpecBAS runs under WINE - it's built differently to BASin and ZXSpin. There is a 32bit exe available for it.

[Timmy]

Would be interested to hear how SpecBAS runs under WINE - it's built differently to BASin and ZXSpin. There is a 32bit exe available for it.

I will be really busy for a while, so if someone else wants to test this, I wouldn't mind.

[firelord]

So what you're saying is that win32 isn't the magical solution for everything. We didn't say that.
...
Even though I haven't found a good tool that generates good win 32 applications right now on Linux. Maybe one day, but I'm very busy right now. (I also don't have time right now doing any z80 stuff either, so even if I have time it's still a dilemma.)

This is a suggestion. No need to do it...

Would be interested to hear how SpecBAS runs under WINE - it's built differently to BASin and ZXSpin. There is a 32bit exe available for it.

I have tried it (after Basin) but not too much. I run into the same problem. Wine was too heavy for the old PCs in my labs.
The old native linux version run very well but it was old (v0.914 , the gui was missing many options).

In my home PCs (i3 13gen and i5- 5th gen) SpecBAS and Basin run very well -SpecBas sometime show a memory access error and I only can use it full screen...
I use SpecBAS_32_v1247GL__220715 and Basin 1.58-1794.

Spoiler

MPAGD is 64bit and haven't managed to make it work

[ZXDunny]

Interesting that WINE performance is bad - it's not emulating anything, and the OpenGL usage in SpecBAS is literally just a simple quad blit once per frame. The rest of SpecBAS will all be native Linux binary when it's running.

I'll look into a native linux build but the linux build environment (FPC/Lazarus) is terrible.

[Guesser]

No

[berarma]

The problem with Linux is, and has always been, the myriad of different distributions all of which are almost the same but not quite.

That's a poor excuse while trying to put a bad reputation on Linux. Just package all the libraries your application needs, like Windows apps have been doing for ages, and it will work in all distributions. It will probably work with less issues than Windows.

Edited by PJ to remove excess quoting

[Cheez26]

That's a poor excuse while trying to put a bad reputation on Linux. Just package all the libraries your application needs, like Windows apps have been doing for ages, and it will work in all distributions. It will probably work with less issues than Windows.

You make a good point, but AppImages don't always work on all distros. Plus, AppImages are probably painful to compile together. I don't like putting a bad rep on Linux either. I want more WIndows-like distros like Ubuntu/Debian, but do you have any idea how much a complete desktop environment can take up in terms of resources? It's the reason why I use Puppy Linux on my old ThinkPad X140e that has 4GB RAM and some outdated AMD CPU and GPU.

[AndyC]

That's a poor excuse while trying to put a bad reputation on Linux. Just package all the libraries your application needs, like Windows apps have been doing for ages, and it will work in all distributions. It will probably work with less issues than Windows.

It's not though, it's just reality.

Linux is infinitely customizable, which is great if that's what you want. But it's terrible from a developer perspective where you can't entirely rely on anything being available - even really basic stuff like how the audio stack works.

Appimages try to fix that but it's just too vast a chasm to entirely bridge and it always will be unless the definition of what is "Linux" is reduced down to a.managable subset. It's the price you pay for being able to change literally anything.

[firelord]

Interesting that WINE performance is bad - it's not emulating anything, and the OpenGL usage in SpecBAS is literally just a simple quad blit once per frame. The rest of SpecBAS will all be native Linux binary when it's running.

I'll look into a native linux build but the linux build environment (FPC/Lazarus) is terrible.

I don't think the problem is in your SpecBAS code. With newer PCs win32 version of SpecBAS runs very fast. I don't think your program will need more optimisation.

I have some idea of what is making wine apps slow .

Spoiler

I tried that in Debian Dog with basic setup. I don't have any graphics drivers installed -just what the kernel 6.1 sees. I have no idea how much OpenGL is affected. All the PCs in my lab are really old -from P4 to Core2duo E4400 .
Also, I have DebianDog running almost all in RAM (even file changes) to gain as much speed as possible. Wine eats lots of ram so this might amplify the problem.
The performance of wine (in some of the machines) could be compared with the performance of a windows XP machine with less than 1GB RAM (if this helps you understand the speeds).

[berarma]

It's not though, it's just reality.

Linux is infinitely customizable, which is great if that's what you want. But it's terrible from a developer perspective where you can't entirely rely on anything being available - even really basic stuff like how the audio stack works.

Appimages try to fix that but it's just too vast a chasm to entirely bridge and it always will be unless the definition of what is "Linux" is reduced down to a.managable subset. It's the price you pay for being able to change literally anything.

You don't seem to know much about development. There are libraries which handle everything for you, just like there are on Windows. You just use them and include them in your app. Seriously, it's the same as on Windows.

Why wasting time dissing an OS you clearly don't care about?

[PROSM]

Linux is infinitely customizable, which is great if that's what you want. But it's terrible from a developer perspective where you can't entirely rely on anything being available - even really basic stuff like how the audio stack works.

Appimages try to fix that but it's just too vast a chasm to entirely bridge and it always will be unless the definition of what is "Linux" is reduced down to a.managable subset. It's the price you pay for being able to change literally anything.

I agree that there are a huge number of variations of Linux. However, even just providing a package for, say, Ubuntu, would cover a large portion of users, including people like myself on Linux Mint. Those using niche distributions likely have the technical skills to get it running without help.

That being said, as long as I can build it myself, then I'm happy. There's only two non-game applications on my system that I can't get Linux versions of, those being EightyOne and OpenMPT, because they've been written using the Win32 API. Running under Wine, they respond very sluggishly compared to the rest of the system. I'll continue using them, because they're great in their respective domains and I couldn't get by without them, but occasionally I do find myself thinking, "I wish they'd written this to be cross-platform".

[AndyC]

You don't seem to know much about development. There are libraries which handle everything for you, just like there are on Windows. You just use them and include them in your app. Seriously, it's the same as on Windows.

Why wasting time dissing an OS you clearly don't care about?

I'm not dissing it, I use it almost every day for things it is good at. I'm also painfully aware of its shortcomings. Cross platform libraries do exist but they're by no means a panacea. And ultimately supporting more platforms means more testing,. When you're tools are already niche, and Spectrum tools are very niche already, it just isn't worth the effort.

[Cheez26]

You don't seem to know much about development. There are libraries which handle everything for you, just like there are on Windows. You just use them and include them in your app. Seriously, it's the same as on Windows.

Why wasting time dissing an OS you clearly don't care about?

Okay, wise guy. What would you suggest?!! Because I personally suggest learning how to use Godot. I know one person here is working on a cross-platform tool with that. That same person also has more experience in software development than you probably ever will. As matter of fact, you're just being elitist, forgetting that most people here use Ubuntu or Debian as their starter Linux distro, and even with the Windows-like nature of those systems, they're not and never will be perfect. I know this, because I use Linux Mint, a popular Linux distro made with beginner users in mind.

tl;dr - Sit your arse down and listen to reason. They weren't even dissing Linux anyhow.

[berarma]

I'm not dissing it, I use it almost every day for things it is good at. I'm also painfully aware of its shortcomings. Cross platform libraries do exist but they're by no means a panacea. And ultimately supporting more platforms means more testing,. When you're tools are already niche, and Spectrum tools are very niche already, it just isn't worth the effort.

The libraries don't need to be cross platform, alhough there are some good cross platform libraries. I'm aware that developing for two platforms is more work than developing for just one, that's undoubtfully true. That's all there is.

Developing for Linux is no different than developing for Windows. Your apps don't usually make system calls and use the hardware drivers directly. They use libraries which work across all Windows versions and hardware drivers. Same with Linux. Windows isn't better in that regard.

[Guesser]

Just package all the libraries your application needs, like Windows apps have been doing for ages, and it will work in all distributions. It will probably work with less issues than Windows.

Hooray, now I have 50 different copies of an outdated library with some horrible security bug on my system all going unpatched because the authors of the apps haven't released new builds. This is clearly an amazing improvement over shared libraries. Truly this is finally The Year of the Linux Desktop

[Cheez26]

Hooray, now I have 50 different copies of an outdated library with some horrible security bug on my system all going unpatched because the authors of the apps haven't released new builds. This is clearly an amazing improvement over shared libraries. Truly this is finally The Year of the Linux Desktop

I'll be quite honest and suggest you try Arch if you're that worried about security bugs. Then again, Arch is also more of a pain to set up than stock Debian (and I ain't talking about Ubuntu).

[berarma]

Hooray, now I have 50 different copies of an outdated library with some horrible security bug on my system all going unpatched because the authors of the apps haven't released new builds. This is clearly an amazing improvement over shared libraries. Truly this is finally The Year of the Linux Desktop

Hooray, you've just discovered how Windows apps work and one of its biggest strengths according to its users.

If you want portability, this is the way on any system. AppImage files have the same issue. They're just a package with all libraries included, a bit more convoluted than it needs to be but automated.

[berarma]

Okay, wise guy. What would you suggest?!! Because I personally suggest learning how to use Godot. I know one person here is working on a cross-platform tool with that. That same person also has more experience in software development than you probably ever will. As matter of fact, you're just being elitist, forgetting that most people here use Ubuntu or Debian as their starter Linux distro, and even with the Windows-like nature of those systems, they're not and never will be perfect. I know this, because I use Linux Mint, a popular Linux distro made with beginner users in mind.

tl;dr - Sit your arse down and listen to reason. They weren't even dissing Linux anyhow.

It's funny that you mention Godot. It doesn't have 20 export targets for Linux, only one just like Windows. It can do that because it contains all the libraries that needs. It's really a good example of what I'm suggesting. It does the same for every target platform. Nothing's perfect but the defect you're talking about it's the same on every system, and the same solution applies.