Use appdata/home folder to hold games and config

[Jookia]

That way Desurium would just be an executable, and avoid security issues. Oh, and piracy. I don't see this happening for a while, this is just a note.

[TheSiege]

I want to second that notion and add a few arguments: Desurium is installed without an auto-updater therefore having only one executable helps to bring it to major distributions through the package-manager, this would also help with install-deps messiness. It would help port the application to Mac as they have a much stricter seperation.

[ssokolow]

@Jookia What does any of this have to do with piracy?

[Jookia]

Well, assuming you're in a multiuser system, other users won't have access to your games assuming your have your home folder locked down.

[ssokolow]

So it's not really piracy it's preventing. It's just preventing naughty siblings from swiping your CD-key because they got theirs banned.

Aside from that use case, I'm not sure I've every known someone who was anything but annoyed by how hard Steam makes it to share games with your siblings.

[karolherbst]

but steam games need a shared lib from steam to run (which will check your account). On Desura there is not something like that.

But I think it's important for security that not every user is allowed to write system wide binaries (change binaries to annoy the big brother would be funny, but putting maleware there instead, would not).

[Jookia]

Ironically I've been pretty pissed at Steam for not letting my rip my Doom files for emulation.

[ssokolow]

@karolherbst Ahh. I hadn't thought of that because my Desura is in ~/opt/desura and the default Ubuntu umask and group settings render them readable by other users but not writable by them.

[Protektor-Desura]

Just as a side note. Eventually Desura is going to offer the option to validate installs on the game side to make sure the user actually bought the game. It will be like what Steam offers. It isn't going to happen for awhile but you might want to keep it in mind. Personally I will push for less DRM but for some developers without this option it is a deal killer.

[ssokolow]

As long as games with DRM are clearly marked and the DRM blobs are in the games rather than the client, I'm fine with that.

"Clearly marked" because, even now, I still buy most of my games from GOG.com or Humble Bundles because I worry about accidentally buying something off Desura which requires a CD key for more than creating an account on the online matchmaking service. (For example, with GOG.com, the worst that'll happen is that I won't buy a game because the message doesn't confirm that LAN play is exempt from the multiplayer key system.)

"DRM blobs in the games only" because I have a very strict policy about closed-source code on my system. Only games, Flash, Opera, and my nVidia binary drivers get exceptions.

(Games get an exception because I recognize that "disposable code" like games has yet to develop a viable business model based on open-source development. Opera is used only to test my creations. Flash was grandfathered in prior to Apple taking a stand against it. The "nouveau" reverse-engineered drivers don't yet do decent 3D and TwinView dual-head on my GPU.)

This policy is actually why I became a member so long after discovering Desura with the release of Humble Bundle 2. I dropped by your site, noticed the client was closed source, and put you out of my mind until the Desurium announcement.

[Protektor-Desura]

DRM is something that Desura really doesn't have a say about. We can only suggest to developers to use as little DRM as possible but it is up to them how much DRM they end up using.

[ssokolow]

I understand that. I'm just saying that I don't want to accidentally break my DRM boycott because Desura didn't warn me clearly enough about what I was buying.

[Protektor-Desura]

I will say right now the only things we have allowed on the system are no-DRM or CD-Key/Serial-Number DRM with one exception. The exception we didn't know about until after the game was launched and has since been addressed.

I don't have a problem with the binary running from the system dirs and installing everything under the user's home directory. My only issue is for the non-community version it needs to be able to update itself rather than rely on package managers/volunteers to update the client. The exception to this might be if Desura could run RPM and DEB repositories and some how get them added automatically or easily to the system list of repos so it would stay updated.

[ssokolow]

I know that, on Ubuntu, adding a repository to the system package manager is as simple as dropping a file into /etc/apt/sources.list.d and running a command to add your signing key to the keyring.

As for doing all that as part of installing the .deb you want to keep up to date, Google Chrome's .deb was doing that last I checked, so you could unpack it and look at its install scripts.

[naryl]

Protektor, you can add one more field which will list restrictions forced by game's developers. Only three options needed: free/open-source (no restrictions), proprietary (restricted modification), DRM (restricted copying).

And of course Desura should allow filtering games by this field. It will make it more comfortable to use but may put off some DRM-fans among developers.

[Protektor-Desura]

If it is free doesn't automatically make it open source so that category doesn't really work. I would think "No DRM" and "DRM Key" and "DRM Auth" would be the only things needed with "DRM Auth" not available from Desura right now. You could put any games that "phone home" so to speak under the "DRM Auth". Games that require an account on dev login server for multiplayer I would think "DRM Key" would be enough or you could use "DRM Auth". All of this also assumes that the higher ups at Desura would add a DRM field.

Now we are way off topic of the discussion of directories.

[naryl]

Protektor, The first category means "modification and copying allowed". It doesn't have anything to do with cost.

EDIT: Right, it's offtopic. Create another issue?

[ssokolow]

@naryl I think Protektor's point is that it should be "libre/open-source", "proprietary" and "DRM". The word "free" doesn't distinguish between freedom and cost and, in the current Desura UI, is already in use to mean "gratis".

[Protektor-Desura]

I'm opening a new ticket for DRM discussions

[ssokolow]

@naryl: That would be issue #93.

[Jookia]

Back on topic: Should we try and move Desurium to store things in home directories and whatnot instead of a central location?

[TheSiege]

Yes, yes please! If you don't like it please give us at least a build/run-time option to do so. This is a very major problem for me, as the distribution I have (gentoo) already has a good working ebuild which just has this problem with the central location. If done I belive major distributions would not have a big problem (that is because the port to cmake works very well on linux) to get it into their repositories.

[ssokolow]

I think so. The current behaviour makes sense for manual installs to somewhere like my ~/opt but doesn't really make sense for system-wide install.

(I was surprised when I heard that Desura installs into Program Files on Windows, given the current state of this bug and how Unix-like the Windows filesystem layout has become in recent versions.)

[Protektor-Desura]

I'm not sure I would put the downloaded games under a . directory though. I think ~/desura/ should be the default location for all per-user games. It would make it so much easier for new Linux users to find things if they want to setup "shortcuts" or whatever.

[ssokolow]

For the love of god, please don't force me to either wrap yet another program in a script which lies about $HOME or maintain my own build.

It's bad enough that SOFA Statistics, Crayon Physics Deluxe, and StepMania try to clutter up my home directory with folders I don't want to see.

Even the current situation of having all of Desura in a single folder I can squirrel away wherever I want is preferable to that.

[karolherbst]

that's a general point I miss under Linux: where to put configurations and other stuff. Because I came from Mac OS X I'm a bit accustomed to find all these stuff in ~/Library/Application Support/{AppName}/ (for runtime and user specific things such as skins or databases) and ~/Library/Preferences/{domain shortcut like org.desurium.plist} (for settings).

Anyway for the Mac OS X port this will be necessary, because otherwise it would be "bad style".

On Mac OS X Steam puts all the game data in ~/Library/Application Support/Steam/ not in the steam application as it is on windows.

[naryl]

karolherbst, there's a Freedesktop.org standard for it. And a library. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

EDIT: Removed some rant about Desurium not following XDG.

[Jookia]

Desurium implements the XDG basedir spec for configuration files and cache/temp files.

[ssokolow]

Ahh. I'd wondered how OSX did it but never got around to looking it up.

The big thing I'm not sure about is whether it'd be better to count downloaded games as user data or cached data. It's a bit tricky:

• ~/Library/Application Support sounds like a mix of XDG_RUNTIME_DIR and XDG_DATA_HOME
• XDG_RUNTIME_DIR is basically a user-specific version of /var/run and the spec explicitly says not to put stuff bigger than PID files, pipes, and sockets in it because it could be a RAM disk.
• XDG_DATA_HOME is for user data that, if you lost it, would send you cursing and scrambling for your backups, which makes it roughly equivalent to AppData\Roaming on Windows. (It's essentially ~/Documents for when programs don't think a Save/Open dialog is appropriate.)
• On Windows, stuff that would be expensive to sync or backup and easy to re-download or re-generate (like game binaries) would go in AppData\Local, but there's no exact equivalent on Linux because the XDG basedir spec has no explicit provision for application binaries installed in user home directories. (I suspect they considered it out of the scope of the spec.)
• If it weren't for the fact that it's so intuitively, obviously wrong, I'd say to put the games in XDG_CONFIG_HOME because everything else about its description fits. (It's for data files that may be specific to a given piece of hardware and which, if you lose them, it'll be annoying to re-acquire, but you won't go running for your backups.)
• Depending on how the ecosystem of Linux tools equivalent to CCleaner has evolved, XDG_CACHE_HOME might be the place to use. It's the closest match and the only concern is how likely users are to naively empty it.

That basically leaves these options:

• Put downloaded games in $XDG_DATA_HOME/desura and risk getting cursed at by users whose backup utilities or profile-roaming solutions blindly sync what could be gigabytes of unnecessary data.
• Put downloaded games in $XDG_CONFIG_HOME/desura and risk getting cursed at by users whose local backup utilities blindly version it. (Caution: Some people use git or another VCS to backup ~/.config)
• Put downloaded games in $XDG_CACHE_HOME/desura and risk having them blindly flushed by an over-eager CCleaner-alike. (This may or may not happen. I'm not up to date on the situation for Linux cache-clearing tools.)
• Tastefully extend the pattern the XDG basedir spec sets up in order to resolve this oversight. (This is probably the option I'd choose. I already have Desura in ~/.opt/desura and I'd say that's probably the closest I can come to matching the "roughly replicate the global directory structure" spirit in which the basedir spec's directory names seem to have been chosen)

If you do go with that last option, just keep in mind two things:

• If you do amend the basedir spec, you'll want to also discuss it on freedesktop.org to try to get some consensus and inclusion in the text of the spec.
• While you and the freedesktop.org crowd are arguing details, you'll probably want to listen on an environment variable like DESURA_GAMES_DIR to provide an equivalent config point to the XDG_*_DIR and XDG_*_HOME variables.

[Jookia]

On my branch (https://github.com/Jookia/Desurium/tree/80) I've done the XDG-route, with XDG_DATA_HOME, XDG_CONFIG_HOME and XDG_CACHE_HOME for respective purposes.

[karolherbst]

nice :)

[Jookia]

Fixed.

[ssokolow]

Is there any kind of script or guide for moving pre-GPL data files to their new locations? I'd really rather not have to manually re-add all the non-Desura games I've got in my Play list.

...or re-download the Desura-provided ones. (Last I checked, Desura wouldn't automatically resume the install process after a crash or accidental quit the way I've seen my brothers' Steam clients do.)

[Jookia]

The guide is to dump the desura/data and desura/bin folder contents in to the desura folder, and move the desura/.settings folder in to ~/.desura, or ~/.config/desura if you're using the XDG thing, or desura/config if you're using the portable thing. Games go in ~/.desura/games or ~/.local/share/desura or desura/games.