I have been using Arch Linux
for 3 years now. I still use Debian and Ubuntu for the servers I
administer but I acknowledge Arch Linux has taught many valuable
lessons.
With Arch Linux there is very little in your system that you are not aware of. You have to configure everything yourself by editing config files. The process is not that hard because all those configuration files are meant to be tweaked. You also count with an excellent wiki to help you.
The Arch Linux philosophy doesn’t try to shield the user from complexity with extra layers. Instead it focuses on making the direct configuration as simply as possible. For example, writing a proper boot script is much straightforward than in other distros. At the same time if you are not careful you have more chances of really screw things up everything.
Arch Linux aggressively updates from upstream sources. This has the advantage and disadvantages of being always in the bleeding-edge. I also like the idea of putting more responsibility about the stability of software in developers than in packagers, as long as you are aware of this as a user. As a user you have to assume the responsibility of being at the cutting-edge. Things may not go always smooth but you count with excellent tools to manage chaos.
That brings me to the real killer feature that makes Arch Linux shine over the rest: the packaging system. Pacman, ABS, AUR, makepkg and the PKGBUILD format are just great. You usually don’t have to mess with packaging that much, everything installs nicely and dependencies are correctly handled, specially if you stick to the official repository.
But if you don’t like something about a package or need another version you have all the tools in place for the creation and introspection of packages without disrupting pacman bookkeeping (pacman is the equivalent of dpkg/apt-get in Debian). Let me illustrate all this with something I had to deal with this week.
I decide to use Compass to make my stormy relationship with CSS smoother. Compass is a Ruby gem, the usual way to install gems is through Ruby packaging system but I don’t want to mess with the Ruby libraries already installed in the system with pacman. If I install those gems as root pacman will not be able to keep track of them, everything could break in the future, and most importantly, without an easy solution.
A way to deal with this issue is to install the Compass gem in some directory and handle the runtime somehow. You usually end up with a new runtime environment for each project you start. There are excellent tools to manage runtimes in Ruby like Rake, but boy, I already have enough managing my Python virtualenvs.
I see that Compass is already in AUR. AUR is a very liberal package repository where anyone can upload source packages. When you install from AUR you usually have a review the PKGBUILD, the comments of other users and check how many users have voted the package to be included in official repositories. With tools like yaourt the whole process is very smooth.
Alright, the ruby-compass PKGBUILD looks good to me so I install it. Now compass is a good system citizen and can be updated, installed and uninstalled through pacman. Compass works as expected but it turns out that the most interesting feature I wanted to use in Compass is only available in the latest version of Compass, the version in AUR is not the latest one.
No problem, it’ll probably be some version bumps and I’ll be done. I download the PKGBUILD, bump the versions and build the package again but then I realize that the new version depends on new Ruby gems that are not in AUR.
At this point I would avoid getting into a dependency hell and go for Rake, but wait, I’m using Arch Linux, let’s see what happens if I continue with the Arch flow.
I take the PKGBUILD of Compass as a template, which is generic enough for any Ruby gem, and use them for the Ruby dependencies. I update licences, versions checksums, build them and done, everything works. They are all coming from rubyforge and follow the same building conventions, making my life easy as a packager.
I upload the PKGBUILDs to AUR with just one burp command. Now I can install the latest version of compass through pacman without any issue. I then send my modified version of PKGBUILD to the original Compass packager who updates it. That’s it, now anyone can install the latest version of Compass with all its dependencies from AUR. I now can install Compass at home with just one command: just yaourt -Sy ruby-compass.
Now I just have to keep an eye in new updates on the dependencies I’m now maintaining in AUR but rubyforge offers an excellent notification system for gem updates.
That’s it. The whole thing took less than 30 minutes.
I don’t know if nowadays writing a DEB package spec is that hard, I acknowledge I never tried. The tutorials I found about them drove me away when I considered it some years ago.
It’s not only the packaging format itself, there is also the community and policy aspects. Editing your PKGBUILDs is something that every Arch Linux user does. For AUR there is very little regulating making the packaging smoother process at the expense of shifting the trust on the packages to the user. In general, most packages in AUR are good enough but for production machines I still value more the trust the Debian and Ubuntu package maintainers.
That’s where open source community shines, you have many choices.
from http://dannynavarro.net/2011/05/21/why-arch-linux/
--------------------------------------------------
I’ve been on many distros (in order): Mandriva, Ubuntu, openSuSE, Fedora, and only in VirtualBox: Debian and Linux Mint. But since two months there is another distro in both lists (I tested it out on VirtualBox and then set it up on the actual machine): Arch Linux.
Arch Linux is a Linux distribution by Judd Vinet and Aaron Griffin, existing since 2002, intended to be simple, elegant, versatile and expedient (See Reason #3). It uses pacman as the package manager. It’s a rolling-release distro, that means there are only new CD images released, you get updates even if you’ve installed Arch Linux v0.1.
# What makes it so awesome? There are six things that makes it the best distro:
## Reason 1. ArchWiki The Arch Wiki is an awesome place. You can find many useful things about Arch. In this article you can find 9 links to articles in the wiki (plus two doubled).
## Reason 2. Pacman and the AUR The package manager is pacman. It has a specific syntax. The Arch User Repository is a place, where you can find PKGBUILDs (build instructions, which help you make a package) for more packages than contents of the default repositioriies — [core], [extra] and [community] (which consists of binary packages that began their life in AUR) Read the ArchWiki Pacman and AUR articles for details.
## Reason 3. The Arch Way The distro is intended to be simple, elegant, versatile and expedient, as The Arch Way v2.0 states.
## Reason 4. /etc/rc.conf /etc/rc.conf is the main configuration file. Or at least it was. when I wrote this post.
## Reason 5. The community: IRC, Forums, Mailing Lists Arch Linux has a strong community: there are many people on the IRC channel, Forums and Mailing Lists. They are here to help you.
## Reason 6. The rolling-release model Arch uses an rolling-release model, described above (and quoted below).
> It’s a rolling-release distro, that means there are only new CD images released, you get updates even if you’ve installed Arch Linux v0.1. The CDs are released so often I can’t write their dates here.
from http://chriswarrick.com/blog/2011/01/06/arch-linux-the-best-distro-ever/
相关帖子：http://briteming.blogspot.co.uk/2012/01/archlinuxlinux.html
With Arch Linux there is very little in your system that you are not aware of. You have to configure everything yourself by editing config files. The process is not that hard because all those configuration files are meant to be tweaked. You also count with an excellent wiki to help you.
The Arch Linux philosophy doesn’t try to shield the user from complexity with extra layers. Instead it focuses on making the direct configuration as simply as possible. For example, writing a proper boot script is much straightforward than in other distros. At the same time if you are not careful you have more chances of really screw things up everything.
Arch Linux aggressively updates from upstream sources. This has the advantage and disadvantages of being always in the bleeding-edge. I also like the idea of putting more responsibility about the stability of software in developers than in packagers, as long as you are aware of this as a user. As a user you have to assume the responsibility of being at the cutting-edge. Things may not go always smooth but you count with excellent tools to manage chaos.
That brings me to the real killer feature that makes Arch Linux shine over the rest: the packaging system. Pacman, ABS, AUR, makepkg and the PKGBUILD format are just great. You usually don’t have to mess with packaging that much, everything installs nicely and dependencies are correctly handled, specially if you stick to the official repository.
But if you don’t like something about a package or need another version you have all the tools in place for the creation and introspection of packages without disrupting pacman bookkeeping (pacman is the equivalent of dpkg/apt-get in Debian). Let me illustrate all this with something I had to deal with this week.
I decide to use Compass to make my stormy relationship with CSS smoother. Compass is a Ruby gem, the usual way to install gems is through Ruby packaging system but I don’t want to mess with the Ruby libraries already installed in the system with pacman. If I install those gems as root pacman will not be able to keep track of them, everything could break in the future, and most importantly, without an easy solution.
A way to deal with this issue is to install the Compass gem in some directory and handle the runtime somehow. You usually end up with a new runtime environment for each project you start. There are excellent tools to manage runtimes in Ruby like Rake, but boy, I already have enough managing my Python virtualenvs.
I see that Compass is already in AUR. AUR is a very liberal package repository where anyone can upload source packages. When you install from AUR you usually have a review the PKGBUILD, the comments of other users and check how many users have voted the package to be included in official repositories. With tools like yaourt the whole process is very smooth.
Alright, the ruby-compass PKGBUILD looks good to me so I install it. Now compass is a good system citizen and can be updated, installed and uninstalled through pacman. Compass works as expected but it turns out that the most interesting feature I wanted to use in Compass is only available in the latest version of Compass, the version in AUR is not the latest one.
No problem, it’ll probably be some version bumps and I’ll be done. I download the PKGBUILD, bump the versions and build the package again but then I realize that the new version depends on new Ruby gems that are not in AUR.
At this point I would avoid getting into a dependency hell and go for Rake, but wait, I’m using Arch Linux, let’s see what happens if I continue with the Arch flow.
I take the PKGBUILD of Compass as a template, which is generic enough for any Ruby gem, and use them for the Ruby dependencies. I update licences, versions checksums, build them and done, everything works. They are all coming from rubyforge and follow the same building conventions, making my life easy as a packager.
I upload the PKGBUILDs to AUR with just one burp command. Now I can install the latest version of compass through pacman without any issue. I then send my modified version of PKGBUILD to the original Compass packager who updates it. That’s it, now anyone can install the latest version of Compass with all its dependencies from AUR. I now can install Compass at home with just one command: just yaourt -Sy ruby-compass.
Now I just have to keep an eye in new updates on the dependencies I’m now maintaining in AUR but rubyforge offers an excellent notification system for gem updates.
That’s it. The whole thing took less than 30 minutes.
I don’t know if nowadays writing a DEB package spec is that hard, I acknowledge I never tried. The tutorials I found about them drove me away when I considered it some years ago.
It’s not only the packaging format itself, there is also the community and policy aspects. Editing your PKGBUILDs is something that every Arch Linux user does. For AUR there is very little regulating making the packaging smoother process at the expense of shifting the trust on the packages to the user. In general, most packages in AUR are good enough but for production machines I still value more the trust the Debian and Ubuntu package maintainers.
That’s where open source community shines, you have many choices.
from http://dannynavarro.net/2011/05/21/why-arch-linux/
--------------------------------------------------
Arch Linux: The Best Linux Distro Ever
I’ve been on many distros (in order): Mandriva, Ubuntu, openSuSE, Fedora, and only in VirtualBox: Debian and Linux Mint. But since two months there is another distro in both lists (I tested it out on VirtualBox and then set it up on the actual machine): Arch Linux.
Arch Linux is a Linux distribution by Judd Vinet and Aaron Griffin, existing since 2002, intended to be simple, elegant, versatile and expedient (See Reason #3). It uses pacman as the package manager. It’s a rolling-release distro, that means there are only new CD images released, you get updates even if you’ve installed Arch Linux v0.1.
# What makes it so awesome? There are six things that makes it the best distro:
## Reason 1. ArchWiki The Arch Wiki is an awesome place. You can find many useful things about Arch. In this article you can find 9 links to articles in the wiki (plus two doubled).
## Reason 2. Pacman and the AUR The package manager is pacman. It has a specific syntax. The Arch User Repository is a place, where you can find PKGBUILDs (build instructions, which help you make a package) for more packages than contents of the default repositioriies — [core], [extra] and [community] (which consists of binary packages that began their life in AUR) Read the ArchWiki Pacman and AUR articles for details.
## Reason 3. The Arch Way The distro is intended to be simple, elegant, versatile and expedient, as The Arch Way v2.0 states.
## Reason 4. /etc/rc.conf /etc/rc.conf is the main configuration file. Or at least it was. when I wrote this post.
## Reason 5. The community: IRC, Forums, Mailing Lists Arch Linux has a strong community: there are many people on the IRC channel, Forums and Mailing Lists. They are here to help you.
## Reason 6. The rolling-release model Arch uses an rolling-release model, described above (and quoted below).
> It’s a rolling-release distro, that means there are only new CD images released, you get updates even if you’ve installed Arch Linux v0.1. The CDs are released so often I can’t write their dates here.
A short install guide
Pay a visit to the Installation Guide instead.from http://chriswarrick.com/blog/2011/01/06/arch-linux-the-best-distro-ever/
相关帖子：http://briteming.blogspot.co.uk/2012/01/archlinuxlinux.html
