Debian Testing “Bullseye”: The Repository Does Not Have a Release File

After installing Debian Testing "Bullseye" mid March 2020 I got an error trying to run apt update.

E: The repository 'http://security.debian.org./debian-security 
bullseye/updates Release' does not have a Release file.

Unfortunately, the Debian maintainers managed to let a bug creep into the /etc/apt/sources.list. It’s called "Testing" for a reason, I guess.

The offending lines are this.

deb http://security.debian.org/debian-security/ bullseye/updates main
deb-src http://security.debian.org/debian-security/ bullseye/updates main

Note "bullseye/updates", which is where the error is. Change those two lines to look like this.

deb http://security.debian.org/debian-security/ bullseye-security main
deb-src http://security.debian.org/debian-security/ bullseye-security main

After that, the update will work. I have noticed that in a later version of the installer this bug has been fixed.

Debian Testing “Bullseye”: NVIDIA Driver Install

Debian’s documentation on installing the proprietary NVIDIA driver does not (yet) cover the "Bullseye" release because, as of the time of writing, it is still in testing. However, the documentation for Debian 10 "Buster" can still be used.

The main difference is that there is no "backports" for "Bullseye" – although I have found the folders on repo mirrors. At least to me they seemed to be there. Anyway.

What you have to do is to add "contrib" and "non-free" to your main mirror definition, not to backports. You don’t need to add a repo for backports because you’ll only get an error.

(Unfortunately, I haven’t made a note of the error message)

This is what you have to do:

  • Open /etc/apt/sources.list as sudo/root.

  • Add "contrib" and "non-free" to the end of the main repo so it looks like this.

    deb http://deb.debian.org/debian bullseye main contrib non-free

(The observant among you might have noticed that the feature image is from a Pop!OS installation, not Debian. I’ve since changed the distribution.)

The Switching Windows to Linux Experiment

(Beware of the many text)

For the longest time I have been a Windows user. My first computer came with Windows 98 SE (ignoring the Amiga before it) and I’ve used Windows as the main operating system for almost all that time since then. There was a brief excursion into the Apple world for about a year or two, but apart from that: Microsoft’s creation. It’s not that I have not tried using Linux, it’s just that for many years my needs could not be easily satisfied by a Linux based operating system. For one, I have always enjoyed PC gaming and I still do. I’ve tried going with a console, but that was one of the worst decisions I had made in 2019. There also was a long period where I had used my computer as a TV, a time where Youtube and all the other streaming services hadn’t existed. And although I had managed to get the TV tuners to somehow work, it was not comparable to the experience on Windows. For my use case, over all those years, Microsoft’s OS simply was the Vulkan choice. But now in 2020, this isn’t the case anymore. Things have changed, including the maturity of Linux as well as my own needs and my views. Therefore, it’s about time that I revisit this topic.

Read More »

Benchmark RX 570 vs. RX 5700 XT vs. GTX 1660 Super, Ryzen 2600 OC, 3600MHz RAM

At the end of last year, I was researching GPUs like a madman, trying to find the best option for price and performance and maybe also have some headroom for a future CPU upgrade. My starting point was a Ryzen 5 2600, 16 GB of 3000 MHz CL15 RAM and an AMD RX 570 with 8 GB of VRAM. A very good performance per buck machine in the summer of 2019 for 1080p gaming. It was purpose-built to be cheap with an upgrade path in the near future. However, my inner hardware enthusiast didn’t want to be content. It also didn’t help that the two games I was playing at that time performed rather poorly (which was the games fault, but you take every excuse you can get to buy new stuff).

Putting that aside, I have data of three graphics cards to compare, tested in four games at three different in-game settings – plus a custom one for two games that I used for playing. In addition to that, I have a bit of CPU overclocking as a result of troubleshooting and a RAM upgrade from a 3000 MHz CL15 kit to a 3600 MHz CL17 kit – which is running at 3400 MHz. More wasn’t possible with this motherboard and CPU. This post isn’t about the CPU overclocking though. I did that to see if the 5700 XT was limited by the R5 2600 and would perform better with a faster CPU. Well no surprise there, but as it turned out, the numbers I found were not caused by the CPU. More on that later.

Read More »

Far Cry 5 Coop Review

The Far Cry series has been going on for several years now without changing too much of the core game mechanics since the first Far Cry I have played – which was Far Cry 3. What’s new in FC5 is a coop mode that lets you play the main campaign with a buddy. Far Cry 3 had some form of coop as well, but it worked differently by presenting a story unrelated to the game’s single player campaign. I’m not sure how version 4 handled multiplayer, but to my knowledge Far Cry 5 is the first Far Cry to support coop gameplay. It has a few quirks though, which unfortunately still doesn’t make it a 100% coop enabled game. We nevertheless decided to give it a spin and here are my thoughts about the game, its story and gameplay and how the coop experience was.

Read More »

Spring @ConfigurationProperty a Bean or not?

Semi-recently (“semi” because procrastination kept me from writing, so it’s more like two months ago, but blog posts have to start with “recently” when you try to explain yourself why you are writing what you are writing – but I’m getting sidetracked here, so let’s move on) I was wondering whether Java classes annotated with Spring’s @ConfigurationProperty should be declared as a bean, e.g. with @Component. I didn’t find a definitive answer, but I found three ways on how to do it – typical Spring, I guess.

Here’s a quick setup:

My configuration class.

package com.thecodeslinger.configpropsdemo;

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties; 

@Data 
@ConfigurationProperties(prefix = "demo")
public class Configuration {

    private String elegy;
}

My main application:

package com.thecodeslinger.configpropsdemo;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

import javax.annotation.PostConstruct;

@SpringBootApplication
public class ConfigPropsDemoApplication {

   @Autowired
   private Configuration configuration;

   @PostConstruct
   public void postConstruct() {
      System.out.println(configuration.getElegy());
   }

   public static void main(String[] args) {
      SpringApplication.run(ConfigPropsDemoApplication.class, args);
   }
}

And finally, my properties file:

demo.elegy=R.I.P. Kobe

It’s not an elegant setup, but that’s not the point. It does the job for now.

If you run the application in this state, Spring will greet you with an error message.

APPLICATION FAILED TO START

Description:
Field configuration in com.thecodeslinger.configpropsdemo.ConfigPropsDemoApplication required a bean of type 'com.thecodeslinger.configpropsdemo.Configuration' that could not be found.
The injection point has the following annotations:
- @org.springframework.beans.factory.annotation.Autowired(required=true)
Action:
Consider defining a bean of type 'com.thecodeslinger.configpropsdemo.Configuration' in your configuration.

It obviously cannot find the configuration bean.

Option #1: Slap @Component to it.

package com.thecodeslinger.configpropsdemo;

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Data
@Component
@ConfigurationProperties(prefix = "demo")
public class Configuration {

    private String elegy;
}

Option #2: Use the @EnableConfigurationProperties annotation.

import org.springframework.boot.context.properties.EnableConfigurationProperties;

@SpringBootApplication
@EnableConfigurationProperties(Configuration.class)
public class ConfigPropsDemoApplication {

Option #3: Use @ConfigurationPropertiesScan to explicitly name the packages to scan for.

import org.springframework.boot.context.properties.ConfigurationPropertiesScan;

@SpringBootApplication
@ConfigurationPropertiesScan({"com.thecodeslinger.configpropsdemo"})
public class ConfigPropsDemoApplication {

All three options achieve what you’re aiming for, a running application.

:: Spring Boot :: (v2.2.4.RELEASE)
2020-02-03 19:57:43.562 INFO 4612 --- [ main] c.t.c.ConfigPropsDemoApplication : Starting ConfigPropsDemoApplication on DESKTOP-C0O3OKC with PID 4612 (D:\OneDrive\Code\Java\config-props-demo\target\classes started by lober in D:\OneDrive\Code\Java\config-props-demo)
2020-02-03 19:57:43.562 INFO 4612 --- [ main] c.t.c.ConfigPropsDemoApplication : No active profile set, falling back to default profiles: default
R.I.P. Kobe
2020-02-03 19:57:43.921 INFO 4612 --- [ main] c.t.c.ConfigPropsDemoApplication : Started ConfigPropsDemoApplication in 0.573 seconds (JVM running for 1.083)

So, is there any benefit of one over the other? The Spring documentation has the following to say:

Sometimes, classes annotated with @ConfigurationProperties might not be suitable for scanning, for example, if you’re developing your own auto-configuration or you want to enable them conditionally. In these cases, specify the list of types to process using the @EnableConfigurationProperties annotation. This can be done on any @Configuration class, as shown in the following example:

I’m not using a @Configuration class in my example, but if you were, you could leverage that to load your configuration classes based on @Profile annotations. Although @Component works too, it’s not mentioned in that part of the Spring documentation (“Type-safe Configuration Properties”).

For myself, I might go with @EnableConfigurationProperties and if it makes sense, even have dedicated @Configuration classes linked to @Profile. For little samples like this one it’s obviously overkill. In a remotely useful application, the additional overhead may be worth it for structural and documentational reasons.

Ghost Recon: Wildlands – Coop Review

It was a dark night. Rain was pouring relentlessly from the heavens as a helicopter made its way across the border to Bolivia, going unnoticed against the black clouds. Any of the chopper’s noises were suppressed by the droning rain and constant thunder in the sky. Its destination was a remote location, a secret safe house where an equally secret meeting will be held. The helicopter’s passengers were a group of well-trained covert operatives and their handler. These were the kind of people you only call upon in dire need, when circumstances don’t allow anything other than an elite group of soldiers that can get any job done regardless of difficulty or danger. And all that without ever being noticed. They are effectively ghosts and haunt whomever they have been unleashed on. This time around their target is El Sueño, the biggest and most ruthless drug lord in Bolivia.

And this is where you as the player come in. The story is nothing particularly spectacular, but it provides a good enough canvas for an entertaining open world action game that justifies why you do what you do. I’ve played this game all the way to end in coop mode and this my review of the roughly 75 hours it took.

Read More »