Language Selection

English French German Italian Portuguese Spanish

Review: Solus 3 and the Budgie desktop

Filed under
Reviews

Solus is an independent, rolling release distribution. Solus's design is mostly aimed at home users who want a friendly desktop operating system. The distribution is available in three editions (Budgie, GNOME and MATE) and runs on 64-bit x86 computers exclusively. Each edition's installation media is approximately 1.2GB in size.

The project's latest release is Solus 3 which features support for Snap packages as well as more traditional packages managed by Solus's eopkg package manager, which is a fork of the PiSi package manager. There were many tweaks in this release with a number of improvements made to the application menu and searches. The Budgie edition also includes the ability to place the desktop panel on any of the four sides of the screen. There are more changes and tweaks listed, with accompanying screen shots, in the project's release announcement.

One of the reasons I wanted to try out Solus 3 and do it now is because I typically test rolling release distributions immediately after a new snapshot has been released. Solus 3 was made available back in August of 2017 and I was curious to see how well the distribution would handle being rolled forward several months and what changes might be visible between the August snapshot and Solus's current packages.

I decided to try out the Budgie edition of Solus. Booting from the Solus live media brings up the Budgie desktop with a panel placed along the bottom of the screen. The panel houses an application menu, task switcher and system tray. On the desktop we find a single icon for launching the project's system installer. I did not see any welcome screen or encounter any immediate issues so I jumped straight into the installer.

Read more

More in Tux Machines

today's howtos

Android Leftovers

The Spectre/Meltdown Performance Impact On Linux 4.20, Decimating Benchmarks With New STIBP Overhead

As outlined yesterday, significant slowdowns with the Linux 4.20 kernel turned out to be due to the addition of the kernel-side bits for STIBP (Single Thread Indirect Branch Predictors) for cross-HyperThread Spectre Variant Two mitigation. This has incurred significant performance penalties with the STIBP support in its current state with Linux 4.20 Git and is enabled by default at least for Intel systems with up-to-date microcode. Here are some follow-up benchmarks looking at the performance hit with the Linux 4.20 development kernel as well as the overall Spectre and Meltdown mitigation impact on this latest version of the Linux kernel. Some users have said AMD also needs STIBP, but at least with Linux 4.20 Git and the AMD systems I have tested with their up-to-date BIOS/microcode, that hasn't appeared to be the case. Most of the AMD STIBP references date back to January when Spectre/Meltdown first came to light. We'll see in the week ahead if there is any comment from AMD but at this time seems to be affecting up-to-date Intel systems with the Linux 4.20 kernel. Read more

Today in Techrights