I want in - please realease a Linux client soon


#1

I really want in, but I am on Linux Mint 17. And I am not a Linux wiz self compiler.

It really saddens me that I am missing cool things like the mini golf challenge!


#2

A statically-linked binary that can be just be plonked down in /opt and run on any system would be fine, for beta at least.


#3

I am on Linux as well and havn’t been able to run the client yet. At least some easy up to date step by step instructions on how to self compile would be great. SL and Sansar do not support Linux anymore, so this would be a great chance for HiFi to gain some new users.


#4

"At least some easy up to date step by step instructions on how to self compile would be great"
They exist, they just don’t work unless you are willing to beat up your install. .


#5

Yeah good luck with that since they decided to scrap previous Opengl version support (especially if you aren’t using a new high-end graphics card, since Intel integrated graphics cards will not work because of this). A very STUPID decision if you ask me. Given the amount of unprofessional (non-optimized) assets that will be floating around everywhere, high-end graphics functions will be completely USELESS for another 20 years.

I can run brand new games like Roller Coaster Tycoon World from my intell 4400 HD but not HiFi. I guess they think they are much better than new AAA game titles.

One big reason this is a very stupid idea is because of the current rush on mini-itx machines and smartphones that don’t have room in them for a huge graphics card. A lot of people want tiny portable computers that use very little power.

Powergamers won’t be interested in hifi because they will be off powergaming in MMORPGS and AAA FPS games. The bulk of people interested in virtual worlds at the moment are older people who don’t want to spend a fortune on a gamer rig to do it.

Welcome to the world of High Fidelity. It is a world of bad business decisions and rapid reconceptualization where something might be here one day but removed the next on a whim (even if it locks out half their users or renders current software projects unusable. Don’t expect an apology!).

But hey we have minigolf and snow ball fights, so apparently it is ready for Steam.


#6

hm… more developers think that linux users - power programmers and can self compile all soft… and self can debug this soft… i see cool distribution HiFi for Windows, with installer, with simple for use sandbox… i see installer for Mac… But fo linux again compile source… compile and see bugs with edit overlays… in stable branch… in windows stable i not see this bug… i not know that with crossplatform Qt this work… bug for one platform not bug for other… i be wait binary package for linux from developers…


#7

Building on Linux really isn’t that hard. If anything the roughest part is tracking down the different libraries you’ll need. Most of the ones mentioned here: https://github.com/highfidelity/hifi/blob/master/BUILD_LINUX.md seem to do the trick (names may vary depending on your distro). Other then that its just a matter of downloading QT 5.6.1 (from http://www.qt.org), exporting a few environment variables, and firing off the build.


#8

i see A-Frame, framework for simple create and manipulate 3D scene in browser with use Oculous Rift and more VR HDS and manipulators (thanks MozVR), i see Web-RTC and WebAudio for 3d sound, audio effects and voice chat (if want - for videochat), i see mutiuser component for A-Frame with use sockets.io or Firebase, i see full scriptable all this with javascript, i see Electron project for create desktop apps from webapps. I think this simple way for create good and light analog HiFi.


#9

yes i compile stable release, but… in windows stable release work good, in linu compiled version i see bug with edit objects… edit overlay not work correct…


#10

I see. I’ve been using the newer (not yet stable) releases where they seem to be switching things over to a newer version of QT. Mostly everything seems to work fine with the exception of a few random glitches. Although the only downside is that until its marked stable I can only teleport to other domains running the newer protocol version.


#11

Wow. I finally got a make-all to work on Debian/testing!!!.

I have to go to work shortly, but I will try to write up my process tonight.


#12

As long as you track down the right dependencies it should work on any distro. So far I’ve switched between Ubuntu, Fedora, Mint, and finally settled on OpenSuse. I’m partial to the debian based distros, but alas getting Maya and Mudbox to install on anything not rpm based proved to be a little too frustrating for my nerves to handle. :slight_smile:


#13

I’m one of two HighFidelity developers who work primarily on Linux. From my understanding the reasons why Linux is not an officially supported platform for HF are:

(1) Most of our prospective users are on Windows. HF performed a survey of potential early adopters back in late 2013 right before I joined and the results were 70% Windows. We’re a startup and need to focus on our largest potential user base. If we happen to also run on other platforms then great, but when we’re short on manpower and need to make a call… non-windows platforms get neglected first.

(2) Oculus stopped officially supporting Linux probably for reason (1). They also stopped supporting Mac but stated different reasons as I recall (lack of good video card hardware and early abandonment of OpenGL in favor of a new 3D rendering library they call “Metal”, which arrived this past June) . We’re making a bet that the future of really compelling VR is going to be through the use of head mounted displays (HMDs) and so we’re focusing on platforms where that works well. When these gadgets start working well on Linux then great.

(3) As demonzla suggested above there is a stereotype that Linux users are more technically savvy than your average computer user. Hence it is assumed that a motivated Linux user could figure out how to download the code and build it.

Finally, it has occurred to me that it might be fun to try to maintain an Ubuntu/Debian PPA for highfidelity, however I’ve just been too busy to find the time to figure out how to do it. It is possible that HF would be interested in paying someone via Worklist to set such a system up. If it was mostly automated then I’m confident HF would be willing to host and maintain it.


#14

While the focus on Windows over other OSes can be frustrating at times for users like me, I fully understand the need for a business to cater to its primary markets first. :slight_smile:

The main issue with compiling under Debian-based Linux-es (and likely a good reason why packaging for them might be a non-starter for now) is the absence of qtWebEngine in the qt libs (due to Google’s approach of making Chrome a big nest of interlinked and difficult-to-separate-out support libraries, which makes packaging it up beyond many distos’ manpower capabilities*). My own solution was to go outside the package manager and install a separate qt build environment away from where the system keeps its official stuff. This is quite acceptable for beta software, IMO, but hopefully things will be better by release time**.

*the QT people have now gone to some trouble to untangle this mess, but the initial inertia seems to have stuck for now.

** When release time comes, if you can get it accepted into Debian/unstable I believe it should then naturally flow across to Ubuntu(universe?) and derivatives at their next release (snapshotted off D/U). May as well work at the bottom of the tree! :innocent:

…

For Ubuntu users, the KDE-Neon repos might be worth checking out as I am sure I read recently that they had qtWebEngine packaged for their own use.


#15

I thought the stated goal was to make an open source platform to create a virtual world web standard, basically?

With the closed platforms allowing less and less control for the user and it getting harder and harder to opt out of data mining as it gets designed into even the OSes it feels like better support for the open platforms are getting more crucial. Not from a market perspective, no. But if you achieve the goal of being the virtual reality web standard neglecting pre-compiled packages for the open platforms will lock out anyone who isn’t a computer wiz and still doesn’t want to support corporations whose business practices are shady at best.


#16

Most of what’s stopped one of us who could provide a linux binary package has been the state of flux with what Interface needs to properly compile/operate, as in dependent libraries. Now that QT5.6.1 is fully integrated and other dependencies have stabilized it makes more sense to invest some time in a packaged solution, but… that’s no small matter - for example, lets take a tour of distribution choices… Ubuntu 16.04.1, works great, but you need to either provide a dpkg for QT5.6.1 or point to an additional PPA or install from QT Installer manually. Fedora latest comes with QT5.6.1, but, oh joy - neither server side programs (domain-server and assignment-client) or Interface work compiled against its native packages - no errors seen, they simply don’t work. OpenSuSE Tumbleweed works, but, it’s a distro that aims to live constantly on the bleeding edge and may not remain viable as it evolves.

I’m already building server side packages for Ubuntu 16.04, automatically for both RC and DEV pushes and am considering doing so for Interface as well, but, if I did so it would be for one distro and one distro only - Ubuntu 16.04.1 64 Bit. The real problem is you can’t make everyone happy, what about CentOS, SuSE, Fedora, Mint, Debian and etc etc etc… figuring out how to make a complete chain to go from source to installer package automatically and reliably is no small task for one specific version of one specific distribution let alone trying to do so for others… So - let me as this, of those who want a binary package - how many of you run Ubuntu 16.04.1 64 bit?


#17

That actually sounds a lot like the horrors I faced with Maya and Mudbox. Not only did I have to go through the rigamaroo of trying to convert the rpm packages over to deb for Ubuntu but also manually tracking down which library links were broken and what paths were different on distro A versus distro B and… Ugh. So to answer your question on my end at least, I’m running OpenSuse Leap 42.1 on the desktop / interface end and Ubuntu 16.04 server on the box that’s hosting my domain. Both are compiled against the 5.6.1 tarball from qt.io while the rest of the dependencies were pulled in via package.

As a better solution though, I wonder if maybe just bypassing the whole packaging problem would be a better way to go? Instead gobbing out rpms and debs for each individual distro, maybe it’d make more sense to just toss out a tarball containing both the troublesome dependencies (ie - qt) bundled in with the build along with maybe a quick installer script to create whatever launcher shortcuts and hunt down any stray library links? Sort of like how the SL viewer, Firestorm, and even QT itself does things.


#18

Well the real solution is to use something like Ununtu’s Snap architecture as it, reportedly, can run on just about any modern distribution (Modern = in last 1 to 2 years max). It’s like Docker in that it containerizes all dependencies for a application and runs said container in Kernel’s “container space” infrastructure. But - I haven’t had time to really develop a workflow for creating that nor the need to do so. I do run my stack side in Docker containers, but, that’s mainly for enhanced ease of deploy.

I had thought about the “tarball solution” but, much like Firestorm which I’m used to using that way, it doesn’t really make it all that much easier for someone who just wants to press a button and have something installed… which is what many want. If I have some time this week I’ll add Interface building to my automatic build box and start making some Ubuntu 16.04 builds to see how it goes. I already have a apt repository with signed packages - a requirement for warning free Ubuntu 16.04 installing, so, maybe I can at the least offer that as it wouldn’t be a huge project.


#19

In theory QTWebEngine is no longer a dependency as it was replaced by QTWebChannel when HF moved to QT5.6.1, but, and this is something I’m still investigating, I think there’s an unintentional link time requirement for WebEngine still present when building for Linux - probably a cmake file that didn’t get properly modified to not spec webengine when building on Linux. Adding another todo to my investigations.


#20

Linux mint 18 uses the ubuntu 16.04 package base.

If I upgrade to Linux Mint 18, your ppa would work for me?