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 😉
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).
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).
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:
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
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.
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
What’s so different about Crystal compared to other distributions?
Easy to use package manager
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:
❖Successfully upgraded repo packages
?Continuetoupgrade AUR packages?[Y/n]:
❖No upgrades available forinstalled AUR packages
❖It appears that atleast one program you have installed/upgraded has
installeda.pacnewconfig file.These are created when you have modifieda
program'sconfiguration,andapackageupgrade could notautomatically merge
?Would you like Amethyst torun pacdiff todeal with this?You can always deal
with thislater by running`sudo pacdiff`[y/N]:y
==>pacnew filefound for/etc/pacman.conf
::(V)iew,(M)erge,(S)kip,(R)emove pacnew,(O)verwrite with pacnew,(Q)uit:[v/m/s/r/o/q]r
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):
$sudo btrfs su li/
ID258gen87top level256path var/lib/portables
ID259gen87top level256path var/lib/machines
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:
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!