Welcome to This Week in Solus, install #48.
This has been an absolutely incredible week for our Snap support. In a matter of a few days, we’ve gone from having no snap gaming runtime to one that’s been battle tested (quite literally) against over 70 titles, with over 60 that are known to be working.
So what makes this gaming runtime so important? Well if you’re a Solus user, you’ve had a pretty stellar experience with Steam and Linux gaming for quite some time, whether it’s having our optimized libraries, a modern and native runtime, or the recent addition of
liblsi-intercept in our Linux Steam Integration tool for enabling a wider variety of titles to work as expected. But if you’ve been using a different operating system, you haven’t necessarily been able to benefit to the fullest extent from all our optimizations and improvements.
But thanks to the power of Snaps, we’re able to bring that same gaming experience to everyone. Snap enables us to provide a “base snap” (recently introduced to snapd), allowing the base layer of an application snap to depend on a snap that isn’t necessarily Ubuntu. Effectively, our base snap is a miniature version of Solus, featuring our optimized Mesa, glibc, SDLs, and various graphical components such as the necessary GTK theming to make Steam look proper. This snap is referred to as
solus-runtime-gaming and is leveraged by our application runtime snap, which features Linux Steam Integration and Steam itself.
To quote our project page:
This is an ongoing effort to produce snaps to provide the Steam client, Linux Steam Integration project, and Solus packages to create a true “universal app” variant of Steam that will work on every Linux distribution in the same way, while mitigating many of the runtime issues.
This isn’t just a “native Steam” effort, LSI is a highly complex project that seeks to replace the runtime almost entirely, and fix many issues. Integrating LSI is also a large undertaking - thus Solus is now seeking to share our work on our own runtime and LSI implementation with the rest of the Linux world for a pain-free and consistent gaming experience.
A large element of this is also to help developers and studios targeting Linux as a platform to have a singular target that would work across all Linux distributions, and provide peace of mind that their games would work as intended. Additionally, as the keepers of LSI, we can rapidly deploy changes to LSI and the runtime to better support the games and alleviate regressions before they hit users.
Our runtime features:
We’re always looking to improve the state of gaming under Linux and part of that means actually testing those games! So we hit the ground running and have tested over 70 titles, with roughly 60 that are known to be working and several that are a work-in-progress.
The above mentioned games are examples of games we’ve tested and do not indicate official support from their respective publishers or developers.
This isn’t the full, comprehensive list of games that are known to work, but we’ll be working to provide a way of submitting your tested games.
This isn’t a full, comprehensive list of games, and may not be up-to-date by the time you’re reading this.
At this stage, we’re considering our runtime a “pre-alpha”. Rome wasn’t built in a day and we’re looking to the broader community to help test across a wider range of operating systems, like Fedora and Ubuntu. It requires getting your hands a bit dirty, but we’ve provided some instructions on our project page on getting started! It will require you to have a
snapd with a few patches that haven’t landed yet but we are hosting and actively updating our runtime and linux-steam-integration snaps, so you likely won’t need to build the runtime and LSI snaps, but rather just follow the instructions below!
Please ensure that before testing, you are using a patched snapd and have rebooted after its installation. For Solus users, it’ll be a matter of
eopkg up as usual, then proceeding to reboot. For non-Solus users, consult the respective documentation for your operating system on building, installing, and enabling snapd prior to rebooting.
Download our snaps with the following commands:
wget https://packages.solus-project.com/lsi/solus-runtime-gaming_0.0.0_amd64.snap wget https://packages.solus-project.com/lsi/linux-steam-integration_0.6_amd64.snap
First, if you already have our Snaps installed (like using this as a reference to update your snaps), run the command below:
sudo snap remove solus-runtime-gaming linux-steam-integration
Then install our snaps:
sudo snap install --dangerous solus-runtime-gaming*.snap sudo snap install --dangerous --devmode linux-steam-integration*.snap
You can run using one of these commands.
To run without any debugging, run
snap run linux-steam-integration
To run with Linux Steam Integration debugging turned on, run:
snap run --shell linux-steam-integration $ export LSI_DEBUG=1 $ $SNAP/linux-steam-integration
Like any early testing, there are some known issues and notes we want to provide.
--devmodeinstall as confinement isn’t finished yet
With our plan to release Solus 4 this month, we’ve created a meta tasklist on what we want to get done before shipping. The full list is available here, but here is a summary of some of the items we want to do.
We’ll be shipping a point release of Budgie 10.4. This will, in comparison to Budgie 10.4 itself, be a fairly minor release, but it won’t be without goodies.
This Budgie release will feature icon tasklist improvements courtesy of Stefan Ric (aka cybre), specifically window grouping and smarter window control / switching (switching windows using the scroll wheel). These options will be configurable so grouping can be disabled.
Solus MATE Edition will see a visual refresh, including to mate-notification-theme-slate and a new Brisk Menu release.
We’ll be performing various stack upgrades such as:
Additionally, we’ll be working on improving the state:
The same Snap technology enabling our gaming runtime will also enable a smoother third-party experience. We’ll be continuing our work on integrating Snaps into the Solus Software Center, replacing our current third party system with them. Meanwhile, we’ll be fixing various issues and addressing some feature requests for the Software Center, such as adding an Update button in the package details page of apps that are already installed.
Over time, elements of the underlying system are prone to change due to the nature of being a rolling release. Traditionally those changes have required manual user-intervention to resolve update issues. Recently an example of this opted to rear its ugly head in Solus.
After upgrades to some packages, including
sane-backends, users were left unable to use their scanners without first using sudo or similar to gain administrative privileges. This was due to the udev rules update requiring users to be in the
scanner group. Similarly, other packages when updated required users to be in the
The problem is, those groups didn’t exist in Solus 3, and there was no way for users to be in those groups. Rather than resorting to an informational blog post with manual intervention instructions, we built a new solution to address this kind of upgrade issue head-on.
qol-assist is a new part of Solus that is designed to help rolling releases to keep rolling. Currently this is responsible for dealing with complex migrations in a controlled fashion - dealing with elements that are typically very hard to do from package install scripts. Right now qol-assist will be triggered to run when first installed, and any time the qol-assist package is updated to provide migrations.
Right now qol-assist is responsible for applying versioned migrations to the system, and was recently used to automatically migrate all human system users with administrative privileges (i.e. in the
sudo group) to the new
scanner groups automatically. This meant that upon rebooting from these updates, users had been automatically migrated without any intervention and things went back to “just works”.
As part of solidifying the core experience, we’re going to expand upon our tooling to provide not only solid upgrade systems, but tooling that can be used for recovery purposes. Currently we have a disconnected set of “post-install” scripts in various packages in the repositories, just like any other distribution. However, this significantly complicates the upgrade process as we cannot gaurantee execution order, nor are these action scripts available for recovery or diagnosis purposes.
Our next steps are to consolidate all of the OS triggers into a new project, which will provide a static binary designed to be entirely immune to potential upgrade issues. Much like
qol-assist it will employ intelligent state tracking to determine exactly which system operations need to be applied, and ensure a sane order of execution. This will be used for everything from simple
ldconfig style updates up to the management of system users.
Additionally, the new trigger system will provide a CLI system to assist in
chroot-style recoveries, so that all system triggers can be applied (and introspected) to bring a system back up to health, without requiring complex bootstrap steps to interact with the package manager. Once this system is integrated we will begin preparing for the replacement of eopkg by completely removing its own configuration system,
COMAR, from normal packaging operations.
An item that isn’t on the Solus 4 agenda, but will be worked on in the coming months, is replacing the
COMAR part of the package manager entirely. Once the trigger system is implemented, the only part of COMAR still being used will be by the Software Center to handle the installation and removal of packages. However, we’ve experienced some issues with this due to an architectural limitation: This service lives on D-BUS. This is common to almost all user-space management daemons for package management, and during their initial design would never have been an issue. However, nowadays we see systemd and dbus both deeply entwined, thus, if one goes down, so does the other. This makes it impossible to safely implement sane restarts of systemd (
daemon-reexec) from within the user session as it would cause D-BUS to restart, nuke the daemon, and in turn take out the Software Center.
To alleviate that architectural weakness and reliance on D-BUS, a new system daemon for software management will be implemented, again designed to be fail-safe and resilient to upgrades, service restarts, etc. This will also allow for managed transactional package management operations in the background, insulated from the effects of the upgrade itself (this also links back into the system triggers).
It should be noted that these changes will reduce much of the surface area of the eopkg codebase back to something far simpler, notably, something that would be trivial to then replace with an improved implementation (we know you guys want support for automatically removing orphan packages). The qol-assist binary, new system triggers, package mux daemon will all come together to provide the required architecture to implement the package management system, and will happen in a serial fashion with a currently unbounded timeline.
When I first started This Week in Solus (which dates clear back to September of 2015), the project was in its early days. We didn’t have any of the fancy infrastructure that we have today, we had a completely different bug tracker and literally emailed in patches. Our Core Team was just Ikey, Justin, and myself. Basically what I’m saying is things were much simpler then.
But while the project has grown massively, TWIS has largely remained the same. It has become the primary place we break news (like the snap news today), with obvious dedicated blogs for new releases of Solus or Budgie, infrastructure posts, and technical pieces from Ikey. However as a result of our accelerated cadence and the size of the project, there have been many instances where we’d be actively working on something, like a massive stack upgrade, then bounce back to writing TWIS and updating its content based on what we were doing that second. Or when we’d have something interesting to talk about in the middle of the week, but defer it for TWIS and leave us in an awkward position of wanting to communicate with everyone in the community about something for days (we’re terrible at secrets).
So, this is the last This Week in Solus. Our blog will have more dedicated pieces. These posts will be under the name “The Roundup” so when we do a bunch of misc. stuff, we can more easily categorize and consolidate it.
Alongside our faster cadence, I’ve wanted a place to highlight people in our community, to share how people empower others by using Solus or how Solus empowers those people, and about people in our community that are using Solus, whether in their personal lives or deploying it in their businesses or schools. Those that take time, sometimes hours every week, to actively improve Solus through translations, bug fixes, updates to various software we build or even ship, etc. The people that make Solus what it is. It isn’t about “what’s the core team and global maintainers done this week” but rather what have we all accomplished, together. There will be a dedicated series for community highlights with no set timeline, and Sundays with Solus will be the thing to listen to if you still crave a weekly talk on Solus news.