Ubuntu – Long Term Support

One item of particular interest with Ubuntu is their development schedule. Because a typical Linux distribution is composed of many applications from many different parties, the Ubuntu developers do not directly control or develop a lot of the software included in Ubuntu. Furthermore Ubuntu tries to be a complete desktop environment rather than just an operating system, which means it includes a wider variety of software than what’s found in Windows and Mac OS X.

What this amounts to is that Ubuntu needs to both provide future patch support for included applications, and it needs to compensate for the fact that they don’t develop many of these programs. Coupled with this is the fact that 2nd party application development is not necessarily synchronized to Ubuntu’s release schedule and some applications (and the kernel itself) can have a rather rapid development rate.

Trying to deal with all of these factors, Ubuntu has settled on two classes of releases. Every 6 months – in October and April – Ubuntu takes what’s ready and releases a new version of the OS. For 1st party material this is tied with some goal for the release (such as replacing the audio daemon) while for 3rd party software this may be as simple as grabbing the latest version. This puts regular Ubuntu versions in an unusual position when trying to classify them – it’s significantly more than a Mac OS X point update, still more than a Windows service pack, and yet a single release generally encompasses less than a new version of either OS. But at the same time, there’s no guarantee that any given release of Ubuntu won’t break software compatibility or binary driver compatibility, which puts it up there with major OS releases.

Furthermore because of the need to provide security updates for all these different programs in all of these different versions, Ubuntu has a very short support cycle, and in that cycle only bug fixes and security updates will be issued, software is not otherwise changed as it’s intended to represent a stable platform. A regular release is only supported for 1.5 years; which for example means support for 7.10 Gutsy, the immediate predecessor to 8.04 Hardy Heron, expired in April. This pushes new versions of Ubuntu back towards the idea of them being closer to a service pack or a point release. In essence, it’s intended that everyone using regular versions of Ubuntu will stick to a relatively rapid upgrade treadmill.

But this obviously doesn’t work for everyone, which results in there being two classes of Ubuntu. What we’re looking at today, 8.04, is what Ubuntu calls a long term support (LTS) release. Every 2 years a version of Ubuntu is labeled as a LTS release, which entails a much greater effort on the developer’s part to support that edition of the OS. The standard support period is 3 years instead of 1.5 years, and for the server edition of the OS that becomes 5 years.

This makes the LTS releases more comparable to Mac OS X and Windows, both of which have long support periods in excess of 3 years. This is also why we’re starting with a review of Hardy, in spite of it being over a year old now, because it’s the current LTS release. Regular short-support Ubuntu releases have their place, but they are not intended for long-term use. Coming from Windows or Mac OS X, a LTS release is the comparable equivalent.

Operating System Mainstream Support Extended Support
Windows 5 years 5 additional years
Ubuntu 1.5 years None
Ubuntu LTS 3 years None
Mac OS X So long as it's the newest OS So long as it's one version behind

Unfortunately, in spite of the LTS designation, not all of the applications in a LTS release are intended to be used for such a long period of time, or are their developers willing to support them for that length of time. If we take Firefox for example, the last Ubuntu LTS release, 6.06 Dapper, shipped with Firefox 1.5. Mozilla very quickly ended support for Firefox 1.xx after Firefox 2 shipped, and now you can’t even get support for 2.xx now that 3.xx has been out for quite some time. This leaves the Ubuntu developers in charge of supplying security updates for the older versions of Firefox they still support, which while better than the alternative (no security patches) isn’t necessarily a great solution.

The Ubuntu developers have done a good job of staying on top of the matter (they just published a new 1.5 security patch as recently as last month) but it highlights the fact that the Ubuntu developers do not always have the resources to maintain both a stable platform and the necessary security updates. So while an LTS release is supposed to be supported for 3 years, in reality not every component is going to make it that long.

Digging through the bugs list for Dapper and Hardy, I get the impression that these kinds of cracks only occur on less-used software (particularly that which is not part of the default install, such as VLC), so an option for users who need to stick with the base OS for the entire life of a LTS release, but don’t mind upgrading a few applications can go that route and cover all of their bases. Unfortunately this is easier said than done, and we’ll get to why that is when we discuss the package manager.

What this amounts to is that if you’re the kind of person that intends to run a computer and an OS for a very long period of time – say on the scale of XP, which turns 8 this year – Ubuntu likely isn’t a good fit for you.

It’s Secure What’s the Value of Technical Support, Anyhow?
Comments Locked

195 Comments

View All Comments

  • jigglywiggly - Wednesday, August 26, 2009 - link

    I see you shared a lot of the same problems I had with Ubuntu when I first got it. Yeah, it's harder, I won't lie, and it's a pain in the ass when it doesn't work. But when it works, you love it, and you feel like more of a man. I use it for my web server, runs very nicely.

    Ubuntu sometimes makes you want to shoot it with a m249, but at other times you feel superior to other users. But that's because you are using the terminal all the time and are actually smart, Mac users just need to be shot in the face for their ignorance.
  • smitty3268 - Wednesday, August 26, 2009 - link

    I agreed with a lot of what was in this review.

    I think a lot of your problems would have gone away by using the newer versions, though, specifically with the package manager. There's much less need for finding things outside of it when you're using the new versions. Even video drivers can usually be put off for 6 months or so if you're not too cutting edge. Leaving the package manager behind is a pain, though, as you found out. You tried to explain that the LTS version was more comparable to Windows/OSX, but in truth very very few desktop users continue to use it. In fact, I'm not aware of any. It's really only used by companies for work machines who don't want to make large changes every 6 months like home users can.

    MSTT fonts. Good luck trying to get those by default, they're owned by microsoft who is in no mood to simply give them away to their competitors. Installing them is like installing the patent encumbered video codecs - at your own risk, which is minimal as long as you aren't trying to make money off of it.

    It should be mentioned that Red Hat put down some money to buy some nice new fonts a while ago, called Liberation, that are much nicer than the default serif ones this old Ubuntu version was using. Still different than the MS ones, though, which is going to cause some people problems. Also, the font anti-aliasing differences are again due to patents owned by other companies, but there's good news there. They're supposed to expire later this year so better font rendering in Linux should be coming soon! You can already get it working manually, but the distros make it hard to setup.

    You mentioned you chose Ubuntu because it was supposed to be user-friendly, which I regard as one of the more puzzling wide-spread myths that go around. Sure, it's a lot simpler than Debian, or some other choices, but it is definitely NOT the distro to choose if you're looking to avoid the CLI, as you found out.

    On that note, I would HIGHLY encourage you to eventually go back and do another review (part 3?) that uses a KDE based distro. Maybe try out OpenSUSE next fall, for example. Although KDE is going through a bit of a transition now, it's definitely where all the more interesting stuff is going on. As you said, Gnome is a lot like a boring Windows XP environment, which is both a positive and a negative. KDE is quite different, for better or worse, and is worth a look I think. For one thing, that smb://COMPUTERNAME address will work out of the box in KDE apps. If you do try KDE, I highly recommend another distro besides (K)Ubuntu, though, because they simply don't put any resources into their KDE implementation and it shows.
  • leexgx - Wednesday, August 26, 2009 - link

    Ubuntu KDE has more options to play with that are missing in gnome (but gnome top is far better then KDE top, long time i used linux its task monitor, Linux verson of windows XP task manager but only the process page but very detailed)

    Ubuntu should be easy to use but it lacks the easy install for drivers and Still does not offer Fail save VGA mode if X windows fails to start your stuck with an command line, it should try an second time but in save mode vga but it does not
  • Badkarma - Wednesday, August 26, 2009 - link

    Thought I'd mention a linux specific site Phoronix has an "Open Letter to Tech Review sites" (http://www.phoronix.com/scan.php?page=article&...">http://www.phoronix.com/scan.php?page=article&....

    You mentioned linux on Netbooks, and thought I would mention that I found Moblin(www.moblin.org) from Intel very impressive. It's still in beta and a little rough around the edges, but it boots faster than xp resumes from hibernate, around 15sec from bios screen and the UI is designed around small screens. After using it for a few hours and then installing Windows 7, I immediately missed how well Moblin was optimized for the lowres small screen. I had to install W7 because the ath9k kernel module drivers are unstable in Moblin, if not for this I would probably keep it as the primary OS on my netbook.
  • colonel - Wednesday, August 26, 2009 - link

    I ve been using Ubuntu 9.0 for a year with my Dell notebook and i love it, I dont see limitations in my work, the only problem is my company doesn't allow it in the network but is my OS in the house
  • Eeqmcsq - Wednesday, August 26, 2009 - link

    I'm still reading it, but on my xubuntu 8.04, my firefox is located in /usr/bin/firefox. Most apps are under /usr/bin.

    Also, the directory structure is definitely VERY different from Windows. One main difference is that everything that belongs to the user is supposed to be under /home. Everything that belongs to the "system" is everywhere else. I think the theory is that the user stuff is "sandboxed" in /home, so he doesn't mess things up in the system for everyone else.
  • Penti - Tuesday, September 1, 2009 - link

    You have the same in Windows under %SystemDrive%\Documents and Settings\user Although many settings are stored in the register (which can be said to be the equivalent of /etc). It's however there programs like Firefox saves it settings and where you have your My Documents and tempfiles.

    * %SystemDrive% is a variable and substitute for your systems drive letter on which Windows is installed which can be something other then C:.
  • fepple - Wednesday, August 26, 2009 - link

    On the normal Ubuntu install, the /usr/bin/firefox is actually a symlink that points to the firefox install in /usr/lib :)
  • ioannis - Wednesday, August 26, 2009 - link

    the question is, who cares where firefox or any other application's binary is installed? It's not as if you'll go searching for it to run it. They are on your execution 'PATH', which means you can just press ctrl+F2 and type their name, or a terminal, or access them from the application menu.

    My favourite way is to use something like gnome-go (or krunner in Kubuntu)

    PS: yes, all package manager provided application have their binaries in /usr/bin and most user build ones go in /usr/local/bin by default, which is also in your $PATH.
  • fepple - Wednesday, August 26, 2009 - link

    As a developer that has to deal with custom paths or managing symlinks in default paths, I can say I do care where binaries are located ;)

Log in

Don't have an account? Sign up now