Re: hlfs fwrite changes to binutils and gcc
Hi, > Move > to , include the vanilla header in the new > , then redefine the functions with assertions... unless NDEBUG is > defined. This would be a lot easier to work with, as a sysadmin, and would > work transparently with all packages. The only problem is that we will get errors even when there is a check in the code. I'm however going to recompile something smaller (coreutils, bash) and then see how it works... Fine, done... I've tried coreutils with checks in unistd.h and malloc.h, bits/stdio2.h, bits/wchar2.h, stat.h, stdio.h and stdlib.h I'll try tomorrow. It looks quite good. Coreutils testsuite went OK... I'm see tomorrow... -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Dan Nicholson wrote: > Let's analyze it a different way. It takes over twice as long to > initialize and close a bash shell than a dash shell. Why do that when > you don't have to? It's a simple optimization. We had an old saying in the military: Measure with a micrometer, mark it with a grease pencil, cut it with an axe. It strikes me that this is what is happening here. Let me reiterate that I have no objections to doing this as an intellectual exercise. I'm just saying that the results will not be noticeable by the casual user, even if they can be measured with a watch or by internal measurements. >> The memory space is generally not significant either because only one >> copy of the code is in memory at any time. The difference would be data >> space. > > It's not the amount of memory that's the problem. But you're > constantly loading and unloading 6 times as much memory. I'd say that > accounts for the difference above. No, no, no. That's not how Linux memory works. When a program is terminated, the kernel keeps it in memory as long as possible after the last instance using it is finished. If the program is called while it is still in memory, it doesn't have to be reloaded. Generally it only gets thrown out if all memory, including swap, is needed for something else. It is the first to be put in swap if it is unused though. Generally, something like an often used program like a shell would always be in memory or, at worst, swap. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
On Tue, Feb 20, 2007 at 03:28:49PM -0600, Bruce Dubbs wrote: > > The memory space is generally not significant either because only one > copy of the code is in memory at any time. The difference would be data > space. > /me admits to hoping someone would try this - there was an article on lwn recently, http://lwn.net/Articles/220255/ - apparently in Tanenbaum's benchmarks the original sh was fastest, and in the discussion somebody noted that ubuntu had switched to dash to speed up their bootscripts. Of course, our own bootscripts are lean and mean - anything derived from debian seems to do its best to add layers of indirection. ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
On 2/20/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
> >
> > $ time { for (( i = 0; i < 20; i++ )); do /bin/bash -c ":"; done; }
> >
> > real0m0.034s
> > user0m0.014s
> > sys 0m0.020s
> > $ time { for (( i = 0; i < 20; i++ )); do /bin/dash -c ":"; done; }
> >
> > real0m0.015s
> > user0m0.004s
> > sys 0m0.011s
>
> OK, let's analyze this. 20 invocations. 19 ms difference. Less than 1
> ms wall clock time per invocation. How much time did you want to put in
> on this? :)
Let's analyze it a different way. It takes over twice as long to
initialize and close a bash shell than a dash shell. Why do that when
you don't have to? It's a simple optimization.
> The memory space is generally not significant either because only one
> copy of the code is in memory at any time. The difference would be data
> space.
It's not the amount of memory that's the problem. But you're
constantly loading and unloading 6 times as much memory. I'd say that
accounts for the difference above.
The overhead is the same reason why people are adamant about coding in
C after all these years despite the availability of more powerful and
intuitive languages.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Dan Nicholson wrote:
> On 2/20/07, TheOldFellow <[EMAIL PROTECTED]> wrote:
>> Dan's OP was 'use dash to speed up booting' (over-compressed
>> over-simplification). I said you'd do better by parallelising the
>> service start ups. Nothing here that says it's at all worth while to do
>> either really. It's an intellectual exercise!
>
> I never said that it was going to make a significant difference, but
> it that if you're going to spawn a bunch of shell scripts, it would
> make sense to use the interpreter that's 1/6 the size of the other.
>
> $ time { for (( i = 0; i < 20; i++ )); do /bin/bash -c ":"; done; }
>
> real0m0.034s
> user0m0.014s
> sys 0m0.020s
> $ time { for (( i = 0; i < 20; i++ )); do /bin/dash -c ":"; done; }
>
> real0m0.015s
> user0m0.004s
> sys 0m0.011s
OK, let's analyze this. 20 invocations. 19 ms difference. Less than 1
ms wall clock time per invocation. How much time did you want to put in
on this? :)
The memory space is generally not significant either because only one
copy of the code is in memory at any time. The difference would be data
space.
What *would* be useful, IMO, is to have a copy of the messages that the
bootscripts or subordinate programs write, including errors, sent to a
boot log.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
On 2/20/07, TheOldFellow <[EMAIL PROTECTED]> wrote:
>
> Dan's OP was 'use dash to speed up booting' (over-compressed
> over-simplification). I said you'd do better by parallelising the
> service start ups. Nothing here that says it's at all worth while to do
> either really. It's an intellectual exercise!
I never said that it was going to make a significant difference, but
it that if you're going to spawn a bunch of shell scripts, it would
make sense to use the interpreter that's 1/6 the size of the other.
$ time { for (( i = 0; i < 20; i++ )); do /bin/bash -c ":"; done; }
real0m0.034s
user0m0.014s
sys 0m0.020s
$ time { for (( i = 0; i < 20; i++ )); do /bin/dash -c ":"; done; }
real0m0.015s
user0m0.004s
sys 0m0.011s
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Bryan Kadzban wrote: > (However, the biggest delay on my machine is udev, and we can't > parallelize that away. The devices that udevd creates are needed for > both checkfs and mountfs, and mountfs is probably required for most > other scripts. But whatever.) Me too. I've considered a MAKEDEV approach, but I think that's too cutting edge. ;-) R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Bruce Dubbs wrote: > Dan Nicholson wrote: >> On 2/20/07, Joe Ciccone <[EMAIL PROTECTED]> wrote: >>> Bryan Kadzban wrote: On the topic of parallelizing the bootscripts, what do people think about doing this? DJ has added some easily-parallelizable scripts to the contrib/ directory in the bootscripts repo (basically, by making them LSB compliant, you make them easy to run in parallel). Should we look into making these scripts the default, perhaps for LFS 6.4 or 7? (And should we actually run them in parallel or not?) >>> I'm all for parallelizing the boot scripts. The only thing I'm having a >>> hard time getting my head around is updating the screen with the status. >> +1 here, too, so long as they can be proved reliable, etc. I haven't >> gotten around to playing with DJ's scripts, but I will soon. > > I guess I still don't understand the need for this. I just did a test > on my laptop and it took 18 seconds from the time I pushed enter from > grub to a login prompt. This included udev, dbus, hal, sshd, nfsd, but > not X, ntp, or bringing up my wifi card. > > If I cut the boot time in half and rebooted my system seven times a day > (I rarely boot it more than twice, normally once.), I will save one minute. > > If this is done for the challenge, I can understand that, but I don't > think that the the benefit is significant. > > -- Bruce Dan's OP was 'use dash to speed up booting' (over-compressed over-simplification). I said you'd do better by parallelising the service start ups. Nothing here that says it's at all worth while to do either really. It's an intellectual exercise! R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
On Tue, Feb 20, 2007 at 12:46:04PM -0500, Bryan Kadzban wrote: > > On the topic of parallelizing the bootscripts, what do people think > about doing this? DJ has added some easily-parallelizable scripts to > the contrib/ directory in the bootscripts repo (basically, by making > them LSB compliant, you make them easy to run in parallel). Should we > look into making these scripts the default, perhaps for LFS 6.4 or 7? > (And should we actually run them in parallel or not?) > If it causes no damage, and people think it's worth the time to test it, yes to running in parallel. I'd better clarify that - earlier this month I noted that the total time from power-on to a login prompt on my desktops is dominated by the time to a boot prompt, the time to get a dhcp lease, time for ntp to start up, and on one by time for X to start. For me, saving a couple of seconds in the bootscripts is neither here nor there. If X can start while ntp is deciding whether or not to get out of bed, that would be nice - but if ntp decides to call in sick, I'd like to get the report. As to testing, I'll mention that the via C7 I'm playing with for possible lower-power (hah, 1 Watt less than my athlon64 when that is at 1GHz with CnQ) seems to have an interesting race with the bootscripts from December - when the console comes up with the LatArCyrHeb font, one of the earlier messages gets rendered as if it were mostly in cyrillic characters. I've only seen it on that box, it's mostly harmless, and it's such a slow dog that I'm not motivated to debug it ;) My point is that changing how the bootscripts are run will need a *lot* of testing across different machines and combinations of bootscripts. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Xorg-7.2 released
On 2/15/07, Dan Nicholson <[EMAIL PROTECTED]> wrote: > On 2/15/07, Dan Nicholson <[EMAIL PROTECTED]> wrote: > > > > Anyway, what's in BLFS right now is pretty close to what's in 7.2. > > Another suggestion. One of the X developers reorganized the tarballs > nicely so it's easy to see what's changed from release to release. > Browse through these directories: > > http://xorg.freedesktop.org/releases/X11R7.2/src/ > http://xorg.freedesktop.org/releases/X11R7.2/src/deprecated/ > http://xorg.freedesktop.org/releases/X11R7.2/src/update/ More niceness from Alan Coopersmith of Sun. If you're trying to slim down X to just what's needed, here are descriptions and categories of the packages: http://wiki.x.org/wiki/ModuleDescriptions -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Bruce Dubbs wrote: > > > I guess I still don't understand the need for this. I just did a test > on my laptop and it took 18 seconds from the time I pushed enter from > grub to a login prompt. This included udev, dbus, hal, sshd, nfsd, but > not X, ntp, or bringing up my wifi card. > > > 14 is still better then 18. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Dan Nicholson wrote: > On 2/20/07, Joe Ciccone <[EMAIL PROTECTED]> wrote: >> Bryan Kadzban wrote: >>> On the topic of parallelizing the bootscripts, what do people think >>> about doing this? DJ has added some easily-parallelizable scripts to >>> the contrib/ directory in the bootscripts repo (basically, by making >>> them LSB compliant, you make them easy to run in parallel). Should we >>> look into making these scripts the default, perhaps for LFS 6.4 or 7? >>> (And should we actually run them in parallel or not?) >>> >> I'm all for parallelizing the boot scripts. The only thing I'm having a >> hard time getting my head around is updating the screen with the status. > > +1 here, too, so long as they can be proved reliable, etc. I haven't > gotten around to playing with DJ's scripts, but I will soon. I guess I still don't understand the need for this. I just did a test on my laptop and it took 18 seconds from the time I pushed enter from grub to a login prompt. This included udev, dbus, hal, sshd, nfsd, but not X, ntp, or bringing up my wifi card. If I cut the boot time in half and rebooted my system seven times a day (I rarely boot it more than twice, normally once.), I will save one minute. If this is done for the challenge, I can understand that, but I don't think that the the benefit is significant. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
On 2/20/07, Joe Ciccone <[EMAIL PROTECTED]> wrote: > Bryan Kadzban wrote: > > > > On the topic of parallelizing the bootscripts, what do people think > > about doing this? DJ has added some easily-parallelizable scripts to > > the contrib/ directory in the bootscripts repo (basically, by making > > them LSB compliant, you make them easy to run in parallel). Should we > > look into making these scripts the default, perhaps for LFS 6.4 or 7? > > (And should we actually run them in parallel or not?) > > > I'm all for parallelizing the boot scripts. The only thing I'm having a > hard time getting my head around is updating the screen with the status. +1 here, too, so long as they can be proved reliable, etc. I haven't gotten around to playing with DJ's scripts, but I will soon. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
Bryan Kadzban wrote: > > On the topic of parallelizing the bootscripts, what do people think > about doing this? DJ has added some easily-parallelizable scripts to > the contrib/ directory in the bootscripts repo (basically, by making > them LSB compliant, you make them easy to run in parallel). Should we > look into making these scripts the default, perhaps for LFS 6.4 or 7? > (And should we actually run them in parallel or not?) > > I'm all for parallelizing the boot scripts. The only thing I'm having a hard time getting my head around is updating the screen with the status. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Parallelizing bootscripts [was: Make bootscripts more POSIX compliant]
On Tue, Feb 20, 2007 at 12:45:38PM +, TheOldFellow wrote: > On the point of speeding up bootscripts, you'll have far more luck by > parallelising your service start ups, then lightening the scripter. Yep, that's right; most of the time now is spent waiting for various services to actually start up. If the services are not interdependent, then starting them in parallel will speed up booting a lot more than making the interpreter load faster -- or run faster, for that matter. (However, the biggest delay on my machine is udev, and we can't parallelize that away. The devices that udevd creates are needed for both checkfs and mountfs, and mountfs is probably required for most other scripts. But whatever.) On the topic of parallelizing the bootscripts, what do people think about doing this? DJ has added some easily-parallelizable scripts to the contrib/ directory in the bootscripts repo (basically, by making them LSB compliant, you make them easy to run in parallel). Should we look into making these scripts the default, perhaps for LFS 6.4 or 7? (And should we actually run them in parallel or not?) On the one hand, it could be argued that this is not at all needed for a base system, and depending on your definition of "base", that may be right. But OTOH, most users expect OSes to come up in way less than a minute these days. Plus, having parallel bootscripts is certainly an education opportunity, if the user looks into how the scripts work together, or if the general idea is explained when the scripts get installed. (And LSB compliance helps when another package, e.g. one that isn't in LFS or BLFS, needs to install a bootscript -- but I'm not sure how many of those there even are. Of course, we would get that by using the LSB scripts without running them in parallel, too.) If I remember, I'll try doing some testing on my machine sometime soon, to see what, if anything, is required to get these contrib scripts to work, and then what else, if anything, is required to get them to work in parallel. (Well, "what else" apart from actually running them in parallel from rc, that is.) pgpOkMGfZrMww.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Make bootscripts more POSIX compliant
Dan Nicholson wrote: > On 2/19/07, TheOldFellow <[EMAIL PROTECTED]> wrote: >> Dan Nicholson wrote: >>> After the error the other day with dash and glibc-2.3.6, >> I prefer to install bash and start all the bootscripts #!/bin/bash to >> make it clear that anyone who wants to use another shell is on their >> own. :-) > > Very true. But a big motivation of using dash is that it's much more > lightweight than bash, presumably providing some speedup for simple > scripts where lots of features aren't needed. I do love a bash script, > though. > > -- > Dan Hmm... Maybe we should do a Dash version of LFS, designed for sub-gigahertz systems with minimal memory, say 64M. I'm all in favour of recycling to save the planet. While we're at it we could use one of the simple libcs and avoid that dead-weight too. On the point of speeding up bootscripts, you'll have far more luck by parallelising your service start ups, then lightening the scripter. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Make bootscripts more POSIX compliant
Dan Nicholson wrote: > On 2/20/07, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: >> Dan Nicholson wrote: >> >>> How would an implementation of translated messages work in general? gettext? >> Yes - but the use of $"Message to be translated" syntax requires >> #!/bin/bash. The only difference from the original bootscript would be to >> change the interpreter, add $ before every translatable string (in one case, >> this requires making the string translatable), and add *.po files. Russian >> and Spanish po files already exist for old bootscripts. > > In the Advanced Bash Scripting Guide they seem to suggest using $"..." > is deprecated and gettext should be used directly. > > http://tldp.org/LDP/abs/html/localization.html Yes - but Fedora still uses this old syntax. > So, any localization might be best done in a portable manner anyway. I will try this. > That would require moving gettext to /bin, though. No, because the required gconv libraries and locale data are in /usr anyway. Thus, there is no choice except falling back to untranslated English strings until /usr is mounted. So, the functions file should define the gettext function that functions like echo, if /usr/bin/gettext is missing. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Make bootscripts more POSIX compliant
On 2/20/07, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: > Dan Nicholson wrote: > > > How would an implementation of translated messages work in general? gettext? > > Yes - but the use of $"Message to be translated" syntax requires > #!/bin/bash. The only difference from the original bootscript would be to > change the interpreter, add $ before every translatable string (in one case, > this requires making the string translatable), and add *.po files. Russian > and Spanish po files already exist for old bootscripts. In the Advanced Bash Scripting Guide they seem to suggest using $"..." is deprecated and gettext should be used directly. http://tldp.org/LDP/abs/html/localization.html So, any localization might be best done in a portable manner anyway. That would require moving gettext to /bin, though. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Various issues with the book
On 2/19/07, Chris Staub <[EMAIL PROTECTED]> wrote:
> 1. Perhaps it should be made somewhat clearer that the "Linux-Headers"
> installation comes from the kernel tarball. More than one user has come
> into the IRC chat asking if it was the CLFS "Linux-Headers" package.
No kidding. I don't know what else can be said, though. The Ch. 5 page
says "This is done by way of sanitizing various C header files that
are shipped in the Linux kernel source tarball".
I'd think the only reason to specify the mechanism would be if you
weren't using the scripts in the kernel. If you can think of anything,
though, I'll add it.
> 2. The toolchain-adjustment section says that you can edit the specs
> file by hand, but there is no specs file at all until it's generated by
> that command gcc | sed command.
Nice catch.
> 3. Is m4 really needed in Chapter 5? I thought the only reason it was
> there was because of Binutils, but it doesn't need m4 now...
Is that why? I have no idea, and I think you're probably most
qualified since you did all the work on the dependencies. The other
things that need it early in Ch. 6 are bison and autoconf, and they're
taken care of. I just looked through my logs, and gcc checks for m4,
but I don't think it uses it.
It could probably be removed or commented out, but I think someone
will have to do an ICA build to see what happens.
> 4. Inetutils installs programs for ipv6, including a "ping6" program.
> Since the FHS says that ping must be in /bin, it would seem to make
> sense to put ping6 there too...this is what we have done in CLFS.
I don't think I agree with that, but I don't feel really strongly either way.
> 5. The instructions for Man-DB eliminate the reference to /usr/man in
> the manpage search path to remove potential redundant results (since
> /usr/man is a symlink to /usr/share/man). The same should be done for
> /usr/local/man.
Good point.
> 6. Are the instructions in Texinfo for optionally installing TeX stuff
> really needed? First, there is no explanation for what TeX is. Second,
> there is no description of what exactly is installed ("components
> belonging in a TeX installation" - what components?). We simply removed
> that in CLFS.
I like that. You can enable an additional part with no extra
dependencies. And we don't install texinfo in BLFS, so the TeX sources
would just float away unless you were around before to know that they
exist.
I'd be alright with adding a little explanation about what they are.
Maybe all that's needed is a link to a site explaining TeX.
> 7. The Udev page says that Udev does not install any rules by default.
> Actually, it does. Right make install for Udev...
>
> [EMAIL PROTECTED]:/home/lfs/sources/udev-105# ls /etc/udev/rules.d/
> 60-cdrom_id.rules 75-persistent-net-generator.rules
> 75-cd-aliases-generator.rules
OK.
> Do we want to keep those or replace them? In CLFS we simply eliminate
> the contents of /etc/udev/rules.d immediately after installing Udev.
We actually use them in LFS, and we decided not to replace any rules
provided upstream (unless they're broken). The udev-config tarball
only has a couple rules files and some documentation.
> Also, the "make install-doc" command for the LFS Udev rules creates the
> /usr/share/doc/udev-105 directory so the command for installing the
> documentation for writing Udev rules should be able to be shortened to
> "install -m644 -v docs/writing_udev_rules/index.html
> /usr/share/doc/udev-105".
Thanks.
> Also, I have attached a patch with a few text fixes for the book.
Those all look good. Thanks, Chris.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Make bootscripts more POSIX compliant
Dan Nicholson wrote: > On 2/19/07, Alexander E. Patrakov <[EMAIL PROTECTED]> wrote: >> Could you please install posh from >> http://ftp.debian.org/debian/pool/main/p/posh/posh_0.5.4.tar.gz and test >> whether it reveals any additional breakage? > > I'll take a look at it. Any background on posh? It is known to be POSIX-compliant, but creatively broken in worst possible ways. So, if a script works with posh, it should work almost everywhere. http://www.mail-archive.com/debian-policy@lists.debian.org/msg19954.html http://www.garayed.com/linux/137368-default-debian-shell.html > How would an implementation of translated messages work in general? gettext? Yes - but the use of $"Message to be translated" syntax requires #!/bin/bash. The only difference from the original bootscript would be to change the interpreter, add $ before every translatable string (in one case, this requires making the string translatable), and add *.po files. Russian and Spanish po files already exist for old bootscripts. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
