Nicky Dasmijn Personaly i think that Ubuntu 22.04 LTS and up is the right choice as users can't on one side ask for modern SL features and go on with oldies. Linux has the advantage to be light enough to be easy to upgrade without changing the system.

Moreover, Ubuntu is already conservative compared to Arch and talking about maintaining oldies is in the same style as going on with Windows XP ...

If i had one more point to add, it would also be to have a full use of all cores on the whole SL viewer code, which has not been the case till now ... with some parts that could be largely better optimized.

Anyway, as i mentioned earlier, let's go step by step and have in step one Ubuntu LTS 22.04 working fine ..., knowing that it is already 2 y/o and many are already on their upgrade naturally to to 24.04. On my side i forecast to move to Pop!OS next LTS release that should be released on Q3 or Q4 2024, because it brings many features that are much better compared to 22.04, knowing that if you want at the same time stability, modernity on graphics and up-to-date LTS Pop!OS is certainly the best Linux choice at this date, based on Ubuntu.

Woolfyy Resident Ubuntu 20.04 has an EOL 2025-04. It's hardly like Windows XP which went out of support 10 years ago.

I could care less about that itself, as I self compile and use a rolling distribution.

But one of the practical limitation is Github Codespaces being run on 20.04 and they are a convenient environment for simple 3P development or testing things "close" to the GHA runners.

Except one cannot, as the binaries fail to link there (GLIBC too old)

Nicky Dasmijn anyway as quoted before, LL has a problem of old parts too that need to be rewritten ... and there is a time when they will need to really look at it ...

maybe one day i ll have a look at the SL viewer source but frankly looking at oldies that i didn't write has always made me sick. I suppose it is the same reason why Henri did it's own ...

Moreover though my companies have been in the 80s a close partner to Microsoft, i share the same view as some old friends from Redmond .. there are MS choices that it is better not trying to understand LOL also a reason why i moved to Linux ...

So basically you tell me you got not experience with the viewers code. While I do. We can conclude this here

Nicky Dasmijn I should have said "deeper look" .... just what i looked at made me get sick at compiling so i did it for fun and to know how it works, but for sure i am not going to lose daily my time on things badly done due to historical choices needing to rewrite parts to get rid of dependencies that are out of date

UPDATE Knowing that it is a challenge (and a cost) for LL to upgrade it, knowing that dev teams get older, move, and some old parts often get orphan of their authors etc. but there are times when things need to go on.

It is also why i said that the best way to go ahead toward modernity is to have a SL viewer really working as a rolling release on a modern LTS Ubuntu basis first and then see for other environments, knowing too that Linux is just 3% of Firestorm users as mentioned by Beq a few weeks ago ... which is quite deceptive and (to my point of view) would certainly get better if LL was really supporting Linux too.

Coffee Pancake: Most 3p dependencies are statically linked to the viewer, and problems with system shared libraries are much less common now than they were a decade or more ago. The distribution archives that most TPVs provide, including Firestorm and Alchemy, are broadly compatible with the most popular modern linux distros (Arch, Debian, Ubuntu, Fedora, et al.)

One option would be to distribute flatpak and/or snap packages, but the adoption of these packaging methods has been very limited.

Coffee Pancake: It may be possible to produce a wide variety of linux packager formats using nfpm or similar packaging tools. Ultimately though, the first step is getting the Linux viewer building again :)

Signal Linden: Very much agreed.

Signal Linden: The dependency problem is not as big as some people make it out to be - with Firestorm, the only issue like that we encounter is the occasional user who has a system with a glibc that's too old (and a lot of the time its due to someone running an EOL distribution of Ubuntu or Debian, or some other really old distribution).

Support wise though, we only officially will provide support for Ubuntu and debian - though the viewer may also work on other distributions we make no promises of that (in fact we politely let people know this on the Linux download page). The main reason for limiting support to those distributions is largely to to the fact we simply don't have the resources to tackle providing support for every Linux distribution in existence. I gather the same situation would be true for LL if a Linux viewer were to ever surface again (Unless your support team is feeling brave enough to provide support regardless of what distribution the end user is running - yeah, good luck there, lol)

I have always held the belief that its kind of a pipe dream to be able to offer a Linux viewer and expect that's going to work on every single distribution in existence and be able to support it and make everyone happy...

To me, since the viewer is open source, it makes more sense for distribution maintainers (for distributions other than the ones we support) to compile and offer their own packages (and to provide some support to their end users). We've seen Firestorm end up in the Arch Linux AUR repository funnily enough.

mygoditsfullofstars Resident: It's not about compatibility or getting it to run if you're brave and savvy enough.

It's about shipping the viewer though the standard means each distro offers. Getting the viewer (and TPVs) into package management systems is a big deal as it makes the software accessible. even if that requires adding an additional source.

This

apt get secondlife

pacman -S secondlife

emerge secondlife

(etc)

not this

tar xf Phoenix_Fire{tab to expand} -C $HOME/Firestorm --strip-components=1

cd $HOME/Firestorm

apt install wine libidn12:i386 patchelf

patchelf --replace-needed libidn.so.11 libidn.so.12 bin/SLVoice lib32/libortp.so lib32/libvivoxplatform.so lib32/libvivoxsdk.so

It's not really a pipe dream .. there aren't that many distributions that need coverage. deb and arch is most everything these days, add a gentoo ebuild just for me :P

Coffee Pancake: The Vivox issues sure are annoying but unlikely to get any better unless Vivox revive Linux support (more chance of hell freezing over than that happening), or LL (hopefully) one day end their marriage with Vivox and use something less proprietary and more multi platform friendly.

>> "there aren't that many distributions that need coverage"

Try telling that to some of the people out there running LFS, Slackware, CERN Scientific Linux (or one of other 600+ active linux distributions out there that are less known/popular than Ubuntu, Arch and Debian) and you will be met with the typical aggressive response like "who the hell are you to decide what distributions need coverage, its Linux, it should work on any and every system and you should support it" ;)

Coffee Pancake: Even though I don't disagree, I don't think that will happen anytime soon. Which package maintainer will want to deal with the Linden toolchain, which is alien and annoying with anyone outside LL and a selected few.

Plus they'll have to deal with things like fmod, voice (even if) and still always be second class citizen due to no KDU or Havok.

On top of having to constantly battle the Linden codebase with newer GCC versions, having hidden dependencies on curl (must be linked with openssl). And a chonky boi named CEF on top of all that.

Flatpak (on Flathub) is probably the least bad choice with and acceptable amount of effort

````

This viewer exists: the Cool VL Viewer works on any Linux distribution you can find (with or without systemd too), and got its own installer (meaning it does not rely on a specific packaging system). It does not rely either on any UI toolkit (GTK, Qt or whatnot).

The same thing could be done with LL's or any other TPV viewer, and everyone is welcome to reuse my Linux-specific code.

You can also compile it on any Linux distro, without any need for exotic build dependencies (no need for LL's "autobuild" and all its Python modules, for example), simply launching a single script in a terminal pointing in the source tree.

Snap/Flatpak got their own dependency, and some Linux distro don't have them, or some users (I am one of them) refuse to install them and run such opaque and enormous monstrosities...

The Cool VL Viewer is provided bundled as a package-system agnostic installer, which will run on any distro, provides options to install Vivox to run under Wine, and to check for any missing dependency (I am using the old but totally gorgeous InstallJammer, which also works very nicely for Windows builds packaging).

The Cool VL Viewer binaries can run, as provided, on any 4 or less years old Linux distro (the age limitation being related to the glibc minimum version), and do not depend on things such as systemd, root-portal, GTK, Qt or whatnot !

The same could be true of any other viewer (LL's or other TPVs alike), by reusing the code I already developed for the Cool VL Viewer...

````

Everyone is welcome to reuse my build scripts for pre-packaged libraries: they will work for any Linux x86_64 or aarch64 systems. You will also find a recent build of CEF for Linux there, which has been patched to also work properly together with jemalloc (something official CEF builds cannot do any more without crashing lamentably)...

You of course also can reuse the pre-built libraries themselves, but just be aware that I update them frequently and do not keep any archive for their old builds (so you'd have to copy them on you own web server).

````

I solved them via a simple script provided together with the Cool VL Viewer (): as long as the user got Wine installed, my script will install automatically a SLVoice-reserved Wine prefix for them, and the viewer will automatically use it when present; other viewers could also reuse that Wine prefix, since all they have to do is check the "LL_WINE_SLVOICE" environment variable: if present and not empty, all they have to do is to invoke the file it points to instead of "SLVoice" to start the voice daemon...

Henri Beauchamp ``

Glad to hear you have had time to test it on all 600+ Linux distributions that exist out there in the wild :)) I will test your viewer on CERN Scientific Linux, Clear Linux (from intel) and CAELinux later ;) Have you tested it on a LFS system? :P

No need for testing on every distro: as long as your glibc version is recent enough (v2.35 or newer), the viewer will run just fine...

This is due to its almost-zero prerequisites; the only "problem" could be a missing libopenal that you would need to install if not installed by default in your distro, since to avoid issues seen in the past (I have a 16 years experience/history with this viewer and its Linux users) with some rare distros, I do not ship it with the viewer (just click the "Verify libraries dependencies" button in the last page of the installer).

Henri Beauchamp this is about Linux support in LLs viewer. Unless you contribute those 3Ps to them this is a moot point.

The same applies to the build scripts (LL will never accept a contribution for those anyway, as they are hellbent on their own autobuild system)

Nicky Dasmijn something something contribution agreement

Coffee Pancake on GitHub this is even for Henri a non issue.

He signed the CLA there 😀

The problem is that my viewer is too far apart from LL's code base now (after 17 years of code changes, rewrites, etc by me), so I cannot just "commit" stuff "as is" to LL's viewer github: this would have to be backported manually...

As for the 3p libraries, they could simply integrate my script and call it from their own build script for Linux... I be inclined to make such contributions and do it for them, I first receive the that the said contributions (which will cost me time, and time is precious and best spent for my own viewer improvements) will be accepted.

I do not want to end up seeing my contributions lost for nothing, like yours have been in the past for Linux support (I really think LL has been very to you !).

mygoditsfullofstars Resident It's entirely unrealistic to give all Linux distributions official support. The best you can hope for is to pick 1-3 of the most popular, and provide a gzipped tarball or something for the rest with a list of needed libraries and a "provided as-is" agreement. If someone wants to scream that the SL client doesn't work on their custom Linux-powered router, let them scream at a wall.

Signal Linden Please no snap, or at least don't use snap exclusively. Flatpack could be OK if done correctly.