Author Archives: Lorenzo Bettini

About Lorenzo Bettini

Lorenzo Bettini is an Associate Professor in Computer Science at the Dipartimento di Statistica, Informatica, Applicazioni "Giuseppe Parenti", Università di Firenze, Italy. Previously, he was a researcher in Computer Science at Dipartimento di Informatica, Università di Torino, Italy. He has a Masters Degree summa cum laude in Computer Science (Università di Firenze) and a PhD in "Logics and Theoretical Computer Science" (Università di Siena). His research interests cover design, theory, and the implementation of statically typed programming languages and Domain Specific Languages. He is also the author of about 90 research papers published in international conferences and international journals.

Stop VS Code’s Java LSP from Rewriting Your Eclipse .classpath with m2e-apt Entries

Leave a reply

How to prevent JDT LS (via m2e) from adding generated-sources APT folders and org.eclipse.jdt.apt prefs to an Eclipse+Maven project in VS Code.

If you open a Maven Java project in Visual Studio Code that also contains Eclipse project metadata (.project, .classpath, .settings/…), you might notice that VS Code’s Java tooling (JDT Language Server) “helpfully” edits your Eclipse files.

In particular, it may keep re-inserting entries like these into your .classpath:

<classpathentry kind="src" path="target/generated-sources/annotations">
  <attributes>
    <attribute name="optional" value="true"/>
    <attribute name="maven.pomderived" value="true"/>
    <attribute name="ignore_optional_problems" value="true"/>
    <attribute name="m2e-apt" value="true"/>
  </attributes>
</classpathentry>

<classpathentry kind="src" output="target/test-classes" path="target/generated-test-sources/test-annotations">
  <attributes>
    <attribute name="optional" value="true"/>
    <attribute name="maven.pomderived" value="true"/>
    <attribute name="ignore_optional_problems" value="true"/>
    <attribute name="m2e-apt" value="true"/>
    <attribute name="test" value="true"/>
  </attributes>
</classpathentry>

</attributes>

</classpathentry>

</attributes>

</classpathentry>

…and it may also create this file:

.settings/org.eclipse.jdt.apt.core.prefs

eclipse.preferences.version=1
org.eclipse.jdt.apt.aptEnabled=false

eclipse.preferences.version=1

org.eclipse.jdt.apt.aptEnabled=false

VS Code Java support is powered by Eclipse JDT Language Server (JDT LS). When it detects Eclipse metadata (.project / .classpath), it will often use Eclipse-style project configuration and keep it synchronized.

For Maven projects, JDT LS relies on m2e (the “Maven integration for Eclipse”), and in many setups m2e-apt is present as well. m2e-apt is the component that manages annotation processing (APT) integration and, as part of that, it adds the standard “generated sources” folders into .classpath.

I find that very annoying!

If your project doesn’t use annotation processing and you don’t want these Eclipse files constantly modified, and you remove the entries, Visual Studio Code will re-add them when you open the projects in Visual Studio Code. If you open the projects from Eclipse and you “update” the Maven projects, Eclipse will remove the entries… and so on and so forth!

Here’s how to fix things for good.

The fix: disable m2e-apt at the project level

m2e-apt supports overriding its activation per-project using a Maven property:

<m2e.apt.activation>disabled</m2e.apt.activation>

1	<m2e.apt.activation>disabled</m2e.apt.activation>

Add this to your `pom.xml`

Put it under the regular Maven <properties> section:

<project>
  ...
  <properties>
    <m2e.apt.activation>disabled</m2e.apt.activation>
  </properties>
</project>

...

<m2e.apt.activation>disabled</m2e.apt.activation>

</properties>

</project>

That’s it. After this, m2e-apt will stop treating your project as something it should manage, and VS Code/JDT LS will no longer keep reintroducing those APT-related .classpath entries.

Note: The documentation mentions a “settings section” in the POM. There is no settings element in pom.xml; Maven “settings” live in ~/.m2/settings.xml. In the POM, this is implemented via a property, so properties (or a profile’s properties) is the right place.

Refresh VS Code so it stops regenerating the files

After editing the POM, VS Code may still have cached the project configuration. Do this once:

Open the Command Palette
Run: Java: Clean Java Language Server Workspace
Let the Java server restart and re-import the project

Then you can delete the unwanted entries/files one last time:

Remove the APT-related classpathentry … m2e-apt … blocks from .classpath
Delete .settings/org.eclipse.jdt.apt.core.prefs if you don’t want it around

They should not come back.

If you only want to disable it in certain environments, you can place the property in a Maven profile or in the pom file of a single project.

Happy (quiet) classpaths! 😉

LaTeX listings: Eclipse colors

Leave a reply

This is the style I use to highlight my Java code in LaTeX documents with the Listings package, with Eclipse colors:

% Colors for code highlighting according to the Eclipse default theme
\definecolor{keywordColor}{rgb}{0.5, 0, 0.33}
\definecolor{commentColor}{rgb}{0.25, 0.5, 0.35}
\definecolor{stringColor}{rgb}{0.16, 0, 1}
\definecolor{numberColor}{rgb}{0, 0, 0}

% Color style
\lstdefinestyle{mystyle}{
    flexiblecolumns=true,
    keepspaces=true,
    tabsize=4,
    showstringspaces=false,
    basewidth={0em,0em},,
    numbers=left,
    basicstyle=\scriptsize,
    numberstyle=\color{numberColor},
    commentstyle=\color{commentColor}\itshape,
    stringstyle=\color{stringColor}\ttfamily,
    keywordstyle=\color{keywordColor}\bfseries,
}

% Colors for code highlighting according to the Eclipse default theme

\definecolor{keywordColor}{rgb}{0.5, 0, 0.33}

\definecolor{commentColor}{rgb}{0.25, 0.5, 0.35}

\definecolor{stringColor}{rgb}{0.16, 0, 1}

\definecolor{numberColor}{rgb}{0, 0, 0}

% Color style

\lstdefinestyle{mystyle}{

flexiblecolumns=true,

keepspaces=true,

tabsize=4,

showstringspaces=false,

basewidth={0em,0em},,

numbers=left,

basicstyle=\scriptsize,

numberstyle=\color{numberColor},

commentstyle=\color{commentColor}\itshape,

stringstyle=\color{stringColor}\ttfamily,

keywordstyle=\color{keywordColor}\bfseries,

}

And this is an example of a document, where I show the same listing both with black and white colors an Eclipse colors:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc} % not needed on XeLaTeX/LuaLaTeX
\usepackage{xcolor}
\usepackage{listings}

% Colors for code highlighting according to the Eclipse default theme
\definecolor{keywordColor}{rgb}{0.5, 0, 0.33}
\definecolor{commentColor}{rgb}{0.25, 0.5, 0.35}
\definecolor{stringColor}{rgb}{0.16, 0, 1}
\definecolor{numberColor}{rgb}{0, 0, 0}

% Color style
\lstdefinestyle{mystyle}{
    flexiblecolumns=true,
    keepspaces=true,
    tabsize=4,
    showstringspaces=false,
    basewidth={0em,0em},,
    numbers=left,
    basicstyle=\scriptsize,
    numberstyle=\color{numberColor},
    commentstyle=\color{commentColor}\itshape,
    stringstyle=\color{stringColor}\ttfamily,
    keywordstyle=\color{keywordColor}\bfseries,
}

% Black and white style
\lstdefinestyle{mystylebw}{
    flexiblecolumns=true,
    keepspaces=true,
    tabsize=4,
    showstringspaces=false,
    basewidth={0em,0em},,
    numbers=left,
    basicstyle=\scriptsize,
    commentstyle=\itshape,
    stringstyle=\ttfamily,
}

\begin{document}

\section*{Demo}

With the default black and white style:

\begin{lstlisting}[language=Java,style=mystylebw]
// A simple Java program
class Demo {
        public static void main(String[] args) {
            System.out.println("Hello, world!");
        }
}
\end{lstlisting}

\noindent
With the color style:

\begin{lstlisting}[language=Java,style=mystyle]
// A simple Java program
class Demo {
        public static void main(String[] args) {
            System.out.println("Hello, world!");
        }
}
\end{lstlisting}

\end{document}

\documentclass{article}

\usepackage[T1]{fontenc}

\usepackage[utf8]{inputenc} % not needed on XeLaTeX/LuaLaTeX

\usepackage{xcolor}

\usepackage{listings}

% Colors for code highlighting according to the Eclipse default theme

\definecolor{keywordColor}{rgb}{0.5, 0, 0.33}

\definecolor{commentColor}{rgb}{0.25, 0.5, 0.35}

\definecolor{stringColor}{rgb}{0.16, 0, 1}

\definecolor{numberColor}{rgb}{0, 0, 0}

% Color style

\lstdefinestyle{mystyle}{

flexiblecolumns=true,

keepspaces=true,

tabsize=4,

showstringspaces=false,

basewidth={0em,0em},,

numbers=left,

basicstyle=\scriptsize,

numberstyle=\color{numberColor},

commentstyle=\color{commentColor}\itshape,

stringstyle=\color{stringColor}\ttfamily,

keywordstyle=\color{keywordColor}\bfseries,

}

% Black and white style

\lstdefinestyle{mystylebw}{

flexiblecolumns=true,

keepspaces=true,

tabsize=4,

showstringspaces=false,

basewidth={0em,0em},,

numbers=left,

basicstyle=\scriptsize,

commentstyle=\itshape,

stringstyle=\ttfamily,

}

\begin{document}

\section*{Demo}

With the default black and white style:

\begin{lstlisting}[language=Java,style=mystylebw]

// A simple Java program

class Demo {

public static void main(String[] args) {

System.out.println("Hello, world!");

}

\end{lstlisting}

\noindent

With the color style:

\begin{lstlisting}[language=Java,style=mystyle]

// A simple Java program

class Demo {

public static void main(String[] args) {

System.out.println("Hello, world!");

}

\end{lstlisting}

\end{document}

Here’s the result:

Browse and run your Sway keybindings with Rofi

1 Reply

Remembering every Sway shortcut is tough. I wrote a small script that parses your Sway config, displays all bindsym shortcuts in a clean, searchable list via Rofi, and executes the command associated with whichever one you select.

It’s fast, keyboard-friendly, and great for discovery: “What did I bind to Mod + Shift + P again?” Now you can search, see, and execute it.

What the script does

Reads your Sway config from $XDG_CONFIG_HOME/sway/config (or ~/.config/sway/config)
Finds all bindsym … lines
Formats each entry nicely, e.g.

Mod + Return → exec alacritty

Shows the list in a wide Rofi dmenu
When you select an entry, it executes the associated command through swaymsg

Dependencies

sway (for swaymsg)
rofi
awk, sed, grep (standard on most distros)
notify-send (optional – shows an error if the config isn’t found)

The script

Save this as ~/.local/bin/rofi-sway-keybindings.sh and make it executable.

#!/usr/bin/env bash

# This script lists Sway keybindings from the Sway config file and allows the user to select one via rofi dmenu.
# When a keybinding is selected, it executes the associated command.

CONFIG_FILE="${XDG_CONFIG_HOME:-$HOME/.config}/sway/config"

# Check if config file exists
if [[ ! -f "$CONFIG_FILE" ]]; then
    notify-send "Sway Keybindings" "Config file not found: $CONFIG_FILE" -u critical
    exit 1
fi

# Parse keybindings from config file
# Format: "Mod+Key → Command description"
keybindings=$(grep -E '^\s*bindsym' "$CONFIG_FILE" | \
    grep -v '^[[:space:]]*#' | \
    sed 's/^\s*bindsym\s*//' | \
    awk '{
        # Remove trailing inline comments
        sub(/\s+#.*$/, "")

        # Skip leading flags like --release, --locked, etc.
        i = 1
        while (i <= NF && $i ~ /^--/) { i++ }
        if (i > NF) next

        # Extract the key combination
        keys = $i; i++

        # Extract the command (remaining fields)
        cmd = ""
        for (j = i; j <= NF; j++) {
            if (j > i) cmd = cmd " "
            cmd = cmd $j
        }

        # Format: "Key → Command"
        # Clean up common modifier names for better display
        gsub(/\$mod/, "Mod", keys)
        gsub(/Shift/, "⇧", keys)
        gsub(/Control/, "Ctrl", keys)
        gsub(/\+/, " + ", keys)

        printf "%-35s → %s\n", keys, cmd
    }')

# Show in rofi and get selection
selected=$(echo "$keybindings" | rofi -i -dmenu -p "Sway Shortcuts" -theme-str 'window {width: 60%;}')

# If something was selected, extract and execute the command
if [[ -n "$selected" ]]; then
    # Extract the command part (after the arrow)
    command=$(echo "$selected" | sed 's/^[^→]*→\s*//')

    if [[ -n "$command" ]]; then
        # Execute the command through swaymsg
        swaymsg "$command"
    fi
fi

#!/usr/bin/env bash

# This script lists Sway keybindings from the Sway config file and allows the user to select one via rofi dmenu.

# When a keybinding is selected, it executes the associated command.

CONFIG_FILE="${XDG_CONFIG_HOME:-$HOME/.config}/sway/config"

# Check if config file exists

if [[ ! -f "$CONFIG_FILE" ]]; then

notify-send "Sway Keybindings" "Config file not found: $CONFIG_FILE" -u critical

exit 1

# Parse keybindings from config file

# Format: "Mod+Key → Command description"

keybindings=$(grep -E '^\s*bindsym' "$CONFIG_FILE" | \

grep -v '^[[:space:]]*#' | \

sed 's/^\s*bindsym\s*//' | \

awk '{

# Remove trailing inline comments

sub(/\s+#.*$/, "")

# Skip leading flags like --release, --locked, etc.

i = 1

while (i <= NF && $i ~ /^--/) { i++ }

if (i > NF) next

# Extract the key combination

keys = $i; i++

# Extract the command (remaining fields)

cmd = ""

for (j = i; j <= NF; j++) {

if (j > i) cmd = cmd " "

cmd = cmd $j

}

# Format: "Key → Command"

# Clean up common modifier names for better display

gsub(/\$mod/, "Mod", keys)

gsub(/Shift/, "⇧", keys)

gsub(/Control/, "Ctrl", keys)

gsub(/\+/, " + ", keys)

printf "%-35s → %s\n", keys, cmd

}')

# Show in rofi and get selection

selected=$(echo "$keybindings" | rofi -i -dmenu -p "Sway Shortcuts" -theme-str 'window {width: 60%;}')

# If something was selected, extract and execute the command

if [[ -n "$selected" ]]; then

# Extract the command part (after the arrow)

command=$(echo "$selected" | sed 's/^[^→]*→\s*//')

if [[ -n "$command" ]]; then

# Execute the command through swaymsg

swaymsg "$command"

How it works

The core of the script is a small text-processing pipeline that reads the config and renders a nice two-column list for Rofi:

grep -E '^\s*bindsym' finds all bindsym lines (ignoring leading whitespace)
grep -v '^[[:space:]]*#' ignores full-line comments
sed 's/^\s*bindsym\s*//' strips the leading bindsym
awk splits the line into (and does some cleanup):

– keys: the first token (e.g. $mod+Return)
– cmd: the rest of the line (e.g. exec alacritty)

It also strips trailing inline comments (after #) and skips bindsym flags like --release or --locked before reading the key. Finally, it prettifies modifiers and prints a fixed-width column so the arrows line up.

Rofi presents that list with -dmenu. When you pick one, the script extracts the command part (after →) and sends it to swaymsg. That means anything you can put after bindsym (like exec …, workspace …, kill, etc.) will run on demand.

Usage

Run the script from a terminal: rofi-sway-keybindings.sh
Or bind it to a key in your Sway config, e.g.:

bindsym $mod+slash exec ~/.local/bin/rofi-sway-keybindings.sh

1 2	bindsym $mod+slash exec ~/.local/bin/rofi-sway-keybindings.sh

Tip: the window is set to 60% width for readability; tweak it via -theme-str if you prefer.

Nice touches in the UI

Replaces $mod with Mod
Shows Shift as ⇧ and Control as Ctrl
Adds spacing around + so chords read clearly: Mod + ⇧ + q
Aligns the left column to 35 characters for a tidy two-column look

Why this is handy

Onboarding: perfect for new setups or when you come back after a while
Discovery: search by key or by command to find what you already have
Launcher: use it as a programmable “cheat sheet” that also runs things

Here are some screenshots (including filtering):

Modern Java in LaTeX listings (Java 17)

Leave a reply

If you use the LaTeX listings package to typeset Java, you’ve probably noticed that modern Java has moved faster than the package itself. Records, var, and text blocks may not highlight correctly out of the box. The good news: the listings package is extensible so that you can teach it “modern Java” with a tiny language definition.

The minimal language extension for Java 17

Here’s a drop‑in snippet that builds on the stock Java lexer to support key Java 17 features:

\lstdefinelanguage{Java17}{
        language     = Java,
        morekeywords = {var,record},
        deletekeywords={label},
        morestring=[b]"""
}

\lstdefinelanguage{Java17}{

language = Java,

morekeywords = {var,record},

deletekeywords={label},

morestring=[b]"""

}

What each line does:

language = Java: inherit all of the listings’ built‑in Java rules.
morekeywords = {var,record}: colorize var and record as keywords (var is contextual, but highlighting it improves readability in code listings).
deletekeywords = {label}: avoid mistakenly highlighting labeled statements like label: for (…) { … }. label is not a Java keyword; removing it prevents false positives.
morestring=[b]”””: treat triple quotes as a balanced string delimiter so Java text blocks highlight as a single string.

Using it in your document

Activate the language globally:

\lstset{language=Java17}

1	\lstset{language=Java17}

…or per listing:

\begin{lstlisting}[language=Java17]
// code here
\end{lstlisting}

\begin{lstlisting}[language=Java17]

// code here

\end{lstlisting}

If you already have a custom style (e.g., mystyle) with colors and fonts, combine them:

\lstset{language=Java17, style=mystyle}

1	\lstset{language=Java17, style=mystyle}

Minimal working example

This is a compact MWE you can compile with pdflatex, xelatex, or lualatex. Adjust the style to your taste:

\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc} % not needed on XeLaTeX/LuaLaTeX
\usepackage{xcolor}
\usepackage{listings}

% Simple, readable default style
\lstdefinestyle{mystyle}{
    flexiblecolumns=true,
    keepspaces=true,
    tabsize=4,
    showstringspaces=false,
    basewidth={0em,0em},,
    numbers=left,
    basicstyle=\scriptsize,
    commentstyle=\itshape,
    stringstyle=\ttfamily,
}

% Modern Java language extension
\lstdefinelanguage{Java17}{
    language=Java,
    morekeywords={var,record},
    deletekeywords={label},
    morestring=[b]"""
}

\begin{document}

\section*{Demo}

With the default \texttt{Java} language definition:

\begin{lstlisting}[language=Java,style=mystyle]
record Point(int x, int y) {}

class Demo {
        public static void main(String[] args) {
                var msg = """
                        Hello,
                        Java 17 "text blocks!"
                        """;
                System.out.println(msg);

                label: for (int i = 0; i < 1; i++) {
                        break label; // 'label' is not highlighted as a keyword
                }
        }
}
\end{lstlisting}

\noindent
With the \texttt{Java17} language definition:

\begin{lstlisting}[language=Java17,style=mystyle]
record Point(int x, int y) {}

class Demo {
        public static void main(String[] args) {
                var msg = """
                        Hello,
                        Java 17 "text blocks!"
                        """;
                System.out.println(msg);

                label: for (int i = 0; i < 1; i++) {
                        break label; // 'label' is not highlighted as a keyword
                }
        }
}
\end{lstlisting}

\end{document}

\documentclass{article}

\usepackage[T1]{fontenc}

\usepackage[utf8]{inputenc} % not needed on XeLaTeX/LuaLaTeX

\usepackage{xcolor}

\usepackage{listings}

% Simple, readable default style

\lstdefinestyle{mystyle}{

flexiblecolumns=true,

keepspaces=true,

tabsize=4,

showstringspaces=false,

basewidth={0em,0em},,

numbers=left,

basicstyle=\scriptsize,

commentstyle=\itshape,

stringstyle=\ttfamily,

}

% Modern Java language extension

\lstdefinelanguage{Java17}{

language=Java,

morekeywords={var,record},

deletekeywords={label},

morestring=[b]"""

}

\begin{document}

\section*{Demo}

With the default \texttt{Java} language definition:

\begin{lstlisting}[language=Java,style=mystyle]

record Point(int x, int y) {}

class Demo {

public static void main(String[] args) {

var msg = """

Hello,

Java 17 "text blocks!"

""";

System.out.println(msg);

label: for (int i = 0; i < 1; i++) {

break label; // 'label' is not highlighted as a keyword

}

\end{lstlisting}

\noindent

With the \texttt{Java17} language definition:

\begin{lstlisting}[language=Java17,style=mystyle]

record Point(int x, int y) {}

class Demo {

public static void main(String[] args) {

var msg = """

Hello,

Java 17 "text blocks!"

""";

System.out.println(msg);

label: for (int i = 0; i < 1; i++) {

break label; // 'label' is not highlighted as a keyword

}

\end{lstlisting}

\end{document}

Here’s the result, where you can see the differences (note in the standard behavior the wrong highlighting of the double-quoted string in the text-block):

Happy highlighting! 🙂

Getting Your MacBook Air Webcam Working on Linux

Leave a reply

If you’ve installed Linux on your MacBook Air, you’ve probably discovered that while most hardware works out of the box, the built-in FaceTime HD camera is notably absent from your video applications. Don’t worry—you’re not alone, and there’s a solution that doesn’t involve external USB webcams or complicated workarounds.

The issue stems from Apple’s use of Broadcom’s proprietary FaceTime HD camera hardware. Unlike most standard USB webcams that work with Linux’s UVC (USB Video Class) drivers, the MacBook Air’s camera uses a PCIe interface with the Broadcom 1570 chipset, which requires specialized drivers that aren’t included in the Linux kernel.

Identifying Your Hardware

Before diving into the solution, let’s confirm you have the same hardware. Open a terminal and run:

lspci -nn | grep Cam

1 2	lspci -nn \| grep Cam

If you see output similar to this, you’re dealing with the same Broadcom camera:

02:00.0 Multimedia controller [0480]: Broadcom Inc. and subsidiaries 720p FaceTime HD Camera [14e4:1570]

1 2	02:00.0 Multimedia controller [0480]: Broadcom Inc. and subsidiaries 720p FaceTime HD Camera [14e4:1570]

The key identifier here is [14e4:1570]—this tells us we have the Broadcom 1570 chipset that needs the reverse-engineered driver.

The Solution: Community-Developed Drivers

Thanks to the hard work of the Linux community, reverse-engineered drivers are available through the Arch User Repository (AUR). These drivers have been developed by analyzing the hardware behavior and creating open-source alternatives to Apple’s proprietary drivers.

If you’re using an Arch-based distribution (like EndeavourOS, Manjaro, or plain Arch), you can search for the available packages:

yay -Ss facetime

1 2	yay -Ss facetime

This will show you several packages:

facetimehd-dkms: The main reverse-engineered driver
facetimehd-firmware: Required firmware files extracted from macOS
facetimehd-data: Sensor calibration data for optimal performance
facetimehd-dkms-git: Development version of the driver

The installation is straightforward. Install the main driver package:

yay -S facetimehd-dkms

1 2	yay -S facetimehd-dkms

The package manager will automatically pull in the required dependencies, including the firmware and calibration data packages.

After installation, you must reboot your system. This isn’t just a suggestion—the kernel module needs to be loaded fresh, and the hardware needs to be properly initialized during the boot process.

sudo reboot

1 2	sudo reboot

Once your system boots back up, your webcam should be functional. However, there’s an important caveat to be aware of.

While the driver successfully enables the webcam, there are some compatibility quirks:

Google Chrome/Chromium: Works perfectly
Firefox: May not detect the camera
Native Linux applications (like Kamoso): May have issues

This inconsistency likely stems from the different ways in which various applications interact with the video4linux (V4L2) subsystem and handle the specific quirks of this reverse-engineered driver.

Maintaining KDE dotfiles with Chezmoi Modify Manager

1 Reply

I have already blogged about managing KDE dotfiles with chezmoi and chezmoi_modify_manager. But what about maintaining them?

For example, one of the KDE configuration files changes, and you want to update the version managed by chezmoi.

Here’s an example where the Kate configuration file changed on the system and chezmoi detects that:

❯ chezmoi status
MM .config/katerc

1 2	❯ chezmoi status MM .config/katerc

You can see the change with “chezmoi diff”:

diff --git a/.config/katerc b/.config/katerc
index 3a67fa38f0ba021369d48ace9803e4f7f2e55657..17d7ffff36b8526c4ab14f03942e8a14c64c19d3 100600
--- a/.config/katerc
+++ b/.config/katerc
@@ -201,7 +201,7 @@ Legend=false
 LineNumbers=false

 [UiSettings]
-ColorScheme=BreezeDark
+ColorScheme=Breeze Dark

 [filetree]
 editShade=74,55,117

diff --git a/.config/katerc b/.config/katerc

index 3a67fa38f0ba021369d48ace9803e4f7f2e55657..17d7ffff36b8526c4ab14f03942e8a14c64c19d3 100600

--- a/.config/katerc

+++ b/.config/katerc

@@ -201,7 +201,7 @@ Legend=false

LineNumbers=false

[UiSettings]

-ColorScheme=BreezeDark

+ColorScheme=Breeze Dark

[filetree]

editShade=74,55,117

Remember that the part with “+” is the version known by chezmoi, while the one with “-” is the version in the local system.

You now want to update the corresponding file managed by chezmoi.

The command “chezmoi re-add” won’t help because that file is handled by chezmoi_modify_manager, which splits it into two files: “modify_private_katerc” and “private_katerc.src.ini”.
The latter contains only the parts of the file we want to track, and the former is the corresponding modification script.

Moreover, “chezmoi merge” won’t help either for the same reason. Here’s what this command shows (I configured chezmoi to use the GUI program “meld” for such a command):

However, “chezmoi_modify_manager” has an option for such situations. Here’s the option to use with “chezmoi_modify_manager”:

-s, --smart-add        Smartly add a file to be tracked by either chezmoi or
                       chezmoi_modify_manager

1 2	-s, --smart-add Smartly add a file to be tracked by either chezmoi or chezmoi_modify_manager

Here’s the command and the output:

❯ chezmoi_modify_manager -s ~/.config/katerc
State: Managed by chezmoi and is a modify script.
Action: Updating existing .src.ini file for /home/bettini/.local/share/chezmoi/dot_config/modify_private_katerc.
Has existing modify script, parsing to check for filtering...
Writing out file data

❯ chezmoi_modify_manager -s ~/.config/katerc

State: Managed by chezmoi and is a modify script.

Action: Updating existing .src.ini file for /home/bettini/.local/share/chezmoi/dot_config/modify_private_katerc.

Has existing modify script, parsing to check for filtering...

Writing out file data

By using “chezmoi cd” and “git diff”, we can verify that the corresponding “.src.ini” file has been correctly updated (and the git repository can then be committed and pushed):

diff --git a/dot_config/private_katerc.src.ini b/dot_config/private_katerc.src.ini
index 8e5db59..a54672b 100644
--- a/dot_config/private_katerc.src.ini
+++ b/dot_config/private_katerc.src.ini
@@ -193,7 +193,7 @@ Legend=false
 LineNumbers=false

 [UiSettings]
-ColorScheme=Breeze Dark
+ColorScheme=BreezeDark

 [lspclient]
 AllowedServerCommandLines=

diff --git a/dot_config/private_katerc.src.ini b/dot_config/private_katerc.src.ini

index 8e5db59..a54672b 100644

--- a/dot_config/private_katerc.src.ini

+++ b/dot_config/private_katerc.src.ini

@@ -193,7 +193,7 @@ Legend=false

LineNumbers=false

[UiSettings]

-ColorScheme=Breeze Dark

+ColorScheme=BreezeDark

[lspclient]

AllowedServerCommandLines=

In the end, it’s easy, once you know the right option to use with “chezmoi_modify_manager”!

Enjoy your KDE dotfiles! 🙂

Configure Tmux to support true color and italics in Alacritty and Neovim

Leave a reply

I know there are many blog posts about configuring Tmux to support true color and italics in Alacritty, but many of them miss a crucial detail that breaks Neovim’s diagnostic undercurl (wavy underlines).
Many of them suggest overriding the TERM variable in Alacritty to xterm-256color, which causes Neovim to lose the ability to display undercurl correctly.
Many of them are also outdated or incomplete.

This is how I configured Tmux and Alacritty to work perfectly together, supporting true color, italics, and Neovim’s undercurl diagnostics.

The Problem

When using Tmux inside Alacritty, you may encounter several issues:

No True Color Support: Colors may appear washed out or limited to 256 colors instead of the full 24-bit RGB spectrum
Italics Not Working: Italic fonts don’t render correctly, or reverse video appears instead
Neovim Diagnostic Undercurl: Neovim’s diagnostic undercurl (wavy underlines) shows as simple underlines instead

These issues stem from incorrect TERM environment variable configuration and missing terminal capability overrides.

For example, using the shell script linked below to check true color support, when it’s not working, you get (left: Tmux inside Alacritty, right: Alacritty by itself):

When it works, you get:

The Solution

1. Alacritty Configuration

DO NOT override the TERM variable in Alacritty. Leave it at the default value alacritty.

# DON'T DO THIS or Neovim will not show undercurl correctly (only underline)
# Leave the default value, which is `alacritty`
# [env]
# TERM = "xterm-256color"

# DON'T DO THIS or Neovim will not show undercurl correctly (only underline)

# Leave the default value, which is `alacritty`

# [env]

# TERM = "xterm-256color"

Why? Alacritty’s default TERM=alacritty includes the terminfo capabilities for undercurl, which Neovim needs to display diagnostic wavy underlines. Setting it to xterm-256color breaks this feature.

2. Tmux Configuration

Add the following lines to your ~/.tmux.conf:

# Enable 256-color and true-color (24-bit) support in tmux
# And also italics
set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",*:Tc"

# Enable 256-color and true-color (24-bit) support in tmux

# And also italics

set -g default-terminal "tmux-256color"

set -ga terminal-overrides ",*:Tc"

Explanation:
– default-terminal "tmux-256color": Sets tmux to use a terminal type that supports 256 colors and italics
– terminal-overrides ",*:Tc": Tells tmux to enable true-color (24-bit RGB) support for all terminal types that support it

3. Why This Works

When you start tmux inside Alacritty:
– Alacritty sets TERM=alacritty (which supports true color and undercurl)
– Tmux creates a new environment with TERM=tmux-256color (which supports italics)
– The terminal-overrides setting tells tmux to pass through true-color escape sequences from the outer terminal (Alacritty)

This combination gives you:
– True color (24-bit RGB) support
– Italic fonts working correctly
– Neovim undercurl diagnostics rendering properly

Verification

To verify everything works:

Check true color support:

curl -s https://raw.githubusercontent.com/JohnMorales/dotfiles/master/colors/24-bit-color.sh | bash

1 2	curl -s https://raw.githubusercontent.com/JohnMorales/dotfiles/master/colors/24-bit-color.sh \| bash

Check italics:

echo -e "\e[3mThis text should be italic\e[0m"

1 2	echo -e "\e[3mThis text should be italic\e[0m"

Check in Neovim:

Open a file with syntax errors or any diagnostics (including spelling errors)
You should see wavy underlines (undercurl) for diagnostics, not simple underlines

References

How we used Maven relocation for Xtend

Leave a reply

In Xtext release 2.40.0, we adopted Maven relocation to move Xtend Maven artifacts’ groupIds from org.eclipse.xtend to org.eclipse.xtext without breaking existing consumers.

References:

Rationale

Xtend’s Maven coordinates were relocated to comply with Maven Central’s new publishing requirements after the OSSRH sunset.

The new Maven Central publishing portal enforces namespace consistency: all artifacts in a single deployment must share the same groupId prefix (namespace). We were getting this error when trying to deploy:

Deployment failed:
- Deployment contains files for multiple namespaces: org.eclipse.xtend, org.eclipse.xtext

Deployment failed:

- Deployment contains files for multiple namespaces: org.eclipse.xtend, org.eclipse.xtext

Xtend Maven artifacts historically had groupId org.eclipse.xtend, while all other Xtext Maven artifacts use org.eclipse.xtext. This mismatch prevented us from publishing both in a single deployment to Maven Central.

See the detailed rationale in issue #3398 and specifically this comment.

Why relocation instead of just renaming

Backwards compatibility: Existing builds continue to resolve, emitting a clear warning rather than failing.
Gradual migration: Library and plugin maintainers can update on their own schedule.
Single source of truth: Only the new artifact publishes real content; the old coordinate becomes a lightweight stub POM.
Clear deprecation signal: A relocation message is more explicit than a silent artifact disappearance.
No breaking changes: Consumers don’t need to update immediately; their builds keep working.

Maven relocation basics (summary)

Maven relocation allows you to redirect artifact coordinates without breaking existing consumers.

The process involves:

Real artifacts with the new groupId that contain actual JARs, source, and javadoc
Relocation artifacts with the old groupId that are minimal POMs pointing to the new coordinates

A relocation artifact is a simple POM project with this structure:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>OLD.GROUP</groupId>
  <artifactId>ARTIFACT_ID</artifactId>
  <version>2.x.y</version>
  <packaging>pom</packaging>
  
  <distributionManagement>
    <relocation>
      <groupId>NEW.GROUP</groupId>
      <!-- artifactId stays the same -->
      <!-- version stays the same -->
    </relocation>
  </distributionManagement>
</project>

<groupId>OLD.GROUP</groupId>

<artifactId>ARTIFACT_ID</artifactId>

<groupId>NEW.GROUP</groupId>

</relocation>

</distributionManagement>

</project>

At resolution time, Maven automatically replaces the old coordinates with the new ones and displays a warning to the user.

Our goals

Preserve build stability for all existing Xtend consumers
Minimize maintenance by publishing only one real artifact per logical module
Provide a clear migration path with visible warnings
Avoid transitive duplication (both old + new coordinates ending up on classpath)
Comply with Maven Central’s namespace requirements

Implementation outline

Our implementation involved several steps (see PR #3461 for details):

Identify artifacts to relocate: All Xtend artifacts published to Maven Central under org.eclipse.xtend: org.eclipse.xtend.lib, org.eclipse.xtend.lib.gwt,org.eclipse.xtend.lib.macro, etc.

Create relocation parent POM: Created org.eclipse.xtend.relocated.parent to organize all relocation artifacts.

For each artifact, create a relocation POM module with:
– Packaging: pom
– Old groupId: org.eclipse.xtend
– Same artifactId and version as the original
– Relocation block pointing to org.eclipse.xtext

Separate publishing workflow: Since Maven Central requires same-namespace deployments, we had to:
– Build relocation artifacts separately
– Archive deployment bundles for manual upload
– Publish relocation artifacts in a separate step from main artifacts

Update CI/CD scripts: Modified Jenkins deployment scripts to handle both artifact sets.

Example relocation POM

Here’s a real example from our implementation:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  
  <parent>
    <groupId>org.eclipse.xtend</groupId>
    <artifactId>org.eclipse.xtend.relocated.parent</artifactId>
    <version>2.40.0</version>
  </parent>
  
  <artifactId>org.eclipse.xtend.lib</artifactId>
  <packaging>pom</packaging>
  
  <name>Xtend Library (relocated)</name>
  <description>
    This artifact has been relocated to org.eclipse.xtext:org.eclipse.xtend.lib
  </description>
  
  <distributionManagement>
    <relocation>
      <groupId>org.eclipse.xtext</groupId>
      <!-- artifactId remains org.eclipse.xtend.lib -->
      <!-- version remains the same -->
    </relocation>
  </distributionManagement>
</project>

<project xmlns="http://maven.apache.org/POM/4.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

http://maven.apache.org/xsd/maven-4.0.0.xsd">

<groupId>org.eclipse.xtend</groupId>

<artifactId>org.eclipse.xtend.relocated.parent</artifactId>

</parent>

<artifactId>org.eclipse.xtend.lib</artifactId>

<name>Xtend Library (relocated)</name>

This artifact has been relocated to org.eclipse.xtext:org.eclipse.xtend.lib

</description>

<groupId>org.eclipse.xtext</groupId>

</relocation>

</distributionManagement>

</project>

When a consumer uses the old coordinates, Maven shows:

[WARNING] The artifact org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.40.0
has been relocated to org.eclipse.xtext:org.eclipse.xtend.lib:jar:2.40.0

[WARNING] The artifact org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.40.0

has been relocated to org.eclipse.xtext:org.eclipse.xtend.lib:jar:2.40.0

Ensuring no duplicate classes

Because the relocation artifact is only a stub POM with no JAR attached, the classpath will contain only the new artifact. This prevents:

Duplicate classes on the classpath
Class shadowing issues
Version conflicts between old and new coordinates

Maven and Gradle both handle this correctly by fetching only the relocated target.

Publishing workflow

The key challenge was Maven Central’s namespace requirement. Our solution:

Main build: Publishes all org.eclipse.xtext artifacts (including the real Xtend artifacts with new groupId)
Separate relocation build: Publishes all org.eclipse.xtend relocation POMs
Validation: We performed dry-run deployments to verify Maven Central would accept the artifacts
Manual upload: For milestone releases, we archived bundles and manually uploaded them to Maven Central

As noted in the PR discussion, we had to update version-bumping scripts to include the new relocation parent directory.

Migration guidance for consumers

Search your builds for the old groupId:
– Maven: mvn dependency:tree | grep org.eclipse.xtend
– Gradle: ./gradlew dependencies --configuration compileClasspath | grep org.eclipse.xtend

Replace org.eclipse.xtend with org.eclipse.xtext in your POMs or build.gradle files:

   <!-- Old -->
   <dependency>
     <groupId>org.eclipse.xtend</groupId>
     <artifactId>org.eclipse.xtend.lib</artifactId>
     <version>2.40.0</version>
   </dependency>
   
   <!-- New -->
   <dependency>
     <groupId>org.eclipse.xtext</groupId>
     <artifactId>org.eclipse.xtend.lib</artifactId>
     <version>2.40.0</version>
   </dependency>

<groupId>org.eclipse.xtend</groupId>

<artifactId>org.eclipse.xtend.lib</artifactId>

</dependency>

<groupId>org.eclipse.xtext</groupId>

<artifactId>org.eclipse.xtend.lib</artifactId>

</dependency>

Run your build and verify the relocation warning disappears

Update any BOM or dependencyManagement entries

Tooling considerations

IDEs: Eclipse, IntelliJ IDEA, and other IDEs honor Maven relocation. Refresh your project after migration.
Gradle: Fully supports Maven relocation when resolving from Maven repositories.
Reproducibility: The relocation POMs are stable and don’t affect build reproducibility.
CI/CD: No changes needed; relocation works transparently in CI environments.

Lessons learned

Maven Central namespace enforcement is strict: You cannot publish artifacts with different groupId namespaces in a single deployment, even if they’re in the same monorepo.
Relocation is low-effort and highly effective: Once set up, relocation artifacts are trivial to maintain across versions.
Separate publishing is required: Relocation artifacts must be published in a completely separate Maven deployment due to namespace restrictions.
Testing is crucial: We performed dry-run deployments first to ensure Maven Central would validate the artifacts correctly.
Scripts need updates: Don’t forget to update version-bumping and release automation scripts to include relocation modules.
Communication is important: Clear documentation and release notes help consumers understand and adopt the changes smoothly.
It works across ecosystems: Both Maven and Gradle consumers benefit from relocation automatically, as do IDE integrations.

FAQ

Q: Do I need to change anything immediately?
A: No; builds continue to work with the old coordinates, but you’ll see warnings. Update when convenient to eliminate warnings.

Q: Does relocation affect checksums or reproducible builds?
A: No; the new artifact is authoritative. The stub POM exists only for resolution redirection and contains no actual code.

Q: Can Gradle consumers rely on this?
A: Yes; Gradle honors Maven relocation information when resolving from Maven repositories.

Q: What about IDEs?
A: IDEs (tested with Eclipse and IntelliJ) honor Maven relocation when resolving from Maven repositories. You may need to refresh your project after migration.

Q: What if I use dependencyManagement or BOM entries?
A: Update them to reference the new groupId. Transitive relocation continues working in the meantime.

Q: Will this affect my transitive dependencies?
A: No; if your direct dependencies haven’t migrated yet, their use of old coordinates will be automatically relocated, and you’ll see warnings for those too.

Q: What happens if I have both old and new coordinates in my dependency tree?
A: Maven/Gradle will resolve both to the same artifact (the new one), so you won’t have duplicates on the classpath.

Install Ubuntu on Apple Silicon Macs Using UTM

Leave a reply

Let’s install Ubuntu 25.04 on Apple Silicon (M1) in a virtual machine using UTM.

We must first download an Ubuntu ISO for ARM. Go to https://ubuntu.com/download/desktop and search for “ARM 64-bit architecture”; if not available for the specific version you want to install, then you’ll have to install the Ubuntu Server and then install the “ubuntu-desktop” package. Before downloading the server edition, you might want to search deeper in the Ubuntu release download site and look for the ARM ISO, which is not advertised in the above download site. For example, for 25.04, you get the link for the ARM version from the download site, but not for 24.04. However, by looking at the releases web directory, you’ll also find the ARM ISO for 24.04 (for example, https://cdimage.ubuntu.com/releases/24.04.3/release/ubuntu-24.04.3-desktop-arm64.iso).

You can install UTM in several ways. I installed with Homebrew: “brew install utm”.

Let’s start it and create a new Virtual Machine:

Choose Virtualize (we want to use an ARM Linux distribution):

Then, of course, choose “Linux”

Here we use QEMU, not Apple Virtualization. We select the ISO we downloaded before:

Let’s change Memory and Cores to allocate to the VM (I also enable hardware acceleration to have nice visual effects in the VM; As specified in the checkbox’s documentation, this might give you troubles in some configurations):

And the storage of the VM disk. Remember that by default, not all the specified GiB will be used by the file of the disk image: the disk image file will occupy only the effectively used data by the filesystem.

For the moment, I won’t use a shared directory.

Here’s the summary, where you can also give a custom name to the VM:

OK, let’s start the VM; the first time, this will start the installation ISO:

Here we are in the VM. From now on, the installation procedure is basically the standard Ubuntu one. Here’s the list of screenshots:

Since that’s a VM, I select to erase the entire (virtual) disk; alternatively, you might want to specify your custom partitioning scheme, possibly with a different file system than the default one, i.e., EXT4.

The installation starts with the usual slide show:

Remember that by clicking on the small icon on the bottom-right, you’ll get the log of the installation:

After installation has finished, shut down the machine (instead of “restart now”) and “Clear” CD to avoid booting from the installation ISO again:

Now, start the installed VM.

As usual, you’ll almost immediately get updates:

If not already installed, you might want to install spice-vdagent and spice-webdavd for better integration with the host system (for example, shared clipboard and folder sharing).

Let’s see a few screenshots of the installed system:

Note the SWAP file created by the installer and the filesystem layout.

I’ve installed fastfetch to show the typical output:

Note the graphics (remember we selected above the Hardware OpenGL Acceleration):

Concerning the resolution of the VM, let’s consider the “Display” setting of the virtual machine:

Note the selected “Resize display to window size automatically”; that’s useful, especially when setting the VM window to full screen.

Concerning the display settings: “Retina mode” (optimize resolution for HDPI displays). Then you have to adjust the resolution in the VM.
The documentation https://docs.getutm.app/settings-qemu/devices/display/ suggests NOT to enable “Retina mode” because it increases memory usage and processing (and the host operating system can use efficient hardware scaling, while the guest uses software scaling).

Without this setting, the display will be presented at the current resolution and scale that the operating system uses. For example, here’s my macOS setting:

And in fact, as you see from one of the screenshots above, the Ubuntu desktop, when the UTM VM is full-screen, has the same 1280×800 resolution.

You might want to have a look at the special input settings:

The “Command+Option” is important to easily switch between the VM and the host OS concerning keyboard inputs.

First impressions

In general, the VM usage is very pleasant. Everything runs smoothly, including the visual effect. Indeed, it all seems to run at native speed.

WARNING: You’re running an ARM Linux distribution, so packages must be available for this architecture. Sad news: a few programs are NOT available for Linux ARM, notably Google Chrome and Dropbox. Please, consider that.

That’s all for this initial UTM post.

Stay tuned for other posts related to Linux virtual machines in UTM.

Switch SSD mode from RAID to AHCI (for Windows and Linux dual boot)

Leave a reply

On some computers, like the new Dell Pro Max Tower T2 and the old XPS 13, the SATA operation mode for the SSD is set to RAID by default.
Linux will not be able to see the SSD in RAID mode: you need to change it to AHCI.
If you just change it to AHCI in BIOS, Windows will not boot.

The idea is to boot Windows in Safe Mode once, then change the SATA mode to AHCI in BIOS, then boot Windows normally (it will automatically load the AHCI drivers).

WARNING: Do the procedure at your own risk!

The procedure can be found in many places online.
However, I decided to put the steps that worked for me here:

Click the Start Button and type cmd; Right-click the result and select Run as administrator
Type this command and press ENTER: bcdedit /set {current} safeboot minimal (If it does not work, use this alternative: bcdedit /set safeboot minimal)
Restart the computer and enter BIOS Setup (in Dell, it is F2)
Change the SATA Operation mode to AHCI from RAID
Save changes and exit Setup, and Windows will automatically boot to Safe Mode.
Do as in the first step to open an elevated command prompt.
Type this command and press ENTER: bcdedit /deletevalue {current} safeboot (If it does not work, use this alternative: bcdedit /deletevalue safeboot)
Reboot once more, and Windows will automatically start with AHCI drivers enabled.

Note that in the Dell Pro Max Tower T2 BIOS, you must enable the “Advanced Setup” (see the top-left corner) to be able to change the operation mode in the “Storage” section:

Here are the sources I used:

Managing KDE Dotfiles with Chezmoi and Chezmoi Modify Manager

1 Reply

If you’re a KDE user who wants to keep your desktop configuration under version control, you’ve probably discovered that KDE’s configuration files can be quite challenging to manage with traditional dotfile tools. KDE stores settings in complex INI files that frequently change, contain system-specific data, and include sections you may not want to track. This is where Chezmoi Modify Manager becomes useful when using the Chezmoi dotfile manager.

The Problem with KDE Configuration Files

KDE applications like Kate, Dolphin, and KWin store their settings in INI-style configuration files. These files often contain:

Volatile sections that change frequently (like window positions, recent files)
System-specific data (like file dialog sizes, screen configurations)
Mixed content where you only want to track specific settings

Things have improved recently in that respect; however, some KDE INI files still mix those configurations.

Managing these files directly with Chezmoi would result in noisy diffs and configurations that don’t work well across different machines.

Enter Chezmoi Modify Manager

Chezmoi Modify Manager acts as a configurable filter between your actual config files and your Chezmoi repository. It allows you to:

Ignore entire sections or specific keys
Set specific values while ignoring everything else
Use regex patterns for flexible matching
Transform values during processing

The tool works by creating “modify scripts” that tell Chezmoi how to process each configuration file.

Quoting from the official documentation:

For each settings file you want to manage with chezmoi_modify_manager there will be two files in your chezmoi source directory:

modify_<config file> or modify_<config file>.tmpl, e.g. modify_private_kdeglobals.tmpl
This is the modify script/configuration file that calls chezmoi_modify_manager. It contains the directives describing what to ignore.

<config file>.src.ini, e.g. private_kdeglobals.src.ini
This is the source state of the INI file.

The modify_ script is responsible for generating the new state of the file given the current state in your home directory. The modify_ script is set up to use chezmoi_modify_manager as an interpreter to do so. chezmoi_modify_manager will read the modify script to read configuration and the .src.ini file and by default will apply that file exactly (ignoring blank lines and comments).

Note that this is based on the Chezmoi mechanism of “modifying scripts”, allowing you to manage only some parts of files.

Thus, the integration with Chezmoi is based on these mechanisms:

Source files (.src.ini) contain your desired configuration
Modify scripts (starting with modify_) define filtering rules
Chezmoi applies the modifications when deploying configs
The .chezmoiignore file ensures source files aren’t directly copied

The file name after “modify_” and the file name of the “.src.ini” must follow the naming conventions of Chezmoi.

Your .chezmoiignore must include:

**/*.src.ini

1 2	*/.src.ini

This prevents the source files from being deployed directly, letting Chezmoi Modify Manager handle the processing.

So, let’s see how to use that.

Real-World Examples

You can use the “chezmoi_modify_manager” command line to create the proper files.

Let’s look at how this works in practice with actual KDE configurations, based on my dotfiles (so I have already created these files):

KWin Configuration (`kwinrc`)

The file “modify_private_kwinrc”:

#!/usr/bin/env chezmoi_modify_manager

source auto

ignore section "$Version"
ignore section "Desktops"
ignore regex "Tiling.*" ".*"
ignore section "Xwayland"

#!/usr/bin/env chezmoi_modify_manager

source auto

ignore section "$Version"

ignore section "Desktops"

ignore regex "Tiling.*" ".*"

ignore section "Xwayland"

This script ensures only the relevant window manager settings are tracked (the file “private_kwinrc.src.ini”):

[Effect-cube]
CubeFaceDisplacement=126
DistanceFactor=1.82

[Effect-magiclamp]
AnimationDuration=400

[Plugins]
cubeEnabled=true
magiclampEnabled=true
squashEnabled=false

[TabBox]
DesktopMode=0
HighlightWindows=false
LayoutName=compact

[Effect-cube]

CubeFaceDisplacement=126

DistanceFactor=1.82

[Effect-magiclamp]

AnimationDuration=400

[Plugins]

cubeEnabled=true

magiclampEnabled=true

squashEnabled=false

[TabBox]

DesktopMode=0

HighlightWindows=false

LayoutName=compact

Global Shortcuts (`kglobalshortcutsrc`)

The names of the files are using the same convention already shown before.

For keyboard shortcuts, you might want to ignore certain dynamic sections:

#!/usr/bin/env chezmoi_modify_manager

source auto

ignore section "ActivityManager"

#!/usr/bin/env chezmoi_modify_manager

source auto

ignore section "ActivityManager"

This keeps your custom shortcuts while filtering out activity-specific bindings that may not be relevant across systems. The file “private_kglobalshortcutsrc.src.ini” is not shown because it’s quite huge.

Font Configuration (`kdeglobals`)

Sometimes you only want to track a single setting:

#!/usr/bin/env chezmoi_modify_manager

source auto

set "General" "fixed" "Hack Nerd Font,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1" separator="="
ignore regex ".*" ".*"

#!/usr/bin/env chezmoi_modify_manager

source auto

set "General" "fixed" "Hack Nerd Font,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1" separator="="

ignore regex ".*" ".*"

This results in a clean config that only tracks the terminal font:

[General]
fixed=Hack Nerd Font,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1

[General]

fixed=Hack Nerd Font,10,-1,5,400,0,0,0,0,0,0,0,0,0,0,1

Kate Editor Configuration

For Kate, you might want to ignore volatile sections while keeping your editor preferences:

#!/usr/bin/env chezmoi_modify_manager

source auto

ignore section "KFileDialog Settings"
ignore section "FileDialogSize"
ignore section "KTextEditor::Search"
ignore section "MainWindow"
ignore regex "Kate Print Settings.*" ".*"

#!/usr/bin/env chezmoi_modify_manager

source auto

ignore section "KFileDialog Settings"

ignore section "FileDialogSize"

ignore section "KTextEditor::Search"

ignore section "MainWindow"

ignore regex "Kate Print Settings.*" ".*"

Again, the “.src.ini” file is not shown.

Benefits

Clean diffs: Only track settings you care about
Portable configs: No system-specific clutter
Selective tracking: Include only relevant sections

Drawbacks

In general, setting the files initially takes much more time: you need to understand what to include/exclude in the “modify_” scripts and properly craft the “.src.ini” files accordingly. Moreover, some Chezmoi mechanisms, such as “merge,” will not function. Therefore, updating the files requires employing alternative techniques, as outlined in the next blog post. Finally, besides “chezmoi”, you need to install an additional program “chezmoi_modify_manager”.

Eclipse in Wayland (2025)

Leave a reply

Let’s see what Eclipse looks like in Wayland in 2025.

I report some screenshots of a few Wayland Window Managers and Desktop Environments.

Sway

Eclipse looks good in Sway:

Hyprland

The same can be said for Hyprland, especially now that the infamous bug has been solved:

GNOME

No problems on GNOME either; I’d expect that since it is “natively” based on GTK:

If I run Eclipse forcing X11 (GDK_BACKEND=x11), I see no difference.

KDE

On KDE, the situation is not bad, but I find it far from optimal.

Eclipse on Wayland doesn’t look completely native on KDE Plasma:

Many parts don’t look sized correctly.

There’s also the strange thing of the window title bar for the splash screen, which, of course, is not expected:

Dialogs also look not properly sized:

In X11, it looks better, or at least better integrated with the KDE desktop. Moreover, there’s no additional titlebar in the splash screen, and the dialog looks better (for size and width):

That’s all for this post!

Using Unison File Synchronizer on macOS: Now Available via Homebrew

1 Reply

Unison, a powerful file synchronizer, has long been one of my favorite tools. However, installing Unison on macOS used to be a manual and sometimes cumbersome process, as detailed in my earlier guide.

The great news is that Unison is now available as a Homebrew cask! This means you can install it with a single command, leveraging the convenience and reliability of Homebrew’s package management.

To install Unison, simply run:

brew install --cask unison-app

1 2	brew install --cask unison-app

This command will download and install the Unison application into your /Applications folder.

After installation, you might encounter permission issues due to macOS’s security features (especially if you downloaded the app from the internet). To clear any extended attributes that might prevent Unison from launching, run:

xattr -c /Applications/Unison.app

1 2	xattr -c /Applications/Unison.app

This command removes quarantine flags and ensures Unison can start without macOS warnings.

For more details and troubleshooting tips, check out my earlier guide.

Installing EndeavourOS Linux on an old MacBook Air (2016)

6 Replies

I bought this laptop in late 2016. It’s still a good laptop (8 GB RAM, 128 GB SSD) and very light. However, I cannot use it with macOS anymore.

I previously blogged on installing Ubuntu on my old MacBook Air. Everything mainly went smoothly, except for the WiFi, which was not working during and after the installation, but it could be fixed by installing the proper module. The upgrade to Ubuntu 25.04 was almost fine: after the upgrade, the system did not boot anymore; I didn’t even get the Grub menu.

Ubuntu once again disappointed me. Time to wipe everything and go with my favorite Arch Linux distribution: EndeavourOS. In particular, “Mercury Neo”.

Installation

After having put the EndeavourOS ISO on a USB stick with Ventoy and inserted the USB stick, turn on the Mac and immediately press and hold the Option (⌥) key until you see the startup disk selection screen:

Select the entry corresponding to the USB and get to the Ventoy menu.

After some time, here’s the live system:

Did you notice the WiFi icon? Exactly! The WiFi has been automatically detected! Well done!

This is the WiFi card:

[liveuser@eos- ~]$ lspci -nn | grep Network
03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter [14e4:43a0] (rev 03)

1 2	[liveuser@eos- ~]$ lspci -nn \| grep Network 03:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4360 802.11ac Dual Band Wireless Network Adapter [14e4:43a0] (rev 03)

And we can see that the corresponding kernel module is part of the live system (of course, it will also be part of the installed system):

[liveuser@eos- ~]$ pacman -Qs broadcom
local/broadcom-wl-dkms 6.30.223.271-42
    Broadcom 802.11 Linux STA wireless driver

[liveuser@eos- ~]$ pacman -Qs broadcom

local/broadcom-wl-dkms 6.30.223.271-42

Broadcom 802.11 Linux STA wireless driver

I changed the keyboard layout for an easier installation.

Before starting the installation, I use the Welcome menu to update Arch and EndeavourOS mirrors, of course, after connecting to the WiFi.

Before going on, everything seemed to work: touchpad, keyboard light, volume, brightness, though function keys were inverted. We’ll fix that later.

Let’s start the installation, choosing the “Online” method:

Then, the installation, based on Calamares, is the standard one, showing a few dialogs to select some configurations:

I will install KDE:

I also select as additional packages the LTS kernel and the printing packages:

As usual, I choose Grub as the bootloader:

I choose to wipe everything, select BTRFS as the file system, and also “Swap with hibernation”:

Let’s review everything and choose “Install”:

The installation takes a few minutes. Time to restart:

The installed system

Here we are:

Here are some screenshots of the good-looking KDE desktop:

And, of course, the fastfetch output in all its glory:

Configuration

As already stressed, unlike Ubuntu, there’s no need to fix any WiFi problem: it works out of the box!

Then, let’s fix the function keys, which are inverted (so, to have F1, you’d have to press “Fn F1”, which is not ideal). You can try:

sudo bash -c "echo 2 > /sys/module/hid_apple/parameters/fnmode"

1	sudo bash -c "echo 2 > /sys/module/hid_apple/parameters/fnmode"

If it works, change this permanently:

echo options hid_apple fnmode=2 | sudo tee -a /etc/modprobe.d/hid_apple.conf
sudo dracut-rebuild

1 2	echo options hid_apple fnmode=2 \| sudo tee -a /etc/modprobe.d/hid_apple.conf sudo dracut-rebuild

Concerning hibernation (selected during the installation), it does work; however, there’s a big problem: the system does not shut down, it reboots. Upon rebooting, it effectively resumes from hibernation, but as it is, it’s rather useless. I still have not figured out how to fix that.

Another thing not working is the webcam.

This is the device:

❯ lspci -nn | grep Cam
02:00.0 Multimedia controller [0480]: Broadcom Inc. and subsidiaries 720p FaceTime HD Camera [14e4:1570]

1 2	❯ lspci -nn \| grep Cam 02:00.0 Multimedia controller [0480]: Broadcom Inc. and subsidiaries 720p FaceTime HD Camera [14e4:1570]

Maybe it’s just a matter of installing the corresponding packages, but I haven’t investigated further yet.

Everything else works smoothly, as I have already said (including touchpad gestures in KDE).

Final thoughts

The laptop works great with EndeavourOS, even better than with Ubuntu. Everything is smooth and reactive. Even more than with the original old macOS operating system.

I noted that concerning sleep, the default configuration already uses the more power-saving setting:

❯ cat /sys/power/mem_sleep
s2idle [deep]

1 2	❯ cat /sys/power/mem_sleep s2idle [deep]

Power consumption also works fine after installing the powertop package (running that with the “auto-tune” setting) and setting the power profile to “Power Saver” from the KDE menu. MacOS probably used to have better power consumption, but this one is acceptable.

It was a nice decision to put Linux on this laptop, even more so with EndeavourOS instead of Ubuntu! 🙂

Speed Up Your Linux System with Zram

4 Replies

Zram, https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html, is a Linux kernel module that creates a compressed block device in RAM. This device can be used as swap space or a general-purpose RAM disk. By compressing data in memory, zram allows your system to store more data in RAM, reducing the need to swap to slower disk storage and improving overall responsiveness.

In particular, zram

Increases effective RAM capacity by compressing data.
Reduces disk I/O and wear, especially useful on SSDs.
Improves performance on systems with limited memory.

If you’re looking to boost your Linux system’s performance, especially on machines with limited RAM, zram is a powerful tool worth exploring.

In this post, I’ll show how to set it up on both Arch Linux and Ubuntu.

Installing zram

On Arch Linux

Install the zram generator package:

sudo pacman -S zram-generator

1 2	sudo pacman -S zram-generator

On Ubuntu

Install the systemd zram generator:

sudo apt install systemd-zram-generator

1 2	sudo apt install systemd-zram-generator

Configuring zram

Create a configuration file to set up your zram device. For example, to allocate half of your system’s RAM to zram and use the efficient zstd compression algorithm, run:

cat <<-EOF | sudo tee /etc/systemd/zram-generator.conf
[zram0]
zram-size = (ram / 2)
compression-algorithm = zstd
EOF

cat <<-EOF | sudo tee /etc/systemd/zram-generator.conf

[zram0]

zram-size = (ram / 2)

compression-algorithm = zstd

EOF

After saving the configuration, reboot your system to activate zram.

By default, zram will have the precedence over an existing swap partition.

You can use the command zramctl to see the status of zram and swapon to show your swap partitions (zram’s one will be /dev/zram0).

Install Nerd Fonts on macOS with Homebrew

Leave a reply

I like Nerd Fonts a lot, and blogged about those in the past. If you spend a lot of time in the terminal, you’ve probably heard of them: they patch popular programming fonts with a huge set of icons, making your terminal and development environment look great and more informative.

Here’s how you can easily install Nerd Fonts on macOS using Homebrew.

Step 1: Install Homebrew (if you haven’t already)

If you don’t have Homebrew installed, open your terminal and run:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

1 2	/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Step 2: Install `fontconfig`

Before installing fonts, it’s a good idea to have fontconfig:

brew install fontconfig

1 2	brew install fontconfig

Step 3: Install Nerd Fonts with Homebrew Cask

Homebrew makes it easy to install fonts with the --cask option. Here’s how I install my favorite Nerd Fonts:

brew install --cask \
font-jetbrains-mono-nerd-font \
font-caskaydia-cove-nerd-font \
font-iosevka-term-nerd-font \
font-fira-mono-nerd-font

brew install --cask \

font-jetbrains-mono-nerd-font \

font-caskaydia-cove-nerd-font \

font-iosevka-term-nerd-font \

font-fira-mono-nerd-font

You can add or remove fonts from this list as you prefer. Homebrew will handle downloading and installing them for you.

Step 4: Use Your New Fonts

After installation, open your terminal or code editor’s settings and select your preferred Nerd Font from the font list. Now you can enjoy enhanced icons and a better coding experience!

Tip: You can browse all available Nerd Fonts with:

brew search nerd-font

1 2	brew search nerd-font

Happy fonts! 🙂

Better diffs in Lazygit with delta

1 Reply

If you use Lazygit as your terminal Git UI, you know how convenient it is for staging, committing, and managing branches.

I use it in Neovim (LazyVim already configures it).

Integrating a custom pager (Lazygit Custom Pagers Documentation) can dramatically improve how diffs are displayed.

In this blog post, I’ll document how to use delta: a syntax-highlighting pager for git, diff, and grep output.

Delta makes diffs much more readable by adding syntax highlighting, line numbers, and custom themes. This is especially helpful when reviewing changes in Lazygit, as it makes it easier to spot what’s changed at a glance.

Installing delta

On Arch Linux (or derivatives), you can install delta with:

sudo pacman -S git-delta

1	sudo pacman -S git-delta

For other platforms, check the delta installation instructions.

Configuring Lazygit to use delta

To use delta as the pager in Lazygit, add the following to your ~/.config/lazygit/config.yml:

git:
  paging:
    colorArg: always
    pager: delta --paging=never

git:

paging:

colorArg: always

pager: delta --paging=never

This tells Lazygit to use delta for displaying diffs, with color always enabled and paging disabled (since Lazygit handles paging itself).

Here are two screenshots with the diffs better highlighted:

Show line numbers

If you want to see line numbers in your diffs, update the pager line with “–line-numbers”.

Customizing delta with themes

Delta supports custom themes for even better readability. You can find a collection of themes here.

To use these themes:

Download the raw themes.gitconfig file, for example, to ~/.config/delta/themes.gitconfig:

wget https://raw.githubusercontent.com/dandavison/delta/main/themes.gitconfig -O ~/.config/delta/themes.gitconfig

1

wget https://raw.githubusercontent.com/dandavison/delta/main/themes.gitconfig -O ~/.config/delta/themes.gitconfig
Include it in your global Git config by adding the following to your ~/.gitconfig:

[include] path = ~/.config/delta/themes.gitconfig

1
2

[include]
path = ~/.config/delta/themes.gitconfig
To see available themes, run:

delta --show-themes

1

delta --show-themes
Pick a theme you like (e.g., colibri) and enable it in your Lazygit config:

YAML

git: paging: colorArg: always pager: delta --paging=never --line-numbers --features=colibri

1
2
3
4

git:
  paging:
    colorArg: always
    pager: delta --paging=never --line-numbers --features=colibri

For example, with the “colibri” theme:

With “weeping-willow” theme:

Enjoy your diffs! 🙂

Computing the total test execution time of Maven Surefire

Leave a reply

When working with Maven projects, the Surefire plugin is commonly used to execute tests, but it lacks a built-in feature to display the total execution time across all test suites. This can be particularly important when monitoring performance trends in larger projects with many test classes.

Maven’s Surefire plugin reports execution time for individual test classes but doesn’t provide an aggregated view of the total test execution time. The reports are generated in the “target/surefire-reports” folder, both as text files and XML files.

Here’s a shell script that parses the XML report files generated by Surefire and calculates the total execution time. The script is compatible with both Linux and macOS environments.

#!/bin/bash

# Calculate total test execution time by summing only the time attributes from the testsuite elements
# Using a more compatible awk syntax for macOS and other platforms
echo -e "\n========================================"
echo "TOTAL SUREFIRE EXECUTION TIME: $(awk '
/<testsuite/ {
  for (i=1; i<=NF; i++) {
    if ($i ~ /^time=/) {
      gsub(/time="/, "", $i);
      gsub(/".*/, "", $i);
      total += $i;
    }
  }
}
END {
  printf "%.3f seconds", total
}' target/surefire-reports/TEST-*.xml)"
echo "========================================"

#!/bin/bash

# Calculate total test execution time by summing only the time attributes from the testsuite elements

# Using a more compatible awk syntax for macOS and other platforms

echo -e "\n========================================"

echo "TOTAL SUREFIRE EXECUTION TIME: $(awk '

/<testsuite/ {

for (i=1; i<=NF; i++) {

if ($i ~ /^time=/) {

gsub(/time="/, "", $i);

gsub(/".*/, "", $i);

total += $i;

}

END {

printf "%.3f seconds", total

}' target/surefire-reports/TEST-*.xml)"

echo "========================================"

These are the steps:

Look for lines containing <testsuite> tags
For each matching line, loops through all fields (words) in the line
Find fields that start with time=
Uses gsub() to extract just the numeric value by removing the time=" prefix and the " suffix
Add the extracted value to the running total
Format the output in the same way, with the total time in seconds

To make this script run automatically after your tests, you can integrate it into your Maven build process using the exec-maven-plugin:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>3.5.0</version>
    <executions>
        <execution>
            <id>extract-total-test-time</id>
            <phase>test</phase>
            <goals>
                <goal>exec</goal>
            </goals>
            <configuration>
                <executable>bash</executable>
                <arguments>
                    <argument>report-total-time.sh</argument>
                </arguments>
            </configuration>
        </execution>
    </executions>
</plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>exec-maven-plugin</artifactId>

<id>extract-total-test-time</id>

<goals>

</goals>

<argument>report-total-time.sh</argument>

</arguments>

</configuration>

</execution>

</executions>

</plugin>

The above snippet assumes the script is in a file “report-total-time.sh” in the same directory as the POM. Otherwise, you’ll have to adjust the argument accordingly.

When your tests complete, you’ll see output similar to:

========================================
TOTAL SUREFIRE EXECUTION TIME: 4.237 seconds
========================================

========================================

TOTAL SUREFIRE EXECUTION TIME: 4.237 seconds

========================================

That’s all!

Using Neovim in Gitpod

Leave a reply

I’m going to show you how to use Neovim on Gitpod. This can be useful for checking and testing your Neovim configuration.

The example can be found here: https://github.com/LorenzoBettini/neovim-gitpod-example.

I’m using a LazyVim distribution as a demonstration.

The Gitpod custom Dockerfile, “.gitpod.Dockerfile”, must be tweaked to install Neovim and its requirements (especially for using Lazyvim):

# You can find the new timestamped tags here: https://hub.docker.com/r/gitpod/workspace-full/tags
FROM gitpod/workspace-full:2025-04-16-08-49-20

# Install packages that are not in the Ubuntu repos
# the version in Ubuntu repos is too old for lazy.vim
# shellcheck is not available at all in Ubuntu repos
RUN brew update
RUN brew install \
	neovim \
	shellcheck

# install-packages is a wrapper for `apt` that helps skip a few commands in the docker env.
# additional packages needed in neovim with this configuration
# (tree is just to inspect folders, not needed by neovim)
RUN sudo install-packages \
	fzf \
	ripgrep \
	stow \
	npm \
	tree

# You can find the new timestamped tags here: https://hub.docker.com/r/gitpod/workspace-full/tags

FROM gitpod/workspace-full:2025-04-16-08-49-20

# Install packages that are not in the Ubuntu repos

# the version in Ubuntu repos is too old for lazy.vim

# shellcheck is not available at all in Ubuntu repos

RUN brew update

RUN brew install \

neovim \

shellcheck

# install-packages is a wrapper for `apt` that helps skip a few commands in the docker env.

# additional packages needed in neovim with this configuration

# (tree is just to inspect folders, not needed by neovim)

RUN sudo install-packages \

fzf \

ripgrep \

stow \

npm \

tree

Then, the file “.gitpod.yml” must be tweaked accordingly; in particular, I’m using “stow” to create a symlink for the default Neovim configuration directory using as the source the configuration directory of this repository (you could also simply use the “ln” command for that):

image:
  file: .gitpod.Dockerfile

tasks:
  - init: ./stow.sh

vscode:
  extensions:
    - ms-azuretools.vscode-docker
    - eamodio.gitlens

image:

file: .gitpod.Dockerfile

tasks:

- init: ./stow.sh

vscode:

extensions:

- ms-azuretools.vscode-docker

- eamodio.gitlens

The “stow.sh” script is part of the repository. I also specify a few extensions to install in the VScode of Gitpod.

Note that the first time, it will take a few minutes for Gitpod to provision such a Docker image.

Once in Gitpod, we can see that the link has been already configured:

Now, let’s enlarge the Terminal view and start Neovim.

We should see Neovim is installing all the packages as configured by LazyVim:

Note the change of the default color scheme:

Let’s close the Lazy window and see the Dashboard:

Since I’m using a light theme for the VScode, upon restarting Neovim, the color scheme is changed to its light variant as well:

We can now open the explorer (“space e”) to browse the contents:

By default, we have the Lua LSP installed.

We can use the file picker (“space f”):

We can use Lua LSP features like code completion:

And hover (“K”):

And change the color scheme with the picker (“space u C”):

Note that there are a few things that are not working correctly in Gitpod concerning Neovim:

Clipboard does not work since there’s no “DISPLAY” set.
Missing nerd fonts, things like folders and file types in the explorer, are not rendered correctly.

That’s all!

Installing Ansible and Molecule in Arch Linux

Leave a reply

Using “pip” is the supported installation method for Ansible and Molecule. Let’s install Python libraries and applications (in this case, Ansible and Molecule) in a Python virtual environment. (This post is similar to the one about Ubuntu.)

First, install the required packages, including the Python virtual environment package:

sudo pacman -S python-pip python-virtualenv

1	sudo pacman -S python-pip python-virtualenv

Create a virtual environment somewhere (in this example, I create it in my home folder as a subdirectory of a folder for all the virtual environments; the directory will be created automatically):

python -m venv ~/.venv/molecule

1	python -m venv ~/.venv/molecule

Once the virtual environment has been created, “enter” the virtual environment:

source ~/.venv/molecule/bin/activate

1	source ~/.venv/molecule/bin/activate

Install the Python packages for Ansible, Molecule, and its plugins in the virtual environment:

python -m pip install ansible molecule "molecule-plugins[docker]" yamllint ansible-lint

1	python -m pip install ansible molecule "molecule-plugins[docker]" yamllint ansible-lint

You can verify that everything is installed correctly, e.g., at the time of writing:

❯ molecule --version
molecule 25.4.0 using python 3.13 
    ansible:2.18.5
    gce:23.7.0 from molecule_plugins requiring collections: google.cloud>=1.0.2 community.crypto>=1.8.0
    openstack:23.7.0 from molecule_plugins requiring collections: openstack.cloud>=2.1.0
    containers:23.7.0 from molecule_plugins requiring collections: ansible.posix>=1.3.0 community.docker>=1.9.1 containers.podman>=1.8.1
    docker:23.7.0 from molecule_plugins requiring collections: community.docker>=3.10.2 ansible.posix>=1.4.0
    default:25.4.0 from molecule
    azure:23.7.0 from molecule_plugins
    ec2:23.7.0 from molecule_plugins
    vagrant:23.7.0 from molecule_plugins
    podman:23.7.0 from molecule_plugins requiring collections: containers.podman>=1.7.0 ansible.posix>=1.3.0

❯ molecule --version

molecule 25.4.0 using python 3.13

ansible:2.18.5

gce:23.7.0 from molecule_plugins requiring collections: google.cloud>=1.0.2 community.crypto>=1.8.0

openstack:23.7.0 from molecule_plugins requiring collections: openstack.cloud>=2.1.0

containers:23.7.0 from molecule_plugins requiring collections: ansible.posix>=1.3.0 community.docker>=1.9.1 containers.podman>=1.8.1

docker:23.7.0 from molecule_plugins requiring collections: community.docker>=3.10.2 ansible.posix>=1.4.0

default:25.4.0 from molecule

azure:23.7.0 from molecule_plugins

ec2:23.7.0 from molecule_plugins

vagrant:23.7.0 from molecule_plugins

podman:23.7.0 from molecule_plugins requiring collections: containers.podman>=1.7.0 ansible.posix>=1.3.0

Each time you want to run Ansible or Molecule, just run the “source” command above:

source ~/.venv/molecule/bin/activate

1	source ~/.venv/molecule/bin/activate

And then you can run “ansible” and “molecule”.

When using “Oh My Zsh” with the “Powerlevel10k” theme, you also get the virtual environment name shown in the prompt:

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

About Lorenzo Bettini

The fix: disable m2e-apt at the project level

Add this to your pom.xml

Refresh VS Code so it stops regenerating the files

What the script does

Dependencies

The script

How it works

Usage

Nice touches in the UI

Why this is handy

The minimal language extension for Java 17

Using it in your document

Minimal working example

Identifying Your Hardware

The Solution: Community-Developed Drivers

The Problem

The Solution

1. Alacritty Configuration

2. Tmux Configuration

3. Why This Works

Verification

References

Rationale

Why relocation instead of just renaming

Maven relocation basics (summary)

Our goals

Implementation outline

Example relocation POM

Ensuring no duplicate classes

Publishing workflow

Migration guidance for consumers

Tooling considerations

Lessons learned

FAQ

First impressions

The Problem with KDE Configuration Files

Enter Chezmoi Modify Manager

Real-World Examples

KWin Configuration (kwinrc)

Global Shortcuts (kglobalshortcutsrc)

Font Configuration (kdeglobals)

Kate Editor Configuration

Benefits

Drawbacks

Sway

Hyprland

GNOME

KDE

Installation

The installed system

Configuration

Final thoughts

Installing zram

On Arch Linux

On Ubuntu

Configuring zram

Step 1: Install Homebrew (if you haven’t already)

Step 2: Install fontconfig

Step 3: Install Nerd Fonts with Homebrew Cask

Step 4: Use Your New Fonts

Installing delta

Configuring Lazygit to use delta

Show line numbers

Customizing delta with themes

Add this to your `pom.xml`

KWin Configuration (`kwinrc`)

Global Shortcuts (`kglobalshortcutsrc`)

Font Configuration (`kdeglobals`)

Step 2: Install `fontconfig`