Canonical might switch Ubuntu to rolling releases for 14.04
extremetech.com
extremetech.com
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.
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.
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...
(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.)
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.
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.
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.
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.
Edit: formatting. I've over-done quotation marks to make it clear when precise wording matters.
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'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'`.
Working out the kinks was/is admittedly non-trivial. Read the directions. ;)
Edit: OK, 18 seconds. Still pretty good.
Just out of curiosity, what are Arch desktop users using for servers, where the rolling-release format isn't as acceptable?
But seriously, alias commands you use, no need to remember the oddities.
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.