Monthly Archives: September 2022

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

Leave a reply

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 😉

Finding a type in the classpath of an Eclipse Java project

Leave a reply

Recently, I started to contribute and maintain Pitclipse, an Eclipse plugin for running mutation testing with PIT.

We needed a mechanism to detect whether JUnit 5 is in the classpath of a Java project (so that we could run PIT with its JUnit 5 plugin).

The first implementation of such a mechanism was rather cumbersome since it manually inspected the Java project’s classpath entries. Something like that:

That’s rather unclear, and there are lots of paths to test.

I opened an issue for investigating an alternative implementation, https://github.com/pitest/pitclipse/issues/149, and I was thinking of something simpler, along these lines:

We could try to load some classes of the JUnit 5 engine by constructing a classloader using the classpath of the Java project.
Something like (untested):


That’s simpler and cleaner, but we can do better than that 🙂

JDT provides a lot of API for such things. For what we need to do, we can simply rely on IJavaProject method findType:

IType findType(String fullyQualifiedName)
Returns the first type (excluding secondary types) found following this project’s classpath with the given fully qualified name or null if none is found.

So it’s just a matter of creating a reusable method, e.g.,

And we can simply call it by specifying the fully qualified name of a type that we know belongs to JUnit 5 (PR https://github.com/pitest/pitclipse/pull/199):

Now we don’t even have to test several cases: we simply rely on the correctness of the implementation of findType. This is expected to work on Java projects, Maven projects, Gradle projects, etc.

My notes on the Grub incident in Linux Arch

Leave a reply

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

Leave a reply

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!