Category Archives: Reports

Some benchmarks for building an Eclipse project: Linux, Windows, macOS (M1)

I want to share some benchmarks for building an Eclipse project with Maven/Tycho. I built the project on Linux, Windows, and macOS (in particular, on my Mac Air M1 2020).

I stressed that the macOS environment is an M1, the new Arm-based chip from Apple, which is said to be quite efficient and performant. However, I also used an older Mac Air 2016, so no M1 here.

Concerning Linux and Windows, I used an LG GRAM 16. Both are good machines with powerful processors, 16Gig RAM, and NVMe disk. I ran the same build on a few Linux distributions (Arch, Ubuntu, Fedora) and the results concerning Linux are basically the same.

The Eclipse project is Edelta, https://github.com/LorenzoBettini/edelta, “An Xtext DSL for EMF metamodels refactoring and migration.” It’s quite a complex project with an extensive test suite: unit tests, integration tests (JUnit Plug-in tests), and SWTBot tests. The project also includes a custom Maven plugin, which is also tested. Yes, I’m test-addicted 😉

To avoid the Internet connection influencing the benchmarks, I first run the Maven build once so that Maven downloads and caches all the dependencies. Moreover, I first mirrored the p2 Eclipse artifacts so that the target platform definition is resolved against the local mirror.

LG GRAM 16 (LINUX) Total time: 03:25 min

LG GRAM 16 (WINDOWS) Total time: 04:20 min

MACBOOK AIR M1 Total time: 02:49 min

MACBOOK AIR 2016 Total time: 08:17 min

I must say I was impressed by the best performance shown by the M1 processor!

As expected, on the same machine, Windows performs worse than Linux 🙂

The performance of the old Mac Air is not impressive, but that’s an old machine.

Just for fun, I ran the same build on the PineBook Pro (which runs Manjaro KDE): Total time: 21:27 min. Of course, that’s not usable for intensive development 😉

My notes on the Grub incident in Linux Arch

In this post, I’d like to share my thoughts and the solution I adopted to circumvent the terrible incident that happened a few days ago with grub in Linux Arch. The bug affected all Arch-based distributions (not Manjaro, which is not really Arch-based, but for sure EndeavourOS and Arch itself).

You can find the details of the problem online:

If you’re reading this, you’re already aware of the bug, and maybe you’ve been hit by it. Thus, I’m not going into the details of the issue itself.

First of all, although I’ve been enjoying Arch for some time, I must say I was not pleased with the way the Arch team handled the problem (it’s really a severe issue, and having bootable snapshots does not save you from that if you don’t take countermeasures to avoid it or to fix the problem, once you’ve already been hit). After a few days, the Arch team closed the bug, blaming other Arch-based distros because they have hooks that update the grub configuration during package upgrades. The Arch team says that if you use grub the “Arch way,” you have no problem. However, if I understand the details of the issue correctly, as soon as you have a software update that installs a new kernel version, it will also update the grub configuration, and the bug will hit you. (update: no, that’s not the case in Arch, since the kernel image file always has the same name and does not have the version in the name).

Moreover, I have hooks to take Timeshift snapshots before a system upgrade and to generate grub entries to boot the snapshots. Isn’t this the “Arch way”? For sure, it’s a safety mechanism widely adopted. After all, Linux is about choice! 🙂 (update: since, as said above, the kernel image file name is always the same, even, for example, if you update from version 5.19.4 to 5.19.5, having bootable snapshots is even more crucial in Arch).

The issue is said to be fixed by showing a warning during the upgrade of the grub package saying:

Seriously?! That’s just a warning, which is likely to go unnoticed. That’s not a fix; it’s a patch (In the true sense of the word).

However, let’s say that you note that warning and do what it says.

You will have no problem on the next boot, but I found these huge drawbacks (at least for me):

  • The grub installation of the current Arch distribution will replace the default UEFI boot configuration. Of course, you can reorder the boot configurations from the UEFI setup, but that’s an unwanted side-effect if you had already configured things the way you wanted;
  • Related to the previous point, if you have another grub configuration (e.g., of another distro) to boot other distros on the same machine (see, e.g., my blog post on this mechanism), including this Arch installation, it will not work anymore. That’s expected because the other grub does not know anything about the new grub configuration anyway.

Moreover, in my humble opinion, what the grub developers have done in this new version does not make much sense: why do you want to execute a command to generate a boot entry dynamically?! Perform that choice when generating the grub configuration once and for all!

If you’re curious, that’s the difference after the grub update in the file used to generate the culprit entry in the grub.cfg (old file on the left, new file on the right):

So, after restoring my computer with arch-chroot (because I was hit by the bug), instead of their proposed “solution,” I ignored the package update by adding this line to /etc/pacman.conf:

This way, I won’t be hit by the bug again (until, hopefully, grub developers will revert that implementation decision, and Arch developers will provide a new grub package)

Then, I realized that, in the end, I don’t need a grub entry to enter UEFI! I can enter UEFI when starting the computer with a key combination (not to mention that, as I said above, my main grub is not the Arch one, but the Fedora one, as shown in my blog post)! Thus, I updated the grub package (of course, after removing the IgnorePkg entry shown above). Before rebooting (that’s crucial), instead of following the suggestion shown during the upgrade, I simply removed the grub file to generate the culprit configuration for UEFI in the grub.cfg (and, of course, I regenerated the grub configuration afterward):

That’s all! Your grub.cfg will not have an entry for entering UEFI anymore. I don’t need that.

Of course, you have to repeat these operations if Arch releases an update to the grub package without fixing the problem. However, I prefer this solution, which does not have the abovementioned drawbacks.

A first look at Crystal Linux

Crystal Linux is a brand new Linux distro based on Arch. Although it has not been officially released, you can already download an ISO and try that in its current development state.

Quoting from its home page:

Crystal Linux is a brand new Arch Linux based distribution.
Powerful and easy to use.

And, in particular

Why Crystal?
What’s so different about Crystal compared to other distributions?

  • Easy to use package manager
  • Beginner Friendly
  • Easy Btrfs snapshots
  • Easy to install

Since I’ve been using Arch and Arch-based (mainly EndeavourOS) distros for a while, I decided to try it, even if it’s not officially released, to briefly evaluate its current development status.

I downloaded the ISO crystal-live-08-20-22-07-55-x86_64.iso and tested it on a VirtualBox VM.

After the BOOT, you’re greeted by the GNOME desktop. I searched for the installer. I thought I’d find it in the dock, but that was not the case. I searched for an “install” string in the GNOME Activities. Again I got no results. Then, I recalled that Crystal names its installer Jade, and that’s how I found it.

The installer provides several screens to specify the typical information of a Linux installation. I would say that it does that in a very clear way. Here are a few screenshots of the pages of the installer:

Since it’s based on Arch, Crystal can provide a good selection of desktop environments. However, you can select only one:

Another interesting section is the next one, where you can enable Timeshift (recall from the introduction that “Easy Btrfs snapshots” is one of the advertised features):

Regarding partitioning, the Crystal Linux installer shows its “work-in-progress” state: you can only select the disk for the installation and nothing else. As noted in the dialog, it will wipe the whole disk and automatically partition it. Nothing is said about the file system, but I guess it will be a Btrfs filesystem (Spoiler: it is):

However, they are still working on the partitioning program:

Then, you get the summary for a final review. When you’re ready, start the installation:

The installer shows the installation log, which is excellent and helpful. Unfortunately, when the installation finishes, the log is not available anymore. It would be good to have access to that window still, to copy the log somewhere for a later examination.

OK, let’s reboot and see the distribution in action.

Crystal Linux should come with a customized GNOME desktop, Onyx, but that’s not installed by default. So you get a vanilla GNOME session (just like in Arch) with only a few programs installed (so, in this respect, it’s not bloated):

You don’t even have a Text Editor with a GUI (but at least you have Gnome Tweaks):

Of course, you can install whatever you want with pacman or with the Crystal custom AUR helper, amethyst, but beware: the command to run it’s ame; it took me some time to discover that 🙂 The AUR helper amethyst looks nice. Just like “yay”, you run it, and it also executes an update (“-Syu”). Besides that, the command line arguments are the same as pacman and yay, at least, that’s my first impression. Just like yay, amethyst also updates the AUR packages. Moreover, it is also configured to execute “pacdiff” at the end:

Unfortunately, the keyboard layout and the time zone I specified during the installation was not considered. I had to set them again in the GNOME settings.

The default shell is ZSH, which I like. However, it’s not configured at all, with any default. Thus, the first time you open a terminal, you have to do that yourself:

Let’s see how the installer created the partitions:

So we have BTRFS, with the two standard volumes @ and @home, which are suitable for Timeshift. No SWAP partition (swap is not configured at all). Moreover, there’s no compression on the BTRFS subvolumes, while I usually prefer to have compression.

There are also other subvolumes (I guess to exclude from snapshots the virtual machines you might create with Kvm):

Concerning repositories, Crystal is similar to EndeavourOS: it relies on Arch repositories and adds just a few custom repositories that you can also browse at https://repo.getcryst.al/. You can see that there are not so many packages there. Besides the Crystal programs, you also find a few packages you typically install from AUR, like timeshift and timeshift-autosnap.

This allows me to talk about the “Easy Btrfs snapshots.” The Crystal installer has already set up timeshift, timeshift-autosnap (which creates snapshots before package upgrade), and grub-btrfs (which adds “btrfs snapshots” to the grub menu to boot your system on a “snapshot” from the grub menu). (I wrote about these 3 tools previously).

For example, that’s what you see when you perform an upgrade (note the automatic creation of the snapshot and the creation of the grub menus for the snapshot):

In fact, the next time you boot, you also get the grub entry for the snapshots:

Summary

I liked a few things and a few things I did not like, but I enjoyed the installation, and, in general, I have an excellent impression of this new distribution. It’s not for beginners, but it’s easy for users who have already tried a few Linux distributions.

In any case, I found Crystal promising, and I really look forward to the official ISO release!

Ubuntu Jammy and Nvidia

I installed Ubuntu Jammy a few months ago, when it was released, on a desktop computer. It was a terrible experience: crashes now and then, and the Wayland session was not working well on some applications. After a week, I uninstalled it immediately and switched to Fedora on that computer.

Then, a new point release came out, 22.04.1. I heard that, in the meantime, many bugs were fixed. I decided to give it another chance. In particular, I decided to install that on an older computer, a Dell m3800, because it comes with an integrated video card and a “terrible” Nvidia card, which is well-known to give headaches to Linux users 😉 In the past, I used Bumblebee on such a computer to keep the power consumption low. However, Bumblebee gave me problems in the past, and I seem to understand that it is not actively maintained anymore. So, let’s try a fresh installation of Ubuntu Jammy and see how it deals with the Nvidia card.

The installation went fine and smoothly. In the end, when rebooting into the new installation, I could verify that the Nvidia drivers were installed automatically and working correctly (meaning no crashes or other issues)!

Since it uses Nvidia, Ubuntu does not show any gear icon on the login screen to switch the graphical session: it’s X11 automatically, and you cannot change it. I guess that’s done because Nvidia does not work correctly in a Wayland session.

Another nice thing is that it detected my huge screen resolution, 3200×1800, and automatically enabled 200% scaling. However, I seem to remember that this is a feature of Gnome itself.

Having said that, I found using the Nvidia drivers really a problem: the computer gets immediately hot, the fans get pretty noisy, and it looks like the battery does not entirely charge even when connected to the AC. It also looks like the battery goes down a bit, even when connected to the AC.

I opened the Nvidia settings. However, it looks like Hybrid mode will not work with this version of the driver.

Of course, when running on battery, the power consumption is too much, and the battery would drain in less than two hours, as reported by powertop. That’s the reported consumption (even when the computer is idle):

33.6 W of power consumption is too much.

Since I’m not using graphical intensive software, I tried to switch to the integrated Intel graphics card. You cannot select this choice in the Nvidia settings because it’s greyed out (you can find many posts on the Internet reporting this problem without a solution). However, we can use the command line:

Let’s reboot, and now the gear icon appears, and you can select the Wayland session since the Nvidia card is not used. By the way, Nvidia settings still have the greyed-out entry for the integrated card, but at least it recognized that’s the one selected:

The power consumption on battery is better (about 15 W, i.e., half), but I seem to understand that the Nvidia card itself it’s still using power since it’s not completely turned off:

At least the computer is not that hot anymore, and the battery seems to charge correctly.

Let’s try to use a tool to turn the Nvidia card off: EnvyControl.

Let’s install that:

As noted here, there are a few additional steps when installing EnvyControl in Ubuntu:

We could use the envycontrol command to set the card, but let’s now install a Gnome extension with a GUI for the switch: GPU profile selector.

Let’s also activate the extension.

Let’s reboot, and now, in the Gnome dropdown menu about the battery and power profile, we also have the menu entries to select the card:

Remember that we had to set the “on-demand” mode for installing EnvyControl. That’s why the “Hybrid” entry is selected.

Let’s select “Integrated” and reboot; now, the Nvidia card should be off.

The power consumption on battery is even better now (13.8 W):

If we switch to the Wayland session, it even improves a bit:

I find this installation usable, and I saw no issues for the moment.

That’s all for now!

Installing Arch Linux with the archinstall script

After using EndeavourOS for a while, I also decided to try Arch itself!

I did not feel ready to go through the manual procedure (but I’ll do that someday), and I heard about the archinstall script, which comes in the Arch official ISO. After watching a few videos and reading a few blog posts, I tried that myself, first on a VM and then on a real machine.

I can anticipate that I liked this installation procedure. Still, it is not perfectly usable in a multi-boot environment, as I’ll say near the end of this post, where I summarize my experience with the installation.

In this post, I’ll first show an installation on a VM (and I suggest you try that one), then briefly describe the installation on a real machine.

If you want to try that, you have to download an official Arch ISO. Once you booted into the live ISO, you must connect to the Internet as described in the official documentation.

Now, it’s time to run the installer:

And you have access to the main installation menu:

You see, it’s easy to use, especially if you’re familiar with other Linux installation programs.

The first three entries are easy to deal with.

The fourth, “Select harddrives,” requires some care because it’s where you deal with your disk! You have to select the correct drive. In my case:

Since I’m on a VM, I’ll simply choose to wipe everything on that drive and let the installer handle the partitioning automatically. That’s easy in a VM, and that’s what I’ve seen in all demos on the web (but, as I’ll show later, things are more complicated in a multi-boot environment):

Then, you choose the filesystem EXT4, BTRFS, etc.

For the bootloader, I chose GRUB, which is the one I’ve always used.

Concerning the user accounts, it’s best NOT to set a root password: it’s better to create a user with administrator rights (so that you later rely on the good ol’ “sudo”). An interesting feature of this installation procedure is that it lets you create as many users as possible. On the contrary, typically, other Linux installations only allow you to create a single user.

The other interesting menu entry is the one to choose the profile. I’m choosing “desktop”:

And in particular, I’m choosing GNOME (you see that you have plenty of choices):

Moreover, you can select the graphic drivers:

And the kernels:

Since, for the moment, you could just select from a predefined set of choices, you are given a chance to manually specify additional packages to install (but you have to know them by their name). In this example, I’m installing “firefox”:

It’s also crucial to configure the network for the installed system. If you use GNOME or KDE, I’d say that it’s best to choose “NetworkManager”:

Once you’ve done with all the menu entries, before starting the actual installation, you’re given a chance to save these configurations, which is helpful if you want to use the same configurations on other machines or to do some further customizations:

Now, it’s time to choose “Install”; a countdown starts to abort the installation in case you just remembered you’ve done something wrong:

The installation starts and in a few minutes (where a few packages will be downloaded)…

…you should get to the end of the installation, where, if you want, you can also tweak the installed system before rebooting:

If you choose “no”, you’re back to the live environment:

And you can now reboot to (hopefully) enjoy your installation:

Having installed GNOME, I’m presented with a few options, and I choose the first one, that is, GNOME on Wayland:

You see that the GNOME installation is a vanilla one.

OK, that was a VM, and it was straightforward to install Arch with the installation script. It’s also easy if you plan to install ONLY Arch on your computer (by wiping all the rest).

Things are not working completely fine if you want to install it on a computer with other Linux installations, which you want to keep and be able to boot into. In this case, of course, you cannot wipe the selected hard drive and must do manual partitioning. The installation script is still helpful in that respect (I’m not showing anything in this blog post), but you must be aware of a small problem.

In fact, due to an issue, which, at the time of writing, is still open, specifying to mount an existing EFI partition into “/boot/efi“, which, as far as I know, it’s the standard mount point in most distributions (every distribution I know at least). You must specify a mount point “/boot” and that must be a boot partition (with the boot flag). Of course, that’s what I’ve done myself; I specified the exiting EFI partition (the first partition of the installation drive in my computer) for the mount point “/boot”. However, the installer will treat that directory as if it was /boot/efi in other installations. Thus, it will copy the booting files directly there. As a sad result, the Arch installation will not be detected when rebooted. You will only see an existing installation’s GRUB menu (and running os-prober from an existing installation does not seem to help). Thus, you end up with the Arch installation that you cannot boot.

The only solution I found to boot into the Arch system was to apply the mechanisms shown in my other post and configure the Fedora GRUB with an entry pointing directly to the EFI partition, i.e., according to the post mentioned above, something like the following (remember, on my computer the EFI partition is the first one, and I installed Arch on the partition 13):

Or even like that (i.e., without specifying the root partition of the Arch installation at all and just relying on the grub that the installer created directly on the EFI partition):

Besides this problem, the installation script archinstall is really interesting and still under development.

Linux EndeavourOS Artemis Review

I have already blogged about EndeavourOS, which I use most of the time on a few laptops. Since EndeavourOS, based on Arch, is a rolling release, I update it almost daily and don’t need to install it from scratch when a new release comes out, like Artemis, which was released a few days ago. However, since I wanted to switch from the EXT4 file system to BTRFS (since I started to experiment with this file system and its snapshot capabilities), I took the chance to try this new release by installing it from scratch (of course, using BTRFS this time).

I’ll first go through the installation, but I can anticipate that, once again, I’m impressed by EndeavourOS. This installation feels really fast, maybe due to BTRFS or the new kernel (instead of the LTS kernel, I now use the latest one provided by the distribution) or both. Most of all, EndeavourOS is pure Arch but with outstanding defaults. Indeed, the KDE and GNOME environments are vanilla ones.

Installation

As usual, the first thing to do, once booted in the live environment, which in this case is XFCE, is set up the network connection. You might also want to change the keyboard layout (Disable system defaults and install your layout, in my case, it’s the Italian layout):

Then, let’s update the mirrors (typically by selecting your state) and start the installer.

I choose the “Online” method because I want to install KDE Plasma instead of Xfce.

You have to wait a few seconds (or about a minute) for the installer to download the modules (I always prefer to install any operating systems in English):

Maybe, due to a bug, the location has been found successfully, but the English version proposed is not the right one, so I have to change it to Americ English again:

After setting the keyboard layout (this time for the installed system), it’s time for partitioning.

Since on this computer I have a few Linux installations, including the old version of EndeavourOS I’m going to replace, I choose Manual partitioning (and not “Replace a partition” because that would keep the same file system type, EXT4, while I want to switch to BTRFS).

I Edit the partition, select “Format” (otherwise, I cannot change the File system type), modify the File system (BTRFS), and specify the mount point.

Before going on, we must specify to mount the EFI partition (into /boot/efi) without formatting it and ensure the “boot” flag is selected. This way, the installer can properly install GRUB.

WARNING: on another computer, the installer complained that I did not select a boot partition with at least 300Mb (mine was just 200Mb). Since I knew there was enough space in that partition, I ignored the warning, and the installation went fine.

As for the desktop, I select Plasma.

And then, we can select the single packages. Note that, different from my previous review, you choose the packages after selecting the desktop, so that a few packages, in particular, the ones of the chosen desktop, have already been selected:

In this blog post, I’m not going to install GNOME besides KDE, but I also select the “Printing-Support” and the “Support for HP Printer/Scanner” checkboxes.

As usual, then you have to specify your user’s details, and then it’s time to take a look at the summary:

Let’s start the installation. It might take a few minutes because it’s an “Online” installation, so it has to download several packages.

You can press “Toggle log” during the installation to see the installer’s log.

When it’s done, it’s time to restart the computer.

First impressions

As in the previous blog post, I must note that the Discover icon is still in the taskbar, though the software manager Discover is not installed at all.

Maybe because I selected KDE Plasma only, the Wayland session has not been installed, while in my previous post, I installed both GNOME and KDE. However, I just had to run this command:

And then I could enjoy Plasma also in Wayland, which seems to be pretty usable.

A nice addition is a firewall applet in the taskbar

Here’s neofetch:

Printing support is excellent! I connected an old USB HP Deskjet printer, and I got these notifications from Plasma:

The printer has been automatically installed correctly (I only had to configure a few things like paper size and color mode).

Setting up my Google accounts (drive access and calendar) is as cumbersome as always, but I did not experience any problems once I finished.

Power consumption on the battery is also excellent, but that was true in the past, so nothing changed in that respect.

All in all, this distribution keeps on being awesome.

As I initially anticipated, you have Arch and its vanilla desktop environments, but with useful and reasonable defaults. Moreover, the installation is effortless! 🙂

KDE Plasma 5.25 in Arch

After the recent release of KDE Plasma 5.25, this version landed a few days ago in Arch-based distros like EndeavourOS (the one I’m writing from).

Although I’m mostly a GNOME user, I also have a few distributions installed where I’m using KDE Plasma.

The new features that impressed me most are related to eye candies 🙂

First, the “Present Windows” effect now looks the same as the new “Overview” effect. If we compare the “Present Windows” effect in the previous version (5.24):

with the new one:

we can see a significant improvement: in the earlier versions, the windows not selected were too dark, making it hard to distinguish them. This behavior relates to an old bug (10 years old): https://bugs.kde.org/show_bug.cgi?id=303438. This bug has been fixed by rewriting this effect “to use the same modern, maintainable backend technology found in the Overview effect.”

I use this effect a lot (I also configured the “Super” key to use this effect, simulating what happens in Gnome for its “Activities” view), and I use the filter to filter the open windows quickly. So I appreciate this usability change a lot!

One detail I do not like in this new version of “Present Windows” is that the filter textbox remembers the entered text. Thus, the next time you use it, the presented windows are already filtered according to the previously entered text. I’m not sure I like this.

The other cool thing introduced is the automatic accent color! Accent colors were introduced a few versions ago in Plasma, but now you can have Plasma automatically adjust the accent color from the current wallpaper:

If you use a wallpaper changer mechanism (like the one provided by Plasma), possibly by downloading new wallpapers (like Variety), you will get nice accent colors during the day. Here are a few examples produced running Variety to change the wallpaper:

Maybe it’s not an important feature, but, as we say in Italy, “Anche l’occhio vuole la sua parte” 😉

The last new feature that positively impressed me is that now KRunner also shows Java files (and probably other programming languages related files) when you search a string. Previously, although “Baloo” (the file indexing and file search framework for KDE) knew about these files, KRunner was only showing .txt files and a few others, but not Java files.

Concerning Wayland, one thing I noted is that if I start a Plasma Wayland session using a brand new user, it automatically scales the display in case of an HDPI screen. Wayland usability in Plasma has not improved since my last experiments (see KDE Plasma and Wayland: usability).

 

KDE Plasma and Wayland: usability

It looks like KDE Plasma is getting usable with Wayland!

This is my current testing environment for this blog post:

Operating System: EndeavourOS
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.15.41-1-lts (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15,3 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

I had tested KDE Plasma with Wayland in the past, and the main problem I was experiencing, which made it unusable to me, was that I had to scale the display. I could scale the display, but the main problem was that, while KDE applications looked nice, the GTK applications looked blurred. This problem is still there, as you can see from this screenshot (here, I scaled the display to 150%):

You can see that the System settings dialog and Dolphin (in the background) look nice, but the EndeavourOS Welcome app and Firefox (in the background), which are GTK applications, look blurred!

Thus, I tried another way: I went back to 100% Display and tried to work on the Font HDPI scaling, though Plasma discourages doing that (it suggests using the display scaling). I tried with both 120 and 140 the result is satisfactory, as you can see from these screenshots:

IMPORTANT: You have to log out and log in to apply these changes. At least, I had to do that in my experiments.

There’s still one caveat to solve: GTK4 applications, like Gedit (the Gnome text editor) and Eye of Gnome (the Gnome image viewer), which, in this version of EndeavourOS, are already provided in their 42 version (using libadwaita). These applications are not considering font scaling. To solve that, you have to install Gnome Tweaks and adjust the “Scaling Factor” from there. Then, everything works also for those applications (Gedit is the one with “Untitled Document 1,” and Eye of Gnome is the dark window in the foreground):

With the Wayland session in Plasma, you can enjoy the default touchpad gestures (which, at the moment, are not configurable):

  • 4 Finger Swipe Left –> Next Virtual Desktop.
  • 4 Finger Swipe Right –> Previous Virtual Desktop.
  • 4 Finger Swipe Up –> Desktop Grid.
  • 4 Finger Swipe Down –> Available Window Grid.

Moreover, the scrolling speed for the touchpad can be configured (while, on X11, I wasn’t able to):

There are still a few strange things happening: the splash screen has the title bar and window buttons if you start Eclipse! 😀

I’ll try to experiment with this configuration also in other distributions.

Let’s cross our fingers! 😉

Testing the new Fedora 36

Fedora 36 has just been released, and I couldn’t resist trying it right away. I had already started using Fedora 35 daily (though I have several Linux distributions installed), and I’ve been enjoying it so far.

Before upgrading my Fedora 35 installations, I decided to install Fedora 36 on a virtual machine with VirtualBox.

These are a few screenshots of the installation procedure.

As usual, you’re greeted by a dialog for installing or trying Fedora, and I went for the latter.

The installation procedure is available from the dock:

To be honest, I’m not a big fan of the Fedora installer: compared to other installers like Ubuntu and EndeavourOS or Manjaro, I find the Fedora installer much more confusing. Maybe it’s just that I’m not used to such an installer, but I never had problems with Calamares in EndeavourOS or Manjaro, not even the very first time I tried Calamares.

For example, once a subsection is selected, the button “Done” is at the upper left corner, why I would expect buttons at the bottom (right).

I appreciate that you can select the NTP server time synchronization (at my University, I cannot use external NTP servers, and in fact, the default one is not working: I have to use the one provided by my University). Unfortunately, this setting does not seem to be persisted in the installed system. UPDATE 12/May: Actually it is persisted: I thought I’d find it in the file /etc/systemd/timesyncd.conf but instead it is in /etc/chrony.conf. Well done!

Since I’m installing the system on a VM hard disk for the partitioning, I chose the “Automatic” configuration. On a real computer, I’d go for manual partitioning. Even in this task, the Fedora installer is a bit confusing. Maybe the “Advanced Custom (Blivet GUI)” is more accessible than the default “Custom” GUI, or, at least, it’s much similar to what I’m accustomed to.

Finally, we’re ready to start the installation.

Even on a virtual machine, the installation does not take that long.

Once rebooted (actually, in the virtual machine, the first reboot did not succeed, and I had to force the shutdown of the VM), you’re greeted by a Welcome program. This program allows you to configure a few things, including enabling 3rd party repositories and online accounts and specifying your user account.

Then, there is the Gnome welcome tour, which I’ll skip here.

Here is the information about the installed system. As you can see, Fedora ships with the brand new Gnome 42 and with Wayland by default:

Fedora uses offline updates, so once notified of updates, you have to restart the system, and the updates will be installed on the next boot:

The installation is not bloated with too much software. Gnome 42 new theme looks fine, with folder icons in blue (instead of the old-fashioned light brown). Fedora also ships with the new Gnome Text Editor. Differently from the old Gedit, the new text editor finally allows you to increase/decrease the font size with Ctrl and +/-, respectively. I cannot believe Gedit did not provide such a mechanism. I used to install Kate in Gnome because I was not too fond of Gedit for that missing feature.

Instead, Fedora does not install the new Gnome terminal (gnome-console) by default. I installed that with DNF, and I wouldn’t say I liked it that much: with Ctrl +/-, you can zoom the terminal’s font, but the terminal does not resize accordingly. For that reason, I prefer to stay with the good old Gnome terminal (gnome-terminal).

First impressions

First of all, although I tried this installation in a VM, Fedora 36 seems pretty responsive and efficient. I might even say that the guest Fedora 36 VM looked faster than my host (Ubuntu 22.04). Maybe that was just an impression 😉

Since I chose the Automatic partitioning, Fedora created two BTRFS subvolumes (one for / and one for /home) with compression, and a separate ext4 /boot partition:

It also uses swap on zram:

I soon installed the extension “AppIndicator, KStatusNotifierItem and legacy Tray icons support to the Shell” by Ubuntu (https://extensions.gnome.org/extension/615/appindicator-support/) and it works in Gnome 42.

However, after installing Dropbox, while the icon shows on the system tray, clicking on that Dropbox icon (left or right-click or double-click) does not make the context menu appear, making that unusable. I seem to understand that it is a known problem, and maybe they are already working on that. For the time being, if you need the Dropbox context menu for settings like “selective sync,” you’re out of luck. However, you can use the dropbox command-line program for the settings. In that case, I first ignore all the folders and then remove the exclusion for the folders I want to have in sync.

For example, I only want “Screenshot” and “sync” from my Dropbox on my local computer, and I run:

On a side note, I find the Dropbox support for Linux a kind of an insult…

I look forward to upgrading my existing Fedora 35 installations on my computers, and maybe I’ll get back with more impressions on Fedora 36 on real hardware.

For the moment, it looks promising 🙂

Getting started with KVM and Virtual Machine Manager

After playing with VirtualBox (see my posts), I’ve decided to try also KVM (based on QEMU) and Virtual Machine Manager (virt-manager).

The installation is straightforward.

In Ubuntu systems:

In Arch-based systems:

Then, you need to add your user to the corresponding group:

Reboot, and you’re good to go.

In this post, I’m going to install Fedora 35 on a virtual machine through Virtual Machine Manager (based on KVM and QEMU).

So, first, download the ISO of this distribution if you want to follow along.

Let’s start Virtual Machine Manager (virt-manager):

Press the “+” button to create a new virtual machine, and we select the first entry since we have downloaded an ISO.

Here, we select the ISO and let the manager detect the installed OS. Otherwise, we can choose the OS manually (the manager might not catch the OS correctly in some cases: it happened to me with ArcoLinux, for example).

Then, we allocate some resources. Since I have 16GB and a quad-core, I give the virtual machine 8GB and two cores.

Then, we allocate storage for the machine. Alternatively, we can select or create a custom image file in another location. By default, the image will NOT occupy the whole space physically on your disk. Thus, I will not lose 60GB (unless I’ll effectively use such a space on the virtual machine). The file will appear of the specified size on your drive, but if you check the free disk space on your drive, you will note that you haven’t lost so many Gigas (more on that in the next steps).

In the last step, we can give a custom name to our machine and customize a few settings before starting the installation by selecting the appropriate checkbox (we also make sure that the network is configured correctly).

If we selected “Customize configuration before install,” by pressing “Finish,” we get to the settings of our virtual machine.

In this example, I’m going to change the chipset and specify a UEFI firmware:

We can also get other information, like the path of the disk image:

And we can click “Begin Installation.” After the boot menu, we’ll get to the live environment of the distribution ISO we chose:

You can also specify to resize the display of the VM automatically if you resize the window and when to do that. (WARNING: this will work correctly only after installing the OS in the virtual machine since this feature requires some software in the guest operating system. Typically, such a software, spice-vdagent, is automatically installed in the guest during the OS installation, from what I’ve seen in my experiments.)

And we can start the installation of the distribution (or try it live before the actual installation), as usual. Of course, the whole installation process will be a bit slower than on real hardware.

I’ll choose the “Automatic” choice for disk partitioning since the disk image will be allocated only to this machine, so I will not bother customizing that.

While installing, you might want to check the disk image size and the effective space on the disk:

After a few minutes, the installation should be complete, and we can reboot our virtual machine

And upon reboot, we’ll get to our new installed OS on the virtual machine:

In the primary Virtual Machine Manager window, you can see your virtual machines, and, if they are running, a few statistics:

In the virtual machine window’s “View” menu, you can switch between the “Console” view (that is, the virtual machine installed and running OS) and the “Details” view, where you can see its settings, and change a few of them.

Note that now the automatic resize of the machine display and the window works: in the screenshot I resized the window (made it bigger) and the display of the machine resized accordingly.

When you later restart a virtual machine from the manager, you might have to double-click on the virtual machine element and possibly switch to the “Console” view.

After installing the OS, you might want to check the image file and the actual disk usage again. You will find that while the image file size did not change, the disk usage has:

What I’ve shown in this blog post was one of my first experiments with KVM and the Virtual Machine Manager. To be honest, I still prefer VirtualBox, but maybe that’s only because I’m more used to VirtualBox, while I’ve just started using virt-manager.

That’s all for now! Stay tuned for further posts on KVM and virt-manager, and happy virtualization! 🙂