Open Beta for Steam on Linux

A welcome, if expected surprise, Valve opened up their Linux beta of their Steam gaming platform, along with the Linux version of Team Fortress 2 in time for the end of the long count of the Mayan calendar (sorry, I know everyone’s made and heard enough Mayan calendar jokes already, and I’m even late to the apocalypse, but with it being the busy-busy holiday season I didn’t have time to get by the joke store to restock).

It takes a little administrating to install if you’re not on their preferred platform of Ubuntu. On Debian it’s mostly down to version number discrepancies between Ubuntu and Debian (eg, Ubuntu might have a specialized version number for a package that’s based on Debian’s, but different). The biggest pain is that you basically have to either rely on a private repository or disable apt-based updating (typically by commenting out the repository in /etc/apt/sources.list.d/[specific list]) to avoid complaints every time their package changes.

This is okay for the short term, but will need to be fixed if they intend to support multiple distros in the long term, possibly by looser depends specifications, or maybe by working with distros to have a steam metapackage that their package can depend upon.

So I finally played some Team Fortress 2 again. I’ve played it a bit under WINE, but had stopped some time back (I believe around the time of the release of the Pyrovision update) for various reasons. This was the first time I saw the Man v. Machine game mode (or MvM/Cooperative as it might be referred). It seemed fun except for having to return and upgrade after every wave of machines had been rendered nonfunctional.

That has to be my biggest peeve about the direction Team Fortress 2 took, or any game for that matter: don’t make me weigh so many options. Do I want to spend that much time deciding what weapons I scrap and which ones I add nametags? It just gets silly, having to manage hundreds of items, or not wanting to switch classes during MvM because I bought upgrades for a different class.

Maybe it’s just the gaming generation I came from, but it used to be you got random upgrades, and you liked them, dammit!

The Steam service runs well so far, as does Team Fortress 2. It will probably take a few months before other Source games are available, and the roadmap for non-Valve games isn’t clear yet, but the first piece of the puzzle is just about there.

No discussion of Linux gaming is complete without another look at graphics drivers. In any general thread about Steam on Linux, you’ll see them brought up, with people lamenting performance, stability, and closedness of the drivers. My experience with nVidia has been decent performance with near-satisfactory stability. That is to say, I do have some stability issues with the graphics driver, including things like my virtual terminals occasionally being rendered as artifacts in X (little 10-20 pixel squares), and sometimes my browser (Iceweasel, which is GPU-accelerated) will flicker all-black while playing games.

I’d imagine the troubles are at least this bad for AMD-based graphics, as in the past I used their cards/drivers and had problems as well.

Intel graphics and drivers are probably the smoothest except for performance. I say probably, as I don’t have any direct experience there.

It is the hope of the community that Steam will push all the graphics vendors to fix their problems, but even if that happens, that’s short of the true best outcome: completely open, performant drivers.

Attack of the Undead Penguins

Steam coming to Linux, you say?

People following the Valve/Steam/Linux news already know that the awesome hackers at Valve have Left 4 Dead 2 running on Ubuntu like a champ. They know that Valve has been doing some work toward a so-called three meter display (ie, for television display), and have probably speculated that they are at least considering building a console.

This is a post about what I’m looking forward to seeing out of Valve on Linux.

Playing Games

Foremost, I’m looking to playing games without even the minor inconveniences of WINE. Often there are tweaks, there’s turning off features, or some minor thorn of just about every game I’ve played on WINE. WINE is awesome, and it’s made some money for game companies, as there are games I bought because I knew that I could play them.

But it’s not perfect, and for people that eschew yak shaving to play a game, the set of titles they might purchase and play drops (I’m not thinking about side projects like PlayOnLinux, as I’ve not tried them).

For a lot of games, if they make it to Linux, that means getting full eye candy. Full features.

Building Games

Secondly, I’m hopeful that the game creation tools will be coming to Linux. Some of these kind-of-sort-of run under WINE, but my experience with these hasn’t been nearly as good as with games. Even if the current generation tools don’t make it, maybe the next generation will.

The lower the barrier to entry for creating game content, the more that will be created, and the better games we will see. That’s true of technology in general.

I’ve made a few maps years ago under Windows, but the few times I tried to build maps under WINE it was much clunkier and fraught with peril. I’m very hopeful that in another decade or so it will be commonplace for gamers to be mappers and modelers, even if their extent of mapping and modeling is just to customize existing maps and models.

Building Bridges

But, like others, my biggest hope is that this work will result in greater support from the four corners of the earth for Open Source and Linux. That it will widen the market for gaming, while making governments and businesses evaluate Linux as a greater possibility for their employees.

Just like Android has pushed a device with Linux to far more hands than ever before, a Valve console could do it again. But so can Steam for Linux. There’s plenty of people that keep a second computer or dual booting just for games. There also a general perception that Windows is the king because of gaming. Linux getting more gaming means that even Apple may end up supporting iTunes for Linux one day.

A side bet is, assuming the success of Steam for Linux, could that competition bring Microsoft back from the brink? For years Microsoft has had the capacity to push the computing world far beyond its current state. But it’s had no reason. That’s harmed its server market, which hasn’t been very competitive.

Conclusion

In any case, as a long-term fan of Valve’s games, I look forward to playing Half-Life 3 on Linux (just like I played Half-Life 2 here), and with any luck the Black Mesa modification can be playable on Linux too.

Brought to You by Windows Seven

Instead of writing about something more interesting, a short rant about hardware compatibility and computing.

People often complain about driver availability on GNU/Linux, but the situation can be far worse for the Microsoft Windows systems.

On Linux, when you need a driver, the only real problem you run into is the case where a driver was never created for it.  Almost all of the divers on Linux are Free (as in speech), meaning that once a driver was written, it can live forever.  If the systems change, it can be updated.  The bulk of the work’s been done, and the old source has most of what’s needed if an update is required.

On Windows, you have the opposite problem.  A driver was almost undoubtedly created, because the hardware vendors are in the business of selling Windows-compatible hardware.  But at some point they don’t want to maintain drivers for their old hardware, so they stop.

That’s a problem you can run into for Windows Seven for at least some vendors.  Some vendors keep updating, but others just drop support and you can have a perfectly functional computer without valid drivers.  The source is closed, and the vendors simply care not.

This is one of the ways that Free Software is undeniably superior to Closed Software.  Microsoft has no control over the situation, because they don’t require any source to be available.  While they may partner with specific vendors for specific hardware drivers, they can’t possibly do that for the whole ecosystem.  They’re just as stuck as you are for devices that have been orphaned by the manufacturer.

Unless Microsoft and that community decide to shift toward freedom, the long-term situation will be one of an ever-growing pile of completely useless-to-Windows hardware.  That’s not an environmental boon, that’s not a way to spread the technology to the poor, and it’s not a way to build the technology economy as high as we can.

It’s bad business, and it’s bad citizenship.

The other side of the situation is where Linux could conceivably help.  There’s likely a Linux driver for some of the hardware that people can’t get to run on Windows.  It’s at least possible that some of the information from the Linux drivers could be used to create free drivers for the orphaned hardware for Windows.

While I don’t have a Windows computer around and don’t have much driver experience, it would be interesting to know if that hunch is correct, and whether the free software community could use that as an inroad to spread freedom to Windows users.

What’s in a name? Version numbers as names

What’s in a name? that which we call a rose
By any other name would smell as sweet;

— William Shakespeare, Romeo and Juliet

In practically every discussion I’ve seen of Firefox’s new accelerated release cycles the topic of the version numbers stands prominent.  People have repeatedly claimed that it’s some sort of half-assed ploy to raise the version number to improve marketing.  I find that quite misguided, as I see the great promise the new development plan has for making Firefox the best browser it can be.

But people get bent out of shape over versioning, for whatever reason.  Though in this case the focus has been on the marketing angle, Linux has had heated discussions before regarding their versioning scheme.  And TeX just keeps on approaching Pi as its versioning scheme.

It’s just a name, and the only real rule that’s commonly followed is that the version should always be an increasing value (mainly because it’s good for programmatic comparison purposes).

Shakespeare was dead on in the famous speech by Juliet regarding the disputes that names cause.

Hell, the Internet Protocol simply skipped version 5, as ECMAScript skipped version 4.

Oh, which reminds me:

  1. APNIC (the Asian/Pacific Network Information Centre) is almost out of IPv4 addresses, meaning that for practical purposes all new allocations will be of IPv6 addresses and it’s time for the world to move on.
  2. Thanks to the awesomeness that hosts this blog, it now has a AAAA record (ie, an IPv6 address).

There’s a warm feeling to know that this humble blog is accessible to users over IPv6.  For now I can only wait for the day that I can actually get to it over IPv6 myself.

Canonical and GNOME

Removing the minimize button?  Not giving a preference to turn off the display and not suspend when you close your laptop?  Moving the window controls to the other side of the window? Making the tabs square instead of round? Not allowing the editbox to be manually resized? Hiding the RSS icon? Moving the link preview to the URL bar? Removing the status bar?

And those are just the ones I can recall at the moment.

The computer is so central to peoples’ activities, that there is a certain fear that someone will break it for them.  That’s one of the major motivations behind Free Software in the first place: if I can build it myself, then you can’t force me to use the broken one.  If I can’t, then MicrosoftAppleSonyPaypalMastercard can up and decide to force their will upon me, and my recourse is simply to stop using them.  No stabbing big corporations with a fork.

Canonical Limited (the main driver for Ubuntu Linux) and the GNOME project couldn’t work together so they are each moving forward with their own, reinvented desktop interfaces. GNOME is going for gnome-shell and Canonical/Ubuntu will get Unity.

I don’t think this is a bad thing, excepting the bickering.  The larger community of desktop Linux users will get to see two different approaches in the wild for at least a year, which will inform the next iteration of the Linux desktop landscape.  There’s also an open-ended possibility for reunion later.

The dispute is territorial, which is not uncommon in open source.  The uncommon part of this is simply that it’s between two big players rather than between one big player and the users.  Though, the latter has occurred for both reinventions as well (see a few of the questions posed in the first paragraph).

Project governance is hard.  Cooperation is hard.  Finding the best way is hard.

If it weren’t for the bickering, nothing would be wrong.  There’s too much distrust and fear, because that’s what we’ve been taught by the proprietary realm.  When we used proprietary software, we could be stuck with a bug indefinitely.  Or things could change with no warning.

So we’re edgy.  But when the source is open, we shouldn’t be.  And if we weren’t, it would make project governance easier, it would make progress easier.  We should be willing to give the code an honest run.

At the end of the day any shift in any system will require a new equilibrium to be reached.  In open source that means some users will switch, forks might be created, etc.  But it also means that most users will find a slightly better workflow, will be a little (or a lot) happier and more productive.

I just wish that the developers weren’t so quick to assign blame, because they’re both building the foundation for the future, and they should be proud of their efforts even if they fail.