Posted on

With WINE, Buying Unsupported (?) Games on Steam

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.

Posted on

Nautilus and Hidden Files

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.

Posted on

Adding Memtest to a Debian Install USB Drive and Menu

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.

Posted on

Debian’s init Options

The Debian Project will choose a new default init system for its next major release (codename Jessie). The debate details (Debian Wiki: Debates: initsystem) include the following proposals:

  1. sysvinit (status quo)
  2. systemd
  3. upstart
  4. openrc
  5. One of the above for Linux, other(s) on non-Linux
  6. Multiple on Linux, at least one for every other kernel

The chief goal in switching? Bring modern boot functionality (speed and lower resource use). Others include lowering the bar for packaging and maintenance, and taking advantage of newer kernel features.

The matter of choosing an init system mainly deals with the amount of work and amount of benefit available. Unfortunately, some aspects of this debate must focus on other things.

The main contenders, systemd and upstart, both have at least one strike against them:

  • systemd looks technologically superior, but that superiority makes it a non-option for at least some non-Linux kernels (owing to using Linux-specific features), and support for other kernels would require much effort. It also takes a different approach to being pid 1, namely rolling in some functionality that has long been outside of init‘s domain.
  • upstart can be supported more readily, but similar if slightly less effort would be required for non-Linux. Worse, Ubuntu’s stewardship of upstart hampers it with the Canonical Contributor License Agreement problem.

A Contributor License Agreement basically states that by signing it, you grant rights of your contributions to the project maintainer. But the Canonical CLA goes a step beyond, in claiming for Canonical the right to relicense the contributions in a non-free manner.

In the Free/Open Source world that makes it as attractive as poison ivy. Also important, some who contribute as part of their work may actively be barred from participation. A company that sees benefit in open source will probably see hostility in their employee’s work being tied into a CLA of this sort (or any sort).

It all adds up to one difficult decision. The fact that both major contenders do not reduce Debian’s workload means the decision will boil down to technical merits. That makes systemd more likely.

What of non-Linux, then? openrc or sticking with sysvinit both seem plausible. Debian likely will not abandon their work with other kernels, so they will likely bite their tongues. Debian will put up with the extra work of dual systems for now. That will also mean that their Linux decision will remain a technical hybrid for the time being.

But not forever. Post-Jessie, I expect Debian will re-evaluate and hopefully find a more useful option to shed some of the extra weight they will take on in the short-term, whether that means configuration conversion tools, or something else.

The main reason that upstart seems unlikely, Ubuntu and Canonical never took the time to lead the way on non-Linux and while some Debian packages might have easier times adopting upstart configurations, the feature set of systemd seems to be a bit more powerful.

Posted on

Cleaning $HOME: XDG Base Directory

Freedesktop.org: Standards: XDG Base Directory Specification is the main document at hand here.

Every now and again the folks that work on free software decide to rearrange a specified or de facto standard directory/file structure with an eye on improving the state of the platform. XDG-basedir is one such attempt, but there have been others like the advent of /run.

The XDG-basedir basically stipulates three locations:

  • $HOME/.config or $XDG_CONFIG_HOME
  • $HOME/.local/share or $XDG_DATA_HOME
  • $HOME/.cache or $XDG_CACHE_HOME

These are meant for your configuration files, data, and caches. These locations provide for some flexibility and improved organization over throwing everything in your $HOME. For example, your caches may be kept in a virtual path that points to RAM or on a SSD that is faster than your regular storage. Or your configurations may be on some networked disk.

Lots of applications support this specification in some way, though some more than others. To take advantage of this specification requires first looking to see what dot folders and dot files (ie, those named like .foo) exist in your $HOME. While you’re at it you may look in the above-mentioned folders to see what applications have already set up shop in their new locations.

Some applications will have moved their baggage themselves. Other applications implement the standard to whatever degree, but give precedent to the old location, the old dot files. They do this out of pragmatism. They don’t have to write a migration scheme, and they don’t confuse their long-term users who may not know or want to know about these new locations.

For these applications, moving the files yourself (or if the data/configuration/cache does not matter, simply deleting the existing file(s)) works fine.

For others, those that do not support the specification, you can often still move them if you define their environment to point to the proper location(s).

An example of the latter is Mercurial, the distributed source control system. It does not support XDG-basedir, but it does support the environment variable HGRCPATH. By properly setting it, export HGRCPATH=${XDG_CONFIG_HOME}/hg/hgrc (or the full path if you do not have XDG_CONFIG_HOME defined), you get the benefit of the specification without Mercurial actually supporting it.

In cleaning my own $HOME I found this sort of fix was useful for about six applications including vim and gnupg.

Still other applications do not support an environment variable to specify where their files live. Some of these will accept configuration file locations from the command line. For these, setting shell aliases or functions may help. I found this useful for only one or two applications.

Some applications have support for it in versions newer than I have installed. I let these wait, glad to know of the effort.

And quite a few applications have open (or closed) bugs for supporting XDG-basedir. In most cases this is less about the technical work for the specification and more about deciding if and how to support it. At least a handful of the applications I looked at were reticent to support it at all. Others said support would be welcomed given enough background to show what would/not break and with a patch available.

But several argued about how far they would support it. This mostly came down to applications willing to move their lot into $HOME/.config (or wherever $XDG_CONFIG_HOME), but not split out cache and/or data. It seemed this was more often argued against for portability reasons (ie, they support Microsoft Windows operating systems and want to allow their users to move their files between them or have them on one common drive without issue).

And in rare cases files are hard to nail down. They sort of configure, but they’re sort of data. Or they’re sort of data, but they’re sort of cache. (Hopefully never all three in one.)

On the whole I was able to reduce my number of dot files by about 15, and the number of dot directories by about 60.

At least a full half of the files and folders I lost were obsolete entries from applications that I no longer use. Another chunk were applications that wrote their configurations even though I used all default options. The rest were from applications that now support XDG-basedir or had other acceptable workarounds for moving their files.

I find this an interesting topic to look at given that the change to applications is not overly complex, but it affects a wide variety of applications. I also like having a cleaner $HOME as it makes finding things easier.

Maybe my next step will be to audit my XDG directories as I’m sure they contain some files from applications I no longer use.