Latest Comments

Quoting: liamdawe

Quoting: maokeiLover the art style! This could endup being a really cool game im not sure If I want to contribute yet though 88k is the streetch goal for Linux, "Hopefully" it will be reached otherwise it would be a waste of my money and time.

Well their current trending is to over 200K, so once it reaches 88K be sure to chip in ;)

I can garantee you that I will :) I just wanna vote for Linux with my wallet :)

View this comment - View article - View full comments

Quoting: maokeiLover the art style! This could endup being a really cool game im not sure If I want to contribute yet though 88k is the streetch goal for Linux, "Hopefully" it will be reached otherwise it would be a waste of my money and time.

Well their current trending is to over 200K, so once it reaches 88K be sure to chip in ;)

View this comment - View article - View full comments

Lover the art style! This could endup being a really cool game im not sure If I want to contribute yet though 88k is the streetch goal for Linux, "Hopefully" it will be reached otherwise it would be a waste of my money and time.

View this comment - View article - View full comments

Quoting: micmonThis only seems to solve the problem of game storage. The more interesting thing is to also share the savegames and settings which is easily possible on Linux. This way all of Steam can be put on an external drive and be used on multiple PCs.

Well, most games on Steam store any configuration (in-game) settings under the Steam folder designated as your default Download location, which is the location I utilize. There are odd-ball games like Organ Trail that stores some configuration details in a weirdly buried folder (~/.config/unity3d/TheMenWhoWearManyHats/Organ Trail). But, Organ Trail was not developed with Steam originally in mind, nor did they make full effort to make it to be configured easily in this regard. So, with Organ Trail, I need to venture to that weird configuration folder to even make it go to fullscreen mode in Linux (any distro), as you cannot do so via the game's GUI. So, I need to configure Organ Trail twice in both distros. I just want to remind everyone that Organ Trail in this situation does not follow the standard Steam file structure, therefore ~95% of your Steam games will work in sync by both distros if you follow my advice.

To repeat what I mentioned in the how-to, I advise you to not share the Steam client files themselves across two distros. This can lead to stability problems, simply because each disto manages things like their library files and core system programs (e.g., GCC) very differently (the Linux programming libraries, not the Steam 'Library' of games).

This is true regarding how Fedora and Ubuntu manage their distro as a whole. Fedora is more bleeding edge, so you usually have the latest of everything, but Fedora is not as extensively tested as Ubuntu. Likewise, Ubuntu typically has older libraries and core system programs. Just compare and contrast the repos between the various Linux distros, you'll see what I mean (and pick two distros different from each other, not Ubuntu and Mint).

Thus, even though this may be technically possible to do, most people today warn others to never share a /home directory or a program directly across two different distros (unless you compile and package everything yourself for such programs). Yes, there was a time where many said such a set up was good practice, but you are only asking for problems. Hence is the reason for my data partition that I called SweetData.

In the case of Steam, it may not be a big deal as the flagship .deb package created by Valve, for Ubuntu/Debian, gets repackaged into different package formats (.rpm [Fedora/RHEL], .tgz [Slackware], .pkg.tar.xz [Arch]) by lots of volunteers as Steam is a popular program. But you are depending on these volunteers to do so and, moreover, even if a new .tgz package may exist for Slackware, it may not get uploaded in a timely fashion to the Slackware repositories because these newer Steam packages often depend on other packages (and each Linux repo is normally vastly different). This may be a bad example, as I haven't used Slackware for ages, so they may have what Steam needs all the time, but the idea is valid since Valve does not maintain the other package formats, nor do they interact with any other distro (officially) other than Ubuntu. Also, you may get away with less problems with sharing Steam like this, as it does not have that many dependencies. But, I still warn you to not do this.

A better example would be regarding other common applications people might use, such as LibreOffice. If you share your LibreOffice configuration files between Fedora and Ubuntu, you will most likely have issues eventually. The LibreOffice version in the Fedora repo is newer and it is older in Ubuntu's repo. So, even the configuration files for LibreOffice, not the full program itself, could have complications as newer programs eventually switch to newer designs of their configuration files. It may not happen often, but like the famous phase illustrates, “The only constant in life is change.”

Moreover, if you directly share your latest Fedora version of LibreOffice, meaning the WHOLE program into Ubuntu (akin to the Steam client), I would be very surprised if LibreOffice would work correctly. This is because, on Fedora, this shared LibreOffice would be happy with its newer dependencies (which has MANY dependencies), but Ubuntu would not have these newer dependencies installed (via the default Ubuntu repos) and LibreOffice would likely fail to operate or run at all, as Ubuntu would be trying to reference newer library requests which may not have such programming functions defined in the older libraries.

So, what I am advocating (using LibreOffice as an analogy) is NOT to share LibreOffice Writer (the MS Word equivalent) directly between both distros, but to share your Writer documents themselves (.odt, .docx, .doc). Though, in the Steam client example, your game files are what takes up most of the space, not the client itself. Yes, you will lose an extra 1 GB of space to store another client on your secondary distro, but how much pain is this in today's sense of storage reality?

View this comment - View article - View full comments

Quoting: LinuxianThanks RuneSoft for bringing up new games to Linux through Desura. I wondered why the developers were quite silent on ongoing projects that seem dead today. Just look at their page :
https://bitbucket.org/runesoftdev/

Games still to be released :
- Ankh
- Ankh 2
- Anlh 3
- Pinball 3D
- Knight & Merchants

Hopefully they will be released soon (or never ?)

From what I know only one guy is doing the Linux ports at RuneSoft, so don't expect quick releases.

View this comment - View article - View full comments

As I have been told myself: "More is on the way but sadly one day only has 24 hours."

The guys working on the Linux releases have a lot on their plates, so it is best to be patient.

View this comment - View article - View full comments

Don't forget Rome Total War 2 that will be released in 2014!
http://www.omgubuntu.co.uk/2013/11/total-war-rome-ii-coming-linux-early-next-year

View this comment - View article - View full comments

This only seems to solve the problem of game storage. The more interesting thing is to also share the savegames and settings which is easily possible on Linux. This way all of Steam can be put on an external drive and be used on multiple PCs.

View this comment - View article - View full comments

last time i had 2 linux distros (arch and mint) i just had both of them linked to same /home partition
ofc username and stuff had to be same then. but it worked great for me.. no issues at all.
both systems had exact same configs for every program by that and also steam worked without issues.

it was little more than year ago though

View this comment - View article - View full comments

Thanks RuneSoft for bringing up new games to Linux through Desura. I wondered why the developers were quite silent on ongoing projects that seem dead today. Just look at their page :
https://bitbucket.org/runesoftdev/

Games still to be released :
- Ankh
- Ankh 2
- Anlh 3
- Pinball 3D
- Knight & Merchants

Hopefully they will be released soon (or never ?)

View this comment - View article - View full comments

DrMcCoy,

Hmm, well, at least in how I described the set up in Steam (meaning that you need to first uninstall all of your games, then create a common game folder, then just reinstall your games), that Steam will then automatically install any new game to that common game folder. You are never asked by Steam which folder you want to use, as Steam will simply use the new common game folder. I just tested this out again to triple-check my work, and Steam just quietly put the new game files where I wanted. I cannot speak for everyone, but this condition applies in my situation, again using two very different distros (in a dual-boot design).

I would assume that people may only experience what you describe, where a new game install goes back to the stock Steam location and NOT the new folder you specified, because that person did not uninstall all of their games (before creating and pointing Steam to the new common folder). Keep in mind the uninstallation aspect is a one-time ordeal. It doesn't matter if you overwrite your secondary distro and place instead, say Slackware, over Ubuntu. All that would be required in this fresh Slackware install is to get the Steam client running and then just point Steam towards the common game folder. Both distros would then use the same game data without issue. (Well, as long as the game files were not on the Ubuntu partition! Hah.)

So, in a reduced example, where a person only has one game, such as Half-Life 1, installed on Steam's default directory (the "~/.local/share/Steam" folder). This person now wants to install Natural Selection 2, while also wanting to get their all of their Steam games working in both Linux distros. Now, let's say this individual did not uninstall Half-Life 1 before pointing Steam to a new common folder (the "SteamWPL" in my example). So, when they try to install Natural Selection 2, Steam may very well install Natural Selection 2 to Steam's default folder (where Half-Life 1 is still residing). I do not know if this example holds true in reality, as this was not the configuration I described in the article, but my example is based upon how I am understanding your complaint.

Also, I agree that a symlink process could work, but I appreciate that Steam itself can be configured to provide this 'sharing' role directly. This way, there is no odd user/group ID issues as adolson mentioned (at least I don't think there should be such a problem). This feature that I utilize in Steam was not its intended purpose, since it mainly allows people to move large game files to just a different partition of the same OS (which sounds like you wanted), not necessarily for a dual-Linux system. In your case, you could have used my suggestion, but it won't benefit you much now that you already have your games installed and have a symlink in place.

I hope this helps clarify what I was trying to say in the how-to article.

View this comment - View article - View full comments

Yeah, I symlink as well. Not to share the data between two distributions, but to have the data located in a different directory than the default inside the Steam folder.

Adding a new location in Steam would work, in theory. But for every game installation, the drop-down thing for the location always defaults to the default Steam location. So you have to manually change that every time. And you can't delete the default location either.

And you don't even need to uninstall any already installed games either. Just move the whole folder, and symlink it to the original position. Done.

View this comment - View article - View full comments

Quoting: paupavAnd OpenGl doesn't have basic features so gpu vendors have to add extensions.

You obviously have no idea how OpenGL standardization works.

There are several paths to a new OpenGL features. One of them is by GPU vendors introducing new features, either by themselves (NV_/ATI_/AMD_/INTEL_) or jointly (EXT_). The Khronos Group frequently reviews those new features and often gives them their "blessing", adding an official ARB_ extension to match the vendor-specific extension.

Those ARB_ extensions very often enter the core of the next OpenGL version.

This is not a case of "Oh, OpenGL is lacking essential features, so we have to roll our own", but a case of "Oh, there's this new thing that was just discovered in a research paper, let's implement it in a new extension". This path to OpenGL standardization exists by design.

Quoting: paupavNow when Valve is in OpenGl group its time for change.

Valve has been a contributor member of the Khronos Group for quite a while now.

View this comment - View article - View full comments

Quoting: n30p1r4t3Honestly what purpose does this serve the average user?

Oh, yeah, this isn't really meant for an average Linux user, since most people settle with only one distro. But, I tend to enjoy switching distros every so often, which I hope my article helps others to do the same. The greatest strength of the Linux community is all the choices we have.

It sounds like others have the same success with the symlink feature. But, that's Linux for you. There are many ways to do one task :-).

View this comment - View article - View full comments

Quoting: GuestI just symlinked ~/.local/share/Steam to a steam directory on another partition. I’m not actually dual booting, but this is another solution that should work…

Same here. Works great for sharing between SteamOS and another distro (was Arch, now Debian). Only caveat is the user id ownership of the installed data is 1001 for SteamOS, so I just use that on my regular distro as well, rather than change SteamOS (I want to keep it vanilla, no added repos, etc).

View this comment - View article - View full comments

Honestly what purpose does this serve the average user?

View this comment - View article - View full comments

Shiva 2.0 editor is also coming to linux, more competition the better.

http://www.phoronix.com/scan.php?page=news_item&px=MTYxMTc


View video on youtube.com

View this comment - View article - View full comments

Everything seems to work so much better when using Linux!

View this comment - View article - View full comments

Awesome!

View this comment - View article - View full comments

Yeah, I hear you, minj. It is a bit long. I figured it was better to help explain certain points more fully to make sure nobody was lost and wouldn't fall into a trap by accident.

View this comment - View article - View full comments

Reading the release notes show that there are problems with both AMD and nvidida drivers. There was likely more testing with nvidia first (not too surprising), and now they've moved on to making it work with AMD ("just got the ball rolling").
That's all the news that's here.

What OpenGL lacks the most is some standarised framework for compatibility testing, and that's pretty much everyone's fault. G-truc provides a good start for such things, and a debugger provides another.

View this comment - View article - View full comments

I exaggerate by saying people will abandon OpenGl, but improvements are necessary!

View this comment - View article - View full comments

Wooo, i will buy it today. Great memories and defo I need to show my support. Back in 1977 in Poland I had no way to play it and not pirate it. At least now I have a chance to fix it.

View this comment - View article - View full comments

So much text... For such a simple task.

As long as it helps anyone, I guess.

View this comment - View article - View full comments

Quoting: rustybroomhandle

Quoting: Anonymoushow do you tweak performance when you never get real results

By building a Linux build. Unless I misunderstand the question.

doesn't that require running outside Unity? at that point you lost most of reason why to use framework like that. anything run in Unity is bound to wine flaws where you don't get accurate performance picture

View this comment - View article - View full comments

Quoting: paupavYou are very arrogant. It's not about AMD it is about OpenGl. OpenGl is messy API and need to improve fast.

Wikipedia:
addition to the features required by the core API, GPU vendors may provide additional functionality in the form of extensions.
And OpenGl doesn't have basic features so gpu vendors have to add extensions.

OpenGl needs drastical changes or people will abandon it. Now when Valve is in OpenGl group its time for change.

Well the one thing I credit AMD for is not doing the NVidia/Apple "lets make our own extensions and then we will get all the monies". So in part it is Nvidia's fault for not sharing OpenGL extensions out but hey, they aren't opensource guys. AMD do have some blame though, those drivers are just bad in implementation as they are in OpenGL.

I haven't actually done much with raw OpenGL myself but just watch the sheer number of extension checking it has to do for platform specific extensions when you load a source game.

Edit: But I think people abandoning OpenGL is going a bit far, I mean its literally impossible at this point, its like abandoning C++.

View this comment - View article - View full comments

Quoting: paupavYou are very arrogant. It's not about AMD it is about OpenGl. OpenGl is messy API and need to improve fast.

Wikipedia:
addition to the features required by the core API, GPU vendors may provide additional functionality in the form of extensions.
And OpenGl doesn't have basic features so gpu vendors have to add extensions.

OpenGl needs drastical changes or people will abandon it. Now when Valve is in OpenGl group its time for change.

No, I just happen to know a lot about AMD drivers thanks. OpenGL supporting extensions doesn't mean OpenGL doesn't have basic features, jeez talk about talking out of your ass.

I used AMD chips for 5-6 years before finally switching to Nvidia.

Also it is "OpenGL", not "OpenGl" as you call it.

View this comment - View article - View full comments

You are very arrogant. It's not about AMD it is about OpenGl. OpenGl is messy API and need to improve fast.

Wikipedia:
addition to the features required by the core API, GPU vendors may provide additional functionality in the form of extensions.
And OpenGl doesn't have basic features so gpu vendors have to add extensions.

OpenGl needs drastical changes or people will abandon it. Now when Valve is in OpenGl group its time for change.

View this comment - View article - View full comments

I have a great lack of RTS games. Earth 2140 is in the first place of my shopping list.

View this comment - View article - View full comments

QuoteIt's funny to see people claiming AMD's drivers have improved, yet when you see developers and Valve themselves here clearly having to go to extra lengths for their drivers, AMD still has work ahead of them.

Mhmm, pretty much why I abandoned the official driver to go hang out with the FOSS driver. (Funny cause these issues don't happen on that driver). I still want AMD to flip all the catalyst code into the FOSS driver where it fits and then work on that full time. These issues would be avoided much easier.

View this comment - View article - View full comments