There are so many other Linux distributions
Xubuntu Linux looks very old fashioned when compared to DeepinOS, Linux Mint, Ubuntu, and other beefier Linux distributions. So why does the Working Centre’s Computer Recycling Project still use Xubuntu Linux when there are better-looking alternatives? Isn’t the idea to attract people to Linux?
A collection of reasons
There are a number of reasons Computer Recycling still uses Xubuntu Linux. The best place to start is the beginning:
History
In the beginning, the Working Centre’s Computer Recycling Project ran a Linux distribution, WCLP, spearheaded by Paul Nijjar, and developed by Daniel Allen and Karl Amdur. Paul started the project back in 2001 and presented the idea to the Kitchener/Waterloo Linux User Group in October of 2001. WCLP was a Debian GNU/Linux-based distribution that initially had a target of putting a desktop on a 486 25MHz machine with 16MB of RAM and a 500MB hard drive. WCLP featured IceWM as the Window Manager. At the time IceWM was both extremely lightweight, and had the familiarity of a “Microsoft Windows-like” interface.
By 2004 a number of new Linux distributions arrived on the scene, including a promising one called Ubuntu Linux. While the project was aware of Ubuntu Linux back in 2004, a lot of work had gone into developing WCLP. WCLP could be deployed completely to machines via FAI, a Fully Automated Installer, so all machines would be identical, and volunteers would have less work to do. Still, the project was still largely developed by the 3 volunteers above.
I made some minor contributions early on, PS/2 mouse support (with help from my youngest brother), a graphical bug-reporting tool (which never made it into the distribution, but which I still have the code for), and redoing the manuals in Docbook (which we didn’t use). My role at this time was largely helping install WCLP to machines, and helping rebuild hardware.
There was a project similar to WCLP back then called RULE. RULE stood for RUn Linux on Everything. The chief difference between RULE and WCLP was that RULE used Red Hat Linux as a base operating system. I tried RULE several times, and I always maintained that WCLP was better. Keep in mind that up until I found out about WCLP I mostly preferred Red Hat-based Linux distributions (Mandrake Linux, Red Hat). I put this in as more of an aside since there isn’t much information on the Internet about RULE. It was a good project, and was used by at least a couple of refurbishers. As far as we know WCLP was only ever used by The Working Centre’s Computer Recycling Project.
By 2006 maintaining WCLP had become a nightmare. Paul was the sole developer working on the project. One of the biggest challenges back then was how to deal with all the proprietary hardware, installing a wifi driver was not as simple as typing “drivers” into the menu system, and clicking to install a driver. Often a proprietary driver would have to be extracted from a Windows executable, and then ndiswrapper would be used to “wrap” around the driver – essentially tainting Linux with Windows drivers. Ubuntu 6.06 solved a lot of the challenges WCLP faced.
Despite Paul’s best efforts, maintaining WCLP by himself was just too much. I joined the staff of The Working Centre in September 2005 as the new person maintaining Computer Recycling. I made the decision in late 2006 to start using Ubuntu 6.06 since it solved a lot of the problems WCLP was trying to solve, and it was simpler to install on a lot of the hardware the project owner.
Canonical, the company behind Ubuntu, used to really push the desktop as a grass-roots project that solved a lot of problems people had with their hardware. Some people complained about the brown-look of 6.06, and there were issues with some of the optional wallpaper (some nudity had crept into one of the optional backgrounds), but it was otherwise a very solid Linux distribution, and it worked on most of our hardware.
Things were good in the Linux world for our project until Canonical decided to change the default interface in Ubuntu from GNOME 2 to Unity (2011). Unity simply wouldn’t run on a lot of the laptops our project was seeing. Even some of the desktops didn’t have the right graphics card capable of running Unity. It was time for a change.
We looked at the Linux Mint project at this time, but when we tried it on several of our machines we ran into a number of issues – it just didn’t run correctly on several of the machines we tested it on. We also tried some Red Hat-based Linux distributions (we ruled out RULE, which by this time was also a memory), but they fell flat.
Xubuntu Linux had the familiar feel of GNOME 2, the core of Ubuntu, and worked well on all the hardware we tested it on. It became our new Linux desktop standard in 2011. Paul joined the Working Centre in 2007 as a system administrator for the larger organization, but set up a server so the Computer Recycling project could deploy Xubuntu Linux via a PXE (network) server. The process was almost completely automated. The PXE server could also be used to wipe drives via DBAN and test memory via Memtest. The system worked well, so well that we mostly still use the system Paul built to this day.
Of course Xubuntu has gone through a number of iterations since 2011, and the system has been updated every time there’s a new LTS release. A couple of years ago the Ubuntu project switched gears and made some changes to the way *buntu is installed. It used to be we could just copy a few files from the ISO, and mostly use our existing Debian-Installer configuration files, for completely automated PXE installs of Xubuntu desktop, but this no longer seems to be the case (particularly for our after-the-install scripts). There’s also the confusion with UEFI. I’ve made some changes to our PXE server to let it UEFI boot, but it doesn’t work universally. Some of the programs we PXE boot don’t support UEFI PXE-booting (older versions of DOS tools), but I’ve recently updated some of these tools.
Not that long ago we ran into a couple of “deal-breaking” bugs with Xubuntu where I considered switching to another distribution. One of the bugs was that the interface for changing printers would freeze if you tried selecting another driver. The other was forcing people to use snaps. As a concept snaps are not terrible, but the initial implementation and forcing people to use Firefox as a snap was disastrous. It took more than 25 seconds for Firefox to launch on the machine I’m typing this on, a system with an Intel Core i7-4770 with 16GB of RAM – a seriously bad number, even if it did launch faster subsequently. We were still pushing out a few Atom-based netbooks with 4GB of RAM, launching Firefox was a brutal experience. Both the printer freezing issue and snap issue got better. Snaps were sped up, and the printer issue was completely fixed. So we’ve soldiered on with Xubuntu. Currently the project is installing both Xubuntu 20.04 and 22.04.
Just before the pandemic, the Computer Recycling Project, made some major changes. From about 2007 until 2020 Computer Recycling also participated in Microsoft’s refurbishing program. The project bought licenses of Windows and Office, aimed at helping low-income earners be able to afford a properly licensed Windows-based computer. Initially the program was very helpful, people who were taking Microsoft Office training, and who were a qualified Low-Income individual, could purchase a Windows-based computer from the project (we used the LICO, Low Income Cut Off to determine eligibility and people buying a machine had to sign an agreement and prove income).
I won’t go into the reasons extensively here, but the program changed so that Microsoft was less involved in managing the program. At this time we decided to stop participating in the program and go Linux-only. We knew going Linux-only would be a challenge, so we invested a lot of time and resources creating documentation and troubleshooting problems. This extra time investment meant we had to be sure of what we were going to deploy. I tried Linux Mint again, and several other distributions, but kept coming back to Xubuntu because it mostly “just worked” on a lot of the hardware we deploy.
The project still builds the occasional Core 2 Duo desktop or laptop, though my ideal target now is at least 2nd generation Core i-Series machines. Xubuntu still works on these systems, though some of the software works less well as time goes on.
Familiarity
When we made the change to Xubuntu, one of the reasons why we chose it was because it “felt” both like GNOME 2 and Windows XP. There are still a lot of (mostly older people, of which I’m part of) people who feel Windows XP was one of Microsoft’s best releases. To me, it broke the Windows barrier in the same way early versions of Ubuntu made Linux more accessible to people.
Xubuntu has that Windows XP esthetic, even if it doesn’t look the same. Clicking on the “start” button brings up a menu, which in later versions of Xubuntu is searchable (the “whisker menu”). The configuration menu also shares some similarity with how configuration has been done on Windows for awhile.
This also ties in to the next point:
Customization
The default installation of Xubuntu Linux is pretty bland. The Computer Recycling Project has been customizing Xubuntu as long as we’ve been installing it. All installations prior 22.04 had an extra panel added to the bottom with a selection of icons added to it, to make it simple for people to one-click programs like Firefox, GIMP, and LibreOffice.
Xubuntu uses XFCE, which can be customized both through the user interface and the command-line. This makes it simpler for us to automate customization changes. We don’t need to “remaster” the distribution, just script any changes we want.
For Xubuntu 22.04 I removed the extra panel at the bottom and installed a more modern-looking program called plank, along with some customization to the icons and programs displayed. It’s all scripted via a BASH script that gets deployed via a master script that makes a few other changes to the system.
Some Linux distributions use a desktop environment that isn’t as customizable. The environment might have better customization tools, but may not let you script things as simply, or forces you to use a particular tool that doesn’t always work.
While it’s true that customizing Xubuntu is a bit confusing compared to other environments, it’s still the same process as it’s been for a long time, so it’s simpler for our project to make configuration changes.
Lightweight
While Xubuntu Linux isn’t as lightweight as Lubuntu Linux, or a distribution like Puppy Linux, it has the right combination of functionality and weight. Over the years we’ve seen people suggesting some KDE-based distributions were lighter-weight than Xubuntu, but we’ve never come across a KDE-based distribution that worked as well on all the hardware we install Xubuntu to.
As I hinted earlier, we’ve installed Xubuntu on machines with super-under-powered Atom-based processors. With an SSD these machines have run okay, but our minimum target machine is increasingly moving towards 2nd to 3rd generation Core i-Series machine. As software changes, there are sometimes changes that take better advantage of instruction sets on newer machines.
In some cases a Core 2 Duo will out-perform a newer Atom-based or AMD E-series based system. Compressing video via Handbrake comes to mind as one of the scenarios where an older machine can sometimes outperform a newer machine, but this is happening less and less as more software takes advantage of extra instruction sets in newer chips. A modern i3 can outperform a Core 2 Duo easily, and some older i5 processors.
Even given our moving target, we still want to be able to support people who already have older hardware, Xubuntu is good for this.
PXE / Network installation
Part of our project’s investment in Xubuntu comes from the large amount of work that’s been put into fully deploying the system via a PXE server / network installation server. The Computer Recycling Project has been deploying Xubuntu via PXE for over 12 years now.
Times change, and as I hinted earlier, how Ubuntu is deployed started changing way back in the Ubuntu 18.04 days (2018). Deploying Ubuntu server is different from before, the system no longer uses the Debian Installer for deployment, making it trickier for those who deployed Ubuntu server using this method. Since 18.04 things have progressed further towards the new installation method, and the old ways of installing are not as simple anymore. We can’t use the same configuration files we once used to deploy Xubuntu. On top of this documentation around automatic deploying Ubuntu Desktop or other flavours of *buntu is fragmented. No official documentation exists from Canonical that takes you through the A-Z of setting up a PXE server to completely automate the deployment of Ubuntu Desktop from start to finish. There is documentation around fully deploying Ubuntu Server, but it’s confusing, and links to other works. On top of this UEFI has added more of a wrinkle to things, one method for non-UEFI systems (syslinux), another for UEFI systems.
A few years back I started working on a new PXE server. It worked extremely well, some of our tools loaded 10x faster than they do on our old server. But we complicated that server by adding automated Windows deployment (for our larger organization staff), which to be fair was on the old server too. Windows had changed a lot too so what we used to do didn’t work the same way. In the end the server ended up losing some drives, and the work I’d put into it.
Because the process was a bit involved, learning about dhcp, tftp, nfs, etc., I decided some of this should be automated. As such I started a few scripts on github, none of which come close to mirroring the work I originally did, but are a step towards building a new PXE server. The scripts are still in a non-working state, but can be seen here:
- https://github.com/chaslinux/deploy-pxe/blob/main/deploy-pxe.sh
- https://github.com/chaslinux/ubuntu-pxe/blob/main/ubuntu-pxe.sh
Both scripts assume an installation of Ubuntu Server with git installed. It’s also assumed you’re using something other than the server for DHCP (like pfsense). The boot images get pointed to in pfsense. It’s been awhile, but I also seem to remember I assumed a DHCP reservation for the PXE server.
With the recent release of *buntu 23.04 there’s a new ISO. I believe the release of this ISO was in part an attempt to appease some who PXE booted a mini.iso before and deployed using that method, though I’m happy to be wrong about this.
Deployment of Xubuntu 22.04 via the PXE server isn’t completely automated. Instead it uses *buntu’s newer method of “live booting” an image. Some of the decisions that used to be automated in 20.04 and earlier, are now stepped through via this live graphical installer. There are not a lot of steps, but choosing a wrong username and password could lead to confusion when we go to support a machine.
After the installation we install git and pull a script called 1ring (yes, one ring to rule them all), which pulls 3 other git scripts to do things like identify hardware, install extra software and customization, and benchmark each system. These scripts are now almost completely automated, with the exception of the testing script which likely could be automated completely.
More effort
I’ve also been attempting to put more effort into helping people learn Xubuntu via Youtube videos, blog posts here, and documentation updates and support. Xubuntu might not be the slickest Linux around, but it seems to work well on the hardware we refurbish, and it looks like the process for completely automating deployment is headed back in the right direction. More and more people are starting to document the new installation methods, it would be nice if Canonical stepped up to the plate and made this a lot simpler for organizations like ours, but I don’t expect the desktop market, ours in particular, is on their radar anymore.
As our project starts to open up more again I’m hoping to move things forward, but for now we’re using a bit of a band-aid solution.
Conclusion
Using Xubuntu was a natural evolution given the early adoption of a Debian-based Linux distribution. Xubuntu’s light-weight nature, and familiar interface made it a logical choice back in 2011, and the fact that it still runs well on lightweight hardware today makes is still attractive. Xubuntu doesn’t espouse modernity, but what it lacks in flash, it makes up in customization (and usability once you learn hot keys). Our project has for the most part, been able to copy our existing configuration files, to automate the deployment of Xubuntu over many versions. We still use that method for deploying Xubuntu 20.04 (which has an EOL in 2025), but increasingly we’re considering change. For the moment I’m still enamored with Xubuntu because I can get work done faster on Xubuntu than any other system.
As an aside, last year I tried Linux Mint XFCE for a month. I was on vacation at the time and didn’t have an easy way to redeploy Xubuntu where I was. After the month was finished I couldn’t wait to install Xubuntu again. I liked the look of Linux Mint XFCE, but once you get used to how a particular user interface functions, and become productive with some of the hot-keys, it becomes harder to relearn something else. I think this is telling, as it’s likely the same for others on other operating systems trying to move to Linux. For now Xubuntu still works for our project. We’ve invested a lot of time over a number of years exposing people to Xubuntu. It may not be the flashiest OS, but it (still) works for us.