The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

With WINE, Buying Unsupported (?) Games on Steam

Thoughts about the addition of WINE (Proton) to Steam for Linux.

Interesting news that Valve has developed and integrated a WINE fork called Proton into the Linux version of their game launcher. The consideration now becomes whether to buy games that work through this compatibility layer but don’t otherwise support Linux.

There are always a lot of people on forums that speak of dual-booting, and that class will mostly buy games regardless of Linux support. For them, lack of Linux support was never a deal breaker, even if they would have liked to have support. Game access comes first, and they’ll be happy to keep buying the games they want, playing them in a Linux environment when they can.

There are people that have used WINE or similar layers all along from Linux, and they would buy whatever games they liked that they could verify would work via the WINE database (plus natively supported games). For this group, access via Linux, by any means, comes first. But they’ll still happily keep doing their thing.

There are also plenty who will want first-class Linux support, and that group is harder to judge now. If a game’s support is via WINE/Proton, does that count as first class? Especially if they are willing to fix bugs that arise, either by contributing to Proton or by changing their own game. One issue there is that updating games for Windows to fix bugs for Linux seems weird. It’ll be up to Valve and developers to decide whether having a “Windows-WINE” flavored repository makes sense for developers that use that approach.

But I digress. Some of the purist camp will not want to play games via compatibility, but if the developers signal they support Linux through WINE/Proton, others will consider support support.

The main long-term benefit of adding a compatibility layer may actually be bigger than Linux gaming. Due to WINE’s potential for portability, there may be places that Windows games end up working in the distant future that nobody planned on.


I installed and tried the old Katamari Damacy clone, The Wonderful End of the World (Dejoban Games). It worked just fine. There were only one or two models without rendered textures (black instead), and only one occasion where mouse-capture was partially lost (alt-tabbing out and in fixed that).

When I get a chance, I’ll try some other games I haven’t played in the years since I left Windows. I suspect most of them will mostly work.

Whether I’ll buy games that work through “Steam Play,” I haven’t decided just yet. I’ll certainly consider it, though.

Nautilus and Hidden Files

Why an application might toggle showing hidden files in nautilus (Gnome Files) when you don’t want it to.

Awhile back I updated Gnome and wasn’t seeing hidden files in nautilus (“Gnome Files”) anymore. I went into dconf-editor and looked around and found the old preference for it set correctly, so I dug around online and found they now use org.gtk.settings.file-chooser.show-hidden instead of the old preference. So I set that and went on, only to find sometime later it wasn’t working again.

Something was changing that setting, but in the meantime I discovered the “Ctrl + h” keyboard shortcut to toggle it, and would just use that. Still, who wants to toggle something like that frequently?

Eventually, I looked at some code of a non-packaged GTK+ application I use. Lo and behold, its file open dialog included a call to gtk_file_chooser_set_show_hidden, which apparently doesn’t just set it for the current file chooser, but sets the preference, too.

I’m not sure if that’s a bug or a feature (in GTK+), but Gnome Bugs: 610925: “GtkFileChooserDialog won’t pick show-hidden setting from a GtkBuilder File”: Comment 4 suggests it’s semi-expected behavior (the idle bug Gnome Bugs: 710258: “File chooser dialog saves show-hidden on closure” suggests others found it as a bug, though). Weird. I even tried replacing the above with something that used g_object_set_property to directly change the ‘show-hidden’ property. No dice, it still persists to the setting (when the dialog is closed, as the second bug suggests).

Anyway, I just commented it out in the end since I don’t care if the application file chooser shows hidden files, but do care if nautilus does. The moral of the story is that sometimes the bug is in some other piece of software for no particular reason.

If you find your file browser sometimes showing and sometimes hiding, it’s likely some application you use is toggling it back on you.

Adding Memtest to a Debian Install USB Drive and Menu

I wanted to add Memtest86+ to my debian installer thumb drive, so I am documenting how.

This is meant to work with a USB drive or other bootable media containing the boot.img.gz contents for the Debian Installer. You might be able to shoehorn it in other of the various ways to set up Debian installation media, but this is the simplest.

It’s actually very easy to add Memtest86+ to an existing drive with this setup.

  1. Copy the Memtest86+ kernel over (I named it memtest for simplicity):

    $ cp memtest86+-5.01.bin /media/user/usbdrive/memtest
    
  2. Add a new config (I used memtest.cfg) for Memtest86+:

    label memtest  
        menu label ^Memtest  
        kernel memtest  
    
  3. Include your config in the menu.cfg (I put mine at the bottom):

    include memtest.cfg
    

That’s it. Despite not coming with Memtest86+, it can be easily added to the menu and it works fine.

Some of the other installation media seem to be hostile to this small addition. They have locked partitions or do not have easily-amended menu configurations. That said, maybe Debian Installer will eventually include Memtest86+ by default.