You are not logged in.
Ubuntu (no troll intended) is doing this and Debian has been using /bin/sh for long time, which you can link to dash when you install it, and I think it's a good idea.
dash is "A POSIX compliant shell that aims to be as small as possible", it's faster than bash and eats less ram.
It would be a good choice for boot and administration scripts, and I think it would fit the Arch philosophy.
The drawback of linking /bin/sh to dash is that some scripts in the sources would break because they *incorrectly* use "#!/bin/sh" but require bash, and would need fixing (nothing more than a sed line, but still some extra work for packagers).
A working compromise would be using "#!/bin/dash" in boot scripts and leave /bin/sh pointing to bash.
P.S. For those who are guessing, it would be a bad choice as login shell, because it doesn't fit an interactive use.
What do you think?
Offline
EmaRsk,
You might be interested in this: http://bbs.archlinux.org/viewtopic.php?id=40479 . There was a discussion about dash a few months ago.
Offline
D'oh! I missed that one... ![]()
Ahem...
Hey! Look! A three-headed monkey! </me runs away> ![]()
Offline
It's actually not that easy. rc.conf uses bash arrays, so we cannot switch to dash without changing that.
Offline
It's actually not that easy. rc.conf uses bash arrays, so we cannot switch to dash without changing that.
I just sent a patch to Thomas fixing this issue.
It does require that you replace the bash arrays in order to use /bin/sh -> dash but as long your /bin/sh -> bash the current format of rc.conf will work.
so in order to use dash you will need to use the style:
DAEMONS='syslog-ng network net-fs crond'-nc
Offline
phrakture wrote:It's actually not that easy. rc.conf uses bash arrays, so we cannot switch to dash without changing that.
I just sent a patch to Thomas fixing this issue.
It does require that you replace the bash arrays in order to use /bin/sh -> dash but as long your /bin/sh -> bash the current format of rc.conf will work.
so in order to use dash you will need to use the style:
DAEMONS='syslog-ng network net-fs crond'-nc
Try rolling this "simple" change out to our entire userbase. /bin/sh pointing to bash doesn't actually fix anything, and won't be any faster, which is the only real reason to go to dash. I stirred the pot on this near the end of last year, but I realized rc.conf was going to be a pretty big hurdle that we couldn't easily work around.
Offline
DAEMONS='syslog-ng network net-fs crond'-nc
Try rolling this "simple" change out to our entire userbase.
If ubuntu and gentoo could do it, why shouldnt Arch be able to? I mean, Arch doesnt have that much bigger userbase than gentoo and Ubuntu. ![]()
https://wiki.ubuntu.com/DashAsBinSh
/bin/sh pointing to bash doesn't actually fix anything, and won't be any faster, which is the only real reason to go to dash.
It is only there for the rollout/switch. It will need to be made annoucements etc. Once people have changed their rc.conf then they can point /bin/sh to dash.
After next release there could be a warning on screen: "Looks like rc.conf is still old style. please upgrade it"
I stirred the pot on this near the end of last year, but I realized rc.conf was going to be a pretty big hurdle that we couldn't easily work around.
gentoo had a similar change recently. Or, the change have been goin on for some time now.
This kind of changes does not happen over the night but it is possible.
But the longer you wait the bigger issue it becomes (assuming Arch userbase is growing).
Offline
I'm really interested in the idea but I think its not very KISS. I remember reading those topics a long time ago and the discussion returns to how hard it would be to implement ie the advantages are not worth the cost of implementation. If its not broken, why fix it. Especially if the results are not exactly proven yet.
However, I'm still really interested. Maybe if you could post some good boot testing? I would be interested in a bootchart of your system before, and then with dash.
Offline
If ubuntu and gentoo could do it, why shouldnt Arch be able to? I mean, Arch doesnt have that much bigger userbase than gentoo and Ubuntu.
Agreed. Just adding a message in post install telling the users to update their rc.conf would probably be enough. Maybe telling them to run something like that if they don't want to bother, too:
sed -i "s/=(\(.*\))/=\'\1\'/" /etc/rc.confLast edited by catwell (2008-06-20 15:09:07)
Offline
Agreed. Just adding a message in post install telling the users to update their rc.conf would probably be enough. Maybe telling them to run something like that if they don't want to bother, too:
sed -i "s/=(\(.*\))/=\'\1\'/" /etc/rc.conf
Obviously, you arn't a regular on the irc channel. We do get severa people a day with "problems" just cause they don't read the pacman output, and that's when there is no big changes. Last time there was some major change that forced you to take action, if you didn't want to have a broken system, we got 100+ people a day asking the exact same question, about the exact same problem. All because they didn't read the post_install() message and/or the mainsite.
You seem to be missing the fact that users are: dumb, ugly, unable to read and lazy.
I can see #!/bin/dash initscripts as an optional pkg for those who want it, but it will only cause unnessesary problems if it get pushed as default.
The main reason atm for the slow boots are not bash, but udev and some daemon handeling. (ime)
Edit: Keeping a dash branch of the initscripts in git, combined with a custom repo with pkg's would be realy easy to set up, if anyone care enough to bother.
Last edited by Mr.Elendig (2008-06-20 16:31:20)
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
You seem to be missing the fact that users are: dumb, ugly, unable to read and lazy.
Arch Linux users fully manage the system on their own. The system itself will offer little assistance, except for a simple set of maintenance tools that are designed to perfectly relay the user's commands to the system.
The user-centric design also implies a certain "do it yourself" approach.
By the way I do idle on IRC 24/24 even though I don't read what's said there most of the time, and I am well aware that some users don't read the output of pacman, but they should just learn to do so. Considering users to be stupid leads to a Ubuntu-like way of doing things.
Offline
I think most of us are careful, we specifically write #!/bin/bash and not just /bin/sh, unlike Ubuntu/Gentoo. An upgrade of the rc scripts could come along with the porting of those very scripts to dash; we keep it system/rc-only; directly point to interpreter #!/bin/dash. It's the user's fault if the post-install message about merging the rc scripts is not read, or there could be a news highlight a week before it is implemented.
edit: if the gain is insignificant, though, there's no point.
Last edited by schivmeister (2008-06-20 16:53:23)
I need real, proper pen and paper for this.
Offline
I converted the init scripts on a test box to dash just for kicks one weekend.
I noticed little speed improvement on the system I was using for a test. Furthermore, it was quite a bit of work (some bugs I hadn't fully ironed out yet), and there was less flexibility due to dash's more limited scriptability. I had some issues with bash daemon control scripts sourcing dash variable scripts, and losing environment settings (weird). I didn't look too far into it though, as the benefit at the time didn't warrant continued work on it. I was able to boot a system, and most things worked.
The real benefit to using dash would be the fact that dash is statically compiled (more robust with regard to underlying system lib issues) and smaller (reduced memory footprint). A cost benefit analysis doesn't really make a strong case for the benefits of moving to dash against the losses with regard to flexibility.
I bet you would get a much larger overall speed benefit from optimizing the udev start scripts.
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Eliott is correct. If you want to completely shirk any module blacklisting, you can replace all instance of 'load-modules.sh' with a direct call to modprobe in the udev rules. That will give you the most speed improvement. WARNING, PROS ONLY. This is outlined somewhere in the wiki, too.
The simple fact is, if you want performance gain, you need to do an analysis first - most startup time is taken by udev. That is what should improve first, and where you will see the most gain.
Offline
I doubt that dash vs. bash in real life applications even matters in terms of speed. Echoing nothing to nothing is a useless benchmark. And it's not because some other distro's are doing it, we should do it too. Would you jump off a cliff because the guy next to you did? There's nothing wrong with bash, it's fully featured and works as it should, period. People seem to be obsessed with bootup time. Well guess what, no matter which software you use, I'll doubt you'll even be able to shave off 5 seconds. If you really want your computer to boot faster, get a hard disk with lower latency, oh hell get a new computer all together. Or for once in your life spend time on things that are really important, instead of wondering "what if my computer booted 5 seconds faster...".
:?
Offline
What if.. what if..
Anyway, I agree. Actually I think "linux people" in general are too obsessed with speed / performance, usually placing it above stability / maturity (eventualy even security).
Offline
I doubt that dash vs. bash in real life applications even matters in terms of speed. Echoing nothing to nothing is a useless benchmark. And it's not because some other distro's are doing it, we should do it too. Would you jump off a cliff because the guy next to you did? There's nothing wrong with bash, it's fully featured and works as it should, period. People seem to be obsessed with bootup time. Well guess what, no matter which software you use, I'll doubt you'll even be able to shave off 5 seconds. If you really want your computer to boot faster, get a hard disk with lower latency, oh hell get a new computer all together. Or for once in your life spend time on things that are really important, instead of wondering "what if my computer booted 5 seconds faster...".
RedShift, I completely agree with you. It's too disheartening to see so many users of otherwise fine distributions trying to spread what "seems" like a good idea. I mean sure, nobody here is saying that X idea is bad for bar purpose(and neither am I), but it seems rather pointless to "clump" together and go about developing/maintaining a method of doing things just because the supposed "mass" is doing it. I think part of the steam behind dash is the same steam that pushed the Iceweasel project into being, to have a 'distribution specific' maintained version of a piece of software, and then have it thrown out to everyone else as being somehow 'better' or 'more worthy of use' than other solutions which work just fine.
Personally speaking, I haven't seen reasonable speed increases with dash over using bash for functions similar in nature to those found in the initscripts, but as always YMMV. IIRC, the BusyBox environment has a significant amount of code derived from the almquist shell in its original writing. I have nothing against dash either, and it of course has its own merits, one of which is being derived from the fine almquist shell ash and being rather aptly suited for embedded environments.
In other words, I hate to say it like this, but in our case it's udev that is the biggest consumer of time spent during the boot process. Seeing that bash has worked for many purposes beautifully for many years, I end my thought with the saying, "if it ain't broke, don't fix it" because it seems to fit in here in this case.
The water never asked for a channel, and the channel never asked for water.
Offline
But what if we do some initscripts-posix package including POSIX-compliant boot scripts, and then we test them with dash, is things work we might just leave it in the repos as an optional package an gradually switch to it using it by default on the Install-CD?
Proud Ex-Arch user.
Still an ArchLinux lover though.
Currently on Kubuntu 9.10
Offline
@LTSmash: I'm not opposed to using dash, but I would say that when the initscripts written for dash are truly stable and error/bug free, then the option of including it instead of the standard bash initscripts. Until then I think it would be better for arch to stick to using bash for the initscripts. The only trouble I have with dash is that it doesn't really follow the philosophy of arch sticking to code that is purely upstream - we should really be using ash instead of dash because it is the purest version of the almquist shell.
Just my 2 cents.
Last edited by xaw (2008-06-21 00:55:15)
The water never asked for a channel, and the channel never asked for water.
Offline
Is the point of moving to dash boot speed?
Personally, I would hope that someday openrc would be pushed into Arch somehow. If anything, that's where I see the real potential for boot speedup.
~kinection
Offline
Sorry that I was a bit harsh up there, but it's a sad fact.
On the note of ubuntu: The switch was easier for them than it will for arch, the reason being the fixed release cycels, and the fact that their init script already is parsed by auto-tools without the user having to do anything. The whole change just took place without the user getting even a msg that is was taking place. While on arch, it will take user intervention.
On the speed note. Atleast rc.sysinit won't save mutch execution time. What dash realy exels at, are for loops etc, and there ain't many of those in rc.sysinit. Also, using compiled GNU tools can save you alot more than a switch from bash to dash can.
E.g. if you are summing the number of lines in alot of files, an find | wc | tail will he alot faster than an "for f in *; do wc -l blablabla; done"
Edit: If we want maximum speed, we should move most of the init functions into a compile lang, like C/C++/haskell/D/java
Edit2: Another tip to get faster boot, is to strip away the udev rules that you don't need, specially those that calls external scripts etc.
Last edited by Mr.Elendig (2008-06-21 13:24:40)
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
So far, nobody has been capable of proving that any significant speed gain is attained by using dash instead, nor that this has any practical advantage over bash.
Last edited by iphitus (2008-06-21 13:49:38)
Offline
So far, nobody has been capable of proving that any significant speed gain is attained by using dash instead, nor that this has any practical advantage over bash.
I don't care at all about speed (damned udev scripts!) ![]()
The only advantages of dash over bash I can recognize:
$ ls -lh /bin/*ash
-rwxr-xr-x 1 root root 518K 30 gen 06:45 bash*
-rwxr-xr-x 1 root root 79K 4 mar 13:18 dash*
$ ldd /bin/*ash
/bin/bash:
linux-gate.so.1 => (0xb804e000)
libreadline.so.5 => /lib/libreadline.so.5 (0xb8000000)
libhistory.so.5 => /lib/libhistory.so.5 (0xb7ff8000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb7fb5000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fb1000)
libc.so.6 => /lib/libc.so.6 (0xb7e6f000)
/lib/ld-linux.so.2 (0xb804f000)
/bin/dash:
not a dynamic executableThis could be great for very minimalistic linux installations on weird hardware, yet arch is i686 so it wouldn't be that useful.
Also, I think having more "standard" init scripts would be better (what you say? Bash is so common it's a standard?
), but I haven't dug into the patched initscripts, really.
Offline
## man 1 bash
3516 BUGS
3517 It's too big and too slow.Let's do the init stuff in py and C instead ![]()
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
So far, nobody has been capable of proving that any significant speed gain is attained by using dash instead, nor that this has any practical advantage over bash.
Using dash is not all about speed. The speed is just a bonus. The real benefit is that it becomes POSIX compliant.
Arch is light and simple. Perfect for building an uclibc distro on (I do this kind of stuff). Unfortunally, bash is too bloaty.
Get rid of bloat, gain speed and be portable is a win. Sure, you don't switch over night, but it is possible.
Offline