Following their introductory video, Linus and Luke are back with part two of their Linux Gaming Challenge. Linus opens by saying the challenge has been “as advertised,” a challenge.

Due to the more focused nature of this video, it isn’t likely that today’s post will end up at the 4000+ length of the previous entry. I think I spent too long writing the last response, as even Drew DeVault had chimed in by the time I’d got my own act together.

This is NOT going Well… Linux Gaming Challenge Pt.2 - 2021-11-23

In this second video, which features considerably less ‘frustrated Linus,’ the pair have to set up their systems for their streaming efforts. Both Linus and Luke stream regularly from their desktops at home, and like it or hate it, streaming is a large part of the modern ‘gamer culture’ that’s here to stay.

The tasks are effectively:

• Set up live comms

• Set up game capture

• Set up audio capture

• Set up face cameras

For their “points” to be scored, their streams have to look “every bit as legit” as they did on Windows. They also make mention of their Elgato Key Lights, which they’ve previously controlled using Windows software. Their solution for these lights however, is to just use the mobile phone app.

Linus

Installing OBS Studio

Opening with an admission that he immediately started by overthinking things, Linus tries to sudo apt-get install obs-studio from his Manjaro installation. This obviously doesn’t work, or rather, it obviously doesn’t work for anybody who’s familiar with Linux, and understands the semi-hierarchical family tree of the various Linux distributions. Manjaro doesn’t have apt and isn’t dpkg based.

This command fails… oops. Linus then has an odd complaint about the message that comes up, as it doesn’t go so far as to suggest he might want pacman instead, pacman being the installer for Arch and Frankenarch installations.

It’s a bit tricky to know what to suggest here, the implication from Linus appears to be that Manjaro should inherently know that the user has just come from a Debian-based distro, or perhaps a Fedora-based, BSD-derivative, or macOS system, and therefore work out that the user wants to invoke the package manager. It’s hard to sympathise with this viewpoint, as it’s not the job of any singular distribution to keep a library list of all the potential package managers a user might have come across, and point them in the right direction.

Is it technically possible? Of course. Is it kind of pointless and needlessly time-consuming? I’d argue yes, other people would probably say “maybe.” Again, Linus admitted that he started by overthinking things, and maybe he was rushing, but starting your task-list by firing up the terminal on a brand new install of an OS you’re unfamiliar with, doesn’t strike me as a very “new user” approach.

Linus says that his command tries to install some dependency for apt, quietly fails, and then prompts you to do the same thing again. I couldn’t recreate this on my Manjaro VM, so I’m not sure what happened here. I get the expected warning that apt-get isn’t found.

Realising his mistake, or perhaps after slowing down (following a sip from his LTT water bottle,) Linus goes to the OBS Studio site and finds that there are “build instructions” for Linux, though Arch and its derivatives are “unsupported,” which means that the builds are community-supported, and not guaranteed in the same way as the Ubuntu builds.

OBS Studio is officially available for Ubuntu 18.04 and newer, another supporting argument for the idea of starting with Ubuntu if you’re new to Linux.

Linus does get OBS Studio installed, though NVENC isn’t available as an encoder option. The screenshot in the video is of a two year old Reddit thread though. I don’t have a free Nvidia GPU to check this claim out. There is quite an extensive thread on the Manjaro forums on the topic, which Linus might have found, though it’s not exactly easy to parse and includes references to kernel patches and downgrading various packages.

Either way, not a simple ‘install and go’ sort of deal, like Windows.

Nvidia

Linus takes a quick sidebar with the viewer, talking about the Nvidia drivers and the Linux community’s general view of Nvidia. It’s fair to say, at this point in time, that the Linux community in general prefers to recommend AMD or Intel for graphics drivers. This is for a combination of factors, which Linus touches on, but it isn’t limited to just the fact that Nvidia’s drivers are closed-source, which adds complexity to their very operation with the Linux kernel.

My own aside here is that I’ve got a lot of respect for the engineers and distribution maintainers who work to make the Nvidia experience as seamless as possible on Linux, given the constraints imposed by big green, which don’t exist with the other two major players in the graphics market. The fact that installations can work with Nvidia is the result of a good deal of effort all round. That’s not to say AMD is perfect by the way, I’ve had at least two recent updates which have caused sporadic graphical glitches with my AMD machine.

Linus mentions the “quality of the product” in relation to Nvidia. Functionality is missing compared to Windows, the interface is confusing, and the control panel looks like it’s from ten years ago. Welcome to the world of Nvidia ownership on Linux.

Software that doesn’t exist

Tools that “don’t exist” are a big problem for Linus, though he mainly means tools that aren’t provided by the manufacturers. If you’ve got a mouse and keyboard from Razor, for example, you’re going to be disappointed if you were hoping for official Linux support; that said, you might find more success with open source or community efforts, like OpenRazer. This does depend on individuals having the time, and drive, to develop the software, which can also include reverse engineering efforts and working against interfaces with little-to-no documentation.

Linux has long suffered from the classic chicken or egg problem. Developers don’t want to “waste” development effort developing their software for Linux, or even testing it in some cases (though it should work out of the box,) and as a result, Linux doesn’t get the users of the software and hardware that it otherwise might. There have been discussions in the FLOSS space that go back decades on how to combat this problem, and honestly, the only sensible solution that’s ever been suggested is for a company to actively produce a product, based on Linux, with mass-market appeal… enter Valve and the Steam Deck.

The solution that Linus comes up with for his own issues is to install Windows in a VM and pass the device though, before configuring it and releasing it from the VM. This is a solution, and can be viable for hardware which has on-board storage for profiles and settings, though it’s obviously less than ideal.

Moving onto his GoXLR deck, which is another example of that ‘streamer’ kit which is probably more ubiquitous than Linux users want to admit, Linus bemoans the fact he’s been unable to get it working with the official software (that doesn’t exist for Linux.) He does find this repository, though then has trouble “downloading” the script from GitHub (a customised git platform that’s favoured by developers) as he’s unfamiliar with the concept.

In the days since the LTT video has been released, the maintainer of the repository has added “LSproof” steps to download and run the script, though they do make use of the terminal, which the LTT hosts have complained about being the ‘default’ for Linux. There’s another article in here in defence of the terminal, which I will promise myself that I will write at some point, but it would easily dwarf any of these comments in scope.

Linus finds a guide on how to run a script, though does go into a slight aside about file association in Linux. As a rule, file association doesn’t mean much to Linux outside of the desktop environment. I can’t add a .sh to the end of a file and have it magically be recognised as an executable file in most scenarios. What you can do, is right click the file, go into its properties, and allow execution. Linus doesn’t appear to appreciate this nuance, but I suspect this is because he’s still treating Windows as his baseline OS.

As mentioned, association is really the desktop environment’s responsibility, and Gnome’s way of dealing with file extensions are “Default Handlers” available in Settings, which associat extensions with certain applications (though again, it won’t make a script executable).

Convenience is subjective, Linux isn’t Windows, and visa versa.

GitHub’s default behaviour gets brought up, as Linus lumps the user experience of GitHub, when right clicking and downloading a file (it downloads the HTML absolute link, instead of the “portrayed” file,) in with Linux as a whole. GitHub, GitLab, SourceHut, and probably others, all default to this behaviour, when you “save” a link, you’re saving the page linked, not the portrayed script.

I don’t really know what to say about this, GitHub isn’t a “file hosting service,” it’s a git service. If Linus has issues with the default behaviour (and I’m not saying I agree or disagree with his points) then the correct company to bring it up with is… well it’s Microsoft.

Despite being a git platform, GitHub has become synonymous with software hacks, scripts, fixes, and general toys. Maybe Microsoft could work on its UX from a non-developer point of view?

Pamac & Discord

Moving to software management again, Linus talks about using Pamac to manage his software installations. I had to check in my VM for the next few comments, so my understanding of this situation is probably lacking, my apologies if I misunderstand anything fundamental about Pamac or the way it’s set up.

Linus mentions having to enable the AUR, Flatpak, and Snap installations in the “Third Party” section of the Pamac settings pane, so that it works similarly to pacman on the terminal. I think something might have got lost in translation here, or my understanding of his needs is wrong, because Discord itself (and the canary build which we’ll get to) is in the “Official Repositories (community)” repository. It doesn’t need Flatpak or Snap, or even the AUR, to be enabled.

Anyway, next Linus talks about having both Discord and Discord Canary (whatever that is…) available to him. I’m a bit surprised that Linus hasn’t come across the idea of a canary build or deployment in the computing space, as they’re fairly well-known terms at this point, though it could be because he doesn’t have much to do with software development. A canary build is usually an “unstable” or nightly build of software, available for a subset of users to use if they want to, to either aid in bug-finding or development. Even Google has a canary build of Chrome available, to those who wish to use it.

The term comes from the old practice of miners taking a canary into a coal mine to check for gas leaks, as the birds are far more susceptible to the noxious gasses than humans are.

It’s possible that Linus is highlighting the fact a canary build shouldn’t be readily available in default repositories, and I’d agree with him that it is a strange decision. It’s also likely that he’s just never come across the term before, because he’s not close to the coal seam of software development.

Linus does praise the per-application volume mixer, though complains about its clunky nature. I have no opinion on this, I don’t daily-drive KDE. He also has another complaint about notification controls not showing up where they’re supposed to, in the Notifications manager, I can’t speak for this much either, though on my XFCE installation, I also couldn’t see the application in notifications, following a logout and login, and even a reboot.

Notifications on Linux still need work, though the situation is a lot better than it was.

Camera Capture

The easiest part for Linus is getting his Camlink 4K up and running, though the first of his duplicated inputs was “garbled” when he first selected it in OBS. He tries the second “source” and is able to get a good picture. It’s “picture perfect,” and works, but there’s definitely a larger up-front investment in getting it working.

Luke

Installing OBS Studio

Luke installs OBS Studio by going into his package manager and installing it. This should probably be the first port of call for anybody starting out with Linux, and is generally the go to for a lot of people. If you’re looking for a piece of software, it’s generally recommended that you check out your distributions default distribution method first; if you latterly discover that the installed version of software is a bit older, or lacking some specific features, then you can look at alternative methods (like Flatpak).

Window capture appears to be a problem immediately for Luke and Linus, and while Luke has an option for it (that doesn’t work) Linus doesn’t even have the option. A few days later this problem seemed to “fix itself” and things worked just fine.

Now I’m not sure if Luke installed the Flatpak or the native version of OBS Studio, but as a test I installed the native version from the Software Manager on my Mint VM. Window Capture in OBS appears to use Xcomposite, and out of the box I was able to capture a Firefox window. This isn’t a good test, I’m in a VM, Luke is on a physical machine, I’m using software rendering, he’s probably using hardware; any number of odd things might have happened in the stack to create our different experiences.

To not count my chickens too early, I went back a step and installed the Flatpak version of OBS, removing the native package first, there’s little to differentiate the two packages at a glance, so it’s possible either might have been the package selected. Sadly I was also able to immediately add a window source for capture, so I can only conclude that there’s some esoteric difference that’s causing problems for Luke and Linus, or there was a bug that just happened to coincide with their installations.

Distributions might start to consider visible use cases of their users, streaming is a very public activity, and if your distro excels at it, you might find a lot of traffic heading your way.

I also tested OBS window capture on a physical machine, with a 4k monitor, and found that the captured “scaled” windows only got the top quarter of the screen, so there’s still a long way to go here.

Audio Issues

Luke’s most notable issue are his audio devices being “screwy” in OBS. His voice is deeper for some reason, and his eventual solution is to restart OBS. Luke does talk about the whole “you don’t have to turn things off and on again” in Linux idea, which isn’t entirely true anyway. This ideal is usually listed as an advantage of the OS as a whole; generally on Linux, you only have to restart the process of an application or service to get updates applied, though this isn’t true in some crucial areas (init system, the kernel itself, core libraries) but the notion persists.

In recent years, a “reboot” practice has actually come to be favoured anyway, with distributions like Fedora preferring to reboot the user into an update environment, from where package changes can be applied without concern, before the computer is booted again into the newly-updated setup.

The concept of “not having to restart it” might be doing more harm to the perception of Linux, than the Linux community realises.

There are positives in Luke’s experience, such as his mixer working out of the box, which is nice to see.

Discord & Screen Sharing

Luke easily installs Discord through Mint’s package manager, though he does point out that screen-sharing across Slack, Teams, and Discord is sketchy at best. This is true, and honestly the slow-migration to Wayland and Pipewire has only compounded the problem of a lack of uniformity on Linux. Steam recently enabled streaming using Pipewire’s native abilities, though it’s been a longtime coming and it isn’t a simple solution that can be applied to all systems.

Teams is a bit better, but that’s again, down to adoption. Microsoft know that for better or worse (as far as they’re concerned,) a lot of developers like to use Linux on their work machines, so they have an actual drive to make the experience usable, even if it’s not on-par with those developers’ Windows and macOS colleagues.

Luke’s complaint that features feel “less stable” is very valid, as Linux is a second-class citizen. Again, I feel like I’m repeating myself a bit here, but it’s still leaps and bounds better than when I started using Linux.

Camera Capture

Luke’s camera software isn’t supported on Linux (back to the chicken or egg problem, see above) and he briefly appears to have debated using a separate capture-setup for the purposes of getting his camera running. Ultimately he opts to simply use his old webcam, and admits that people probably can’t tell for the most part anyway, as he’s usually just a small window in the corner of a game screen.

Conclusions

Luke rounds out the video by saying that in the end “it worked,” and that a random viewer tuning in wouldn’t be able to tell the difference between one of his old Windows streams, and this one. He does say that regardless of the final situation, his experience was made worse by the buggy problems with OBS and Teams (to name a couple of applications.) He admits that it was “easier than he expected” but wasn’t as simple, or clean, as it would have been on Windows.

Linus’ bottom line is around what you’re looking to get out of it, if you want to learn Linux and streaming, then “have at it” and “have fun” though know what you’re getting into. He says Linux gaming requires all the usual cruft (okay, he says mountain of crap) that’s required of PC gaming, with the Linux “mountain of crap” on top of it.

There’s a closing tease of part three, which will feature an attempt to get the top twenty games from Twitch working on Linux… oh boy.

My own conclusion is that streaming is easier on Windows than Linux, but as with most things, that’s not surprising. Up until recently you could game on Linux, in the same way you can cycle across the continental United States, but only lunatics actually want to. Streaming hasn’t yet had the time to mature on Linux, and it’s very-much a catch up game to the position that Windows is in. Linus and Luke both admit that you can make it work, but do you want to write a blog post on your experiences streaming? or do you want to actually stream?

I mean, I apparently prefer writing about other people streaming to both those options, but then I also like Linux, so clearly I’m a glutton for punishment.