Re: [RFC] Drop the Coreutils Uname patch
Matthew Burgess wrote these words on 04/20/07 16:55 CST: Given that all 3 books use different patches, it serves a purely cosmetic purpose (as far as I know), and upstream will not entertain the patch at all in its current form, I'd like to drop it. Thoughts, comments? On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 01:50:01 up 30 min, 1 user, load average: 0.21, 0.13, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
On Tuesday April 24 2007 02:50, Randy McMurchy wrote: Matthew Burgess wrote these words on 04/20/07 16:55 CST: Given that all 3 books use different patches, it serves a purely cosmetic purpose (as far as I know), and upstream will not entertain the patch at all in its current form, I'd like to drop it. Thoughts, comments? On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. robert pgpAVmnoqvetk.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Robert Connolly wrote these words on 04/24/07 01:57 CST: On Tuesday April 24 2007 02:50, Randy McMurchy wrote: What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. Then -1 to Matt's proposal to remove the patch. Seems dumb to remove a patch that provides a better end product. Why would we want to remove a perfectly functional patch that provides a decent machine name instead of unknown? -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Randy McMurchy wrote these words on 04/24/07 02:11 CST: Then -1 to Matt's proposal to remove the patch. Seems dumb to remove a patch that provides a better end product. In my haste in replying I didn't think through this response, please: s/Seems dumb to/I would prefer that we didn't/ -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 02:25:00 up 1:05, 1 user, load average: 0.11, 0.44, 0.60 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Matthew Burgess wrote: Hi, http://wiki.linuxfromscratch.org/lfs/ticket/1990 proposes to have LFS use the same uname patch for Coreutils that HLFS uses. Note also that CLFS uses another version of the uname code that adds outputs for more architectures still. Given that all 3 books use different patches, it serves a purely cosmetic purpose (as far as I know), and upstream will not entertain the patch at all in its current form, I'd like to drop it. As the ticket mentions, the correct way to implement this, according to upstream, is to have the kernel make the processor type available via a syscall. Thoughts, comments? It is a cosmetic patch, but I like it. I don't see a particular advantage to having all the books use the same patch. In other words, it would be much more effort to maintain it than it's worth. Why would we want to change the LFS book to keep the patch in sync if it changed for some exotic architecture being addressed in CLFS? Looking at the ticket, it might be useful to change the patch to use position independent assembly. I think the problem with putting a syscall into the kernel is that it would be difficult to ensure that it is set properly for all architectures (e.g. Sparc or S390). Overall, I would be in favor of using the patch, but not keeping it in sync with the other *LFS books unless it affected the IA32 architectures. I am not in favor of dropping the patch completely. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [PATCH] Speedup killproc
On 4/17/07, Dan Nicholson [EMAIL PROTECTED] wrote:
On 4/17/07, Matthew Burgess [EMAIL PROTECTED] wrote:
On Tuesday 17 April 2007 05:15, Dan Nicholson wrote:
Index: bootscripts/lfs/init.d/functions
===
--- bootscripts/lfs/init.d/functions(revision 8076)
+++ bootscripts/lfs/init.d/functions(working copy)
@@ -657,11 +657,12 @@
# Wait up to 3 seconds, for ${pid} to terminate
case ${killsig} in
TERM|SIGTERM|KILL|SIGKILL)
- local dtime=${KILLDELAY}
+ # sleep in 1/10ths of seconds
+ local dtime=${KILLDELAY}0
A 0 is added to KILLDELAY to essentially multiply by 10.
while [ ${dtime} != 0 ]
do
kill -0 ${pid} 2/dev/null || break
- sleep 1
+ sleep 0.1
dtime=$(( ${dtime} - 1))
I think the above needs to be:
dtime=$(( ${dtime - 0.1)) otherwise we're not going to wait for 3 seconds.
I
suspect this might be why your bootups have a far shorter delay ;)
This isn't possible because the shell arithmetic $(( )) only handles
integers. But multiplying the value of KILLDELAY (seconds) should make
this work. I.e., dtime=${KILLDELAY}0 (dtime=30), sleep 0.1, dtime--
(dtime=29).
I just installed another system without the above tweak and noticed
how slow it makes shutdown. No one replied confirming/denying my above
statements, so here's a quick test to show that this is functionally
equivalent.
$ time {
KILLDELAY=3
dtime=$KILLDELAY
while [ $dtime != 0 ]; do
sleep 1
dtime=$(($dtime - 1))
done
}
real0m3.007s
user0m0.001s
sys 0m0.001s
$ time {
KILLDELAY=30
dtime=$KILLDELAY
while [ $dtime != 0 ]; do
sleep 0.1
dtime=$(($dtime - 1))
done
}
real0m3.070s
user0m0.000s
sys 0m0.001s
Does anyone object to this?
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [PATCH] Speedup killproc
On Tuesday 24 April 2007 19:06, Dan Nicholson wrote: I just installed another system without the above tweak and noticed how slow it makes shutdown. No one replied confirming/denying my above statements, so here's a quick test to show that this is functionally equivalent. Sorry, Dan, I got sidetracked and forgot to reply to this. I've no problems with this patch - thanks for your previous explanation! Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
On Tuesday 24 April 2007 08:27, Randy McMurchy wrote: Randy McMurchy wrote these words on 04/24/07 02:11 CST: Then -1 to Matt's proposal to remove the patch. Seems dumb to remove a patch that provides a better end product. In my haste in replying I didn't think through this response, please: s/Seems dumb to/I would prefer that we didn't/ Oh, ever the diplomat Randy :-) The reasons I wanted to drop the patch were in my original RFC, the main one being that it's never going to get accepted upstream as the functionality to determine the processor type belongs in the kernel. Thinking over that again though, that's exactly the same situation faced by the Coreutils i18n patch - it provides useful functionality but in a manner that upstream won't accept. So, maybe it wasn't a very strong argument after all. Given the above, and the fact that those that responded want the patch kept, I'll just let it lie for now. Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Fighting spam via greylisting
On Mon, Apr 23, 2007 at 08:46:04AM +0300, Ag. D. Hatzimanikas wrote: Maybe it's a flaw in Track, maybe there is already a patch. Keep in mind that, although it may have appeared that way externally, the idea to try out greylisting had nothing to do with recent vandalism of the trac system(s). We fully realize that there are two separate and distinct issues there. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[new XSL] Finished LFS and BLFS rework
Hi, The LFS and BLFS stylesheets rework has been done, or as least I can't find any obvious remaining issues. To allow review it, the generated chunked XHTML and PDF versions for both books can be found here: http://www.linuxfromscratch.org/~manuel/ I will wait some days for your comments and inputs. I would have solved all concerns and complaints about the LFS/BLFS outputs and the stylesheets layout before start working on HLFS and CLFS integration. Please, keep the discussion on the lfs-dev list. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Robert Connolly wrote: On Tuesday April 24 2007 02:50, Randy McMurchy wrote: On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. You are technically incorrect. An unpatched `uname -a' simply omits the -p and -i fields when they are unknown. $ uname --help Usage: uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --allprint all information, in the following order, except omit -p and -i if unknown: Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [RFC] Drop the Coreutils Uname patch
Greg Schafer wrote: Robert Connolly wrote: On Tuesday April 24 2007 02:50, Randy McMurchy wrote: On the computer I'm typing this message on, 'uname -a' reports this: Linux rmlscsi 2.6.14.3 #1 PREEMPT Sat Mar 25 07:47:39 CST 2006 i686 pentium3 i386 GNU/Linux What would it report without the patch? The pentium3 would become unknown. The patch sets uname -p. You are technically incorrect. An unpatched `uname -a' simply omits the -p and -i fields when they are unknown. $ uname --help Usage: uname [OPTION]... Print certain system information. With no OPTION, same as -s. -a, --allprint all information, in the following order, except omit -p and -i if unknown: That looks like a recent change to the behavior. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
