Debian for Ubuntu people

It’s no secret that many people’s first Linux experience these days is on Ubuntu; yet as they — for one reason or another — find themselves needing to branch out into the wider Free OS world, Debian is often the next stop along the road.  Having introduced a few Ubuntu users (in real life or online) to Debian, I’ve noticed a few common stumbling blocks, and thought it might be nice to offer a little guide for those making the transition (or expansion) to Ubuntu’s parent distro.

It’s also no secret that there tends to be a bit of friction between the Debian and Ubuntu communities, both users and developers, for a variety of reasons.  For the record, I appreciate and use both distributions quite a bit, so I hope that this article will help users from both camps have a healthy appreciation for the other.

Philosophical differences

In order to have a proper context to appreciate the differences between the two projects, you have to start with their philosophies.  Those of a strictly pragmatic mind may think that project philosophy is merely auxiliary fluff that has no bearing on the quality or usefulness of the end product, but I feel that any project should be “measured by its own yardstick”; in other words, we should judge the failure or success of each project according to the goals it set for itself — its fitness for our purposes is another matter entirely.

Ubuntu’s philosophy

Ubuntu bills itself as “Linux for Human Beings”.  Its primary goal is an operating system that “average people” can easily install, maintain, and use for “average people things”  like web browsing, document editing, and multimedia consumption.  As such, the project only supports platforms used in consumer devices (like x86, amd64, and newer, mobile-related ARM platforms), focuses heavily on polishing a single desktop environment, features a graphical LiveCD installer, and prioritizes new software.  While it’s partially community-developed, it’s primarily driven by Canonical Ltd., a private, for-profit company.

Debian’s philosophy

Debian, on the other hand, bills itself as “The Universal Operating System”.  Its goals are (1) to be a good operating system for as many purposes as possible on as many platforms as possible and (2) to be completely free in every sense of the word.  Its currently supported ports cover a whopping 9 hardware platforms and 2 kernels (Debian isn’t just Linux anymore; there’s a version based on FreeBSD, and soon a version based on HURD), and its software repositories are easily the largest “officially maintained” repositories of any distribution (Ubuntu inherits these, of course; I’m comparing to non-Debian based distributions).

Debian is also the largest purely community-driven free software project in existence; it has no corporate affiliations or ownership, is governed by a democratically-elected council, and developed by a worldwide community of independent developers.  It has a strong commitment to, and history of support for, software freedom (the Debian free software guidelines were the template used for the OSI’s open source definition, for example), which is pivotal to its community dynamic.

It should be no surprise, then, that Debian has a strong showing in the server space, in research, in embedded projects (for example, the Raspberry Pi), and as a base for derivative distributions.  In fact, the incredible proliferation of Debian respins and derivatives makes two points about Debian quite clear: (1) it’s a great base for creating your own distribution, for technical, legal, and pragmatic reasons; and (2) it obviously leaves a great deal of room for improvement in many use cases, most notably as a desktop OS.

This last point is particularly relevant when comparing Debian and Ubuntu, because it more or less summarizes where each project’s strengths and weaknesses lie.  Ubuntu has arguably made a Debian derivative that provides a friendlier desktop experience for the “average user”; but it has done so at the expense of universality and fitness for a variety of applications and preferences, not to mention the occasional loss of goodwill from a community whose goals must be subservient to the goals of Canonical.  Debian is equally fit for just about any task you want to put it to, on any hardware you want to put it on; but in being so, it cannot afford to make special concessions for desktop-friendliness that might make it unsuitable for other uses (e.g., having a default installer or package manager that requires X11, requiring non-free software, etc).

Practical Differences

Keeping these philosophical differences in mind, let’s start looking at some of the practical differences an end user will encounter when first exploring Debian.  It’s worth noting, for the record, that many of these things are available or configurable in either distribution (Debian installer, for example, is available to Ubuntu users on the “Alternate Install” or Server discs), but we’re focusing on what is likely to be different in the most common, default usage situations.

The installer

While Ubuntu installer, Ubiquity,  is a short and simple wizard that runs from a LiveCD desktop, Debian installer is a more old-fashioned boot-straight-to-the-installer affair.  In many ways it’s less automated, and provides facilities to do advanced procedures during the install.  It has both a text-based (ncurses) version and a graphical (gtk) version, but the graphical version is little more than window dressing for the former, and the experience is quite similar either way.

You need a little more know-how to get through the Debian installation.  I admit to having been thwarted in my first attempt to install Debian (way back in 2004) by the relative complexity of the installer, and by my inability to answer some questions related to X11 configuration.  It’s much simpler nowadays, but compared to Ubiquity it’s still no walk in the park.  However, Debian installer runs on some pretty antique hardware and offers some powerful advanced options for dealing with oddball configurations.

Instead of giving you a default desktop setup with a selection of pre-installed applications, the Debian installer gives you a checklist at the end with a dozen or so generic “tasks” you can install.  The categories are pretty broad and mostly server-oriented, though “Desktop Environment” is one of the options (it installs GNOME, if you were wondering).  Most users end up skipping this and just installing the software they want manually.  This, of course, requires some knowledge about what you want to install, which is pretty hard to know as a beginner.  On the other hand, it means the same Debian install media can be used to set up whatever kind of environment you want; there’s no need for a separate “Server” version, or separate versions for different desktop environments (though, to be fair, such CDs exist — you just don’t strictly need them if you have an Internet connection to download packages).

 Root user

The next glaring difference most people get hung up on is the use of the root user account rather than sudo.  Ubuntu disables the root user by default and configures sudo privileges for the first user installed, and any subsequent users added to the “admin” group.  This more closely mimics what users experience on Windows and OSX, where administrative privileges are granted to select user accounts, rather than tied up in a single root account.

Debian takes the old-school Unix approach of having one all-powerful root user, and every other account being limited.  Administrative actions are accomplished either by logging in as root, or by the use of “su” (or graphical equivalents) to temporarily become root.

It’s trivial enough to switch either distro to the other’s behavior, and I myself have a preference for sudo on my Debian systems.  But this is the default, and in Debian circles (for instance, on forums or in documentation), it’s  assumed that you are operating with this configuration.  Graphical tools also default to the “su” version instead of “sudo” (e.g., “gksu” is invoked instead of “gksudo” when starting administrative GUIs).

So why, you might ask, doesn’t Debian install sudo by default?  I can’t say authoritatively, but my guess is:

  • The su/root method is more traditional and expected by pretty much anyone other than an Ubuntu user
  • su/root still exists on a system whether sudo is configured or not, and it doesn’t make security sense to have multiple privilege elevation systems installed by default
  • sudo is basically a more abstracted, high-level approach to security, which isn’t necessary in many use cases.  If the aim is universality, it doesn’t make sense to add in this extra layer.

Package management and repositories

Both Ubuntu and Debian use the Debian package management system, dpkg/APT.  In Ubuntu, the default front-ends for this system are the Ubuntu software center (on the desktop) and apt-get (on the command-line).  In Debian, the recommended front end is aptitude (CLI/ncurses), though Synaptic is provided on the desktop.

To be honest, I’ve never been clear why the Ubuntu community focuses on apt-get rather than the far more feature-filled aptitude, but it’s clear why Debian recommends aptitude: it provides the most robust package management functionality without actually requiring X11.  In practice, you can (usually) use any front-end you want on either system (with the exception of USC on Debian, and aptitude sometimes breaks in certain Ubuntu configurations), though due to subtle differences in dependency management and conflict resolution, you’ll probably get better results using the recommended tools on each platform.

The bigger difference with regard to package management on the systems is the breakdown of the repositories.  For a given Ubuntu release, the repositories are:

  • Main: free-as-in-freedom software supported by Canonical
  • Universe: free-as-in-freedom software supported by the Ubuntu community
  • Restricted: non-free drivers
  • Multiverse: non-free software
  • Partner: (non-free?) software from Canonical’s corporate partners

With Debian, the segments are a little simpler:

  • Main: all free-as-in-freedom software
  • Non-free: all non-free software, drivers, etc.
  • Contrib: Free software that depends on non-free software.

There’s no equivalent to “Universe” or “Partner” here because there’s no corporate sponsor to have partners or support packages; it’s all community supported.

Ubuntu also has different subsections of each section for updates, security updates, backports, and proposed updates.  Debian’s stable release (more on that below) has a backports section (for newer software releases backported to stable), a security subsection (for security patches), and an updates (formerly “volatile”) subsection for programs that require regular updating (anti-malware packages, e.g.).   There are also a number of popular 3rd party repositories, since Debian lacks any equivalent to Ubuntu’s PPA system.

Release schedule

Ubuntu, like clockwork, releases a new version every six months.  Every two years, they designate the release “LTS” (long term support), meaning it will be supported for 3 or 5 years.   Regular releases are supported for 18 months, and the next release is always available for beta testers.  Releases are codenamed with alliterative animal names and versioned  with the year and month of release.

Debian does not release on a fixed schedule.  Instead, they have a four-tier system for the releases:

  • Packages start in Unstable.  Sometimes they are directly put into Unstable, sometimes they start in Experimental first.
  • When it’s determined that a package in Unstable causes no significant breakage, it graduates to Testing (unless testing is in freeze mode).
  • Approximately every two years, Testing is “frozen”, meaning it cannot receive any major package updates.  Once it’s frozen, developers work to address all outstanding bugs.  When the worst bugs are all eliminated (a process that usually takes three to twelve months), the frozen Testing release is graduated to Stable.
  • Once the new release is in Stable, it receives only security updates and minimal bug fixes.  When the next version of Stable is released, the current Stable is retired to Old Stable, which is supported for 1 year after the release of its successor.

Debian releases are codenamed for characters from the movie Toy Story, with Unstable perpetually bearing the name Sid (Sid breaks toys :)).  As you can imagine, the Debian release cycle is quite long, sometimes going two-and-a-half to three years between releases.  Many Debian users opt for using Testing on their desktops, with Stable being reserved for servers and mission-critical systems.  Obviously, the software versions in Stable are far behind those in the current Ubuntu, but they’ve also been through more rigorous testing and bug-fixing.

Upgrading between releases is different as well; in Ubuntu, you usually run a special release-upgrade tool that alters or disables your software sources, runs the upgrade, removes a bunch of stuff, cleans up a bit, and the prompts you to reboot.

With Debian, things go one of two ways, depending on how you configure your sources:

  • If you set up your sources to point to generic releases like “stable” or “testing”, you’re automatically upgraded the first time you do a full upgrade after the official release.  In other words, pointing to “stable” means you’ll always stay with stable, and when a new stable is release, you go to it.
  • On the other hand, if you set up your sources to point to a particular release codename (like “squeeze” or “wheezy”), you’ll stay with that release until you manually change the sources file to point to a newer release.  For example, a system pointed to “squeeze” will not upgrade to wheezy when it goes stable, but only after the user changes the sources to point to “wheezy” and upgrades.
In either case, upgrading Debian is just a matter of pointing the sources to the release you want, running a full-upgrade, and rebooting.

Proprietary Drivers

Ubuntu has a snazzy little tool called Jockey that allows you to install those pesky proprietary drivers for your graphics cards and wi-fi chips; assuming you can get a working screen and network connection without them, it’s pretty handy and easy for people to get the proprietary stuff they need.

Debian doesn’t (yet) have jockey, so you have to do the drivers the hard way.   Well, it’s not really that hard, but it’s not as easy as Jockey.  You’ll need to enable the non-free repositories, install the appropriate packages, possibly tweak your xorg.conf or /etc/modprobe.d files, and reboot.  If that sounds intimidating, I’m going to bet that step-by-step instructions are probably a Google search away, so don’t panic.

In addition to the well-known proprietary drivers, though, Debian has also cleared the default kernel of “binary blobs” — proprietary firmware files that are embedded in the kernel in many other distributions (including Ubuntu).  These firmware files are required for some popular networking and other hardware, but in Debian they need to be installed separately.  Enabling the non-free repositories and installing the firmware-linux package should restore these should you need it.

The bottom line is that making hardware with proprietary drivers work in Debian is just as possible as it is in Ubuntu, but not always as easy.

Who would want to use it?

Maybe you’re looking down this list of differences, and saying to yourself, “This sounds awful, why would I want to use Debian over Ubuntu?”  That’s a fair question, and maybe the answer is simply, “You wouldn’t.” Keep in mind, though, that so far I’ve focused on the negative things that Ubuntu users encounter when trying Debian.  Let’s quickly look at a few reasons why you might want to branch out to Ubuntu’s mother distro.

Stability is your priority

It seems like nearly every new release of Ubuntu finds a certain number of people complaining that the development cycle is too short and not enough bugs are squashed to make them happy.  If you’re one of those people, I’d suggest it’s time to try Debian.

As you can see from the release policies, Debian is more concerned with delivering stable, bug-free software than meeting a schedule.  This is a double-edged sword, of course; but if you are unconcerned with having the latest versions of things, don’t want to do a major upgrade every six months, and just want your software to be as reliable as possible, Debian is a great solution.  True, Ubuntu offers an LTS release which is supported for 3-5 years, but it gets no more pre-release vetting than any other release of Ubuntu.  Debian stable is thoroughly tested  and only released when quality goals are met.

Even if stability doesn’t trump cutting edge on your computer (certainly doesn’t on mine, I’ll admit!), if you’re a professional tech or just the resident “computer guy” among your friends and family you may find yourself working on a system where it does — such as a friend or relative’s computer (who isn’t computer-savvy), in a work environment, etc.  Having Debian in your toolbox is a good idea if you’re going to be setting up Linux systems for other people.

You are interested in something other than the desktop

Ubuntu is a great desktop OS, but suppose you want to play with embedded systems, clustering, or alternative platforms.  Debian’s focus on universality makes it a perfect fit for creative, oddball uses, and it’s quite common to see it employed in such applications for this reason.

On the server end, it’s a bit of a toss-up between Ubuntu Server (LTS releases, of course) and Debian Stable.  I use both at my job; Ubuntu’s longer support cycle (5 years for LTS servers) is nice, and there are a few areas where its fresher package selection is a plus (virtualization, e.g.); but for standard services like web or infrastructure servers, Debian’s more conservative architecture and release-when-ready development model wins me over.

You aren’t keen on Canonical’s influence

Canonical has never made any pretense of being anything other than a for-profit company, and it’s clear that — whatever the reason may be — creating and distributing Ubuntu is part of their plan to generate revenue and become a healthy, profitable company.  Personally, I don’t have a problem with that.

Over the last few years, though, a lot of users (or at least a vocal minority of them) seem to be uncomfortable with the increasing presence of Canonical’s corporate goals in the design and direction of Ubuntu.  Whether it’s the move towards a more mobile-esque interface, the increasing presence of commercial software, the occasional indulgence in top-down decision making, or just a distaste for the omnipresence of company branding, there are some who just long for a less commercialized experience.

Debian has always been, and will always be, community-driven.  No company, corporation, or individual is in a position to dictate direction and design contrary to the wishes of the community.  That’s not to say unpopular decisions or mistakes aren’t occasionally made (humans are human, after all), but they aren’t driven by profit motives.

You like working with older computers

I sometimes refer to myself as the “Fred Sanford of computers” — I like working with other people’s cast-aside garbage.  There’s something fundamentally satisfying for me in taking a dusty old laptop or tower that has been labeled “obsolete” and giving it a second life.  For this task, I prefer Debian.

Ubuntu aims to be a completely modern, user-friendly operating system with a cutting-edge look and feel.  This is a perfectly laudable goal, but it tends to require a modern computer to accomplish smoothly.

It’s true that there are Ubuntu respins aimed at older hardware, e.g. Lubuntu; it’s also true that you can use the alternate installer (A.K.A. Debian installer) in Ubuntu to install on machines that can’t boot to a Live CD.  Even so, I find that Debian proves to be a more universally useful tool for reviving old systems, for a few reasons:

  • It lends itself well to the minimal installation method.
  • Its underlying architecture is a bit more conservative (sysvinit instead of upstart, plymouth is not a required dependency, etc.)
  • Its defaults err on the side of secure and lightweight rather than fully functional out-of-the-box.
  • Its software is occasionally packaged with less demanding dependencies.
  • Its more rigorous testing results in fewer resource-draining bugs like memory leaks or CPU spikes.
Don’t get me wrong; for the computer with just a slim layer of dust (say, your ~5 year old gaming rig you just replaced), Lubuntu, Xubuntu, Bodhi Linux, or any of the other “Lightweight Ubuntu remixes” can provide satisfying results easily.  But on something truly crusty (like the K6-2 laptop I recently restored for my kids) the performance gains from using Debian are noticeable.

Parting thoughts

This article may not sell many Ubuntu users on Debian, nor will it probably sit well with fanboys on either side of the fence; but for those who have an interest in exploring the world of Debian, I hope it will help them avoid a few stumbles along the way.  For the rest, I hope you have a better appreciation of the relative strengths of each distro and can take a broader view of what constitutes a good operating system.

If you’ve had some experiences trying or migrating to Debian from Ubuntu, I’d love to hear about it.

3 Thoughts on “Debian for Ubuntu people

  1. derek shaw says:

    I’m an IT guy with dozens (or more) of ubunutu desktops at multiple clients. I’m now a refugee from ubuntu’s Unity desktop.

    I’m very happy with squeeze. One aspect of Ubuntu that I truly value is the OSX-like security. I’ve been spending a lot of time browsing and trying what I find to make the debian gnome authentication work like ubuntu. For example, I want to be able to execute Alt+F2 –> gksu gedit and have the local sysadmin enter THEIR password, not the root password. While I know the security difference is negligible, the practicality of not having to change the root password on a whole bunch of machines is very important.

    What I find confusing is that some applications, like /usr/bin/users-admin are pre-set to use the current user’s password to provide root authentication, while other apps, like /usr/bin/update-manager, are not. Using gksu with update-manager still requires that the end-user knows the root password.

    So, how does ubuntu do it? In other words, what am I missing to be able to make apps like update-manger submit to gksu / sudo control?

    1. Alan says:

      Well, I’m not entirely sure, but I always thought that running “gksudo” instead of “gksu” invoked sudo instead of su and would behave accordingly. Same with kdesu/kdesudo.

  2. nice post, though I did not understand much of it as it’s too much technical. I am sure it’s going to help a lot of people.

Leave a Reply

Your email address will not be published. Required fields are marked *