I suppose that your points are valid, especially if one is used to a "stable" distribution. I've been using Arch for nearly a year now, and have come to really love it.

The "rolling-release" process means that the distribution is alway bleeding edge, however this can mean problems in some cases - for example your udev problem. If the machine is left for too long without being updated, then it becomes a hassle to update, since binary compatibility often breaks, and applications are built against different library versions. I admit, that it can be very annoying, but such is the life of someone that needs to have it all :).

The "simplistic startup" issue i think is an indication of the model of Arch Linux - it provides the user with an albeit steep, but very valuable learning curve. It lets the user choose exactly what to do.

I've never experienced package docs being deleted, nor the UID problem, but I'll admit that i've never really cared for these things :)

Check the makepkg man page about doc deletion:

"Once the package is successfully installed into the package root, makepkg will remove some directories (as per Arch Linux package guidelines; if you use this elsewhere, feel free to change it) like /usr/doc and /usr/info."

On the other hand, I don't believe in learning through fixing something that comes broken by default, sorry.

What's the value of figuring out if hal starts before dbus or not? I see none, really.

At least no value bigger than what you would get by putting a comment saying "start this after that and those".

Specially if the docs that explain whether dbus starts after or before hal are deleted ;-)

1. see above comments

2. It is assumed that critical help information can always be found in the man pages. Any other information can be found online.

Some packages don't have man-pages. I don't find this to be ArchLinux's fault. Other packages have pretty big documentation - such as Qt4 (see AUR). Docs can be found in other packages, built with special makepkg options, stopping makepkg from removing docs.

3. Example:
DAEMONS = (... dbus hal @kdm @crond ...)
DBus and Hal will be started in this order, Hal after DBus finished starting. KDM and cron will be started in that order, but in background.

My DAEMONS line which works perfectly:
DAEMONS=(@gensplash @syslog-ng dbus @hal network portmap !fam @kdm @crond samba @lisa @alsa @schedtoold @sshd)

Personally, I don't think you need to set more precisely the order the services are started (I mean, to set individually for each init level).

4. Small number of developers => the counted official packages is small. AUR was created because of this.

5. I think there is some wiki page describing the already used UID in the packages.

Iceram:

So, if you install offline, you are SOL about the docs. That is evil, and means the software as distributed is crippled.

You can rationalize saying everything should be in man pages: sorry, man pages are an ancient, and not very good, way to offer documentation.

3. I **know** how it works. However, if you install hal and dbus, it will not put anything in DAEMONS, so you have to guess where to put them in yourself.

Can I do it? Sure. Is it good? Nope.

4. I am fine with that. I can package anything I need myself ;-)

5. It doesnt matter. If for whatever reason you have UID 89 taken, the mysql server package will break in strange ways. In no other distro does that happen (that I know of).

You know, rationalizing criticism as not a problem is not really a very healthy attitude.

It may not be a problem to you. It may not even be a problem for me. But it is not good, either.

I miss the doc, especially the info pages. I wish it were easy to compromise on this and have two packages. One would be the package as it exists now (emacs sans info pages, for example), but then there could also be a -doc package which would install the info|/usr/share/doc|whatever documentation for that package. I think Debian has a model like this (install abiword then choose if you want to install abiword-doc).

In some cases, I don't want the doc, or I don't want it any longer, so having the option to not install it is nice, but having the option to install it and later remove it would be better IMHO.

Still, I like arch quite a bit. It boots fast, has a good selection of packages, I can use abs fairly painlessly to create my own packages if/when I need to, I like the initialization process. For me it's a good distro. YMMV.

1. Oh, about docs, I forgot to mention one documented thing :) You'll find in the Arch Documentation that Arch is recommended to people with (almost) permanent Internet connection, since the rolling release system - therefore, docs should not be a problem.

This is an assumption for every Arch user (starting from the Arch philosophy page) so I find it pretty natural to search the web for documentation.

3. It must have been me using Arch for more than 2 years... I have forgotten if hal and DBus are installed by default or not. I remember though that in the Arch KDE Wiki page you have the exact order they need to be.

5. For some reason, I find it pretty hard that someone (=not a packager) will add a user with UID

[for an unknown reason reason, my previous comment was trimmed //
Found the reason: It seems that the "less than" sign breaks the comments]

5. For some reason, I find it pretty hard that someone (=not a packager) will add a user with UID (less than) 100 - therefore I find such information useful only to packagers. Anyhow, maybe the procedure used for adding users when installing packages is not the best - a bug report could probably improve the situation overall, in all packages doing this.

It might be the fact that I've been using Arch for more than 2 years that I grew to live with many of the faults which hit the first-time user - everything makes sense to me, even though for new users might be annoying. The Arch philosophy page in the wiki should cover everything.

Overall, it makes a pretty good distribution, very easy to manage from my point of view (except for the upgrades which require lots of attention - but I choose to be bleeding edge)

this is really interesting viewpoint on the subject i might add

Well, the write-up is truly the freshest on this laudable topic.