Re: [PATCH] Fancy rc startup style RFC - v6

2006-04-20 Thread Danny Braniss 
> Coleman Kane wrote:
> > On 4/20/06, *Eric Anderson* <[EMAIL PROTECTED] 
> > > wrote:
> > 
> > David Barbero wrote:
> >  >
> >  --- snip ---
> > 
> > Yep, that's a bug.  I think it's fixed in v7, available here:
> > 
> > http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7
> > 
> > along with a few other suggestions from others.
> > 
> > 
> >  > Another one of the failures that I have seen is that with this
> > patch they
> >  > show all the services, they are or not formed to start, I believe
> > that
> >  > single they would have to appear the services that are formed to
> > start and
> >  > not all those that can start.
> > 
> > If the service is run on bootup, it shows it.  It was still being run
> > before, there was just no output previously.  It would be pretty easy to
> > have an option to not print these, maybe an rc_fancy_verbose option.  Is
> > this desirable to most?
> > 
> >  > In addition  the services that are not formed to start appear
> > like [ OK ],
> >  > in the case of appearing these, I believe that they would have to
> > leave
> >  > with another denomination that is not [ OK ].
> > 
> > 
> > I'm not sure what you mean here.  Can you give me an example?
> > 
> > 
> >  > Another failure that I have seen is that when leaving the message
> > syslogd
> >  > this sample failure, but this service starts without problems,
> > but shows
> >  > it as if it gave failure...
> > 
> > My syslogd looks clean, and doesn't give a false failure.  I'm not sure
> > how to look into this - can you confirm that it truly is passing, but
> > giving the wrong message, or is it that the rc subsystem thinks it's
> > failing but appears to work ok?
> > 
> > 
> >  > In principle this is what I have seen at first sight on the patch.
> > 
> > 
> > Thanks for all the feedback and testing!
> > 
> > 
> > Eric
> > 
> > 
> > I have modified the patch as follows:
> > 
> > Made a bunch of the settings tunable by the user (message text and field 
> > widths).
> > 
> > It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch
> 
> 
> This looks good. I only wonder about two things now:
> 
> - Should we also have a line for the actual colors used too?  Or is that 
> going too crazy?
> 
> - Does it meet style(9)?  I'm wondering about line lengths now.
> 
> Other than that, do we have general consensus that these do what they 
> claim?  Any outstanding issues that haven't been addressed?
> 
> 

is the information correct? for example:
Running start savecore [FAILED]
Running start virecover[FAILED]

the above didn't fail, they just had nothing to do.

there is a danger with false negatives, it tends to confuse the uninitiated,
there is a also a problem with false positives:
Running start geli2[  OK  ]
Running start mixer[  OK  ]

these do nothing, no geli2 nor mixer.

The problem is one of interpretation, what does OK realy mean?

one of the things i dislike with Linux is the amount of information printed 
when booting,
it just wisks by, and when things don't work it's not clear what caused it!

just to show that you are not alone:
Apr 19 12:24:33 gto postgres[43823]: [2-1] FATAL:  the database system is 
starting up

danny


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Build Kernels fails with

2006-04-20 Thread Erich Dollansky 

Hi,

ist looks to me that this is still true for a 32 bit kernel.

http://lists.freebsd.org/pipermail/freebsd-amd64/2005-July/005592.html

This error message appears

if_ural.o(.text+0x205): In function `ural_next_scan':
/usr/src/sys/dev/usb/if_ural.c:699: undefined reference to
`ieee80211_next_scan'*** Error code 1

as long as "device wlan" is not defined.

Erich
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

2006-04-20 Thread Coleman Kane 
On 4/20/06, Eric Anderson <[EMAIL PROTECTED]> wrote:
>
> David Barbero wrote:
> >
>  --- snip ---
>
Yep, that's a bug.  I think it's fixed in v7, available here:
>
> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7
>
> along with a few other suggestions from others.
>
>
> > Another one of the failures that I have seen is that with this patch
> they
> > show all the services, they are or not formed to start, I believe that
> > single they would have to appear the services that are formed to start
> and
> > not all those that can start.
>
> If the service is run on bootup, it shows it.  It was still being run
> before, there was just no output previously.  It would be pretty easy to
> have an option to not print these, maybe an rc_fancy_verbose option.  Is
> this desirable to most?
>
> > In addition  the services that are not formed to start appear like [ OK
> ],
> > in the case of appearing these, I believe that they would have to leave
> > with another denomination that is not [ OK ].
>
>
> I'm not sure what you mean here.  Can you give me an example?
>
>
> > Another failure that I have seen is that when leaving the message
> syslogd
> > this sample failure, but this service starts without problems, but shows
> > it as if it gave failure...
>
> My syslogd looks clean, and doesn't give a false failure.  I'm not sure
> how to look into this - can you confirm that it truly is passing, but
> giving the wrong message, or is it that the rc subsystem thinks it's
> failing but appears to work ok?
>
>
> > In principle this is what I have seen at first sight on the patch.
>
>
> Thanks for all the feedback and testing!
>
>
> Eric


I have modified the patch as follows:

Made a bunch of the settings tunable by the user (message text and field
widths).

It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch

--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

2006-04-20 Thread Coleman Kane 
On 4/20/06, Eric Anderson <[EMAIL PROTECTED]> wrote:
>
> Coleman Kane wrote:
> >
> > I have modified the patch as follows:
> >
> > Made a bunch of the settings tunable by the user (message text and field
> > widths).
> >
> > It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch
>
>
> This looks good. I only wonder about two things now:
>
> - Should we also have a line for the actual colors used too?  Or is that
> going too crazy?


Definately... I think having the ability to specify colorsets as profiles
will be a must-have. Read the LSCOLORS description in ls(1).

- Does it meet style(9)?  I'm wondering about line lengths now.


One unfortunate thing about /bin/sh: [from the sh(1) manpage]

 Only one of the -e and -n options may be specified.

This means that we may not be able to use the -n to chain multiple echos on
one line...

Other than that, do we have general consensus that these do what they
> claim?  Any outstanding issues that haven't been addressed?
>
>
> Eric


--coleman
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

2006-04-20 Thread Eric Anderson 

Coleman Kane wrote:
On 4/20/06, *Eric Anderson* <[EMAIL PROTECTED] 
> wrote:


David Barbero wrote:
 >
 --- snip ---

Yep, that's a bug.  I think it's fixed in v7, available here:

http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7

along with a few other suggestions from others.


 > Another one of the failures that I have seen is that with this
patch they
 > show all the services, they are or not formed to start, I believe
that
 > single they would have to appear the services that are formed to
start and
 > not all those that can start.

If the service is run on bootup, it shows it.  It was still being run
before, there was just no output previously.  It would be pretty easy to
have an option to not print these, maybe an rc_fancy_verbose option.  Is
this desirable to most?

 > In addition  the services that are not formed to start appear
like [ OK ],
 > in the case of appearing these, I believe that they would have to
leave
 > with another denomination that is not [ OK ].


I'm not sure what you mean here.  Can you give me an example?


 > Another failure that I have seen is that when leaving the message
syslogd
 > this sample failure, but this service starts without problems,
but shows
 > it as if it gave failure...

My syslogd looks clean, and doesn't give a false failure.  I'm not sure
how to look into this - can you confirm that it truly is passing, but
giving the wrong message, or is it that the rc subsystem thinks it's
failing but appears to work ok?


 > In principle this is what I have seen at first sight on the patch.


Thanks for all the feedback and testing!


Eric


I have modified the patch as follows:

Made a bunch of the settings tunable by the user (message text and field 
widths).


It is availalbe at http://www.cokane.org/files/rc_fancy-cokane2.patch



This looks good. I only wonder about two things now:

- Should we also have a line for the actual colors used too?  Or is that 
going too crazy?


- Does it meet style(9)?  I'm wondering about line lengths now.

Other than that, do we have general consensus that these do what they 
claim?  Any outstanding issues that haven't been addressed?



Eric



--

Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Per CPU cpu-statistics under SMP

2006-04-20 Thread Marco van Tol 
On Wed, Apr 19, 2006 at 07:26:27AM +, Marco van Tol wrote:
> On Tue, Apr 18, 2006 at 06:38:26PM -0400, John Baldwin wrote:

[...]

> > Ah, hmm.  On 6.x we don't have per-thread stat ticks yet, which is
> > probably why it is failing.  It also isn't safe to move sched_lock
> > down either on 6.x.  You can still apply the rest of the patch by
> > hand, just leave the 'mtx_lock_spin(&sched_lock)' where it is and
> > change all the 'cp_time[FOO]++' to 'PCPU_LAZY_INC(cp_time[FOO])'.
> 
> OK, thanks.
> 
> What I will do is replace my gentoo partition with a BSD current partition
> so I don't loose my workstation as it were, and use that to work on this.
> 
> Will let you know how that goes.  Thanks.

Ha! It succeeded. :)

For additional information:
- I'm running an Athlon64 X2 4200+ in 64bit mode.
  (I won't start about the nvidia controller it also has ;)
- I'm using the SCHED_ULE scheduler (Does that make a difference for this?)
- All patching took place against todays CURRENT.
- I manually patched the first hunk of kern_clock.c, as the rest of the
  hunks succeeded on their own. (Hadn't used .rej files much before, but
  they're very usefull :)

Thank you very much!
I think this should suffice for what I intend to do to gkrellm for now.

If you want any additional information from me, or if you want me to test
other patches, I'd be more then happy to supply/try it/them.

Here's the result:
-< cut here >-
1:[EMAIL PROTECTED] marco]sysctl hw.ncpu
hw.ncpu: 2
-< cut here >-
1:[EMAIL PROTECTED] marco]for (( i = 0 ; $i < 10 ; i++ )) ; do sysctl 
kern.pcpu_time kern.cp_time ; sleep 1 ; echo -- ; done
kern.pcpu_time: 156 0 397 225 20542 21 0 30 0 21259
kern.cp_time: 177 0 427 225 41801
--
kern.pcpu_time: 156 0 397 225 20675 21 0 30 0 21392
kern.cp_time: 177 0 427 225 42067
--
kern.pcpu_time: 157 0 398 225 20807 21 0 30 0 21526
kern.cp_time: 178 0 428 225 42333
--
kern.pcpu_time: 157 0 398 225 20940 21 0 30 0 21659
kern.cp_time: 178 0 428 225 42599
--
kern.pcpu_time: 157 0 398 225 21074 21 0 30 0 21793
kern.cp_time: 178 0 428 225 42867
--
kern.pcpu_time: 157 0 398 225 21207 21 0 30 0 21926
kern.cp_time: 178 0 428 225 43133
--
kern.pcpu_time: 157 0 398 225 21340 21 0 30 0 22059
kern.cp_time: 178 0 428 225 43399
--
kern.pcpu_time: 157 0 399 225 21473 21 0 30 0 22193
kern.cp_time: 178 0 429 225 43666
--
kern.pcpu_time: 157 0 399 225 21606 21 0 30 0 22326
kern.cp_time: 178 0 429 225 43932
--
kern.pcpu_time: 157 0 399 225 21740 21 0 30 0 22460
kern.cp_time: 178 0 429 225 44200
--
0:[EMAIL PROTECTED] marco]
-< cut here >-

Marco

-- 
The difference between theory and practice
is a lot bigger in practice then in theory
- Peter van der Linden in `Deep C Secrets'
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [fbsd] Re: Symbol weirdness with static linking

2006-04-20 Thread Jeremie Le Hen 
Hi, Kostik,

> > For the sake of completeness, I added the output of some objdump(1)
> > outputs here :
> > 
> > /usr/obj/usr/src/bin/echo/echo.o:
> > http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_echo.txt.gz
> > 
> > /usr/obj/usr/src/tmp/usr/lib/libc.a:
> > http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libc.txt.gz
> > 
> > /usr/obj/usr/src/tmp/usr/lib/libssp.a:
> > http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libssp.txt.gz
> 
> It seems that you rebuilt world with CFLAGS -fstack-protector,
> since your libc has references to the symbols like __stack_smash_handler.
> As result, when linking with sequence -lgcc -lssp -lc -lgcc -lssp,
> and no references from the main object,
> references from libc causes objects from _second_ instance of -lssp to
> be pulled into the link. Since libraries are scanned sequentially,
> this object from libssp has no way to get required dependencies
> from libc.

Yes, I understand that.  But I can't see what's the difference between
"syslog" and "sigfillset" symbols from this standpoint.  The fact the
former requires ProPolice/SSP doesn't interfere IMHO.

> What makes syslog(3) special is that corresponding object from libc,
> syslog.o, requires __stack_smash_handler, while objects for mentioned
> syscalls do not.

How does it prevent the "syslog" symbol from being found ?  Libc
undefined symbols implies the second libssp to be pulled in which in
turn has undefined symbol.  But since there is no more libc after this,
"sigfillset" should be missing either.

I would understand if echo.o needed some symbols provided by the same
archive than "sigfillset" (sigsetops.o) but this is not the case.

Regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Server choice.

2006-04-20 Thread Mark Kirkwood 

Paul Halliday wrote:

Hi,

I am in the process of building a new database server and after
pricing up 2 Dell models I thought I would throw this out just to see
which choice would be better suited for FreeBSD.

The demands on the system will be mostly network -> disk I/O with a
hope of best performance on quickly servicing numerous reads; for
example when reports are generated using the data in the database.

The 2 choices (we dont have that much money and they have to be Dell)
are a poweredge 1850 and a poweredge 850.

850 specs.

Procsesor: Pentium(Dual Core) 830 @ 3.0GHz/2X1MB Cache 800MHz FSB
Memory: 2GB DDR2, 533MHz (2x1GB) Dual ranked DIMMs
Disks: SATA

1850 specs.
--
Processors: 2 @ Xeon @ 3.0GHz/2MB Cache 800MHz FSB
Memory: 2GB DDR2, 400MHz (4x512) Single ranked DIMMs
Disks: Ultra 320

The pricing is really close.


Typically for a database server, the IO system is the most important 
single component. Unfortunately this is often the component that is 
skimped on for budget vendor boxes. See if you can find out the details 
for the SATA and SCSI controllers (the SATA particularly as there are 
crappy controllers out there that will just be a misery if you get 
lumbered with them).


I ran Dell servers a few years ago and liked them - but recently 
switched to using Supermicro, as the quality of the more modern Dell 
boxes seems to be ...err... shall we say, 'decreased' :-).


cheers

Mark
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

2006-04-20 Thread Eric Anderson 

Bill Vermillion wrote:

While stranded on the shoulder of the Information
Superhiway and trying to flag down some passing bytes
[EMAIL PROTECTED] said "Bits don't fail me now",
and continued with:


Date: Wed, 19 Apr 2006 13:03:57 -0400
From: "Coleman Kane" <[EMAIL PROTECTED]>
Subject: Re: [PATCH] Fancy rc startup style RFC



On 4/19/06, Mike Meyer <[EMAIL PROTECTED]> wrote:



In
<[EMAIL PROTECTED]>,
Coleman Kane <[EMAIL PROTECTED]> typed:



On 4/19/06, Mike Meyer
<[EMAIL PROTECTED]  wrote:



How about we all discuss good choices for "default" colors?



Depends on the goal: do you want the default to work for
everyone, or do you want the default to be prettier and/or
better for most people but absolutely suck for a few?



I was thinking perhaps of having a predefined set of templates
(with the option and documentation to add your own). Perhaps
implement one that creates the "traffic-light" style that seems
to make intuitive sense to many americans (Bold Red: error, Bold
Green: Success, Bold Yellow: warning/notice), and also have
another perdefined one that uses a different color set.


"Traffic-light" style is also designed to be useable by completely
color-blind people - which is rare.  By that if you notice traffic
lights are always in the same order, green, yellow, red so that all
you have to do is be able to see the luminance value in the
abscence of any chroma information..

That's the problem with web-sites which depend on chroma value, and
often have colors which are easily discernable by normally sighted
people, but the luminance is very close which can make things
almost invisible.

I have a noticed a traffic-sign problem which another person also
wrote to the local newspaper - and the traffic division is looking
to change the signs.

In Florida bright days are indeed very bright.  There are signs
that use lights to spell out the message with what someone feels
the most important part in 'red'. The signs have a black
background.

On a bright day I see  "NO TURN ON "  or "TO PEDS"   as 
the word RED in the first message is invisible to me, and 
the YIELD in the second has the same effect.


There is also a sign that I came up to that used the universal
sign for turn.  I started to turn and my wife had me stop because
the circle with bar through it was in RED and I could not see it.

On overcast days or at night these signs are easily viewable.

For those of you who remember the late 1980s when IBM came out with
OS/2 and MS came out with a new Windows, the complaints were the
default screens on OS/2 were drab while the Windows had bright
colors.  IBM is very good at designing things for people with
disabilites and the OS/2 default screen was designed to be readable
by someone with total color-blindness - which as I said is rare.

The way to check if a web-site is readable by all it to use
a monochrome monitor [ exceedingly hard to find nowdays ], and 
at least some government sites are now required to be that way.


Color can be a great way to emphasize items >IF< the chroma
and luminance values are carefully chosen.  If not you can take
away a lot of functionality.


Bill - thanks for all the info here.  I feel it's important for this to 
work for users with all kinds of vision differences, so can you confirm 
(or not) whether the b/w version (rc_fancy="YES", but 
rc_fancy_color="NO") looks readable to you? (please use patch 7)


Thanks!
Eric



--

Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Server choice.

2006-04-20 Thread Eric Anderson 

Paul Halliday wrote:

Hi,

I am in the process of building a new database server and after
pricing up 2 Dell models I thought I would throw this out just to see
which choice would be better suited for FreeBSD.

The demands on the system will be mostly network -> disk I/O with a
hope of best performance on quickly servicing numerous reads; for
example when reports are generated using the data in the database.

The 2 choices (we dont have that much money and they have to be Dell)
are a poweredge 1850 and a poweredge 850.

850 specs.

Procsesor: Pentium(Dual Core) 830 @ 3.0GHz/2X1MB Cache 800MHz FSB
Memory: 2GB DDR2, 533MHz (2x1GB) Dual ranked DIMMs
Disks: SATA

1850 specs.
--
Processors: 2 @ Xeon @ 3.0GHz/2MB Cache 800MHz FSB
Memory: 2GB DDR2, 400MHz (4x512) Single ranked DIMMs
Disks: Ultra 320

The pricing is really close.


I'm not sure the type of memory<->cpu utilization that mysql will do, 
however I can tell you that in a number of applications that do lots of 
cpu cache utilization, the 2x Xeon will knock over the dual-core.


I'd go with the 1850 (we have stacks of these in house).

Eric




--

Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Server choice.

2006-04-20 Thread Paul Halliday 
Hi,

I am in the process of building a new database server and after
pricing up 2 Dell models I thought I would throw this out just to see
which choice would be better suited for FreeBSD.

The demands on the system will be mostly network -> disk I/O with a
hope of best performance on quickly servicing numerous reads; for
example when reports are generated using the data in the database.

The 2 choices (we dont have that much money and they have to be Dell)
are a poweredge 1850 and a poweredge 850.

850 specs.

Procsesor: Pentium(Dual Core) 830 @ 3.0GHz/2X1MB Cache 800MHz FSB
Memory: 2GB DDR2, 533MHz (2x1GB) Dual ranked DIMMs
Disks: SATA

1850 specs.
--
Processors: 2 @ Xeon @ 3.0GHz/2MB Cache 800MHz FSB
Memory: 2GB DDR2, 400MHz (4x512) Single ranked DIMMs
Disks: Ultra 320

The pricing is really close.

Thanks.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC - v6

2006-04-20 Thread Eric Anderson 

David Barbero wrote:

Eric Anderson escribió:

Thanks to Rick Petty for pointing me in the right direction (man page!),
here's the latest, and I think solid patch (for RELENG-6):


http://www.googlebit.com/freebsd/patches/rc_fancy.patch-6


Eric



Hi all.

I have found several anomalies operations in the patch.

After to apply the patch, so that it works is necessary to put in rc.conf
rc_fancy="YES ", when put this single entry, the system gives errors
saying that correctly this entry in rc.conf is not correctly defined,
adding single rc_fancy_color="YES" gives the same error.
If the two entry meetings are added it don't show the error.
I believe that serious advisable that these two entry did not depend the
one on the other and worked separately.


Well, obviously the _color option depends on the rc_fancy option being 
enabled, otherwise it doesn't make sense, however you can of course have 
rc_fancy enabled with rc_fancy_color disabled.



Another failure with which I have been is that after apply the patch and
to take the normal system, without the entry rc_fancy * the system does
not show such messages exactly, leave several points between the lines of
the services.
Ej:
starting sendmail
.
.
.
starting apache

and it would have to see itself of the following way:

starting sendmail
starting apache


Yep, that's a bug.  I think it's fixed in v7, available here:

http://www.googlebit.com/freebsd/patches/rc_fancy.patch-7

along with a few other suggestions from others.



Another one of the failures that I have seen is that with this patch they
show all the services, they are or not formed to start, I believe that
single they would have to appear the services that are formed to start and
not all those that can start.


If the service is run on bootup, it shows it.  It was still being run 
before, there was just no output previously.  It would be pretty easy to 
have an option to not print these, maybe an rc_fancy_verbose option.  Is 
this desirable to most?



In addition  the services that are not formed to start appear like [ OK ],
in the case of appearing these, I believe that they would have to leave
with another denomination that is not [ OK ].



I'm not sure what you mean here.  Can you give me an example?



Another failure that I have seen is that when leaving the message syslogd
this sample failure, but this service starts without problems, but shows
it as if it gave failure...


My syslogd looks clean, and doesn't give a false failure.  I'm not sure 
how to look into this - can you confirm that it truly is passing, but 
giving the wrong message, or is it that the rc subsystem thinks it's 
failing but appears to work ok?




In principle this is what I have seen at first sight on the patch.



Thanks for all the feedback and testing!


Eric



--

Eric AndersonSr. Systems AdministratorCentaur Technology
Anything that works is better than anything that doesn't.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

2006-04-20 Thread Mike Meyer 
In <[EMAIL PROTECTED]>, Bill Vermillion <[EMAIL PROTECTED]> typed:
> The way to check if a web-site is readable by all it to use
> a monochrome monitor [ exceedingly hard to find nowdays ], and 
> at least some government sites are now required to be that way.

This is part of "section 508", and *all* web sites run by
organizations that receive US government monies are supposed to comply
with it. The government doesn't do a lot to enforce this, though.

FWIW, the last time I checked, the question of whether or not a web
site that wasn't covered by section 508 was covered by the ADA was
still up in the air, hinging on whether or not a web site constituted
a "public place" (but it's been a while since I checked).

  http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] Fancy rc startup style RFC

2006-04-20 Thread Bill Vermillion 
While stranded on the shoulder of the Information
Superhiway and trying to flag down some passing bytes
[EMAIL PROTECTED] said "Bits don't fail me now",
and continued with:

> Date: Wed, 19 Apr 2006 13:03:57 -0400
> From: "Coleman Kane" <[EMAIL PROTECTED]>
> Subject: Re: [PATCH] Fancy rc startup style RFC

> On 4/19/06, Mike Meyer <[EMAIL PROTECTED]> wrote:

> > In
> > <[EMAIL PROTECTED]>,
> > Coleman Kane <[EMAIL PROTECTED]> typed:

> > > On 4/19/06, Mike Meyer
> > > <[EMAIL PROTECTED]  wrote:

> > > How about we all discuss good choices for "default" colors?

> > Depends on the goal: do you want the default to work for
> > everyone, or do you want the default to be prettier and/or
> > better for most people but absolutely suck for a few?

> I was thinking perhaps of having a predefined set of templates
> (with the option and documentation to add your own). Perhaps
> implement one that creates the "traffic-light" style that seems
> to make intuitive sense to many americans (Bold Red: error, Bold
> Green: Success, Bold Yellow: warning/notice), and also have
> another perdefined one that uses a different color set.

"Traffic-light" style is also designed to be useable by completely
color-blind people - which is rare.  By that if you notice traffic
lights are always in the same order, green, yellow, red so that all
you have to do is be able to see the luminance value in the
abscence of any chroma information..

That's the problem with web-sites which depend on chroma value, and
often have colors which are easily discernable by normally sighted
people, but the luminance is very close which can make things
almost invisible.

I have a noticed a traffic-sign problem which another person also
wrote to the local newspaper - and the traffic division is looking
to change the signs.

In Florida bright days are indeed very bright.  There are signs
that use lights to spell out the message with what someone feels
the most important part in 'red'. The signs have a black
background.

On a bright day I see  "NO TURN ON "  or "TO PEDS"   as 
the word RED in the first message is invisible to me, and 
the YIELD in the second has the same effect.

There is also a sign that I came up to that used the universal
sign for turn.  I started to turn and my wife had me stop because
the circle with bar through it was in RED and I could not see it.

On overcast days or at night these signs are easily viewable.

For those of you who remember the late 1980s when IBM came out with
OS/2 and MS came out with a new Windows, the complaints were the
default screens on OS/2 were drab while the Windows had bright
colors.  IBM is very good at designing things for people with
disabilites and the OS/2 default screen was designed to be readable
by someone with total color-blindness - which as I said is rare.

The way to check if a web-site is readable by all it to use
a monochrome monitor [ exceedingly hard to find nowdays ], and 
at least some government sites are now required to be that way.

Color can be a great way to emphasize items >IF< the chroma
and luminance values are carefully chosen.  If not you can take
away a lot of functionality.

Bill
-- 
Bill Vermillion - bv @ wjv . com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [fbsd] Re: Symbol weirdness with static linking

2006-04-20 Thread Jeremie Le Hen 
Hi, Kostik,

On Thu, Apr 20, 2006 at 03:48:29PM +0300, Kostik Belousov wrote:
> It seems that you rebuilt world with CFLAGS -fstack-protector,
> since your libc has references to the symbols like __stack_smash_handler.
> As result, when linking with sequence -lgcc -lssp -lc -lgcc -lssp,
> and no references from the main object,
> references from libc causes objects from _second_ instance of -lssp to
> be pulled into the link. Since libraries are scanned sequentially,
> this object from libssp has no way to get required dependencies
> from libc.
> 
> What makes syslog(3) special is that corresponding object from libc,
> syslog.o, requires __stack_smash_handler, while objects for mentioned
> syscalls do not.
> 
> Probably, another -lc after -lssp will change the situation. But
> I'm not sure would it be enough or not.

You got the point.  If I add another -lc after the second -lssp,
this solves the problem :

/usr/bin/ld -V -Bstatic -o echo /usr/obj/usr/src/tmp/usr/lib/crt1.o 
/usr/obj/usr/src/tmp//usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbegin.o 
-L/usr/obj/usr/src/tmp/usr/lib echo.o -lgcc -lssp -lc 
/usr/obj/usr/src/tmp/usr/lib/crtend.o /usr/obj/usr/src/tmp/usr/lib/crtn.o

Another way to solve this is to group libraries using "-(" and "-)" ld(1)
options :

/usr/bin/ld -V -Bstatic -o echo /usr/obj/usr/src/tmp/usr/lib/crt1.o 
/usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbegin.o 
-L/usr/obj/usr/src/tmp/usr/lib echo.o -lgcc -lssp -\( -lc -lgcc -lssp -\) 
/usr/obj/usr/src/tmp/usr/lib/crtend.o /usr/obj/usr/src/tmp/usr/lib/crtn.o

Thank you for your answer.
Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Symbol weirdness with static linking

2006-04-20 Thread Kostik Belousov 
On Thu, Apr 20, 2006 at 01:48:22PM +0200, Jeremie Le Hen wrote:
> Hi hackers,
> 
> I created a library (libssp) which is to be linked in the same time as
> libgcc (GCC's LIBGCC_SPEC [1]).  This library is intended to provide the
> required symbols for ProPolice/SSP (Stack-Smashing Protector) which GCC
> references whenever it has to protect a function.
> 
> This works almost perfectly but in one edge case : some programs
> are so "simple" (IOW have no stack-based buffer) that GCC does not
> feel the need to put any reference to the above symbols.  For instance,
> bin/echo and bin/mkdir are such programs.
> 
> When libssp is linked dynamically, this is not a problem.  However, if
> I use NO_DYNAMICROOT when building world, ld(1) complains that it does not
> find the "syslog" symbol [2].  It happens that libssp uses syslog(3), but
> since libssp won't be in the resulting executable, I don't understand
> why ld(1) complains.
> 
> OTOH, programs which do have a reference to ProPolice symbols compile
> without any problem.
> 
> Even weirder, while there are other calls to libc functions in libssp
> - such as open(2), sigfillset(3) or sigprocmask(2) - if I comment out
> the call to syslog(3), ld(1) does not complain any longer.  What is
> so special with libc's "syslog" symbol ?  I don't understand what is
> the difference here between, the "syslog" symbol and, say, the "sigfilset"
> symbol (which is not used in echo(1) either).
> 
> For the sake of completeness, I added the output of some objdump(1)
> outputs here :
> 
> /usr/obj/usr/src/bin/echo/echo.o:
> http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_echo.txt.gz
> 
> /usr/obj/usr/src/tmp/usr/lib/libc.a:
> http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libc.txt.gz
> 
> /usr/obj/usr/src/tmp/usr/lib/libssp.a:
> http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libssp.txt.gz
> 
> 
> Thank you.
> Regards,
> 
> 
> [1]
> #define LIBGCC_SPEC "%{shared: -lgcc_pic -lssp_pic} %{!shared: %{!pg: -lgcc 
> -lssp} %{pg: -lgcc_p -lssp_p}}"
> 
> 
> [2]
> ===> bin/echo (all)
> cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -fstack-protector 
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter 
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c 
> /usr/src/bin/echo/echo.c
> cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -fstack-protector 
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
> -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter 
> -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls  -v -static -o 
> echo echo.o
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.4.4 [FreeBSD] 20050518
>  /usr/obj/usr/src/tmp/usr/bin/ld -V -Bstatic -o echo 
> /usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o 
> /usr/obj/usr/src/tmp/usr/lib/crtbegin.o -L/usr/obj/usr/src/tmp/usr/lib echo.o 
> -lgcc -lssp -lc -lgcc -lssp /usr/obj/usr/src/tmp/usr/lib/crtend.o 
> /usr/obj/usr/src/tmp/usr/lib/crtn.o
> GNU ld version 2.15 [FreeBSD] 2004-05-23
>   Supported emulations:
>elf_i386_fbsd
> /usr/obj/usr/src/tmp/usr/lib/libssp.a(ssp.o)(.text+0xe8): In function 
> `__stack_smash_handler':
> : undefined reference to `syslog'
> *** Error code 1
> 
> -- 
> Jeremie Le Hen
> < jeremie at le-hen dot org >< ttz at chchile dot org >

It seems that you rebuilt world with CFLAGS -fstack-protector,
since your libc has references to the symbols like __stack_smash_handler.
As result, when linking with sequence -lgcc -lssp -lc -lgcc -lssp,
and no references from the main object,
references from libc causes objects from _second_ instance of -lssp to
be pulled into the link. Since libraries are scanned sequentially,
this object from libssp has no way to get required dependencies
from libc.

What makes syslog(3) special is that corresponding object from libc,
syslog.o, requires __stack_smash_handler, while objects for mentioned
syscalls do not.

Probably, another -lc after -lssp will change the situation. But
I'm not sure would it be enough or not.


pgpwFfKveVUTf.pgp
Description: PGP signature

Re: [PATCH] Fancy rc startup style RFC - v6

2006-04-20 Thread David Barbero 

Eric Anderson escribió:
>
> Thanks to Rick Petty for pointing me in the right direction (man page!),
> here's the latest, and I think solid patch (for RELENG-6):
>
>
> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-6
>
>
> Eric
>

Hi all.

I have found several anomalies operations in the patch.

After to apply the patch, so that it works is necessary to put in rc.conf
rc_fancy="YES ", when put this single entry, the system gives errors
saying that correctly this entry in rc.conf is not correctly defined,
adding single rc_fancy_color="YES" gives the same error.
If the two entry meetings are added it don't show the error.
I believe that serious advisable that these two entry did not depend the
one on the other and worked separately.

Another failure with which I have been is that after apply the patch and
to take the normal system, without the entry rc_fancy * the system does
not show such messages exactly, leave several points between the lines of
the services.
Ej:
starting sendmail
.
.
.
starting apache

and it would have to see itself of the following way:

starting sendmail
starting apache

Another one of the failures that I have seen is that with this patch they
show all the services, they are or not formed to start, I believe that
single they would have to appear the services that are formed to start and
not all those that can start.
In addition  the services that are not formed to start appear like [ OK ],
in the case of appearing these, I believe that they would have to leave
with another denomination that is not [ OK ].

Another failure that I have seen is that when leaving the message syslogd
this sample failure, but this service starts without problems, but shows
it as if it gave failure...

In principle this is what I have seen at first sight on the patch.

Regards.

-- 
"Linux is for people who hate Windows, BSD is for
people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Symbol weirdness with static linking

2006-04-20 Thread Jeremie Le Hen 
Hi hackers,

I created a library (libssp) which is to be linked in the same time as
libgcc (GCC's LIBGCC_SPEC [1]).  This library is intended to provide the
required symbols for ProPolice/SSP (Stack-Smashing Protector) which GCC
references whenever it has to protect a function.

This works almost perfectly but in one edge case : some programs
are so "simple" (IOW have no stack-based buffer) that GCC does not
feel the need to put any reference to the above symbols.  For instance,
bin/echo and bin/mkdir are such programs.

When libssp is linked dynamically, this is not a problem.  However, if
I use NO_DYNAMICROOT when building world, ld(1) complains that it does not
find the "syslog" symbol [2].  It happens that libssp uses syslog(3), but
since libssp won't be in the resulting executable, I don't understand
why ld(1) complains.

OTOH, programs which do have a reference to ProPolice symbols compile
without any problem.

Even weirder, while there are other calls to libc functions in libssp
- such as open(2), sigfillset(3) or sigprocmask(2) - if I comment out
the call to syslog(3), ld(1) does not complain any longer.  What is
so special with libc's "syslog" symbol ?  I don't understand what is
the difference here between, the "syslog" symbol and, say, the "sigfilset"
symbol (which is not used in echo(1) either).

For the sake of completeness, I added the output of some objdump(1)
outputs here :

/usr/obj/usr/src/bin/echo/echo.o:
http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_echo.txt.gz

/usr/obj/usr/src/tmp/usr/lib/libc.a:
http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libc.txt.gz

/usr/obj/usr/src/tmp/usr/lib/libssp.a:
http://tataz.chchile.org/~tataz/symbol_weirdness/objdump-t_libssp.txt.gz


Thank you.
Regards,


[1]
#define LIBGCC_SPEC "%{shared: -lgcc_pic -lssp_pic} %{!shared: %{!pg: -lgcc 
-lssp} %{pg: -lgcc_p -lssp_p}}"


[2]
===> bin/echo (all)
cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -fstack-protector 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c 
/usr/src/bin/echo/echo.c
cc -O2 -fno-strict-aliasing -pipe -march=pentium-m -fstack-protector 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type 
-Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter 
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls  -v -static -o 
echo echo.o
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
 /usr/obj/usr/src/tmp/usr/bin/ld -V -Bstatic -o echo 
/usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o 
/usr/obj/usr/src/tmp/usr/lib/crtbegin.o -L/usr/obj/usr/src/tmp/usr/lib echo.o 
-lgcc -lssp -lc -lgcc -lssp /usr/obj/usr/src/tmp/usr/lib/crtend.o 
/usr/obj/usr/src/tmp/usr/lib/crtn.o
GNU ld version 2.15 [FreeBSD] 2004-05-23
  Supported emulations:
   elf_i386_fbsd
/usr/obj/usr/src/tmp/usr/lib/libssp.a(ssp.o)(.text+0xe8): In function 
`__stack_smash_handler':
: undefined reference to `syslog'
*** Error code 1

-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Is there compressed fs?

2006-04-20 Thread Alex Lyashkov 
look into mkuzip and geom_uzip.

В Чтв, 20.04.2006, в 05:59, Yoshihiro Ota пишет:
> Is there a compressed file system available in FreeBSD?
> 
> I tried "mdconfig -ocompress" but it doesn't seem saving any spaces.
> Does anyone know what is the status of this, if it works, and if so,
> how it works?
> 
> Thanks,
> Hiro
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Is there compressed fs?

2006-04-20 Thread Yoshihiro Ota 
On Wed, 19 Apr 2006 21:59:48 -0500
Yoshihiro Ota <[EMAIL PROTECTED]> wrote:

> Is there a compressed file system available in FreeBSD?
> 
> I tried "mdconfig -ocompress" but it doesn't seem saving any spaces.
> Does anyone know what is the status of this, if it works, and if so,
> how it works?

Thanks to a couple of people who directly sent me a response.

I was aware of GEOM_UZIP and mkuzip.  However, the problem is
it is read-only file system.  I am looking for read-write
compressed file system.

Thanks,
Hiro 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"