The State of Linux

1.1. Abandoning Apple

But longing for a return to the past rarely works. These days, Apple releases updates with security issues allowing ‘root’ login without a password. They patch it, then release another update with it broken again. And if you want to connect a modern Mac laptop to anything, you’ll need a sack of dongles. And the laptops they offer are fine for the common folk, but nothing really stands out for the power user. Add to that the current Mac laptops being totally unserviceable (RAM soldered, SSD soldered or proprietary, batteries glued into cases, custom screw drives), nor upgradeable. I would happily pay a premium for quality—but for something designed for obsolescence and disposability? Fine, for a $300 machine—but not for something that’ll run me $1,800. Enough is enough.

Then there’s Apple’s direction. I found their ad foreboding this past holiday season, featuring a kid doing various stuff with an iPad pro throughout his day. At the end of the day, his mom asks him if he’s been working on his computer, to which he responds, “What’s a computer?” Never mind that one point he connects a keyboard, because he needs to type stuff—which begs the question, if you need that, why not just get a laptop with one built-in? Apple made a decision long ago that there’s these iThings with touch screens and no keyboard, and the Mac, which has a keyboard and trackpad. The rest of the world decided to build laptops with touchscreens and flexible hinges to transform, but Apple held out—perhaps denying the world changing, much like I’d like to do about Apple’s decline.

They finally added the half-hearted touchbar to the higher-end laptops, and rumor is that iOS and macOS are going to merge. My guess would be Macs will get the iOS libraries, allowing them to run iOS software. Apple’s already solved the 32 vs. 64 bit Arm and other device variances issues: developers upload code to the App store, which recompiles it to produce all the variants needed. It would just be a matter of producing one more variant for Intel platforms.

Of course, the Mac libraries will still be there to support legacy stuff. And there are corresponding rumors about Macs with touchscreens. It makes sense, although it could be rumor—but while we’re all waiting for confirmation, I feel left out to pasture, a developer on a dying platform. I’ve struggled with the uncertainty for at least 2 years, probably longer. With my old Mac laptop, Stefanie, over 8 years old, and being unwilling to replace her with the shit new options Apple sells, I finally pulled the trigger.

I used my boyfriend’s decommissioned PC with dodgy CMOS to try out elementaryOS and LinuxMint. I settled on Mint, and bought new hardware: “Lenora” is a ThinkPad because I’ve heard good things on durability, they’re affordable, and Linux is alleged to run well on them. I repartitioned the drive, retaining a Windows partition, then installed Cinnamon flavor LinuxMint.

But let’s be clear: it isn’t that I went to Linux, it’s that I left Apple.

1.2. Muscle Memory

Although some people bitch about Apple’s stronghold on their platform, it’s not a bad thing. Every application has a menu, every application has the same basic hotkeys, the dialogs have the same shape and look buttons and the same responses to keyboard input (enter, escape). After being on a Mac a while, it’s easy to forget what you’re doing: the brain’s higher functions think what they want, and the lower functions and body execute it without conscious thought. It’s like touch typing, but instead of thinking words and having them appear, you think actions and they happen. And that left me free to focus on my projects' details, instead of fiddling with the UI and trying to use the software.

Linux is built piecemeal, and it feels like it. Some applications have a menu, some don’t. Some look like they were designed with tablets or small screens in mind, others traditional machines or larger screens. A program’s “Preferences” dialog may be in the Edit menu, or under Tools. It might be called “Options” instead. If it has a hotkey assigned, it’ll be unique. On the Mac, I didn’t need to hunt. It’s in File->Preferences, although my body knows it better as propeller-comma. Always. If that doesn’t work, it’s because there is no preferences dialog. It’s the same with print, cut-copy-paste; minimize window, close window, hide application, quit application, and a bunch of other actions.

The cut-copy-paste trilogy is the truly egregious instance of this problem. On Linux, it’s usually control-x, control-c, and control-v. Except in terminals, where these already have meaning. So instead, it’s shift-control-x, shift-control-c, and shift-control-v. So every time I want to do one of these actions—and they are incredibly common—my brain has to interrupt the creative process to ask, “What application is this?” and decide whether or not to include shift in the chord. It seems like a small thing, but it’s a nagging interruption.

1.3. Subtle lines: Rigidity, Uniformity, & Freedom

Apple’s rigidity has technical benefits, too: some years ago, to solve the issue of growing menu complexity, Apple added a search feature. Under the “Help” menu, type text and it lists matching menu items. Point at one, it shows where it is in the menu structure. It’s super handy in complex applications. To support this, applications did nothing, not even a recompile: the feature is provided by the Mac’s unified frameworks, not by app code. The well-defined, stable platform makes it sane for applications to use the provided services, and for developers to not reinvent things. And that means applications—even existing ones—get enhancements for free.

Some open-source folk describe Mac’s uniformity as straitjacket-like. I suppose I can’t do a lot to change the look and feel of my Mac, the way I can load a new skin into Linux. But for usability, I prefer the Mac. Sure, in Linux, I have a choice of Gnome, Kde, Xfce, and various window-manager-agnostic applications; I’m told this offers me a choice I don’t have in Mac. But when it comes down to it, I’m adaptable. I like uniformity, but if it was all this way, or all that way? Eh. Which one works best?

Linux never settles on one set, established way of doing things. Developers go in one direction a while, until some new attitude comes along, and now they develop in that direction. Or maybe the project splits and goes in two directions.

Consequently, there are calendars in Evolution, Gnome-calendar, California (a fork of Gnome-calendar, it looks like, with a new “Agenda” view added), Calendar (a newer version of Gnome-calendar, still lacking California’s Agenda view though), Orage, Korganizer, Xcal, and add-ons for Thunderbird and Claws mail, and a few others. Many of them work alright, but none of them work well, none feel polished. (“Calendar”—a/k/a Gnome Calendar, the modern one from FlatPak—seems best, and shows promise.)

Address books are another issue: I tried several, and every one had something different wrong. Some dropped phone numbers during import. Others dropped e-mail. Some didn’t have CardDAV support, others had it but mangled the cards; one kept duplicating cards and creating more contacts.

Apple provides a framework for the address book. Applications near-universally use that one framework, so Apple’s polishing and improvements over the years benefit all software that uses it. It works well. In the Linux world, nobody can agree on anything, so everybody is re-inventing the wheel. Consequently, there are a half-dozen competing projects, all about 80–90% done, but all with quirks and issues. Almost nothing in open-source land feels polished.

1.4. Not As Bad As It Was

So Linux is still a mess. It’s a hodge-podge because most open-source developer’s goals aren’t to make the best operating system, it’s to build the thing they personally need. I suspect quality and feature standards are often defined by an individual’s needs. User interface behavior is set by developer preferences and current trends, not a long-term strategy.

Still… it’s improving.

Installation was easy, as is adding and removing software.

Terminals finally handle Unicode/UTF-8 correctly. There’s also a Character Map program for looking up characters, and they can be dragged and dropped into applications to “type” them.

The print drivers set up with only a few small snags.

Connecting a second monitor was as easy as plugging it in. It figured out what to do with it, no hassle on my part.

I haven’t once had to go to the command line to configure up an ethernet or wifi adapter.

The window manager is actually good, although there are a few small issues or limitations: you can choose a screensaver, for example, but you can’t configure its behavior completely. But those are really small issue.

The software installer (“Software Manager”) is easy to use and does its job well.

FlatPak is solving some of the Linux software distribution issues by providing a way to guarantee what supporting libraries and their versions are available to programs to use.

1.5. But Still Trouble

There are quirks. Sometimes a software manager window is blank. Go back, do the operation again, it works. I installed Todo, and it was a possible candidate. I thought I’d try a newer version, available via FlatPak. I nearly blew my mind trying to get back to the original: “To Do”, described as a Gnome task manager, is the same latest and (not-so) greatest as the FlatPak version. “gnome-todo” is also the gnome task manager, the earlier one that’s an in-bred cousin of Evolution and actually has working CalDAV support. And in the end, none of them worked to my satisfaction, so I ditched them all and built something of my own. (And in the previously complained-of form: precisely as much as I need, and no more. Only I’m not publishing my code.)

But in most cases, CalDAV and CardDAV support is dodgy and untrustworthy.

Setting up a scanner was a son-of-a-bitch.

Deleted files still show up in recently-used files lists.

After using CornerStone, RapidSVN is… adequate. Thunderbird falls in this category too.

Shotwell is okay, and I’ll grant that Apple’s Photos has become an inefficient, bloated pain in the ass in recent years. Like iTunes before it.

Geeqie is okay as a photo viewer, although it lacks recursive slideshows.

Terminal lacks hotkeys for switching windows (only tabs within a window).

Similarly, the window manager allows hotkeys for switching workspaces (left/right), and although it allegedly supports direct hotkeys, they don’t actually work. It’s picky about which keys, but I got them working.

Although the installer works well, the packaging has long-running problems: one, packages have incomprehensible names. TagLib, for example, is libtag1. Gstreamer is an incomprehensible clusterfuck of versions and component packages. And most of the time, if you need to compile using some package, you’ll need to track down and install the development files too.

Typing common extended characters—such as an em dash, bullet, or copyright symbol—is awkward compared to the Mac: Control-shift-U, U, and the unicode position instead of option-shift-dash, option-8, or option G. You can touch-type the common special characters at full speed on a Mac.

LibreOffice Writer is not Pages '09. But then, Pages '09 has now become iBooks Author, and the formerly excellent all-purpose purpose word processor and page layout program replaced with a new, simpler, less useful version. Pages '09’s impending demise is foretold by notice that 32-bit application support is soon to be on the chopping block.

1.6. The Metaproblem

One of the problems is simply the choice: there’s a dozen or two image viewers out there. Two points on this:

• First, 90% of the many choices are mediocre, burying the jewel in the haystack. I checked out (and rejected) over a half-dozen IDEs before I came across Monodevelop a dozen IDEs before acquiescing on CodeLite. Goofy naming obscures choices, too: I didn’t find Geeqie when I was looking for an image viewer, I stumbled across it later by accident.

• Second, many of the choices are forks of some base project. I definitely saw this with image editors; many were very, very similar. One had an improved slideshow. Another changed the menu layout slightly. Others, I am not even clear what was different. Apparently, we want features and are willing to pony up our time to make them. But instead of contributing them to the main project so it could grow into a full-featured package, we fork off and build our own, collectively creating a forest full of not-quite-done software.

And before you claim that I’m just picking on image viewers, let me share my experience with IDEs:

• Ajunta (Dropped core shortly after firing up debugger)
• Code::Blocks (Pretty but gives error dialog on project creation, crashes and refuses to relaunch)
• Check Eclipse (Java; heavy and slow)
• Gnome Builder (No—no menus, no anything.)
• Geany (Close, but broken; empty dialogs)
• Netbeans (looks like a fork off Eclipse; heavy, feels slow)
• QT Creator (Refused to create project: No applicable kit; reported solutions don’t work)
• Visual Studio Code (Feels promising, but can’t get it to launch application: it wants gnome-terminal or xterm installed, though both are already installed)
• Sublime (Okay for some stuff, but primitive for real debugging.)
• Monodevelop (Also promising, but quirky interaction with GDB and compile errors don’t show up in compile output window.)
• Codelite is the current winner. It’s not obvious how to do a compile, but after some research, it’s doing what it’s supposed to.
• To do: Check Dev++

In this case, I think every one of these is a different code base. Twelve choices. Five crashed within 5 minutes. One was incomprehensible, but maybe if I was willing to try to adapt to a new paradigm. Two didn’t outright crash, but had issues that didn’t have obvious solutions, so I moved on. The two Java ones, I deferred because they’re heavy and slow; I admit I could revisit them, and Eclipse has a reputation (though last time I looked at it, it looked like a Windows 3.1 abomination). Which leaves the one that worked, and the one I didn’t check out because it wasn’t a one-command install from apt-get.

There’s an awful lot of options. And an awful lot of them are broken. Wouldn’t it be better having a few that worked, instead of a whole lot that mostly don’t? But that goes to a problem I observed many years ago: only the best are supposed to survive, but in practice that doesn’t always happen in the open-source world, where choice is biased by being a proponent of a particular technology.

1.7. Do I regret my choice?

With the many good things in the Mac world, and the troubles of Linux, why am I switching?

For many techies, spending a grand on a laptop wouldn’t be a big deal. But for me, that’s a lot of money—stigma of mental illness limits my well-paid opportunities (If I’m only looking for part time work, I don’t fit the positions or I’m treated as not serious; if I disclose why, I’m considered damaged goods). I’m also pretty anti-consumerist, and very careful in selection of items I do purchase. So this transition is a big deal for me.

I feel disheartened that I felt pushed into this choice. Despite my low income, I’d have spent the extra savings to get a Mac if they weren’t designed for disposability. The glued-in batteries, soldered-in or proprietary SSDs are too egregious; I’d have otherwise put up with dongles, external DVDs, high prices and some of the OS slide.

But I do not regret refusing to be taken advantage of. If I’d bought another Mac in these conditions, I’d have felt crappy about it. Even if this transitioned had failed, or eventually does fail, trying will have mattered. But as time goes by, I’m adjusting to a new user interface. I’m finding tools and applications that aren’t as inadequate as the first ones I tried. I’m building new solutions to solve my needs where ones don’t exist. I do miss my Mac, and for a while, there are a few things I’ll do by firing it up again.

Linux will certainly still be a pain in my arse. It’ll be clumsy at times. But it’s on the upward trend, whereas OS X—er, macOS—is falling into decline while Apple envisions its future as a toyish iOS knock-off.

Maybe, just maybe, my world isn’t about to end.

1.8. Aftermath: A Trip to the Apple Store

May 2018

It’s been 4 months since moving back to Linux. I’ve bought books in Inkscape and GIMP since they’ve got incredibly steep learning curves. I’ve been slowly improving my SVN-as-a-cloud solution, which I’ve been using as an opportunity to eradicate old Perl code (I’m replacing it with Python). I’ve submitted fixes and improvements to Goobook, ksh, Cheaty, and Python’s ICS & Calendaring module. Though I’m slowly feeling more at home, I also feel like I’m still slogging my way through setup: I’m still working on transition-related details, rather than getting back to other projects.

My boyfriend needed a dongle to connect his Mac to an external screen, so earlier this week, I used that as an excuse on a warm spring day to cycle out to the Apple store. It was both shocking and dismaying.

When I think of the Apple store, I remember a busy store, full of Macs and other utilitarian, general-purpose computing machines; a warm feeling of a good future. But when I entered the store on Wednesday, it was a shop full of iThings: watches, phones, tablets. Relegated off to two tables in a back corner were some Macs, a seeming afterthought. I knew that Apple was doing away with computers, but it wasn’t until I was standing in that doorway that I understood how far along the process is.

The Mac platform is dead. Apple may still be making a few, but it’s in the way a few horse-drawn carriages are manufactured in these days of automobiles: a tribute to a time past, or a nod to a few stubborn people who won’t move on.

1.9. Moving to Linux, 2 years later (2020)

Two years have passed since that trip to the Apple store. We’re currently in the midst of the Coronavirus mess, and I’m spending my time hacking like I haven’t hacked since I left Apple.

It’s taken those 2 years to familiarize myself with new tools, and to solve the various details of setting up new software. I’ve continued to use CodeLite as my IDE. I’m running version 12; version 13 won’t debug and version 14 wants libc version 2.28, but I’m only at 2.27. So I’m waiting, and making due with an older version.

But that older version is okay. I’ve gotten to know my way around project settings, and I’ve worked out the gdb startup script required to use the debug version of the libstdc++, which puts debugging on par with Xcode. I’ve learned that scan-build is the command-line version of Clang’s static analyzer. The only thing that remains missing is Leaks and debug malloc, two programs excellent for finding memory leaks, use-after free errors, and overruns. efence tries but seems troubled by C++; valgrind… ugh.

But I am moving forward, step by step. Using a Mac feels awkward these days, the UI that I was once so comfortable and familiar with is growing distant.

1.10. Moving to Linux, 4 years later (2022)

It’s been 4 years since purchasing Lenora, and she’s been a champ. I did have to replace the keyboard because one of the shift keys wore out—but the part was available. The new one had a different feel, not because it was different but because years of use had worn off the texture on the keys. The more heavily used the key, the more polished it had become.

Recently, though, our home automation server died. Frank was a 2008ish MacBook I’d picked up second hand, and he’d run like a champ other than the screen backlight being intermittent when the screen tilt was adjusted. Fourteen years isn’t a bad run, and we Freecycled him so hopefully someone else breathes new life into him, or use his remains to restore another machine.

We replaced Frank with a 2012-released, circa 2015-built MacBook Pro. It was the last of the MacBooks with an optical drive, and was kept in the product line until 2016ish. We installed the latest OS it runs, OS X 10.15. And it has utterly vindicated my move away from Apple.

The hardware seems okay; it might be 6 or 7 years old but seems fine.

But the OS is a mess. First problem: iTunes is gone. Okay, ditch that; I don’t use it anyway. Install pianod and get that working. Except it randomly stops working. I switched from Apple’s built-in libraries to ffmpeg and found similar behavior. lldb showed everything was locking up in mutexes and condition variables. Eventually, I figured out the power management stuff was shutting things off even though they were busy playing music.

Next up was X10 for home automation. I found drivers for the USB-to-serial adapter we had and installed them, but it wasn’t quite right. Online I read that OS X had trouble with these older serial devices, so I bought a replacement with the recommended, OS-supported chipset. Which also didn’t work and provided screwy behavior.

We offloaded that service to the RaspberryPi in the basement, where the cable worked fine. With Sun’s old “the network is the computer” slogan in my head, I set up some peer-authenticated secure shell connections to get the machines to coordinate. Great.

Third thing: Integrate it all with the calendar in my homebrew cloud so it works as my alarm clock. I installed the script and it all worked great from the command line. But as a nightly job, the wake-up times weren’t being scheduled. Turns out cron jobs aren’t given filesystem access unless some security options are adjusted.

So the calendar’s updating and I go to bed. Monday morning, Opal wakes me up at 5:30. There’s a job scheduled at 5 AM to run the wake_up script. Why didn’t it run? In the end, I don’t know. I screwed with it for about 2 hours yesterday, adding redirects to try to collect output, and I got nothing. Best I can tell, it just doesn’t run some of the cron jobs. So that’s on the Pi now too.

The SVN server works but some of my repositories have post-commit hooks that need to access the just-committed data. To ensure the server’s performance, those runs as batch jobs. As best I can tell, the jobs get queued up and then MacOS now simply drops them.

The only thing we can get the Mac to do reliably is to play music. It doesn’t understand serial ports, a fundamental piece of UNIX since its inception. It can’t run cron or batch jobs, which are essential for servers. It won’t even let me install an updated Korn shell to fix super-annoying bugs that show up in Apple’s version when certain escape sequences are used in the prompt.

MacOS once straddled the divide between server and end-user machine. It did it well. I loved having all the power of UNIX, and a beautiful and easy to use UI to administrate it all. But in time it evolved into an end-user toy. It is not suitable for real work or development. It has diverged so much from its server-room beginnings that it will no longer reliably run server applications or even standard UNIX system services. It is broken to the point of being unusable for my needs.

2.1. Where Linux Succeeds

To understand why Linux sucks, we need to look at where it wins.

Linux’s technical underpinnings tend to be very advanced. There is a continual evolution of technology and, unlike some of the vendors, it does not hold back in the name of compatibility or ease-of-use.

Apple, for example, is running HFS+, a filesystem going back to the Mac’s pre-UNIX days with enhancements to support symbolic links, UNIX permissions, extended attributes, compressed files/executables, journaling and other cruft for which Apple has added support over the years. On the one hand, it’s impressive it works as reliably as it does (though there were quirks, especially around symbolic links, for several OS iterations in the early OS X days). On the other hand, it’s a bastardization with scary kludges that would be better off replaced with something modern and clean.

Compare that to Linux: ext2 gave way to ext3, which was upgradable to ext4. The new technologies offer improved reliability, efficiency and performance, and Linux takes advantage of it.

Embracing new technology and being willing to lose the old could let Linux be free of the hassles of legacy support.

2.2. Linux Users

Despite Linux being potentially awesome and modern, actual Linux use is by several different groups, all with different needs.

Server Farms

Because Linux can be super-efficient, it’s great for server farms. But the catch here is that a given company doesn’t use crazy varieties of Linux or hardware. Instead, they usually pick a particular model of server and choose a Linux distribution, pair them up and resolve the troubles, then use that as a template for hundreds of thousands of duplicate systems. Sure, there are hassles, but when scaled over enough hardware, the cost savings justifies it.

Embedded Systems

Because Linux is composed from lots of discrete projects, it can be stripped down and tuned to custom needs without a lot of waste. If you’re designing a NAS (network storage device), for example, Linux is a reasonable choice: it’s got support for all sorts of network filesystems, works efficiently, is equipped with excellent filesystems. With some work, Linux can be stripped of everything unneeded. Again, there are hassles, but after the problems are solved once, you have a template that can be duplicated to lots of identical little NAS or other embedded boxes you’re building.

Tinkerers

Tinkerers are looking for parts for their projects. They aren’t worried about reproduction of their work or whether something it easy to set up or use. Resolving the snags that Linux presents is part of the tinkering process, along with building small circuits and writing software to interact with them, or solve whatever problems the tinkerer has invented for him or herself. They will re-use old components they own from earlier projects, meaning older hardware and obscure peripherals.

2.3. Where Linux Loses

Linux lacks overall integration. Using Linux is like driving a car grafted together from all the best components selected from Ferrari, Lamborghini, Porsche, Audio, Mercedes, Volvo, Jaguar, Lexus and Aston Martin. After going through the effort to get it all together, you’d have an engine that would run great but be a beast to work on. It would ride on a bare chassis, or perhaps a boxy body put together as an afterthought.

The problem is one of motivations:

• The projects that build each component are very concerned about the performance, efficiency and reliability. They build something excellent for their needs, but not necessarily easy to use. They build what they want, not what everyone else wants.

• The integrators have to support the different user groups. Server rooms have the latest-and-greatest hardware and lots of compute power. Embedded systems have modern devices, unless using unique hardware; either way there is usually relatively little computing resources. Tinkerers, depending on their project, may use great new hardware, some obscure development kit, or some obsolete piece of junk they had laying around.

• To accommodate the different needs, integrators (the folks managing the distros) have packages divvied up into tiny components. I don’t install ffmpeg, nor do I install each of the half-dozen libraries for ffmpeg: I install each library’s development, documentation, library, debug support and utilities.

The problem then compounds itself. Linux is a hodge podge of projects, and there are hundreds of different flavors (distributions) of Linux built with different projects. Some distributions embrace a change, while others remain skeptical and retain the older version. Yet others may go a different direction, swapping out a package with an alternate solution. Source-code compatibility is a goal, not binary compatibility.

The result is huge messes such as system startup. There were system V startup scripts (/etc/init.d) which were then formalized as the LSB (Linux Standard Base). Then, init was replaced with systemd(1) and other attempts to improve on the old-style init. But rather than replace LSB wholesale, compatibility layers were put in place to allow old-school startup to still work.

The result is a confusing, poorly and contradictorily documented disaster. To be fair, Apple made a similar transition from init to launchd in 10.4. But by 10.6 (maybe even 10.5), support for the old was only there for add-on compatibility; the OS itself had been fully adapted to the new solution. (To be fair, the state of startup in Linux is improving in some distributions as they move beyond the transition.)

I’m finally ready to enumerate the problems with Linux:

1. Because everything comes piecemeal, there are perpetual snags getting it to all work together.

2. Because each project is solving its own problems, there’s no overall coherence to management. Sometimes there’s a GUI configurator. Other times there’s a command-line setup tool. But most often, you’re down to entering obscure command-line usage or editing mysterious configuration files with your text favorite editors.

3. Trying to get anything to work is an exercise in man pages, Google searches and cookbooking on the command line.

4. In the Mac and Windows world, paid software is available, profit drives availability of multiple choices of reliable, complete, easy-to-install, easy-to-use office packages, checkbook programs, calendars, mail programs, and photo managers. For-profit software essentially doesn’t exist for Linux because the hardware architecture, installed libraries and OS services aren’t consistent. While there are open-source versions of common software, they come with installation hassles, quirks and/or bugs, awkward user interfaces, and are often incomplete.

Perhaps some tools could be built to ease more setup, but since configuration files are often free-form text files, that becomes a difficult task. I’m certainly guilty of that one with pianod’s startscript, which is where one specifies audio output devices, crossfade parameters, inputs/sources, and specifies starting state. It’s easy to code it, easier to read and manipulate than XML, and very flexible—but it’s not easy to write a management tool for it because statement order matters, it’s unclear how to preserve comments, and how does the tool deal with unknown content? (With XML, unexpected items are easy: just put them back the way you found them.)

2.4. Back to my Mac

As much as I dislike the walls going up at the same time there’s a general dumbing down within Apple’s ecosystem, a month of dealing with Linux has reminded me why I left in the first place: I want to use my computer, not administrate it.

At least 95% of Mac administration is easy GUI controls. There is minimal futzing. Most applications install by downloading and dropping them in the Applications folder, and uninstall by dragging to the trash. Everything looks pretty (Well, that’s because I’m still running Mavericks and not ClownOS—I mean, El Capitan) and, a few third-party apps aside, everything behaves consistently.

I wish Linux had the ease-of-use of my Mac, because if Apple’s attempts to lock me in had me nervous, increasingly quirky apps (especially ones that used to work perfectly fine), bugs in Korn Shell’s sleep command, and a CERN-quality security issue where the app sandbox breaks PAM authentication wide-open have trashed my confidence in Apple (even if ksh has since been fixed and the PAM issue was patched on Sierra). Microsoft’s addition of a Linux Compatibility Layer has me seriously contemplating a move to Windows.

I can see Linux is brilliant for special uses, especially server-type tasks. But for day-to-day, desktop-style needs, Linux still doesn’t meet needs.