Trackmania Nightmares

For me the primary takeaway is:

> doing the devops/sysadmin parts of a project is a huge upfront drain.

> Many projects don’t really talk about this. Instead you see a nice README that explains how to do things, but that README that doesn’t reflect the human pain and suffering it took to figure out that the path for your Steam directory depends on the version of Proton you have. You can look at our final instructions (less than three hundred words) and compare it to the literal five months of trying to get things working; that ratio probably isn’t unique to us

I had to move my system to a new SSD with more space, mostly because the great Python venv system makes it that each project takes up between 5Go and 30Go of disk space, so having 224Go was not enough anymore. Nvidia driver didn't install properly so second reboot was to a black screen. Thankfully after some fiddling with packages it worked again. Then the old ways I loaded up ssh-agent didn't work anymore, so it took a few logouts to find a new one. I tried to recompile my CV, but somehow Latex dependencies all changed names, so I had to track down missing packages. Then it still would not compile because the names of the fonts had changed. Configuring the font line was frustrating as xelatex and pdflatex did not expect the same line, and both crashed on a different error that did not lead to an easy solution. When I tried some game on Steam, it just crashed without an explanation. After checking ways to boot it from the CLI -- which is unsupported but search results lead to partial solutions to that problem anyway -- I found that it was possible to add a DEBUGGING argument to the proton command. Searching the error lead to simply find that some lib was missing (actually the challenge was in finding the proper error to search for). I'm the most amazed at this one since this is not in any way "developer software", but a standard user one, for which at least 1 hour of pain would have been removed by an optional dependency.

I'm cutting down the list but it took days to solve every single broken thing.

By coincidence I watched "how to prevent the collapse of civilization" by Johnathan Blow. His point that nobody is surprised anymore that everything breaks and is bugged, it has become the baseline expectation.

> Perhaps the best lesson is this: you just need it to work. On your machine. For now. It doesn’t need to be perfect, just good enough to let you do what you actually want to do.

And that's how you end up with the kind of trail of flakiness that brought them so much trouble. Disappearing tutorials and deprecated plugins are a result of this kind of attitude.

A lot of this honestly sounds like "skill issue" - they're trying to do a cascade of things that is multiple layers of unsupported, and a lot of the problems are ones they've made for themselves (e.g. why not set it up on a local machine first, get your setup steps working there, and then put it on your headless machine, rather than having to deal with Xvnc at the same time as everything else? Why not use a working computer and OS instead of buying a new one?). But also this is what doing real work, especially research, tends to look like. The stuff that is hard is rarely the deep mathematical parts, it's the ops rough edges.

Some context about why http://hallofdreams.org/posts/trackmania-1/

> Many projects don’t really talk about this. Instead you see a nice README that explains how to do things, but that README that doesn’t reflect the human pain and suffering it took [to get working]

This resonates.

This makes me feel better about wasting the last 2 days debugging a failed unit test that was due to duplicate dependencies (with different versions).

  expect(mockDynamoDBClient).toHaveReceivedAnyCommand(); // passes
  expect(mockDynamoDBClient).toHaveReceivedCommand(UpdateCommand); // fails

  Received number of calls: 2
  Expected number of calls: >= 1
  Expected command: UpdateCommand

  Received commands:
    - UpdateCommand
    - UpdateCommand

I thought I was taking crazy pills.

I think the real lesson here is how bad the state of support has gotten. Whenever they tried to reach someone they were forwarded to people who don't know what they're doing, to forums where no one answers, to dead Reddit threads, all while hinting that paying extra may solve their issue.

Imagine a world where you call Verizon and the person on the phone knows what port forwarding is, or where you write on an official Discord channel and someone from the team replies with a fix.

> What’s the problem? Trackmania 2020 is available on Steam, so just install it through Steam and use Lutris. The problem, just like in the Xvfb section, is that there’s a middleman: Steam opens the Ubisoft Connect Launcher, which itself opens Trackmania

Every single time Ubisoft comes up in an article, I'm reminded how much I despise that company.

"Oooh Trackmania, I play that every day, what nightmare tracks are they talking about? Deep Dip 2?"

<clicks link>

"Oh, that's not what I was expecting..."

Too long, didn’t read.

I understand your strugles. However i think that instead of bloatbuntu an arch based solution would be "less hassle" the aur has several solutions for steam in various ways and for me to get trackmania running all it took was a yay -Syyu steam launch steam install trackmania and play. I think when it comes down to doing custumized projects like this arch based distro's seem to be less troublesome in some way or there are packages in the aur that greatly help with customized stuff, alternatively, the heroic games launcher also has trackmania.

I think server based distro's are less "flexible" for custom projects like this under the hood it is all GNU+Linux but i think arch offers more flexibility for customizations. And tbh isnt any harder/unstable/or anything else they say than any other distro. Certainly if you are allready familiar with gnu+linux. I would even recommend arch for beginners. Because of the flexibility and the aur.

however i wont say there wont be any struggles to get it working the way you want to since i have had similar "problems" in the past and i think that that will always be to some degree and you will only learn to solve them faster by experiencing more of them. But as you gain experience it will improve.

it is also a case of knowing what will work and what not. I know that i will always make a python venv instead of a conda one because the conda envoirments are doomed with torch, cuda and glibc and conda envoirments seem to get bigger in size as well however my venvs range from 10 to 30gb as well certainly for something like a comfyui with a ton of custom nodes requiring their depencies.

I understand your struggles and congratulate you on your accomplishments and thank you for sharing your experience since it gonna be helpfull for someone sometime.