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 whe
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 p
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 r
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; }
> >
> > re
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 real
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
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
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
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
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
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
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 (bas
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
>
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).
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 star
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
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 fro
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
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
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?
20 matches
Mail list logo