Hacker News new | past | comments | ask | show | jobs | submit login
Canonical might switch Ubuntu to rolling releases for 14.04 (extremetech.com)
63 points by mindstab on Jan 23, 2013 | hide | past | favorite | 26 comments



It seems silly to have any modern Linux distro be anything but a well implemented rolling release, because people aren't getting physical dvds to install this stuff anymore. If you run a server, get the latest stable packages, run with it, and if something needs upgrading manually upgrade the select packages you want to update. Keep security updates. If you are a normal user, you can probably just let rolling updates upgrade everything.

The greatest problem I have with my relatives who I have running Ubuntu or Fedora is that major version increments will almost always critically break the system because they are often 4 - 6 kernels or other package versions behind. If you were to step through the update process in order, you might get a minor snag, but often it updates flawlessly. I have never had an issue in over a year running an Arch box (besides porting my init scripts to systemd, but that was a unique case, and that wasn't a problem, it just required effort) whereas on two separate machines going from 11.04 to 12.04 broke the kernel or graphics drivers respectively.

I do think most distros could do better with 3 tiers of packages in a rolling release, though - new releases for the actual developers of the package to run through the ropes and find and fix major bugs they specifically encounter, which then pass into a testing branch where enthusiasts can run bleeding edge software and submit errors they encounter to be fixed before it enters mainstream core repos. A lot of the current problems with rolling releases are that you don't have a big enough pool running in testing to catch the majority of slip-through-the-cracks integration problems that pop up after the release itself is solid, so you need to properly incentivize people to use the testing branch, and the main reason people don't do that is that updates often just outright break the software entirely rather than have integration issues, hence 3 tiers.


It seems silly to have any modern Linux distro be anything but a well implemented rolling release

The key here is of course well implemented. I switched recently from Debian back to Ubuntu because I need a system that is properly QC'ed. I was using Debian testing and every time I dist-upgraded something broke. It got so bad that I started waiting for weekends to do it.

The greatest problem I have with my relatives who I have running Ubuntu or Fedora is that major version increments will almost always critically break the system because they are often 4 - 6 kernels or other package versions behind.

Use an LTS version of Ubuntu.

I do think most distros could do better with 3 tiers of packages in a rolling release

This is how Debian does it. Problem is that stable branch does not contain many new software, testing/unstable branch is still too volatile for use as a regular system.


Sounds like Debian sid/testing/stable...


Or ArchLinux testing/stable.... though sometimes even stable feels like "testing", but with the occasional breakages I had less problem with Archlinux, then I had with the Ubuntu updates release by release....


Rolling releases and the 6 month-release cycle the worst thing about Linux. I hate it when I have reinstall and upgrade because of compatibility so often - there is zero new functionality and rather that reducing bugs, the distributions replaces the old ones with new ones. Or it randomly breaks your fixes. Or after the update your system locale is switched to Chinese (happened to me, and no I have nothing in common with China).


This has been my experience too. In the end, I found myself more comfortable with slower-moving distributions like Slackware.


Linux Mint does this on their LMDE version. A rolling release will mean that Canonical must provide an easy way to rollback to previous package versions or to save snapshots of the user's machine before upgrading. You can't expect that an Ubuntu end-user to have the same technical knowledge as someone with experience with Debian, Gentoo or the BSDs to troubleshoot when suddenly their computer is not booting and that they need to change run levels or disable their display manager to figure out what's wrong with Xorg. Shit happens, and happens often.

Also, I've used Archlinux (now Debian sid recently with their systemd "upgrade" and other desicions that deviate away from their KISS principle) and haven't experienced any problem, then again I tend to run a maximalist[1] desktop. Stuff starts to break when you have a lot of applications installed with their own dependencies and their own team of people working on that application, I've always felt that the whole desktop environment on Linux is like building a tower with cubes, it's solid when you have a few applications, but as you start adding stuff on top, the whole things starts trembling away and it takes a really small problem to bring everything down.

If this is going to be done, they better provide ways to their users to easily recover from an upgrade gone wrong.

[1] - Maximailism is a better word: http://kmandla.wordpress.com/2010/05/05/maximalism-is-a-bett...


I think it's a win, as long as they make rolling releases between LTS releases optional. That way the LTS users keep their current status quo, and the 6-month release users get a more even distribution of new features and OS updates (they can be released when they're done, not when the release cycle hits, and you can always have the latest web browser).

(For what it's worth, my current Linux distro of choice is Linux Mint Debian Edition, but I used Ubuntu on my primary machine for a couple years around the end of the oughts.)


6 months of "rolling releases" isn't a rolling release at all (i.e. if the rolling releases are only between LTS and LTS). LTS would have to be separate from the rolling releases entirely.


I meant that the users that currently upgrade every 6 months would move over to the rolling release system.

Also, I don't think LTS would have to be completely separate from the rolling release. IIRC Debian stable is basically just a freeze of the Debian testing rolling release somewhere that makes sense.


I guess the idea here is to bring the joy of running Arch and Gentoo to the unwashed masses?


Ah yes, the joy of having to religiously read release news to make sure the next `pacman -Syu` won't horrifically screw up your system. Having been an Arch user for several years, I understand the appeal of rolling-release, but if Canonical doesn't make it safe they'll ruin the "plug'n'play" appeal of Ubuntu.


The reason I originally switched from Gentoo to Ubuntu several years ago is that Gentoo kept deferring from marking things stable. At one point it had been almost 10 months since a Gnome release and it still wasn't marked stable. This was during a time of great transitions like Network Manager - something that was desperately needed. You could of course go in and say it was okay to install the unstable versions of various packages but my list just kept getting longer and longer. Rolling distributions change the big milestones from everything to smaller pieces but they will still be a problem such as when new Gnome/GCC etc releases come out that interact with a lot of other packages.

My main problem with Ubuntu/Canonical is that they seem to prefer going their own way instead of trying to collaborate. Unity could be done as a Gnome Shell extension. Replace upstart with systemd. Do something about the bugs.


I'm not sure rolling releases makes sense but either removing Unity or making it as configurable as Gnome 2 was would be a huge step back in the right direction.


If it weren't for pacman's weird user interface (not functionality, just the UI), I might have already switched to Arch. As Ubuntu gets worse (it seems like every day there is a new anouncement that sucks), pacman looks better and better.


pacman is a little awkward, but I prefer it to apt/dpkg, which have sub-commands, each with their own flags, some of which are undocumented. pacman, on the other hand, has ALL options documented in one fairly short man page.

The trick to understanding pacman is to understand how it maintains databases of packages, and what it means to "sync".

There are several "databases" that pacman deals with:

  * "the database", (`/var/lib/pacman/local/`)
    The database of currently installed packages
  * "package databases", (`/var/lib/pacman/sync/${repo}.db`)
    There is one of these for each repository.  It is a file
    that is fetched over plain http(s) from the server; it
    is not modified locally, only updated.
The "operation" of pacman is set with a capital flag, one of "DQRSTU" (plus -V and -h for version and help). Of these, "DTU" are "low-level" (analogous to dpkg) and "QRS" are "high-level" (analogous to apt).

To give a brief explanation of cover the "high-level" operations, and which databases they deal with:

  "Q" Queries "the database" of locally installed packages.

  "S" deals with "package databases", and Syncing "the
      database" with them; meaning it installs/updates
      packages that are in package databases, but not
      installed on the local system.

  "R" Removes packages "the database"; removing them from
      the local system.
The biggest "gotcha" is that "S" deals with all operations with "package databases", not just syncing "the database" with them.

Edit: formatting. I've over-done quotation marks to make it clear when precise wording matters.


What UI are you talking about? pacman is a relatively simple to use cli tool. -S to install something, -Ss to search for something -y to update the package list, and -Su to upgrade packages; that's basically four flags to memorize. Or do it all at once with -Syu.


It's simple, but the switches are rather odd. I get the point of S, Y, U etc... and then the minor options of yu etc... but it's rather arbitrary in practice.

Note: -S isn't "install," it's for syncing which does all manner of things including installs, but not removals (oddly enough). It's little things like this that bother me about pacman.


I can't tell if you're being sarcastic. I guess that means you've won.


It is also valuable to know -R and c and s to remove a package and its dependencies and dependents.


I felt the same way, but once I actually learned it, it's pretty straightforward. Besides just installing packages, -Qs, -Ss, and -Si give me most of the information I need in a digestible way. I never did figure out how to do most of that with apt-get. After working out the kinks, I'm loving Arch on my laptop, 10-second startups and ~6 hours of battery, with basically nothing running that I didn't ask for.

Working out the kinks was/is admittedly non-trivial. Read the directions. ;)

Edit: OK, 18 seconds. Still pretty good.


The idea of only running things that I decide to run is probably the most appealing thing to me about Arch/Gentoo. And I'm sure I'll figure out the user interface, but I still think it is weird. I'll probably think of maybe 5 more excuses to keep using Ubuntu before I toss in the towel and switch to Arch.

Just out of curiosity, what are Arch desktop users using for servers, where the rolling-release format isn't as acceptable?


Generally I only have to use the following: pacman -Ss (for the occasional search)

pacman -Syu [pkgname] (I almost always use yu to ensure that things are always in sync)

pacman -Rsun pkgname

pacman -Qi pkgname

pacman -Sc (used every so often)

I would say those cover 99% of my interaction with pacman. I'm not sure of any other interfaces to use it so it would be interesting to know more about how you use pacman.


I've got to say, as somebody who is very comfortable with the command line (my job is linux server admin) but has never used arch before, that sounds pretty damn obtuse.


There are several GUI wrappers around pacman (and several wrappers to unify it with AUR), but for the most part that's it.

I'd add that I'd be careful about -n on -R (don't back up configuration files when removing a package); I'd let pacman back them, then catch them in my usual `sudo find /etc -name '.pac'`.


<scarcasm>You know there is a nifty feature called bash aliases which is present in linux. so 'pacman -Syu' can simply be called 'upgrade'</scarcasm>

But seriously, alias commands you use, no need to remember the oddities.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: