Starfield PC Technology Discussion (Linux + Windows Benchmarks)

In my game reviews, I usually include a section I call “The Nerdy Bits” to examine a game’s technology. I have decided to separate this content from the game review to keep the size manageable. My Marvel’s Midnight Suns review showed me how an expansive technology section can inflate the blog post and maybe even distract from discussing the gameplay, the content, and the story, or potentially deter and intimidate readers because of the total length.

(This blog post is dangerously close to 3000 words πŸ˜‰.)

I firmly believe that technology is a crucial aspect of a video game. Still, sometimes, I can get carried away and focus too much on it. Other people may not be as interested in that or as curious as I am, and they prefer an overview of the gameplay and a brief summary of the visual fidelity.

For me, a lousy running game can break the immersion. Take Elden Ring on the PlayStation 5, for example. My sister bought the game and thinks it runs fine, like many others who believe it to be the greatest thing since sliced bread. I took a 10-second look, turned the camera around one time, and concluded it ran like crap, and I did not want to play this way. Playing for ten to fifteen more minutes solidified this initial perception. This technology discussion is for gamers like me who are also interested in the technical aspects of a video game and base their purchasing decisions on that.

With this explanation out of the way, let me discuss what I think of Starfield’s technology. I will touch on the art style, the visual fidelity and technology, audio, and performance on Windows and Linux.

Please note that this is not a Digital Foundry-level inspection. For that, click here and here.

Read More »

How To Execute PowerShell And Bash Scripts In Terraform

The first thing to know is what Terraform expects of the scripts it executes. It does not work with regular command line parameters and return codes. Instead, it passes a JSON structure via the script’s standard input (stdin) and expects a JSON structure on the standard output (stdout) stream.

The Terraform documentation already contains a working example with explanations for Bash scripts.

#!/bin/bash
set -e

eval "$(jq -r '@sh "FOO=\(.foo) BAZ=\(.baz)"')"

FOOBAZ="$FOO $BAZ"
jq -n --arg foobaz "$FOOBAZ" '{"foobaz":$foobaz}'

I will replicate this functionality for PowerShell on Windows and combine it with the OS detection from my other blog post.

The trick is handling the input. There is a specific way, since Terraform calls your script through PowerShell, something like this echo '{"key": "value"}' | powershell.exe script.ps1.

$json = [Console]::In.ReadLine() | ConvertFrom-Json

$foobaz = @{foobaz = "$($json.foo) $($json.baz)"}
Write-Output $foobaz | ConvertTo-Json

You access the C# Console class’ In property representing the standard input and read a line to get the data Terraform passes through PowerShell to the script. From there, it is all just regular PowerShell. The caveat is that you can no longer call your script as usual. If you want to test it on the command line, you must type the cumbersome command I have shown earlier.

echo '{"json": "object"}' | powershell.exe script.ps1

Depending on how often you work with PowerShell scripts, you may bump into its execution policy restrictions when Terraform attempts to run the script.

β”‚ Error: External Program Execution Failed
β”‚
β”‚   with data.external.script,
β”‚   on main.tf line 8, in data "external" "script":
β”‚    8:   program = [
β”‚    9:     local.shell_name, "${path.module}/${local.script_name}"
β”‚   10:   ]
β”‚
β”‚ The data source received an unexpected error while attempting to execute the program.
β”‚
β”‚ Program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
β”‚ Error Message: ./ps-script.ps1 : File
β”‚ C:\Apps\Terraform-Run-PowerShell-And-Bash-Scripts\ps-script.ps1
β”‚ cannot be loaded because running scripts is disabled on this system. For more information, see
β”‚ about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.
β”‚ At line:1 char:1
β”‚ + ./ps-script.ps1
β”‚ + ~~~~~~~~~~~~~~~
β”‚     + CategoryInfo          : SecurityError: (:) [], PSSecurityException
β”‚     + FullyQualifiedErrorId : UnauthorizedAccess
β”‚
β”‚ State: exit status 1

You can solve this problem by adjusting the execution policy accordingly. The quick and dirty way is to allow all scripts as is the default on non-Windows PowerShell installations. Run the following as Administrator.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine

This is good enough for testing and your own use. If you regularly execute scripts that are not your own, you should choose a narrower permission level or consider signing your scripts.

Another potential pitfall is the version of PowerShell in which you set the execution policy. I use PowerShell 7 by default but still encountered the error after applying the unrestricted policy. That is because the version executed by Terraform is 5. That is what Windows starts when you type powershell.exe in a terminal.

PowerShell 7.4.1
PS C:\Users\lober> Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine
PS C:\Users\lober> Get-ExecutionPolicy
Unrestricted
PS C:\Users\lober> powershell
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\lober> Get-ExecutionPolicy
Restricted
PS C:\Users\lober> $PsVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.22621.2506
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22621.2506
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Once you set the execution policy in the default PowerShell version, Terraform has no more issues.

A screenshot that shows the Windows Terminal output of the Terraform plan command.

And for completeness sake, here is the Linux output.

A screenshot that shows the Linux terminal output of the Terraform plan command.

You can find theΒ source code on GitHub.

I hope this was useful.

Thank you for reading

How To Detect Windows Or Linux Operating System In Terraform

I have found that Terraform does not have constants or functions to determine the operating system it is running on. You can work around this limitation with some knowledge of the target platforms you are running on. The most common use case is discerning between Windows and Unix-based systems to execute shell scripts, for example.

Ideally, you do not have to do this, but sometimes, you, your colleagues, and your CI/CD pipeline do not utilize a homogeneous environment.

One almost 100% certain fact is that Windows addresses storage devices with drive letters. You can leverage this to detect a Windows host by checking the project’s root path and storing the result in a variable.

locals {
  is_windows = length(regexall("^[a-z]:", lower(abspath(path.root)))) > 0
}

output "absolute_path" {
    value = abspath(path.root)
}

output "operating_system" {
    value = local.is_windows ? "Windows" : "Linux"
}

The output values are for demonstration purposes only. All you need is the regex for potential drive letters and the absolute path of the directory. Any path would do, actually.

The regexall function returns a list of all matches, and if the path starts with a drive letter, the resulting list contains more than zero elements, which you can check with the length function.

You could also check for “/home” to detect a Linux-based system or “/Users” for a macOS computer. In those instances, the source code must always be located somewhere in a user’s directory during execution. That may not be the case in a CI/CD pipeline, so keep that in mind. Here is the result on Windows.

A screenshot that shows the Windows Terminal output of the Terraform plan command.

And here on Linux.

A screenshot that shows the Linux terminal output of the Terraform plan command.

You can find the source code on GitHub.

I hope this was useful.

Thank you for reading

Fedora 39/40 Switch Desktop Environment KDE Plasma To Gnome Shell

If you want to do the reverse operation and switch from Gnome Shell to KDE Plasma, I also have a blog post on that.

Replacing KDE Plasma on Fedora 39 requires only a couple of dnf and systemctl commands to convert the Fedora KDE spin into the Default Fedora Workstation with Gnome Shell. It might also work on earlier and later versions.

I have verified these steps on a fresh installation. Be sure to check the console output to avoid accidentally uninstalling any required software if you perform the desktop swap on a productive system.

Start with upgrading all packages. It is generally a good idea when performing such a massive system change.

sudo dnf upgrade

Next, you change the type of the Fedora installation. This is required because Fedora uses package groups and protected packages. You allow removing the KDE package groups by swapping them with the Gnome package groups.

$ sudo dnf swap fedora-release-identity-kde fedora-release-identity-workstation

Last metadata expiration check: 0:19:04 ago on Tue 02 Jan 2024 08:37:17 AM CET.
Dependencies resolved.
==============================================================================
 Package                              Architecture  Version  Repository  Size
==============================================================================
Installing:
 fedora-release-identity-workstation  noarch        39-30    fedora      11 k
Installing dependencies:
 fedora-release-workstation           noarch        39-30    fedora      8.2 k
Removing:
 fedora-release-identity-kde          noarch        39-34    @updates    1.9 k
Downgrading:
 fedora-release-common                noarch        39-30    fedora      18 k
 fedora-release-kde                   noarch        39-30    fedora      8.2 k

Transaction Summary
==============================================================================
Install    2 Packages
Remove     1 Package
Downgrade  2 Packages

Total download size: 45 k
Is this ok [y/N]:

And the second command.

$ sudo dnf swap fedora-release-kde fedora-release-workstation

Last metadata expiration check: 0:20:04 ago on Tue 02 Jan 2024 08:37:17 AM CET.
Package fedora-release-workstation-39-30.noarch is already installed.
Dependencies resolved.
==============================================================================
 Package                              Architecture  Version  Repository  Size
==============================================================================
Removing:
 fedora-release-kde                   noarch        39-30    @fedora     0  

Transaction Summary
==============================================================================
Remove  1 Package

Freed space: 0  
Is this ok [y/N]:

Next, fetch the Fedora Workstation packages and dump them on your storage drive (omitting output for brevity).

sudo dnf group install "Fedora Workstation"

Now that Gnome Shell packages are installed disable SDDM and enable the GDM login manager on boot.

sudo systemctl disable sddm
sudo systemctl enable gdm

At this point, I would log out or reboot and log into the Gnome Shell.

As the final step, you remove the KDE spin packages and the remaining stragglers.

sudo dnf group remove "KDE Plasma Workspaces"
sudo dnf remove *plasma*
sudo dnf remove kde-*
sudo dnf autoremove

Be careful not to mistype sudo dnf remove kde-*! If instruct dnf to remove kde*, it will catch more packages than you would like.

That is all there is to turn the Fedora KDE spin installation into the default Fedora Workstation with the Gnome Shell.

Read More »

Fedora 39/40 Switch Desktop Environment Gnome Shell To KDE Plasma

If you want to do the reverse operation and switch from KDE Plasma to the Gnome Shell, I also have a blog post on that.

Replacing the Gnome Shell on Fedora 39 requires only a couple of dnf and systemctl commands to convert the default Fedora Workstation into the KDE spin. It might also work on earlier and later versions.

I have verified these steps on a fresh installation. Be sure to check the console output to avoid accidentally uninstalling any required software if you perform the desktop swap on a productive system.

Start with upgrading all packages. It is generally a good idea when performing such a massive system change.

sudo dnf upgrade

Next, you change the type of the Fedora installation. This is required because Fedora uses package groups and protected packages. You allow removing the Gnome package groups by swapping them with the KDE package groups.

sudo dnf swap fedora-release-identity-workstation fedora-release-identity-kde

And the second command.

sudo dnf swap fedora-release-workstation fedora-release-kde

Next, fetch the KDE spin packages and dump them on your storage drive (omitting output for brevity).

sudo dnf group install "KDE Plasma Workspaces"

Now that KDE packages are installed disable GDM and enable the SDDM login manager on boot.

sudo systemctl disable gdm
sudo systemctl enable sddm

At this point, I would log out or reboot and log into the KDE session.

As the final step, you remove the Fedora Gnome packages and the remaining stragglers.

sudo dnf group remove "Fedora Workstation"
sudo dnf remove *gnome*
sudo dnf autoremove

That is all there is to turn the default Fedora Gnome installation into the Fedora KDE spin.

Read More »