Re: [PATCH] Remove absolute paths from gpg.rc
On Fri, Mar 23, 2007 at 12:13:06AM -0400, Derek Martin wrote:
> On Fri, Mar 23, 2007 at 02:52:24AM +0000, Dave wrote:
> > > ...and users never do things they're not supposed to, and always
> > > follow all the rules, and all of the world's jails are completely
> > > empty, because everyone does what they're supposed to do all the time.
> >
> > You're getting off-topic.
>
> Not at all... users behaving themselves, or not, is an essential
> aspect of system security.
It's the sysadmin's responsibility to ensure the security of his own system, if
he cares. If he doesn't, it's not his responsibility, either. Physical users
behaving themselves or not is a matter between them and the system owner,
represented by the sysadmin.
> But you don't get that, any more than you
> get that virtually no one thinks like you do about using computers,
> and don't want to use them the way you do.
If they don't think about computers as tools to get real work done, that's their
own choice. Somehow, though, I doubt it. When you teach a user how to do
something in a more efficient way, he's usually at least half interested.
> That's fine; I'll leave
> you to your happy fantasy world.
I love my happy fantasy world. I get happy fantasy work done with happy fantasy
effiency using happy fantasy software (cat doesn't actually exist), and I get
paid with happy fantasy money. Anyway, I have an all-nighter scheduled at my
happy fantasy data center, so I'll start catching up on the backlog of email
tomorrow morning, God-willing. I'm not avoiding you :-)
> > Check this out:
> > $ cat --version
> > cat (coreutils) 5.2.1
> > Written by Torbjorn Granlund and Richard M. Stallman.
> >
> > Copyright (C) 2004 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > Hey, this is a three-year-old program that still does its job right today.
>
> That's a really amuzing example of just how wrong you are. It's not a
> 3-year-old program at all... If you read the source code for GNU
> cat.c in the textutils package, you'll discover that the first
> copyright date is 1988. It's a 19-year-old program,
You got me. I meant an at-least-three-year-old program, as in, a program that
nobody's touched in three years. The useful life of a proper tool is 19+ years.
(Don't forget, the GNU cat wasn't even the original. The idea (and original
implementation) traces itself right back to DMR and his UNIX philosophy.)
The basic idea is this:
Simple task => simple program
Complex task => factor into simple tasks
Incidentally, the UNIX philosophy is ridiculously similar to the scientific
method:
Simple experiment => learn facts about the world
Complex experiment => factor into simpler experiments to eliminate variables
> less than 1000
> lines of code,
That's all it takes to do a single job right. Maintaining such a program is a
piece of cake. Using such a program is a piece of cake. Auditing such a
program is a piece of cake. Why the heck would anybody want complexity???
> which has gone through revision after revision after
> revision, and yet still does pretty much the same thing it always did.
That's the mark of a simple program.
> Apparently, even simple programs are not so simple, after all...
Hmm ... if cat(1) isn't simple according to you, then where does that put GIMP?
> Oswald is right; you're a lost cause.
Yup, it looks like it won't be that easy to convert me to a religion that
doesn't like to get real work done in an efficient way. The problem is that
you're too late: I've already learned how to use a versioning file system, so
there's no reason for me to want programs to question every move I make in the
hopes of making me think twice before nuking my doctoral thesis. (Of course,
the confirmation dialog doesn't even guarantee that I won't make a mistake
after thinking twice. Statistically, I believe I ran across a number someplace,
that thinking about something 7 times is necessary in order to eliminate 90% of
errors made by thinking once. That's a whole lot of confirmation dialogs for a
90% solution to a problem that I can show you how to solve 100% without losing
efficiency to stupid dialogs that you quickly get into the habit of blindly
clicking in order to save time. It's called scripted behavior, and it creates
a lot of problems.[1])
- Dave
[1]
Scripted behavior is what happens when you learn to type by recognizing words in
the source material (what you're typing up) and remembering how to type them
rapidly, rather than recognizing and typing character by character. Those types
of typists can type certain (common) words very efficiently, but they end up
losing all their efficiency in the longer thought process that goes into
recognizing one of X possible words (where X is substantially greater than 26*2)
before copying each word. They also tend to make errors in copying spacing and
capitalization and/or to type a similar word instead, since they don't see the
individual characters, only the word as a whole. What they've essentially done
is trained themselves to quickly solve certain combinations of problems (certain
letter sequences - to them, they're letters, not characters) in particular
domains (English, for example - they almost always have trouble typing random
character sequences). The typist who learns to type character by character
(that is, the one who learns to do one simple task and to do it right), on the
other hand, has no trouble typing anything, in any language that his input
method supports [2]. The UNIX philosophy wasn't really invented by DMR, and
isn't really so mythical, if you think about it for a second; it's actually
quite firmly grounded in the science of Mathematics. It has many parallels (how
the heck do you spell that word? I'm too lazy to install ispell or aspell) in
many other disciplines (hardly surprising, since an optimal method usually
does), most of which are regarded as the proper way of doing things in their
respective fields. Even computer security experts tend to agree that simple
Mathematical problems with simple (brute-force) solutions create the best
encryption schemes (not counting OTP, which in a deterministic world is
theoretically impossible ... we can currently approximate an OTP fairly well
using random noise, but we're not guaranteed to always have an easy time
gathering that much entropy (just like earlier security-by-obfuscation systems
eventually ran out of an "entropy" of available obfuscation methods as the
science of Cryptanalysis improved), and as entropy becomes scarce (for example,
as our Physicists get better at predicting the weather, which could've been an
excellent entropy source 20 years ago), we'll have to learn techniques for
making the most out of the entropy we can get our hands on, which means we'll
have to go back to simple Mathematical problems with simple (brute-force)
solutions), for example. The bottom line is that knowledge is power, and those
who lack (a) will always suffer. Knowledge is gained by the scientific method,
not by deciding that you don't want to learn anything, and that you just want
the programmer of your favorite program to make all your decisions for you, so
you can just sit back, and watch your life unfold in whichever way said
programmer tends to program his users' lives. I find it a bit strange that you
accuse me of being the one with a narrowminded view of the world.
[2]
Now, just like the earlier example of translating a problem into a different
domain in order to solve it with an existing efficient tool (using VI to edit
SVG graphics), I can type Hebrew without learning a new keyboard layout by
simply assigning Hebrew characters to English character sequences (although
there are only 22 glyphs in Hebrew, their phonetic properties make it far easier
to type them the way they sound, rather than saving keystrokes by assigning
individual glyphs to individual keys on the keyboard, the way a real Hebrew
keyboard does ... Hebrew is a very compact language, anyway, since the vowels
aren't normally included at all, so even hitting more than one key per glyph
still yields pretty good speed), and then running the result through a filter
that does the mapping, and save the result for presentation. (Since my terminal
doesn't support Hebrew either (nor do I want it to, since bidi opens up a whole
new can of worms, and doesn't buy me anything new), I leave everything in ASCII
on my end.) Typing Spanish is even easier, since the filter only needs to find
quotes, colons, and tildes (yeah, I use Bill's method - sue me). Now, you put
everything together with a filter that looks for [e], [h], and [s], and calls
the appropriate filter for each section of your text, and you can suddenly type
in any of three languages (and you can switch between them in only three
keystrokes with no ESCs, METAs, ALTs, CTRLs, or SHIFTs) with the same Dvorak
keyboard that you use for everything else. Now, when it's time to switch to
speech, we'll have a very easy time, since by simply switching input method
states, we can go from ASCII character mode to English dialog mode, to Spanish
dialog mode, or to Hebrew dialog mode. (Obviously, we can also go to Spanish
character mode or to Hebrew character mode, but the latter two aren't as
common.) All of our current tools will continue to function just the way they
ever did, and by adding a text-to-speech engine, we can even toss the CRT.
(Yes, I still love CRTs. The only reason I'm on an LCD now is that my ThinkPad
came with one, and I don't have the luxury of working on a desktop right now.
There's some strange new technology making the rounds, that wants to bring an
electron gun to each pixel individually, to avoid (a) the bulge necessary for
channeling the electron beam, and (b) the refresh cycle (since all beams can
fire simultaneously and continuously). I doubt I'll give up my CRTs to another
visual tty system before I can get a monitor with that type of technology.
Maybe I'm stuck in a fantasy world (a happy fantasy world - don't forget), but I
find CRTs much more efficient (and comfortable) to work with, and I'm not overly
excited about letting the wise programmer give me an LCD to protect my personal
safety. (After all, there's a lot of radiation coming out of that screen!
Users WANT YOU TO RUN THEIR LIVES FOR THEM, since almost all of them are stupid
and don't want to learn anything at all!) As a user, I'm slightly offended that
anybody thinks that users want to be stupid. We are Primates, and Primates are
well-known for their intelligence and interest in learning.)
The reason I bring this up is that it clearly illustrates the science of solving
problems efficiently. The correct procedure is to first analyze the problem,
then to break it down into tasks, and then to recursively break those tasks down
into simple tasks. At that point, you look through your toolbox, and pick out
all the tasks that you don't have tools for. Now, you try to translate those
tasks into similar tasks that you do have tools for. If you have any tasks left
that you can't break down further and can't translate productively, only then do
you create a new tool. You then combine the toolchain with a script, to avoid
learning scripted behavior. Reduce, reuse, recycle.
Anyway, I'm off to the DC. Peace.