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!
After a google search you read, "bar.conf needs the --force switch to be altered".
So you're like, fine..
foo -abc --force
"Press <enter> to get in the shell"
Me pressing enter.. and even the keyboard isn't working.
That's what happened.
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.
I love Arch as much as the next guy, but their default font experience is awful. The biggest headache of using it was constantly fighting/maintaining patched cairo/freetype from AUR (because they'd occasionally conflict with a newer version of some other package). And on top of that you'd have a ton of other packages with baked-in broken fonts like Firefox, xulrunner and Open Office.
When it comes to fonts and text rendering, all users firmly belong into two groups: the 1st group would post a screenshot of their screen where the 'd' and 'p' are rendered with double line thickness at the tip of their curves, and then claim "my fonts are fine". The 2nd group would consider that unusable.
What Ubuntu excelled at (and still does) is to bring Linux to the 2nd group of people, which is a lot larger than the 1st one. All Canonical's questionable achievements like Unity, upstart and Bazaar have been easily eclipsed by them noticing and taking care of the elephant in the room: readability of text on user's screen. They fixed it by patching freetype, providing sensible defaults for fontconfig and by developing an excellent set of default fonts.
Sorry for the long rant, this is Arch birthday after all. Arch rocks! Long live Arch! :)
Get Ubuntu’s /etc/fonts directory, remove or rename your own /etc/fonts, and put Ubuntu’s in its place.
I’ve been using this hack in Debian Sid, I have applied it to several machines, and it always gets the job done.
Apologies for veering off topic.
I've used these successfully on Debian, Arch and FreeBSD, and always had great results.
Below are two examples of "looks fine":
Case #1. Thin non-antialiased fonts sirca Windows 95:
Case #2. Default Arch anti-aliasing with poor quality:
Just look at "archlinux" rendering in the URL.
And this is how Ubuntu looks by default:
Notice the excellent typeface they developed themselves, consistent and high-quality anti-aliasing, etc. This looks gorgeous on a modern high-DPI screen. Group #1 thinks this "looks blurry" and Arch works fine for them.
Simply put, It is technically impossible for Arch to provide you with the best font experience because their freetype is compiled with, hm... parts of code removed. The parts that are responsible for hinting, bytecode interpretation and subpixel rendering. And the way they ship Open Office and Firefox (well, last time I checked) makes their fonts non-configurable at all, since they ignore system/global version of freetype.
I have probably worked more for my fonts than for anything else about my system, on any linux distro I've tried (on OSX, the rendering's fine but the actual font choices kind of blow...there I have other problems that consume much more of my time than the fonts).
On arch, I install the infinality patched freetype stuff from the AUR, set some preferences in .Xresources, install the fonts I like, and I'm good to go. On any other distro, installing patched freetype and overriding the distro-maintained font configuration invariably leads down the path of madness. I don't run the software you mention, but I have never seen an incompatibility issue.
You mention ubuntu. Honestly, its defaults are fine. That is, as long as you never try to use a different font, or install software that ignores the default, or try to use an alternative program like rxvt-unicode instead of gnome-terminal, or visit a web page that specifies its own font, or have a lowish dpi screen. Ubuntu's great if you stay inside the garden. I just barely don't, but it's enough to piss me off.
Also, I happen to not use openoffice or firefox, so I haven't run into the problems you describe. But I expect that they would look great on my system, because the only version of freetype I have installed has patches that do what I like.
EDIT: here's my screenshot with a 'd' and a 'p'. looks fine to me: http://imgur.com/UZJ17
I proved my point right there. That's what I've been doing too and maintaining AUR-sourced patched core packages like that has been problematic: every once in a while you'll get a part of Gnome or something else demanding a higher version of freetype (which your patched version doesn't provide) and it either halts your update or forces you to get plain vanilla freetype.
And you haven't addressed the case of packages that don't use system cairo/freetype. BTW the rendering on your screenshot is excellent. Also I feel that this discussion is somewhat misplaced. :)
Yeah, probably. :)
P.S. I am not bashing arch linux, I am just pointing out that the default Arch linux does not even have a ui and you can not compare this to Ubuntu.
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.
Yes it might be more frequent, yet each time it is of a more limited scope since it concerns a single, maybe two packages. Following the news and maybe the forums helps a lot. Example regarding the scope: I upgraded some machines Ubuntu 11.04 to 11.10, and so much breakage occurred that the machines required such an extend of work that they simply were declared unrecoverable and reinstalled from scratch.
> use Debian Testing
In the months following a release, Debian testing essentially == Sid, and breakage is infamous.
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)
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.
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. :)