Linux is not ready for Steam

[darkphoenix22]

I think Steam does not matter if it fails, more development, more users. To ensure a successful market, you first have to stumble a few times. If more game makers make their attempts, albeit unsuccessful, to Nvidia and ATI are most interested in improving their drivers.

In addition to the current pace, the MESA project soon overtake ATI implementations. In just one year, development has been brutal (over 600 commits per month) and for most models of ATI, the OpenGL 1.5 is supported. When overcomes the barrier of the OpenGL 2.0 games may begin to have a decent alternative.

Well I think the video side is more than ready. It's the audio side that needs work.

[Remco]

Another option I did not mention : the /opt directory, but in that case, the binary will not be in the PATH, requiring a wrapper script in /usr/local/bin (that's my current solution). But its "Program Files-like" organization just makes me feel alien.

Nothing wrong with that, because you *are* alien. /opt/ is the accepted directory for unmanaged software. You should never mess with /usr/ if you don't use a package manager. /usr/local/ might also be OK, but /opt/ is the canonical answer.

[drag]

Nothing wrong with that, because you *are* alien. /opt/ is the accepted directory for unmanaged software. You should never mess with /usr/ if you don't use a package manager. /usr/local/ might also be OK, but /opt/ is the canonical answer.

There are standards developed in Linux for this sort of thing.


STANDARD PACKAGE FORMAT
========================

Standard package management == RPM. This is from LSB. Everybody supports LSB. Even Debian (and Ubuntu since it's based on Debian) supports the use and installation of RPMs.

If your using Ubuntu try a 'apt-cache search rpm' sometime.

But users won't typically like that. Just create a deb file.

Look at what companies like Opera do.

They generate rpms and deb file that, on a their website, a user can choose specifically what deb or rpm for their OS they want to use.

Does Opera provide a new build for each Linux system?

FUCK NO they don't.

They provide the same exact binaries for Ubuntu, Fedora, Redhat, Debian, etc etc. I've hashed them. They are the same binary. Only very old versions they provide different binaries and that is because a breakage in the C++ ABI that GCC and other folks introduced a long time ago. (yes C++ sucks balls).


STANDARDS FOR 3RD PARTY INSTALLS
===================================

/usr/local/ is a mess. Don't use that.
Don't install into /usr/. That's just stupid because distros consider that their playground and it will piss off your users one way or another and ruin compatibility.

For installation of software using tools like RPM, but it's outside the package management system you'll want to use '/opt'. That is what it's for... packaged 'alien' software.

You want to install your software to /opt/$app-name/ and you can use your normal Unix-style directory launcher.

Soo... say a intellegent approach for Steam would be like this:

/opt/steam-1.2-56231/

Put a symbolic link to /opt/steam/

then you'd have
/opt/steam/lib/
/opt/steam/common/
/opt/steam/bin/
/opt/steam/sbin/
/opt/steam/doc/

Etc. etc.

That way when people upgrade to a newer version of the application all you have to do is change the symbolic link. Makes it safer as users will never face a situation were upgrading steam breaks everything. They can always go back to a older version with a simple shell command.

Helps out a lot for support....


WHAT TO DO ABOUT YOUR EXECUTABLES
====================================

Then to launch your application you will not want to have a binary directly executed. You will need to use a script that will setup the environmental variables so your libraries and other do-dads will get correctly launched.

See 'man ld'


WHAT TO DO ABOUT PATH AND MENUS
==================================


Instead of doing something stupid like trying to stick a command in the users $PATH you will need to create various *.desktop files.

The .desktop files is a standard for letting the system know about your application and how to launch it.

To a 'locate gedit.desktop' or something like that when your using Ubuntu. The format of the file is very self-explanatory.

So you can add a few of these .desktop files in a fairly safe way directly to the user's /usr/ directory in the correct location.

The OS will pick up the presence of the files and then use that to generate new entries in a user's application launcher menus.

Say for steam you have:

steam.desktop
steam-help.desktop
steam-quicklauncher.desktop

Here are a few examples on how they get used.

PROBLEM: Need launcher on user's desktop
-----------------------------------------

Copy your 'steam.desktop' to their Desktop directory. It will behave similar to how shortcuts works in Windows.

USUALLY the desktop directory is going to be ~/Desktop, but it's configurable. Especially for internationalization support it's going to be popular to have that directory be named different things for different languages.

What you want to do is use this command:

xdg-user-dir DESKTOP

That will deal with a user's desktop.

If xdg-user-dir does not exist then your dealing with a shitastic Linux distro and it's not really worth your time fucking around with because it's broken or a user does not care about compatibility.

For people like that just use ~/Desktop if it exists and otherwise just stick it in ~/

They will probably bitch and moan about random problems with *.desktop stuff or they won't understand what your trying to do, but you can safely ignore them.

xdg-user-dirs are:
DESKTOP
DOWNLOAD
TEMPLATES
PUBLICSHARE
DOCUMENTS
MUSIC
PICTURES
VIDEOS


PROBLEM: Need to provide QuickLaunch-style icon in the systray
----------------------------------------------------------------

So that requires having a program getting launched that starts a systray instance (to do that in KDE and Gnome is a bit different, but it's in the process of being standardized right now)


To launch applications automatically when the user logs in stick your *.desktop file in $HOME/.config/autostart

You may have to make that directory.

So that would mean something like taking a symbolic link from were steam-quicklaunch.desktop is stored and putting it into:

~/.config/autostart/steam-quicklaunch.desktop


All decent desktop session managers will launch that automatically from now on. XFCE, LXDE, Gnome, KDE, for example should all handle that the same.



PROBLEM: Want to launch browser for HTML readme and links to online FAQs and links to support forums, etc
--------------------------------------------------------------------


Do NOT try to run a command like 'firefox'. It will probably work, but it's still a stupid thing to default to.

What you want to do is use 'xdg-open'

That will detect the mime-type of the file or decipher the URL and launch the appropriate application for you according to user's preferenecs.

So something like:

xdg-open http://www.google.com/

Will launch the user's preferred web browser.

xdg-open music.mp3

will launch their preferred music player

etc etc.


If the system does not support the xdg stuff then it's shit. You don't have to care because it's going to be impossible for you to do the right thing. Just launch firefox in that situation.



HOW TO DEAL WITH USER CONFIGURATION FILES
===========================================


This one is easy.

So you don't end up with a shitload of different ~/.??* files the standard for configuration files is now:

~/.config/$app-name

Blows your mind, right?

So you will probably want to use something like

~/.config/steam

That's it. It's your directory; you can do what you want.


Now if you want to store user specific files....

Say you want a place for your application to store downloaded content.

You will want to use
~/.local/share/$app-name

===============================


And there is a bunch of other crap like this to.

It's all very simple and makes a lot of sense, but it's not common knowledge yet, unfortunately.

[Remco]

They provide the same exact binaries for Ubuntu, Fedora, Redhat, Debian, etc etc. I've hashed them. They are the same binary. Only very old versions they provide different binaries and that is because a breakage in the C++ ABI that GCC and other folks introduced a long time ago. (yes C++ sucks balls).

This must be why I couldn't install UT99 some time ago. It claimed that the installer wasn't an executable.

Instead of doing something stupid like trying to stick a command in the users $PATH you will need to create various *.desktop files.

I wouldn't say putting the startup script somewhere in your path is a bad idea. *.desktop files don't work in the terminal. A usable terminal is a major advantage of a Linux system.

[Tomservo]

I don't see how audio is an issue. Practically all newer and not so newer games resort to software mixing anyway.

The only capabilities a game needs to have access to is the ability to set an output mode (frequency, bit depth, channels), get the playback position and just stream the audio. Any functionality beyond that is unnecessary. If there's a Source engine for Linux, it would do fine with most distros by using small wrapper libraries that handle either native Alsa or Pulseaudio. I think both implement the needed caps in uncomplicated ways.

[chaperon]

In addition to the current pace, the MESA project soon overtake ATI implementations. In just one year, development has been brutal (over 600 commits per month) and for most models of ATI, the OpenGL 1.5 is supported. When overcomes the barrier of the OpenGL 2.0 games may begin to have a decent alternative.

Except that the norm is now DirectX 10 and companies are looking toward DirectX 11. To be more precise, all AAA titles are tailored for XBox360 hardware, which is between DX10 and DX11. You need at least OpenGL 3.0 to compete with that (Please, do not feed the troll).

[darkphoenix22]

I don't see how audio is an issue. Practically all newer and not so newer games resort to software mixing anyway.

The only capabilities a game needs to have access to is the ability to set an output mode (frequency, bit depth, channels), get the playback position and just stream the audio. Any functionality beyond that is unnecessary. If there's a Source engine for Linux, it would do fine with most distros by using small wrapper libraries that handle either native Alsa or Pulseaudio. I think both implement the needed caps in uncomplicated ways.

It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.

[Remco]

Except that the norm is now DirectX 10 and companies are looking toward DirectX 11. To be more precise, all AAA titles are tailored for XBox360 hardware, which is between DX10 and DX11. You need at least OpenGL 3.0 to compete with that (Please, do not feed the troll).

Luckily, NVIDIA and AMD provide OpenGL 1, 2, 3 and 4 drivers. Games will always support multiple renderers, and the OpenGL 2 renderer won't go away for quite some time. So, for the small percentage of people who don't run the proprietary drivers, the games will still work.

[Remco]

It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.

For games that need direct control over latency: http://www.pulseaudio.org/wiki/LatencyControl

[WhiteDwarf]

It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.

From my experience, the problem lies entirely in PulseAudio's ALSA compatibility layer. It just doesn't tend to play nice with lower latency ALSA applications, even those that stick to the "safe ALSA subset". The same application with a PulseAudio backend, with the same latency settings, will not have issues. For example, the audio problems many users were experiencing in HoN disappeared when the PulseAudio backend was added.