DistroWatch Weekly, Issue 735, 23 October 2017

Feature Story (by Joshua Allen Holm)

ArchLabs Linux Mínimo ArchLabs is a lightweight Linux distribution designed to provide a BunsenLabs-like experience based on Arch instead of BunsenLabs's Debian base. While there are certainly many stylistic similarities shared by ArchLabs and BunsenLabs, the latest ArchLabs release, named Mínimo, is clearly something that is inspired by BunsenLabs, but not a straight port of BunsenLabs onto Arch. ArchLabs has forged its own path, resulting a distribution that is BunsenLabs-like, but very much its own thing.



To find out what ArchLabs had to offer I gave it a try inside a VirtualBox virtual machine and bare metal on my laptop. Below, I take a look at the desktop environment, the install process, a handy setup script called AL-Hello, and more.



Installing ArchLabs



The install disc for ArchLabs Linux Mínimo is 956MB. For users just wanting to try out the distribution, the image comes with VirtualBox guest additions pre-installed. Booting the ArchLabs image in a virtual machine or from a USB drive on bare metal should be a familiar experience for anyone experienced with any modern Linux distribution. The live desktop environment boots quickly and the installer can then be run from the live environment.





ArchLabs 2017.09 -- The Calamares system installer

(full image size: 180kB, resolution: 1360x768 pixels)



The installer for ArchLabs is called Calamares. While much easier than Arch's do-everything-yourself install process, Calamares works pretty much like every other standard Linux installer out there. There are really no surprises here. The installer asks for the same information and does the same things as all the other Linux installation programs.



The only issue I had with Calamares happened the first time I tried to install ArchLabs in VirtualBox. For optimal installation, Calamares needs an Internet connection, but it only checks to see if there is an active network connection. When I was installing, my host computer was not connected to the Internet. The virtual machine had an active network connection, but when it finally tried to get data from the Internet near the end of the installation process, the installer failed, and it did not do so cleanly. Since this problem might also occur in situations where the machine is connected to a LAN with no outside access to the Internet, the installer should really start by checking to see if it has Internet access, not assuming it has Internet access just because it has an active network connection. In situations were there was no network connection or there was a network connection with an active connection to the Internet, the installation process worked as expected.



ArchLabs desktop environment



The desktop for ArchLabs is based on Openbox with a Polybar panel at the top of the screen. This top bar has four virtual desktops; a small shortcut menu for accessing the default web browser, terminal, and file manger, and logging out and shutting down the system; a window switcher that displays a count of how many windows are open; a network connection manager; volume control; and a clock. The application menu is accessed by right-clicking on the desktop. While lightweight, the desktop is aesthetically pleasing with nice transparencies, polished icons, and clean window decorations. On my system, I found that the desktop with nothing extra installed and no applications running used between 160MB and 180MB of RAM, but the blog post announcing the release of Mínimo lists RAM usage closer to 260MB. Either way, much, much lighter than some of the alternatives.





ArchLabs 2017.09 -- The default desktop

(full image size: 201kB, resolution: 1360x768 pixels)



Installing software



The default ArchLabs desktop does not come with much software. Firefox for web browsing, Geany for text editing, Audacious for audio, MPV for video, Thunar for file management, and a few other utilities come pre-installed. However, installing additional software is very easy using the AL-Hello script that runs after the system has been installed. This script asks dozens of questions, letting the user customize their system to their liking. To give just a few examples: the script asks if the user wants to add a dock, what office software they would like (if any), if they want to install Steam, if they want to install extra media codecs and fonts, and the list goes on.





ArchLabs 2017.09 -- The customization script

(full image size: 172kB, resolution: 1360x768 pixels)



While very thorough, the AL-Hello script is not perfect. Each question is just a single line in the terminal with no context. If a user is unfamiliar with a particular option, they have to look elsewhere to find out what the programs mentioned are and what they do. Because each prompt is a single line in a standard sized terminal window, there is plenty of room to provide more text explaining what various choices are. Another minor problem is that some of the options give multiple options and an “install all” option, but if the choices are A, B, and C, with D being install all, there is no way to just install A and C, for example. Don't get me wrong, the script is wonderful, but both of these issues are usability enhancements I would very much like to see in future releases.





ArchLabs 2017.09 -- The Pacli package manager

(full image size: 206kB, resolution: 1360x768 pixels)



The AL-Hello script does a great job of getting a system up and running with a large selection of packages, but it does not cover everything. After the initial setup, ArchLabs uses Pacli to handle installing and updating software. This text-based utility has options for installing software, updating the system, and all the other traditional package manager tasks. If the text-based interface is too spartan, Pamac is available as one of the many options available in the AL-Hello script. Pamac provides a graphic interface for installing and updating software, for users who prefer graphical interfaces to text-based ones. Either way, there are plenty of software packages available, so installing all of their favorite applications should not be a problem for most users.



Final thoughts



ArchLabs is a great combination of lightweight and, thanks to its Arch base, constantly up-to-date software. While probably not for everyone, ArchLabs is a polished distribution that anyone looking for an Arch-based distribution that has a pre-configured desktop and software selection should check out. The only drawback is that, like many lightweight distributions, selecting applications based on what is deemed best for an individual task can result in an odd hodgepodge of applications that all behave differently. Of course, the choice of what to install is up to the user, so that might not be a problem for some, but having applications from Xfce, GNOME, KDE, etc., can lead to a jumbled user experience. * * * * * Hardware used in this review



My physical test equipment for this review was a Lenovo Ideapad 100-15IBD laptop with the following specifications: Processor: 2.2GHz Intel Core i3-5020U CPU

Storage: Seagate 500GB 5400 RPM hard drive

Memory: 4GB of RAM

Networking: Realtek RTL8723BE 802.11n Wireless Network Adapter

Display: Intel HD Graphics 5500 * * * * * Visitor supplied rating



ArchLabs has a visitor supplied average rating of: 9/10 from 96 review(s).

Have you used ArchLabs? You can leave your own review of the project on our ratings page.





Miscellaneous News (by Jesse Smith)

Solus updates, Manjaro improving on-line MS-Office integration, Ubuntu's changing desktop sessions, Parabola creates OpenRC spin, information on the WPA vulnerability The Solus project published a newsletter this week which laid out several important changes and upgrades coming to the distribution. Among the key changes are an upgrade of the GNOME desktop to version 3.26.1 and getting the Control Centre to better integrate with the rest of the distribution. Behind the scenes, the LLVM compiler has been upgraded to version 5.0.0. Several changes have been applied to the Steam gaming portal too: " Linux Steam Integration has seen three releases this week and features a new 'liblsi-intercept', which controls the dynamic linking for Steam binaries, resolving some long-standing issues such as crashes on start, broken full screen views, and ensures that the Steam client uses OS-provided libraries. liblsi-intercept also provides a whitelist to allow Steam to continue to load its own private libraries and our intercept behaviour is controlled on a process-name basis. What does this mean? Well it means the Steam client is now using more system libraries, such as SDL, which fixes crashes as well as full screen issues when watching a game trailer in the store. " * * * * * The Manjaro Linux team is working to integrate the on-line version of Microsoft Office with the Linux desktop using the Jade Application Kit. The new functionality, which makes Microsoft's on-line productivity tools appear to run like native Linux applications, can be set up on Manjaro by installing the ms-office-online package. A discussion on the new functionality can be found on the Manjaro forum. * * * * * This past week there has been a lot of talk about a vulnerability in most implementations of WPA2 which could make it possible for attackers to break the encryption on wireless network traffic. The vulnerability is widespread and affects most major desktop and mobile operating systems. The FreeBSD team has a good summary of the issue: " A vulnerability was found in how a number of implementations can be triggered to reconfigure WPA/WPA2/RSN keys (TK, GTK, or IGTK) by replaying a specific frame that is used to manage the keys. Such reinstallation of the encryption key can result in two different types of vulnerabilities: disabling replay protection and significantly reducing the security of encryption to the point of allowing frames to be decrypted or some parts of the keys to be determined by an attacker depending on which cipher is used. We are actively working on a patch for the base system to address these issues. Current users who use Wi-Fi with WPA2 should use a wired connection as a workaround, and we strongly recommend using end-to-end encryption methods like HTTPS or SSH to better protect against this type of attack. " * * * * * With the launch of Ubuntu 17.10 this week, the distribution is making GNOME the default desktop instead of the formerly used Unity desktop. With this change, some people running Ubuntu and Ubuntu GNOME may be wondering about how to upgrade and which desktop sessions will be available. The DidRocks blog has some answers and a guide for navigating the various desktop options: " The 'Ubuntu' session corresponds to GNOME Shell experience with our modifications (Ubuntu Dock, appindicator support, our theme, small behaviour changes). You have probably seen those and followed their development on previous blog posts. This is the default session running under Wayland. The 'Ubuntu on Xorg' session, being similar to the previous one, but running on Xorg as the name indicates. Users who can't run Wayland (using NVIDIA proprietary driver or unsupported hardware) should be automatically fallbacked and only presented with that session. " * * * * * The developers of Parabola GNU/Linux-libre, a free software distribution based on Arch Linux, are experimenting with new spins of their operating system. The new spins will feature the OpenRC init software instead of systemd. A post on the project's news page reads: " Since a considerable amount of Parabola developers and users prefer to use the OpenRC init system instead of systemd, which is the default, we are proud to announce the first releases of Parabola GNU/Linux-libre OpenRC Edition ISOs! As of now they are still in beta, you can get them here . These are not official, yet, but we are working on fixing all their issues. You can help by testing them and giving us some feedback so we can improve them. Besides this, due to a bug in MATE , we are planning to replace MATE with LXDE in the graphical ISOs (available with systemd and OpenRC) and include the Calamares installer for a more user-friendly experience for newcomers. * * * * * These and other news stories can be found on our Headlines page.





Tips and Tricks (by Jesse Smith)

Building software with Ravenports One challenge software developers and packagers constantly face is the effort required to get new projects packaged for the wide variety of operating systems and package managers present in the open source community. If I write a new utility and want to share it with the community, then I (or other packagers) need to create a variety of packages in various formats. Traditionally, I might need to make an RPM package for the Fedora family of distributions, a Deb package for the Debian family, and another package for the Arch family. If I want to support the BSDs, then each flavour (FreeBSD, NetBSD, OpenBSD, etc) has their own unique style of creating and testing ports & packages.



Portable package formats such as Flatpak and Snap reduce the effort package maintainers and developers need to put into supporting each separate platform, but we can still easily run into cases where we need to work with four or five separate package formats to support a wide range of open source systems. This results in a lot of duplicate effort, basically teaching each package manager how to build and install the software. Ideally, it would be nice to create just one package or port script for the software we write and have it work across all open platforms. This is where a young project called Ravenports shines. The Ravenports website describes the project as follows: Ravenports is an integrated system designed to build packages of complex software on all UNIX-like platforms. It is considered "universal" because Ravenports is not anchored to any single operating system; once the build procedure for a particular software is created, that software is then available for all supported platforms. The simplest use case is to access the freely available prebuilt package repository for each supported platform. What this means is I, as a developer, can create one set of rules for building my software on the Ravenports framework. That one recipe can then be used to build native packages that will install and run on DragonFly BSD, FreeBSD and almost all flavours of Linux. This has the potential to be a huge time saver for developers and people porting software. We do not need a separate build file or script for every operating system and package manager, we just need one Ravenports port and the software should build and run everywhere.



This idea sounds good, at least for hardworking developers and package maintainers, but does Ravenports deliver on its lofty goals? I decided to test Ravenports on a copy of Manjaro Linux and find out.



Ravenports does have a few restrictions in its current form. Right now, Ravenports runs on 64-bit x86 systems exclusively. Some of the tools used to set up Ravenports are 64-bit executables and simply will not run on 32-bit computers. On Linux, there is a library dependency, but this should not be an issue for any mainstream Linux distributions.



The Ravenports project has documentation which explains how to set up the ports system on Linux distributions. The initial set up of Ravenports just takes a minute and, when it is completed, we essentially have two key tools available in our operating system's /raven directory.



The first significant tool is a native, statically-linked version of the FreeBSD pkg package manager. This package manager can be used to find packages in the Ravenports test repository, install packages (either from a remote source or locally), display package information and statistics and remove unwanted Ravenports packages. The pkg package manager is located at /raven/sbin/pkg-static. I like the pkg package manager, it is fast, has informative prompts and offers a fairly straight forward syntax.



The second tool we get when we install the Ravenports framework is a utility called ravenadm, which can be found in the /raven/bin directory. The ravenadm program can be used to discover what ports are available, whether we have installed a specific port or not, and build local copies of a port. The main function of ravenadm is to turn source code into binary packages and we can do this using the build keyword. For example we can fetch and package the curl application using: sudo /raven/bin/ravenadm build curl Ravenports has a much more elegant approach to showing us what it is doing than most other port build systems I have encountered. Most port systems flood the terminal with each instruction the build is performing and any output from the compiler or other build tools. This show-everything approach can be useful for debugging issues, but it is ugly and typically unhelpful in other situations as the user is not shown useful progress information or statistics. Ravenports takes a cleaner approach. Instead of being shown step-by-step instructions, we are given a general overview of what the build process has done and plans to do. While it is working, Ravenports displays a dashboard in the terminal which shows how many ports it is going to build (including dependencies), how many it has built and how many ports have been completed successfully. The messy step-by-step details are logged to text files in the /var/ravenports/primary/logs/logs directory in case we need to go back and investigate a port which failed to build. Each port gets its own log file which greatly reduces the amount of scrolling we need to perform when searching for problems in the build information.





Ravenports -- Showing build status information

(full image size: 383kB, resolution: 1280x1024 pixels)



When my build process finished I was curious to see if my newly built software would run natively on my Linux box. However, it was not immediately clear where my freshly built packages had been stored. They were not in the /raven directory and the new software had not been copied into my user's path. I eventually found new packages were stored in the /var/ravenports/primary/packages/All directory. These packages could then be installed using the pkg package manager by running sudo /raven/sbin/pkg-static add /var/ravenports/primary/packages/All/package-name The above command installs our new package into the /raven directory. We can then run it using the program's full path or by adding /raven/bin to our user's executable path.



At this point it may be clear that installing software from Ravenports is not exactly convenient for end users. Which is fair, Ravenports is not attempting to make package management easier for end users, this is a framework for developers and packagers. Which means the questions we should be asking are whether or not Ravenports works and whether it makes packaging easier?



I am happy to report Ravenports definitely works. I tried installing pre-built software from the test repository and built three ports at random. All four packages installed and worked properly on my Manjaro Linux test box. And, assuming the framework is functioning as expected, I should be able to build the same ports on any other Linux distribution, DragonFly BSD or FreeBSD. This is a big step forward for people who maintain ports and packages. Typically I need to maintain separate build instructions for RPM- and Deb-based distributions as well as BSD ports. With Ravenports, I could use one set of instructions and have my software automatically packaged everywhere. It is potentially a huge time saver.



The only drawback I see with Ravenports is it requires each operating system to support it in some way, either by setting up a Ravenports software repository or linking to the Ravenports testing package repository. In theory, in a few years each distribution could compliment (or even replace) its existing build system with a Ravenports system and every upstream software project would only need one person to maintain the cross-platform port. But that would require each operating system to feature a way for users to easily install Ravenports packages. Historically it has been difficult to get open source systems to standardize on any one system, there is a lot of inertia when it comes to packaging open source software. Still, I think Ravenports holds a lot of promise as a cross-platform, write-once-package-for-everyone framework. It has the ability to do for packagers what Flatpak and Snaps have done for end users, reducing the effort required to create and distribute software packages. * * * * * More tips can be found in our Tips and Tricks archive.





Released Last Week

Torrent Corner

Upcoming Releases and Announcements

Opinion Poll

Cross-platform ports and packages



In our Tips and Tricks column we discussed Ravenports and how it can be used to build packages cross multiple operating systems. Ravenports is not the only cross-platform ports system and other projects, such as pkgsrc, assist users in installing applications on a variety of platforms.



This week we would like to know if you use a cross-platform ports framework or cross-distro package manager, like Ravenports. Please leave us a comment letting us know which one you use on your computer(s).



You can see the results of our previous poll on keeping utility discs on hand in last week's edition. All previous poll results can be found in our poll archives.



Cross-platform ports and packages



I use multiple cross-platform ports systems: 50 (5%) I use one cross-platform ports system: 83 (8%) I do not use a cross-platform ports system: 921 (87%)