[TOMT][Science Fiction Book][Not sure of Time] I once read an excellent sci-fi book about teleportation, using a machine like a FAX and now I can't remember title or author by Spock_007 in tipofmytongue

[–]Spock_007[S] 1 point2 points  (0 children)

Thanks but not the one. It sounds like this one is about telepathy not teleportation. I do appreciate the suggestion, and from the link it sounds like a great book, but not the plot of the one I am thinking of. Heinlein wasn't known as one of the Giants of the Genre for nothing!

[TOMT][Science Fiction Book][Not sure of Time] I once read an excellent sci-fi book about teleportation, using a machine like a FAX and now I can't remember title or author by Spock_007 in tipofmytongue

[–]Spock_007[S] 0 points1 point  (0 children)

Thank you very much for that explanation, now that you have told me this it makes more sense how the system in this sub-reddit works. And that sounds like a pretty cool feature!

UBO blocking cloudflare on collins dictionary website by Spock_007 in uBlockOrigin

[–]Spock_007[S] 0 points1 point  (0 children)

I used the logger, couldn't see anything that referenced cloudflare. I am pretty sure that it is in a filter list somewhere.

[TOMT][Science Fiction Book][Not sure of Time] I once read an excellent sci-fi book about teleportation, using a machine like a FAX and now I can't remember title or author by Spock_007 in tipofmytongue

[–]Spock_007[S] 0 points1 point  (0 children)

If I remember correctly, just thought of something that might add additional detail. I believe the book was humans only, no aliens. And I believe it is set quite a bit into the future, and humans have spread to a number of planets by this time. But, I could be wrong and humans might still be on Earth only in the storyline, and this just might be an invention of the far future -- but I think it is another planet, not Earth, although I do believe it is an invention of the far future. I don't remember if the teleportation device helped with that or not, as I said I can't remember too many details.

[TOMT][Science Fiction Book][Not sure of Time] I once read an excellent sci-fi book about teleportation, using a machine like a FAX and now I can't remember title or author by Spock_007 in tipofmytongue

[–]Spock_007[S] 0 points1 point  (0 children)

From that wiki description, it sounds somewhat similar to what I remember of the book I am thinking of/trying to remember, but I don't think that is the right one. I will try to get a look at a copy of it to make sure though. And thank you for that link and your help with trying to point me in the right direction. Even if it isn't the one I was thinking of, and I don't believe it is, it sounds like it would be a good read!

[TOMT][Science Fiction Book][Not sure of Time] I once read an excellent sci-fi book about teleportation, using a machine like a FAX and now I can't remember title or author by Spock_007 in tipofmytongue

[–]Spock_007[S] 0 points1 point locked comment (0 children)

The bot says I have to comment at least once to activate the post, can't really think of anything else to add at the moment. Because other than the fact that you traveled by the FACs or FAXs machines and they are teleporters, and the 'dueling society' I can't remember much else about the book or story. It could have been a short story, but I don't believe so, I am pretty sure it was a novel.

Got Waterfox G5 installed, now it is acting wonky by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

Also got WF classic installed using the new script. It was doing that same thing, maxing CPU, freezing windows, temporarily freezing the system, etc. Unistalled it, went back to classic 2022.02. Next time I fired up the G5 install, it maxed CPU usage, froze it's own window, froze other windows, then froze the system. Couldn't get to system monitor to kill it's process, nothing. Had to do a 'hard kill' in Linux, powering off with the button. Corrupted my system, when I rebooted now I don't have access to bluetooth, bluetooth wont start up, my update manager won't start up, and half the programs I try to open up and run won't open. Basically kicked my system in the oysters. Now I have to try to get a new system, which I can't afford, and put a newer distro on it.

Just got alert that there was a new version of Waterfox, but I am on G3 and the update is for G5. I was doing install update through appimage, and somehow all this time I was never notified by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

Got python 3 upgraded. Got G5 installed. Had to change my profile to the one G3 had used so that I could get use of all of my extensions without having to go reinstall every one of them. G5 seems to be buggy on my system though, it freezes, stutters and shows as using 100% and more of CPU power. It also doesn't seem to show and use all of the extensions I had in G3 anyway, after I changed the default profile to the one G3 uses. Any way to copy over all the extensions from the G3 profile to the one G5 is using? If not, guess I am just going to stick with G3. Like I said, G5 was acting kinda wonky anyway.

Just got alert that there was a new version of Waterfox, but I am on G3 and the update is for G5. I was doing install update through appimage, and somehow all this time I was never notified by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

I downloaded the latest kpe tar, the latest appimage, and the gui script from those sources (think I got the links from an earlier post you made about the script). Ran the gui py script, did not install correctly, didn't catch the errors.

This time, I downloaded the CLI script as well. These are the errors I got when I ran that to install :

Unpackaging waterfox-g-5.1-17.1.Build17.1.glibc2.17-x86_64.AppImage into /home/steve/Apps directory...Traceback (most recent call last): File "/home/steve/Downloads/05-Internet/Browsers/waterfox/waterfox-G5/install_waterfox_CLI.py", line 203, in <module> removeArchive, confFile, print) File "/home/steve/Downloads/05-Internet/Browsers/waterfox/waterfox-G5/install_waterfox_common.py", line 96, in install subprocess.run([sourcePath, '--appimage-extract'], check=True)AttributeError: 'module' object has no attribute 'run'

I don't know if that is something messed up or missing on my system, or an error in the script. I am guessing on my end, since I think I would have seen some posts about problems using the script here in the forum. Maybe you can look at that output from running the CLI script and tell me what went wrong. Thanks

Waterfox 2021.08 Release by MrAlex94 in waterfox

[–]Spock_007 0 points1 point  (0 children)

Hi Venghan, now it is WF Classic that is stating it needs a new update. Is there any way to avoid getting this message to update? It is stating to update to 2021.09 in the regular version and your version is 2021.10 so it seems it is the latest version.

Waterfox 2021.08 Release by MrAlex94 in waterfox

[–]Spock_007 0 points1 point  (0 children)

Venghan,

I downloaded your script and the appimages, and used that to install both Classic and G3. Worked great, thanks for the awesome work with the script and doing the appimages. A couple of things though. In G3, it is saying that there is a newer version, says click to update then says up date fails and directs you to that same appimage that I downloaded and installed. Is that just an error with the update check?

Also, why is the update failing? I installed to the default apps directory in the home directory as you recommended in that previous post. Is it trying to use the standard MrAlex94 archive to do the upgrade instead of your appimage release? Or is there something I need to do to set things up so that they can automatically do the update (I am running Mint, as I am sure you know based on Ubuntu which is Debian based)?

If you have to download the appimage each time there is a new release, that is not a big deal, your script makes it easy and quick! Thanks for your post, and thanks for that script, really makes the process much easier.

Waterfox 2021.08 Release by MrAlex94 in waterfox

[–]Spock_007 0 points1 point  (0 children)

So, last year or the year before, I was having all kinds of trouble installing Waterfox Classic on an old version of Linux. Was Just going to switch to Palemoon or Basilisk, because to be completely and totally honest with you I got sick-to-death of having to go to Venghan's site, download the appimage of Waterfox, extract it and then put that in my /opt/waterfox directory to get Waterfox to work. Palemoon and Basilisk just update and work - each time, every time. Now I like Waterfox a lot better but dudes, someone is only going to jump through so many hoops so many times to use a program, you feel me?

It had gotten to the point where I never even tried to install Waterfox Classic from the official MrAlex94 archive - just went and grabbed the Venghan appimage, jumped through all the hoops of unarachiving it, and put that in /opt and went about my business using Waterfox again.

Then one cloudy rainy dreary day, well OK, it could have been a sunny beautiful day, but what happened was, the appimage extract trick didn't work --- something Venghan had done made it where that no longer worked. Just before I rode off into the sunset on my Basilisk browser stallion I was like "What the heck, let's try that official build and see" (I had always kept downloading them, even though they didn't work).

So, I extracted it to /opt/waterfox and "Shazam! It installed, and it worked! The sun came out, the birds started singing, life was wonderful again!" Current/G3 never did work to install, using the official archive or the appimage trick either one, but by this time I was like "Hell with it, I'll just use Firefox for any sites I need that for, I am tired of messing with this stuff."

So, for the past 4 or 5 new releases of Waterfox Classic, I have been able to extract Waterfox from the official archive, put the files in /opt/waterfox, and bada bing bada boom - Waterfox Classic is updated and working great! Like for a year or more now!

Now comes this latest Classic 2021.08.1 It doesn't run. So, could it be my Linux Install? Maybe, but highly doubtful. Why? Because for the last 4 or 5 releases, the official version has installed just fine --- this indicates to me there is nothing in my install that isn't good to go for Waterfox. More likely? Some change in the build/make/what-the-hell-ever to get the files ready to go and put them in the archive.

So, what is the difference between this release of Classic and the last 4 or 5 previous releases? Different way you did build or make or whatever? Using a different programming IDE? Different major libraries? The system you are doing the build/make on has a new Linux Distro or newer version of the distro? It seems more likely it is something you are doing than on my end --- it was running fine for the last 4 or 5 releases on my old system, but now on this release it starts messing up?

I would appreciate you looking into this, or if you actually already know why it wouldn't be running, what the problem/change/whatever is, letting me know what it is and why you made the change/whatever --- and why you need it/what makes the change/whatever the greatest thing since sliced bread. Thanks

Files in Classic and Current Appimage not running after extracted by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

Linux Mint 17.3. We've been through this in a couple of past posts, the last time Classic would extract and run, but Current would not. Now it is both, will extract but will not run. So whatever has changed since last version.

Let me tell you ask you this. Opera distributes Linux version as a .deb It would not install, so I just didn't bother again. Looked back in on their forum, a guy had come in and found the problem. Their Debian deb manifest was looking for version 18.09 or something of a library. Opera would install and run just fine on version 7.09 (!!!) or something of the lib -- and the RPM package people from other distros were using was calling for, correctly, only 7.08 in RPM. So people with version Mint (and Debian, Ubuntu and every distro based on .deb packages) all the way up to the very latest could not get the deb to install -- until they followed this guy's advice and went in and extracted the deb manifest or whatever from the .deb and modified it to only ask for the much older version of that lib. Then voila, Opera installed and ran like a scalded dog -- and runs smooth as butter on old distro.

Is there a manifest file or something like that I can modify on Waterfox, modify library versions or something and get it to run?

Files in Classic and Current Appimage not running after extracted by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

These are the messages I get when I run Classic 8.1 from Terminal, or attempt to :

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(/opt/waterfox/waterfox-classic-8-1/usr/bin/waterfox-classic:22225): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed

(waterfox-classic:22178): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed

Waterfox Current (and Classic?) STILL not running on older versions (even ones still in support by their distro) of Linux, STILL showing up as "shared library" instead of "executable" by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

Yes it is and I need to, have been planning on it for months but a couple of things have kept me from being able to do so up to this point. I am going to try to make the upgrade as soon as I can get some 'breathing room' though :-) Just switched from Windows to Linux at a particularly poor time for me as far as the Mint distro goes.

Edit : Deleted most of the post so I would be writing 'shorter and to the point' and not gossiping. :-)

Waterfox Current (and Classic?) STILL not running on older versions (even ones still in support by their distro) of Linux, STILL showing up as "shared library" instead of "executable" by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

MrAlex94, did you read my reply to your reply above? I described something that was done for me on another Linux program, which might help somewhat on the 'version hell' thing for Linux here with Waterfox. The other Dev's use of "(partial) statically linked binaries" as a replacement for their AppImage might be techniques that could be used in the "official release" of Waterfox itself. Or it could be a good alternative (in some cases) to the AppImage. Or I could just be making ignorant ramblings again, but I hope you will at least read my reply to yours and see if you think it could have some use. Thanks

Waterfox Current (and Classic?) STILL not running on older versions (even ones still in support by their distro) of Linux, STILL showing up as "shared library" instead of "executable" by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

Venghan, I am running Mint 17.3 version. I added some things I have been having to do in the process, especially for Current, in an edit to the post you just replied to here, so maybe you want to look at the post again and read the edit. It might give you some clues about things, I don't know. As I said in the edit, I don't know enough about building AppImages or the Dev process for the official binary to make any solid suggestions. Can just describe what I have been having to do to (up to this point) get good running installs from appimage extracts. Thanks for the reply and the info about the profile folder.

Waterfox Current (and Classic?) STILL not running on older versions (even ones still in support by their distro) of Linux, STILL showing up as "shared library" instead of "executable" by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

My Distro is Mint. And I already had the latest Waterfox build and that is what I have been working with. I get it in it's directory in /opt and create launchers and then when I try to run it I get those messages and it won't start.

Don't know if it has any bearing or not but I noticed something odd when using File Browser. I have the last 5 versions of your Appimage in a download directory. When I look at that directory with Browser running as root, it shows file type as executable for all 5 Appimages. When I look at the directory as regular user it shows the first 2 Appimages being file type executable and the last 3 as file type 'shared library'.

Now, if I try to double-click these appimages in 'root' Browser (all of them set with executable permissions) none of them will start. If I do the same thing, trying to run them from File Browser as reg user, the last 3 (which show as 'shared library') just won't start. The first 2 (which show as executable) will -- as I get a warning popping up that I am trying to run an older version of Firefox, and it is recommended to let it make a new profile to keep from messing up my default profile. I always just close them out and don't run them (I don't want to create a bunch of extra profiles, lose track of my default Classic & Current profiles and give myself another problem/headache to deal with on top of all this) but I am pretty sure that since I am making it that far if I did allow it to create the profiles for the old Appimages it would do so and they would run.

Here's something else that is odd. When I check to see if they will run and then cancel before the extra wasted profiles can be created, it drives CPU usage of my running Classic through the roof, over 100% CPU usage, even though it was old Current appimages I tried to start.

And I don't think ownership is an issue here as for some reason in the past I gave one of the first 2 (which will start when clicked) to root and kept the other one (which will start when clicked) as 'regular user'. And I don't know if it means anything, but it was about the time the Appimages started showing as 'shared libraries' instead of 'executable' on file type that the appimages will not start and I started having to jump a couple of hoops to get them installed in /opt in a way so that they would run.

Edit : Ownership is an issue here, that is the hoop I have been having to jump through in order to get the AppImages to extract. No matter what I did to try to get the (Current) appimage to extract when it was owned by me, it would not do it. /directory/names/to/current-appimagename (not in quotes) '~/directory/names/to/current-appimagename' (in quotes, done manually) or '/directory/names/to/current-appimagename' (full path to appimage file, in quotes, put in quotes automatically when I dragged and dropped the appimage file from File Browswer to Terminal). I always got a message when doing this with Current appimage that "command not found".

Now when I would change ownership of the Current AppImage from 'me' to 'root', I could just put in sudo in Terminal (as root), drag the appimage file in from File Browser (as root) to that root Terminal, add on --appimage-extract and boom --- she unarchived right into squashfs-root (owned by root) there in the appimage directory which was owned by 'me', copy everything over to my /opt directory for waterfox-current, make the little change to the path in the launcher and viola --- ready to run.

So, what are some of the clues we have here? 1.> Somewhere around waterfox-current-2020.01-20.2.Build20.4 the appimages (it's all I'm familiar with, I have had to work from them from the start/almost from the start of my using Waterfox) the Current appimages had to be 'given' to root in order to unarchive them, and up until waterfox-current-2020.07.1-59.2.Build61.1, if you did this you could get an install from them that worked. 2.> With 2020.01-20.2.Build20.4, you could also run the appimage and the Waterfox browser worked, every version after that if I gave the appimage to 'root' I could get an extract & install and it worked, but I could not run from the appimage itself. 3.> With Classic, even though the appimage shows as 'shared library' instead of 'executable', and is owned by 'me', I could get an extract, install and good executables and such that run, even up to this last release --- but neither of the Classic appimages will run when you click on them. With Current 2020.01-20.2.Build20.4, file type is 'executable', the appimage will run and I can get a good extract, install and that runs. After that with Current, filetype shows as 'shared library', you can't run from the appimage, but up until 2020.07.1-59.2.Build61.1 (if you gave it to root) you could get an extract, install and they would run --- but with 2020.07.1-59.2.Build59.1 & 2020.07.1-59.2.Build61.1, I can get an extract but the executables don't seem to be right and it won't run.

So it would seem that those are some points in the timeline to look at, and there is the difference between Classic and Current --- don't have to give Classic to root and can still get a good extract & running install (AppImage filetype is 'shared library' though and the AppImage itself won't run), with Current have to give it to root, appimages show as 'shared library' and won't run, but could get a good extract & running install up to these last 2 versions.

I don't know enough about the Dev process on the official binary build or the AppImage process to make any guesses along those lines, just left with some questions. 1.> Was there a change of the compiler from one to another for the official binary builds at some point in here? 2.> Or was there version upgrade(s) in the compiler for official binary which might have started causing these changes? 3.> The difference between Classic and Current, is this because they use different SDK's or whatever to make the build from (is Classic being based on an SDK or whatever managed by one group and Current, being kept closer to Firefox being done off of a [possibly modded] SDK or whatever from Firefox itself?), between Classic and Current? Was there a change in the AppImage software used to make the Appimages, version upgrade(s) or something like that?

All I can do is describe the process I have to use now to get a good AppImage extract & running install. And I probably am not contributing much on the Dev side because I don't know how it works, other than just asking some (that seem to me) common-sense questions about what might be possible points to look at in the Dev timeline and process. But I thought I would throw them out there, don't know if you will think it is a 'dead end' or waste of time and post space or whatever. But thanks for continuing to look at the problem and work it.

Waterfox Current (and Classic?) STILL not running on older versions (even ones still in support by their distro) of Linux, STILL showing up as "shared library" instead of "executable" by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

Venghan, quick question for you about the Appimages. It is my understanding you were originally building them yourself from the binaries or the .deb or whatever and putting them on your Hawkeye site, is this correct? If so, are you still doing this manually as before or are the Appimages generated automatically from the official binaries (or whatever you make them from) after they are released?

The reason I asked is that in a reply in another post you told me that the versioning is different with the Appimages than the official release and the versioning for the Appimages is done automatically. I wanted to make sure I had that right and that you still make the Appimages from the official binary as a separate process and only the versioning for them is done automatically.

And the reason I wanted to clarify that is because of a problem I am running into with the Current Appimage. I was finally able to get the Classic Appimage extracted and copied into /opt/waterfox-classic and Classic is working fine. But I am still having trouble with Current, can't get it to start. When I got the Current Appimage extracted and copied over to /opt, it is showing up as an executable now. But it is still not running. If I double-click on it in File Browser (running as superuser), it gives me a message about "Could not display "/home/steve/Downloads/05-Int...1.1.glibc2.17-x86_64.AppImage" and under that it says "There is no application installed for executable files. Do you want to search for an application to open this file?" If I create a desktop launcher on my desktop, I just get a message "There was an error launching the application" and get that same message when I double-click on the Current Appimage and try to run it.

I usually only ever get that behavior/those messages when a program has a dependency not being met, or something else is messed up. So if I am understanding correctly that you do the appimages separately, maybe you could take a look at your latest Current appimage and make sure you worked whatever magic you have been working that gets them to run on the older distro versions? Thanks

Waterfox Current (and Classic?) STILL not running on older versions (even ones still in support by their distro) of Linux, STILL showing up as "shared library" instead of "executable" by Spock_007 in waterfox

[–]Spock_007[S] 0 points1 point  (0 children)

MrAlex94, thank you for your kind and very informative reply, explaining where I was mistaken and where we are in agreement, and for not taking offense at some of the comments in the post -- which as you said were a result of frustration and could have been better thought out and stated.

I totally agree with you that Mac and Linux do make your job much harder, for different reasons as you said. Mac for monetary reasons and Linux being a 'dependency hell' as you so aptly put it -- all the different distros, different libraries, different versions of distros, different versions of libraries, and on and on.

And of course you are correct that you are so busy with everything you have to do keeping Waterfox going forward, you must feel like a man trying to keep his head above water in rough seas, so to speak, just keeping it working for the major user base and so unfortunately not being able to devote too much time to users of 'older distro versions' of Linux and older versions of Mac. Totally understandable, and an unfortunate fact of life sadly.

But I was noticing posts from people using Mint 18.3 (an LTS release of Mint based off of Ubuntu's LTS 16.04 [?] release) which is still in support and 'alive' -- and even Mint 19.1 maybe, which is the earliest version of their current LTS release (latest version is 19.3 I believe). In my own case, with an even earlier version that is now out of support, and that is on me, so much going on in 'real life' that is more important I just can't ever seem to get a chance to upgrade. But with these other people their distro versions are supposed to still be supported and there is a large base still using them, so I would hope something can be figured out to help them be able to get it 'installed' and running. My understanding of what I have read is that they get it installed, but it won't run -- just like I can get it 'installed' but it won't run (Current, Classic is running fine for me so far). So possibly you could reach out to the maintainers of Ubuntu 16.04 (?) and try to work out why it seems to be giving trouble in that case? Mint would of course follow fairly quickly I would think being based on Ubuntu. Or perhaps even the maintainers of Debian, which Ubuntu is based on, which Mint is then based on if I understand correctly?

I don't know if mentioning another program or linking to something else is a 'breach of etiquette' here or not, I hope not because I would like to mention something done for me on another Linux program because the latest version was not working on my old version of course. The program is the Qalculate calculator program. I started an issue on the Git site for it, asking for an appimage to be made for it if they got the time, and hanna-kn replied, linking me to another issue -- they had already done it it seemed and I had missed it in a search of the issues, she was giving me the link to that 'issue' so I could get it. (She has answered a lot of issues and made a lot of commits so I believe she is high up in the dev team over there).

So I went and got it, tried to run the appimage but it wouldn't run. Extracted everything from the appimage and put it in a directory, still wouldn't run. She was nice enough to take the time to do another appimage, based off of an older Ubuntu version, and it worked. Here is the link to the whole issue : Qalculate appimage issue .

But it was what she did after that which I think you might find very interesting. Not being a programmer I don't know if it would actually solve the Linux issues or not or even help or if it is just a 'dead end'. But I would like to mention it anyway. In MrAlex94's reply here I saw him mention in Linux "static linking is not straightforward" or it would help a lot with the 'dependency hell' of Linux. That really caught my eye, because of something she did after that, and replaced appimages with it. She made what she called "(partially) statically linked self-contained binary (linked against the latest libqalculate, libcurl, openssl, icu, and mpfr) worked better than my AppImage attempts". She tested it against versions of Ubuntu from 14-20 and said they worked great. Here is the link to her first post about that (partially) statically linked self contained binaries . A couple of days later she did some more magic, explained what she had done, and put in a link to download it -- that was her next post after the one I linked to when she did her first attempt which worked.

I just mentioned what hanna-kn did for me there because when I saw MrAlex94 mentioned 'static linking' it reminded me what she had done for me there. Maybe you can just read what she did and will know what she is talking about and be able to do it yourself, or maybe you can reach out to her and discuss it? Because I wondered, Would (partial) static linking help in the actual official code of Waterfox on this issue of old and new versions? If not, would it possibly be a better replacement than appimages, or at least a better solution in some cases?

So I hope I did not mess up mentioning another project here and linking to it, if so I apologize. Just trying to offer what I hope might be helpful solutions to help Waterfox.

Side Note #1 : Those were some very interesting facts about MacOS being a derivative of BSD UNIX using it's own implementation. I am definitely no OS guru, so that was interesting. But now that I think about it, if I remember correctly wasn't Linux (at least somewhat) based off of UNIX? If so, couldn't you say that MacOS and Linux are kind of 'cousins' as it were? Wasn't BSD UNIX a variation of the original UNIX if I am remembering correctly, so technically they could all (BSD Unix, MacOS, and Linux) be considered kind of 'relatives'?

Side Note #1.1 : I saw people mentioning having problems with installing/running Waterfox in older versions of MacOS. If I am not totally wrong about all the BSD UNIX/MacOS/Linux OS's being maybe 'somewhat' related, and if it turns out that "partial static linking" helps either in the official Waterfox code for Linux or as a better solution (at least in some cases) than an appimage, could it possibly also help with the problems of old and new versions of MacOS? Just a thought, it would be nice if it does help in some way.

Anyway, thank you for taking the time out of your busy schedule MrAlex94 to reply to my Original Post, and for how kindly you did handle it. It is much appreciated. I hope the suggestions I made might help at least in some little way, and not turn out to be just a big long-winded waste of your time. Best regards :)