Fixed a CI deployment issue. There are no application changes since Beta 1.
32.2 New Features
Replaced add source dropdown with new dialog [Warchamp7]
Improved FPS selector UX [jcm93]
Added missing file support for filters [exeldro]
Added ability for plugins to set custom icons for new source types [cg2121]
Included .webp files when adding a directory to Image Slide Show source [TarunCore]
Added copy paste functions to frontend API [exeldro]
Added filter to compose SDR into HDR [jpark37]
Added delete as a hotkey to delete sources on macOS [PatTheMav]
Added dynamic bitrate support to multitrack video [lexano-ivs]
32.2 Changes
Forced Intel-based installations to update to Apple Silicon version on macOS [PatTheMav]
This change means that OBS Studio versions built for Intel-based Macs but running on Apple Silicon Macs will automatically update to OBS Studio built for Apple Silicon Macs. If an installation was using third-party plugins, those plugins will no longer load until replaced with Apple Silicon versions.
Fixed audio mixer state getting out of sync when changing settings via websockets or plugins [Warchamp7]
Added theming for checked QToolButtons [glikely]
Improved OpenGL performance slightly on low-end machines [kkartaltepe]
Set minimum size for color source to 1 pixel [exeldro]
Added minimum width to spinboxes [Warchamp7]
Disallowed overwriting the crash handler [sebastian-s-beckmann]
Applied process mitigation policies for Windows [notr1ch]
Adjusted description of multitrack video [jhnbwrs]
Changed new capture devices to use fallback frame rate by default [PatTheMav]
Improved DLL loading behavior on Windows [notr1ch]
Limited multitrack video config to Custom service [PatTheMav]
32.2 Bug Fixes
Fixed OAuth and dock state save corruption [PatTheMav]
Fixed group bounds not resizing when removing items [howellrl]
Fixed canvas mixes not being restored after video reset [dsaedtler]
Fixed some erroneous crashes during shutdown [Warchamp7]
Fixed display capture sometimes capturing black after a duplicator failure [ThrowTop]
Fixed color of controls dock output buttons in System theme [shiina424]
Fixed virtual camera reset failures [stephematician]
Fixed potential crash when user discards changes in the settings window [suogesi]
Fixed incorrect return value in virtualcam filter [xtfo]
Fixed source toolbar buttons not working after dragging a source into a group [Warchamp7]
Fixed properties hint icon spacing [Warchamp7]
Fixed potential crash when a video device reconnects on macOS [jcm93]
Fixed an issue where PipeWire could fail on NVIDIA GPUs [hoshinolina]
Today, we're excited to share another episode of our SCS On The Road series, where we travel across North America to meet passionate vehicle owners and gather valuable reference materials for future projects.
This time, our journey brought us to Denton, Texas, where we had the opportunity to experience a true American automotive icon - the 1997 Dodge Viper GTS.
During our visit, we had the chance to document and scan this beautiful car, getting our vehicle artists the accurate reference data needed to faithfully recreate it for the Road Trip project in American Truck Simulator. From its distinctive exterior styling to the finer interior details, every piece of information helps us bring this legendary sports car to life in-game.
This vehicle belongs to Dino, who kindly welcomed our team and generously allowed us to document his prized Viper. We also had the pleasure of having an interview with him, where he shared more about his amazing ride.
The Dodge Viper remains one of the most recognizable American sports cars ever produced, and seeing this exceptionally preserved 1997 example in-person was a fantastic experience for our team.
We would like to extend a sincere thank you to Dino for taking the time to speak with us, sharing his story, and allowing us to scan and capture reference materials from his stunning Viper. Support from owners like Dino is invaluable and helps us create authentic experiences for players around the world.
We hope you enjoy this latest episode of SCS On The Road from Denton, Texas. Be sure to watch the video and learn more about this incredible machine and its owner.
The DistroWatch news feed is brought to you by TUXEDO COMPUTERS. This week in DistroWatch Weekly:
Review: TBlock
News: Arch responds to more AUR attacks, Fedora's growing community, reasons to avoid immutable desktops, Ubuntu 26.10 to get speech recognition, Canonical updates its beta policy, highlights of KDE Plasma 6.7
Questions and answers: What is the significance of the AUR being compromised?
Released....
We are pleased to announce the first release candidate preview release of Jellyfin 12.0!
This is a preview release, intended for those interested in testing 12.0 before it's final public release. We welcome testers to help find as many bugs as we can before the final release.
As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!
A note about versioning
Starting with this release, we are dropping the preceeding 10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was.
Thus, we are now on two digits:
The first digit is the major release. Expect signifiant changes between major releases. Do not ever auto-update to a new major release without first checking the release notes, and always take a backup of your server data and config before a major release upgrade.
The second digit is the minor release. These are primarily bug and security fix releases, and do not introduce significant feature or functionality changes. You can, usually, safely auto-update between minor releases and should not need a full backup, but it is prudent just in case. You should also ALWAYS strive to run the latest point release as security fixes are embargo'd for at most 2 weeks after the release.
What's new?
The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.
There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests.
Note:You must be on Jellyfin 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. I have been informed that I was wrong here, and upgrades from 10.10.7 are also possible, same as 10.11.x!
Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process.
Note: If you install the RC, you should disable all plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.
Installing
This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.
For all non-Docker environments, you can find the files for manual download in our repository by selecting "Stable Preview" for your OS.
For Docker, you can pull the 12.0-rc1 or preview tags.
We are pleased to announce the first release candidate preview release of Jellyfin 12.0!
This is a preview release, intended for those interested in testing 12.0 before it's final public release. We welcome testers to help find as many bugs as we can before the final release.
As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!
A note about versioning
Starting with this release, we are dropping the preceeding 10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was.
Thus, we are now on two digits:
The first digit is the major release. Expect signifiant changes between major releases. Do not ever auto-update to a new major release without first checking the release notes, and always take a backup of your server data and config before a major release upgrade.
The second digit is the minor release. These are primarily bug and security fix releases, and do not introduce significant feature or functionality changes. You can, usually, safely auto-update between minor releases and should not need a full backup, but it is prudent just in case. You should also ALWAYS strive to run the latest point release as security fixes are embargo'd for at most 2 weeks after the release.
What's new?
The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.
There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests.
Note:You must be on Jellyfin 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. I have been informed that I was wrong here, and upgrades from 10.10.7 are also possible, same as 10.11.x!
Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process.
Note: If you install the RC, you should disable all plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.
Installing
This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.
For all non-Docker environments, you can find the files for manual download in our repository by selecting "Stable Preview" for your OS.
For Docker, you can pull the 12.0-rc1 or preview tags.
The seL4 organisation on GitHub uses
git-repo to manage
multiple source repositories, and so there are a large number of
projects to get your head around when figuring out the ecosystem.
As an experiment, I have taken the various manifest files across the
org, and constructed a graph based on how frequently each pair of
repositories is mentioned in a manifest together. See below:
[This may render badly when syndicated outside of my blog; and also
on small screens. And probably large screens. I’ve attempted to make
sure there’s a non-JS fallback –
on my site with JS enabled, if you hover over a node, it should
highlight connected nodes.]
The colouring of the nodes is mostly manual; I experimented with graph
clustering algorithms but have not found a satisfactory result so far.
Still, some clusters are obvious:
Kernel – the seL4 microkernel proper. This often but not
always co-exists with the main cluster of core libraries, but it
is pulled away slightly by the verification and microkit
manifests.
Verification – the verification repositories (l4v, HOL,
graph-refine, polyml, isabelle) form a very distinct group.
These are connected only to the seL4 microkernel itself, which is
the only component formally verified.
Microkit – microkit is a newer operating system framework
that does not use CAmkES, so stands apart from the rest of the
pack. I chose to scope this work to the seL4 org, so the LionsOS
ecosystem and sDDF which are maintained by Trustworthy Systems are
not shown. Also not linked is rust-sel4, because this modern
world isn’t using git-repo in the main to manage its repositories.
RefOS – I’d not come across refos before, but it appears to
be an example OS from 2021 built on the seL4 kernel.
It’s quite hard to pull apart the CAmkES framework and the core
libraries; there are definitely some which are more associated with VM
management, but the overall shape of this co-occurence data is a messy
ball in the middle with some outliers in orbit. One observation is
that camkes is correctly identified as more peripheral than
camkes-tool, which contains the actual core CAmkES code.
Reflecting on this approach, in hindsight I’m surprised that using
co-occurences worked as well as it did – there was no attempt to
actually inspect the code and find direct mentions of other code
e.g. library header dependencies. As the newer microkit effort
largely eschews git-repo, better results might be found by actually
taking that more detailed approach, so that graph edges could
represent real dependencies between two packages. Additionally, this
could allow diving into the various libraries held in the different
’libs’ repos, to get a more granular graph of relationships between
them.
However, I think I spent more time on making it possible to render
graphviz graphs easily on my blog than actually gaining any insight
into the codebase!
Armadillo is a powerful
and expressive C++ template library for linear algebra and scientific
computing. It aims towards a good balance between speed and ease of use,
has a syntax deliberately close to Matlab, and is useful for algorithm
development directly in C++, or quick conversion of research code into
production environments. RcppArmadillo
integrates this library with the R environment and language–and is
widely used by (currently) 1282 other packages on CRAN, downloaded 47.1 million
times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint
/ vignette) by Conrad and myself has been cited 697 times according
to Google Scholar.
This versions updates to the 15.4.0 upstream Armadillo release made on
Thursday. We had run a complete reverse-dependency check leading up to
it, asserting there were no issues with packages dependent on it. As it
sometimes goes with that many packages involved, one CRAN package reported one test
failure. And it turned out to be both unrelated and pre-existing. But
sorting this out over one round of email delayed things by a day. And
then I went cycling
for a good cause so this announcement post comes a little later than
usual. The package has also been updated for Debian, built for r2u, and by now also at
CRAN for the different binary
releases.
All changes since the last CRAN release follow.
Changes in
RcppArmadillo version 15.4.0-1 (2026-06-17)
Upgraded to Armadillo release 15.4.0 (Medium Roast Agave)
Added fill::nan, fill::pos_inf,
fill::neg_inf as optional fill forms for the
Mat class
Added .push_back() for appending elements to
vectors
Faster handling of find() within
.elem()
Faster element-wise min() and
max()
Faster conv_to when element types of input and
output objects are the same
If you are upgrading from v0.16.x, replace the binary (or run docker pull). If you are upgrading from v0.15.x and below, please read the upgrading documentation for more information on how to upgrade from previous versions.
Following up on my previous post, I have released the
debvulns CLI. This utility uses
the same parsing logic as the debsecan-mcp server but exposes the
functionality directly via the command line.
Why a new CLI?
While Debian's native debsecan utility exists, it lacks modern output formats
like JSON and CSV, and fails to expose a significant amount of metadata
available in the Debian Security Team's daily snapshot.
Additionally, running a persistent Model Context Protocol (MCP) server
introduces context window overhead. The manifests and tool descriptions required
by the protocol consume tokens even when idle. For debsecan-mcp, the MCP
Inspector utility shows an
overhead of roughly 150 tokens.
By contrast, an LLM can parse a standard CLI help menu on-demand without
permanently draining the context window. Integrating the CLI into a persistent
agent workflow can be achieved via a skill file, allowing the LLM to leverage the
tool without repeated discovery overhead.
What else is NEW?
During testing, I observed discrepancies between the output of debsecan-mcp/debvulns
and native debsecan. Debugging with an LLM revealed a bug in the version
comparison logic
that caused debvulns to underreport vulnerabilities. This has been resolved.
The current interface supports structured formatting and customizable data backends:
By allowing users to override data sources with local snapshots of the Debian
Security Tracker and EPSS feeds, debvulns can run natively in airgapped
environments.
What Next?
The next step is building a Prometheus exporter for this vulnerability data to
streamline scanning and monitoring across data center infrastructure. Stay tuned.
This version contains security fixes, it is recommended to update to this version immediately.
Important
If you are using Part-DB it would be helpful if you fill out this short survey on your usage of Part-DB (Google Forms): https://forms.gle/Q15twx3YYq3qCNfe8
Part-DB 2.12.3
Security fixes
Fixed missing SVG sanitatization, when file was uploaded with non-svg extension
Added CSP headers to static files, to prevent script execution, should an vulnerable file be uploaded somehow
The DistroWatch news feed is brought to you by TUXEDO COMPUTERS. The PorteuX project has published a new release, version 2.7. The new release includes updates for several desktop environments, including GNOME, COSMIC and Plasma. "First of all, apologies for the long delay. There were some upstream issues that were preventing a stable PorteuX release, most notably the ntfs3....
systemd. Yes, in full lowercase. If there is ever a technology to cause
controversy in the Linux world, this is it. Since its inception in 2010,
systemd’s goals were set quite high — replacing the vital part in every
Linux system that takes care of the system boot process. It quickly reached
maturity, allowing its to be adopted as the main init system in most major
distributions just five years later. But even given we are describing
events that happened over a decade ago, systemd adoption still raises the
temperature in any Linux-related discussion.
David Both’s comprehensive book tackles the “what”, the “why” and the “how”
issues surrounding systemd. Carefully divided in 16 chapters, going from
explaining the basics and some of the technical and political history
behind the project to the different subsystems and aspects covered by
systemd, its almost 450 pages can scare people away — but the text is
written in a very clear, tutorial-like fashion, and while it can be read
sequentially, cover-to-cover, the book is amenable for readers to pick a
single aspect and jump straight to the relevant chapter.
One of the frequent criticisms the systemd project has received is that it
aims to basically rewrite all of a Linux system, and just looking at this
book’s index shows there is some truth to it. The first chapter is an
introduction to the systemd project and a brief overview of its history
(including the controversies around it), and the following four chapters
deal about understanding and controlling the system boot process.
But that still leaves ten chapters to account for — they cover different
aspects or sub-projects of systemd, such as time and date issues
(synchronization, time specifications, and controlling repetitive tasks),
understanding and leveraging the system journal that strongly departs from
the old syslog system, network configuration and firewall management,
system health and performance debugging — all of them, aspects that in the
traditional Unix philosophy were managed by independent programs… And I
can identify several systemd sub-projects not covered by this book!
We long-time Unix and Linux administrators took pride in how highly
performant and stable systems were supported by the simplicity of our
tools; systemd critics point out this massive project has absorbed dozens
of individual tools, yielding corporate control over vast swaths of vital
system tooling. Truth is… as a sysadmin myself, systemd is today one of
my greatest allies.
I appreciate the author evaluates every component independently, including
his personal evaluation of each — even stating he prefers working with the
traditional programs in several areas.
If there is a criticism I must make about this book is that, although
typographically it is well formed and taken care of, given it includes
large amounts of console captures, having a maximum width below 70
characters means several lines are unnaturally cut short (and continued
with odd indentations). I understand there is probably no “right” way to
solve this, but it does affect the feeling of naturally reading the text.
Replaced add source dropdown with new dialog [Warchamp7]
Improved FPS selector UX [jcm93]
Added missing file support for filters [exeldro]
Added ability for plugins to set custom icons for new source types [cg2121]
Included .webp files when adding a directory to Image Slide Show source [TarunCore]
Added copy paste functions to frontend API [exeldro]
Added filter to compose SDR into HDR [jpark37]
Added delete as a hotkey to delete sources on macOS [PatTheMav]
Added dynamic bitrate support to multitrack video [lexano-ivs]
32.2 Changes
Forced Intel-based installations to update to Apple Silicon version on macOS [PatTheMav]
This change means that OBS Studio versions built for Intel-based Macs but running on Apple Silicon Macs will automatically update to OBS Studio built for Apple Silicon Macs. If an installation was using third-party plugins, those plugins will no longer load until replaced with Apple Silicon versions.
Fixed audio mixer state getting out of sync when changing settings via websockets or plugins [Warchamp7]
Added theming for checked QToolButtons [glikely]
Improved OpenGL performance slightly on low-end machines [kkartaltepe]
Set minimum size for color source to 1 pixel [exeldro]
Added minimum width to spinboxes [Warchamp7]
Disallowed overwriting the crash handler [sebastian-s-beckmann]
Applied process mitigation policies for Windows [notr1ch]
Adjusted description of multitrack video [jhnbwrs]
Changed new capture devices to use fallback frame rate by default [PatTheMav]
Improved DLL loading behavior on Windows [notr1ch]
Limited multitrack video config to Custom service [PatTheMav]
32.2 Bug Fixes
Fixed OAuth and dock state save corruption [PatTheMav]
Fixed group bounds not resizing when removing items [howellrl]
Fixed canvas mixes not being restored after video reset [dsaedtler]
Fixed some erroneous crashes during shutdown [Warchamp7]
Fixed display capture sometimes capturing black after a duplicator failure [ThrowTop]
Fixed color of controls dock output buttons in System theme [shiina424]
Fixed virtual camera reset failures [stephematician]
Fixed potential crash when user discards changes in the settings window [suogesi]
Fixed incorrect return value in virtualcam filter [xtfo]
Fixed source toolbar buttons not working after dragging a source into a group [Warchamp7]
Fixed properties hint icon spacing [Warchamp7]
Fixed potential crash when a video device reconnects on macOS [jcm93]
Fixed an issue where PipeWire could fail on NVIDIA GPUs [hoshinolina]
The new version includes changes aiming at improving the defenses of the software against potential HTTP/2 BOMB attacks. It also includes several enhancements.
Today, we’re excited to introduce the team behind the upcoming Soul of Anatolia map expansion for Euro Truck Simulator 2. This upcoming DLC will take drivers on a journey through one of Türkiye’s most diverse and captivating regions, featuring a rich blend of landscapes, historic cities, cultural landmarks, and scenic roads waiting to be explored.
In this edition of Meet the Team, we’d like to give you a closer look at some of the people working on the project. They have prepared a few words about themselves, their roles, and the work they have been focusing on throughout the map's development. We hope you enjoy getting to know the team helping shape the world of Soul of Anatolia.
Ernest - ETS2 Map DLC Lead
"I’ve been working at SCS for seven years now, and during that time I’ve been involved in a wide range of projects. Following the Greece DLC, Soul of Anatolia is my second project as lead. Just as in the past, I’m fortunate to have a very talented and enthusiastic team, whose work, even now in the development stage, shows that Anatolia will once again be a breathtaking DLC. Türkiye is a beautiful country, and everyone on the team is fully committed and proud to bring it to players in the most perfect form possible. I can’t wait to show you more!"
Tomáš - Senior Map Designer
"I joined SCS in December 2017 as a map designer, and I’ve been working in the same role ever since. Over the years, I’ve created many locations in our game world that you can drive through. I played a major role in the creation of cities such as Klaipeda, Andenes, Larissa, Lillehammer, Zadar, Olbia, and Kovrov, and I am currently creating cities for the Soul of the Anatolia DLC. I have also created many roads connecting these cities.
One of the major tasks that is part of my job as a map designer is working on border crossings. If you’ve ever driven through a border crossing in our game, you’ve likely come across my work. At some point, I became a specialist in this area, and I’m now in charge of all work related to borders.
What I enjoy the most about being a map designer is discovering new possibilities for map creation. I always try to get the most out of a specific location and bring as much originality and authenticity as possible into the game world. What brings me the most joy is when a player drives along our roads and recognises places they’ve visited in real life. Euro Truck Simulator 2 is still just a game, but we strive to make the player feel like they’re moving through the real world, and when that feeling comes to the player, it’s a sign to me that I’m doing my job well."
Jakub - Map Designer
"My journey into game development began at SCS four years ago, when I joined the team working on the West Balkans DLC. Since then, I’ve had the opportunity to grow both professionally and creatively while contributing to projects such as the Greece DLC and the Nordic Horizons DLC.
Creating immersive game worlds is where I feel most at home. As a creative person with a keen eye for detail, map design allows me to make the most of my strengths, bringing virtual environments to life and shaping experiences for players to explore.
I specialise primarily in landscapes, expansive scenery, and distinctive locations with unique character and atmosphere. I enjoy finding ways to get the most out of every location and creating a world that feels natural and authentic.
The greatest reward for me is the moment when I see that players are truly enjoying the game and that the world we’ve worked on is able to draw them in.
In addition to designing the game world, I also contribute to the creation of cutscenes and enjoy sharing my experience with my colleagues. I consider the sharing of knowledge across the team to be an important part of our work, as is our collective effort to continually improve the quality of our game.
Soul of Anatolia will be another beautiful and entertaining map DLC. You have a lot to look forward to!"
Klára - Map Designer
"Hi, my name is Klára, and I have been working at SCS for 3 years. During this time, I had the opportunity to be part of the amazing map teams that worked on the Greece DLC and the Nordic Horizons DLC. This time we are going to Türkiye, a country that truly stands out with its breathtaking landscapes, rich history, and unique culture. I am looking forward to capturing its atmosphere and bringing it to our game. Buckle up because this is just the beginning, and there will be much more to see!"
Vlad - Map Designer
"I come from the modding community, where I passionately built map mods for ETS2 for more than 10 years. Now, I have finally decided to join SCS Software, where I've already been working for almost 2 months! As a former experienced logistician and expeditor, SCS' trucking games actually inspired me to study transport and logistics, which led me to work in the logistics industry in the past. On the modding forums, I'm also known by the nickname "Vladzz-G".
Türkiye is my first project at SCS. It is a quite mountainous country, so it’s a great challenge and opportunity to apply my 10 years of mapping experience to represent the region as realistically as possible. Even so, I am still discovering new mapping tricks that make the work easier. Right now, I’m working hard on a coastal city (the name of which I won't reveal just yet!), creating advanced road layouts and doing initial landscape work. It is interesting that a long time ago, I tried to avoid mapping mountainous areas because I thought it would be too difficult, and I mostly preferred mapping flat or gently rolling terrain. But now, I feel quite confident mapping mountains too!
I can't wait to see how this DLC will look in the end, and I'm so excited to share my work with you all when the official DLC releases!"
Ondřej - Junior Map Designer
"Hi, everyone. I've been a fan of city-builders and simulators for a long time now, so a few months ago I decided to join the SCS family as a map designer, which combines both of my favourite genres in one.
Currently, I'm still learning and working on my very first project. The southern part of the Turkish coastline is as beautiful as it is challenging. I think that with its big hills and windy roads, it will be a great visual experience."
Petr - Junior Map Designer
"Hi! I joined SCS Software a few months ago. Ever since I was a kid, I’ve always loved building miniature cities with toy blocks. Today, I’m a huge fan of building and strategy games, and I also love digital drawing. It’s awesome that I get to build worlds for a living!
Soul of Anatolia DLC is my first project. Currently, I’m working on the southern part of the country, which is known for its massive and beautiful mountain ranges. I’m still learning the ropes and gaining valuable experience from my amazing colleagues. I’m doing my best to truly capture the style of the local atmosphere. I’m giving it my all, and I really hope the players will enjoy exploring the new map."
Lucie - Junior Map Designer
"I joined SCS in 2024 as part of the Nordic Horizons team, where I spent most of my time creating roads throughout Finland.
Now, I have the opportunity to work on several cities and interesting locations across Anatolia. Each place has its own distinct character and atmosphere, which makes the work varied and constantly challenging. What I enjoy most is the chance to capture the richness and uniqueness of this region and bring it to life in our game world."
Kristýna - Map Designer
"I joined SCS Software in 2020 and started working on the Iberia DLC, which was then in the middle of production. The last project I had the honour of working on before Anatolia called me was Nordic Horizons. I moved to the south from the towns below the Arctic Circle - there couldn't be a bigger contrast! It is this diversity and learning the peculiarities typical of different countries that keep us curious and eager to present those beautiful places in our game.
I joined the Türkiye team in the pre-production phase. I worked on various tasks across the map and in the process, got to know the variability and diversity of the regions of Anatolia. I was greatly impressed by the traces of rich history in the landscape. Due to the focus of our game on transporting goods, for example, Sultanhani Caravanserai cannot be missing. It is fascinating that sometimes, even at first glance, an ordinary hill, around which we drive, hides an archaeological site of ancient monuments."
Pavel - Map Designer
"Hi, my name is Pavel, and I have been working at SCS Software for almost seven years. As a Map Designer, I have collaborated with many great people on projects such as the Iberia, West Balkans, and Greece DLCs.
Thanks to my passion for roads and driving, I gradually transitioned into the role of a road specialist, contributing my experience to other projects as well, including the Nordic Horizons DLC, the Scandinavia Refresh, and the Benelux Rework.
My goal is always to enrich each project with new ideas and details, such as new prefab types and road accessories, to bring the experience of our virtual world a little closer to the real one. I hope to deliver something special for you in this project as well."
That concludes today’s Meet the Team! We’d like to thank everyone featured in this blog for taking the time to share a little about themselves and their contributions to Soul of Anatolia.
We always enjoy giving our community a glimpse behind the curtain and highlighting the talented people who bring our virtual worlds to life. We hope you enjoyed learning more about the team and the passion driving this project forward.
The system is well designed for space efficiency, both it and the Z640 are 17cm wide but the Z4G4 allows my to close the lid with the Intel Battlemage card installed which doesn’t come close to fitting in a Z640. It has 8 DIMM sockets and with the ready availability of 32G DIMMS that allows 256G of RAM which is the maximum the motherboard supports. That compares well to the Z640 that only has 4 DIMM slots and the Z6G4 which only has 6.
The system supports a maximum RAM speed of DDR4-2666 which is better than the DDR4-2400 of the Z640 but less than the DDR4-2933 of the Z6G4.
The NVMe sockets on the motherboard are a convenient feature. Most systems I run need at most two NVMe devices so this saves a PCIe slot which is important when dealing with GPUs that take 2+ slots. Also for systems that don’t really need NVMe I can use some of the small NVMe devices that I have no other use for. 128G NVMe devices aren’t even worth selling and 256G will be of little use in the near future. So when I move to gen4 Z servers I can use up some of them without wasting slots.
Using the lesser socket LGA2066 in the Z4G4 is a minor annoyance, but for a single socket system 18 cores is probably enough.
The BIOS has an option for single-socket NUMA, which is basically locking cores in a single CPU to specific RAM channels. I enabled it but it did nothing presumably because I only have 2 DIMMs. When I get more DIMMs I’ll do some tests of that and compare it with NUMA on my Z840.
Variants
There are many different variants of the Z4G4 and the only way to recognise them is by the CPU not by any part number or serial number AFAIK. The first difference is between server grade CPUs (the W-2xxx CPUs) and desktop grade CPUs (the i7 and i9 CPUs). The systems with i7 and i9 CPUs don’t support ECC RAM which makes them less reliable, gives smaller limits for RAM
The below table compares the Z640 which is my current desktop PC with the Z4G4, Z6G4, and Z8G4 systems. For the latter 3 I have included multiple options for the parts that differ in different models in the same name series. The Z4G4 I have is an early one which only supports W-21xx CPUs which means a maximum RAM speed of 2666 and the best possible CPU would only be 15% faster than my Z640. I can only use this for ML stuff as it’s the only system I have with REBAR support (which works well).
The Z4G4 doesn’t have any potential for useful upgrades. But for me it was a good cheap way to house a GPU that had already damaged the motherboard of one good system. If the Z4G4 has a PCIe slot break the way my Z840 did then it wouldn’t bother me a lot. It was annoying to discover how limited this variant of the Z4G4 is after buying it, but at that price I can’t complain.
A Z6G4 could be a nice workstation if I found one at a really low price. The only reason I’d seek one out is if I had a need for a desktop workstation with REBAR support, which seems unlikely.
Currently Kitty is my terminal emulator of choice [3]. What I most like about it is the feature of having multiple terminal windows in a single OS window, so instead of having 9 or 16 different xterm instances running all with possible alignment issues I have a single window for all terminals which can be brought to the foreground. The impending 6.7 release of KDE (my favourite Linux desktop environment) [4] includes the feature of per-screen virtual desktops which might be the feature I need to make multiple monitors usable for me. One of the factors stopping me from using multiple monitors in the past was the issue of not getting the alignment of dozens of xterms right if a monitor goes to sleep mode and is regarded as disconnected, moving a few Kitty windows is much easier than moving dozens of xterms (also a tiling window manager isn’t my style).
I’ve just decided that the Terminus font (my favourite out of the monospaced fonts in Debian) is too small for me at 9.0 point. But then I tried 10.0 which looked really ugly and an experiment showed that 10.5 looked good.
Kitty doesn’t and won’t support specifying font size by pixel. I tried some other terminal programs, I started with the Debian Wiki page TerminalEmulator [7] which wasn’t very helpful, I added some new entries to that page. There doesn’t seem to be another option for a terminal emulator with multiple terminals in one OS window that can arrange them automatically. I didn’t even get to the stage of checking whether other terminal emulators supported font size in pixels.
The lcdf-typetools package contains the program otfinfo which gives some interesting information on fonts but nothing about the font sizes in pixels.
Sites like Coding Font to compare fonts [8] can never work properly as the fonts will always be slightly different sizes as the same point size doesn’t mean the same display size.
The Current Situation
On my 5120*2160 monitor with 9 Kitty terminal sessions with 9.0 point font they each have 277*50 characters. With 10 point it’s 237*46 but fuzzy and unpleasant to read. With 10.5 point it’s 208*43 which isn’t as good as I’m used to but is still almost 4.5* as many characters as the original 80*25 standard for terminals.
Some time before 2019 I had a 4*4 array of terminal windows that were 100*25 or 120*25. That left some space at the right and bottom so I could open another 8 or 9 terminals that were partially obscured if I needed to. By 2019 before getting a 4K monitor I had a 3*3 array of terminal windows as my standard desktop and a larger monitor that did 4K resolution allowed me to have 16+ terminals again. Now with Kitty I routinely have 9 terminals in a 3*3 array and I can easily open more if I need them and have them resize appropriately.
This situation works reasonably well, but the element of just trying different sizes in 0.5 point increments until I find something that looks good is unpleasant. I should be able to specify the next largest increment of the bitmaps in the font and just have it look good.
Conclusion
It would be good if more people tested the terminal emulators in Debian and added information to the wiki page about them. The current page is useful but needs more information to support the variety of features that people find important.
We need some tools to provide information on fonts in Debian, such as the sizes of bitmapped fonts.
The whole point size thing is just wrong and would ideally go away. The vast majority of font use nowadays is for things that will probably never end up on a printed page so trying to map it to a physical size in fractions of an inch makes no sense. But that’s just one of many horrible things used for backwards compatibility that aren’t going to go away any time soon. Really everything involving inches should go away.
The DistroWatch news feed is brought to you by TUXEDO COMPUTERS. Home Assistant OS, or HAOS for short, has been upgraded to version 18.0. HAOS is an independently-developed, Linux-based operating system optimised to run Home Assistant, an open-source home automation tool. It is available for several popular platforms, including Raspberry Pi and ODROID, as well as generic x86_64 and....
The diffoscope maintainers are pleased to announce the release of diffoscope
version 320. This version includes the following changes:
[ Chris Lamb ]
* Support androguard 4 and previous versions. Thanks, linsui!
(Closes: #1140016)
* Use --long-form arguments when calling apktool in order to support apktool
version 3. Thanks again to linsui. (Closes: #1140015)
* Update copyright years.
Creating Euro Truck Simulator 2 and American Truck Simulator is a collaborative effort involving many talented teams across SCS Software. While map designers, artists, programmers and more build the driving experience, another team works alongside them to ensure everything functions exactly as intended before players hit the road.
In this Under the Hood blog, we'd like to introduce you to two members of our In-Game QA team, Ivan and David. We asked them about their day to day work, how testing fits into the development process, why quality assurance is about much more than simply playing the game and more!
David - ATS Map QA Lead
"Hey, fellow truckers! My name is David, and I'm 28 years old. I joined SCS as a junior tester when I was just 20, and at the time, I was the youngest employee in the entire company. Today, I'm the QA Lead for ATS map testing. That means I organize and oversee the testing of all ATS map DLCs, communicate with the leads of our map design teams, solve the most complex issues and bugs we encounter, and simply be there for my team whenever they need help. Over the years, I've seen SCS Software grow from a team of around 100 employees into a company of more than 400. When I joined, we were working on the Oregon DLC, and it has been incredible to see how our development and testing processes have evolved and improved alongside our expanding game worlds."
Ivan - World Map Design QA Lead
"Hi everyone! My name is Ivan, and I've been with SCS Software for a little over six years. I started out as a junior tester, but soon after, I took on the responsibility of overseeing map testing for Euro Truck Simulator 2. Today, my role is World Map Design QA Lead, and I manage our entire map testing team, which currently consists of 20 people. Together, we oversee testing for both American Truck Simulator and Euro Truck Simulator 2. While my colleague Davincillo handles the day to day management of ATS, my main focus over the years has remained on ETS2."
When people hear "game testing" they often imagine that you simply get to play games all day. How different is the reality?
"Map testing is definitely not just playing the game all day. That's a classic myth. While the 'playing' aspect certainly has its place, it really only happens during the final stages of our testing process. The reality is far more methodical. We spend hours, or even days, testing one specific part of the map. We drive through the same stretch of road multiple times, checking completely different things on each pass while using different camera views and debug tools.
Simply playing the game is not enough to be a good tester. There is a specific skill set you need, these include attention to detail, a logical and analytical mindset, a good understanding of game industry standards, and a passion for making games more enjoyable for others. Communication skills are also vital because finding a bug is only half of the job. The other half is making sure the right people understand the issue. Ultimately, a good tester should save developers time. Instead of simply reporting that 'something is wrong,' a proper report explains the issue, how to reproduce it, what causes it, and potentially how it could be fixed."
What does a typical day look like for a QA Lead?
"Every day is a little different, but it generally consists of a mix of meetings, coordination, and oversight. Most of my time is spent assigning work, tracking testing progress, reviewing reported bugs, and regularly syncing with developers. Some days are calm and focused on planning, while others are all about solving unexpected, fast-moving issues. A large part of the job involves working closely with the team, discussing the bugs we find, figuring out the best approach, and deciding together what needs the most urgent attention."
What are some of the main things your teams are looking for when testing the game?
"It heavily depends on the stage of production. In the early stages, we focus mostly on the road network itself, its layout, and ensuring the drive is smooth. A big part of this phase is also checking the functionality of the economy and verifying the placement of game elements such as gas stations, companies, and truck dealers. In the later stages, our focus shifts to the AI's ability to navigate the road network, alongside visual polish, correct signage, and core gameplay. This is also when we examine performance across different areas to identify and fix any problematic frame rate drops.
Broadly speaking, we focus on almost everything related to the map. That includes road layouts and collisions, the job economy, gas station distribution, sleep areas and service locations, the UI map and its icons, direction blockers, road markings, traffic signs, speed limits, traffic lights, navigation and voice guidance, garage cutscenes, AI trajectories, triggers, quality consistency, scene logic, terrain, vegetation, world and country borders, asset collisions, gaps in terrain, floating objects, performance-heavy locations, environmental sounds and more!"
What do you enjoy most about working in QA?
"Being a game tester is a dream job for many people, and in many ways, it really is. There is an incredibly rewarding feeling in knowing that you're the safety net protecting the player's immersion and helping make the game better for everyone. It's deeply satisfying to watch a messy, broken build gradually turn into a polished world that millions of people will enjoy driving through.
When a new DLC is released and you see players talking about how smooth the roads feel, how great the scenery looks, or how well everything runs, it's a fantastic feeling. You can look at that and think, 'Yeah, my team helped build that.'"
When a new map DLC or major update enters testing, how do you approach such a large project from start to finish?
"The QA process often begins before production even starts. We provide early feedback on concepts to avoid known issues before development kicks off. Once production begins, we use an agile testing approach, working through multiple iterations throughout development rather than waiting until the very end to deliver one massive list of issues.
Our systematic testing process is divided into four iterations and an economy test. The first iteration focuses entirely on road layouts, ensuring roads, turns, and slopes are safely drivable, even with the longest trailers and low-power engines. The economy test then verifies that companies generate jobs correctly and that cities provide a healthy variety of destinations. As development progresses, later iterations shift towards visual quality, gameplay consistency, and overall polish.
To make testing manageable, we divide each project into smaller sections, sometimes resulting in dozens or even hundreds of individual tasks covering specific roads and cities. These are tracked throughout development, allowing us to revisit the same areas at different stages. We use maps, checklists, internal tools, and bug-tracking systems to ensure every square mile is covered, while also encouraging testers to explore freely because unexpected issues are often found where nobody would think to look."
Many players only see the finished product. Roughly how much testing goes into a map expansion, update, or feature before release? Does it differ depending on what needs testing?
"There is a massive amount of testing involved, and it differs greatly depending on the project. Smaller projects, such as special event maps, can be thoroughly tested in just a few days. On the other hand, a huge project like the Nordic Horizons expansion takes thousands of hours of rigorous testing before it is ready for release.
Every single road, city, company, gas station, sleep area, tollgate, and ferry is tested at least four times, with a different tester each time. To give some insight into the scale, our Mantis bug tracker recorded 6,849 reports for the Illinois DLC, while South Dakota has generated 6,318 reports so far. These reports range from tiny holes in the terrain that are almost impossible to notice to major bugs that can cause the game to crash. Every report is assigned a priority and severity level so that the most serious issues are addressed first."
How closely do QA teams work with map designers, programmers, artists, and other departments throughout development?
"We work very closely across departments because testing is integrated throughout the entire development cycle. As map QA, we collaborate most closely with the map design and art teams. While the majority of our day-to-day communication happens through reports in the Mantis bug tracker, we also actively discuss issues through private messages on our internal chat system, and arrange direct meetings whenever an issue is important enough. Our interaction with the programming department is mostly on a need-to-know basis, usually when there is an issue involving erratic AI behaviour or when a brand-new code feature is being implemented directly into the map." What tools or methods help you track, reproduce, and report issues efficiently?
"We rely on several internal systems that are connected to one another to track individual bugs and the overall progress of a DLC. We use a specialised internal reporting tool that allows a tester to submit a bug directly from the game or the map editor into our central bug-tracking database. Within a few minutes, the report appears and can even be viewed directly inside the map editor itself. This allows map designers to immediately see the exact issue within their active workspace and resolve it much more efficiently, saving a significant amount of time throughout development."
If there's one thing you'd like for people to better understand about QA and the work your teams do, what would it be?
"We'd like players to understand that map testing is a highly skilled, technical job, not simply driving around looking at the scenery or casually stumbling across a floating tree. In reality, a good tester is part detective and part data analyst. If we come across a strange physics bump on a highway or see AI traffic piling up at a roundabout, we don't just report it and move on. We have to understand exactly why it's happening. Translating what is broken on the road into actionable, structured information that our developers can easily understand and fix takes time, patience, and deep knowledge of the game."
What is one aspect of QA work that you think players would be most surprised to learn about?
"Players would probably be surprised by just how much knowledge about the game and real-world infrastructure you need to become a good tester. Our team has to maintain a solid understanding of complex internal game rules, real-world traffic laws, and regional layout standards across different countries.
It's similar to the difference between someone who owns a truck and knows how to drive it and a mechanic who can remove the entire engine, take it apart piece by piece, and put it back together again. Becoming a highly skilled map tester can take years, and many testers naturally become specialists in certain areas of the game because they spend so much time working with those specific systems behind the scenes."
Have you encountered any particularly memorable, unusual, or funny bugs during your time at SCS Software?
Ivan: "Absolutely. Simulators have incredibly complex physics engines, and when things go wrong, they go wrong hilariously. It never gets old seeing an AI vehicle catapulted straight into space. Sometimes, our map designers also leave creative little surprises or jokes for us to discover during development, although we always make sure they don't make it into the live version of the game.
David: "One memorable moment happened while I was parking at a company prefab. I heard a train horn somewhere in the distance, and the sound kept getting louder until suddenly it was right next to me. The only problem was that there was no train there, and there weren't even any railway tracks nearby. A moment later, something invisible hit my truck and launched it all the way across the company. For a few seconds, I genuinely thought I had discovered a haunted company prefab."
How valuable are bug reports and feedback from the community when helping improve the game?
"Community feedback is extremely valuable to us. While our internal QA process is thorough, there are always issues that slip through, and players help us catch them by spotting details or inconsistencies that we might miss. What makes community feedback especially useful is the context players provide. Many are very familiar with the real-world locations we recreate, so they can quickly point out inaccuracies that would otherwise be difficult for us to notice. They also encounter a huge variety of gameplay situations, which helps surface edge cases that are hard to reproduce internally.
"In many cases, a well written report from the community can save us hours of investigation because players provide screenshots, videos, logs, save files, and clear reproduction steps."
Do you have a message for our community?
"A huge thank you for your support, feedback, and for riding along with us for so many years. It's an amazing feeling to work on a game where the players care just as much about the world as the people who build it. Your dedication pushes everyone at the studio to keep raising the bar with every new state, country, and feature. Safe travels, and we'll see you out on the road!"
We'd like to thank both David and Ivan for taking the time out of their busy days to chat with us about their roles in QA and how the team plays such an integral part in bringing our truck simulator titles to life. We hope you've learned a little more about the work that goes on behind the scenes. If you enjoyed this edition of Under the Hood, be sure to leave them a message in the comments below or on our social media channels. Until next time, keep on truckin'!
Log in
