Linux-Advocacy Digest #291, Volume #29 Sun, 24 Sep 00 16:13:04 EDT
Contents:
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Richard)
----------------------------------------------------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: Sun, 24 Sep 2000 19:58:29 GMT
2:1 wrote:
> > Not for engineering! Would you *want* to use a bridge whose only
> > argument going for it is because the engineer "likes it"?
>
> If the SW doesn't meet its specs, then it's a pretty lame argument. Once
> it meets the specs, `I like it' is acceptable for SW and bridges.
No, no, no, that only changes the question to *Who made the spec?*
In the case of a bridge, it's an /engineer/ who made the spec. In
the case of software, it's some loser who copied the spec for a 20
year old obsolete OS.
> > Actually, people don't go for fat girls. Some people are more willing
> > to *tolerate* obesity or maybe even have a fetish for it, but that's
> > not the same thing as being attracted to it.
>
> You obviously don't know some of my friends :-)
Now *that* sounds more interesting than anything else in this thread. :-)
> That's a bit Freudian: either you're obsessed with sex and death, or you
> simply haven't realised that you are yet. It's a bit no-win, really.
No, it's not Freudian. The unconscious features in all schools of
psychoanalysis and is an independently verifiable fact. As for Freud,
his insane ramblings are what repulsed me from psychoanalysis until
very recently.
> > Because they already have a vested interest in them. If they don't
> > inflict unnecessary contortions on the new generation then that
> > proves they were morons to accept these same contortions from their
> > own teachers.
>
> If they have seen that they are contortions and continue to use them,
> then they're being very obtuse. Progress is made when they see the
> contortion and fix it. And progress is made.
I agree completely, but they have a vested interest in *not* seeing
them as contortions. It's simple self-justification.
> > I know plenty of non-physicists who would like to learn physics
> > but they don't want to *do* physics and the moment they admit
> > this to a physicist, they're screwed.
>
> It seems that at least half the physycists I know have little intention
> of doing physics after the degree.
That's a recent development.
> > In general, all fundamental particles *are* solitons.
>
> I said 'in *general*'. Not all solitons are particles: they were first
> observed on water.
By a Scottish engineer. Yeah, yeah everyone knows the story ... oh that's
right most people don't even know what solitons are, and that's my point
isn't it?
> The mass schooling systems's sole purpose is to teach te children up to
> a set standard. It tends to do it using the aforementioned methods, but
> that is not its supposed purpose.
Since blind obedience to authority is *harmful* to the learning experience,
the justification that it is indoctrinated to further teaching is invalid.
The indocrtination aspect of schools behaves like a self-contained set of
goals that have priority *above* teaching; iIf you look at what's more
difficult to change in a school, what it teaches or what it indoctrinates,
you'll soon find yourself questioning its motivation. Knowledge and wisdom
are not needed for the perpetuation of the status quo, only obedience.
> > Your last sentence is incorrect. And your first sentence is not the
> same
> > as your previous claim. There may not be any /particular/ guarantees
> but
> > there most certainly are some general guarantees.
>
> Are there?
Yup; being worth the time and effort of acquisition and installation
seems like a common one.
> > What's a skip?
> A big, metal, yellow thing that you hire out to throw large quantities
> of rubbish in to. Eventually, a bad-tempered bloke will come along with
> a lorry, pick it up and take it to the dump, spilling half the contents
> along the road in the process.
Ooookay.
> If you've never seen him before (you're a sales rep for a lab supply
> firm) giving away free samples. The problem with analogies is that they
> tend to get stretched a little thin after a while.
My only point was that "I take no responsibility" is nonsense since
it ignores all the shades of gray in a situation.
> If you were informed that he did not know the interface or if they were
> compatible with anything?
That would change my expectations, would it not? If there was a big
chance that the drives were useless because of this, I wouldn't even
pick them up in the first place.
> > > A program is an operator. A processor is an object used by a
> computer to make
> > > a program work.
>
> > A reasonable argument. Unfortunately, it's symmetric and you can use
> that
> > argument to say that "10" is the operator on which f(x) works. Your
> argument
>
> You can't say that. 10 can never operate on 20 in any way without an
> operator. 10 is incapabl e of performing operations, so it is not an
> operator.
Alright, that's reasonable.
> > fails because f(10) is not the proper analogue to a process. Instead,
> a
> > process is +10, a program is 10 and the compilation process that
> results
> > in +10 is the +.
>
> I disagree. The program creates or defines `+'. The process is an method
> used to connect the `+' and the 10 together inside a computer.
That's another way to think about it. But note that before the + is
data before it connects to anything. Unlike f(x), there is no implicit
composition of functions defined for +.
> Reverse engineering is usually used to describe the process of having a
> black box that does something and making a version that works in the
> same way by analysing what comes out and what goes in. Aren't there any
> documents describing the architectural design?
Linus certainly never wrote any! What passes for documentation of the
design is "The Linux Kernel Hacker's Guide".
> I have to say that I think that free and bad is still free.
"You are free to shoot your own foot" is technically a freedom, it's
just not any kind of meaningful liberty.
> > The GPL is necessary but *not* sufficient to ensure liberty.
> > The GPL defines "source" as "the preferred format for human
> > manipulation" (going from memory). Well, C/C++ is not source;
> > Smalltalk code compiles *down* to C code.
>
> C/C++ is source if it was written in C++. Machine code is source if the
> program is written in machine code. I think it is reasonable to define
> source as whatever the author actually wrote.
And postscript is source if someone is stupid enough to write in it?
> > Between compatibility and "everything else", I'll pick everything
> else.
>
> It really depends on what your needs are.
My needs are higher than what any Unix can ever provide. Most people's
are, they're just unable to do anything about it.
> If they like it then why not? Personally I like the UNIX command line
> interface. I, infact rarely use the GUI after discovering SVGATextMode,
> which, by the way, rules.
The GUI isn't particularly humane.
> > I don't deny that compatibility can be a reason for bad design, but
> all
> > too often it's just an excuse. And you can tell which is which by what
> > the programmer does when the excuse is removed.
>
> Often that's never done, so you can't tell. Personally, I give them the
> benefit of the doubt, you, aparently, don't.
The excuse is largely removed in the case of large application interface
design. The developers deliberately choose to create anti-human interfaces
and copy all the anti-human aspects of old interfaces (which is unnecessary).
> How does having 2 parents create a union of directories?
It doesn't, it just removes the need for them (mostly). The Plan 9
people needed to show the PATH information as a part of the namespace,
a worthwhile endeavour, and this can be done simply by creating a
directory 'environment' under the user's home directory and then
hard linking to all the directories involved.
> What exactly do you mean by a lattice structure. In UNIX, you can get a
> general graph with the use of soft links. In linux, you can do the same
> with hard links (root can create hard links to directories).
No, it can't. That's just a detail left over from the fact that 'mv'
requires temporary creation of a second hard link to a directory. And
in any case, what a god can do is irrelevant. Moreover, symlinks are
an ugly kludge and irrelevant.
> > They just replaced it with another concept that's equivalent
> > in bogosity to root. Now I remember: they invented "null" users!
> > What a load of crap!
>
> A null user? Sounds like our old friend, `nobody' to me.
Or was it 'none'? Whatever. IIRC, they also invented "group leaders"
and gave them special powers.
> > There's nothing wrong with devices as files but there is something
> > wrong with devices in the /filesystem/.
> Where else do you put files, if not in a file system?
In /other/ components of the OS that behave like the FS and are
connected to the FS by powerful bi-directional mounts so that from
the user's perspective it all looks exactly like one giant FS.
> > If I mount yourMachine under /myMachine, then I can do 'list' and see
> > /myMachine/yourMachine, but when you do 'list' you can't see anything
> > different from your end.
>
> I see. You can make mounts bidirectional if you use 2 of them. With the
> apropriate scripts, it could work well enough.
Actually, it wouldn't because mounts have to work across multiple FSes.
If Alice is a user on machine1, Bob on machine2, and Cindy on machine3,
then it should be possible for Bob to create a mount to machine3 (after
Cindy allows access to the machine), then Alice to create a mount to
machine2, then Alice to create a mount to machine3 passing through Bob's
machine. And when Bob removes his mount to machine3, the mount passing
through Bob's machine should still work.
And even if you make that work, it doesn't change the fact that inside
a single machine, components are *nested* inside each other (with most
components being nested inside the Ram component and the Ram component
being nested inside itself) and in Unix mounts don't work with other
components than the FS. In Plan 9, you *could* create a version of my
concept of portals but they wouldn't be as clean since Plan 9 has state.
(You can probably tell that I spend longer thinking of what can't work
in Unix than how to make it work.)
> > No, that's just the shell keeping track of where you've been to
> compensate
> > for the limitations of unidirectional links. You never actually "go
> back",
> > you just "forget" that you ever went forward and you suddenly find
> yourself
> > back.
>
> The effect is the same.
It's not the same when you encounter symlinks you never traversed.
If there's a symlink from my home directory to your home directory,
then how are you to ever know about it?
> > > OK, so create 2 symlinks. Easy enough. So you can have
> unidirectional *and*
> > > bidirectional links.
> >
> > Symlinks are a kludge in the first place, I don't plan to ever
> implement them.
>
> OK, but i think that's doun to preference.
Uhhh, no. Symlinks and hard links behave in fundamentally different
ways. You see, "owning" a file means having a hard link to it. If we
both have hard links to a file and I remove my link to it then it's
still your file. If you only have a symlink then you're screwed.
> You could easily write a script to create / remove bidirectional links.
> It might be a kludge, but it works.
Only if you replaced the normal 'rm' with that script. And of course,
things would *still* not be symmetrical since the permissions on
symlinks do not override the permissions of hard links. Nor is "creates
a link to" a transitive operation! If I create a link to you and my
friend already has a link to me, he can't necessarily create a link
to you using my link. Because while you and I are in the same group
and may share some access, and he and I are also in the same group,
this doesn't mean that you and he are in the same group. The only way
to make it look like it works is if you set the world execute bit on
all directories so that my friend can go down your directory hierarchy
without being you and without being in your group. And of course,
that's just stupid.
> > there is no legitimate reason for users being able to create
> unidirectional
> > links ....
>
> I don't see why not. It only makes sense for links to files to be
> unidirectional.
Nope, it doesn't. Being able to tell where all the hard links
to a file are is a perfectly legitimate operation. If I create
a hard link to a story from Star Trek, Stargate and Crossover
and I decide that I don't like the story then I should be able
to just delete it. Additionally, I may decide that I want to
give Alice and Bob (who aren't in any convenient group) read
access to the story but not Cindy and so long as they're not
owners, I should be able to change my mind and remove their
access. You can do this if you have directed bidirectional
hard links. You can't do this with unidirectional hard links
or symlinks. Unless of course you're the god of the machine
at which point you create a new group with just Alice and Bob
in it. But this is a common operation and shouldn't require
divine intervention.
> > Additionally, how are you going to *find* the paired symlink? If you
> only
> > have one bidirectional link then there's a function that provides the
> other
> > side's name.
>
> You'd have to kludge it (keep a file or something). It would work,
> though.
Maybe. There's a whole list of other problems with the scheme. And
every time you kludge one, it bloats the code and makes Unix that
much more of a haven for bugs. It also makes it impossible for
someone to learn how the system actually works. Far simpler to do
away with unidirectional links entirely.
> It's consistent for a tree structure. You need more information to go
> up, rather than down. In this case you supply only the information that
> you need. Again, using a symlink, you could effectively rename it,
> though .. would still exits.
Trees are incredibly weak structures.
> > of them. Like I said, the fact that you have backends to directories
> is
> > inconsistent with the fact that you can't have backends to files.
>
> I suppose that there's no need to record in the file where it's come
> from, since it's usually ovbious (buried in the pathname or in the cwd).
Hehehe. The problem with tree structures is that they assume that
everything can be sharply divided and compartmentalized. Pedestrians
aren't related to automobiles in any way, they never interact with
each other, and crosswalks are only for automobiles. This was a big
problem in urban design (still is).
> Again, I'm not exactly sure what you mean by a lattice. I don't think
> user is a superfluous concept. What about object ownership.
A user is a very, *very* high level concept. In a capability system,
you have users keeping track of what objects they own. That way, users
have a concept of "object" (which they will have anyways) but objects
do not have any concept of users.
root
/ \
/ \
user1 user2
\ /
\ /
user3
user3 might be a program, or users 1 and 2 might be sharing sysadmin
work on the machine. There are many reasons why you would want this.
> > > A general graph is probably the best abstraction.
> >
> > Bingo. Though the difference between a graph and a lattice
> > (the ability to create cycles) is questionable.
>
> lattice = acyclic graph?
I didn't remember the difference between the two at the time ...
Lattice = partially ordered set.
root is higher than user1 and user2 and both user1 and user2 are
higher than user3, but the relation "is higher than" is not defined
in the case of user1 and user2.
If you define "undefined" links on the lattice (links that neither
go up nor down) then you get an acyclic graph, sortof.
> If that's the case, I think I understand some of your previous comments
> a bit better. I not convinced cycles in a `user' tree would be good.
> They may be in a filesystem, but then you need garbage collection which
> is very expensive for a whole FS.
Yes. At a high level, you still want to allow cycles in the system but
you can do this by allowing portals (mounts) to form cycles, which you
have to do anyways since there is no way to check that they don't!
And actually, forming a cycle in the user tree would be ... interesting. :-)
> True. I'm not of the opinion that the unix way of dealing with users is
> the be all and end all of doing it. A tree is interesting. I suppose a
> user could create others beneath him in the tree. In an acyclic graph
> (lattice) it gets more tricky when you want to link from your branch to
> someone elses.
Well, it's a pretty simple recursive operation to check that when you
want to make A parent to B, then B isn't already an ancestor of A.
*Expensive* but simple. What's tricky is creating new bidirectional
links since you want to form new portals transparently ....
> Possibly. I switched systems to linux, because I found te old system a
> hinderance. I dont' feel that now, which means that it is good for me.
I can accept that. I felt that Linux was a huge hindrance when I couldn't
keep my /fiction directory hierarchy straight.
> There are dimishing returns. The system I use is very good. To make it
> worth while learning a new one, it would have to be a fair bit better.
> Besides, there is always the thorny issus of compatibility.
The bane of my existence. :-)
> > > Computing is a branch of mathematics.
> >
> > Maybe for the people who deal with Turing machines and P vs NP
> problems.
>
> The rest is like the broken, applied and hacked maths that the rest of
> us use day to day :)
Ahhhh, now I understand! <grin>
> The promary idea is to efficiently convey ideas to a computer. is's
> quite good for a laarge subset of these.
Well, the idea behind Literate Programming is that this is incorrect;
that the purpose of programming languages is to communicate with other
humans first and foremost. This is also the idea behind OO.
> > > Eh? No what I'm justifying is a camera that some people find
> unuseable and
> > > some people really like. What is wrong with that?
> >
> > The fact that nobody actually finds it usable?
>
> But I said some people do find it useable (and like it).
I like lots of things that are unusable ....
> > > The purpose of english is to allow people who speak it to
> communicate.
> Well, that is the sole purpose of any language.
Not quite. The purpose of programming languages is to
communicate ideas to other humans /about/ computers.
Natural languages' purpose tends to be very general
but not all languages are good at the same things;
there are no separate concepts for 'mind' and 'spirit'
in French (and IIRC German) so if you say 'mind' to
a French speaker he may accuse you of going mystical
even if you're talking about Artificial Intelligence.
> No, but it's a coincidence that it has this purpose. It is no more
> suitable than many other languages. In fact it is quite unsuitable
> because of the ambiguities it allows. Have you ever seen hardcore legal
> documents? They result from people removing ambiguities, and they're
> horrible.
:-) I haven't read many.
English is most suitable for a variety of non-technical reasons;
primarily that it is the language of the American empire.
> > Linuxers have something personal against the dominance of Windows
> > then why can't I towards the dominance of Unix?
>
> OH! It all comes in to the light! Why didn't you say so earlier?
LOL!
> I think your OS sounds interesting and would like to try it out at some
> stage. However, I haven't any time at the moment, and i don't know
> smalltalk.
Thank you but that's a bit premature. I'm looking at 5-10 years before
it becomes useable; I don't know how much effort I should put into making
a mock-up. Smalltalk code is fairly easy to follow along, even if you don't
write the language (French is easier to learn how to read than to write too).
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
