GNOME3 Oversimplified?

gnome_logo

Seeing as how GNOME3 and KDE (4? 5? Plasma? Neon? Ion?) are the leading desktop environments nowadays, I decided to give GNOME3 a try on my openSUSE Leap 42.3 workstation (my current main distribution on most hardware, including a Raspberry Pi 3). There are good and bad things and some of it agrees with my former assessment of GNOME3. However, I assumed that since I’m more pro-desktop now, my opinion might change. Well, it did perhaps…

The Good:
In material design alone GNOME3 wins a trophy. There is a lot of MacOS X mimicry and I think that speaks well of the project. The guys (and gals!) from Apple know their stuff so why not get inspired by them a little? The overall UX (user experience) is also positive. Thanks to the highly intuitive interface finding important desktop features is a breeze. One just needs to browse a bit and not follow the imprinted this option must be hidden somewhere philosophy that other desktop environments teach us. Also, I greatly appreciate the attention to useful features like the one-click offloading of graphically intensive applications to the discreet nVidia card on Optimus laptops. If our day-to-day tasks focus on office work and leisure, GNOME3 could potentially be the desktop environment of the future. It stands to reason, because it’s an open-source project, molded and shaped into perfection by the user and developer communities. It constantly evolves so there is no limit to its improvements.

The Bad:
Unfortunately, it seems that simplicity of design has its price. Troubleshooting GNOME3 is extremely painful and many of the applications (including the Gnome Shell and the Gnome Display Manager) throw the most uninformative error messages.

something_went_wrong

Authored by the Interwebs

Case in point, the above error screen. The Oh no! Something has gone wrong is a phrase typically used in commercial applications to shield end users from the headaches of reading crash logs. By willfully choosing Linux we demonstrate that we’re no mere end users so treating us as such is quite rude. To dwell on this a bit more, the above error screen appears even when the Gnome Display Manager login panel crashes. How is one supposed to log out without being logged in to begin with? To make matters worse, since many Linux distributions have the display manager set to restart on failure, this screen will keep re-appearing until proper troubleshooting is done in one of the TTY consoles (ctrl  + alt + F1 – F9 keys). This very much reeks of Windows and MacOS X problems where the user interface basically took over the OS. All we can do is just reboot and hope for the best. Other applications show similar An error occurred messages without any means of actual troubleshooting.

My take-home from this experience is Thanks, but no thanks. If I want to get some work done, I would rather rely on LXDE, XFCE, LxQt and maybe even KDE. Traditional desktop environments without bells and whistles.

Advertisements

Mission: Saving Linux?

Recently, I was really into the BSDs and fiddled around with OpenBSD on some of my PCs. I still keep it on one laptop and FreeBSD on my main workstation. The point being that the BSDs are a lot more consistent, reliable and if something works out-of-the-box, it will most likely stay that way for a long while. Changes are incremental and major frameworks are not being reworked for semi-valid reasons, like oh, this looks old. Also, the very clearly superior BSD documentation – cannot go wrong with that!

Nowadays, Linux seems to be riddled with Windows-like problems. There is a surprisingly strong emphasis on easy-to-use GUI tools and hype for certain technologies (*cough* *cough* Docker) that are far from production-ready. The main rationale seems to be make it easy to set up. Everywhere I look there is loads of fluff. As Matthew Fuller put it in his discourse at over-yonder.net, we should be improving the back-end and extending it into usable front-ends, not the other way round. I agree, it’s important to enable people to do great things with technology, but if the how is there yet the why is missing, we’re not getting far. In addition, there is a lot of wheel re-inventing going on. People forget (or simply don’t know) that many of the great frameworks and tools were implemented already and can still be used effectively. Then, there is systemd (a case study on bad software engineering) and making Linux things so Linux-centric that portability suffers greatly (see: Docker being in fact Linux + Docker on non-Linux platforms). So there, we need a hero. Otherwise, we’re doomed to drown in self-indulgence.

A rather interesting idea would be to take the Linux kernel (for hardware compatibility reasons) and build a BSD-like operating system on top of it. Forget systemd, NetworkManager and other tools that try hard to do something that has already been done successfully. Leave the kernel + GNU coreutils in a steadily improving base and separate third-party software into package repositories. Also, one needs to start fresh – a clean slate to avoid the pitfalls of existing Linux distributions. In fact, there is already a project that tries to implement some of the BSD concepts in Linux and per my very preliminary impressions looks quite successful. Enter Void Linux!

Void seems to fill the gap (pun intended) between the Linux and BSD worlds aptly. There is a simple (limited?) init implementation called runit that takes care of starting the system as our favorite PID1, and launching service daemons to get a certain degree of persistence. It’s a typical Unix-like piece of software – does its job and swiftly moves aside to let us do ours. Then, there is the XBPS package manager and ports builder all-in-one framework. Think Arch’s ABS on steroids. Instead of OpenSSL we get OpenBSD’s LibreSSL (huge plus in my book!) and the musl C library alongside (but not on one installation, mind you) the traditional glibc. Speaking of C, all of these tools seem to be quite robust and xbps is perhaps the snappiest package manager I have seen in a while. Although the developer team is small, it’s doing a decent job at maintaining Void Linux. It’s a clear sign that it’s possible to run Linux without unnecessary bells and whistles, yet with all of the standard desktop features one might expect. My generic ASUS S301LA ultrabook handled Void Linux very well and all of its hardware was both supported and configured correctly (Intel WiFi Link 5100, SiS touchpad, AzureWave webcam, Intel HD 4400 graphics, WD-Green SSD, UEFI). Below a screenfetch rundown of the setup:

void_screencap

Now, it is true that finding a solution to 14 problems generates a 15th problem. There are certain aspects of Linux system design that I don’t completely agree with and adding orderly features on top of a Linux distribution mess doesn’t make the final product more organized. However, it’s a very successful step towards restoring some sanity to Linux Land that we lack so much nowadays.

The Open in BSD

I wrote about OpenBSD a bit in the past. Since then I’ve been distro-hopping plenty like a nervous flea that I am. Eventually, I put Debian 9.1 Stable on some of my machines and that’s what I run at work out of convenience and in case someone needs Linux-related help. I cannot say I don’t like it. To me Debian feels like the FreeBSD of the GNU/Linux side of FOSS. It’s sensible. It’s stable. However, I quickly tire of the systemd hiccups, focus on flashy graphical frameworks and other annoyances. Then, I turn to the BSD world with FreeBSD on my home workstation and OpenBSD on this here VAIO laptop. Admittedly, I was somewhat curious about hardware compatibility in release 6.1. This laptop is more powerful than the Intel M based Dell Latitude E5500 I used for testing OpenBSD previously. Also, the VAIO ran Debian 9.1 well enough that I could do actual work without waiting long minutes for a JavaScript-infested Web page to load. How would it cope with OpenBSD however?

Installing OpenBSD is fairly straightforward and if someone has ever installed Gentoo or Arch Linux….well, OpenBSD is easier! Out-of-the-box we even get an X11 server called Xenocara together with the xenodm display/login manager (not mandatory). Somewhat unfortunately, the default window manager CWM looks extremely dated and the black-white-grey dotted background would hurt my eyes. Not to worry, though. Openbox was just a pkg_add away. In fact, most of the tools I use every day were also, hence I didn’t really miss anything. It’s FOSS and I guess I shouldn’t be surprised that I can reproduce a fairly standard setup on another OS. The critical point for me was whether I could install all of the Python machine learning modules I use for writing regression tests. pandas, matplotlib and numpy are usually available from software repositories. Granted, not on every single open-source operating system. Luckily, the Python package installer PIP provides fantastic means of interoperability, which I encourage everyone to use. Even with Windows *cough* *cough*. Soon after PIP completed its work  I was set up and good to go!

OpenBSD

My desktop look – courtesy of myself (and the wallpaper’s author)

Then there is the usual How to make my system more polished? I got myself a nice OpenBSD wallpaper from the Interwebs (see: image above) and proceeded to reading the official documentation to understand the system better. The login environment is handled by the Korn Shell (the extra crispy OpenBSD variant of the Korn Shell, mind you), From there we add packages with pkg_add and modify them with a slew of other pkg_* tools. If anyone is familiar with former releases of FreeBSD, he or she will know the pkg_* commands. The system (kernel + core utilities) and the Ports Collection source code trees are tracked via AnonCVS, a largely improved CVS fork. It’s quite noticeable that the OpenBSD project strives to tweak and improve existing tools in order to make them more secure. I still need to figure out how to adjust the sound volume efficiently via mixerctl. Perhaps I’ll write a thin GUI client in Java or Python (or port my favourite volumeicon) in case none are available. Or just map a set of keyboard keys to mixerctl calls.

When comparing open-source operating systems, especially BSDs vs GNU/Linux distributions, people often consider things like system performance, resource usage, software availability, etc.

  1. Is OpenBSD faster than Debian? Not really. However, on modern PCs any open-source operating system is faster than Windows or MacOS X. This should come as no surprise.
  2. Does it use less system resources? Perhaps a tiny bit, though many open-source programs are portable and any optimizations are rather accidental. To give you an idea Openbox + WordPress opened in Firefox + mpv playing a jazzy tune amount to ~700 MB RAM in total. Not too shabby, right?
  3. Are programs X, Y and Z available? This largely depends on what tools one requires for work. The typical assortment (LibreOffice, GIMP, Inkscape, etc.) is there for the taking. Also, GUI tools can be replaced with CLI tools with minimal effort (for instance, Irssi/WeeChat instead of HexChat). The only real limitation I noticed so far is programs that are only accessible in binary form or certain device drivers with binary-only blobs (see: nVidia). OpenBSD has a strong policy against closed-source software and unless the company in question has a good reputation of providing quality software consistently, I think full source code disclosure is the right way to go.
  4. Is my hardware well supported? For device drivers see above. Other than that most (if not all) Intel-based hardware works as well as on GNU/Linux distributions. For improved 3D performance AMD is a fine choice, too. Perhaps webcam support is a bit lacking, but many models like the MacBook iSight even are supported.

The bottom line is this – OpenBSD is a great Unix-like operating system. It’s super secure and has one of the best documentations out there. If that’s your cup of tea, join the crew. If not, at least give it a try. I can assure you it’s worth it. Finally, a screenfetch for the geeks among us:

screenfetch_openbsd

In Software We Trust

Inspired by the works of Matthew D. Fuller from over-yonder.net I decided to write a more philosophical piece of my own. While distro-hopping recently it came to my mind that whatever we do with our lives, we never do it alone and our well-being depends on other people. It requires us to trust them. Back in prehistoric times a Homo sapiens individual could probably get away with fishing, foraging and hunting for food, and finding shelter in caves. The modern world is entirely different, though. We need dentists to check our teeth, we need groceries to gather food, we need real estate agents to find housing, etc. Dealing with hardware and software is similar. Either we build a machine ourselves or trust that some company X can do a good enough job for us. The same goes for software!

Alright, so we have a computer (or two, or ten, or…) and we want to make it useful by putting an operating system on its drive(s). MacOS X and MS Windows are out of the question for obvious reasons. That leaves us with either Linux or a BSD-based system. Assuming we pick Linux, we can install it from source or in binary form. This is where trust comes into play. We don’t need to trust major GNU/Linux distributions in terms of software packaging and features. We can roll with Gentoo, Linux From Scratch, CRUX or any other source-based distribution and decide on our own what does and doesn’t go into our software. It’s kind of like growing vegetables in a garden. Granted, we ourselves are responsible for any immediate issues like compile errors, file conflicts or missing features. It’s a learning process and one definitely profits from it. However, it’s also time-consuming and requires extremely good understanding of both system design and the feature sets of individual programs. No easy task that. Therefore, it’s far more convenient to use binary distributions like openSUSE, Ubuntu, Fedora, Debian, etc. It requires us to trust that the maintainers and developers are doing a good job at keeping software up-to-date, paying attention to security fixes and not letting bugs through. I myself don’t feel competent enough to be a source-level administrator of my own computer and be able to fix every minor or major issue in C++ code. I prefer to trust people who I’m sure would do it better than me, at least for now.