Release 1.3.1: Fri Apr 27 19:02:31 EDT 2001
* kxref.py can now replace the unmaintained checkhelp.pl,
checkconfig.pl, and checkincludes.pl scripts.
I'm going to stick my neck out a mile and say that I think this is a
stable release. Doing so, of course, is in reality a clever plan which
ensures that at least three embarrassing bugs will be discovered within
the next 24 hours...
Seriously, I am now out of stuff to do on the CML2 code itself. The
code now seems to be up to acceptable speed even on slow machines, the
UI feature requests have petered out, and this release seems to be
feature-complete with respect to everything that can be done before
the 2.5 cutover.
There is one 1.3.0 bug report pending from jeff millar, but I have
not been able to reproduce it with 1.3.1. I will, of course, continue
to process CML2 bug reports and rulesfile fixes.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"The bearing of arms is the essential medium through which the
individual asserts both his social power and his participation in
politics as a responsible moral being..."
-- J.G.A. Pocock, describing the beliefs of the founders of the U.S.
Eric> I'm going to stick my neck out a mile and say that I think this
Eric> is a stable release. Doing so, of course, is in reality a
Eric> clever plan which ensures that at least three embarrassing bugs
Eric> will be discovered within the next 24 hours...
I've just downloaded and installed cml-1.3.2 on my Dual processor PPro
200mhz, 128mb system. Unfortunately, I set it up into a 2.4.4-pre7 +
patches tree, and it's now giving me the following when I do a 'make
config':
[root@jfs linux]# make config
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
rules.out
ISA=y (deduced from X86)
Side effects from config.out:
NETDEVICES=m (deduced from ATALK)
SOUND_OSS=m (deduced from SOUND_VIA82CXXX)
SOUND_OSS=y (deduced from SOUND_YMFPCI_LEGACY)
SOUND=y (deduced from SOUND_OSS)
This configuration violates the following constraints:
'((X86 and SMP) implies (RTC != n))'
python -O scripts/configtrans.py -h include/linux/autoconf.h -s
.config config.out
Which is a real PITA because now I have to edit my .config file to
have:
CONFIG_RTC=y
in there. Now when I do a 'make config' it comes up properly. I
think this is a poor interface setup. It should either
a. Give more info on what to correct, such as the configuration line
to edit and in which file.
b. Print a warning, startup the configuration tool and put you at the
problematic line, with the help section showing. Or highlight this
choice in some manner as being wrong and showing you how to ffix it.
This is a minor, but annoying problem and should be fixed ASAP before
public use.
In general, I like what I do see, it's more interface issues that I
have so far.
Now for some comments on the X interface.
At the top-level, most stuff cannot be selected on/off, but you can
enter it. But you also do have some y/m/n choices which seems wierd
and out of place. For example, "SCSI disk support" is a menu, but
"HAMRADIO: Amateur Radio support (NEW)" is a y/n choice. It would
make more sense to me to have it down a level, with a simple entry to
"Hamradio support". Once you go into that level, you would be asked
to have it turned on/off there.
This would remove some of the clutter at the top level.
As a contrast, the USB entry doesn't ask Y/N for USB support, and when
I enter the directory, it has all these options listed. I thought
that CML would suppres stuff (children, drivers, etc) if I didn't have
the top level selected. In this case, I can't turn off USB support in
any manner, so I see all the children when I could care less about
them.
Also, the buttons on the right hand side for HELP, are wider when they
have text in them, but slightly narrower when they are blank. They
should be the same width no matter what. It looks ragged and ugly.
I don't like how it keeps changing the window size whenever you go
into a sub-level. It should not re-size the main window at all, it
should just update the contents and give scroll bars if needed for
both up/down scolling and side to side. Once the user has setup their
prefs, the CML code shouldn't keep it jumping all over the screen.
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-952-7548
John Stoffel <[email protected]>:
> Which is a real PITA because now I have to edit my .config file to
> have:
>
> CONFIG_RTC=y
The correct fix for this PITA is for Linus not to ship a broken defconfig.
> Now when I do a 'make config' it comes up properly. I
> think this is a poor interface setup. It should either
>
> a. Give more info on what to correct, such as the configuration line
> to edit and in which file.
>
> b. Print a warning, startup the configuration tool and put you at the
> problematic line, with the help section showing. Or highlight this
> choice in some manner as being wrong and showing you how to ffix it.
>
> This is a minor, but annoying problem and should be fixed ASAP before
> public use.
I hear you. The problem is that "what's wrong" is not as well-defined
as one might like. In this case the error could be in the setting of
X86, SMP, or RTC. CML2 has no way to know which of these is mis-set, so
it can't know which one to pop up..
> At the top-level, most stuff cannot be selected on/off, but you can
> enter it. But you also do have some y/m/n choices which seems wierd
> and out of place. For example, "SCSI disk support" is a menu, but
> "HAMRADIO: Amateur Radio support (NEW)" is a y/n choice. It would
> make more sense to me to have it down a level, with a simple entry to
> "Hamradio support". Once you go into that level, you would be asked
> to have it turned on/off there.
>
> This would remove some of the clutter at the top level.
>
> As a contrast, the USB entry doesn't ask Y/N for USB support, and when
> I enter the directory, it has all these options listed. I thought
> that CML would suppres stuff (children, drivers, etc) if I didn't have
> the top level selected. In this case, I can't turn off USB support in
> any manner, so I see all the children when I could care less about
> them.
USB and SCSI are both enabled/disabled in the system buses menu. The
apparent confusion
> Also, the buttons on the right hand side for HELP, are wider when they
> have text in them, but slightly narrower when they are blank. They
> should be the same width no matter what. It looks ragged and ugly.
I know. Sadly, I couldn't find a way to coerce Tcl into doing this right.
> I don't like how it keeps changing the window size whenever you go
> into a sub-level. It should not re-size the main window at all, it
> should just update the contents and give scroll bars if needed for
> both up/down scolling and side to side. Once the user has setup their
> prefs, the CML code shouldn't keep it jumping all over the screen.
That's on my to-do list. It's low-priority, though, since I figure
most people will use menuconfig.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Today, we need a nation of Minutemen, citizens who are not only prepared to
take arms, but citizens who regard the preservation of freedom as the basic
purpose of their daily life and who are willing to consciously work and
sacrifice for that freedom."
-- John F. Kennedy
John Stoffel <[email protected]>:
> Before on startup it would give:
>
> [root@jfs linux]# make config
> rm -f include/asm
> ( cd include ; ln -sf asm-i386 asm)
> python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
> rules.out
> ISA=y (deduced from X86)
> Side effects from config.out:
> NETDEVICES=m (deduced from ATALK)
> SOUND_OSS=m (deduced from SOUND_VIA82CXXX)
> SOUND_OSS=y (deduced from SOUND_YMFPCI_LEGACY)
> SOUND=y (deduced from SOUND_OSS)
> python -O scripts/configtrans.py -h include/linux/autoconf.h -s
> .config config.out
>
>
> So I poked around, found the RTC setting, read the help and now I
> understand why I should have had it enabled all along. No problem.
> So saved my changes and exited.
>
> I then restarted, and it came up properly, but I'm now getting the
> following output:
>
> [root@jfs linux]# make config
> rm -f include/asm
> ( cd include ; ln -sf asm-i386 asm)
> python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
> rules.out
> ISA=y (deduced from X86)
>
>
> Notice that it's still setting the ISA=y flag, but not the rest it was
> complaining about. I think it should have either updated this setting
> by default for the ISA bus, or warned on exit that it still needed to
> be set.
>
> I think this is a true bug somewhere.
Nope, it's a benign side-effect of the order of evaluation of command-line
switches. Here's what's happening:
1. X86=y is being set and frozen.
2. ISA=y is deduced from X86
3. config.out is read in.
In step 3, you don't see any side effects from config.out because they
were calculated last time and wruitten into the saved configuration.
You still see the ISA=y message because your config.out has not yet been
read in at the time that side effect is computed.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
-- Mohandas Ghandhi, An Autobiography, pg 446
Eric S. Raymond <[email protected]>:
> USB and SCSI are both enabled/disabled in the system buses menu. The
> apparent confusion
Sorry, I typoed...
USB and SCSI are both enabled/disabled in the system buses menu. The
apparent confusion happens because of their defaults.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
-- Thomas Paine
At 23:35 29/04/2001, Eric S. Raymond wrote:
>John Stoffel <[email protected]>:
> > Also, the buttons on the right hand side for HELP, are wider when they
> > have text in them, but slightly narrower when they are blank. They
> > should be the same width no matter what. It looks ragged and ugly.
>
>I know. Sadly, I couldn't find a way to coerce Tcl into doing this right.
I don't know about whether this is possible with Tcl but have you tried A)
invisible text and/or B) white space character text (e.g. one or more
spaces)? That's the kind of thing I usually try in this situation... Just
an idea...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Anton Altaparmakov <[email protected]>:
> I don't know about whether this is possible with Tcl but have you tried A)
> invisible text and/or B) white space character text (e.g. one or more
> spaces)? That's the kind of thing I usually try in this situation... Just
> an idea...
I tried whitespace, but the default Tkinter font isn't fixed-width. How
do you do invisible text?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
..every Man has a Property in his own Person. This no Body has any
Right to but himself. The Labour of his Body, and the Work of his
Hands, we may say, are properly his. .... The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
-- John Locke, "A Treatise Concerning Civil Government"
Eric S. Raymond scripsit:
> I tried whitespace, but the default Tkinter font isn't fixed-width. How
> do you do invisible text?
Set the background color and the foreground color to be the same.
--
John Cowan [email protected]
One art/there is/no less/no more/All things/to do/with sparks/galore
--Douglas Hofstadter
On Sun, 29 Apr 2001, Eric S. Raymond quoted:
> Anton Altaparmakov <[email protected]>:
> > I don't know about whether this is possible with Tcl but have you tried A)
> > invisible text and/or B) white space character text (e.g. one or more
> > spaces)? That's the kind of thing I usually try in this situation... Just
> > an idea...
wrote
> I tried whitespace, but the default Tkinter font isn't fixed-width. How
> do you do invisible text?
and sigged
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> ..every Man has a Property in his own Person. This no Body has any
> Right to but himself. The Labour of his Body, and the Work of his
> Hands, we may say, are properly his. .... The great and chief end
> therefore, of Mens uniting into Commonwealths, and putting themselves
> under Government, is the Preservation of their Property.
> -- John Locke, "A Treatise Concerning Civil Government"
Eric, it's getting tiresome. Kindly learn what the fsck McQ is, OK?
/me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
over the top for l-k...
On Sun, 29 Apr 2001, Eric S. Raymond wrote:
> Anton Altaparmakov <[email protected]>:
> > I don't know about whether this is possible with Tcl but have you tried A)
> > invisible text and/or B) white space character text (e.g. one or more
> > spaces)? That's the kind of thing I usually try in this situation... Just
> > an idea...
>
> I tried whitespace, but the default Tkinter font isn't fixed-width. How
> do you do invisible text?
Make it the same color as the background.
Vladimir Dergachev
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> ..every Man has a Property in his own Person. This no Body has any
> Right to but himself. The Labour of his Body, and the Work of his
> Hands, we may say, are properly his. .... The great and chief end
> therefore, of Mens uniting into Commonwealths, and putting themselves
> under Government, is the Preservation of their Property.
> -- John Locke, "A Treatise Concerning Civil Government"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Al,
I really don't know why you must complain about Eric's sig. I
personally like them just as they are, but thats strictly besides the
point. IMHO, it is just not very intresting to hear you say:
> Eric, it's getting tiresome. Kindly learn what the fsck McQ is, OK?
Especially after all of the brilliant things I have heard you say. It
really seems like a childish move. Let the man have his freakin sig for
crying out loud!! At any rate, I'm just throwin' in my 2 cents. OK,
now can we get back on topic? Good.
I hope no offense is taken and no reply necessary.. But if I mistaken,
then I look forward to your, in all probablity, entertaining reply
(maybe off this list though). :)
Regards,
David
On 29 Apr 2001 22:24:58 -0400, Alexander Viro wrote:
>
>
> On Sun, 29 Apr 2001, Eric S. Raymond quoted:
>
> > Anton Altaparmakov <[email protected]>:
> > > I don't know about whether this is possible with Tcl but have you tried A)
> > > invisible text and/or B) white space character text (e.g. one or more
> > > spaces)? That's the kind of thing I usually try in this situation... Just
> > > an idea...
>
> wrote
>
> > I tried whitespace, but the default Tkinter font isn't fixed-width. How
> > do you do invisible text?
>
> and sigged
> > --
> > <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> >
> > ..every Man has a Property in his own Person. This no Body has any
> > Right to but himself. The Labour of his Body, and the Work of his
> > Hands, we may say, are properly his. .... The great and chief end
> > therefore, of Mens uniting into Commonwealths, and putting themselves
> > under Government, is the Preservation of their Property.
> > -- John Locke, "A Treatise Concerning Civil Government"
>
> Eric, it's getting tiresome. Kindly learn what the fsck McQ is, OK?
>
> /me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
> over the top for l-k...
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Sun, 29 Apr 2001, David Emory Watson wrote:
> Al,
>
> I really don't know why you must complain about Eric's sig. I
Because violating the common standards is a bad thing? You know, like
4-lines limit on sig size... And no, I don't care how many AOL and
WebTV lusers do the same thing.
Oh. Well in hindsight, I guess your are right. After all I wouldn't
want to be a luser, much less associated with AOL. Gosh I never
realized. Maybe I just didn't read the right standards manual when I
started using the internet. Where did you learn all of this? No,
nevermind I don't care. I'm sorry for contributing to this silly flame
war.
I think my points been made. Sorry Al, but this is a bit too silly....
On 30 Apr 2001 01:50:49 -0400, Alexander Viro wrote:
>
>
> On Sun, 29 Apr 2001, David Emory Watson wrote:
>
> > Al,
> >
> > I really don't know why you must complain about Eric's sig. I
>
> Because violating the common standards is a bad thing? You know, like
> 4-lines limit on sig size... And no, I don't care how many AOL and
> WebTV lusers do the same thing.
>
David Emory Watson <[email protected]>:
> Oh. Well in hindsight, I guess your are right. After all I wouldn't
> want to be a luser, much less associated with AOL. Gosh I never
> realized. Maybe I just didn't read the right standards manual when I
> started using the internet. Where did you learn all of this? No,
> nevermind I don't care. I'm sorry for contributing to this silly flame
> war.
Time for me to put on my hacker-folklorist hat...
Actually, Al is sort of half-right here. There used to be a 4-lines-or-less
convention on USENET, back in the days when bandwidth was expensive. I
adhered to it then, because it mattered.
Nowadays it doesn't -- at least not at that level. Huge sigs with
embedded ASCII graphics and the like are still best avoided, but merely
because they're tasteless and distracting.
I don't think I've heard anyone invoke the 4-line rule since about
1992, though. I didn't start generating short random quotes into my sig
until about 1996, well after the "standard" was effectively dead.
Despite the demise of the 4-line standard, I have a pretty definite
impression that the average size of sigs actually dropped in the 1990s.
The main thing that formerly inflated a lot of them was the need to
list multiple bang-path addresses and other forms of contact info.
Reliable @-addressing pretty much eliminated that pressure.
Even back in its day this "rule" was frequently abused as a socially
acceptable way to attack people whose opinions or style one disliked.
This is doubtless one reason it failed to survive the bandwidth boom.
Hmmm. Maybe this should be a Jargon File entry...
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The politician attempts to remedy the evil by increasing the very thing
that caused the evil in the first place: legal plunder.
-- Frederick Bastiat
>
> Eric, it's getting tiresome. Kindly learn what the fsck McQ is, OK?
Just out of curiousity - what is McQ ?
Vladimir Dergachev
PS And no, I am very sure there is no such thing in Star Trek.
>
> /me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
> over the top for l-k...
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
"Eric S. Raymond" wrote:
> Actually, Al is sort of half-right here. There used to be a 4-lines-or-less
> convention on USENET, back in the days when bandwidth was expensive. I
> adhered to it then, because it mattered.
>
> Nowadays it doesn't -- at least not at that level. Huge sigs with
> embedded ASCII graphics and the like are still best avoided, but merely
> because they're tasteless and distracting.
>
> I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though. I didn't start generating short random quotes into my sig
> until about 1996, well after the "standard" was effectively dead.
The 4-line rule is still being invoked all the time, and written into
college netiquette guides for students, things like that. The standard
has never been "effectively dead" except in the sense that it always has
been: clueless AOLers ignore it, clueful netiquette followers follow
it.
Read item #15:
http://www.xs4all.nl/~js/gnksa/gnksa.txt
> Despite the demise of the 4-line standard, I have a pretty definite
> impression that the average size of sigs actually dropped in the 1990s.
> The main thing that formerly inflated a lot of them was the need to
> list multiple bang-path addresses and other forms of contact info.
> Reliable @-addressing pretty much eliminated that pressure.
>
> Even back in its day this "rule" was frequently abused as a socially
> acceptable way to attack people whose opinions or style one disliked.
frequently abused, yes. socially acceptable? doubtful.
--
Jeff Garzik | Game called on account of naked chick
Building 1024 |
MandrakeSoft |
On Mon, 30 Apr 2001, Eric S. Raymond wrote:
> I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though. I didn't start generating short random quotes into my sig
> until about 1996, well after the "standard" was effectively dead.
<wry> We hang in different parts of USENET </wry>
Last time I've seen it invoked was probably a couple of weeks ago.
> Even back in its day this "rule" was frequently abused as a socially
> acceptable way to attack people whose opinions or style one disliked.
> This is doubtless one reason it failed to survive the bandwidth boom.
>
> Hmmm. Maybe this should be a Jargon File entry...
ISTR that you had an entry on AFW - it would more or less fit there.
Stuff generating random quotes (aka. sigmonsters) is pretty common,
indeed, but fitting said quotes into McQ is a part of fun. I suspect
that strong dislike to excessive sigs goes back to the beginning of
Endless September - like it or not, "why would I give a fuck for
conventions" attitude correlates with particulary obnoxious breed
of lusers. Same as with HTML postings, or quoted-printable crap.
Seeing that from folks who should know better... Ugh.
And no, I really don't care for the contents - if anything, I find
both sides of holy war around g*n* c**t**l moderately amusing, but
for all I care it could be 6-7 lines of PARRY vs. ELIZA dialog (or
vi macros, or just a line noise).
BTW, there's one more jarring thing about use of sigs on l-k - you are
getting _two_ sigs that way (look at the unsubscribe instructions).
On Mon, 30 Apr 2001 [email protected] wrote:
> >
> > Eric, it's getting tiresome. Kindly learn what the fsck McQ is, OK?
>
> Just out of curiousity - what is McQ ?
>
> Vladimir Dergachev
>
> PS And no, I am very sure there is no such thing in Star Trek.
McQ: (from George McQuary) Conventional limit on signature size.
>From AFW FAQ:
Q11. What is the McQuary limit?
A11. "There once was a man from Nantucket,
who lost his .sig in a bucket.
Five lines was too long,
columns 80 just strong,
so he didn't know where to tuck it."
A11. The limit on signature size: "4x80".
Alexander Viro <[email protected]>:
> >From AFW FAQ:
>
> Q11. What is the McQuary limit?
> A11. "There once was a man from Nantucket,
> who lost his .sig in a bucket.
> Five lines was too long,
> columns 80 just strong,
> so he didn't know where to tuck it."
> A11. The limit on signature size: "4x80".
I just added the following to the Jargon File masters:
@hd{McQuary limit} @p{} 4 lines of at most 80 characters each,
sometimes still cited on Usenet as the maximum acceptable size of a
@es{sig block}. Before the great bandwidth explosion of the early
1990s, long sigs actually cost people running Usenet servers
significant amounts of money. Nowadays social pressure against
long sigs is intended to avoid waste of human attention rather
than machine bandwidth. Accordingly, the McQuary limit should
be considered a rule of thumb rather than a hard limit; it's
best to avoid sigs that are large, repetitive, and distracting.
See also @es{warlording}.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
-- Frederic Bastiat, "The Law"
At 02:41 30/04/2001, Eric S. Raymond wrote:
>Anton Altaparmakov <[email protected]>:
> > I don't know about whether this is possible with Tcl but have you tried A)
> > invisible text and/or B) white space character text (e.g. one or more
> > spaces)? That's the kind of thing I usually try in this situation... Just
> > an idea...
>
>I tried whitespace, but the default Tkinter font isn't fixed-width. How
>do you do invisible text?
Text colour = background colour -> invisible
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
Anton Altaparmakov <[email protected]>:
> >I tried whitespace, but the default Tkinter font isn't fixed-width. How
> >do you do invisible text?
>
> Text colour = background colour -> invisible
Well, duh. Unfortunately, it doesn't seem to have occured to the dozen or
so people who suggested this that:
(a) Background color can vary depending on how Tk's X resources are set, and
(b) Tk doesn't give me, AFAIK, any way to query either that background color
or those resources.
Fer cripes' sake. If it were that easy I'd have *done* it already, people!
Anyway my attempts to set a foreground color on an inactive button widget
failed. I don't know why. Tk is full of weird little corners like that.
What I've done is just disabled inactive help buttons without trying to
hack the text or color. That makes them all the same width, though the
legend "Help" does show up in gray on the inacive ones.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"The state calls its own violence `law', but that of the individual `crime'"
-- Max Stirner
At 09:03 30/04/2001, Eric S. Raymond wrote:
>Anton Altaparmakov <[email protected]>:
> > >I tried whitespace, but the default Tkinter font isn't fixed-width. How
> > >do you do invisible text?
> >
> > Text colour = background colour -> invisible
>
>Well, duh. Unfortunately, it doesn't seem to have occured to the dozen or
>so people who suggested this that:
>
>(a) Background color can vary depending on how Tk's X resources are set, and
>
>(b) Tk doesn't give me, AFAIK, any way to query either that background color
> or those resources.
Well, that's a problem with Tk. I did say I know nothing about Tcl and this
extends to Tcl/Tk...
>Fer cripes' sake. If it were that easy I'd have *done* it already, people!
Well, you asked a generic question and not one of "how do you do this in
Tcl/Tk?" so you got a generic reply...
>Anyway my attempts to set a foreground color on an inactive button widget
>failed. I don't know why. Tk is full of weird little corners like that.
>
>What I've done is just disabled inactive help buttons without trying to
>hack the text or color. That makes them all the same width, though the
>legend "Help" does show up in gray on the inacive ones.
Cool.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
"Eric S. Raymond" <[email protected]> writes:
>@hd{McQuary limit} @p{} 4 lines of at most 80 characters each,
> sometimes still cited on Usenet as the maximum acceptable size of a
> @es{sig block}. Before the great bandwidth explosion of the early
> 1990s, long sigs actually cost people running Usenet servers
> significant amounts of money. Nowadays social pressure against
> long sigs is intended to avoid waste of human attention rather
> than machine bandwidth. Accordingly, the McQuary limit should
> be considered a rule of thumb rather than a hard limit; it's
> best to avoid sigs that are large, repetitive, and distracting.
> See also @es{warlording}.
Don't tell me how to live my life
Don't tell me what to do
Repression is always brought about
By people with politics
and attitudes like you
-- Anne Clark, The power game, 1982
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
Eric S. Raymond scripsit:
> I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though. I didn't start generating short random quotes into my sig
> until about 1996, well after the "standard" was effectively dead.
I have always obeyed it.
--
John Cowan [email protected]
One art/there is/no less/no more/All things/to do/with sparks/galore
--Douglas Hofstadter
[email protected] said:
> I don't think I've heard anyone invoke the 4-line rule since about
> 1992, though. I didn't start generating short random quotes into my
> sig until about 1996, well after the "standard" was effectively dead.
RFC 1855 is dated October 1995.
- If you include a signature keep it short. Rule of thumb
is no longer than 4 lines. Remember that many people pay for
connectivity by the minute, and the longer your message is,
the more they pay.
--
dwmw2
[email protected] said:
> Maybe I just didn't read the right standards manual when I started
> using the internet.
Then read it now. http://www.ietf.org/rfc/rfc1855.txt
--
dwmw2
Alexander Viro <[email protected]>:
> <wry> We hang in different parts of USENET </wry>
I don't hang in Usenet at all, any more. Gave up on it about '98.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
You know why there's a Second Amendment? In case the government fails to
follow the first one.
-- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993
On Mon, 30 Apr 2001, Eric S. Raymond wrote:
> Anton Altaparmakov <[email protected]>:
> > >I tried whitespace, but the default Tkinter font isn't fixed-width. How
> > >do you do invisible text?
> >
> > Text colour = background colour -> invisible
>
> Well, duh. Unfortunately, it doesn't seem to have occured to the dozen or
> so people who suggested this that:
>
> (a) Background color can vary depending on how Tk's X resources are set, and
>
> (b) Tk doesn't give me, AFAIK, any way to query either that background color
> or those resources.
button .x
.x cget -background
Vladimir Dergachev
>
> Fer cripes' sake. If it were that easy I'd have *done* it already, people!
>
> Anyway my attempts to set a foreground color on an inactive button widget
> failed. I don't know why. Tk is full of weird little corners like that.
>
> What I've done is just disabled inactive help buttons without trying to
> hack the text or color. That makes them all the same width, though the
> legend "Help" does show up in gray on the inacive ones.
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> "The state calls its own violence `law', but that of the individual `crime'"
> -- Max Stirner
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I think ppl are recommending you BZ2 all your sigs......
Nick
On Mon, 30 Apr 2001, Eric S. Raymond wrote:
> Alexander Viro <[email protected]>:
> > >From AFW FAQ:
> >
> > Q11. What is the McQuary limit?
> > A11. "There once was a man from Nantucket,
> > who lost his .sig in a bucket.
> > Five lines was too long,
> > columns 80 just strong,
> > so he didn't know where to tuck it."
> > A11. The limit on signature size: "4x80".
>
> I just added the following to the Jargon File masters:
>
> @hd{McQuary limit} @p{} 4 lines of at most 80 characters each,
> sometimes still cited on Usenet as the maximum acceptable size of a
> @es{sig block}. Before the great bandwidth explosion of the early
> 1990s, long sigs actually cost people running Usenet servers
> significant amounts of money. Nowadays social pressure against
> long sigs is intended to avoid waste of human attention rather
> than machine bandwidth. Accordingly, the McQuary limit should
> be considered a rule of thumb rather than a hard limit; it's
> best to avoid sigs that are large, repetitive, and distracting.
> See also @es{warlording}.
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> What, then is law [government]? It is the collective organization of
> the individual right to lawful defense."
> -- Frederic Bastiat, "The Law"
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Eric> John Stoffel <[email protected]>:
>> Which is a real PITA because now I have to edit my .config file to
>> have:
>>
>> CONFIG_RTC=y
Eric> The correct fix for this PITA is for Linus not to ship a broken
Eric> defconfig.
While I can sympathize with this comment, I still feel that CML2 needs
to be more robust and handle corner cases like this more gracefully.
Eric> I hear you. The problem is that "what's wrong" is not as
Eric> well-defined as one might like. In this case the error could be
Eric> in the setting of X86, SMP, or RTC. CML2 has no way to know
Eric> which of these is mis-set, so it can't know which one to pop
Eric> up..
It should then highlight *all* of the potential problem config
setting(s) and let the user deal. But they should never be forced to
hand edit their config file because a dependency is broken somewhere.
CML2 should enforce the *writing* of compliant files, but should deal
gracefully with non-compliant ones. Within reason of course.
Eric> USB and SCSI are both enabled/disabled in the system buses menu.
Eric> The apparent confusion
Then they should be pushed down a level to be under those buses. They
don't belong on the top level.
More correctly, *any* configuration setting on an upper level should
not depend on a lower level setting. I know, this is probably not
possible for a variety of reasons, but I feel pretty strongly that we
should try to keep common options near/next to each other.
I can see where this would be a problem, using just SCSI as an
example, since you could have ISA, PCI or some other system bus SCSI
controller(s) on the system. So where do you allow users to choose
whether to enable SCSI or not? At the top level? Only under the
"System Busses" menu item?
On the other hand, I really do like the search feature for config
stuff, it seems pretty powerful.
Thanks,
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
[email protected] - http://www.lucent.com - 978-952-7548
[email protected] <[email protected]>:
> I think ppl are recommending you BZ2 all your sigs......
Yes, I got that. Except for the people saying they like them as-is.
In the absence of a clear consensus on the matter, I'm going to do
as I please. Especially since I have a strong suspicion that neither
camp would change their evaluation of my sigs if I did compress them.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"The bearing of arms is the essential medium through which the
individual asserts both his social power and his participation in
politics as a responsible moral being..."
-- J.G.A. Pocock, describing the beliefs of the founders of the U.S.
Does anybody have a procmail recipe that filters out e-mail to
linux-kernel that contain ridiculously long .sigs?
--
Jeff Garzik | Game called on account of naked chick
Building 1024 |
MandrakeSoft |
On Mon, 30 Apr 2001, Jeff Garzik wrote:
> Does anybody have a procmail recipe that filters out e-mail to
> linux-kernel that contain ridiculously long .sigs?
> --
> Jeff Garzik | Game called on account of naked chick
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why that? I see you too support the right to bare arms ;)
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://distro.conectiva.com/
Send all your spam to [email protected] (spam digging piggy)
John Stoffel <[email protected]>:
> It should then highlight *all* of the potential problem config
> setting(s) and let the user deal. But they should never be forced to
> hand edit their config file because a dependency is broken somewhere.
> CML2 should enforce the *writing* of compliant files, but should deal
> gracefully with non-compliant ones. Within reason of course.
The "within reason" is the problem. It's very easy to construct
simple cases of invalid configs that blow the number of `tainted'
symbols up much larger than the number of violated constraints. An
interface of the kind you suggest would deluge the user with possible
things to be corrected without actually revealing the nature of the
problem.
Besides, right now the configurator has a simple invariant. It will
only accept consistent configurations and it will only write
consistent configurations -- in fact, your configuration is guaranteed
correct after ever attempt to change a symbol with the configurator
itself. I'm very, very reluctant to do anything that will go near
breaking that invariant.
I believe the the right fix is to go through the one-time transition
necessary to be in a world where inconsistent configurations never get
written, rather than to be overly accomodating to yesterday's bugs.
> Eric> USB and SCSI are both enabled/disabled in the system buses menu.
> Eric> The apparent confusion
>
> Then they should be pushed down a level to be under those buses. They
> don't belong on the top level.
That doesn't work either. See the "Good style in rulebase design"
section in the CML2 paper for discussion. The last paragraph is
especially relevant.
> More correctly, *any* configuration setting on an upper level should
> not depend on a lower level setting.
Sorry, that's dreadfully bad advice and is not going to happen. If I did
as you suggest, I'd be throwing out the ability to do consistency
checks and deduce side effects.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Those who make peaceful revolution impossible
will make violent revolution inevitable."
-- John F. Kennedy
Jeff Garzik writes:
> Does anybody have a procmail recipe that filters out e-mail to
> linux-kernel that contain ridiculously long .sigs?
> --
> Jeff Garzik | Game called on account of naked chick
Oh for fsck's sake. You've now wasted 1000x more bandwidth bitching
about sig length than the the actual sig used up.
Get a life. Ignore that which displeases you. Ignorance is bliss.
You are no longer a republican. Eat your vegatables.
Just stop whining about ESR's sigs already.
And now back to your regularly scheduled kernel hacking.
(woo! sluggy freelance. poing!)
#insert <longsig.h>
--
Leif Sawyer -- Pi@4398680
[email protected] || [email protected] || internic: LS2540
(907) 868 - 0116 || ICQ - 3749190 || http://home.gci.net/~leif
Network Engineer -- General Communication Inc.
PGP Fingerprint: 77 C8 34 B8 FD BC C6 32 5F FE 93 4B AE 6C F7 4E
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GAT d+ s: a C+++(++)$ US++++$ UL++++$ P+++ L++(+++) E---
W+++ N+ o+ K w O- M- V PS+ PE Y+ PGP(+) t+@ 5- X R- tv b++(+++)
DI++++ D++ G+ e(+)* h-- r++ y+ PP++++ HH++++ A19 NT{--}
------END GEEK CODE BLOCK------
Decode it! http://www.ebb.org/ungeek/
Leif Sawyer wrote:
> Oh for fsck's sake. You've now wasted 1000x more bandwidth bitching
> about sig length than the the actual sig used up.
Nope, between esr's sigs and your geek code block+sig+stuff, we are
still playing catch-up... More posting to do!
--
Jeff Garzik | Game called on account of naked chick
Building 1024 |
MandrakeSoft |
[esr]
> Besides, right now the configurator has a simple invariant. It will
> only accept consistent configurations
So you are saying that the old 'vi .config; make oldconfig' trick is
officially unsupported? That's too bad, it was quite handy.
Peter
Peter Samuelson <[email protected]>:
> [esr]
> > Besides, right now the configurator has a simple invariant. It will
> > only accept consistent configurations
>
> So you are saying that the old 'vi .config; make oldconfig' trick is
> officially unsupported? That's too bad, it was quite handy.
Depends on how you define `unsupported'. Make oldconfig will tell you
exactly and unambiguously what was wrong with the configuration. I think
if you're hard-core enough to vi your config, you're hard-core enough to
interpret and act on
This configuration violates the following constraints:
(X86 and SMP==y) implies RTC!=n
without needing some wussy GUI holding your hand :-).
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The end move in politics is always to pick up a gun.
-- R. Buckminster Fuller
On Mon, 30 Apr 2001, Eric S. Raymond wrote:
> [email protected] <[email protected]>:
> > I think ppl are recommending you BZ2 all your sigs......
>
> Yes, I got that. Except for the people saying they like them as-is.
>
> In the absence of a clear consensus on the matter, I'm going to do
> as I please. Especially since I have a strong suspicion that neither
> camp would change their evaluation of my sigs if I did compress them.
Put them all on one long line and you can piss off a third camp.
Gerhard
PS I have a long rant on the topics your sigs cover but I would hate to
see the resulting flamewar.
--
Gerhard Mack
[email protected]
<>< As a computer I find your faith in technology amusing.
I'm fairly sure if he attached the BZ2'd sigs (exact same sigs, just bz2'd
and tacked on like they are currently) would offend at least three camps,
and have the benifit of showing up many broken mailers, filters, and
various other mail related items.
Nick
On Mon, 30 Apr 2001, Gerhard Mack wrote:
> On Mon, 30 Apr 2001, Eric S. Raymond wrote:
>
> > [email protected] <[email protected]>:
> > > I think ppl are recommending you BZ2 all your sigs......
> >
> > Yes, I got that. Except for the people saying they like them as-is.
> >
> > In the absence of a clear consensus on the matter, I'm going to do
> > as I please. Especially since I have a strong suspicion that neither
> > camp would change their evaluation of my sigs if I did compress them.
>
> Put them all on one long line and you can piss off a third camp.
>
> Gerhard
>
> PS I have a long rant on the topics your sigs cover but I would hate to
> see the resulting flamewar.
>
>
> --
> Gerhard Mack
>
> [email protected]
>
> <>< As a computer I find your faith in technology amusing.
>
[email protected] (Alexander Viro) wrote on 30.04.01 in <[email protected]>:
> On Mon, 30 Apr 2001, Eric S. Raymond wrote:
>
> > I don't think I've heard anyone invoke the 4-line rule since about
> > 1992, though. I didn't start generating short random quotes into my sig
> > until about 1996, well after the "standard" was effectively dead.
>
> <wry> We hang in different parts of USENET </wry>
>
> Last time I've seen it invoked was probably a couple of weeks ago.
I think I see it at least once a week on average. And that's gone *up*
from earlier; in my first Usenet days (pre-Deja), I saw much less of it.
MfG Kai