jaykstah.com

Hey. Welcome to the first installment of systemDiscourse. This is a series of blogs (and possibly supplemental audio/video posts) that will cover my journeys in the world of Linux, FOSS, and other aspects of workstation and home server configuration. This will range from discussing aspects of my own main Arch install, gaming under Linux, producing music, and more. I’ve decided it would be kinda neat to do a proper series on these topics as there aren’t many people in my main circle of friends who are interested in these topics, so most of the time I spend deep diving is either alone or through the company of Jupiter Broadcasting podcasts among others. It also seems like a good opportunity to do regular writing projects as I am very inconsistent in updating this blog and love writing. So, makes sense, I guess.

This won’t necessarily be a weekly series. Posts will likely cover the most recent week of adventures but due to occasional dips in personal interest or otherwise uneventful stretches of time, I don’t think it’s feasible to squeeze a full blog post out on that regular of a basis.

Without further ado, welcome to my first report / check-in!

I. Gaming!

Without going too far into a tangent on my history of gaming under Linux (I’ll consider doing a dedicated post regarding a more comprehensive history of my journey into the FOSS world) I will give context that I have fully* switched to Arch around 2 years ago, performing the initial install of my setup around October 2019. Prior to that I had spent a few months with Kubuntu installed on my main drive in 2018, which I believe is around the time Proton first hit the scene and began to shake things up with a relatively small, yet notable, exodus of fence-sitters from Windows over to Linux full-time.

While I’ve maintained a Windows 10 install on a spare SSD for specific games with incompatible or invasive anti-cheat (namely Apex Legends and Valorant) I do 99% of my gaming under Arch nowadays. I’m less and less willing to boot into that Windows install for any reason as the days go by, and haven’t at all for a few months now. I was really close to doing so this past week, however, but managed to avoid it.

As some of you out there may know, a reboot for the Saints Row franchise was announced this past week for Gamescom. I, along with one of my lifelong friends, are huge fans of the series. Despite the knee-jerk reaction to a reveal trailer that evidently played it safe, we both found plenty of reason to be excited for what this reboot will bring to the table. In celebration, we decided we’d embark on a fresh co-op play through of Saints Row: The Third (2011), one of the best overall entries in the series. To my surprise, SR3 runs natively on Linux along with the second and fourth games. However, we realized a remastered version of SR3 was also available on PC, and was available for free via the Epic Games store.

SR3: Remastered, however, is not ported to Linux natively. But a glance at ProtonDB assured me that the game would run fine and Lutris makes installing the Epic Games Launcher under wine a breeze. Giddy with excitement to check out this remaster that I didn’t realize had even come out a year prior, I log into Epic Games (begrudgingly) and let the game install. I test it in singleplayer and create a character. Working flawlessly.

This is where the excitement came to a crashing halt. It turns out similarly to Saints Row 2, this remaster has a big problem with co-op, though not in the same way. See, Saints Row 2 has a reasonable excuse. It relied on GameSpy, a multiplayer service for games that has been deprecated for years. In order to play SR2 co-op over WAN, you need to use a VPN service akin to Hamachi to directly connect to one another. Fair enough, works fine. However, SR3: Remastered not only has an allegedly functional backed for multiplayer, it came out in 2020. The GameSpy gone trope does not hold up in this scenario.

Absolutely destroying expectations, SR3: Remastered not only did away with the LAN option for multiplayer, making VPN connection less viable, the co-op function just flat-out does not work most of the time in general. It fails to prompt with invites and host acceptance dialogues. On the rare occasion in which the lobby host is actually prompted to accept a join request, the connection will fail after a brief attempt. The kicker: this problem was not due to my stubbornness in running the game under Linux. It was rampant among Windows users with players suggesting the use of a VPN a la SR2, and even then inconsistencies were common with a user remarking that he and his friend could only connect every other day. Day 1 = not working, Day 2 = working, Day 3 = not working, etc.

After trying multiple VPN services and experimenting with the order of hosting a lobby, loading saves, inviting vs joining off of friends list, we had to give up on the remastered co-op experience. Accepting defeat, we installed the Steam version of the original game. Jaded and expecting troubles, we launch the game. Once it’s up and running, co-op works damn near flawlessly with invites going through Steam.

The only issue I had overall was startup crashes initially. It seems like the Steam version’s DRM relies on some deprecated libraries (I’m assuming) and will crash on startup. After a brief search around it seems like using the Flatpak of Steam rather than the regular runtime I had installed let it work perfectly. Great performance, and co-op is functional.

Moral of the story? While Proton is cool and I’m excited for the work put into it by Valve ahead of the Steam Deck launch, native version of a game prevails. Also, remasters of games really need to stop messing up this badly.

II. A Sea of Shell.sh

A project I’ve really lost myself in lately is a combo of updating my few, fairly lame if I’m being honest, Github repos along with reorganizing scripts and configs on my system. Starting a few days ago, I went through my entire list of packages on Arch, excluding necessary ones, and removed a ton of applications that I no longer use as well as orphaned dependencies. I also went through my entire home directory and its subfolders and reorganized it all. It was tedious yet satisfying. Doing this, though, circled me around to a directory I frequent but never really spend to much time looking at: systemScripts.

Now I won’t pretend like I’m a guru of sudo or am even that competent at writing scripts. However, automating some basic tasks that I frequent has always been fun. Hell, just coming up with entertaining ways to use built-in scripting capabilities on systems has always intrigued me. Since middle school I had been writing basic RPG’s with random encounters, inventory systems, and prompts through a mix of batch scripts, vbs, and config files, but I digress. This time I looked into systemScripts, a directory I’d established early on in my Arch directory for basic automation and startup scripts, and felt a great deal of inspiration come over me, along with a sense of childlike wonder.

“What if I do what I did back in school with batch and write a needlessly complicated script that could show me a menu and be used to launch other scripts?” I ask myself at 1:00AM one night. Then, I proceed to get started.

Currently, my collection of scripts isn’t too mind-blowing. Some basics to change performance profiles of my hardware, adjust the configuration of my JACK server, and adjust configuration of some peripherals. Nothing too crazy. Along with my spontaneous idea to write a script that would act as a hub to launch the others, I had the idea to start writing scripts to handle system configuration, especially in regards to visual theming.

For context, at this point in my journey I’ve fully ditched desktop environments. I’ve settled on i3wm with polybar under Xorg. It works and is comfortable. One thing I always like about DE’s, though, is the ability to use GUI apps to change things like color schemes, mouse cursor themes, icons, etc. Sure, you can use GUI settings apps from Gnome, KDE, etc. while logged into i3 to make these changes, but I wanted to build myself a solution that felt right and fit in better to the aesthetics of my setup. One annoyance as well, was the inconsistent cursor theming between my login screen (SDDM), the i3wm environment itself, and various GTK apps, and the tedium of adjusting settings for each aspect to line up.

Enter: cursorChange.sh. A script I wrote that would use user input for theme names and a range of sed commands to edit a few different config files simultaneously for cursor theme parity. It required a few stop to stackexchange and similar cesspools to get my bearings, being very limited in knowledge of how to achieve what I want to with bash scripts. Once I got it working, though, a sense of achievement that I don’t often experience came over me in stride. I can now run this script, type in the theme I want, and know that all of the relevant config files have been precisely edited. No more running instance after instance of nano to change a single line of a file. I was victorious.

After this victory, I got to work with creating and testing a main menu script, and adjusting my other existing scripts to rely on a centralized file for defining variables. There is still a lot of work to be done in order to get these scripts to interact with each other and automate more tasks but it’s been fun to get back into this hobby with a project like this. Hopefully by the next blog I’ll have some much more interesting results to discuss. Who knows, maybe I’ll graduate from bash scripts to just writing an entire settings application tailored to my specific, finicky desires LOL.

-. Conclusion

Well, that’s all I can think of to mention with this first installment. I think a project like this will be a positive source of catharsis for myself, essentially talking about my various passions in computing with the universe itself. Okay, maybe that description was a bit overboard. Anyways, I will be sure to take mental notes of anything cool I do in the realm of personal computing, FOSS, Linux, and more, to bring anyone who comes across this site an entertaining/interesting read.

See you next time!