dpkg is a low-level command that can only complete the install if the dependencies are already installed. apt-get is a high-level command but doesn't know what to do with a package that it didn't download itself. gdebi has neither limitation.
It seems the only free title (at least on the list I got) is the World of Goo demo. It's available via `steam steam://install/22010` and it works without issues (testing under Arch).
Woah, you weren't kidding about switching away from XMonad first. That is the most broken focus switching I've ever seen -- and that's after I figured out why I couldn't click anything in the window.
Ah, it seems like the pointer coordinates are offset from what Steam expects. If I move windows close to the center of the screen, or if I can find resize the window from an offset edge, it works again. With gnome-shell, fwiw.
I bet the people in charge of Steam for Linux are high-fiving whoever coordinated with the Humble Bundle team.
At least half of the titles in that list appeared in Humble Bundles, and I'm guessing a lot of those games wouldn't have been listed otherwise (Darwinia, AYIM, etc.).
Slim pickings still, but much better than just TF2/SS3:BFE.
Actually, Introversion's games were on Linux before even the first Humble Bundle existed, which made the later Bundle appearance a bit of an outlier in that department.
The real surprise in the list is The Book of Unwritten Tales, which I think is the only non-Valve/non-Croteam title in the catalog that was not available on Linux before today. And in its genre (traditional graphical adventure) it's a very high-profile title.
Not bad at all for a beta start. There's a fair amount of good games inside there. I am not in the closed beta yet, so I have no way to say if this work but I certainly hope to try this soon when they open the beta. I wonder if they are still expecting a 2012 launch or whether the actual launch timing is going to be pushed back to 2013. The later is more likely.
You'll notice that Crusader Kings II gives a "no files" error when you try to launch it from the library (you have to own the game already). When I posted this as a bug I was told that CK2 was in an invite-only closed beta. I guess that means I have to get an invitation from Paradox.
I'm assuming the rest of the games with a "no files" error are still being tested or prepped for release.
That's awesome. Of course many of these were available before. But having a good selection together in Linux under the Steam brand is a huge deal. If you're bored, chances are you can pick up something there in a couple of minutes. Chances are, you already have an account.
> “An overwhelming majority of beta applicants have reported they’re running the Ubuntu distro of Linux”
I'm sure the survey results were really valuable and contained only true answers after they announced that "ubuntu" is the "right" answer for the first beta... I hope they don't take them too seriously.
Yep, I run Arch but answered Ubuntu because I knew I'd have no chance of getting into the beta otherwise. No doubt someone will manage to create an AUR package for Arch that uses the Ubuntu version of Steam. Unfortunately, I wasn't selected, so I have no way of knowing when I'll actually get to try it out.
The first time I connected it didn't work, but I put in the command to download tf2 (which didn't download) and after that it seemed to work fine, I could talk to my friends and download/play my HIB games.
Augh. Some really craptastic distro-specific code in there. The wrapper script tries to detect missing dependencies on its own (gee... aren't package dependencies already handled by something, maybe the package manager?) and install them via "gksudo apt-get ...". Sigh...
Valve: come on guys, get it right. Look at how Chrome or Dropbox do this for a clean example. Basically, you define your own repository and your "install now" link simply adds it (and its key) and pulls your package via apt/yum/zypper/whatever.
Those things are explicitly added post-install because a package can't have cross-architecture dependencies and not all the 10.4 packages support multiarch. For example, if your 32-bit package depends on xboxdrv, it can't install on an Ubuntu 10.4 x64 system. (ditto for libappindicator1, jockey-common, etc) I don't see how defining our own repository helps this problem at all. (and isn't what dropbox, chrome, etc. do anyway)
Hah! I knew you guys were watching. First, I'm quite certain that is what dropbox and chrome do, but I'll leave research to you if you like.
And yes: getting cross distro (and especially multilib) support working is a big mess. But what you're doing is just awful. The scripts as-is are completely unusable on a Fedora box, because you've mixed "maintain the package installation" with "check for updates" with "run the binary" in a way that can't be cleanly separated. I'd literally have to rewrite most of your stuff just to use it, and that's dumb. Other providers (Skype is another good example, by the way) don't have this problem. Please study their solutions.
Seconding this: Doing a post-post-install in a script installed in /usr/bin is horrible!
Is targeting Ubuntu 10.4 a hard requirement? I suppose it's the last LTS release, but surely the users Valve is targetting would almost all have upgraded past 10.4 by now, and the 12.04 LTS release has already happened. Anything more recent than 11.04 has proper mutli-arch support in dpkg/apt so you can specify that your package needs both 64 and 32 bit versions of some packages.
Your approach seems extremely fragile: is seamless 10.04 support such a necessity?
Incidentally, your compiled binary is compiled against a more recent libc than was shipped in Ubuntu 10.4, so it will currently refuse to run on 10.4 anyway. I'm guessing you compiled in on an Ubuntu 12.04 install, since it has a hard requirement for a libc version 2.15 or above. This means it won't run on anything older than Ubuntu (12.04), nor will it run on the current or the next Debian release.
Ha! After some gruesome hackery, I got it running on the Debian testing release.
A few small bug reports:
1) Your code to check who is in the closed beta is clearly not working :)
2) In the install dialog, asking whether or not to "Create a start menu shortcut to <game X>" is clearly meaningless :)
3) For some reason, Psychonauts is in my library (I own a copy on Windows), but I can't install it. Once past the dialogs, the install complete instantly & the gui believes it to be installed, but (unsurprisingly, since nothing has been downloaded) it won't run. Installing WorldOfGoo works perfectly.
4) You're re-setting LD_LIBRARY_PATH somewhere, which means that I can't actually play any of the games, even though I can install them, because they're finding the wrong libraries.
5) Running the games directly from the command line doesn't work, because they can't find a running steam instance to authenticate against, even though steam is running fine (this might be expected behaviour at this point, even though it works under windows obv.) I suspect this is related to (4): forcibly preloading everything in .steam/bin fixes the linking problem at least.
The Steam GUI seems perfect though: responsive & the look and feel is much the same as the Windows version. Bravo!
Yeah, it really looks like this was built with essentially no view to binary compatibility (i.e. they did it on Precise simply because that's what they had on their desktops) and then tried to bolt-on multilib and cross-version (cross-distro was clearly chucked as far out the window as they could throw it) features right before beta. Then they added a bunch of "checking" stuff to the scripts "just to be sure".
Broadly, the best way to do this looks like this:
0. Build on 10.04 Lucid. Of the existing "well-supported" distro choices, it is binary compatible with more of the rest of the universe (including modern Fedora/OpenSUSE too!).
1. Identify dependencies on distro-provided software very early, and document them precisely. Things like the "xboxdrv" hacks mentioned above shouldn't exist; if you can't get it everywhere you need your own copy. It sucks but it's true. Building this stuff from scratch really isn't rocket surgery. A Lucid-built library will (absent missing dependencies) work on more modern distros, I promise.
1a. Conversely, if you can get something from the distro reliably, please do!
2. Separate the "update" mechanism from the binaries! Running steam should simply run steam. Put a "there is a new version" check in there if you must, but don't invoke the package manager on behalf of the user! If there are dependencies missing, you shouldn't be running at all.
3. Maintain your own apt (and ideally yum/zypper) repos. This allows you to cryptographically sign your distributed software in a way that the users and their tools already understand. And frankly it's something you need, and aren't likely do (or do correctly) for yourself anyway.
Doing things like this ensures that those of us who aren't on your preferred distro can still run your software without hating you. This is Linux -- you don't need to bend over backwards to support us. We're happy to do some porting work, just don't crap on us like you're doing now.
First, I want to correct my typo - we are initially targeting Ubuntu 12.04 LTS (not 10.4 as I fat-fingered above) We are not looking at other distros in this limited beta release but obviously we don't want to do anything to preclude this in the future.
The dropbox and chrome examples are a little different. They ship both 32-bit and 64-bit .debs so they don't hit the multi-arch issues we did. Try to install the 32-bit dropbox .deb on x64 Ubuntu 12.04 and you will see the same problem (python-gtk2:i386 conflicts with python-gtk2)
Hopefully we can get the multiarch issues ironed out with Canonical (a lot of problems have already been fixed in updates). Believe me, I would like nothing better than to remove the gross hacks.
I'm still not following. There's no (sane) reason I can see you can't ship your own 64 bit binaries. Obviously some of your games aren't going to qualify, but you'll need your own library manager for that stuff anyway. Why must the client install be such a mess?
And again, I'm not part of the beta so I really can't comment on your forums. If I'm going to deliver tough love it has to be here, sorry.
If providing a 64 bit binary is a "port" for this product then I suspect you have more tough love forthcoming. Really, the rest of the universe can just "build" across architectures (and I recognize that you probably can't control your partner's code and need to do multilib for the games, but really -- you couldn't make it work on your own code?). But this thread is long enough already. Just realize that you're not inspiring confidence here... Also look at Skype on Fedora for an example of a 32-bit-only multilib aware commercial product.
I'm not in the beta (just used the download link above) so sadly I lack such a channel. But broadly in my experience your suggestion simply doesn't work. Betas are for bug reports. Criticism of the code never makes it to the dev team, period.
On the other hand, it strikes me as quite likely that some of them read HN...
This might sound ridiculous, but Valve are actually really good at responding, or at least reading, emails sent right to the top. If you just send your thoughts to gaben@valvesoftware.com, I'm sure he'll forward it to whoever it's relevant to.
(I say this from experience - I sent him an email saying I thought the end of Half Life 2: Episode 2 was really fantastic stuff, and got a response back from the script writer, who he had forwarded the email to :])
I've always been curious - is it known whether Gabe himself actually reads emails from non-employees sent to that address, or could it just be an assistant that handles routing most of the emails? I really can't imagine how he could possibly have time to deal with a public email account, but maybe I'm overestimating the volume of email he would get...
I just installed and ran Uplink without beta access. Ran smoothly even in a Virtualbox.
Edit: To clarify, I have lots of indie games on steam that are readily installable on Linux. TF2 doesn't seem to be available without beta access though.
If you break your ubuntu 12.04 install because nvidia driver 304 breaks, here's how you fix it. Hopefully you made backups of your x config files (it's a selectable option when you install new nvidia drivers). If it's x is truly broken, then you won't see any windows or GUI. Hit ctrl-alt-F1 and login to your user, then do this
Yeah, I managed to kill X by installing 310 after having installed 304. It was managing to put 304 in the kernel while using 310's interface to it. Removing the packages for both and then installing just 310 fixed it.
This is great for a closed beta, I thought its gonna be a farm of bugs with almost nothing working ... I really appreciate steam team for their hard work, I hope we see hardcore gamers soon using Linux.
I run it and it strongly recommends that I install a new nVidia driver that is marked as "experimental".
I know that it's not fair to dump on a beta but the interface is really unresponsive even compared to the Windows version and half the time I can't even drag windows around.
It will possibly still require workarounds for non-ubuntu users though, the official sources are only citing compatibility with Ubuntu as a goal. That said, every distribution will likely have a package available through non-official sources. Arch for example already has a working user package for the current client. And I can also confirm that it is slow and buggy as was to be expected.
Next right click the Steam icon in the Unity launcher and pick Store. Pin the icon to directly pick Store next time.