Yea, I like the FHS way of handling things. It allows much finer control and security. When things are in /usr, it's automatically read-only for everyone but root, which means that you can be confident that the contents won't be changed without the administrator's consent. User-specific configuration goes into /home, which means that each program automatically has unique configuration for each user. ~/.config is the central place where each user can change the configuration by hand. ~/.local/share is where their logs and saved games are kept. And having all libraries in /usr/lib allows for more efficient use of both RAM and SSD/HDD space. It's also extremely nice once you do a fresh install, as even though the base system gets upgraded, you don't lose any configuration or progress in your game. By having each program be self-sufficient, you throw away these advantages for the sake of some situational convenience. So it makes sense to follow the FHS.
Why do you need games to be portable, anyway? If you purchase a game, you get to play it on all the computers you own, anyway. Installing it shouldn't be a problem. And if you wish to play it on someone else's computer, well, you're not supposed to do that to begin with. Ask the owner of that computer to install it, instead; have them purchase it if they don't already have a copy. In fact, the FHS makes it much nicer to allow others to play your games on your computer: simply create a new account (or use a guest account), and you can be sure that whoever you allow to play your games won't mess with your configuration, won't delete your saved games, and won't deal any harm to the system in general. Or you could set ~/.config to be read-only or back it up, and then restore it after use, if you wish to keep both save files in one place, but don't want any configuration changes. And that works for all games following the FHS at once.
Last edited by GreatEmerald; 07-14-2013 at 07:03 PM.
When you get a game from the humble indie bundle, it usually just thorws everything in /opt. Steam has its own copy of sdl in ~.steam/something, and there is no game standard. In practice, you want portable game state, which includes saves, configurations, versoning, etc - so you can backup easily, and quickly deploy, your game state. Likewise, you want to control where game data and binaries go. But in security terms, writing over a game executable isn't that much of a problem (and you probably shouldn't make a .elf writable anyway).
Games consistently want to drop everything in one folder, so I'd rather the FHS support that than trying to pigeonhole the shared applications behavior on game developers.
It is also annoying how game saves end up in hidden folders a lot of the time, but because ~ isn't really well thought out for this use case, you end up either polluting ~ even worse. The best scenario would be to agree on ~/State or ~/Save being the user-based save directory for game state, and you write into a subfolder like ~/Save/doom or ~/Save/hl2, but nothing is really followed conventions wise across Linux gaming.
I would hope he has also contacted the SDL devs about updating the doco and has not just left it at updating his slides.
To respond to the bit about source ports throwing data around randomly (I work on ZDoom, ECWolf, and Zandronum): From my point of view the file system standard is actually quite good. Following it correctly can reduce support headache a bit since I don't need to worry about explaing /path/to/where/you/installed/product/x and can instead just give ~/.config/product/x or something like that. But the reasons why things are as they are has already been explained.
The problem isn't so much with supporting the games themselves (although I can see how DLC could be a minor issue), but for source ports there's no standard for how to handle third party shared data. Especially in the case where that data could potentially be shared across many ports of the same game. This is understandable since the standards were designed with commercial software in mind, which for obvious reasons won't depend on the user installing another company's data. All of the ports I work on allow specifying a custom location in the configuration file, so it's technically up to the user, but in the installation instructions we put the easiest default case (in the same directory with the configuration file).
Other than that issue almost everything else is covered. The binary and any supporting 1st party data go into a shared directory (Ubuntu specifically requests that /opt/packagename be used), and then a symlink or bash script is installed to launch from $PATH.
I do agree that home directory clutter necessitating hidden directories is a problem, but that's what ~/.config and ~/.local could have solved. Unfortunately someone decided they should be hidden as well. OS X is the only platform I'm aware of that got this right (although it still has no real standard for 3rd party data).
Keeping savegames in the game directory doesn't solve anything. We already had that in the last century. Every game had one of the things like
- a 'save' subdirectory where it kept savegames
- savegame0.sav, savegame1.sav, etc along other game data
- a 'profile' subdir for userdata
- a randomly named file with a savegame that was hard to tell from the others, placed along other game data
- a milion other solutions
And I'm not even talking about the problems with file permissions!
What we have currently is something like a transition era between the old bad and the new good solution. I guess it'll take another 10 years for all games and apps to use the .config and .local/share directories properly (and %appdata% on windows), but we'll get there.
True, it's too bad that .config and .local are hidden. Well, .local wouldn't be that much of a problem, as you typically don't need to manually do anything in it, aside from finding the game logs for debugging, but .config is a problem. Same thing with .wine, actually. However, it could be solved in file managers by adding a fast way to get there. For example, in Dolphin:
You can add that manually, of course. But it would be nice if it was added automatically.
Never liked the idea of having the different folders as in the FHS.
Like things like Gobolinux filesystem.
Liked the idea of having application folder with subdirectories with what is now the topdirectories.
Fedora and a few other distribution are already changing their file system structure somewhat away from the classical FHS structure.
The %appdata% has a subfolder structure with the application name in it.What we have currently is something like a transition era between the old bad and the new good solution. I guess it'll take another 10 years for all games and apps to use the .config and .local/share directories properly (and %appdata% on windows), but we'll get there.
We need a way to structure things better than now, better than the FHS stuff.