On Mon, Mar 23, at 05:52 Bruce Dubbs wrote: > Agathoklis D. Hatzimanikas wrote: > > On Mon, Mar 23, at 07:12 Dan Nicholson wrote: > >> On Fri, Mar 20, 2009 at 4:44 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote: > >> > >> If you were looking at a system (not just a computer system) and you > >> found that one part took twice the resources and twice as long to > >> start up as another part offering similar functionality, why would you > >> dismiss it? > > > > In a perfect world? You have to adopt the best technology. > > But in the case of Linux, Bash is the single most sacred piece of code. > > > > Objectively, Dash is more suitable for login and system scripts than Bash, > > because is faster, > > Yes, but is it significant
Of course is significant. In fact decreasing booting time in Linux is all over the news for months, see, http://lwn.net/Articles/299483/ We are not talking about your home workstation or about a server. We are talking about laptops, netbooks, instant devices, which are not only the trend of today market as might some people think, *it is* the future. So its about research to that direction, and about adoption of the best technology. If there is a 3 seconds gain then by all that means we have to adopt the solution. > more stable > > this is an unsupported assertion Less code usually means, lesser bugs. > and offers portability > > portability to what? Today? (with the current LFS status?) probably nothing. But I don't know for tomorrow. Depends on your expectations. > and compliance with > > POSIX specifications, which is very important in a project like ours. > > Dash is arguably less in compliance than bash as it does not support the > LINENO > variable specified in the PSOIX standard. I've made a research about this. The result is that, POSIX wording is ambiguous and it doesn't really require the variable. > The advantages of dash/ash are that they are smaller and faster. The real > question is whether the speed differences and size are significant for an LFS > system. > > The drawback to dash/ash is that they offer fewer features. It's a trade off. But we don't care about the extra features on login scripts. > > And try to compare with a shell concept, where everything (directories > > and files) are plain objects and you just send messages (applying > > methods) to those objects. > > What we take is consistent syntax (no matter the kind of operations you > > apply), and a powerful language in our disposal with almost no limitation. > > > > E.g., (an example from a Ruby based experimental shell concept named Rush) > > > > dir = home['somedir/'] > > dir['*.txt'].each {|f| f.destroy} > > In bash: rm -f $HOME/somdir/*.txt > > You really think Ruby is easier? It's not only about which is easier, although trying in shell to chain commands with different syntax, enclosed in backticks, running every command in its own environment, and filtering processes through pipelines, can be a complex and sometimes fragile operation (usually I say). You need experience and a good technical background to the I/O operations. (And we are not talking only about old Unix timers like you. I am pretty familiar with the command line too, and I did in the past and I still do, some really complex stuff.) Again, you don't need to learn all the command line different switches from a dozen various applications. You learn a language and you apply the techniques of that language to any of your objects. Its about consistency, intelligence, interactivity, remote connectivity, debugging (capturing exceptions), analyzing the results, familiarity with the environment and the principle of least surprise. Anyway we are talking about future technologies, that we will see them coming. Speaking about the future here is a small gift: http://vpri.org/ http://VPRI.Org/pdf/tr2007008_steps.pdf Alan Kay is the guy from smalltalk. They are talking about a TCP/IP stack in 200 lines of code and a subset of cairo in less than 500 lines of code. One guy from cairo is working on this. > Actually this whole discussion is about what interpreter should be used for > the > boot sequence. Does a 10-20% decrease in boot time justify the time spent to > make the scripts compatible with an interpreter that we don't even install in > LFS? Repeating myself. Of course it does. > -- Bruce Regards, Ag. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
