linux video games windows

Steam Deck Gets Windows Drivers “As-Is”

The people working on Valve’s Steam Deck had a lot of complicated hardware and software hurdles to overcome in order for it to just be a functional handheld gaming computer. My guess is that the biggest hurdle after everything else is probably Valve’s WINE-fork, Proton. Fortunately, Valve can continue to update Proton after the Steam Deck was released. Unfortunately, I don’t think they will undo the damage they’ve caused to the people who were porting games to Linux natively for two decades. Windows compatibility layers like Proton will also never provide perfectly accurate Windows operating system compatibility and it’s gotten to the point where Bungie is threatening to ban users who try to play Destiny 2 through Proton. That’s not entirely unreasonable from their perspective running a multiplayer game, but it stinks for Destiny 2 players.

Because the Steam Deck is “just a computer” Valve is now providing an incomplete set of drivers for Windows to run on the Steam DeckDual-booting SteamOS isn’t supported, neither is Windows 11 which requires TPM support, Valve says that both of those will work later on. The built-in speakers and microphone jack also won’t work for now, but Valve says that users can use Bluetooth or USB-C audio adaptors.. Valve is also calling this release unsupported “as-is,” and not offering any official support for the drivers but points users to this page to download the driver packages and this guide for restoring the Steam Deck back to SteamOS.

Destiny 2 runs on the Steam Deck when Windows is installed.


Slackware Linux 15.0 Released

Slackware 15.0 is out today, this is the first new version of one of the oldest Linux operating system distributions since Slackware 14.2 was released in July of 2016. The first version of Slackware was released 28 years ago in 1993.

Patrick J. Volkerding announced Slackware 15.0 with this message:

Well folks, in spite of the dire predictions of YouTube pundits, this
morning the Slackhog emerged from its development den, did *not* see its
shadow, and Slackware 15.0 has been officially released – another six
weeks (or years) of the development treadmill averted.

This has been an interesting development cycle (in the “may you live in
interesting times” sense). Anyone who has followed Linux development over
the years has seen the new technology and a slow but steady drift away from
the more UNIX-like structure. The challenge this time around was to adopt
as much of the good stuff out there as we could without changing the
character of the operating system. Keep it familiar, but make it modern.
And boy did we have our work cut out for us. We adopted PAM (finally)
as projects we needed dropped support for pure shadow passwords. We switched
from ConsoleKit2 to elogind, making it much easier to support software
that targets that Other Init System and bringing us up-to-date with the
XDG standards. We added support for PipeWire as an alternate to PulseAudio,
and for Wayland sessions in addition to X11. Dropped Qt4 and moved entirely
to Qt5. Brought in Rust and Python 3. Added many, many new libraries to the
system to help support all the various additions. We’ve upgraded to two of
the finest desktop environments available today: Xfce 4.16, a fast and
lightweight but visually appealing and easy to use desktop environment, and
the KDE Plasma 5 graphical workspaces environment, version 5.23.5 (the
Plasma 25th Anniversary Edition). This also supports running under Wayland
or X11.

We still love Sendmail, but have moved it into the /extra directory and made
Postfix the default mail handler. The old imapd and ipop3d have been retired
and replaced by the much more featureful Dovecot IMAP and POP3 server.

The Slackware pkgtools (package management utilities) saw quite a bit of
development as well. File locking was implemented to prevent parallel
installs or upgrades from colliding, and the amount of data written to
storage minimized in order to avoid extra writes on SSD devices.

For the first time ever we have included a “” script that allows
automatically rebuilding the entire operating system from source. We also
made it a priority throughout the development cycle to ensure that nothing
failed to build. All the sources have been tested and found to build
properly. Special thanks to nobodino for spearheading this effort.

We have also included new scripts to easily rebuild the installer, and to
build the kernel packages. With the new ease of generating kernel packages,
we went on to build and test nearly every kernel that was released, finally
landing on the 5.15.x LTS series which we’ve used for this release. There
are also some sample config files to build 5.16 kernels included in the
/testing directory for anyone interested in using those kernels.

There’s really just way too many upgrades to list them all here. For a
complete list of included packages, see:

Slackware has always been my favorite distribution of Linux. In the 90’s and early 2000’s Slackware epitomized the hacker lifestyle that if you wanted a new piece of software you had to compile it yourself and if you messed something up, that was your fault. It was extremely unfriendly to use and that was perfect for the shitty teenager I was at the time. Fortunately I had some friends who were much nicer and helped when I ran into trouble. Even the install process today has no GUI to help partition your hard drive before the console-based setup program runs, it’s all up to you.

Part of the reason for the delay between releases may be due to Slackware’s Patrick J. Volkerding struggling after getting ripped off by his former business partners. Slackware was never easy, but it is a huge part of the history of Linux and it is a shame that big businesses continue to profit off of this free and open source software without contributing back to the people who made their businesses possible.

See the rest of the announcement for links to download Slackware 15.0.

linux video games

How-To Geek: “Why You Should Use Proton Instead of the Steam Linux Runtime”

The situation with Windows “API Compatibility” or emulation, however you call it, came to an inflection point when Valve started pushing or reassuring developers that they don’t need to port their games to Linux for them to work well on the Steam Deck. Jordan Gloor at How-To Geek has this article titled “Why You Should Use Proton Instead of the Steam Linux Runtime”:

When you use Steam’s compatibility features to run games on a Linux PC, you may have the option to run it with one of two utilities: Proton and Steam Linux Runtime. Between the two, you should probably choose Proton. Here’s why.

Gloor goes through a few reasons that it might be preferable for Linux gamers to use Proton instead of a native Linux port. Gloor says that the smaller size of the Linux game-playing audience means that the game developer may have spent fewer resources on making the port function well versus the Windows version of their game.

I don’t think Gloor is a bad person, but this is bad advice for both game players and Linux as a whole. Articles like this are disappointing, but they are the natural consequence of what Valve is doing by pushing their Windows API compatibility emulation layer over native Linux ports. It would be interesting if game developers have the option to disable Proton for their games because, and I cannot stress this enough, Windows emulation or compatibility layers truly are a coincidence when they work. Especially with games from smaller developers who do not have fantastic commercial success, I would not expect Proton to be the correct choice or to be surprised when Proton doesn’t work. Valve will most likely not take the time to make sure that, for example, Escape Goat 2 works in Proton. Yes, Escape Goat 2 is a real and very good puzzle game with a native Linux port. There are tens of thousands of games on Steam, it is impossible that these games will all work well in Proton. Linux users should absolutely go with the native port first, when they have the option.

linux video games

Frozenbyte Developer Says Proton Better Than Older Linux Ports, Native Ports Not Worth Doing Yet

In a few threads on the Steam forums for an upcoming game called Starbase from Frozenbyte, the developer have spelled out that they believe Valve’s Proton Windows emulation compatibility layer is better than the older ports their games (Trine, Shadowgrounds) had:

Currently it’s probably a better idea to play the Windows versions of our old games via Proton, than trying to get the native versions running.

The majority of Frozenbyte’s games were brought to Linux, but they say it’s unlikely for Starbase unless the Linux audience increases in size:

If Linux gaming takes off (for example, because Steam Deck becomes a huge success), then we’ll have a reason to consider not-so-low-on-resources port, which may (and probably does) change the picture somewhat.

…and they say that another reason to do the port might be if people who play Starbase using Proton report issues:

I recommend using Proton, because it usually just works. If a user reports that Proton no longer works, we would pay attention, but can’t promise anything is done very fast.

These are just comments from an engine developer (Jukka Larja) at Frozenbyte on their game’s forums, so I wouldn’t consider them to be the final word in what gets done, but it seems likely that the statements are accurate and Frozenbyte won’t support Linux in the future if Proton is effective at running their games.


The Torvalds Situation

This is old news to some, but it’s still something I wanted to write about. Linus Torvalds, the Linux kernel creator and project manager, has stepped aside (temporarily) to work on his attitude, which is acerbic and awful. Spewing expletives and insults at anyone who dares to work on the kernel. At first, it wasn’t understood why Torvalds chose this moment to take a break.

Noam Cohen has the scoop for The New Yorker:

Torvalds’s decision to step aside came after The New Yorker asked him a series of questions about his conduct for a story on complaints about his abusive behavior discouraging women from working as Linux-kernel programmers. In a response to The New Yorker, Torvalds said, “I am very proud of the Linux code that I invented and the impact it has had on the world. I am not, however, always proud of my inability to communicate well with others—this is a lifelong struggle for me. To anyone whose feelings I have hurt, I am deeply sorry.”

It shouldn’t take a journalist looking into your attitude for some self-reflection to happen, but I’m pretty happy that this acknowledgement is happening at all.

Torvalds’ shitty attitude of non-conformity to being a good person was infectious, it helped encourage a younger Jack Slater to be a bad leader for the ioquake3 project in the IRC channel and on the mailing list. I thought this attitude made for a good leader, it had the opposite effect. Being an asshole only brought in other assholes and a few extremely great people who helped me change as a leader.

Other “open source” leaders like Eric S. Raymond have already been found to be complete shitbergs blocking the flow of progress, at least Torvalds had enough sense to step aside and try to change.

It is decades past time for better leadership in open source and free software. Bring out the open-source 3D printed ultra mega guillotine for the leaders who refuse to step-aside or change.