Hacker News Reader

Hacker News

Comment by Adaptive | Hacker News Reader

Full thread

Adaptive

I switched from Ubuntu to Arch on my servers and linux desktops a while back.

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.

View on HN

I've seen this cycle repeat endlessly in software:

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.

Yep. The one exception that immediately comes to mind though is OpenBSD. The devs there have no trouble telling the users "No!", and, although various individuals of them burn out occasionally, as a group they are talented and dedicated enough to keep moving on.

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.

If only some part of the world of software works like this...

SQLite, OpenBSD, Python, PostgreSQL. Robust, stand through test of time, high quality.

Instead Linux, MySQL, PHP win the popularity contest.

Agreed. OpendBSD is my choiche for my servers, altough I'd love to use it in my laptop too (macbook 5,1 - no luck).

Its not like arch is one year old im using it since quite some time. They trie to keep small not add anything not every user needs. If you wnat to build a complex Linux with arch, go and do so. Doesn't bather the rest of the arch users.

I agree to this. Arch has been out there for long enough; but it has been lean. To exemplify: it does not provide packaged Broadcom wireless drivers. You have to compile them yourselves.

AUR is definitely one of the best thing for me, along with the rolling release scheme, the simplicity and the wiki.

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 had precisely the same concerns.

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.

Could you please elaborate on how you created the mirror?

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.

I just checked out ArchServer and it looks like the project is winding down.

http://www.archserver.org/

I'm not sure if Linode is using archserver but I don't believe they are. I don't see the advantage over vanilla arch isos.

Can you explain to me what's so great about pacman? As of the last time I used Arch (a few years ago), you can't roll back to an old version unless it happens to be cached on your system. For a rolling release system it creates a lot of hassles.

It seems like a very straightforward package manager, what does it have that apt doesn't have, for instance?

I think the draw of pacman is that it's really simple. (Actually that's the draw of Archlinux overall.) Pacman is fast, useful, and you can learn its feature set in ten minutes. Apt-Get is considerably more complex by comparison. Especially, and I think this is where pacman really shines, is making new packages. All it takes to build a pacman package is simple PKGBUILD file. This is analogous to a Gentoo ebuild but much simpler.

You still can't rollback without either having the package in your cache, or going to the source repo and grabbing the old PKGBUILD

I think some of the other comments have addressed this, but I'll comment on the rollback issue.

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.

The only time it backfired at me is when the package you want to rollback to is not in your cache, and basically the only time it happens is for the version installed during the install phase: the installer does not copy the package from the install medium to the target package cache, as it uses it straight from the medium.

The great thing is there are other package managers built on top to be more friendly such as yaourt. So if you think pacman is too primitive then you have options.

> It really does take time if you want to understand Arch deeply.

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.

A friend of mine did so too, on my suggestion. I have been using Arch for more than two years. I disagree that pacman is an outstanding package manager. It is very good though. You should try portage on Gentoo. I used Gentoo before going for Arch. I still have Gentoo and whenever I want a system to be stable for long time, I will use Gentoo. I use Arch because it is bleeding edge. From Gentoo I learnt so much that Arch practically had little less to offer. For a comparision check http://intosimple.blogspot.com/2011/09/arch-linux-my-perspec...

- shallow mental model: I know where everything is, I know all the moving pieces

How is that different than Ubuntu (or any other distro once you've used it enough)? (serious question, considering the same switch myself)

I have been using Ubuntu now for a little over a year, and honestly, I find it incredibly tedious to do the most mundane amount of configuration. I want to adjust what programs get run at start up.

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.

Agreed. This is a great example of why I prefer Arch. Arch has BSD like startup and it's very simple to configure.

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.

There have been GUIs for the init scripts for ages, why don't you use them? Also, what's wrong about learning the init scripts, it's a common concept you will find on so many Linux/UNIX systems, it's just nice to know.

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.

On Ubuntu, rather than weeding through the rc folders, just look in /etc/init.d/ or /etc/init (for upstart).

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.

Thanks, I like Ubuntu Server as well. If it's good enough for Facebook (so I've heard, at least) it's good enough for me.

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.

re: kvm - this might be of help: http://blog.falconindy.com/articles/build-a-virtual-army.htm...

Great writeup, with scripts on github to boot. Thanks!

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.

In what way does Arch have a shallower mental model than Debian? Or pacman superior to apt-get? I'm not trolling. Debian is a pretty vanilla Linux and has a huge package repository.

Debian has dpkg-* , apt-* and aptitude. Now I now they all have their purposes and whatever, but Arch has only pacman.

Consider the complexities of APT: package substitutions, virtual packages, provides, requires, recommends, suggests, replacements and patches as pinning and... There's just more complexity involved. Compare the SysV init system, or systemd, or upstart, to the BSD init system that Arch uses. Now, I'm not saying that Arch is better --- something like Systemd has many more features than what it replaces, and in lots of ways it is better. But it is indeed a more complex system.

"shallow mental model (...) It really does take time if you want to understand Arch deeply"

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.

The "shallow mental model" most likely refers to fewer initialization files and locations. When starting out, most everything you need is in /etc/rc.conf . Also, Arch and its package manager don't use /usr/local/, instead simply using /usr.

"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/

It may also be that figuring out the entire Ubuntu stack is near-impossible, whereas with Arch this is at least approachable.

No package manager should use /usr/local/.

would you elaborate? i guess i agree for historical reasons but for practical reasons i think package managers actually should use /usr/local/. basically everyone uses a package manager now (except lfs). where would you like package managers to install.

From the FHS:

"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

It's the "go" (as in the game) of Linux distros. Easy to understand, long to master.

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.

Reply on news.ycombinator.com