Figured I'd do a quick updated, as it's been nearly a week since my last. Here's a quick recap of the technical issues we've resolved, some of which I didn't mention last week as the post would have been too long:

Needed to write a basic linux bootloader (the main executable)

Crash immediately after attempting to login

Login failed due to SSL issues

Every button thought it was being clicked twice

Dialogs were being drawn with multiple frames

Buttons couldn't be activated by [Enter]

Offline mode would crash

Menu button was buggy

I wasn't mentioned on the 'About' page

Avatar on the main form was out of proportion

A few other minor nagging issues

We also spent a significant amount of time working on porting CEF (http://code.google.com/p/chromiumembedded/) to Linux, which is mostly complete and working with both GTK and wxWidgets. Thanks heaps to Marshall Greenblatt for his continued support.

Here's some nice shiny examples of the UI to keep you Linux gamers and Desura enthusiasts on the edge of your seats.

Nearly fully functioning login form:

Main form sans web interface (Yeh tab and button themes are still a little buggy):

CEF running in a wxWidgets test application:

Over the next week or two we plan to smash head first through quite a few milestones, and we'll definitely take screenshots as we go and keep all of you guys and girls in the loop.

I also loved all the feedback from the first post, and the insightful and supportive comments. As I said in one of my replies; sorry if we miss you now and then, there's a lot to keep up with!

To finish this off, I thought I'd say there's a few news sites that caught wind of the Linux screenshots, and a few commenters who ran with the wind and compared the 'leaked screenshots' to the similar Steam incident. I don't know what those guys over at Valve are up to, but let me confirm this now: we're definitely working on Desura Linux, and I'm doing everything in my power to make it happen soon! For those of you that doubt there's a strong enough Linux gaming community to justify it, just go have a look at the Humble Bundle graph (http://www.humblebundle.com/). Not only are these guys amazing developers who make great games, but they are doing some great things to support multi-platform DRM-free indie gaming!

Until next time,

Keith Poole
Linux Engineer / NCP
Desura

My quote of the day: "I am so clever that sometimes I don't understand a single word of what I am saying." - Oscar Wild, RIP

Don't know if you can (already) tell us about this, but how will you handle game installations? Will you just put all games and other data in a directory in the users home? (that is also what I would like most)
And (even more uncertain if you want to tell about this) are you already talking to game devs/publisher about releasing linux version through desura and are there some planning to do so, right from start?
:)

Correctly it should be "/opt" or "/opt/games". ~home should not have applications installed into (one big rule-breaker wine does) unless it is in a production environment where the user has no root access.

I would also highly prefer, if it won't require root at any point - I already have package manager on the system, don't want to have another one even if it is made by such nice people. Personally I already use similar approach suggested above (unpack all games to ~/apps/games as normal user and rung them as normal user also, I even don't like, when the game is packaged as rmp or deb - for me the game is another kind of stuff than system packages coming from repositories), but would agree, that this might be a security issue, cause game binaries might be infected by some harmful program if the user has full write access to the executable file. Probably a good solution could be to create special user "desura" with write access somewhere to /opt/desura/games - this would require root access once during installation (only to add new user and create /opt/desura dir with required rights)... but such solution would require some kind of desura daemon, which would be started with the rights of "desura" user name and would handle install/remove requests from the desura gui client which is running as normal home user.

Yes, this dialog is rather convenient, but I think that if less apps require root password it is better; and also giving root password to all users even on the home system (for example to children who might want to use desura to download/update games) is also not a good idea.

and by the way, there is also an important nuance - 2 users on the same machine might want to have different desura accounts with different set of installed games and it would be hard to use same folder for 2 and more users without subfolder subdivision. Generally, it might be ok, if they share same game installed in one folder, but probably there would be conflict usecases for example if one user wants to patch the game and other does not want.

This is only a problem if the game in question fails to respect the FHS properly. Applications (and thus also games) are separated into 3 main parts: configuration, static data and dynamic data. Configuration goes into /etc (gloabl) and ~/.config (user). Static data is what stays the same in the game at all times (only changes when updated but otherwise the same). That goes into /opt/games (for apps /usr/shares). The last part are dynamic data like for example run-time caches and alike. These go usually into /tmp or ~/.config (depending on the how the data is structured and if it is persistent or not like logs). Typically windows games though smash everything into the game directory which is wrong. Even Windows7 knows this and UAC boots you if you don't do it properly.

So for the Desura case user accounts are under ~/.config/desura and are unique to the user. Games working according to the FHS work properly with multiple users as their config is under ~/.config but their static data under /opt/games (managed by Desura). Only problems are FHS-deniers... and unfortunately a bunch of games are. These buggers would have to be installed under ~/bin to avoid problems in multi-user environments. That though is not the problem of Desura but bad game design to begin with.

My engine and launcher by the way respect the FHS properly both on Linux and Windows.

EDIT: Concerning patching, this could be solved using two different desura directories under /opt/games one for each user. But patching or not is anyways a problem under Windows Desura if you use multiple mods so the problem has to be solved with potentially different root directories in Desura anyways for the "trouble" cases.

Firstly, FHS is something that I really do want to adhere to, and it bothers me when applications don't. The conflict of interest here though is similar to what benderamp said, where users may have conflicting thoughts on game revision, patch level, etc, and how you mentioned that occasionally multiple mod's cause issues.

We have a specification that we're looking at adhering to, that A) doesn't conflict with FHS, and B) resolves most of the issues. I'll probably post more about it in the next blog. The key is though that FHS is more in the direction of "don't put files in these directories if they don't belong" as opposed to "files of this type _have_ to go in this directory".

More details will be announced in time though, and thank you very much for your concern, comments, and responses!

Oh and I also forgot to mention that the 'desura' user/group, and the 'background daemon' suggestion is something that we looked into at the start as it's similar to how we do it on Wnidows, but we have mostly discarded. Our/my reasons are that 1) Most users won't want to ever deal with needing root/sudo access, nor should they, 2) The less things running in the background the better (or at least as far as I'm concerned), 3) Converting the Desura service to run as a daemon, or creating a new program to run as a daemon, and handle this functionality, would be timely, and 4) It may not be necessary at all with the path we're taking.

There is no problem with running a background app. The key is proper use of sleeping. A background app in proper sleep east no processor time nor does it yield troubles with the user. Desura is especially an app which can be put easily into sleep mode while in the background as it does not have any real-time operations(like steam friends crap for example. The only thing is updating but it's all fine to not sleep when an update is downloaded and going to sleep if there is none. An additional daemon is anyways not a bad idea to protect against crashing games. I'm using an additional launcher binary alongside my engine launcher which is only used to launch the game. This way if something crashes only this slave launcher goes down not the main app. But this can be chosen whichever way.

Regarding installation, this is a hot point and I'll reply to it a bit further down the page (after other similar comments). As for the Linux game publishers though, this is something Scott is handling and it's definitely an important one! Quite a few of the games we have up already do have Linux builds though, and so they'll most likely be the first ones to appear in the store.

Sure, you can say there is little point in building a digital distribution system on Linux because there are few games worth distributing, but then why should a game developer build a game on Linux if there are easier ways to deploy them to other OS (eg steam for windows)

Obviously, for indie or commercial games to ever become a success on linux, either the developers or the distributors will have to step forward and break the cycle.

So it's really nice to see people like ModDB doing just that, and they should be supported in what they are doing because I for one really hope they succeed and Linux can see the wide choice of titles that Windows already enjoys.

Good reply, but I don't 100% agree. I think there are more than just a 'few' Linux games out there, I just don't think they are well known or advertised as there's currently no 'unified' distribution hub for Linux games (or at least none that I know of). Also a lot of games are written with cross platform libraries these days such as SDL, which makes porting a lot easier.

At the moment, each Linux distribution has it's own package management system, and then each game publisher or developer has their own website, and there's a few stragglers inbetween. We're trying to encompass all of that and make it easier for developers, publishers, and gamers alike. Not to mention that making the Linux game distribution process easier will most likely bring more Linux games out of the shadows!

Off the top of my head, some good Linux games:
Dwarf Fortress (not well known, but warning: highly addictive once you learn all the ASCII symbols!)
Trine
Lugaru
ShadowGrounds games
Aquaria
Braid
World of Goo
Osmos
Minecraft
Penumbra games
Nexuiz
Wormux
FreeCiv
FreeCol
Urban Terror
Machinarium
Chromium BSU
0 A.D.
GLTron
Armagetron
Warsow
Revenge of the Titans
Cube 2 - Sauerbraten
Unreal Tournament 2003/2004
And maaaaany more (check out Askubuntu.comEn.wikipedia.org and Lgdb.org)

This has been another hot topic, not just here but on a few forums that I've been following (http://ubuntuforums.org/showthread.php?p=10926858#post10926858 being the main one).

I raised the issue with the others this morning, and I'm waiting for a reply and to see more of what the community thinks. Personally I can understand how people grow attached to their theme or the consistency of widgets across applications (for example I set Chrome to use the system theme and widgets ;)), but there may also be avid Desura users or gamers migrating from Windows that don't want to budge from the theme. My best guess (but this isn't a definite) is that there'll be an option to switch between system/GTK theming, and Desura theming.

Just thought I'd quickly say a big thank you to all of you for your continued feedback, positive attitude, and support.

Please also don't have a go at anyone if they're being negative, we want honest feedback and even negativity helps and gives us a clear idea of what people are thinking, and which direction to go in! If you are going to be negative, please try to make it constructive too ;)

The game should not be installed in the /opt or under the /usr directories. There are a huge number of reasons why games can and *MUST* be treated differently than system software.

First, nothing against any of the game developers but their games/packages are not open for review and we have no idea what kind of security nightmares they might be opening up or how secure they actually are. We definately do not want games running SUID or as root or anything like that, which could compromise the security and integrity of the system.

Second updates are not handled well unless every user has root access to install new updates for every game. At that point we are back to point 1.

Third if your partitioning your Linux drive properly as is recommended, then your root directory and everything but home should be in one partition that is about 20-50 gigs. You home directory should be the rest of the space and should be the largest partition. If your installing a bunch of games in the /opt or /use/share or /usr/local then you will quickly run out of room. You never want to run out of room on your main partition, especially when you are doing upgrades.

Fourth if your sharing your computer with a family some might not want their kids to play everything Dad does. If you install it in a public area then you have to start messing with special groups and permissions to keep the kid out but let Dad play.

Fifth I would assume that Desura is going to handle keeping the games updated. If they are out in the system area it could be confusing or in theory could cause a problem with other package managers. It is simpler and less hassle to install the games into the users home directory.

Actually /opt is for software (including games) which are "optional" and thus not required to be managed by a package manager. Many 3rd party tools like Acroread and company go there including stuff which updates. You can put games into home but this is a backup nightmare. Imagine if you have to backup tons of game data each night which can easily be restored by reinstalling then you know why games in home are a pain. /opt is designed for this and in any sane configuration /opt has to be of at least 20+G. This also deals with the security issues. Anything under /opt/games is under user control. He is responsible to trust or distrust what is located there.

You don't normally back up huge amounts of the main system. There is no point since you can simply reinstall the package using your package manager. The config files are about the only thing you need to worry about (besides mail) and by backing up /etc you will catch most of them. The main area you should be backing up is the users files in the /home directory. If you install the games there (where the largest amount of space is) then backuping up the /home directory will automatically back up your games.

If you use the Loki/Mojosetup installers it will prompt you asking you where you want to install it. If the Desura client runs a special version of them (installers) and adds to a config file where each game was installed for update purposes then it wouldn't matter where it was installed and people could pick whatever they want. You could even have it prompt for sudo password if it reads a game is installed anywhere other than /home. You could probably write a wrapper for Mojosetup where you don't need a custom version you just pass it all the info and append to the location file.

I really think you guys need to reach out to the Indie developers out there and get a large number of Linux games for sale on the system. I am so tired of the lip service and the crap that Valve gives to Linux. I would love to see Desura eat Valve's lunch. I would also love for you to show Valve how silly and stupid they have been about leaving so much money on the table by not supporting Linux in any way, other than the required Linux game servers.

If you need to know who contact, I have a huge list of Indie developers that also offer Linux versions of their games. Not to mention I have a few commerical give aways of nice games by companies that don't do Linux anymore or aren't around anymore, but they are free. Let me know if you need some help.

I really want to see Desura support more than 2000 characters for posts. I guess I type too much info, but I am hitting the 2000 character limit often. Maybe there should be a real forum or something for all this that allows longer posts since I type too much. LOL

I must say, excellent work squire. I keep jumping back and forth to the desura website to see if any news about the linux client show up. I must say, you have made my day with this post. :)

On the topic of where to place games, I would much rather they went into the /home directory. Since I place all my games (from humble bundles, minecraft, etc) inside of ~/apps/games anyway. I don't feel that games should ever get the root treatment, since games are not regular applications - but this is just my opinion on the matter.

As far as UI goes, I'll be happy with anything you guys come up with - all I ask for is a nice clean interface to work with. From what I've seen of the windows client, you've done a great job with that... and I'd be happy to use a direct clone of what that interface has to offer.

As for updates, it would be nice if version control could be done from the interface. E.g. an option to select if updates are stored in their own folder (~/apps/games/game_name/0.1, ~/apps/games/game_name/0.2, etc). I don't mind if all this does is copy the existing folder into a new folder and patch the new folder. I hope my description is clear. This way, mods/users could also be assigned to a version number too. Sure it'll take up more space, but would benefit all - and the option can be switched if needs be. Obviously this wouldn't be the default scenario, but would be a nice option to have.

The next blog post I'm going to cover game installations a little, as it's been quite a hot topic and so we've had to make a decision and put our foot down (in an attempt to make the majority happy and keep things manageable).

As for updates though, I don't think that sort of segregation between updates would be possible for all if not any games. A lot of updates are just small patches, not a whole other copy of the game. It is something that will be kept in mind though, and we appreciate feedback and suggestion of new ideas :)

I will apologise first, since this might end up being a long post. (P.S. I also had to chop it down into 2 due to the character limit)

Thanks for your reply. Also, thanks for commenting on my pingu avatar. He has always has been one of my favourite character from my childhood, I also think he looks cooler than Tux - but that's just my opinion :).

I will look forward to the upcoming blog post about the ideas you guys have for game installations. Can't wait to see what you guys have cooked up, I'm sure whatever you guys come up with will work best for everyone as a whole.

Just an interesting though, to add on to my previous comment about keeping revisions. I was discussing it with a friend, and when he read my post (along with your reply), he came up with an interesting idea which would solve having to keep 2+ copies of a game/file/folder - and shouldn't be too hard at all to implement:

1) First method would be to have a master branch, i.e. the initial install of a game, this would serve as the base for updates later on. When an update needs to be done, simply create a new directory for the new patch, then recursively go through all the folders of the master directory and then "mkdir -p" all those folders. Which would create a hard-link to those directories. Then after that, recursively go through all the files and then "ln" all those files. This way we have a hard-link to all the files. During patching of the game, all that would need to be done is, unlink/remove the files and then replace with the new file. That way, all we have are new copies of the files, plus links to existing (unchanged) files and folders. Thus we aren't wasting hard drive space, and we also have 2+ versions (essentially) of the game - which would solve modders (and users of mods) problems.

2) The other method, if desura isn't actively doing the updates itself (relying on the games own update methods, or own patcher application), is to do this process in reverse. Sure it might