This is taken form the Arch Wiki and put here to put it under the attention of you all:
These are quotes; read the whole page here: https://wiki.archlinux.org/index.php/En … _Stability
...Arch is inherently stable due to its commitment to simplicity in configuration, coupled with a rapid bug-report/bug-fix cycle, and the use of unpatched upstream source code. Thus, by following the advice below on setting up and maintaining Arch, the user should be able enjoy a very stable system. Furthermore, advice is included that will ease system repair in the event of a major malfunction. ...
Save old packages!!!
Use Recommended Configurations
In the detailed Arch Linux installation and configuration documentation, there is often more than one way to configure a specific aspect of the system. For example, there are several ways to configure a login manager to run during startup. Always choose the recommended, default configuration when setting up the system. (In the case of login manager configuration, this is the inittab method). The recommended, default configurations reflect best practices, chosen for optimum system stability and ease of system repair.
Be careful with unofficial and less tested packages
Avoid any use of the testing repository, or individual packages from testing. These experimental packages are for development and testing, and are not suitable for a stable system....
Use precaution when using packages from AUR. Most of the packages in AUR are supplied by user and thus might not have the same packaging standard as those in official repositories. Always check AUR package's PKGBUILD for any signs of mistake or malicious code before you build and install them.
Use Up to Date Mirrors
Use mirrors that are frequently updated with the latest packages from the main Arch FTP server. Review the Arch Mirror Check webpage ( http://users.archlinux.de/~gerbra/mirrorcheck.html ) to verify that your chosen mirror is up to date. By using recently rsync'd mirrors, this ensures that your system will always have the freshest packages and package databases available during the course of routine maintenance. ...
Avoid Development Packages
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community. These are packages taken directly from upstream development branches, and usually feature one of the following words appended to the package name: dev, devel, svn, cvs, git, hg, bzr, or darcs.
Most especially, avoid installing any development version of crucial system packages such as the kernel or glibc, such as those found in the testing or community repositories.
Install the linux-lts Package
The linux-lts package is an alternative Arch kernel package based upon Linux kernel 3.0 and is available in the core repository. This particular kernel version enjoys long-term support from upstream, including security fixes and some feature backports. Additionally, this package includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a fallback kernel in case a new kernel version causes problems, linux-lts is the answer.
# pacman -S linux-lts
It will be necessary to edit either GRUB or LILO, depending upon which bootloader is used, to make this kernel available as a boot-time option.
Generic Best Practices
Use the package manager to install software
The package manager (in Arch: pacman) does a much better job than you at keeping track of files. If you install things manually you will, sooner or later forget what you did, where you installed to, install conflicting stuff, install to wrong locations etc.
From a stability standpoint you should try to avoid unsupported package and custom software, but if you really need such things making a package is better than manually compiling and installing.
Use Proven, Mainstream Software Packages
Install mature, proven, mainstream software; while avoiding cutting edge software that is still buggy. Try to avoid installing "point-oh", aka x.y.0, software releases. For example, instead of installing Foobar 2.5.0, wait until Foobar 2.5.1 is available. Do not deploy newly developed software until it is proven to be reliable. For example, PulseAudio's early versions could be unreliable. Users interested in maximum stability would use the ALSA sound system instead. Finally, use software that has a strong and active development community.
Choose Open Source Drivers
Wherever possible, choose open source drivers. Try to avoid proprietary drivers. Most of the time, open source drivers are more stable and reliable than proprietary drivers. Open source driver bugs are fixed more easily and quickly. While proprietary drivers can offer more features and capabilities, this can come at the cost of stability. To avoid this dilemma, choose hardware components known to have mature open source driver support with full features. Information about hardware with open source Linux drivers is available at linux-drivers.org.
Read more at https://wiki.archlinux.org/index.php/En … _Stability
After installing kernel-lts be sure to put it in your mounting /dev/sdaX/boot/grub/menu.lst:
title ArchBang Linux LTS kernel root (hd0,10) kernel /boot/vmlinuz-linux-lts root=/dev/sda11 ro noresume 4 initrd /boot/initramfs-linux-lts.img
And if you want to keep proprietary drivers, which is not recommended, you probably need to install lts specific drivers ; for example nvidia-lts:
#pacman -S nvidia-lts
Installing pacmatic seems a sensible suggestion too: http://kmkeen.com/pacmatic/index.html
#pacman -S pacmatic
Getting your questions answered here at ArchBang Forums
Please! Always give hardware info, if there is a chance that 's relevant: #lspci -vnn
Quote: What I have learnt from Linux is to minimize dependencies and functionalities for greater independence.
On Arch(bang) and Openbox: http://stillstup.blogspot.com/
It is certainly a page well worth reading on the Arch wiki.
I've only recently started using pacmatic, http://kmkeen.com/pacmatic/index.html it adds a few seconds at most to my daily upgrades & gives me very useful info' when needed. I wish I'd known about it a long time ago.
I call it using the alias (with nice http://ss64.com/bash/nice.html) paur from my ~/.bashrc as follows:
### packer using pacmatic & nice with -Syu: alias paur="PACMAN=pacmatic nice packer -Syu"
It works like a charm.
Last edited by handy (2012-02-27 17:30:04)
nice read thx.
especially the part about "...Use precaution when using packages from AUR. Most of the packages in AUR..." most are fine, but some can be very problematic.
The "BSD" things in life are "Free", and "Open", and so is ArchBang!
Go Leafs Go !!!
To prevent serious breakage of the system, do not install any development packages, which are usually found in AUR and occasionally in community.
Ionut (wonder) recently blasted some of the unofficial repositories for consistently having packages available that break systems (he was mainly talking about archlinux.fr)
GUI's?? We don't need no stinkin' GUI's!!!