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.

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.

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.

I spent some time browsing through the manual online today, and thought I’d share my reactions.

Nothing like a book

Obviously, the Internet is chock full of resources for the aspiring Debian admin already, such as forums, wikis, blogs, how-tos, and more.  But there’s nothing quite like the cohesiveness of a well-written book or manual to bring things together and get you proper context for things.

For instance, the manual starts off with a good summary of the Debian project’s history, philosophy, and organization; these things may seem superfluous to the busy admin just trying to configure a system, but I think they’re important context for approaching Debian with the right frame of mind.

I also found several chapters that highlighted gaps in my own knowledge, such as the bits about LVM and logcheck.

Understand, this is an English translation of a book originally written in French, so the syntax is sometimes a bit odd; overall, though, it was well done and readable.

Some good

There are some really nice sections in this manual that are highly specific to Debian, such as the sections on dpkg and creating your own .deb packages.  There is documentation out there about this, of course, but it’s presented in a compact and straight-to-the point way here with nice diagrams and so forth.  I also look forward to a deeper perusal of the SELinux and virtualization sections, which I’ve wanted to get a deeper grasp on.

I also enjoyed the running “case study” theme that the book kept bringing back, similar to the approach used in “Samba by example”.  It gives a more concrete feel to the examples and instructions.

Some not so good

My biggest criticism of the manual so far, though, is that it seems very dated and of questionable relevance in a lot of places.  For example:

• In the sections on interoperating with other systems, Macs are referred to as running PowerPC processors and using AppleTalk networking protocols.  Neither has been true for years.
• The section on remote login begins with a discussion of why you should disable Telnet and avoid “r commands” (rcp, rsh, etc).  This is good advice, I guess; but I haven’t seen telnetd installed on any distro by default since… ever.  And only the greyest of greybeards (who should know better already) has ever used “r commands” in Linux, seeing as they have been deprecated since the late ’90s.
• No mention of LXDE in the list of desktop environments.  Granted, it’s not been around as long as KDE, GNOME, and XFCE, but its popularity has been explosive over the last few years, especially among derivatives and users of older computers.

These are nit-picking examples, I know; but they seem exemplary of the overall datedness of the tone (if not necessarily the content).  It’s not so much that the book hasn’t been updated with new information over the years, but that the old information hasn’t been suitably diminished, reorganized, or removed.

My other beef with the handbook is what’s missing:

• There’s only minimal mention of PAM, and then only in the context of configuring a system for LDAP login
• I found no references to LTSP/MueKow or similar PXE-boot/thin client type setups, which are pretty common in large deployments
• Also, no mention of cfengine or similar large-scale management solutions
• There really doesn’t seem to be a good “Linux fundamentals” section for absolutely new users.  This manual is really mostly aimed at those who know Unix, but want to learn the Debian specifics.

None of these is really essential, but it seems like they’d be worth including given the detail with which some other low-level bits are discussed.

A finished work, or a starting point?

Now that the book is released under free licenses, I’m wondering if it can make a transition into a project that can be constantly updated and improved, or if it will just be another stagnant and soon-to-be-outdated text like so many others out there.  What the Debian community really needs is not so much a finished opus as a rallying point for building some really top-notch documentation.  Will this handbook be that point?  Time will tell….

The Ubuntu studio 12.04 desktop.

Not so long ago, I posted about my attempts to bring my old DAW system back to life with Lubuntu.  Emboldened by my success, and eager to get it on a nice firm LTS-release foothold, I tried to upgrade it to Precise Pangolin a few weeks ago.  Sadly, the results were not so great:  after upgrading, I ran afoul of a mysterious bug that caused Ardour, Audacity, and Hydrogen (and possibly other programs) to segfault when I started them.  Despite my best efforts to track down the error (probably caused by my liberal use of PPAs and 3rd-party repositories), it became clear I needed to start afresh.

This time I decided to skip a bit of the DIY and just grab a ready-made audio production distro; after all, there are plenty of them out there, aren’t there?  Well, the hunt began for an audio-production oriented distro that would work decently on an older 32-bit system while promising future updates; and yes, believe me, my not-so-fond-of-Ubuntu friends out there, I didn’t limit myself to ‘buntuland.  Yet search as I might, every project I found seemed either at least 18 months stale (if not out-and-out abandoned), or a one-man project based on Debian or Ubuntu anyway.  In the end, Ubuntu studio seemed best to fit the bill.  So I downloaded the nearly 2 GB .iso file, popped it on my flash drive, and loaded it onto the old workhorse; and here, dear reader, are my findings so far…

 The desktop

Ubuntu Studio, mercifully, uses the XFCE desktop, whose light resource footprint fits just fine on my crusty old Sempron system.  It’s not quite as light as Lubuntu, but close enough and more mature.  Ironically, the layout is almost exactly what I’d set up on my Lubuntu desktop, with the panel at the top and a bar of larger quick-launch shortcuts at the bottom.   You might say it’s a bit of a nod to the Mac desktop layout, though without the global menu and animated dock.  This sort of layout works well for me, and I’ve pretty much moved to a top panel on all my systems no matter what DE I use.

One nice improvement over my Lubuntu setup, though, is the menu; it’s been carefully customized to organize applications into convenient categories (audio production, video production, photography, etc) and sub-categories (effects, recording, mixing, etc), so you don’t have to scroll through some giant “multimedia” menu to find your favorite soft-synth.  Nicely done, lads.

The desktop did require a bit of customization for me; I didn’t need the indicator plugin (no chatting while I’m recording, thanks), nor did I want that bottom toolbar auto-hiding (I have plenty of screen real-estate, and auto-hiding panels always tend to pop-up annoyingly when I’m trying to do stuff at the edges of a maximized window).  The default volume icon is useless with my multi-channel audio interface, so it goes out as well, and I replaced the icons in the bottom panel (all of which are generic apps like chat, web, file browser, etc) with my most commonly used audio apps.  Last, and probably very much least,  the default wallpaper is professional-looking but rather drab and mostly unnecessary, so it got replaced with a flat color background to save some CPU.

 Applications

Ubuntu Studio isn’t just for musicians, but pretty much anyone who works with multimedia.  So all the applications you’d expect for audio, video, and graphics work are here.  I don’t do either of the latter, so my focus is on the audio.  You have:

• Jack2 set up and ready to rock.  I’d been on Jack v1 before, since it worked better with my (antique) MIDI interface, but so far Jack2 works well enough.  I like new software .
• Ardour, as the main DAW.
• Audacity, for audio editing.  I also prefer this for non-musical recording (e.g., VO work)
• Hydrogen drum machine
• GUITARIX!!! my amp simulator of choice, when I rock out (it happens…)
• Most of the better LADSPA, LV2, and DSSI plugins for effects and synths
• QTractor for MIDI-sequencing

Rosegarden isn’t there, but personally I didn’t use it much, and it’s readily available from software center of course, along with LMMS, Buzztard, several trackers, and various other niche applications that some musicians may find compelling.  I also found a few more plugins in the software center that weren’t included by default, as well as the Bristol softsynth collection; most of the stuff I actually find useful, however, is ready to roll out-of-the-box.  Nice.

For the graphically inclined, there’s a good selection of applications like GIMP (not the new 2.8 version (yet)), InkScape, Dark Table, MyPaint, and Blender.  OpenShot video editor looks compellingly simple, even for someone like me who’s never done any video work.  I think the kids might be interested in checking that out more now that they have a new webcam.  DVD mastering software (DVDStyler) is also included, for those who wish to put their video creations to disc.

For now I’m resisting the urge to go hunting for more plugins from 3rd-party sources, as I don’t want the next upgrade to blow my system apart; but really, everything I need to start recording is already here.

 Under the hood

Digging below the surface, Ubuntu Studio conveniently comes with the lowlatency Linux kernel installed by default, which saves adding in a PPA or compiling it yourself.  That’s convenient!

My M-audio Delta 44 (another antique, I know) works flawlessly with Ubuntu Studio, and the appropriate mixer/configuration software (Mudita24) is already installed.  No worries there.

I also had no trouble getting it to work with my parallel-port MOTU MIDI Express, after applying the same modprobe configurations I did before, though as I mentioned it doesn’t work as well with Jack2 (basically, it doesn’t show up in the Jack MIDI ports, just in the ALSA MIDI ports).

I did have some initial trouble with pulseaudio, which is supposed to be nicely integrated with Jack, but wasn’t working right and caused a lot of slowdown.  I purged pulseaudio, and everything is working fine (and much faster).  Not sure why it was included, it adds nothing to Jack in my opinion.

 Dreams and wishes

In my wildest dreams, (ok, not wildest) I could wish that Ubuntu Studio came with Wine VST support working right out of the box, with a simple interface for installing my VST and VSTi plugins from the old days.  I guess that would probably violate some kind of intellectual property restriction, and in any case the basics are already covered.

Of course, what would be even better would be the development of more quality libre LV2 plugins, included and ready to roll. I suppose that will come eventually.

I wonder if the Ubuntu Studio developers might look into doing some sort of integration with FOSS-related music services, like Jamendo or UbuntuOne Music, so that artists can readily publish their creations.  Not sure how that would work, but it’s a thought.

Really though, with Ubuntu Studio installed what I most need now is something no distro can provide:  the time and energy to get out the microphones and start recording!  Wish me luck!

There still seems to be a lot of confusion out there about this, and sadly a lot of people downloading OpenOffice are not aware of the situation are are downloading something that is way behind technically, and as far as I can see hasn’t got much of a future at this point (though that could change).  The difference is particularly important to Ubuntu users, many of whom may be upgrading in the next few months from 10.04 to 12.04 and (as a result) apparently “switching” to LibreOffice.

Ironically, though, the “OpenOffice” that they’ll be switching from is actually a lot closer to the LibreOffice they’re switching to than anything currently available under the name “OpenOffice”.  You see, before LibreOffice existed, there was a project called Go-OO.  Go-OO was funded primarily by Novell, and essentially consisted of a comprehensive patch set for OpenOffice that added features or fixes which (mainly for licensing reasons) could not be included in the “official” OpenOffice from Sun.

Nearly every major Linux distribution (including Ubuntu, Debian, Fedora, etc) shipped Go-OO (in addition to other distro-specific patches) in place of Sun OpenOffice, even as far back as 2.x versions.  For the sake of familiarity (I assume) they packaged it under the name OpenOffice, despite the differences.

When LibreOffice was created, the Go-OO patches were among the first things to be folded into the forked codebase, along with various patches from major Linux distributions (e.g. RedHat, Debian, etc).  The Go-OO development community (including Meeks himself) also mostly threw in their lot with LibreOffice.

Anyhow, take a look at Michael’s post, particularly the nice graphic comparison of the two.  I think it’s pretty clear which one you’ll choose.

There is a lot of good general advice out there, but I’m going to give a few specific tips of my own for folks trying it out:

Tip #1: Use a decent computer

Linux has a reputation for rescuing old, crusty computers from the landfill, of course, and there are many Linux distributions that cater to aging PC’s.  Ubuntu isn’t one of these.  It’s a modern, no-holds-barred OS designed for simplicity and ease-of-use.  So it requires a little horsepower.

I’ve personally been testing it on a Pentium M with 512 MB of RAM and an old Intel video chip; it runs, but I wouldn’t wish the performance I’m getting on anyone (even in “2D” mode).  If you want an easy metric, get a machine designed for Windows Vista or newer (something made in the last 5 years or so).

If you want to see Ubuntu running as it’s meant to, don’t drag dad’s old Windows 98 box out of the attic.  I’d recommend at minimum a dual-core processor, 1 gigabyte of RAM, and a newer NVidia, AMD, or Intel video chip.

Tip #2: If it seems slow, it’s probably the video driver

You have your “decent computer”, loaded with terabytes of RAM and a 16-core 5GHz processor, but Ubuntu seems sluggish and unresponsive.  WHY???? you find yourself screaming.

It’s the video hardware.  Chances are, you have a video card that isn’t compatible, or requires a proprietary driver to be loaded.  Don’t panic, just fire up the “Additional Drivers” tool from the menu and see if it recommends any driver installs.  If it does, it’s just a few clicks, enter your password, and reboot.  Ahhhh…. all better.

Needless to say you can’t do that from a Live CD environment, you have to actually have it installed on a hard drive.  And if no drivers are recommended, or it doesn’t fix the problem, definitely seek help from the community forums.

Tip #3: Wubi is a temporary solution

Wubi is a great, revolutionary tool for making a dual-boot installation painless and safe.  It installs Ubuntu to a file on your Windows C:\ drive rather than a separate partition.  This saves you the trouble and danger of repartitioning your hard drive, and lets you easily uninstall Ubuntu from your computer using Windows’ add/remove programs dialogue.

Wubi has some downsides, though:

• It’s slower than a normal install
• It’s more prone to disk corruption, since there are two file-systems to deal with
• If you decide you just LOVE Ubuntu and want to remove Windows, you can’t without some serious contortions on the command line.

If you do decide to install using Wubi, don’t consider what you’ve installed a permanent situation.  Keep it in the back of your mind that, should you decide to keep Ubuntu, you’ll be reinstalling it from scratch.

Tip #4: Don’t drink the WINE

WINE is the most amazingly cool, ambitious, unprecedented, and unimaginable software project ever.  It’s a compatibility layer that allows Windows software to run — unaltered — directly on Linux.  It’s been in development for nearly two decades, has zillions of programmer-hours behind it, and is now on its third “stable” release (1.4).  It also mostly doesn’t actually work.

Yeah, it works on some things.  Mostly games, or Microsoft Office.  Kind of.  Sort of.  Until the next release breaks it.

OK, so it’s improved over the years, but in my own experience trying to run Windows software in WINE:

• About 50% of the programs I try to install or run just flat out don’t work.  They crash right off the bat.
• About 40% get through the install and seem to run, but have some bizarre, fatal bug that makes them unusable (no text anywhere, crashes when you resize, buttons don’t work, etc).
• About 10% actually install, run, and are somewhat usable.

Despite this failure rate (which is roughly corroborated by the WINE database), I keep hearing Linux advocates blithely say “You can run all your Windows software in WINE!”.  If you’re ever told this by someone trying to get you to try out Ubuntu or Linux, ask them what Windows software they run in WINE, and how well it works; because in over 9 years of using Linux, I can count on one hand the number of times Windows software running in WINE has been part of a functioning computing solution for me — and  I can count hands-free how many times it was part of a solid long-term solution.

Even if WINE worked flawlessly, though, I would recommend new users stay clear of it, for two reasons:

• Windows software running in WINE does not integrate well with the Linux desktop.  It’s hard to describe, but the two operating systems have such different structures and metaphors that it’s just kind of awkward.  You really won’t have a good, seamless experience using Windows software on a Linux desktop.
• Running Windows software on your Linux system will only keep you from discovering and using native Linux tools, which are far more reliable and integrated.

Now, don’t misunderstand; LibreOffice isn’t the same as Microsoft Office, and GIMP isn’t Photoshop, so if running a couple key applications in WINE makes the difference between getting to run Linux and being stuck on Windows, so be it.  But if you are trying to install Kodak EasyShare on Linux just because it came with your camera, or Yahoo Instant Messenger because you think it’s the only way to chat with your YIM buddies, you’re doing this wrong.

Tip #5: Install software the Ubuntu way

“Installing software in Linux is too hard!” used to be one of the biggest resounding complaints I’d hear from people trying Linux.  The funny thing is, the way we install software really hasn’t changed much at all in the last 15 years, but now that everyone understands what an “App Store” is, the whole idea of getting software from an online repository instead of downloading it from random websites doesn’t seem so foreign to people any more.

Still, if you are coming from Windows, here’s my standard instructions on how to install a piece of software in Ubuntu:

• First, check the software center.  These are the online repositories that come with Ubuntu, and they have about twenty thousand software titles in them.  Lots of stuff to choose from.
• If it’s not in there, see if you can find a PPA (personal package archive) on Launchpad that has the software.
• If it’s not there, it may be at one of the third-party repositories like getdeb or medibuntu.
• If it’s not there, see if the software project’s website has a .deb (debian package) file that you can download.
• If you still can’t find it, ask on the Ubuntu forums.  You’ll either get pointed to where you can get a package file, or get help compiling from source.

Remember, compiling from source is always a LAST RESORT.  You almost never need to to this to get a piece of software running in Ubuntu these days, and even then there are convenient, brain-dead easy tools to help you do this correctly.

Tip #6: Ubuntu is only the beginning…

It’s sadly amazing how many people see their choice of operating systems as Windows, OSX, or Ubuntu (though, not as sad as the number who only see two choices…. or one…).  Ubuntu has managed to wiggle itself into a position of being the “third choice” OS,  but it’s important to realize that it’s only one star in the Linux galaxy.  If Ubuntu doesn’t suit you, realize that there are any number of other distributions out there, all of whom have different ideas about what a desktop should be like, how often an OS should be released, how much testing should go into it, etc.  If you really want to run Linux on your computer, and Ubuntu just doesn’t suit your sensibilities, here are a few great options to try out:

• Fedora is the cutting-edge community distribution sponsored by (and based on) Red Hat.  It features the GNOME desktop by default, but also offers KDE, XFCE, or any other environment you might want.
• Linux Mint is based on Ubuntu, but has a unique respin of the GNOME desktop known as Cinnamon.
• SimplyMepis is a great Debian-based distribution with a KDE desktop.  It’s the one I started with, and still offers a great system for beginners.
• Kubuntu, Xubuntu, Lubuntu, and Bohdi Linux are all variants of Ubuntu with different desktop environments, but the same underlying tools and full Ubuntu compatibility.
• OpenSuse, the community version of Suse Enterprise Linux.
• Slitaz, for that dusty old computer I told you not to install Ubuntu on.
• Last but not at all least, Debian, the mother of Ubuntu with more conservative ideas about software releases.

Have fun!

Have fun checking out Ubuntu; remember, Linux is supposed to be fun!!

Now, I never owned an Amiga, unfortunately; in fact I despised Amigas and anyone who owned one, purely out of an unreasoning sense of sour grapes (the Amiga was, in some ways, more advanced than any computer I’d own for almost another decade).  But now that time and tide have washed the vinegar from my teeth, I’ve been overcome with a bit of morbid curiosity about this platform of the past.  And when I discovered that some fine folks had developed AROS,  an open source remake of the Amiga OS, designed for standard PC hardware, I had to check it out.

AROS, like Linux and BSD, has multiple distributions — three to be exact.  As it happens, the leading distro of AROS, Icaros, has recently released version 1.4, so I promptly installed it in QEMU and have been checking it out for a while.

Core system

Icaros boots almost instantly, even with modest hardware resources allocated.  This is probably owing to its extreme simplicity:  the system has no concept of user accounts, runs no network services, and just in general isn’t starting up a whole lot of software when it boots.  Still, let’s give it credit:  it’s speedy on the boot-up.

The AROS filesystem is simple and straightforward, something like DOS or Windows but using disk labels rather than drive letters. So your main partition is called SYSTEM:, and you can have a separate WORK: partition (like /home, I guess) if you wish.  Everything is arranged in a neat heirarchy, with all the messy libraries and program data files swept under the virtual rug as hidden files.  All you see browsing around are executables and your data.   This takes a little getting-used-to for a Linux user, but one can obviously see the logic of it.

As a Linux user, I naturally launched the shell application first, to see if I could dig around a little under the hood. The AROS command line is it’s own thing; it struck me as closer to DOS than POSIX, but with a whole set of commands all its own. Icaros is definitely more GUI oriented anyway, so I decided to give up on the shell and check out the GUI instead.

Icaros comes with GUI tools to configure things like networking, USB, desktop preferences, etc.  These can all be found under the “System” menu, though I’d recommend keeping the manual handy when you work with them, as they aren’t the most intuitive interfaces I’ve ever seen.

One nifty feature on the desktop is a RAM disk drawer (note: they aren’t folders on AROS, they are drawers. Same thing, different metaphor.) on the desktop. This is a handy chunk of memory that you can access just like a drawer on the disk, but of course it’s obliterated whenever you reboot. Not sure how useful that is in the days of multi-terabyte SATA drives, but it’s a neat idea all the same.

The Icaros Desktop

My Icaros desktop, after some tweaking from the default theme. (Click for full-size)

Icaros’ desktop, Wanderer, is an evolution of the original Amiga Workbench desktop. At first glance it seems pretty much like any other desktop environment you’ve ever used, but there are some subtle-yet-important differences.

First, right-click works quite a bit different than I’m used to. Instead of popping up a context menu, a right click toggles an application’s global menu, which appears at the top of the screen Apple-style.

The other oddity is window management. Apart from the obligatory “close” button, the window decorations contain an iconify button (minimizes the program to a desktop icon. You might remember this from Windows 3.1, or NeXTStep-like environments), a “size toggle” button (which seems to toggle between the largest size you’ve resized a window and the smallest), and a “raise to the front” button, which struck me as slightly pedantic. Notably missing is anything resembling “maximize”, which I found increasingly annoying.   I’m not particularly enamored of the way Icaros does window management; granted, I’m used to a tililng window manager, but even compared to conventional desktop environments it seemed to require a lot more mousing about to arrange windows than I want to do.

Icaros sports a launcher/dock type gadget at the bottom of the screen called “amistart”, which as I understand it was not part of the original Amiga workbench. It’s pretty much what you expect, though I kind of like the way the “start menu” works — because the filesystem is basically laid out like a menu structure, and “support files” are hidden, the menu is just a glorified file browser. You can use it like a normal menu, or click on any folder in the menu to just open that folder in a file browser. Kind of nice if you want to check out a bunch of programs under a certain folder, and don’t want to have to keep navigating to it on the menu.

The file browser is minimal, and can operate in a modern “browse” mode, or the classic “spatial” mode (spatial file browsers basically open a new window for each folder you open, which back in the 90′s was somehow believed to be more user friendly. Especially for users who love playing a good game of “click all the X’s” after digging about for a lost file.)

By far the coolest feature of the Icaros desktop is how it handles multiple workspaces. Instead of chucking them on a cube or grid, additional workspaces are stacked up, and can be accessed by sliding the top ones down from the top. It kind of reminds me of those lecture-room blackboards at big colleges that can slide up and down to reveal additional blackboards beneath.

Applications

Audio Evolution running on Icaros. Notice it's on its own screen, which I've pulled down a bit to show the desktop beneath. (click for larger image)

Well window managers and launchers are all fine and good, but not much use without something to launch and manage. Considering its relative obscurity, Icaros pleasantly surprised me with the volume of applications available. The “full edition” (Icaros Live, not Icaros Light) that I installed is chock full of programs that span the gamut.  I was honestly hoping to find one or two real gems among Icaros’s programs that would make me say “I need to have one of my computers booting this so I can check out this application”.  The jury’s still out on whether I’ve found any, but nevertheless there’s a good selection of stuff:

• Web browser:  Yes, it has a web browser, so it’s not a totally useless OS .  Odyssey web browser, or OWB, is basically webkit wrapped in a chunky 90′s-esque UI.   But apart from the obvious lack of proprietary plugins and codecs, it works just like any other webkit browser.
• Other network:  Icaros has a decent POP/IMAP mail client, and clients for IM, IRC, FTP, Remote desktop, and VNC. I didn’t find the SSH client, but there were a few things I couldn’t identify so who knows.  (NOTE: the most recent release, 1.4.1, also adds support for Windows file sharing (SMB) as well).
• Games:  there’s a nice selection of games installed in Icaros; most of them are ports of open source games available on other platforms (SupertuxKart, Blob wars, Doom, etc) or original versions of old standards (solitaire, chess, etc).  Nothing to impress the L337 94/\/\3r crowd, but you can have some fun nontheless.
• Emulators:  Here we have a nice feature of Icaros:  eighteen emulator programs covering a wide variety of classic home computers, consoles, game systems, and operating systems.  Nothing you can’t get for other operating systems, but here they are packaged, configured and apparently sporting the necessary ROMS to function.
• Multimedia:  Being a musician myself, and knowing the Amiga was at one time a top-line multimedia machine, I was eager to see what music making software Icaros held.  There are some mod trackers, a 303 emulator, a drum synth, and a serviceable multitrack DAW (Audio Evolution 4).  The selection didn’t blow me away, but if anything tempts me to put Icaros on real hardware, it’s the idea of doing some music Amiga-style.
• Graphics:  Icaros comes with several paint/draw sort of applications, none of which seemed either stunningly better or egregiously worse than Gimp, Paint.NET, or any of a dozen other free paint applications for other platforms (at least in my limited non-artist assessment).
• Other: Text editor, PDF viewer, ZIP archiver, CD burner, disk formatter, etc — all those little applications you never think about needing until you need them.  Icaros has them, no worries.
• Development:  A Lua interpreter is included, as well as the SDL libraries.  Vim has been ported, but sadly no Emacs .  There is a weirdly cartoonish IDE called Murks, and a number of other tools with obtuse names whose purpose was not clear to me (like “Chocolate Castle” ?¿?).

Overall Thoughts

What’s the point of Icaros?  Is it a nostalgic curiosity?  The up-and-coming desktop of the future?  A niche OS for a small community of holdouts?  Hard to say, really; but for anyone with a spare computer and fond memories of (or burning curiosity about) the Amiga, it’s almost certainly worth spending a rainy afternoon with, at the very least.   It’s also a good candidate for that old-and-dusty PC that’s too slow for your favorite OS.

By all means, if you have the time and inclination check it out!  You can find the software here, and an excellent must-read-first manual here.  Let me know how it goes!

I wanted it to behave more like the run prompt in other desktops, so that typing in a URL would open the URL in an appropriate application.

With help from Alexander Yakushev on the awesome mailing list, I managed to figure it out….

I originally had planned to just send any identified URL to xdg-open, but I found that it really only handles file, http, and ftp urls properly.  More exotic urls, like ssh://, fish://, smb://, vnc://, man://, and others require more explicit direction.  So the first thing was to define which programs would handle various protocols, using a lua table:

--runners for various protocols
myrunners = {
http = "xdg-open",
ftp = "dolphin",
file = "xdg-open",
vnc = "krdc",
rdp = "krdc",
fish = "dolphin",
smb = "dolphin",
man = "dolphin",
info = "dolphin"
}

The next step was to override the default run callback.  This takes place down in the globalkeys assignment table, where the default file has something like this:

awful.key({ modkey },            "r",     function () mypromptbox[mouse.screen]:run() end),

I replaced it with this definition:

awful.key({ modkey },            "r",     function ()
  local promptbox = mypromptbox[mouse.screen]
    awful.prompt.run(
      {prompt = "<span>Run: </span>"},
      promptbox.widget,
      function (command)
        local protocol = command:match("^(%a+):/+")
        if protocol then
          command = (myrunners[protocol] or "xdg-open").." " .. command
        end
        local result = awful.util.spawn(command)
        if type(result) == "string" then
          promptbox.widget.text = result
        end
      end,
      awful.completion.shell,
      awful.util.getdir("cache") .. "/history")
end),

My callback for the run command (starting on line 6 here) basically does this:

• Uses a regex to search for the string “:/” as part of the first word, and puts the letters before the colon into a variable called “protocol”
• If there is a protocol, it looks up the protocol in the “myrunners” table, and prepends the resulting command (or xdg-open, if the protocol isn’t in the table) to the URL.
• If there isn’t a protocol found (the first word contains no “:/”), then it does nothing
• Finally, the constructed command is run!

It works great, and allows me to quickly open remote URLs with a minimum of fuss.  So far the only shortcoming is that opening files this way requires using “file://” followed by the full path.  I’m contemplating the best way to streamline opening files in awesome, but haven’t quite decided how I want to work with it yet.

Something about running a window manager like Awesome makes you uber-sensitive to operations that require you to do a lot of mouse-maneuvering or manual window management, and thus encourages you to streamline these operations.  One such thing for me is searching google for something, an activity which I’m bound to do at least six dozen times during a workday, especially when developing (since I can’t remember API’s for squat).

With a little help from a bash script and surfraw, I came up with a pretty cool solution. 

First, you need to install surfraw.  Surfraw is a command-line tool for searching different search engines; it’s available in the Debian and Ubuntu repositories.  Once installed, you can call it like this:

sr google bunch of search terms

And it will open a new tab in your browser (or open a browser, if need be) with the google search.  Of course, you don’t have to use google, as surfraw comes with a variety of other search options.

You’ll also need wmctrl installed.

Once those were installed, I created a script in my ~/bin directory (which I’ve added to my path — you can of course put this script in /usr/local/bin/ or wherever) and called it “google_search.sh”:

#!/bin/bash
term=$@
foo=''
#search with surfraw
sr google $term
#wait until the window exists and registers with the WM
while [ -z "$foo" ]; do
 foo=$(wmctrl -l |grep -i "$term - Google Search")
 sleep .5
done
#could use wmctrl -a, but it's not always reliable in awesome with dual screens
wmctrl -r "$term - Google Search" -b add,demands_attention
echo "awful.client.urgent.jumpto()" |awesome-client

Basically this script does the following:

1. assigns all arguments to a variable “term”
2. runs surfraw with the search terms
3. the while loop watches the window list for a window with your search terms and “Google Search” in the title
4. Once it shows up, we mark the given window as “demands_attention” a.k.a. “urgent”
5. Finally, we tell awesome to switch to the urgent client.

As I noted in the script, on a single monitor situation I could just use “wmctrl -a” to switch to the window instead of doing all that urgent nonsense, but I’ve found that to be unreliable with dual monitors (e.g., sometimes it switches to the right tag, but on the wrong screen).

Once I have this script somewhere in my $PATH, I add the shortcut to awesome, by adding these lines to the “globalkeys” table in my rc.lua:

-- surfraw search
 awful.key({ modkey, }, "g",
 function()
 awful.prompt.run({ prompt = "<span foreground='#7f9f7f'>Google Search:</span> "},
 mypromptbox[mouse.screen].widget,
 function(input)
 awful.util.spawn_with_shell("google_search.sh " .. input)
 end, nil
 )
 end
 ),

(Incidentally, you may want to remove or change the pango markup on the prompt to match your theme. I’m using zenburn, so it matches nicely).

After restarting Awesome, Mod4-g gives me a prompt to do a google search.  Works a treat!

Well, I figure it’s time to stop being stingy, so I am releasing the code to that browser under the GPL.  You can find it on github, here:

https://github.com/alandmoore/wcgbrowser

Contributions would be welcome, as the code has some stupidities and shortcomings.  It does work for my needs, and may work in a wide variety of situations, so feel free to make use of it.

I will, of course, appreciate code contributions from those so inclined!

The result is here.  No sequencing or drum programming going on (obviously), just laid down one track at a time into Ardour and mixed down with a handful of plugins.  The lead synth is nekobee running through a parametric eq and rotary speaker sim, recorded live into Ardour.

I’m pretty happy with what it can do, though I still feel like the workflow with Jack/Ardour is a little cumbersome.  My hardware is kind of flaky too, sadly.  Still, there’s something that inspires me more about working with duct-tape and baling wire than with some shiny turnkey system.