The downsides of Arch ?

wantilles · 2007-04-02 14:30:42

Having used Gentoo for 3 years, and Debian Unstable for about one and a half, I am a newbie to Arch.

I've been "playing" with it for about 10 days now, and I might say I like it already.

True, there are some drawbacks but I think the good elements far outweight the others.

Some people here mentioned that many packages are large.

True. However since the community is small, and the developers are few in numbers, it is a small price I am more than willing to pay in order to have the latest and greatest so soon after upstream release -> we now have Gnome 2.18 -> who else does? Nobody (in Gentoo it is still hard-masked).

So, I am sticking with Arch.

The only drawback I found, is that it is a little immature for the x86_64 architecture - which is understandable since it only recently supported it.

PS: Man pages are essential and - in my humble opinion - should not be removed.

Jungian · 2007-04-02 16:27:18

wantilles wrote:

Having used Gentoo for 3 years, and Debian Unstable for about one and a half, I am a newbie to Arch.
True. However since the community is small, and the developers are few in numbers, it is a small price I am more than willing to pay in order to have the latest and greatest so soon after upstream release -> we now have Gnome 2.18 -> who else does? Nobody (in Gentoo it is still hard-masked).

Ubuntu, Frugalware and several other distro's.

Gentoo will probably make it non-hardmasked non ~ within a few years. It lost its edge ages ago

Last edited by Jungian (2007-04-02 16:28:03)

Alejandro Nova · 2007-04-02 16:45:52

Downsides of Arch (minor quirks).

1. Please, make the ArchWiki access more clear. I can only reach easily a handful of articles, and I miss a general index.
2. Please, upgrade your Compiz guide to latest Compiz. If you are human-resource-limited, wait until Coral/Blitz/whatever (the names discussed for Compiz+Beryl fusion)
3. Please, increase the number of games in your official repos

None of these is really important. Good work, guys. The community is small, but strong.

Weeks · 2007-04-02 18:00:07

I'd say 1) updating your system can bring it to a halt if you fail to read and understand the implications of some kernel, udev and boot manager messages 2) things don't work out of the box unlike ubuntu. There's also the issue of QA, but I've not encountered any difficulties as yet, however I've not really compared arch packages against packages built for other distributions. And although 2 is a disadvantage I can customise the system to my own requirements, which is an advantage -- it cuts both ways. I basically have few qualms, and the qualms I have are with the Linux constellation of programs and sub-systems than with the distribution.

[Edit] and yes I agree, AUR needs to be integrated into pacman...

Last edited by Weeks (2007-04-02 18:03:56)

jf/ · 2007-04-03 20:15:20

baze wrote:

as much as i like the simple bsd scripts, i'd prefer if arch would switch to upstart in the future. i really like the much more flexible system that upstart provides and imho upstart is the only modern approach which reflects what can happen to modern systems. frugalware is switching to upstart aswell, so it's not only ubuntu
i don't know if the arch devs consider switching in the future, but i'd very much appreciate it.

thank u for making a suggestion, but not really justifying it - nor even bothering to give a proper url at all. http://upstart.ubuntu.com/. Now if only that site (or somebody else) could do a better job of answering what upstart is really about and that oh-so-crucial "why upstart" question....

jf/ · 2007-04-03 20:16:54

Weeks wrote:

I'd say 1) updating your system can bring it to a halt if you fail to read and understand the implications of some kernel, udev and boot manager messages

ditto. I've had stuff like that happen to me in the past, which is why once i've got my basic system working, i'm very hesitant to want to do a 'pacman -Syu'. I just dont have all the time in the world to deal with the latest intricacies of whatever fantastic new trial (and i say this bluntly) the kernel developers have thought of. Although this is really a gripe against the kernel developers, it is, in a sense, the downsides of using a rolling-release distro as well. Once a version has gone past, u may have to upgrade quite a number of packages (and pray sincerely to God that u dont hit into this "upgrade kernel problem") in order to get to ur "desired new app that i just found out that i now or want", or even ur entire system. But then again, there is a solution as well - keep ur ABS synched, and then if the version of the package u need has been deleted from ur spanking mirror, just conjure it up using 'makepkg', and then install....

ditto about the large number of package dependencies as well (think mplayer), and about the info pages (although i've managed to survive thus far without the info pages - but that is not to say that really, installing the info pages as well would be good).

Weeks · 2007-04-03 20:45:44

jf/ wrote:

Weeks wrote:
I'd say 1) updating your system can bring it to a halt if you fail to read and understand the implications of some kernel, udev and boot manager messages
ditto. I've had stuff like that happen to me in the past, which is why once i've got my basic system working, i'm very hesitant to want to do a 'pacman -Syu'. I just dont have all the time in the world to deal with the latest intricacies of whatever fantastic new trial (and i say this bluntly) the kernel developers have thought of.

To be fair, I've just placed kernel26, udev, grub and klib* in the IgnorePkg section in pacman.conf. That could either be explained better or those packages could be placed there by default.

jf/ · 2007-04-03 20:50:44

Weeks wrote:

To be fair, I've just placed kernel26, udev, grub and klib* in the IgnorePkg section in pacman.conf. That could either be explained better or those packages could be placed there by default.

ah, thanks for that info!!! i guess that would be another (and probably easier) way of doing it...

deficite · 2007-04-04 04:08:52

sendmail, httpd, smtp-vilter, spamd, thttpd,

http://www.google.com

emphire · 2007-04-04 07:37:27

I think the documentation/wiki needs a serious overhaul. Some of it is great. Some of it is incomplete, some of it is out of date. Some of it is missing altogether. It would be nice to have a main page that has a more linear walkthrough of the articles (the freebsd docs are a great example). It would be nice to see it progress from install to config to costomization/tweeks to installing apps to contributing documentation/wiki articles and packages.

anykey · 2007-04-04 10:00:43

The day arch strips manpages will be the day it is no longer usable by me. I use this when I am working, mostly chapters 2 and 3.

One could argue whether these "developer's man pages" are really belonging to this discussion; I just wanted to point out there are serious uses for man beyond just application documentation.

I cannot keep every function in my mind.

TomE · 2007-04-04 17:55:08

baze wrote:

as much as i like the simple bsd scripts, i'd prefer if arch would switch to upstart in the future. i really like the much more flexible system that upstart provides and imho upstart is the only modern approach which reflects what can happen to modern systems. frugalware is switching to upstart aswell, so it's not only ubuntu
i don't know if the arch devs consider switching in the future, but i'd very much appreciate it.

Can someone tell me the point of upstart? What can it do that can't be done with a udev rule?

Weeks · 2007-04-04 19:57:03

TomE wrote:

baze wrote:
as much as i like the simple bsd scripts, i'd prefer if arch would switch to upstart in the future. i really like the much more flexible system that upstart provides and imho upstart is the only modern approach which reflects what can happen to modern systems. frugalware is switching to upstart aswell, so it's not only ubuntu
i don't know if the arch devs consider switching in the future, but i'd very much appreciate it.
Can someone tell me the point of upstart? What can it do that can't be done with a udev rule?

I looked at it a while ago and I do like those kinds of boot systems. Basically, it's asynchronous booting instead of synchronous. For instance when I load arch at home it takes ages to finish the "network" stage (because I'm not connected to the internet at home). If I could make it so the login prompt came before the "network" stage it would reduce my boot time substantially.

There are many different asynchronous systems. Upstart was the one developed by ubuntu.

raymano · 2007-04-04 20:19:59

Weeks wrote:

TomE wrote:
baze wrote:
as much as i like the simple bsd scripts, i'd prefer if arch would switch to upstart in the future. i really like the much more flexible system that upstart provides and imho upstart is the only modern approach which reflects what can happen to modern systems. frugalware is switching to upstart aswell, so it's not only ubuntu
i don't know if the arch devs consider switching in the future, but i'd very much appreciate it.
Can someone tell me the point of upstart? What can it do that can't be done with a udev rule?
I looked at it a while ago and I do like those kinds of boot systems. Basically, it's asynchronous booting instead of synchronous. For instance when I load arch at home it takes ages to finish the "network" stage (because I'm not connected to the internet at home). If I could make it so the login prompt came before the "network" stage it would reduce my boot time substantially.
There are many different asynchronous systems. Upstart was the one developed by ubuntu.

Put an @ in front of it in rc.conf DAEMONS= line

DAEMONS=(... @network ...)

emphire · 2007-04-04 21:56:53

raymano wrote:

Put an @ in front of it in rc.conf DAEMONS= line
DAEMONS=(... @network ...)

DAEMONS=(... @net ...) is probably a BAD idea if you have any services that depend on net. There is no way to know if it will finish loading before the daemons that require it start loading. Upstart and init-ng would take care of this and start all the services that require net as soon as net (and any other required daemons) are finished loading.

raymano · 2007-04-05 04:09:57

emphire wrote:

raymano wrote:
Put an @ in front of it in rc.conf DAEMONS= line
DAEMONS=(... @network ...)
DAEMONS=(... @net ...) is probably a BAD idea if you have any services that depend on net. There is no way to know if it will finish loading before the daemons that require it start loading. Upstart and init-ng would take care of this and start all the services that require net as soon as net (and any other required daemons) are finished loading.

You can accomplish what upstart does for service dependency with a combination of @ and order of services specified in DAEMONS.

Let's say x,y,z depend on network but a,b, and c don't, and z depends on y. Here's how it's done:

DAEMONS=(@a @b @c network @x y @z)

Last edited by raymano (2007-04-05 04:26:42)

emphire · 2007-04-05 05:14:45

raymano wrote:

emphire wrote:
raymano wrote:
Put an @ in front of it in rc.conf DAEMONS= line
DAEMONS=(... @network ...)
DAEMONS=(... @net ...) is probably a BAD idea if you have any services that depend on net. There is no way to know if it will finish loading before the daemons that require it start loading. Upstart and init-ng would take care of this and start all the services that require net as soon as net (and any other required daemons) are finished loading.
You can accomplish what upstart does for service dependency with a combination of @ and order of services specified in DAEMONS.
Let's say x,y,z depend on network but a,b, and c don't, and z depends on y. Here's how it's done:
DAEMONS=(@a @b @c network @x y @z)

Add a few more daemons and you might have:

DAEMONS=(@a @b network @n1 @n2 chrootd @c1 @c2)
where:
- 'n1' and 'n2' require 'network'
- 'c1' and 'c2' require 'chrootd'
- 'chrootd' and 'network' require nothing

Now either chrootd (and c1 and c2) are going to have to sit and twiddle their thumbs while 'network' loads when they don't even need it. You could flip it around so chrootd (and c1,c2) start first, but then network (and n1,n2) will be waiting for 'chrootd' when they don't need to.

raymano · 2007-04-05 05:46:16

emphire wrote:

raymano wrote:
emphire wrote:
DAEMONS=(... @net ...) is probably a BAD idea if you have any services that depend on net. There is no way to know if it will finish loading before the daemons that require it start loading. Upstart and init-ng would take care of this and start all the services that require net as soon as net (and any other required daemons) are finished loading.
You can accomplish what upstart does for service dependency with a combination of @ and order of services specified in DAEMONS.
Let's say x,y,z depend on network but a,b, and c don't, and z depends on y. Here's how it's done:
DAEMONS=(@a @b @c network @x y @z)
Add a few more daemons and you might have:
DAEMONS=(@a @b network @n1 @n2 chrootd @c1 @c2)
where:
- 'n1' and 'n2' require 'network'
- 'c1' and 'c2' require 'chrootd'
- 'chrootd' and 'network' require nothing
Now either chrootd (and c1 and c2) are going to have to sit and twiddle their thumbs while 'network' loads when they don't even need it. You could flip it around so chrootd (and c1,c2) start first, but then network (and n1,n2) will be waiting for 'chrootd' when they don't need to.

Since most rc scripts start in a few seconds and if they don't the rc script has not been implemented correctly, I think the current @ method satisfies most rc script needs. That said, your example could be satisfied with a simple change to the base rc scripts (e.g. /etc/rc.sysinit) to accommodate the use of parentheses instead of using upstart in Arch:

DAEMONS=(@a @b @(network @n1 @n2) @(chrootd @c1 @c2))

phrakture · 2007-04-05 06:22:07

raymano wrote:

your example could be satisfied with a simple change to the base rc scripts (e.g. /etc/rc.sysinit) to accommodate the use of parentheses instead of using upstart in Arch:

If it was a "simple change", it'd probably be done.

Here's something to gnash on:

$ x=(a b c @(d e f))
$ echo $x
a
$ echo ${x[3]}
@(d e f)

#looks good, right?

$ echo -e "#!/bin/bash\nx=(a b c @(d e f))" > script
# this is the EXACT same command as above
$ chmod +x script
$ ./script
./script: line 2: syntax error near unexpected token `('                                                                                                     │
./script: line 2: `x=(a b c @(d e f))'

I conclude it's a bash bug

phrakture · 2007-04-05 06:28:06

Alternatively, the following syntax would be a 2 line addition to rc.multi:

DAEMONS=(foo bar @baz @abc @"def xyz blah blah" foo)

But that looks a tad ugly

raymano · 2007-04-05 08:48:21

phrakture wrote:

Alternatively, the following syntax would be a 2 line addition to rc.multi:
DAEMONS=(foo bar @baz @abc @"def xyz blah blah" foo)
But that looks a tad ugly

For sake of prettyness and keeping the format below in /etc/rc.conf:

DAEMONS=(foo bar @baz @abc @(def xyz blah blah) foo)

at top of /etc/rc.multi replace

. /etc/rc.conf

with

# Create and source a temporary rc.conf without the line that sets DAEMONS 
cat /etc/rc.conf | grep -v "^ *DAEMONS *=.*$" > /tmp/tmprc.conf
. /tmp/tmprc.conf
rm /tmp/tmprc.conf
# Convert the DAEMONS from DAEMONS=(a b c @(x y z) e f g) to DAEMONS=(a b c @"x y z" e f g)
DAEMONS="`cat /etc/rc.conf | grep "^ *DAEMONS *= *" | sed -e's/DAEMONS *= *//' -e's/(/\"/g' -e's/)/\"/g' -e's/ *\"/(/' -e's/\" *$/)/'`"

Add your 2 lines of code to rc.multi and you are done.

I know it's a hack but it will work. A better approach would be to write a simple state machine which would allow multi-levels like this:

DAEMONS=(foo bar @baz @abc @(def xyz @(blah blah @moo) doo) foo)

Wait a minute... This is starting to look familiar... Oh yeah! It's LISP

We don't need no stinkin' upstart.

Last edited by raymano (2007-04-05 09:08:23)

Weeks · 2007-04-06 03:03:27

LISP sweet LISP.

gnud · 2007-04-12 11:14:31

Just to revive a nearly dead thread:
How about something like

net_daemons=(network @httpd @sshd)
DAEMONS=(syslog crond *net_daemons @x @y @z foo @bar)

rbrownclown · 2007-04-13 14:23:02

The Wiki needs better organization. Particularly in post-installation tips.

sweiss · 2007-04-22 18:43:55

A thing I personally dislike is the documentation stripping. I enjoy reading documentation for certain software when my internet connection is lacking. I also do not much approve of the "the internet is more up-to-date", as software is distributed with its proper documentation.

I'm really into the idea of having a [doc] repository.

Also, as for the daemons, I also had the idea that it might be nice to borrow some concepts from upstart and the like. By the way, is there a way to configure different daemons array for different runlevels?

Arch Linux

#51 2007-04-02 14:30:42

Re: The downsides of Arch ?

#52 2007-04-02 16:27:18

Re: The downsides of Arch ?

#53 2007-04-02 16:45:52

Re: The downsides of Arch ?

#54 2007-04-02 18:00:07

Re: The downsides of Arch ?

#55 2007-04-03 20:15:20

Re: The downsides of Arch ?

#56 2007-04-03 20:16:54

Re: The downsides of Arch ?

#57 2007-04-03 20:45:44

Re: The downsides of Arch ?

#58 2007-04-03 20:50:44

Re: The downsides of Arch ?

#59 2007-04-04 04:08:52

Re: The downsides of Arch ?

#60 2007-04-04 07:37:27

Re: The downsides of Arch ?

#61 2007-04-04 10:00:43

Re: The downsides of Arch ?

#62 2007-04-04 17:55:08

Re: The downsides of Arch ?

#63 2007-04-04 19:57:03

Re: The downsides of Arch ?

#64 2007-04-04 20:19:59

Re: The downsides of Arch ?

#65 2007-04-04 21:56:53

Re: The downsides of Arch ?

#66 2007-04-05 04:09:57

Re: The downsides of Arch ?

#67 2007-04-05 05:14:45

Re: The downsides of Arch ?

#68 2007-04-05 05:46:16

Re: The downsides of Arch ?

#69 2007-04-05 06:22:07

Re: The downsides of Arch ?

#70 2007-04-05 06:28:06

Re: The downsides of Arch ?

#71 2007-04-05 08:48:21

Re: The downsides of Arch ?

#72 2007-04-06 03:03:27

Re: The downsides of Arch ?

#73 2007-04-12 11:14:31

Re: The downsides of Arch ?

#74 2007-04-13 14:23:02

Re: The downsides of Arch ?

#75 2007-04-22 18:43:55

Re: The downsides of Arch ?

Board footer