Ok. So I did the game jam and the results are … well not that great but I believe the ratings are inline with what was delivered. Now that the Jam is over I’d like to take some time to reflect on my choices made during the Gam Jam.
The Experience
This was a great learning experience and the provided feedback is a good starting point for improving the project going forward. Most of the feedback was for things that I wanted to do but just ran out of time.
Linux Game Jam 2023 has just started and I’m going to do my best to publish an entry this year. I’ve entered many game jams in the past and life has always found a way to prevent me from completing an entry.
I’m going to put this out into the universe.
This year, I’m going to finish and submit a simple game.
Linux Game Jam does not have a theme so my options are wide open. I already have a base concept that I think will provide some flexibility and , if time allows, extensibility.
We have a long running pipeline that has worked without issue for years on CentOS 7 however after a recent upgrade to Rocky 9 we began noticing that the pipeline was starting to fail. The application being tested would start with no issue at the begining of the test run but as time passed the application would fail to start due to not being able to find a valid JAVA_HOME environment variable.
Introducing Downtime Arcade. Downtime Arcade is a place where we can unwind and relax after a hard day at the day job and the side-job.
Downtime Arcade is a casual gaming channel focused on primarily single player experiences. Games will be played on Linux when possible. Recorded content will be on YouTube and live content will primarily be on Twitch.
Content will be published under the Downtime section.
I’m updating the theme from the previous Hyde theme to Terminal. There will be a few visual glitches as I work through the change but the basics are in place.
The syntax highlighting is still a work in progress.
Add the process id to the desired cgroup’s cgroup.procs file.
# create cgroup
sudo mkdir /sys/fs/cgroup/testgroup
# enable cpu interface
echo "+cpu" | sudo tee -a /sys/fs/cgroup/cgroup.subtree_control
# enable cpuset interface
echo "+cpuset" | sudo tee -a /sys/fs/cgroup/cgroup.subtree_control
# add current process to cgroup
echo "$$" | sudo tee -a /sys/fs/cgroup/testgroup/cgroup.procs
What happend to the prompts?
Prompts were an interesting concept but I’ve decided not to pursue them at this time. This is mainly a choice in how I want to spend my time.
At the end of the day, what do I want to accomplish? My main goal is to produce applications and libraries. Prompts would take my focus away from this goal.
The basic commands are nearly identical to the commands you would use to build a container with dockerd(moby). The main difference is that unlike dockerd, containers built with nerdctl are not available in Kubernetes by default.
To build a container that is available in Kubernetes you must specify the k8s.io namespace
# -n specifies the k8s.io namespace
nerdctl -n k8s.io build . -f containerfile -t app:0.0.1
# the container is visible inside Kubernetes
kubectl create deployment quick-test --image=app:0.0.1
Linux distributes system resources using control groups (cgroup) which the kernel.org defines as
cgroup is a mechanism to organize processes hierarchically and distribute system resources along the hierarchy in a controlled and configurable manner. [1]
There are currently two versions of cgroup in use today and due to historical and compatibility reasons version 1 and version 2 of cgroups can coexist as long as there are no overlaps between which controllers are being managed.
How many cores are on my system?
This is a seemingly simple question. We’d like to use the number of available processors to determine how many jobs we can safely run in parallel. Linux provides various ways to fetch the number of available processors including:
- nproc
- lscpu
- /proc/cpuinfo
> nproc
32
> lscpu | grep ^CPU\(s\)\: | awk '{print $2}'
32
> grep --count "processor" /proc/cpuinfo
32