I had some outdated package that I wanted to update so I asked in the #arch irc room how to just update that one package. I was told upgrading a single package is generally a bad idea and its better to just update the entire system. I have had a server running Gentoo for ~5 years and I frequently upgrade single packages at a time so I saw no problem with this but ok, I'm not an Arch expert so I followed the #arch people's advice.
I invoked the upgrade command and I see it wants to upgrade the linux kernel to 3.2 and a bunch of other stuff. After the upgrade completes I rebooted the machine (or it rebooted itself, I forget). It wasn't able to boot up. I put in a rescue cd but I couldn't figure out what was wrong.
This is exactly why I don't do 'emerge world' in gentoo anymore. It has backfired on me more than 50% of the time (when I used to do it). I simply do not trust these bleeding edge distro people to get everything working all the time and I am annoyed at the zealots who constantly advise to just upgrade as if nothing could possibly go wrong.
Imagine your window manager relies on libX as a dependency. You update CoolNewApp, which relies on an updated version is libX. So it installs that from your repos and CoolNewApp works great. However, your WM needs an update to be compatible with the newer version of libX, and that update wasn't installed, so the next time you go to login, bam, broken system.
More hegemonic distro's like Debian trade some of that speed and freshness for a more hands-off experience. Nothing wrong with either!
I happily run dwm, and a handful of CLI tools. This minimalistic setup is enough for me - and seems to cut down on things breaking.
> This minimalistic setup is enough for me
I think that's a poor choice of words ;). It implicates that a GUI, or 'less minimalistic' setup is something 'more', something better. I think it's just something different, for differenet needs. Being very careful, maybe using less GUIs and handful of CLIs is an evolution (in certain areas). You can do more (stuff) with less (commands). But "great power, comes with great responsibility" = you can easily shoot yourself in a foot, and so it is not for everyone.
Ubuntu isn't around to cater to power users, the whole idea behind it is shipping a distro thats so easy your grandma can install and use it.
When I switched my parents over to Linux, I installed Mint, not Ubuntu. This was well before the Unity debacle, but even besides that, I'm glad I did. Mint looked familiar to them (coming from Windows), and while it may be heavily bloated from a software perspective (the stuff that makes Arch users cringe, since they ship everything by default to maximize configuration-free compatibility), it feels very lightweight from a user perspective - like what Windows might be like if they stripped out all of the stuff that people really don't care about.
If you want to get and keep non technical users consistency in terms of metaphors and the software itself is #1 thing.
Here is to another amazing 10 years for Arch as well as everyone working on other Linux distros. You are all pretty damn amazing in my opinion. Thank you for all you do and please don't stop =D
Thanks! I still feel good about being listed on the fellows page as a past developer. :)
A question for people using arch: If I install arch correctly and study the basics, will I need to spend time maintaining it? I like the idea of having a distro I can customize and play with to really learn how linux works, but when I want to stop messing about and get work done, it would be nice for it to be as stable as OSX. Unrealistic?
In contrast, on Debian, major changes to e.g. Gnome are mostly limited to when a new version of Debian comes out, and you get a lot of leeway as to when to upgrade to the new version, and in particular, sometimes you have the option of subscribing to just the security patches for your version of Debian -- an option that Arch Linux just does not offer at all.
And I got the impression that updates of Arch Linux broke things that required my manual intervention to fix more than updates of Debian did.
Still it is a very compelling distribution because of its "elegance".
I probably spend just as much time maintaining my OS X box as I did maintaining my Arch Linux box: e.g., when I upgraded from Leopard to Snow Leopard and from Snow Leopard to Lion, I had to install a bunch of stuff (a dict client, Gnu coreutils, Carbon Emacs, even wget IIRC) to get a comfortable environment, and the installation took a lot more time than it would have on a Linux distro. E.g., the upgrade to OS X 10.7.3 changed the behavior of sleep mode such that simply bumping the mouse wakes the system, which eliminates most of the value I used to get from putting the system to sleep, so now I have to ask on some forum for a way to revert to the OS X 10.7.2 behavior of waking only on key press or mouse button click.
Maybe it looks more 'frequent' but when it does so it's in a much, much more limited scope each time. It's more like small, discrete steps vs a whole batch at once.
> you have the option of subscribing to just the security patches for your version of Debian -- an option that Arch Linux just does not offer at all.
That's because Arch subscribes to the opinion that upstream knows best, and puts emphasis on as much vanilla as possible (which contributes to its overall simplicity, leanness and elegance). Hence security update means version bump from upstream. Contrast with Debian which actively back ports security patches to the pinned version in each release.
> E.g., the upgrade to OS X 10.7.3 changed the behavior of sleep mode such that simply bumping the mouse wakes the system, which eliminates most of the value I used to get from putting the system to sleep, so now I have to ask on some forum for a way to revert to the OS X 10.7.2 behavior of waking only on key press or mouse button click.
Ironically (although I did not notice that particular behavior myself) this would restore the pre-Lion behavior.
I update once a week, keep configs up to date with "yaourt -C" (yaourt is available in the AUR), and read archlinux.com prior to updates to avoid issues.
One caveat is that you need your /boot mounted if you keep it separate, or else anything that depends on linux-headers (like filesystem drivers :/) will break if there's a kernel update.
If you want stability along with the tweakability, go with Debian.
At least that's how it is for me. I know many people who have no problems with updates breaking stuff in Arch; maybe it's the fact that I'm using a full-blown KDE instead of a mere xmonad or such. But I wouldn't recommend Arch to anyone who expects stuff to work.
The only issues come up when some sort of breaking change is released, and in that case there is always an article right on the arch homepage for steps to migrate to the new package.
Yes, sometimes, like every few months or so, there is some maintenance to do, but only after manually initiating system updates. Never once have I come across a maintenance issue that didn't have a quick solution already discussed on the Arch forums or wiki.
I also want to add that while people always seem to talk about Arch breaking, it has hardly broken more for me that Windows of Ubuntu have in the same period of time. The advantage is that when Arch breaks, you fix it because you just tend to really learn how your system works when you use Arch, while in Windows and Ubuntu, I'd just reinstall usually.
I use Arch as my only OS, for day-to-day use, and it's perfectly stable when I'm not actively experimenting etc.
So using AUR introduces a bit of maintenance overhead in the sense that I spend more time reading the comments, checking the number of votes for an item, researching the dependencies that arise, etc. But I'm also happy AUR is there to supplement what is in the supported repos. That said, I've definitely had some MAJOR problems that I've had to work through using AUR packages.
I would say that your statement about putting in the time up front to learn how the system works in order to do relatively less system administration in the long run applies more to Gentoo than to Arch. I was a Gentoo user for several years before switching to Arch, and once you get all your configuration files set up on Gentoo, the system is rock solid. The only drawback is that you're compiling nearly everything from source based on your specific system configuration through make.conf and such, updates can take a while. However, the internal consistency and dependency resolution of emerge seems far, far better than pacman in my experience.
To me at this point Arch is as stable as OSX, and possibly even more so. I go weeks without reboots and my computer never slows down. I do updates almost every day, and most of the time have no problems. And I really appreciate the rolling-release paradigm. In fact, I'd be willing to bet that possibly sometime in the future, OSX could potentially go that route as well. It already seems like they're headed there in some ways.
This is the key differentiator between Arch and other distros (particularly, Debian): Arch wins when the user wants to modify the system in ways not intended by the maintainers of the distro. In contrast, Debian wins against Arch when the user never does anything that the maintainers of the distro did not anticipate that users would do. (Debian wins here because changes have gone through vastly more real-world testing and bug-fixing before hitting Debian stable than they have gone through before hitting the machine of the Arch user. Note that there is no stable version of Arch Linux.)
Also, try to use pacman as much as possible.
Meanwhile, other distros have gotten to the point of automatically installing the right debug symbol packages right from the crash reporter built into app suites like KDE's to generate useful backtraces.
It's just perfect for me. I love how easy it is to quickly build a new package (not that I need to write PKGBUILDS myself often, most things are available in the AUR)
Happy Birthday!
It does suffer the occasional dip into making things more complicated than they need to be, some element of the distribution straying towards the "SysV" darkside and away from the "BSD" ideal, or an upstream's configuration system just getting too insane to work around any longer, but everything always works back to some sense of balance after a few years. And it does feel like upstreams come around to the Arch way of thinking more often that the other way around.
I do wish it was a bit easier to automatically build or just download pre-made packages with some of the more popular compile flag variants, ports- or portage-style, but not so much that it casts a shadow on all the other benefits of Arch.
Still, it would be nice to be able to install a console vim with python and ruby interpreter support without having to install gnome too, or being able to install java on a headless server without having to stick half of X11 on there, or not having to install Apache because you want to change nginx's modules. It's always possible to change the PKGBUILD and recompile, but it seems like just changing one enable/disable switch to ./configure should be easier than it often is (vim is especially a pain to keep a custom PKGBUILD of, the ABS PKGBUILD seems to undergo massive revisions every few months).
But really the distribution is just great, the best out there. It lets you use pure Linux and avoid all the hoop jumping other distributions make you do in order to keep their package managers happy, while still giving you all the benefits you want from a distribution like automatic pre-compiled upgrades. And that's enough to make it the best balance of a distribution out there for me.
But yeah, for users willing to adapt themselves to a system, as opposed to adapting the system to their desires, the debian-based distros are probably the best Linux distros.
I have had other distributions autogenerate and overwrite hand-modified /etc files, and not just system-level ones but even daemon config files! It was something like the distribution required you to edit a distribution-unique "local changes" file for the daemon, not the daemon's actual config file, all so the package manager could incorporate parameters out of some sort of "friendly" config database into a new autoregenerated config file.
Many distributions require that you run a custom command just to do something as stupidly simple as create the /etc/localtime symlink, sometimes even dropping you into a GUI (to create a symlink! Arch is guilty of autocreating this symlink too, but at least it's controlled by a single ASCII line in the distribution's one main distribution-specific config file, rc.conf). Or some distributions have "SysV"-type init systems but require you to use a custom command to handle creating and deleting the symlinks for starting and stopping daemons. Again, usually to allow a package manager to alter those same files without having to figure out what a human has done to them. Those are the sort of "hoops" I'm thinking of.
My complaint's not that those systems exist for people to use, especially if it makes things easier for them, it's just that everyone is forced to use them. Those custom commands/the package manager integration is usually pretty delicate and almost always breaks completely if you try to do things the standard way, without going through them, or if they don't break they stay resilient by silently erasing your changes.
I'm sure there are great advantages to be had by committing fully to a given distribution's custom systems. People managing large or many systems probably find a lot of problems solved by the distributions' custom methods of doing things and the tight integration of those methods with their package managers (but I'm just running a laptop). I'm sure they're also just fine if you first learn how to do a specific configuration change on that distribution, and then don't even need to care what the real output of your manipulations of the distribution's configuration system is.
But if you already know the form of the change you want to happen, the exact line in a config file that you want changed or the exact flag passed to a daemon on startup, it's incredibly frustrating. You have to wade through all of a distribution's weird changes to a piece of software and its added config system layers just to figure out how to mangle your change in such a way that the distribution will unmangle it back into the exact form you could have just edited into the program's config file by hand in 3 seconds.
It's been a long time since I've tried Debian, I don't know what it's like in its modern form, how much you are required to actually cooperate with the distribution's unique systems or if you can ignore them without breaking anything. But the presence of debconf, alternatives, and update-rc.d all sound very discouraging.
[0] http://eddiedu.wordpress.com/2008/11/03/gentoo-wiki-gentoo-p...
Happy Birthday Arch Linux!!
Anyone running Arch on servers, how does it compare to Gentoo in your opinion?
As for my recommendation, imho you should learn the system you are going to use. If you want to learn Debian, use Debian (or Mint, or some other close Debian derivate). If you want to learn Arch, then use Arch. Every major distro can be poked and prodded, tweaked to no end, and you can look what happens under the hood.
But I do occasionally find it hard/difficult (from a mental POV), and I fall back on Fedora. I'll be a true *nix guy when I can stop doing that. :)
