The Mac-ifying of the Linux Desktop

By

-

May 20, 2014

Elementary OS desktop

The sheer variety available to the Linux desktop brings with it a level of discussion and debate most other platforms do not know. Which desktop is the best? Should Linux hold onto what has always worked? Should the Linux desktop mimic what others already know? Dare Linux look and feel like OS X?

That last idea is a bit of a conundrum – one with multiple arguments. First and foremost, there is no debating that OS X is a fast-growing platform. It not only has deep roots in Linux architecture, it has been accepted by numerous types of users. There have been many attempts at “cloning” the OS X desktop on Linux. Some of those clones have succeeded, to varying levels. One in particular (PearOS) succeeded so well it was bought by an unknown American company and removed from existence. That company is rumored to be Apple (a Black Lab Linux developer announced (in a goodbye letter) he was leaving the team to join Apple “…in a Linux endeavor they recently acquired.” It’s fairly easy to put that two and two together.) But still, until there are facts, it is conspiracy, at best.

But what is it about OS X that not only draws the users, but has Linux developers scrambling to clone? One fact that cannot be denied about OS X is the consistency found throughout. No design element has been overlooked and every window opened retains the overall look and feel better than any other desktop. Beyond that, you have to start looking at apps…even more specifically, the likes of iTunes. Since the smartphone has become such an incredibly integral component of day-to-day life, users rely upon the tools to keep those devices in sync with their data. Whether you like the app or not, few apps do a better job of syncing multi-media and other data as does iTunes. Without something similar – Linux loses out.

Matthew Garret, in his essay The Desktop and the Developer proposes that “A combination of improved desktop polish and spending effort on optimising developer workflows would stand a real chance of luring these developers away from OS X with the promise that they’d spend less time fighting web browsers, leaving them more time to get on with development.”

Improved desktop polish. That statement alone should ring very true with Linux desktop designers across the globe. I would add modern to that – Improved modern desktop polish – because users are no longer happy with the likes of flat desktops, such as Gnome 2, Fluxbox, or KDE. Users, especially the average user, wants polish, they want something that looks as modern as the mobile tools they use.

Distributions, such as Ubuntu, have gone to great lengths to take that idea of consistency and elegantly apply it throughout. Unity does an incredible job of working the look and feel of the design to every aspect of the desktop. Linux Mint also has grown, leaps and bounds, with unifying the look and feel of the desktop.

Have Ubuntu and Mint caught up to OS X? With respect to unification of look and feel, it’s becoming a very close race. As for application familiarity, that’s another debate all together.

OS X-Like Linux Distros

As for distributions cloning OS X, PearOS has been forked, but even the fork is running into some levels of resistance. At first it was named Clementine and showed promise. The distribution then ran into legal issues with the name (the original name belongs to my media player of choice, Clementine). Now, Klementine OS is nowhere to be found.

Beyond the conspiracy theories, beyond the purchasing and obfuscation, why would a Linux distribution want to mimic the look and feel of OS X? When you do a search for “OS X Linux clone”, you generally come up with the following distributions:

PearOS
Elementary OS Luna
Clementine (now Klementine)
Red Star OS.

After much digging, I discovered yet another Linux distribution with a desktop aimed at resembling OS X. This distribution is called Pirum OS. This distribution was started by high school developer Tyler Wolf and, almost as quickly as it started, was re-branded into The Pear Project. No development, no signs of life.

This disappointment sent me reeling back to Google to discover LuninuxOS. Outside of having a double-take of a name (it’s pronounced loon-e-nux o-s), the platform has a single idea: that an alternative computing operating system should be beautiful, simply, fast, reliable and fun. After a bit of digging, it turns out this distribution is also no longer in development.

Why try to clone OS X?

All of this leads me to a single question: With so many challenges (some legal), why do developers insist on attempting to create an OS X clone of Linux? I’ve scoured through the various pages of the different distributions to seek out that answer. There are numerous conclusions to draw:

The developers want to mimic the OS X look because of its popularity
The developers feel the familiarity of the OS X interface will draw users
There is some truth to the ease-of-use claims that surround OS X.

Once you give some of these distributions a try, you quickly come to realize that some are simply a standard GNOME (in most cases) desktop with a Dock and a Panel. Once you get beyond the theme of the desktop, there is little OS X to be found. You won’t find iTunes or any of the other software stacks that draw people to Mac. What you will find is the standard Linux software. And that is nothing to hide. In fact (outside of the desire to look like OS X), when you examine the single most common goal of all of the OS X clones to have come and gone, you have one common goal:

Beauty.

All of these clones want to emulate what is often considered the de facto standard when it comes to elegance on the computer desktop: OS X. But by whose standard? Compare OS X to some of the modern Linux desktops, such as:

Unity
GNOME 3
Deepin Linux.

A new kernel debugging tool

Kernel developers use oops to find and fix programming errors that cause problems in the Linux kernel. Compressing them into QR codes solves several problems with this process, said PJ Waskiewicz, the Linux kernel developer who mentored Băluţă’s internship with Intel, funded by The Linux Foundation.

Oops messages can often be very large and tend to scroll off screen, especially on heavily-loaded systems and systems with large numbers of CPU’s, he said. “Or, in some instances, the panic is lost on hard lockups, since the framebuffer could be taken by the running window manager, and the panic is scribbled to the virtual terminal elsewhere.”

This makes it difficult for kernel developers and users in the field to quickly and accurately copy a kernel panic to aid in debugging. So bug reports sometimes have incomplete or missing panic traces.

“Getting good kernel panics and panic traces is very important for effective debugging,” Waskiewicz said.

For example, he said, “if I’m working on my laptop while traveling, and hit some obscure bug that I only see once every 3-4 months, I want to make sure to get a clean capture of the panic. I don’t have a serial console hooked up, I may be running some graphics workload that hangs the display, so the panic may have dumped the backtrace, but there’s no way to extract it.”

A QR code can encapsulate an entire oops and will still always fit on screen. Using KMS (kernel mode setting), it can also write the QR code to a portion of the framebuffer that will always be visible, so you never lose the panic, Waskiewicz said. And in a QR code format, you don’t need to be a kernel developer to find, read and report an oops – just take a picture of the crash and send it to your favorite bug reporting software so a kernel developer can dig into it.

How to catch an oops

To capture oops as QR codes, Băluţă first had to research existing QR code libraries that were compatible with the kernel and could also handle a large amount of text. She also studied algorithms capable of compressing all of that data and ended up using the zlib inside the kernel code. Finally, she had to insert hooks into the various oops paths in the kernel to catch the outgoing messages that comprise the full oops message.

“So now we have a compressed form of the QR code which I would write to framebuffer,” Băluţă said. “It’s fairly simple actually.”

Learning how to write to framebuffer was the most challenging part of the project, she said, because she wasn’t very familiar with the kernel code itself. Waskiewicz became her guide in navigating the kernel by pointing out, for example, the various existing compression implementations in lib/.

“He answered my questions over hangouts and email, was very patient with me and explained kernel internals when I had problems,” Băluţă said. “He was very open to discuss the ideas I had and I liked the fact that I had this freedom of trying things out.”

After graduation at the end of May, Băluţă plans to pursue her master’s degree in computer science and continue on the path toward becoming a Linux kernel developer.

“OPW was an eye-opening experience because I got to work and talk with really cool and different people: Marina (Zhurakhinskaya) from the Gnome Foundation who coordinated everything, Sarah (Sharp at Intel) was very thorough and helped all candidates throughout the application process, Greg KH, PJ, Paul McKenney (and everyone on the mailing list!) who reviewed our patches and corrected our silly mistakes,” Băluţă said. “I gained the confidence to do the things I want to do.”