Steam for Linux Beta is now open to the public(steamcommunity.com) |
Steam for Linux Beta is now open to the public(steamcommunity.com) |
Are there any better solutions for getting a tracker set up easily where non-contributors can raise bugs and discuss feature requests?
Are all Steam games now compatible with Linux, or only a few titles that the developers are willing to support Linux? Is there a list anywhere?
Very few games are compatible, but Team Fortress 2 is one of them.
Left4Dead was also going to be available, not sure what happened.
Are they planning to support amd64 too?
Either way, it'll get sorted, Steam for Linux is already quite great. Still can't get over that TF2 runs better in a window in Linux than I've ever had it run in Windows.
It's because they don't really grasp yet how these things work on Linux. Which is understandable, since they're coming from a Windows world, where package management has to be done manually. So the Steam executable you download is an installer that downloads/installs the Steam package manager, which then downloads/maintains the games.
Ideally, all the Steam Linux games would be maintained in APT repositories and you would update them through APT, but I don't know if that will ever happen. At least this is better than nothing at all.
They should ship the Steam binaries properly through apt and yum repositories, but I doubt that they'll ever ship the games that way.
A lot of people's backups suddenly grew rather large.
Also steam has diff based patching (which requires accress from whoever is running the steam binary) which makes a lot more sense than how package managers operate for large packages, imagine downloading an entire 20 gig game every time there was a minor bugfix, it would be very obnoxious.
Unless the design of both package managers, and how steam games store settings/etc both change radically, this really is the only workable solution.
Luckily, you will still be able to share steam folders cross user, just simply give both users read/write access to the folder.
The way they're doing it now is plain unclean.
This isn't even true. The deb has dependencies just like any other DEB you'd get through apt-get. That's... kinda the point of package management...
There is a launcher script that is installed in /usr/bin/steam. There was strong feedback from users that updating this script should belong to the system package manager. This is why the repo exists - so this script can be updated and managed by the system package manager.
It is something I have always bet that they will eventually do - once they see the number of support questions by people who have some sort of dependency problems (e.g [1], [2] and [3]).
I wonder how long will it take for them to latch on to something like Zeroinstall or nix.
[1] http://steamcommunity.com/app/221410/discussions/0/846940247... [2] http://steamcommunity.com/app/221410/discussions/1/846940247... [3] http://steamcommunity.com/app/221410/discussions/0/882965118...
TF2 is 12.0 GB ... damn, that's hefty.
This had better be the richest, smoothest, highest quality game; feature rich and expansive. That is about 11GB bigger than any [single] thing I've ever downloaded before. Estimated download completion time ... Christmas.
Well, it's not working very well, since only Debian-based distros can directly install the software. And those distros could just add a repository anyway.
Other distros, like Arch, are forced to create workarounds, such as scripts that download and extract the .deb[0].
Even the steam client package itself is something like 100megs, so it becomes painful without diff/delta patches. (steam updates a LOT)
Pretty much the only valid point is having to update the whole thing every release, but I've never seen the Steam client download an update that was less than 75 MB.
Steam has always been designed on both osx and windows to be a portable folder that you can move around from system to system and run stuff out of wihout worrying about installers and dependancies.
2. I'm pretty sure path prefixes can be used and the same set of pkg management tools can be used to install in user land. I've done it in the past into an env I was chrooting and minifying to power a picture frame.
As paths to libs and stuff are hardcoded as part of the ELF spec, it becomes difficult to implement something like this and ive not seen a package manager that can do it.
Possibly a bigger issue would be that Steam has incremental updates (fixing a bug in a game requires downloading a fixed binary but not the multi-gigabyte data files) while most Linux package managers do not support incremental updates (when Debian releases a new LibreOffice package that fixes some dependencies for the s360 archictecture, I still have to download hundreds of megabytes of changes on amd64).
I think it makes sense for Steam to be isolated from the rest of the system as much as possible.
It is also helpful to Valve if it is as consistent with Steam on other platforms as possible.
Game downloads can be pretty big and take a while too, I'd rather not have apt locked for an hour while it grabs some large game update.
The package manager on Windows (Steam) isn't needed on Linux because there's already a native package manager on the majority of distros. In fact, you can already buy games through the Ubuntu package manager. I believe they're in a separate, "partners" repository. Steam should just be another repository like that.
Everything else is up to the various game studios, though all games in the Humble Indie Bundles support Linux so hopefully they are added to Steam soon.
Darn. This what I'm waiting for as most of my games are from humblebundle. Well at least uplink+defcon should work :)
Many are already available.
Quite a smart business decision and I'm glad they brought TF2 over - I always thought this would be the first game to publicly release.
It would be interesting to think more about user-level applications and how that sort of trust would work, if it could.
The more packages managed by the system, the better. Ideally, you'd want the games, too, but I understand why Valve might not like that.
Using the unclean alternative when there's a clean one that's just as good isn't a good decision, in my opinion.
No?
Something like "I want to play TF2, so I should update Steam and TF2" is a reasonably common thing and it makes sense to want one thing to handle both of them.
"You should discard the package manager entirely" does not follow from that.
Ergo, "you should discard the package manager entirely".
Steam is separate from the games, it's just an installer. You can play (and update) the games without the installer, therefore at least Steam should be a managed package.
The same thing you gain from every other linux package that has a globally installed application with per-user configuration? which is... every single other application in the entire linux world?
>Steam has always been designed on both osx and windows to be a portable folder that you can move around from system to system and run stuff out of wihout worrying about installers and dependancies.
Huh? Are you familiar with Linux? You can move/copy your home dir, reinstall the package-managed binary and it "just works". That is the best definition of portable, far better than copy-pasting a "Program Files" directory between machines and crossing your fingers. Again, I've yet to hear a technical reason that we can't have /usr/bin/steam and ~/.steam/<steamapps> like every other Linux application does.
That is not much like my reasoning. Taking something out of the package manager does not generally make it so that it is taken care of by the same thing that takes care of TF2 being up to date. Making Steam handle Steam updates does.
Once you have introduced Steam as a thing that handles updates for you, moving Steam updates from package manager to Steam is clearly not exactly the same issue as removing things from the package manager in general.
(I mean, it sort of is if "the package manager should handle as many things as possible" is your goal. It is not if "as few things as possible should handle package manager-like things" is your goal.)