The downside to a rolling release cycle, of course, is that the distro maintainers don't have a fixed code-base to test against, making sure that everything works together smoothly. This increases the probability that the user will have to do more work to make things integrate the way he wants them to. But in practice, many of the open-source applications for Linux are run at so many version levels, thanks to the various distributions that package them at different snapshots of their ongoing developments, that they have evolved to inter-operate very well without relying on a specific version of this or that. Dependencies are usually described in terms of an inequality expression, like "glibc >= 2.3", meaning that the developer has tested against v2.3 of the glibc library, and knows of no changes to it after that time that breaks his application. So the ">=" expresses his expectation that any version of glibc at or above 2.3 should be fine. The other side of that coin is that packages in active development always make sure they work with the latest stable version of libraries like glibc. If a breaking change occurs to glibc, the developer of the application that relies on it will scramble along, updating his application to work with the new library. In the process, he may find he has to make it impossible for his app to work with prior versions of glibc, updating his dependency to "glibc >= 2.5".
Ubuntu is based on Debian, another Linux distro. Debian is famous for being very conservative about rolling out new code, which makes it very stable. Stability is great, but this conservatism means that two rounds of delays and testing need to happen before big changes come to the desktops of Ubuntu users: first Debian has to sign off on it, and then Ubuntu goes through its own round of customizing, integrating, and testing. Finally in April or October, the new stuff hits the wires for users to get as part of their Ubuntu systems. In theory, I can go get the latest-greatest directly from the teams building it: if I want KDE, I can go download it from kde.org. The problem with doing this is that Ubuntu manages its version of that software in its repositories, and now I have installed my own version. By working around the system in this way, I take on not only the installation, integration, and updating tasks, but also all the strange inter-dependency problems potentially introduced between my new version of KDE and my old versions of all my other applications. This is a slippery slope, and soon I find myself doing three kinds of version management on vast parts of my system: the Ubuntu (easy) way, my own home-grown (scripted) way, and the nasty and manual toggling back and forth on an individual package basis.
Arch, on the other hand, is not based on anything except Linux kernel source. When a new version of something big like KDE comes out, the Arch team builds it against the latest source tree, does some dependency checking to determine if related packages are affected, and packages the KDE-only release for deployment. Instead of a delay of close to 6 months, like Ubuntu, this regression testing and packaging is typically done in only a day or two. Recently, KDE had a fairly major revision bump from 4.6 to 4.7. The KDE project announced the new version on July 27. Arch had the package ready to be automatically updated on users' systems on July 30.
In addition to the officially supported packages like KDE, Arch has the Arch User Repository (AUR). This repository is maintained by the user base itself, and is the place to find the less-common applications that have not been officially added to the distribution. If something isn't in the AUR, anyone with the experience and community-mindedness can add it themselves, making it easier for the next guy to install the software. In Ubuntu, individual software maintainers can create their own repositories, called PPAs. These can be added to the Ubuntu Update Manager to automatically keep the software up-to-date. This works well, but PPA support is pretty spotty across various maintainers; often the web address of the PPA - where the Update Manager should go to check for updates to install - changes, causing arcane error messages in the Update Manager that must be decoded and dealt with. The PPA system does a good job of hiding the details of Open Source Software from the user, but that also makes it very difficult for him to fix his own problems when the maintainer is too busy to fix them for him. Arch avoids this issue by putting the responsibility squarely on the user's shoulders. This would make management of all these "3rd-party" applications nearly impossible for most, but not for a developer - and in practice, by the time I suffer enough pain to go deal with an issue myself, someone has probably already packaged the solution up for me and updated the AUR.
In general, Arch has a do-it-yourself flavor not found in most of the other distributions. This DIY spirit hearkens back to the early days of Linux, where if you wanted to run the operating system, you were compiling kernel source for hours first. Arch isn't nearly this effort-intensive, of course, since there is no reason for thousands of users to cover the same ground and deal with the same frustrations over and over. It strikes a balance between doing the common work so the user doesn't have to, and leaving the personal decisions (and the maintenance consequences) to each individual. Like all continuums, different people have different opinions about whether the right balance has been struck. That's OK, that's why we have so many distros to choose from!
Arch Linux isn't all sunshine and flowers, though. The installer is a lot less helpful than Ubuntu, and when you get done you find yourself at a console login: no desktop manager has been installed, not even X-Windows. If you don't know you need to keep the system up-to-date, or you don't know how, it doesn't get updated. If an update breaks your system, you're on your own to fix it. The growing user community is very helpful and the Arch Wiki is fantastic, but many of the basic things that users take for granted on Ubuntu (like wireless support) are the subjects of long, technical Wiki entries and vast arrays of piteous requests for help on community support forums. Each of these preceding words are a separate link, if you're feeling curious, and these are just the first page of results from Google! There are Linux distros (Mint) I would recommend in good conscience to a first-time user coming from Windows or Mac. Arch is not one of those distros. This is a big step up for me in terms of taking responsibility for the ongoing maintenance of my desktop machine, and I don't take it lightly.
The best way I know to make sure something is going to work and support all my critical computing tasks (including Minecraft) is to install it in a Virtual Machine, documenting my challenges and their solutions as I go. It's like a dress rehearsal.
Next: Virtual Box
Or check out the Index
No comments:
Post a Comment