RE: [PATCH] Fancy rc startup style RFC
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Brooks Davis > Sent: Thursday, 20 April 2006 9:58 AM > To: Bruce M Simpson; [EMAIL PROTECTED]; Eric Anderson; > freebsd-hackers@freebsd.org > Subject: Re: [PATCH] Fancy rc startup style RFC > > On Thu, Apr 20, 2006 at 12:43:43AM +0100, Bruce M Simpson wrote: > > On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: > > > My point is that we should let our purist values get in > the way of others' > > > enhanced experience using the system. > > > > My view is: We take the patch, as long as it doesn't interfere with > > the internal machinations of rc too much. > > > > There are good aesthetic and functional arguments on either side. > > Given the excellent work on rc to date, we have clean > abstractions in > > rc itself, so fitting colour-aesthetics in does not have a high > > maintenance cost. > > I agree with this line of reasoning. So long as things are > kept modular and don't cause maintance headaches when working > on the internals I'd like to see this sort of work encouraged > and encorporated into the tree. While there's something to > be said for console output that shows everthing there's also > something to be said for console output that only shows whats > actually important. Giving people room to explore other > options could yeild something much better than what we currently have. > > -- Brooks My 0.02c worth - one of the Unix precepts for command line tools is silence = no error This is to consciously aid and abet the pipelining of programs Which is a major strength of Unix.. >From "The Art of Unix Programming" http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2877684 Also http://www.catb.org/~esr/writings/taoup/html/ch11s01.html The whole site is a good read. And Albert speaks well too (see sig below) mjt -- "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein --- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters. --- ***This Email has been scanned for Viruses by MailMarshal.*** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: [PATCH] Fancy rc startup style RFC
They all laughed on Wed, Apr 19, 2006 at 13:32 when Mike Meyer said: > In <[EMAIL PROTECTED]>, Sergey Babkin <[EMAIL PROTECTED]> typed: > > >From: Bill Vermillion <[EMAIL PROTECTED]> > > > > has some > > >color vision problem. Mine is a bit more than others. Everytime > > >I get called to work on a Linux system, I have to go in and disable > > >the colors as the reds and other colors become very hard to see > > >against a dark background. The problem is the luminance value of > > >colors such a red is quite low compared to others. > > The problem with Linux colors is that they have been > > designed to be used on the white background which is > > the xterm's default (and which I hate as it's tough > > on my eyes). Since I usually use the black background, > > I disable them too. > > So where do linux's blasted ls colors come from? It prints some file > type as green. Green on white is simply bad news, whether or not you > have vision problems. I always have to go disable them (and some linux > distros make them *hard* to disable). I just checked in on one Linux machine I admin - SuSE 9.2 - and the colors are set with the variable LS_OPTIONS. I've set LS_OPTIONS to '-N --color=none -T 0' And looking at the .bashrc there is also a test for the binary dircolors, and then looks for user files .dir_colors I also notice that as shipped the .bashrc has a comment line that says If LS_COLROS is set but empty the terminal has no colors. It is spelled COLROS not COLORS - but that's just cosmetic and sloppy. 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]"
Is there compressed fs?
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]"
Re: [PATCH] Fancy rc startup style RFC
On 2006-04-19, Brooks Davis wrote: > On Thu, Apr 20, 2006 at 12:43:43AM +0100, Bruce M Simpson wrote: > > On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: > > > My point is that we should let our purist values get in the way of others' > > > enhanced experience using the system. > > > > My view is: We take the patch, as long as it doesn't interfere with > > the internal machinations of rc too much. > > > > There are good aesthetic and functional arguments on either side. > > Given the excellent work on rc to date, we have clean abstractions > > in rc itself, so fitting colour-aesthetics in does not have a high > > maintenance cost. > > I agree with this line of reasoning. So long as things are kept > modular and don't cause maintance headaches when working on the > internals I'd like to see this sort of work encouraged and encorporated > into the tree. While there's something to be said for console output > that shows everthing there's also something to be said for console > output that only shows whats actually important. Giving people room to > explore other options could yeild something much better than what we > currently have. Perhaps the default setup, while having all the pretty stuff turned off, could include one or two lines as close to the bottom of the output as possible that simply listed the new options so those who wanted them would know how to get the features and the rest of us would be gently reminded of what we were missing without damaging the output that we prefer. Greg ___ 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
On Thu, Apr 20, 2006 at 12:43:43AM +0100, Bruce M Simpson wrote: > On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: > > My point is that we should let our purist values get in the way of others' > > enhanced experience using the system. > > My view is: We take the patch, as long as it doesn't interfere with > the internal machinations of rc too much. > > There are good aesthetic and functional arguments on either side. > Given the excellent work on rc to date, we have clean abstractions > in rc itself, so fitting colour-aesthetics in does not have a high > maintenance cost. I agree with this line of reasoning. So long as things are kept modular and don't cause maintance headaches when working on the internals I'd like to see this sort of work encouraged and encorporated into the tree. While there's something to be said for console output that shows everthing there's also something to be said for console output that only shows whats actually important. Giving people room to explore other options could yeild something much better than what we currently have. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpuR810TJzAt.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
On Wed, Apr 19, 2006 at 10:46:09AM -0400, Coleman Kane wrote: > My point is that we should let our purist values get in the way of others' > enhanced experience using the system. My view is: We take the patch, as long as it doesn't interfere with the internal machinations of rc too much. There are good aesthetic and functional arguments on either side. Given the excellent work on rc to date, we have clean abstractions in rc itself, so fitting colour-aesthetics in does not have a high maintenance cost. I agree strongly with the functional arguments however and think that this stuff shouldn't be turned on by default. I think that it should be available in the base system for those who wish it. I feel that this should be both for aesthetic reasons and for promoting FreeBSD to the ultimate end, that is, to potential users, who may find it easier to relate to FreeBSD if the console messages are in colour, no matter how irrational that may seem to some! Regards, BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel Fatal Trap 12
Kris Kennaway wrote this message on Wed, Apr 19, 2006 at 14:08 -0400: > On Wed, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote: > > Hum, is there a way to have a little idea of which hardware begun to fail ? > > Check CPU cooling, power supply, cabling, RAM, etc. Google for more - > this question is asked and answered about once a week. Just as a little bit of advice.. Make sure that there isn't dust in your cpu heat sink... and even if there isn't much dust, dust can cling to the blades of the heat sink preventing air flow and seriously limiting the ability of the heat sink to work... /me just had a computer randomly crash due to this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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
On Apr 19, 2006, at 2:07 PM, Eric Anderson wrote: Ok - first, let me remind everyone that this is for startup/ shutdown of scripts and such, not for ls and other things. I'd also like to remind everyone that the default for the whole thing can be OFF, so you won't even know the option exists if you don't want to know about it. If it is on, then the default is b/w like the current setup is, and currently no information is suppressed so there is no loss of helpful information on boot, only additional information (OK, FAILED, SKIP, etc). If someone doesn't like the colors, doesn't like the 'fancy' bootup, then they merely have to do nothing at all. This is a similar feature as rc_info is, and there's no issue there, because it's off by default. Same with the color daemon at the boot menu. I think it should be off by default, until enough people demand it on (if that happens at all), and then it should be b/w by default, with the option to make it color. My main goal was to implement this with as little reworking of the current system as possible, yet still reap rewards of easy readability when the system boots. I hate to even suggest this, but perhaps we should add a desktop vs server option when installing freebsd. It wouldn't effect packages used, but might change a few defaults such as this new fancy startup. People using terminals and such would still get their black and white startup and everyone else would get the nice color startup. Anyone using a desktop or sys admins who have video cards in their servers and never tend to debug anything would like it. I think PC-BSD and DesktopBSD show there is a demand for FreeBSD on the desktop. It might be time we acknowledge that. Adding color doesn't minimize the "power to serve." As much as I love FreeBSD, sometimes its difficult to get others to try it simply because the project is so difficult about desktop usage. People often try out a new OS on a desktop before using it on production servers. Few people just risk it like I did a few years ago. In my case, I just didn't want linux. Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysctl(3) and sysctl(8) discrepancies
In the last episode (Apr 19), Mathieu Prevot said:
> Hello,
>
> I have FreeBSD 6.1-RC #27: Wed Apr 19 02:08:00 CEST 2006 amd64 and I have 3
> different outputs about hw.ncpu:
>
> `sysctl hw.ncpu` gives me:
>
> 'hw.ncpu: 2'
>
>
> and I have:
>
> hw.ncpu = 6
> hw.ncpu = 3
>
>
> with:
>
> #include
> #include
> #include
>
> main()
> {
> int ncpu[1];
> size_t len;
>
> len=sizeof(int);
> sysctlnametomib("hw.ncpu",ncpu,&len);
You want sysctlbyname() here instead. sysctlnametomib() returns a
pointer to a mib array that you can pass to the sysctl() function
later. Saves having to parse the string every time if you are looking
up the same sysctl repeatedly.
sysctlbyname("hw.ncpu", &ncpu, &len, NULL, 0);
HW_NCPU is the mib number for hw.ncpu if you want to build the mib
array manually.
--
Dan Nelson
[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: Kernel Fatal Trap 12
Hum ... first thing done before reinstalling freebsd 2 passes without errors For the little story, i don't know if it could help, My network is like that : LAN <-> FreeBSD Gateway <-> ISP Router <-> Internet Each 22 hours the isp router reboot the internet connection and usually the freebsd gateway crash when the isp router stop and restart the internet connection but it's not all the time, there could be few days without problem (max 12 days I think). So I can't say that the isp router make the freebsd crashing but when it crash it's very often when the isp router restart :-/ I'll continue to test the hardware Thanks to Kris & Steve -- Thomas SOETE Etudiant Ingénieur Télécom - Enic Télécom Lille 1 Etudiant Master Recherche, Conception de Systèmes Embarqués - LIFL WWW : http://toms.netcv.org/ Mail & MSN : [EMAIL PROTECTED] GTalk : [EMAIL PROTECTED] Steve Kargl a écrit : On Wed, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote: Kris Kennaway a ?crit : On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote: Hi everybody Since a little time I began to have some kernel fatal trap 12 Kernel panics that magically start for no reason after a long time of stability are usually because your hardware has begun to fail. Kris Hum, is there a way to have a little idea of which hardware begun to fail ? (Top post fixed!) Start by checking memory. If you have x86 hardware, then look at memtest86+. http://www.memtest.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel Fatal Trap 12
On Wed, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote: > Hum, is there a way to have a little idea of which hardware begun to fail ? Check CPU cooling, power supply, cabling, RAM, etc. Google for more - this question is asked and answered about once a week. Kris pgp61xkB8fejK.pgp Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
Bill Vermillion wrote: "Ang utong ko ay sasabog sa sarap!" exclaimed Sergey Babkin while reading this message on Wed, Apr 19, 2006 at 12:18 and then responded with: From: Bill Vermillion <[EMAIL PROTECTED]> has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. When I have time and patience to mess around, I set the LS_COLORS and such variables to the complementary bitmasks of what they've been, and that fixes the problem with contrast on the black background. Well I run in 80x24 text mode almost all the time, and when I need some graphics/web stuff I hit the KVM and move to an XP machine. I use vidcontrol to set my screen /home/bv/.profile:vidcontrol green black /home/bv/.profile:vidcontrol -b blue /home/bv/.profile:vidcontrol -c blink That gives me green on black, with a blue border defining the edge of the screen. With my vision it works very well. I got to something with white on black and I find it too bright to use, except on dying monitors :-) [I've had some clients with really bad server monitors - typically SCO. On those I'd set the white to bright white to make them readable] Ok - first, let me remind everyone that this is for startup/shutdown of scripts and such, not for ls and other things. I'd also like to remind everyone that the default for the whole thing can be OFF, so you won't even know the option exists if you don't want to know about it. If it is on, then the default is b/w like the current setup is, and currently no information is suppressed so there is no loss of helpful information on boot, only additional information (OK, FAILED, SKIP, etc). If someone doesn't like the colors, doesn't like the 'fancy' bootup, then they merely have to do nothing at all. This is a similar feature as rc_info is, and there's no issue there, because it's off by default. Same with the color daemon at the boot menu. I think it should be off by default, until enough people demand it on (if that happens at all), and then it should be b/w by default, with the option to make it color. My main goal was to implement this with as little reworking of the current system as possible, yet still reap rewards of easy readability when the system boots. 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: Kernel Fatal Trap 12
On Wed, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote: > Kris Kennaway a ?crit : > >On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote: > > > >>Hi everybody > >>Since a little time I began to have some kernel fatal trap 12 > >> > > > >Kernel panics that magically start for no reason after a long time of > >stability are usually because your hardware has begun to fail. > > > >Kris > > > > Hum, is there a way to have a little idea of which hardware begun to fail ? > (Top post fixed!) Start by checking memory. If you have x86 hardware, then look at memtest86+. http://www.memtest.org/ -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel Fatal Trap 12
Hum, is there a way to have a little idea of which hardware begun to fail ? -- Thomas SOETE Etudiant Ingénieur Télécom - Enic Télécom Lille 1 Etudiant Master Recherche, Conception de Systèmes Embarqués - LIFL WWW : http://toms.netcv.org/ Mail & MSN : [EMAIL PROTECTED] GTalk : [EMAIL PROTECTED] Kris Kennaway a écrit : On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote: Hi everybody Since a little time I began to have some kernel fatal trap 12 Kernel panics that magically start for no reason after a long time of stability are usually because your hardware has begun to fail. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel Fatal Trap 12
On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote: > Hi everybody > Since a little time I began to have some kernel fatal trap 12 Kernel panics that magically start for no reason after a long time of stability are usually because your hardware has begun to fail. Kris pgpGuwqbOuIMP.pgp Description: PGP signature
Kernel Fatal Trap 12
Hi everybody
Since a little time I began to have some kernel fatal trap 12
I had FreeBSD 5.3 and I decided to install 6.0 to avoid this problem
(thinking that the bug was patched between these versions)
But after installing all, the kernel panic is still there
uname -a output :
FreeBSD freebsd 6.0-RELEASE-p6 FreeBSD 6.0-RELEASE-p6 #0: Mon Apr 17
19:27:35 CEST 2006 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TOMS i386
where kgdb :
#0 doadump () at pcpu.h:165
#1 0xc04b4c76 in boot (howto=260) at ../../../kern/kern_shutdown.c:399
#2 0xc04b4f0c in panic (fmt=0xc05e963d "%s")
at ../../../kern/kern_shutdown.c:555
#3 0xc05cce40 in trap_fatal (frame=0xd5cf9ad8, eva=88)
at ../../../i386/i386/trap.c:831
#4 0xc05ccbab in trap_pfault (frame=0xd5cf9ad8, usermode=0, eva=88)
at ../../../i386/i386/trap.c:742
#5 0xc05cc7e9 in trap (frame=
{tf_fs = -1067712504, tf_es = -1048772568, tf_ds = 40, tf_edi = 0,
tf_esi = 0, tf_ebp = -707814604, tf_isp = -707814652, tf_ebx =
-707814256, tf_edx = -707814000, tf_ecx = 0, tf_eax = 8, tf_trapno = 12,
tf_err = 2, tf_eip = -1068217761, tf_cs = 32, tf_eflags = 66183, tf_esp
= -707814612, tf_ss = 8})
at ../../../i386/i386/trap.c:432
#6 0xc05bbfda in calltrap () at ../../../i386/i386/exception.s:139
#7 0xc0544a5f in ip_ctloutput (so=0x8, sopt=0xd5cf9c90)
at ../../../netinet/ip_output.c:1208
#8 0xc0552c03 in tcp_ctloutput (so=0xc16ca164, sopt=0xd5cf9c90)
at ../../../netinet/tcp_usrreq.c:1036
#9 0xc04ee3cc in sosetopt (so=0xc16ca164, sopt=0xd5cf9c90)
at ../../../kern/uipc_socket.c:1553
#10 0xc04f3629 in kern_setsockopt (td=0xc17d2d80, s=14, level=8, name=8,
val=0xd5cf9d90, valseg=UIO_USERSPACE, valsize=0)
at ../../../kern/uipc_syscalls.c:1331
#11 0xc04f355a in setsockopt (td=0xc17d2d80, uap=0x8)
at ../../../kern/uipc_syscalls.c:1287
#12 0xc05cd157 in syscall (frame=
{tf_fs = 139264059, tf_es = 59, tf_ds = -1078001605, tf_edi = 39,
tf_esi = 139367520, tf_ebp = -1077941204, tf_isp = -707814044, tf_ebx =
138942556, tf_edx = 14, tf_ecx = 139367616, tf_eax = 105, tf_trapno =
22, tf_err = 2, tf_eip = 677011411, tf_cs = 51, tf_eflags = 518, tf_esp
= -1077941248, tf_ss = 59})
at ../../../i386/i386/trap.c:976
#13 0xc05bc02f in Xint0x80_syscall () at ../../../i386/i386/exception.s:200
#14 0x0033 in ?? ()
I tried to investigate a little and I found that :
*#7 0xc0544a5f in ip_ctloutput (so=0x8, sopt=0xd5cf9c90)
at ../../../netinet/ip_output.c:1208
1208inp->inp_ip_tos = optval;
*and
(kgdb) p inp
$12 = (struct inpcb *) 0x0
ok ... p null pointer :-/
inp is : struct inpcb *inp = sotoinpcb(so);
and so is : (kgdb) p so $13 = (struct socket *) 0x8
hum strange, a pointer with value as 8 ...
and so was passed as parameter : #7 0xc0544a5f in ip_ctloutput
(so=0x8 , let see where it was called :
#8 0xc0552c03 in tcp_ctloutput (so=0xc16ca164, sopt=0xd5cf9c90)
at ../../../netinet/tcp_usrreq.c:1036
1036error = ip_ctloutput(so, sopt);
and between the call of tcp_ctloutput and ip_ctloutput so wasn't
changed, so it's value should be 0xc16ca164
(kgdb) p so
$14 = (struct socket *) 0xc16ca164
So why the value passed by the caller is different with the value in the
called function ?
If you could help me to find why my gateway crash allmost each time the
adsl connection drop it'll be nice :)
Thanks,
--
Thomas SOETE
Etudiant Ingénieur Télécom - Enic Télécom Lille 1
Etudiant Master Recherche, Conception de Systèmes Embarqués - LIFL
WWW : http://toms.netcv.org/
Mail & MSN : [EMAIL PROTECTED]
GTalk : [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: Re: [PATCH] Fancy rc startup style RFC
"Ang utong ko ay sasabog sa sarap!" exclaimed Sergey Babkin while reading this message on Wed, Apr 19, 2006 at 12:18 and then responded with: > >From: Bill Vermillion <[EMAIL PROTECTED]> > > has some > >color vision problem. Mine is a bit more than others. Everytime > >I get called to work on a Linux system, I have to go in and disable > >the colors as the reds and other colors become very hard to see > >against a dark background. The problem is the luminance value of > >colors such a red is quite low compared to others. > The problem with Linux colors is that they have been > designed to be used on the white background which is > the xterm's default (and which I hate as it's tough > on my eyes). Since I usually use the black background, > I disable them too. > When I have time and patience to mess around, I set the > LS_COLORS and such variables to the complementary > bitmasks of what they've been, and that fixes the > problem with contrast on the black background. Well I run in 80x24 text mode almost all the time, and when I need some graphics/web stuff I hit the KVM and move to an XP machine. I use vidcontrol to set my screen /home/bv/.profile:vidcontrol green black /home/bv/.profile:vidcontrol -b blue /home/bv/.profile:vidcontrol -c blink That gives me green on black, with a blue border defining the edge of the screen. With my vision it works very well. I got to something with white on black and I find it too bright to use, except on dying monitors :-) [I've had some clients with really bad server monitors - typically SCO. On those I'd set the white to bright white to make them readable] 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: Re: [PATCH] Fancy rc startup style RFC
In <[EMAIL PROTECTED]>, Sergey Babkin <[EMAIL PROTECTED]> typed: > >From: Bill Vermillion <[EMAIL PROTECTED]> > > has some > >color vision problem. Mine is a bit more than others. Everytime > >I get called to work on a Linux system, I have to go in and disable > >the colors as the reds and other colors become very hard to see > >against a dark background. The problem is the luminance value of > >colors such a red is quite low compared to others. > The problem with Linux colors is that they have been > designed to be used on the white background which is > the xterm's default (and which I hate as it's tough > on my eyes). Since I usually use the black background, > I disable them too. So where do linux's blasted ls colors come from? It prints some file type as green. Green on white is simply bad news, whether or not you have vision problems. I always have to go disable them (and some linux distros make them *hard* to disable). 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
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. BTW, I know that blue and red are "bad" colors. How to the "emphasized" or "emboldened" versions of these colors match up? I like the former. Which means the defaults need to be black and > white. Given a sufficiently flexible system for picking colors, we can > use bold/underline/reversed as "colors". That might work well under > that constraint. I am merely talking about predefined color choices... of course if rc_fancy_color="NO" then fancyiness will be B+W. I'd like to know if there are better choices than Red/Green/Yellow. To me Red/Green/Yellow make sense to a lot of people because of their relation to our driving system here in the states. Maybe something like Error=Yellow, Good=Blue, Warn/Notice=Green is a better choice across the board. -- > Mike Meyer <[EMAIL PROTECTED]> > 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]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: [PATCH] Fancy rc startup style RFC
>From: Bill Vermillion <[EMAIL PROTECTED]> has some >color vision problem. Mine is a bit more than others. Everytime >I get called to work on a Linux system, I have to go in and disable >the colors as the reds and other colors become very hard to see >against a dark background. The problem is the luminance value of >colors such a red is quite low compared to others. The problem with Linux colors is that they have been designed to be used on the white background which is the xterm's default (and which I hate as it's tough on my eyes). Since I usually use the black background, I disable them too. When I have time and patience to mess around, I set the LS_COLORS and such variables to the complementary bitmasks of what they've been, and that fixes the problem with contrast on the black background. -SB ___ 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
On Wed, Apr 19, 2006 at 05:57:21PM +1000, Peter Jeremy wrote:
> On Tue, 2006-Apr-18 15:02:27 -0500, Eric Anderson wrote:
> >Peter Jeremy wrote:
> >>>+ padding=""
> >>>+ paddingsize=$(($columns - 15 - $2 - $namesize))
> >>>+ until [ 0 = ${paddingsize} ]; do
> >>>+ padding=" $padding"
> >>>+ paddingsize=$(($paddingsize - 1))
> >>>+ done
> >>
> >>This particular block of code appears unnecessary (since $padding is
> >>unused).
> >
> >I must be missing something, because I'm pretty sure it's used.. What
> >did I miss?
>
> Actually, I had a closer look and I was wrong, sorry. I missed the
> '[ $2 = 0 ]' test. The code might be more legible (and is definitely
> more efficient) if the above code was moved into the else clause for
> that test.
>
> Also '[ $2 = 0 ]' should probably be written as '[ "0$2" -eq 0 ]', or
> similar, so that it doesn't blow up if there is no $2.
Or better use "${2:-0}" if that's what you mean. The idiom of
prepending stuff to a variable in a string to deal with the unassigned
variables has always seemed to me like it was a hold over from some
truly ancent shell without modern features. The '[ "x$var" = "x" ]'
idiom is even worse. Test has only had -z and -n for a decade or two...
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpkcS02eh9o4.pgp
Description: PGP signature
Re: [PATCH] Fancy rc startup style RFC
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 like the former. Which means the defaults need to be black and white. Given a sufficiently flexible system for picking colors, we can use bold/underline/reversed as "colors". That might work well under that constraint. 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
On 4/19/06, Mike Meyer <[EMAIL PROTECTED]> wrote: > > In <[EMAIL PROTECTED]>, Coleman > Kane <[EMAIL PROTECTED]> typed: > > On 4/19/06, Eric Anderson <[EMAIL PROTECTED]> wrote: > > > >>> Please do not use colors in rc. Escape-sequenced colors make > > > >>> unacceptable assumptions about the user and syslogd strips > > > >>> escape sequences anyway, so it would be of no use to logged > > > >>> consoles. Serial consoles introduce other problems with buggy > > > >>> escape handling in third-party terminal programs. A good text > > > >>> layout and descriptive status messages do far more for clarity > > > >>> and readability than any use of color ever can. > > This point can be debated... > > Only the last point, and only because it involves a quantity that's > very difficult to measure. > > > read some literature from Edward Tufte... > > I've read Tufte. I've gotten him to sign my copy of some of his books > at his seminars. I wish (vehemently!) that more web authors would read > Tufte. > > > colors are a good way to cram more "information" into a space without > > actually compromising the capacity of that space. > > True, but that's not his point. His point is that the colors aren't > always visible (another thing I wish more web authors were aware > of). The text layout and status messages should work well in > environments where the colors aren't visible, because there are times > when that's the kind of environment they'll be in. > > That said, colors can make checking for exceptions much easier - if > you can see them. So I don't have any problem with adding > colors. However, they should be off by default (at least initially), > and the messages and layout should be tested that way until they work > well without colors. I want to make a nicely configurable console message system that includes colors and formatting settable by the user (with a few sane defaults). I am familiar with the trouble of using red for errors (if you've ever seen red on a B+W TV you'll know too). How about we all discuss good choices for "default" colors? And, I think I am going to assemble some sort of "framework" sh script for this after all. Either it gets ammended to rc.subr, or it sits alone as its own dedicated module (that can be sourced by rc.*). -- > Mike Meyer <[EMAIL PROTECTED]> > 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]"
sysctl(3) and sysctl(8) discrepancies
Hello,
I have FreeBSD 6.1-RC #27: Wed Apr 19 02:08:00 CEST 2006 amd64 and I have 3
different outputs about hw.ncpu:
`sysctl hw.ncpu` gives me:
'hw.ncpu: 2'
and I have:
hw.ncpu = 6
hw.ncpu = 3
with:
#include
#include
#include
main()
{
int ncpu[1];
size_t len;
len=sizeof(int);
sysctlnametomib("hw.ncpu",ncpu,&len);
printf("hw.ncpu = %d\n",(*ncpu));
printf("hw.ncpu = %d\n",HW_NCPU);
exit(0);
}
Am I doing something wrong ?
Mathieu
___
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
In <[EMAIL PROTECTED]>, Coleman Kane <[EMAIL PROTECTED]> typed: > On 4/19/06, Eric Anderson <[EMAIL PROTECTED]> wrote: > > >>> Please do not use colors in rc. Escape-sequenced colors make > > >>> unacceptable assumptions about the user and syslogd strips > > >>> escape sequences anyway, so it would be of no use to logged > > >>> consoles. Serial consoles introduce other problems with buggy > > >>> escape handling in third-party terminal programs. A good text > > >>> layout and descriptive status messages do far more for clarity > > >>> and readability than any use of color ever can. > This point can be debated... Only the last point, and only because it involves a quantity that's very difficult to measure. > read some literature from Edward Tufte... I've read Tufte. I've gotten him to sign my copy of some of his books at his seminars. I wish (vehemently!) that more web authors would read Tufte. > colors are a good way to cram more "information" into a space without > actually compromising the capacity of that space. True, but that's not his point. His point is that the colors aren't always visible (another thing I wish more web authors were aware of). The text layout and status messages should work well in environments where the colors aren't visible, because there are times when that's the kind of environment they'll be in. That said, colors can make checking for exceptions much easier - if you can see them. So I don't have any problem with adding colors. However, they should be off by default (at least initially), and the messages and layout should be tested that way until they work well without colors. 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 - v6
On Wednesday 19 April 2006 16:39, Eric Anderson wrote: > Eric Anderson wrote: > > Eric Anderson wrote: > >> Bill Vermillion wrote: > >>> Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped > >>> and listened as [EMAIL PROTECTED] graced us with > >>> this profound tidbit of wisdom that would fulfill the enjoyment of > >>> > >>> future generations: > Message: 20 > Date: Tue, 18 Apr 2006 15:07:31 -0700 > From: Darren Pilgrim <[EMAIL PROTECTED]> > > Eric Anderson wrote: > > If I could figure out how to make sh do colors, I'd do it. :) > > Please do not use colors in rc. Escape-sequenced colors make > unacceptable assumptions about the user and syslogd strips > escape sequences anyway, so it would be of no use to logged > consoles. Serial consoles introduce other problems with buggy > escape handling in third-party terminal programs. A good text > layout and descriptive status messages do far more for clarity > and readability than any use of color ever can. > >>> > >>> Let me add to that. About 10% of the male population has some > >>> color vision problem. Mine is a bit more than others. Everytime > >>> I get called to work on a Linux system, I have to go in and disable > >>> the colors as the reds and other colors become very hard to see > >>> against a dark background. The problem is the luminance value of > >>> colors such a red is quite low compared to others. That's one of > >>> the reasons why fire-trucks in this area are lime-green, as red > >>> trucks disappear into the blackness at night. > >>> > >>> If you add color make sure it is a user selectable option > >>> and not turned on by default. IMO everything you need to admin a > >>> system needs to be able to run on something as lowly as a pure > >>> serial terminal as the above poster notes. > >> > >> Ok. So I've received mass amounts of mail regarding this, and most of > >> it has been positively in favor of having the option to enable the > >> rc_fancy, and then an additional option to turn on coloring, with the > >> default to be non-colored but still rc_fancy="YES" which should work > >> ok on serial and other terminals (it did for me). > >> > >> > >> I completely agree about all the coloring comments, and terminal > >> issues. I personally think it should be an available option, easily > >> enabled or disabled at will. > >> > >> I've put up an updated version, with many changes. This version > >> includes optional coloring (with rc_fancy_color="YES" in rc.conf), > >> better checking, cleaner coding, and no loops. This version is *much* > >> more refined than the others - thanks for all the hints everyone! > >> > >> > >> http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 > > > > Looks like this version does something strange - from an xterm, the > > spacing is correct, but from console, it doesn't do anything with the > > \033[71G in the echo. I've played with term types, but can't seem to > > make it act the same under console as it does in an xterm. > > > > Anyone know the issue? > > 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 Looks really good to me :) Regards, Pieter de Goeje ___ 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
On 4/19/06, Eric Anderson <[EMAIL PROTECTED]> wrote: > > Eric Anderson wrote: > > Bill Vermillion wrote: > >> Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped > >> and listened as [EMAIL PROTECTED] graced us with > >> this profound tidbit of wisdom that would fulfill the enjoyment of > >> future generations: > >> > >>> Message: 20 > >>> Date: Tue, 18 Apr 2006 15:07:31 -0700 > >>> From: Darren Pilgrim <[EMAIL PROTECTED]> > >> > >>> Eric Anderson wrote: > >> > >>> > If I could figure out how to make sh do colors, I'd do it. :) > >> > >>> Please do not use colors in rc. Escape-sequenced colors make > >>> unacceptable assumptions about the user and syslogd strips > >>> escape sequences anyway, so it would be of no use to logged > >>> consoles. Serial consoles introduce other problems with buggy > >>> escape handling in third-party terminal programs. A good text > >>> layout and descriptive status messages do far more for clarity > >>> and readability than any use of color ever can. This point can be debated... read some literature from Edward Tufte... colors are a good way to cram more "information" into a space without actually compromising the capacity of that space. >> > >> Let me add to that. About 10% of the male population has some > >> color vision problem. Mine is a bit more than others. Everytime > >> I get called to work on a Linux system, I have to go in and disable > >> the colors as the reds and other colors become very hard to see > >> against a dark background. The problem is the luminance value of > >> colors such a red is quite low compared to others. That's one of > >> the reasons why fire-trucks in this area are lime-green, as red > >> trucks disappear into the blackness at night. > >> > >> If you add color make sure it is a user selectable option > >> and not turned on by default. IMO everything you need to admin a > >> system needs to be able to run on something as lowly as a pure > >> serial terminal as the above poster notes. > > > > > > Ok. So I've received mass amounts of mail regarding this, and most of it > > has been positively in favor of having the option to enable the > > rc_fancy, and then an additional option to turn on coloring, with the > > default to be non-colored but still rc_fancy="YES" which should work ok > > on serial and other terminals (it did for me). > > > > > > I completely agree about all the coloring comments, and terminal issues. > > I personally think it should be an available option, easily enabled or > > disabled at will. > > > > I've put up an updated version, with many changes. This version > > includes optional coloring (with rc_fancy_color="YES" in rc.conf), > > better checking, cleaner coding, and no loops. This version is *much* > > more refined than the others - thanks for all the hints everyone! > > > > > > http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 > > Looks like this version does something strange - from an xterm, the > spacing is correct, but from console, it doesn't do anything with the > \033[71G in the echo. I've played with term types, but can't seem to > make it act the same under console as it does in an xterm. > > Anyone know the issue? > > > Eric Try: \033[71C Hmm... I see 71 spaces how about we just stick to the padding... I would like to not go overboard by using a lot of other escape sequences that have less experience out in the wild (and thus, less testing and are more likely to fail). Colors and attributes seem to be the overwhelming majority of reasons using the escape codes. Cursor control and other macros are probably less common. You can change the \033 ---> \e if you like, or leave it. We should settle ourselves on a standard for this however... maybe make a /etc/rc.fancy that has macros for all of this stuff. Also, I second the comment regarding making this tunable. Of course the console will default to 7-bit ASCII text, printable characters only (or whatever charset you have chosen). One of the big reasons for Linux's "prettification" of its console, and support for fb console, is that there are a good number of Linux installations out there where the primary application is desktop and workstation. As for me, I primarily run FreeBSD as a desktop/workstation and therefore enjoy the opportunity to make the console more "readable". We discuss the "bare necessities for servers" and "what's necessary for administering a server", I think that my (and others') workstation needs and desires are important to the development of FreeBSD too. We should be embracing the adoption of the platform for workstation and desktop use as well, and actually take the advice of those users to heart. I would hope that if this featureset can get into the base system, then tunables get into the Console section of sysinstall (allowing this to be turned on at install time) and that the screenshots generated from that entice people who like things like "colorful error messages" to gain more intere
Re: [PATCH] Fancy rc startup style RFC - v6
Eric Anderson wrote: Eric Anderson wrote: Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim <[EMAIL PROTECTED]> Eric Anderson wrote: > If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy="YES" which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color="YES" in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Looks like this version does something strange - from an xterm, the spacing is correct, but from console, it doesn't do anything with the \033[71G in the echo. I've played with term types, but can't seem to make it act the same under console as it does in an xterm. Anyone know the issue? 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 -- 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
Eric Anderson wrote: Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim <[EMAIL PROTECTED]> Eric Anderson wrote: > If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy="YES" which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color="YES" in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Looks like this version does something strange - from an xterm, the spacing is correct, but from console, it doesn't do anything with the \033[71G in the echo. I've played with term types, but can't seem to make it act the same under console as it does in an xterm. Anyone know the issue? 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
Bill Vermillion wrote: Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: Message: 20 Date: Tue, 18 Apr 2006 15:07:31 -0700 From: Darren Pilgrim <[EMAIL PROTECTED]> Eric Anderson wrote: > If I could figure out how to make sh do colors, I'd do it. :) Please do not use colors in rc. Escape-sequenced colors make unacceptable assumptions about the user and syslogd strips escape sequences anyway, so it would be of no use to logged consoles. Serial consoles introduce other problems with buggy escape handling in third-party terminal programs. A good text layout and descriptive status messages do far more for clarity and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. Ok. So I've received mass amounts of mail regarding this, and most of it has been positively in favor of having the option to enable the rc_fancy, and then an additional option to turn on coloring, with the default to be non-colored but still rc_fancy="YES" which should work ok on serial and other terminals (it did for me). I completely agree about all the coloring comments, and terminal issues. I personally think it should be an available option, easily enabled or disabled at will. I've put up an updated version, with many changes. This version includes optional coloring (with rc_fancy_color="YES" in rc.conf), better checking, cleaner coding, and no loops. This version is *much* more refined than the others - thanks for all the hints everyone! http://www.googlebit.com/freebsd/patches/rc_fancy.patch-5 Also - could I check the kern.console sysctl and decide if it's starting using a console or not, and then automatically override the rc.conf settings if it is booting to a serial console? 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
Somewhere around Wed, Apr 19, 2006 at 04:07 , the world stopped and listened as [EMAIL PROTECTED] graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: > Message: 20 > Date: Tue, 18 Apr 2006 15:07:31 -0700 > From: Darren Pilgrim <[EMAIL PROTECTED]> > Eric Anderson wrote: > > If I could figure out how to make sh do colors, I'd do it. :) > Please do not use colors in rc. Escape-sequenced colors make > unacceptable assumptions about the user and syslogd strips > escape sequences anyway, so it would be of no use to logged > consoles. Serial consoles introduce other problems with buggy > escape handling in third-party terminal programs. A good text > layout and descriptive status messages do far more for clarity > and readability than any use of color ever can. Let me add to that. About 10% of the male population has some color vision problem. Mine is a bit more than others. Everytime I get called to work on a Linux system, I have to go in and disable the colors as the reds and other colors become very hard to see against a dark background. The problem is the luminance value of colors such a red is quite low compared to others. That's one of the reasons why fire-trucks in this area are lime-green, as red trucks disappear into the blackness at night. If you add color make sure it is a user selectable option and not turned on by default. IMO everything you need to admin a system needs to be able to run on something as lowly as a pure serial terminal as the above poster notes. 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: [PATCH] Fancy rc startup style RFC
On Tue, 2006-Apr-18 15:02:27 -0500, Eric Anderson wrote:
>Peter Jeremy wrote:
>>>+padding=""
>>>+paddingsize=$(($columns - 15 - $2 - $namesize))
>>>+until [ 0 = ${paddingsize} ]; do
>>>+padding=" $padding"
>>>+paddingsize=$(($paddingsize - 1))
>>>+done
>>
>>This particular block of code appears unnecessary (since $padding is
>>unused).
>
>I must be missing something, because I'm pretty sure it's used.. What
>did I miss?
Actually, I had a closer look and I was wrong, sorry. I missed the
'[ $2 = 0 ]' test. The code might be more legible (and is definitely
more efficient) if the above code was moved into the else clause for
that test.
Also '[ $2 = 0 ]' should probably be written as '[ "0$2" -eq 0 ]', or
similar, so that it doesn't blow up if there is no $2.
--
Peter Jeremy
___
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
On Tue, 2006-Apr-18 18:26:33 -0400, Coleman Kane wrote: >As for your "buggy escape handling" of third-party terminals: 1) Don't >enable the feature and it won't be a problem, or 2) Don't use crappy >third-party terminal software that will die when it recieves ^[[0;31;40m >rather than setting the attributes to NormalText-Red-on-Black. In fact, I >haven't heard of one for some time. I have a number of genuine DEC VT510 terminals that I could probably give away to anyone who wants to disprove this :-) -- Peter Jeremy ___ 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
On Tue, Apr 18, 2006 at 06:38:26PM -0400, John Baldwin wrote: > On Tuesday 18 April 2006 18:15, Marco van Tol wrote: [...] > > I'm trying to apply the patch. Tried it to both todays current and todays > > RELENG_6, but both have failing hunks in sys/kern/kern_clock.c. > > The rest succeeds. > > > > I can do two things: > > - Try to manually patch it against todays current. > > - re-checkout todays RELENG_6, and download the relevant files from the > > cvsweb interface from the date you posted the patch from that days > > CURRENT. Then try to apply the patch. > > > > For the latter it may break the kernelbuild, but I'm very tempted to try > > that one ahead of the manual patching attempt. ;) > > > > I'll keep you posted on how far I'm getting with this. Guess I should have > > gone straight to current the day you posted the patch. Sorry. > > 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. Marco -- Als de redding het hoogst is, is de nood nabij! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
