Overte VS glibc_version_header

Overte is an Open Source desktop/VR platform similar to VR Chat or Resonite.

Unlike most other similar platforms, we follow a very distributed model. We don't have a walled garden users must log into, instead the architecture is reminiscent of a 3D webserver -- anyone can deploy the server anywhere in a few minutes, and connect to it.

We don't monetize anything, collect data, or deal with cryptocurrency or NFTs.

The grant will be used to modernize the rendering engine, build system, audio system, and make some other improvements:

https://overte.org/#we-ve-obtained-an-nlnet-grant

That looks amazing!

If you'd ever like to see it in VR, we run an open source desktop/VR social platform at https://overte.org/

It shouldn't be too hard to set up a server and take a walk among the past.

Sure.

High Fidelity, sort of. Failed commercial project to develop a sort of VR world from the same guy that made Second Life. Their advertising honestly cheesed me off and seemed to reek of desperation. Their adoption of cryptocurrency didn't help either. What did was that despite that they had promising technology people I knew talked about, so I did check it out despite all my initial misgivings, and it was good enough for me to stick around there for a good while. When they gave up, I was part of the group of people that tried to keep things going, which eventually became a non-profit I'm now a member of, https://overte.org/

Resonite. The new version of NeosVR, still in development. Happened after an ideological split. I heard of NeosVR mostly from Reddit discussion and friends who love the system.

Linux Weekly News. Only news site I pay for, they post interesting highly technical information. Pretty sure I heard them mentioned in Linux discussion spaces.

Linode -- Same deal, Linux users that use their services. Now it's much bigger, I signed up back in the early days, back when they used User-mode Linux, and had no SSDs.

Oh, I mean we started a non-profit to support our particular project (https://overte.org/), not that we've got a general purpose organization providing service to whoever needs it.

So I'm not sure we're we're a good fit, in that we're neither something comparable to Code Shelter, nor unmaintained.

I think it's an unfortunate necessity for some kinds of applications.

Eg, we make this: https://overte.org/

We're currently using AppImage because that was the first thing that worked for us, but most of the reasons are the same either way: We want to spend time developing the software, and that means it's hard to justify packaging every release for a dozen distributions. And I'd say nobody particularly wants to do it.

We also expect our users to keep reasonably up to date, not whenever it's convenient to the distribution. Code changes can change the networking protocol, and some of those can require everyone to upgrade.

So at least to me it makes perfect sense to package some kinds of applications this way. Maybe not KDE's calculator, but definitely things like games and tools with specialized markets, where it may be difficult to find people wanting to do the work of packaging them for a distribution.

It's probably something we (https://overte.org/) can use.

We have a 3D environment with spatial audio. Audio is encoded server-side, and since it's spatial everyone needs their own mix. We're using Opus, and audio encoding turns out to be the usual limiting factor on small servers.

So this kind of thing is exactly up our alley: an alternate option that uses less CPU than Opus, but consumes less bandwidth than raw audio.

But adding supporting for FLAC is also on our list. It seems nicely performant when compared to Opus.

Philip Rosedale (the Second Life guy) after a while left the company and started something called High Fidelity. That was something like SL 2.0 design-wise and was built with VR support from the start. This also died eventually and got picked up by volunteers, which is what I do now :)

More practically, I currently work on a former commercial project that was luckily open source. Thanks to that, we can keep it going!

One major headache with trying to run precompiled binaries on Linux is that if they were compiled using a newer version of glibc than the target machine, they won't be able to run. Back while working on Factorio, I was trying to get around this problem with endless Docker containers, but coworker Wheybags came up with a much solution to this, which is simply to, at compile time, link to the oldest compatible version of glibc: https://github.com/wheybags/glibc_version_header

If what you're doing works for you, great, but in case it stops working at some point (or if for some reason you need to build on a current-gen distro version), you could also consider using this:

https://github.com/wheybags/glibc_version_header

It's a set of autogenerated headers that use symbol aliasing to allow you to build against your current version of glibc, but link to the proper older versioned symbols such that it will run on whatever oldest version of glibc you select.

There are other approaches like https://github.com/wheybags/glibc_version_header or sysroots with older glibc, e.g. https://wiki.gentoo.org/wiki/Crossdev - you don't need your whole XP, just the the system libs to link against.

Sure, having a nice SDK where you can just specify the minimum vesion you want to support would be nice but who do you expect to develop such an SDK? GNU/glibc maintainers? They would rather you ship as source. Red Hat / SUSE / Canonical? They want you to target only their distro. Valve? They decided its easier to just provide an unchaning set of libraries since they need to support existing games that got things wrong anyway and already have a distribution platform to distribute such a base system along with the games without bundling it into every single one.

A few links gathered from a quick google search as a primer:

http://stevehanov.ca/blog/?id=97

https://www.evanjones.ca/portable-linux-binaries.html

https://insanecoding.blogspot.com/2012/07/creating-portable-...

https://rpg.hamsterrepublic.com/ohrrpgce/Portable_GNU-Linux_...

https://github.com/wheybags/glibc_version_header

In other words: there are a lot of steps and a lot of gotchyas to doing this that you're glossing over. Linux userland libraries are generally designed with the intention that an army of third-party maintainers will integrate all of this desperately developed software together and place it in a repo. Naturally every distribution wants to do things a little differently too, and they have a habit of changing it up every couple years. When you try to step out of that mold things unsurprisingly become more difficult. Whereas Windows, Mac, Android, etc. have been designed since the beginning not to require that sort of thing and it is consequently a much, much more straightforward process.

I'm curious why, since you seem to believe the process is so straight-forward, you think it is that so few people distribute a simple binary? Why were Flatpak and AppImage invented?

> Binaries compiled against today's glibc can fail to run on a machine that hasn't been updated since last week because they rely on a new / different symbol.

Note, however, that it is a Glibc bug (modulo Drepper’s temper) if the reverse happens: Glibc symbol versioning ensures that binaries depending on an old Glibc (only) will run on a new one. So the proper way to build a maximally-compatible Linux executable would be to build a cross toolchain targeting an old Glibc and compile your code with it. Unfortunately, the build system is hell and old Glibcs doesn’t compile without backported patches, so while I did try to follow in the footsteps of a couple of people[1–4], I did not succeed.

Mass-rebuilds still happen with other ecosystems, though. GHC-compiled Haskell libraries are fine-grained and not ABI-stable across compiler versions, so my Arch box regularly gets hit with a deluge of teensy library updates, and Arch is currently undergoing a massive Python rebuild (blocking all other Python package updates) behind the scenes as well.

[1]: https://github.com/wheybags/glibc_version_header (hack but easy and will probably work most of the time)