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.
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.
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 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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
"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.
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.
I've been using Arch as my primary OS for about 1.5 years and have no inclination whatsoever to move away from it. Like many people, I previously used Ubuntu, but grew fed up with the focus of their development efforts on areas which I considered to be inconsequential. Seeing the direction that Ubuntu has taken since then, I'm glad I made that decision when I did.
For me, the best thing about Arch is simply how flexible it is. It feels more like a toolkit for building your own custom OS than anything else. That's obviously not for everyone, but it's definitely for me. I've got a trimmed-down, keyboard-driven, and CLI-focused interface that would not appeal to the average user, but it was fun to configure and I've learned a ton from the experience. My computer behaves exactly the way I want it to, with virtually no compromises, and that was a far easier goal to attain with Arch than with any other system I've tried.
Also, as a bonus for anyone interested in Haskell, there's a rather large Haskell community within the Arch community. In fact, there's a vast user-maintained repository of Haskell packages built for Arch (a large portion of the packages available from Hackage) which you can enable just by adding a line to /etc/pacman.d/mirrorlist.
For anyone who likes to tweak and tinker, and who loves having full control over their computing experience, I highly recommend it.
> For anyone who likes to tweak and tinker, and who loves having full control over their computing experience, I highly recommend it.
My experience has been the exact opposite. I've been using Arch for over 3 years now. And once I had the system configured for the first time, I've never had to mess with it at all. It is one of the simplest distros. And the packages are usually well maintained so that upgrades will automatically make the required changes or notify you about making them. It is surprisingly stable. Also whenever I've to install it on another machine, it takes just over an hour to install and then get it going with my custom config files etc. What I'm trying to say is that after the first time investment, its very very straightforward.
I've been a GNU/Linux user for a bit over a year now, I think. Started out with Ubuntu 10.04 dual booted with Windows, then completely ditched Microsoft in favor of the better operating system some when in January. A bit later, after getting bugged by a good friend and fellow hacker on IRC for a while, I finally set out to install Arch, and got hooked.
Arch Linux can, in my experience, best be described as a journey. A journey to the top of a mountain. It starts steep, sometimes gets hazardous, and I fell down more then once and had to start climbing from the start. But with every time, it became easier as I got to know the mountain, and set out with new knowledge about the steps and stones, as they were aligned perfectly for climbing once you knew how to climb them.
Then finally, I reached the first peak - a custom, running and stable install - and just as you might hold your breath at the sight presented to you when you look down from the top of the mountain you just climbed, I felt kind of serene - I learned so much about my system during the installation, how it worked and how elegantly simple it was once you understood it's philosophy, it was overwhelming.
I knew I arrived at a place where I wanted to stay. Or rather, a place from where I could climb even higher mountains - because the Arch journey is probably never at its end. There's always something more to learn about the system - my system. Something to tweak, somewhere to hack around or some configuration to customize for my needs.
I won't say I'll stay with it forever, as in the world of GNU/Linux, one might always discover something new. I will say, however, that installing (and subsequently running) Arch was (and still is) one of the best and most rewarding things I've done in my life.
To anyone who is interested in learning new stuff and doing things on his or her own, I warmly recommend trying out Arch. You shall not be disappointed.
I started with Archbang, then CTKArch, and then finally installed my own from scratch. Archbang and CTKArch are excellent liveCD versions of Arch but in the end I found I did not like the personal choices made by the creators of those releases. My system is now truly mine. I am in love with it.
My system is stable, and bleeding edge - an oxymoron.
Intellij is in the damn repositories... MondoDB 2.0 - the day it was released was in the damned repositores.
Anything else can't compete.
After installing Arch, and failing at least 3 times and being successful 2 other times, I found an appreciation for the way in which Arch did things. My first version was a Mac OSx clone with some personal touches. It was beautiful; but I was too ambitious and went with BTRFS which was a mistake. So I reinstalled and now I'm on XFS and things purr.
I can setup a development environment in less than 10 minutes using pacman and then keep it updated easily.
To setup the equivalent environment on Ubuntu would take much longer for me.
I am not a linux newb nor a guru, but after using Arch I feel like I can hold my own.
A couple of days ago I was given more RAM to my work computer. I had to run couchdb instances with lots of allocated RAM. The 32bit Ubuntu was not enough anymore so I needed to install a 64bit OS. Somehow I wanted to try Arch and the installation from scratch to the everyday tool took a bit over two hours.
I really like this distribution. Pacman (the package manager) is super fast, the system is much easier to configure from the command line than Ubuntu and the best thing is Arch's documentation. All the information you need to know can be found from the Arch wiki. No need to browse blog posts or forums, the wiki is so good.
My setup is very lightweight. I have only the minimal Arch installation with Xorg and xmonad, vim, RVM and Firefox. This distro is made for command line use and there it really shines.
that colorscheme looks familiar... I making my dotfiles public today and I've got a solarized themed xmonad/xmobar config up at https://github.com/altercation/es-etc .
The only difference with yours will probably be the tabbed decoration theming and xmobar theming. I'd love to see your xmonad.hs too if it's online somewhere.
Sorry to disappoint, but I really run xmonad with very minimalistic setup. I just need the different tiling modes, couple of hotkeys and xmobar for system information.
One thing that has kept me on Ubuntu family distros is font rendering. Ubuntu's patches for freetype, cairo, xft, etc are quite simply requirements for me for a desktop Linux.
Some distros have these by way of some guy maintaining his own set of patched packages. I have always been reluctant to rely on these.
I was thrilled when Linux Mint came out with Linux Mint Debian Edition, which is Debian + these font patches + some other Mint-y friendliness (but still mostly Debian).
The fact that Arch maintains the *-ubuntu family of patched packages means I just might consider using it, too.
I always had the opposite experience with font rendering. I always have to disable all hinting and turn on subpixel rendering to get results I like, since I prefer thicker glyphs that have more consistent forms, kerning and spacing at all sizes, even in print (ala Mac OS X) rather than having glyphs that have been forced into pixel boundaries and smushed closer together at smaller sizes for maximum glyph readability (ala Windows).
To me, the spacing and kerning of the fonts matter much more than the clarity of the individual glyphs. Seeing letters smashed together or with wide gaps between letters drives me insane...
How do you see it as a form of hinting unless we have different definitions of what hinting is?
As I would define it, hinting is the modification of the appearance of the font at smaller sizes, usually away from the actual outline design of the font and the original spacing, in order to make it fit into pixel boundaries for the purpose of clarity and readability. Used with subpixel rendering, you can get sharp, punchy text that is even more readable, but I wouldn't consider subpixel rendering by itself to be hinting.
If anything, unhinted subpixel rendering (where any auto-hinting has been disabled and all font hints are ignored) allows the font to look more like the intended outline design in spite of being rendered at a small size on a low resolution screen by boosting the horizontal resolution and interpolating the values between points where the outline crosses partial pixel boundaries. That is, it allows all the glyph metrics to remain intact at smaller sizes while improving readability, whereas the very notion of hinting implies that those properties have been intentionally modified for the purpose of readability.
It took me a while to get font rendering working the way I wanted in Arch, but it is possible (that's by way of encouragement... don't let this be a showstopper for you; I understand why it's important).
Infinality is great but even it requires some massaging to get it to the state I like (though of course now I have my configs pretty much ready to install off a repo).
The biggest draw of Arch for me is pacman. The system itself is incredibly simple (and incredibly fast), but more importantly, it's really easy to design and compile your own packages for it. To make a Debian package, you have to edit a bunch of control files, run a bunch of shell scripts, and then it packs all that up in some obscure cpio-based format.
With Arch, on the other hand, it's one program - makepkg - with only one or two "control files" (PKGBUILD and maybe an install script), and it generates a nice, easily-inspectable .pkg.tar.gz file. Plus you can find just about any package you could want in the AUR, and if not, you can find one that builds like it and then modify it to work with your package.
Nitpicking here, but it's RPM that uses the CPIO based format. Debian .debs are ar archives with control and data tarballs. The data.tar.gz is pretty easily inspectable.
Definitely agree. The AUR makes it really easy to manage software not in the official repositories- without that it becomes difficult to keep track of what's installed and often impossible to uninstall.
However, it would be nice if pacman used signed packages, especially in light of the recent kernel.org situation.
I use Arch not so much for the extreme customization aspect, but because if and when something goes wrong, the entire system is simple enough that I can usually fix it.
I've heard this argument multiple times that Arch Linux is what you make of it and it really teaches you Linux, but I'm getting older and trying out lesser distro's now. :) However while I admire its passionate community, I'm genuinely curious, how does it differ from Slackware? In the sense, how exactly does Arch differ from Slackware in terms of teaching you the guts of your own system?
As a former Slackware user myself, I was mostly impressed by ArchLinux's package management and the user-maintained wiki. As far as learning the guts of the system goes, I'd say that ArchWiki has become one of the best searchable references out there and is the main thing that separates Arch from Slackware.
I used Slackware for something like 13 years, and have been using Arch for maybe 2. If you'll allow me to post a link to my own stuff, I put together a blog entry about exactly this question:
Coming from someone who's specifically used both Slackware and Arch for a similar amount of time, I can say that Arch is more forgiving than Slackware, especially because of Pacman and their wiki. That said, though, if you /really/ know what you're doing in both Arch and Slackware, the experience should not be too different...aside from maybe the non-support of GNOME on Slackware.
For those who've never used it. You know all of the "boilerplate" frameworks that have been hot recently? HTML5 Boilerplate is one, iOS Boilerplate is another... well Arch is the Linux Boilerplate if there ever was one. It gives you only the essentials that you need and leaves the rest up to you.
While Arch isn't my primary OS at the moment, I really enjoyed the process of installing it. It felt like the software equivalent of building your own computer. It was very satisfying to learn about all the different parts and assemble those that I wanted,
I run arch on all my daily machines: two desktops and a laptop. Two things are brilliant about arch: 1) how easy it is to improvise a new package if what you need to install is not available in the repo 2) how you can run the last version of every software without the system ever breaking.
If you are a linux power user, I cannot think of a better distro than arch.
Package signing (via gpg) is being added in the forthcoming Pacman 4.0, so this won't be the case for much longer. It's already available in the testing repository, in fact.
That's really all there was to it. It was about... 2 years ago? I forget what exactly was broken about the packages. But the bug was from upstream and was known to the Arch Devs at the time they OKd the package built upon broken sources to roll out. It got pulled in by just updating the system. I asked what was going on and got directed to a message about it that I didn't fully understand and when I asked, I was told what I said above. As were many other users confused about the sudden breakage of X.
That wasn't really the first time I'd encountered ultra rude devs. I shortly after switched to Gentoo which I found to give the deep control that Arch did but amazingly was a system that worked properly and the community wasn't full of jerks. Hopefully the Arch community has changed, but I don't really intend to try and find out.
If I remember the same incident that you're talking about, it was a single file that had to be manually removed, and the fix was displayed right on the home page of http://archlinux.org for months..
The final solution could often need only minimal effort to carry out, but to debug and find out the problem, it takes much more time.
And the fix should come in through the right channel, like the package README or ChangeLog. Not sure if the home page of the whole distribution is the appropriate place for a fix like this.
The message should show up on screen when installing the package. If many packages are upgraded at once, a user could miss it. The output is also sent to /var/log/pacman.log
Helpful, friendly community. No-nonsense packaging. Easy setup and recovery. Been on Arch ever since moving up from Slack 10 years ago, now use it every day in a demanding IT workplace. Maybe it's not the distro for newbies - tis the distro for me and you <3 :)
ArchWiki has been among the most helpful guides in me getting an understanding of Linux. Also, seeing the latest AUR discussions about a package when pulling it down has been a lifesaver a few times.
I switched from Gentoo (4 years user) to Arch (now 4 years) and although the "close to the internals" philosophy are similar, which may make the two distros look the similar, the two are not comparable. Gentoo compiles from scratch by default, and is a real time sink in terms of maintainance. Gentoo is much more complex, I mean that for you as sysadmin of your own computer, the number of "free variables" to tune in gentoo is much greater than in Arch. Often, you end up over-optimizing your Gentoo box. In the end, more packages end up not working or not able to accept some input or plug-ins because of some compilation detail, for instance in my experience.
However, Gentoo is closer to LFS. I learnt the details of manual configuration and compilation of the linux kernel thanks to Gentoo. I learnt initrc, set up the logging system I wanted, etc... What I learnt using Gentoo lets me sail through Arch administration with zero hassle. After fixing my Gentoo box numerous times, I understand the compromise that is made in Arch between power, simplicity of administration and time consumed doing real work. Arch maintains a "pro" feeling, does not try to hide the internals, while keeping a minimal number of "free variables" for you to tweak. Does that make Arch primitive? Maybe, and in that case, I like primitiveness inmy distros.
I'm not about to remove Gentoo from my older servers, but I'm probably never going to install it again. Not having to compile everything is a huge win. The Arch build system is fantastic. It's easier to create/maintain your own packages. Arch's packages seem to be of higher quality, and more frequently updated. I've found the last few months of using Arch to be completely delightful.
I have a friend who uses Arch, she likes it a lot. I've been a Gentoo user for a number of years. From my outside perspective, Arch is similar to Gentoo in terms of configurability and power but without the beefy install process and it has a mirror of pre-built binaries for packages (you can compile from source if you want) where Gentoo typically only keeps binaries around for big things like OpenOffice, browsers, and proprietary drivers. Arch definitely seems more Linuxy though in the heritage of Debian, whereas Gentoo seems to take a bunch of ideas from the BSD folk.
One thing I love about Portage over pacman is the masking. Arch seems to take bleeding-edge a little less seriously.
With Gentoo you have to compile everything yourself (as much as I can tell).
With Arch, you _can_ compile everything yourself, but don't have to: official repos have packages precompiled, but the package source is there if you want something different.
On Gentoo, you can also use binary packages. You can setup some variable to some host which has all the binary packages for you. There are some public servers with x86 and amd64, although none are really official.
I've been using Arch for four or five years now. My current install has been around for three years, x86_64. In my experience, any software carried on i686 that built on x64 has always been in x64, though it's true that i686 used to get new builds first -- that has changed now and x64 usually gets new packages before i686.
Honestly I wouldn't be surprised to see i686 dropped completely in the next 1-2 years.
What do you mean by 'minimal'? If you're talking about wine and flash, there are 32 bit builds available to be installed in 64 bit.. But that's the way it has always been.
For the record Arch is one of the only distributions with sensible multiilib support. Most of the bigger ones require purity and force you to install a chroot if you want to run 32-bit applications. Fedora is multilib by default but it sucks because it always installs 32 and 64 bit versions of everything by default instead of reasoning that you'd be OK to use 64-bit most of the time by default.
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.