My Linux journey began in the late 1990s when I was in college. I was taking a course on operating systems which covered Windows NT and Solaris. At the time I had around a decade of experience with DOS and several years of using Windows under my belt, so the Windows portion of the course was easy enough for me. However, I was new to UNIX-like operating systems and the variety of command shells, the unfamiliar syntax and the many scripting languages we covered were overwhelming at first. I felt, at the time, that the biggest hurdle to me learning Solaris was that I wasn’t using it in practical day-to-day scenarios. At the time I was using Windows for most tasks. When I wrote a report, checked my e-mail or browsed the Web it was on a Windows machine. When I edited my resume it was on Windows. In short, Windows was familiar and using it had become second nature. Solaris was new to me and I was only using it hands-on for an hour or two a day to perform pre-selected tasks. I believed that if I could run Solaris at home, on a daily basis, then it would become familiar, that I would gain skills in Solaris by performing practical tasks.
I asked around if anyone knew where I could find a copy of Solaris on a student’s budget (ie free) and it was suggested I try a similar operating system called Linux. I looked around, discovered a few different flavours and finally settled on a lightweight derivative of Slackware called Pygmy. Pygmy had two positive aspects to it. The distribution fit nicely on five floppy disks (making it a blissfully small download on my dial-up connection) and it could be installed on a Windows partition, saving new users from re-partitioning their hard drive. My experiment with Linux proved successful. In the comfort of my home I started playing with shell scripts, working out how to automate simple tasks, browsing the file system and reading manual pages. My comfort with UNIX-like operating systems quickly grew and I found myself spending more and more time in Linux and, gradually, less in Windows.
Over the next few years I experimented with a few other Linux distributions and found myself slowly migrating my work flow away from Windows toward Linux. I liked that when I told Linux to delete a file it never claimed the file was locked. I liked that the configuration files were in plain text, making them easy to read and understand. I liked that most distributions shipped with a free compiler and manual pages for just about every command. I continued to keep Windows around as I still required it for some tasks and not all my hardware worked smoothly with Linux at first. Gradually though I found Linux distributions began to support my hardware better and more significant applications, such as OpenOffice, arrived on Linux. About four years after being introduced to UNIX-like operating systems, I realized I was using Linux exclusively and decided to wipe my Windows partition.
I share this introduction to Linux because it illustrates why I started using the open source operating system. It was not philosophy or choice or openness that first attracted me to Linux. At first Linux was a practical tool to help me complete a college course. However, over time, I came to appreciate the choice, the openness and the flexibility Linux distributions provided. Linux gave me the ability to tinker, to improve the software I used daily and it put me, the user, in the driver’s seat.
I am sorry to say that about ten years after I installed my first Linux distribution I started to notice trends I found unsettling. Sometime around 2008 I began to notice a number of significant changes which seemed to hit the Linux community one after another. These changes had a tendency to make it harder to work with Linux, rather than easier — at least in the short term. Distributions dropping KDE 3 in favour of the, not-yet-ready KDE 4 was an obvious example. PulseAudio being included in distributions before it was working properly was another. The GNU project pushing out the overly complex General Public License (version 3) and the uncertainty surrounding some of the characteristics of the new license caused confusion. A few years after the botched shift to KDE 4, GNOME users got to experience a similar sudden shift as distributions threw away the traditional GNOME 2 desktop in favour of GNOME Shell. Around the same time, the Ubuntu distribution discontinued GNOME 2 on the desktop in favour of Unity.
Now I want to make it clear that I do not think the technologies I listed above are bad. Far from it. I am happy with the modern implementation of KDE 4, I find PulseAudio quite helpful these days. Unity may have been a big change (and buggy at first), but I am using Ubuntu’s Unity desktop as I type this article. My complaint is not against these technologies, I like that they exist. My complaint is with Linux distributions which are too quick to adopt technologies which either are not ready or are disruptive without making it easy to revert to software that is known to work. For example, anyone who used KDE 4.0 for more than five minutes had to know it was not intended for the general public. Yet distributions moved, en mass, to adopt KDE 4 and most of them did not continue to support KDE 3 at the same time. Most distributions which flocked to PulseAudio did so long before PulseAudio was ready and they did not make it straight forward for non-technical users to revert to using ALSA.
My point is that, in the long term, KDE 4 and PulseAudio and GNOME Shell and Unity may be good changes, but in the short term they are very disruptive and most Linux distributions dive straight into these new technologies without thought or concern for how users will react. A proper migration path should involve offering the new technology as an option while the old technology is the default. Then switching their places, offering both with the new technology as the default. After that the old technology should either be phased out or remain as an alternative. In other words, a proper migration path is evolutionary, giving users a chance to adjust over multiple releases. This approach also gives developers plenty of time to process bug reports as they come in from more experimental users. But this is rarely how Linux distributions migrate from one technology to another. Their approach is typically revolutionary, tearing out old technology from the distribution and replacing it with new software that is often not ready, nor stable.
More recent examples of this revolutionary approach to software packaging have included Red Hat adopting a new, awkward version of the Anaconda installer. Most Linux distributions are now adopting systemd for their init process and Unity 2-D was dropped from Ubuntu before Unity 3-D was working smoothly. For some reason Linux distributions tend to be revolutionary rather than evolutionary.
I don’t know if I would have noticed just how disruptive it can be, migrating from one version of a Linux distribution to the next, if it weren’t for my experiments with other UNIX-like operating systems. Back in 2009 I returned to my roots and played with OpenSolaris for a few weeks. A short time after that I played with FreeBSD for the first time in years and that lead to experiments with PC-BSD. Over the next few years I continued to play with various flavours of BSD and found it interesting to see how different the BSD approach to developing and packaging software is. In contrast to Linux distributions, the BSD operating systems tend to evolve slowly. There is change, there is improvement, there are new technologies introduced, but these changes happen more slowly. Take, for example, pkg (FreeBSD’s “next generation” package manager). The pkg utility was available as a technology preview for around a year before it was introduced as the default package manager. Even then, FreeBSD users could fall back to using the previous package manager. The two package managers co-existed for around two years in total before the old package manager was depreciated. While pkg is FreeBSD’s exclusive binary package manager these days, traditionalists can still use FreeBSD’s ports collection to configure and install software from source code.
Another example of the BSDs taking an evolutionary approach is audio support. Over the past decade or so we have seen Linux move from the OSS sound system to ALSA and then PulseAudio as a sort of additional layer. Meanwhile FreeBSD has stuck with OSS. The OSS software now has similar features and capabilities as PulseAudio, but FreeBSD users got these features through small steps rather than disruptive leaps that left behind a complex legacy. Likewise, when FreeBSD decided to adopt the Clang compiler in place of the GNU compiler, it happened slowly over multiple versions of the operating system. Today Clang may be the default compiler on FreeBSD, but the GNU compiler is still available as an alternative and the GNU compiler is kept up to date.
My point is that when I run FreeBSD (or one of its derivatives) I can be certain the operating system will work mostly the same in this release as the next release. The skills I learn today, the habits I pick up, are still relevant tomorrow. FreeBSD may bring in improvements and new technology, but I can be fairly sure that it will be a gradual process and, once the new technology is in place, I will be able to revert back to the old way of doing things. With Linux distributions I feel I am taking part in a chaotic technological cycle of creation, destruction and re-creation where today’s skills and habits may not be useful tomorrow. Even more conservative distributions, such as Red Hat Enterprise Linux, are not immune from this cycle. With RHEL we might be able to hold on to the older technology longer, but it comes with the price of using older applications. With FreeBSD we can stay up to date with desktop application while sticking to a tried and true core operating system. I have found I like FreeBSD’s slow, steady pace, its gradual progression that maintains both choice and familiarity.
Obviously I’ve been enjoying my time with FreeBSD, so why am I not running that operating system full time? Why am I writing this post complaining about Linux distributions and their packaging habits from the comfort of Ubuntu? When I first began my journey into Linux from Windows my path was blocked by missing applications and gaps in hardware support. I find the same is true of my experiments with the BSDs. I love the design and approach of BSD operating systems, but often run into hardware compatibility issues. Plus, not all of my Linux applications work on FreeBSD yet. But the gap is getting narrower each year. Some of my servers are now running TrueOS (a FreeBSD derivative) where they previously ran a Linux distribution. Over the next year most, if not all, my servers will probably make the transition from Linux to either FreeBSD or OpenBSD. I crave consistency on servers even more than on my desktops and the BSDs offer that. On the desktop side of things I have been experimenting and making sure most of my favourite applications have working FreeBSD ports. Likewise, software offered on BSD (like Lumina and ZFS) I currently run on Linux so transitioning back and forth between operating systems is now nearly seamless.
It strikes me as both appropriate and a little sad that the characteristics of Windows which encouraged me to switch to Linux are the same things that drive me now to move away from Linux. I left Windows to get away from interfaces that changed with every release. I moved to Linux as I felt it empowered me to use my computer as I saw fit, to shape it to my preferences rather than having my operating system dictate to me. I happily left behind restrictive licenses to embrace the GPL. Now I look toward the BSDs from Linux, urged on by changing interfaces, a sense the operating system expects me to adapt to it, restrictive licenses and binary software where there were once plain text scripts. Perhaps I have changed, perhaps the Linux community has, but in either case I feel BSD may be better suited to by current situation.
My Linux Journey
My Linux journey began in the late 1990s when I was in college. I was taking a course on operating systems which covered Windows NT and Solaris. At the time I had around a decade of experience with DOS and several years of using Windows under my belt, so the Windows portion of the course was easy enough for me. However, I was new to UNIX-like operating systems and the variety of command shells, the unfamiliar syntax and the many scripting languages we covered were overwhelming at first. I felt, at the time, that the biggest hurdle to me learning Solaris was that I wasn’t using it in practical day-to-day scenarios. At the time I was using Windows for most tasks. When I wrote a report, checked my e-mail or browsed the Web it was on a Windows machine. When I edited my resume it was on Windows. In short, Windows was familiar and using it had become second nature. Solaris was new to me and I was only using it hands-on for an hour or two a day to perform pre-selected tasks. I believed that if I could run Solaris at home, on a daily basis, then it would become familiar, that I would gain skills in Solaris by performing practical tasks.
I asked around if anyone knew where I could find a copy of Solaris on a student’s budget (ie free) and it was suggested I try a similar operating system called Linux. I looked around, discovered a few different flavours and finally settled on a lightweight derivative of Slackware called Pygmy. Pygmy had two positive aspects to it. The distribution fit nicely on five floppy disks (making it a blissfully small download on my dial-up connection) and it could be installed on a Windows partition, saving new users from re-partitioning their hard drive. My experiment with Linux proved successful. In the comfort of my home I started playing with shell scripts, working out how to automate simple tasks, browsing the file system and reading manual pages. My comfort with UNIX-like operating systems quickly grew and I found myself spending more and more time in Linux and, gradually, less in Windows.
Over the next few years I experimented with a few other Linux distributions and found myself slowly migrating my work flow away from Windows toward Linux. I liked that when I told Linux to delete a file it never claimed the file was locked. I liked that the configuration files were in plain text, making them easy to read and understand. I liked that most distributions shipped with a free compiler and manual pages for just about every command. I continued to keep Windows around as I still required it for some tasks and not all my hardware worked smoothly with Linux at first. Gradually though I found Linux distributions began to support my hardware better and more significant applications, such as OpenOffice, arrived on Linux. About four years after being introduced to UNIX-like operating systems, I realized I was using Linux exclusively and decided to wipe my Windows partition.
I share this introduction to Linux because it illustrates why I started using the open source operating system. It was not philosophy or choice or openness that first attracted me to Linux. At first Linux was a practical tool to help me complete a college course. However, over time, I came to appreciate the choice, the openness and the flexibility Linux distributions provided. Linux gave me the ability to tinker, to improve the software I used daily and it put me, the user, in the driver’s seat.
I am sorry to say that about ten years after I installed my first Linux distribution I started to notice trends I found unsettling. Sometime around 2008 I began to notice a number of significant changes which seemed to hit the Linux community one after another. These changes had a tendency to make it harder to work with Linux, rather than easier — at least in the short term. Distributions dropping KDE 3 in favour of the, not-yet-ready KDE 4 was an obvious example. PulseAudio being included in distributions before it was working properly was another. The GNU project pushing out the overly complex General Public License (version 3) and the uncertainty surrounding some of the characteristics of the new license caused confusion. A few years after the botched shift to KDE 4, GNOME users got to experience a similar sudden shift as distributions threw away the traditional GNOME 2 desktop in favour of GNOME Shell. Around the same time, the Ubuntu distribution discontinued GNOME 2 on the desktop in favour of Unity.
Now I want to make it clear that I do not think the technologies I listed above are bad. Far from it. I am happy with the modern implementation of KDE 4, I find PulseAudio quite helpful these days. Unity may have been a big change (and buggy at first), but I am using Ubuntu’s Unity desktop as I type this article. My complaint is not against these technologies, I like that they exist. My complaint is with Linux distributions which are too quick to adopt technologies which either are not ready or are disruptive without making it easy to revert to software that is known to work. For example, anyone who used KDE 4.0 for more than five minutes had to know it was not intended for the general public. Yet distributions moved, en mass, to adopt KDE 4 and most of them did not continue to support KDE 3 at the same time. Most distributions which flocked to PulseAudio did so long before PulseAudio was ready and they did not make it straight forward for non-technical users to revert to using ALSA.
My point is that, in the long term, KDE 4 and PulseAudio and GNOME Shell and Unity may be good changes, but in the short term they are very disruptive and most Linux distributions dive straight into these new technologies without thought or concern for how users will react. A proper migration path should involve offering the new technology as an option while the old technology is the default. Then switching their places, offering both with the new technology as the default. After that the old technology should either be phased out or remain as an alternative. In other words, a proper migration path is evolutionary, giving users a chance to adjust over multiple releases. This approach also gives developers plenty of time to process bug reports as they come in from more experimental users. But this is rarely how Linux distributions migrate from one technology to another. Their approach is typically revolutionary, tearing out old technology from the distribution and replacing it with new software that is often not ready, nor stable.
More recent examples of this revolutionary approach to software packaging have included Red Hat adopting a new, awkward version of the Anaconda installer. Most Linux distributions are now adopting systemd for their init process and Unity 2-D was dropped from Ubuntu before Unity 3-D was working smoothly. For some reason Linux distributions tend to be revolutionary rather than evolutionary.
I don’t know if I would have noticed just how disruptive it can be, migrating from one version of a Linux distribution to the next, if it weren’t for my experiments with other UNIX-like operating systems. Back in 2009 I returned to my roots and played with OpenSolaris for a few weeks. A short time after that I played with FreeBSD for the first time in years and that lead to experiments with PC-BSD. Over the next few years I continued to play with various flavours of BSD and found it interesting to see how different the BSD approach to developing and packaging software is. In contrast to Linux distributions, the BSD operating systems tend to evolve slowly. There is change, there is improvement, there are new technologies introduced, but these changes happen more slowly. Take, for example, pkg (FreeBSD’s “next generation” package manager). The pkg utility was available as a technology preview for around a year before it was introduced as the default package manager. Even then, FreeBSD users could fall back to using the previous package manager. The two package managers co-existed for around two years in total before the old package manager was depreciated. While pkg is FreeBSD’s exclusive binary package manager these days, traditionalists can still use FreeBSD’s ports collection to configure and install software from source code.
Another example of the BSDs taking an evolutionary approach is audio support. Over the past decade or so we have seen Linux move from the OSS sound system to ALSA and then PulseAudio as a sort of additional layer. Meanwhile FreeBSD has stuck with OSS. The OSS software now has similar features and capabilities as PulseAudio, but FreeBSD users got these features through small steps rather than disruptive leaps that left behind a complex legacy. Likewise, when FreeBSD decided to adopt the Clang compiler in place of the GNU compiler, it happened slowly over multiple versions of the operating system. Today Clang may be the default compiler on FreeBSD, but the GNU compiler is still available as an alternative and the GNU compiler is kept up to date.
My point is that when I run FreeBSD (or one of its derivatives) I can be certain the operating system will work mostly the same in this release as the next release. The skills I learn today, the habits I pick up, are still relevant tomorrow. FreeBSD may bring in improvements and new technology, but I can be fairly sure that it will be a gradual process and, once the new technology is in place, I will be able to revert back to the old way of doing things. With Linux distributions I feel I am taking part in a chaotic technological cycle of creation, destruction and re-creation where today’s skills and habits may not be useful tomorrow. Even more conservative distributions, such as Red Hat Enterprise Linux, are not immune from this cycle. With RHEL we might be able to hold on to the older technology longer, but it comes with the price of using older applications. With FreeBSD we can stay up to date with desktop application while sticking to a tried and true core operating system. I have found I like FreeBSD’s slow, steady pace, its gradual progression that maintains both choice and familiarity.
Obviously I’ve been enjoying my time with FreeBSD, so why am I not running that operating system full time? Why am I writing this post complaining about Linux distributions and their packaging habits from the comfort of Ubuntu? When I first began my journey into Linux from Windows my path was blocked by missing applications and gaps in hardware support. I find the same is true of my experiments with the BSDs. I love the design and approach of BSD operating systems, but often run into hardware compatibility issues. Plus, not all of my Linux applications work on FreeBSD yet. But the gap is getting narrower each year. Some of my servers are now running TrueOS (a FreeBSD derivative) where they previously ran a Linux distribution. Over the next year most, if not all, my servers will probably make the transition from Linux to either FreeBSD or OpenBSD. I crave consistency on servers even more than on my desktops and the BSDs offer that. On the desktop side of things I have been experimenting and making sure most of my favourite applications have working FreeBSD ports. Likewise, software offered on BSD (like Lumina and ZFS) I currently run on Linux so transitioning back and forth between operating systems is now nearly seamless.
It strikes me as both appropriate and a little sad that the characteristics of Windows which encouraged me to switch to Linux are the same things that drive me now to move away from Linux. I left Windows to get away from interfaces that changed with every release. I moved to Linux as I felt it empowered me to use my computer as I saw fit, to shape it to my preferences rather than having my operating system dictate to me. I happily left behind restrictive licenses to embrace the GPL. Now I look toward the BSDs from Linux, urged on by changing interfaces, a sense the operating system expects me to adapt to it, restrictive licenses and binary software where there were once plain text scripts. Perhaps I have changed, perhaps the Linux community has, but in either case I feel BSD may be better suited to by current situation.
Related Posts
An Outsider’s Perspective on Windows 10 Preview
Distributed Torrents
Firefox shoots itself in the foot to annoy you into being more secure
About The Author
jesse