1. New, popular system/language/app appears and gradually adds features and complexity in response to user requests as it catches on. Devs are personal and responsive. Users feel engaged.
2. Users grow disenchanted with the increasing complexity of the system. Developers burn out on support workload and slowly become more remote.
3. A new shiny, simple alternative appears and users flock to it with a storm of feature requests. Go to 1.
Of course you want to avoid non-intrinsic complexity, but a lot of things are only simple because they don't really do much.
The result is an OS that still uses a text-based installer, that is still easy to get accustomed to, and is still for the most part super reliable, even after years of development and popularity.
SQLite, OpenBSD, Python, PostgreSQL. Robust, stand through test of time, high quality.
Instead Linux, MySQL, PHP win the popularity contest.
But you say you use it on your servers? I'm not sure I would do it because Arch doesn't focus on stablity like Debian does, and sometimes update to core packages can break other packages, so... Not a big deal on your own computer but on a server? I would be happy to know if you have good reasons to use it on server :)
I first set up a basic webserver on Linode since they had images for Arch. I was skeptical particularly because I've screwed stuff up on Arch systems during an "aggressive" update.
It's been rock solid and I deal with updates through a basic test methodology. I keep a mirror of the system on a VM and update that first. I am also very conservative about what packages I update.
I'm only running nginx and a couple basic services along with Haskell related packages to update my static website, so I can't speak to anything more complex than that, but I've been very happy so far.
The big advantage for me is the single mental model between my personal and server systems.
I have almost the same setup (Arch, Linode, nginx) and although my VPS has been rock solid so far, I would like to have something like this for testing purposes.
It seems like a very straightforward package manager, what does it have that apt doesn't have, for instance?
If you just want to rollback you can download the current package if it's not in your cache. If you want and rollback to previous version, there's downgrade and the Arch Rollback Machine https://wiki.archlinux.org/index.php/Downgrade#ARM
Really, though, it's never been an issue for me. I've yet to encounter a situation where I nuke my cache and don't have rollback packages available. It boils down to a management issue. If you are nuking your package cache, I assume you are smart enough to have determined your system is running correctly first. There are cases where you might still want to rollback after clearing your package cache, so there is ARM.
Personally, if I ever hit that situation (absolute worst case scenario) I have backups and can reinstall an Arch system in minutes. Haven't had the need yet.
I'm don't get what you mean. I've been using Arch for 4 years or so and I don't think I know much more about the system internals than I did 3 years ago, because there aren't many.
The system config is stored rc.conf, the package manager is configured in pacman.conf. That is Arch Linux. You open these with vim, read the comment, edit, save, that is it. If you break something, tough luck. Other distros will half-assedly babysit you through the system config and leave you confused. That is the main difference I think.
How is that different than Ubuntu (or any other distro once you've used it enough)? (serious question, considering the same switch myself)
On Arch Linux, I go to /etc/rc.d and remove or modify any scripts, which are clearly labelled.
On Ubuntu, I think I need to weed through the dozen or so numbered /etc/rc directories and find what I need and modify. I got pretty frustrated about this.
I don't know where I'm going to be able to modify the modules that get run when my computer starts on Ubuntu, but with Arch, there is a clearly labeled array in the rc.conf file called modules.
It just seems like looking under the hood of ubuntu is something I'm not supposed to do, and arch requires you to when you install it, but it is tremendously simple.
I want to switch back.
To make a program not start on startup, either apt-get remove it, or chmod -x the init script.
I've used both Arch and Ubuntu extensively, and I like them both. For servers, I tend to use Ubuntu server edition, which really isn't that much different to Arch + a few hours of setup. It's really just a stripped down Debian flavored linux... nothing complex about it... but you do get the benefit of being downstream from lots and lots of testing, Arch not so much.
Pacman is 10x simpler then deb/ppa, so Arch is great if you like to tinker, or if you are building a special purpose system - eg for freeswitch, mythtv, xbmc, kiosk browsing, appliances etc.
I currently run Ubuntu desktop 10.04, and several Ubuntu Servers in bridged VirtualBox vm's for development, which lets me simulate a multi-server production environment on my desktop.
However, I've been thinking about switching the desktop to Arch using Xmonad or i3, and KVM for the vm's (keeping Ubuntu Server).
Any experience running KVM on Arch? Assuming there's no issues with it.
I also see qemu-kvm can run Windows too, which somehow escaped my notice. Cool. If only it could OS X as well, I could skip buying a Mac and spend the money on a souped up dev laptop from XoticPC instead.
I realize Ubuntu is moving to upstart, maybe that will simplify things, but the current sysV run level model results in tedious complexity that I don't need. Other's might, but I don't.
Usage of lsmod/rmmod and /etc/modprobe.d isn't exactly hard to understand either, though i don't know of a GUI for this.
You made me curious. Those sound like they are the opposite of each other.
On the article... the same old. Not for me. I like learning, but not just anything. Learning how to use the configuration of dozens of software pieces is NOT on my to do list, specially when it's pretty obvious I won't have room on my mental memory for all of it. As the article says, it's not for everyone.
"It really does take time" most likely refers to the fact that you are responsible for building up the OS yourself. So unlike in an OS like Ubuntu, where you do not have to know what a window manager is, or what an xorg xserver and client means, you'll have to learn it all along the way.
Fortunately the wiki makes figuring everything out managable, and I found it an enjoyable to spend a couple days with different software[1] and a programmable tiling window manager[2]. The end result is a fast-booting custom tailored system.
[1] https://wiki.archlinux.org/index.php/Lightweight_Application... [2] http://awesome.naquadah.org/
"The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated." [1]
And I believe that "system software" today means "installed by a package manager" (please correct me if I'm wrong).
I personally (rarely) use /usr/local for manually-installed packages. This way there's no risk of a package manager accidentally overwriting stuff outside its control.
[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
For instance, I recently switched off of using netcfg to wpa_supplicant instead. netcfg is an awesome way to manage network configs, but I am to the point that I enjoy and want to tweak my network configs to be faster (faster to get the network connection up, not faster throughput).
Most distros will take a very safe, works-in-all-cases approach to networking and sacrifice some efficiencies that can be squeezed out of the process. Since the system is very simple to configure, I can easily dump all that cruft (and in this case the "cruft" is the already pretty lean and efficient netcfg) and just use ip, iw, and wpa_supplicant.
It takes a bit of time to learn those tools, not long, but it's time. It's valuable because iproute2 is the Way going forward.
Just one example, but there are plenty of others.
Here's are the key benefits from my perspective:
- shallow mental model: I know where everything is, I know all the moving pieces
- pacman: outstanding package manager.
- aif: dieter has done a great job making a modular install framework.
- AUR: compared to PPAs, AUR is simple and easy to contribute to (both commentary and packages)
It really does take time if you want to understand Arch deeply. Not crazy amounts of time. Less than vim, I'd say ;) but enough that you shouldn't expect instant results. The knowledge gained is very rewarding and applicable to Linux systems in general.