Linux-Advocacy Digest #146, Volume #29 Sat, 16 Sep 00 21:13:06 EDT
Contents:
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Richard)
Re: "Real Unix" Vs Linux ("Rev. Don Kool")
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Richard)
Re: "Overclocking" Is A Bad Idea (Mark S. Bilk)
Re: "Real Unix" Vs Linux (Gary Hallock)
Re: Because programmers hate users (Re: Why are Linux UIs so crappy?) (Donovan
Rebbechi)
----------------------------------------------------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: Sat, 16 Sep 2000 23:14:44 GMT
2:1 wrote:
> In article <[EMAIL PROTECTED]>,
> Richard <[EMAIL PROTECTED]> wrote:
> > Which is quite telling. But it's not a big surprise that programmers
> > wouldn't be interested in helping users, even if they are
> (technically,
> > not mentally) users themselves.
>
> I think that you are paranoid about programmers. You should try
> programming a bit yourself---mabey then you will see the other
> positions point of view.
I do program, I just don't think of myself as part of some
elite called "programmers" (not least because I do a hell of
a lot more design than programming). And I don't know how you
can say that programmers don't hate users with a straight face
when on this very same thread there are posters complaining
about Real Lazy users, which apparently includes everyone who
isn't willing to spend hundreds of hours finding and learning
about features that should by all rights be right in front of
them.
If you doubt that programmers loathe users and that they inject
this loathing into their programs (unconsciously of course) then
you should take a look through http://www.cooper.com/design.html
The site only explains how programs act towards users like mean
sons of bitches, it doesn't actually explain the reason why an
application would be written to act like an asshole.
> > And writing an "openfile" command would not be sufficient for
> > consistency. The shell would still treat "executable" and "non-
> > executable" files in completely different ways for no justifiable
> > reason whatsoever.
>
> Look at maths for a justifiable reason:
>
> x is a variable (like data)
>
> +, *, d/dx, grad, etc are operators which operate on variables, like
> programs operate on data.
>
> Data and operations (data files and programs) are conceptually
> different. Porgrams operate on data. Data can not do operations; it is
> opperated on.
but a program is *data*; the correct analogue for an operator is a
process. A process is the result of another process (the execution
server) applied on data (the program). So what I'm actually doing
is making a sharper distinction between operators and data.
> That is one justifiable reason. I'm not asking you to agree that it is
> the way you want computers to work, merely that there are justifiable
> reasons for it working that way. Personally, I'm from a mathematical
> background (engineering) and I (as a user) prefer it to work that way.
I'm from a pure math background so I also like things to be consistent.
I'm also very used to dealing with abstract concepts of all kinds (math,
physics, philosophy, you name it) so I'm very good at discerning incon-
sistencies and also very critical of them. And I've spent years finding
out the principles behind good OS design.
> You run in to problems with more complex processing of files. If you
> have a file, say
> index
> and you order the shell to open it. How can the shell know whether to
> open it in a viewer/editor, run it through sort, archive it or use the
> list of files in it to create a CD image, compile it or execute it?
>
> If you're in the habit of processing data, some of the above choices
> would be reasonable.
Agreed. But many, many more choices would be completely unreasonable
and even nonsensical. The shell could easily maintain a list (in a
user-accessible manner) of associations (though "index" has no
extension, so it wouldn't work) and then ask which one the user
wants at run-time; much like bash currently does filename completion.
You'd type
$list\ of\ songs.playlist
and press [tab]
then it would fill in the line with
$xmms list\ of\ songs.playlist
and if there was more than one option then it would display them all,
just like filename completion
> > In some OSes, the creation of a process
> > from a program is done through a separate server process
> > and the identity between opening and execution is obvious.
>
> Sorry, I don't follow.
Many years ago, someone proposed for HURD (maybe it was VSTa)
that a user could replace the standard execution server (the
process that creates a new process based on a program) with a
more complex server that understood different executable formats
and maybe even the need to run a program under emulation.
> I have to say that I agree. In a GUI, I and most of the people I know do
> simple data manipulation: open the file in an editor, do some edits
> ,print it then quit. With the kind of operations done in a GUI, it
> usually makes sense to have a simple assosciation. that is, until you
> get DnD, but then you don't really need assosciation as much.
> IME the shell is usually used for complex manipulations and having no
> distinction between data and operators would be a pain.
Then it depends on your view of the GUI. I don't think that a GUI should
provide added functionality if it can help it. Check out 3Dsia at
http://threedsia.sourceforge.net/about.html
At one point they emphatically state that 3Dsia is not just a filesystem
viewer, that it adds a lot of functionality that the filesystem does not
have. This is correct, but all it proves is that the standard Unix file-
system is broken and that it lacks the functionality that it should have.
If the system on top of which 3Dsia is to be built were elegant, powerful
and consistent, then 3Dsia's only role *would* be visualization and it
would've been done in a few weeks by a single programmer instead of still
being incomplete after half a dozen people spent more than a year on it.
IOW, I don't think that associations belong in the GUI.
> > That's because you've never heard of Persistence before.
> >
> > And not closing a program is *not* the same thing as having
> > useful persistent process. Unix processes are designed to be
> > one-off entities and Unix counts on this fact.
> Why is this a bad thing? With most programs you can keep configurations
> in an rc file, so all instances open with the same configuration.
Unix counting on processes being one-off means that it's not possible
to shut down the computer and retrieve the processes you had (with all
of their state) after you reboot. By all rights, I *should* be able to
reboot my machine right now and get back all of the machine state I
left it in (including an open text editor window, and all the text I
have typed in so far). None of this "saving" something *somewhere* and
then manually retrieving it; I already know where my email is, it's on
my monitor right in front of me! Why should this be destroyed just
because I want to switch OSes for a moment?
> > > Well yes, there is. Even a web server typically starts a seperate
> process
> > > for every user. There is no clear benefit to running everything in a
> single
> > > process.
> >
> > There is in running everything in a single *task*. A single input
> queue for
> > one.
> Why should a server have a single input queue? Surely it needs to handle
> multiple connections? Also, a collection of server processes could be
> considered as a single task.
Okay, we're getting into irrelevant semantics. My original concern is
that the program->process conversion happen as little as possible. You
can create new processes just by copying parts of the old one and I won't
care, but if programs are constantly being converted into processes
for no good reason and this is not transparent to the user (as indeed
it isn't in Unix since internal state is not preserved across activations)
then something is very wrong.
Now, as far as input queues go, it does make sense to have one per user
(say /process1/input/user1/, et cetera) but it doesn't make sense to have
one per process. Additionally, the input queues should be *meaningful*
to users; eg, adding a hardlink to a file in the input queue of Emacs
might create a new buffer with the contents of that file. And if you
have a useable security scheme (which you don't in Unix) then a single
Emacs process should run per machine.
> The problem with your design is that you are ignoring one group of
> users, and providing for a different group. This is your main complaint,
> but with the groups reversed.
That's right, I'm concerned with Users and Software Developers. What
I'm not interested in is anyone who wants to maitain the status quo
for some bizarre reason, or anyone who wants to maintain a difference
between functionality available to programmers and that available to
users (which includes most Programmers). And I draw a difference
between a Programmer and a Software Developer.
Unix maintains a sharp divide between users and programmers (so does
every other OS I know of but that's not the point) and one of the
consequences of that divide is that the GPL is pretty meaningless
to users. Well, I'm interested in winning this class war for the
users and if the other side gets hurt in the process, I don't care.
What's interesting to note is that programmers, as individuals,
hurt themselves by waging this war against users and maintaining
their, collective, superiority towards users. Programmers are sadled
with an OS that's horrible to use and program for just so they can
scare away users.
You see, interfaces are actually languages. Not "like" languages
but *are* languages. When you learn an interface, you're actually
learning idioms in some language (what scrollbars do is an idiom
in a graphical language) that lets you express thoughts. Well, one
of the most important roles of language is to include some people
and exclude others. And that's what programmers do on a regular
basis. Now here's the important part: I don't give a shit about
exclusion or inclusion, I just want the language to make sense, to
be powerful, to be elegant, et cetera. And "powerful" to me refers
to what *users* can do with it, not what a clique of programmers
can do with it.
------------------------------
From: "Rev. Don Kool" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.admin
Subject: Re: "Real Unix" Vs Linux
Date: Sat, 16 Sep 2000 23:20:27 GMT
Gary Hallock wrote:
> "Rev. Don Kool" wrote:
> > I don't trash LINUX, my son. It is a good little system for
> > students, hobbyists and tinkerers. I merely pointed the original
> > poster to a more suitable newsgroup for his questions.
> Uh, yes you do. You are just too blind to see it.
No, my child, I do not. I have no reason to down your hobby.
LINUX has become quite the Gen-X phenomenon these days. College
campuses and kids' bedrooms are rife with it.
> Some hobby OS, Linux.
Indeed.
> I have
> been running it on a 12-way S/390 for a few months now.
My condolences. :-(
Couldn't your employer afford OS/390?
> Windows can't do that.
No, Windows doesn't run on an S/390. It is of course the OS of
choice for PCs.
[...typical Gen-X ad hominem snipped...]
Yours in the glory that is our Lord Jesus Christ,
Don
--
********************** You a bounty hunter?
* Rev. Don McDonald * Man's gotta earn a living.
* Baltimore, MD * Dying ain't much of a living, boy.
********************** "Outlaw Josey Wales"
http://members.home.net/oldno7
------------------------------
From: Richard <[EMAIL PROTECTED]>
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: Sat, 16 Sep 2000 23:43:06 GMT
Donovan Rebbechi wrote:
> On Sat, 16 Sep 2000 17:46:43 GMT, Richard wrote:
> See the manpages for "magic" and "file". The fact that there doesn't
magic and file (and I've known about them for maybe 5 years thank
you very much) are a Rube Goldberg solution to a very, very simple
problem. And as such, they are only available to programmers, not
to users. No user can meaningfully use magic.
> exist a command shell that automatically handles file types is due to the
> fact that no one seems to want one. It's not a design limitation.
One of the first things I noticed when I first got Linux was that
there were no extensions, and that seemed stupid. When I asked about
it, someone waved me at magic and file, and that shut me up. It wasn't
for many years that I got the confidence necessary to believe that
Linuxers don't know what the fuck they're talking about and are just
being assholes. If users don't seem to want something useful, it's
through intimidation of the kind you are using. If you actually cared
to listen to user demands you would find their list is endless. And
if you were being empathic towards those same users, you might decide
that this endless list of demands is quite reasonable.
> There is no such functionality in the command shell -- again, I
> suspect that this is because no one cares. You are the first
> person I've heard dream up such a thing, and I've been hanging
> around several Linux forums ( user and developer ) for the last
> three years or so.
Well, I've only been thinking about what should be possible in a
good operating system and what should not (and how to design an
OS that accomplishes *everything* in the first category and allows
for *nothing* in the second) for the last five years, off and on.
And I can tell you that to dream the big dream, it's simply not
good enough to know the principles behind Unix. Try Plan 9, VSTa,
Grasshopper and Smalltalk *for a start*.
------------------------------
From: [EMAIL PROTECTED] (Mark S. Bilk)
Subject: Re: "Overclocking" Is A Bad Idea
Date: 16 Sep 2000 23:52:22 GMT
In article <[EMAIL PROTECTED]>,
Jim Broughton <[EMAIL PROTECTED]> wrote:
>"Joseph T. Adams" wrote:
>>
>> Mark S. Bilk <[EMAIL PROTECTED]> wrote:
>>
>> : Semiconductor chips are designed and tested to have safety
>> : margins in voltage, temperature, clock rate, etc. Running
>> : a chip beyond its specifications throws the margins away,
>> : so that changes in any of those parameters may cause failure.
>>
>> I would add that CPU is often *not* the performance bottleneck for
>> common tasks (although it may be in certain situations). Overclocking
>> even by a significant amount will not help performance measurably
>> except for CPU-bound tasks, and, as Mark pointed out, it increases the
>> risk of temporary or permanent system failure.
>>
>> People who really know what they're doing, and know the risks, can
>> sometimes benefit from slight overclocking, but the average user
>> should definitely NOT try this. Getting more RAM, building a leaner
>> kernel, and eliminating unnecessary daemons will give far more
>> performance "bang for the buck" for a pretty substantial majority of
>> people.
>>
>> Joe
>
> Overclocking in an of ifself is not BAD. If done properly with the
>correct selected hardware overclocking can be a viable solution to
>an otherwise expensive upgrade. With the newer pentium III coppermine
>chips overclocking is a very reasonably easy thing to accomplish.
>You need a motherboard capable of very small incremental core voltage
>increases and decent Front Side Bus speed increases. An Intel BX chipset
>is also highly disirable. A good AGP graphics card that can handle higher
>clock rates is also a must. The most limitig factor in all of this is your
>memory sticks. PC100 SDRAM is an iffy thing as some can and some cant be pushed.
>PC133 is the ideal. (wish I had some of them). Anyway I currently have
>a pentium III 550 overclocked to 682 this is with a core voltage increase of
>1/10 of a volt and an FSB of 124. It runs rock solid and has been for over
>6 months.
682 / 550 = 1.24 This overclocker is getting a 24% speed
increase, which is *barely noticeable*. In order to do it,
he's overheating his CPU (and other chips), since the heat
generated is at least proportional to the clock frequency,
and is also operating the CPU beyond its specified voltage,
further increasing the heat burden, and also increasing the
rate of dopant atom migration within the silicon, which
shortens the life of the chip.
This type of operation throws away all the safety margins
engineered into the CPU, which means that the results of
all its arithmetic and logical operations can no longer be
trusted as correct as tested by the manufacturer. Small
variations in room temperature or line voltage could cause
the CPU to make errors and thus to corrupt files.
If one isn't writing any files (except game scores), and if
one intends to junk the machine for a faster one after a
year or two anyhow, then burning the CPU into an early grave
and getting possibly corrupt data may not matter, and the
24% additional speed presumably provides the same sort of
satisfaction as modifying one's car engine to reach higher
speeds.
But using a computer that is or *has been* overclocked, for
any non-game application, is running a great risk for no
benefit whatsoever.
> I will admit that OLDER hardware is rife with problems in overclocking
>ability while NEWER hardware is much more overclocking friendly. I would
>also point out that the HIGH end pentium III chips are already maxed out
>as they come from the factory (900 mhz or higher). The ideal overclocking
>pentium III coppermine chips are the 550 600 and 650.
> We gamers just love to push our machines to the max to get better gameing
>performance. The side effect is that it works with linux and results in a much
>better X windows performance. Also linux games receive the same benefit as their
>windows counterparts.
------------------------------
Date: Sat, 16 Sep 2000 20:08:28 -0400
From: Gary Hallock <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.admin
Subject: Re: "Real Unix" Vs Linux
"Rev. Don Kool" wrote:
> Gary Hallock wrote:
> > "Rev. Don Kool" wrote:
>
> > > I don't trash LINUX, my son. It is a good little system for
> > > students, hobbyists and tinkerers. I merely pointed the original
> > > poster to a more suitable newsgroup for his questions.
>
> > Uh, yes you do. You are just too blind to see it.
>
> No, my child, I do not. I have no reason to down your hobby.
> LINUX has become quite the Gen-X phenomenon these days. College
> campuses and kids' bedrooms are rife with it.
>
He, Thanks for the complement. Sort of like being carded at a bar. I'm
afraid I haven't been that lucky in 20 years.
>
> > Some hobby OS, Linux.
>
> Indeed.
>
> > I have
> > been running it on a 12-way S/390 for a few months now.
>
> My condolences. :-(
>
> Couldn't your employer afford OS/390?
Funny. Do you have any idea who my employer is? Hint - I get OS/390 for
free.
Gary
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Subject: Re: Because programmers hate users (Re: Why are Linux UIs so crappy?)
Date: 17 Sep 2000 00:23:52 GMT
On Sat, 16 Sep 2000 23:14:44 GMT, Richard wrote:
>2:1 wrote:
>I do program, I just don't think of myself as part of some
>elite called "programmers" (not least because I do a hell of
>a lot more design than programming). And I don't know how you
>can say that programmers don't hate users with a straight face
>when on this very same thread there are posters complaining
>about Real Lazy users, which apparently includes everyone who
>isn't willing to spend hundreds of hours finding and learning
>about features that should by all rights be right in front of
>them.
If you're referring to me, well you are just wrong. I am not an
"elite" programmer, and unlike the whining brats in this thread,
I have actually contributed something to the community to make life
easier for users, instead of hurling abuse and divisive class-warfare
rhetoric against an imaginary enemy.
I understand perfectly well if users don't want their computer systems
to be difficult to learn and use. In fact if users want to be lazy, I
don't even have a problem with that.
What I have a problem with is users that want to be lazy *and* abusive
and rude. If you want to start bashing people, you had better have a good
argument, because if you don't , there are people who will shoot you down
in flames without thinking twice.
If you want to go on the attack, that's fine, but don't expect everyone
to take your insults lying down.
>If you doubt that programmers loathe users and that they inject
>this loathing into their programs (unconsciously of course) then
What, do you suppose that someone writes software and gives it away actually
hates the users ? If they hate the users, then why do they give
the software away in the first place ? Or is the software simply a sinister
tool designed to make life difficult for users ?
>you should take a look through http://www.cooper.com/design.html
>The site only explains how programs act towards users like mean
>sons of bitches, it doesn't actually explain the reason why an
>application would be written to act like an asshole.
The reason why is that the programmers, like the users, are often lazy.
Writing an application that does *not* act "like an asshole" and does
not* force the user to jump through hoops, is hard. There's no evil
conspiracy. Only laziness.
>I'm from a pure math background so I also like things to be consistent.
>I'm also very used to dealing with abstract concepts of all kinds (math,
>physics, philosophy, you name it) so I'm very good at discerning incon-
>sistencies and also very critical of them. And I've spent years finding
>out the principles behind good OS design.
I'd agree that no perfectly edsigned OS exists. Depending on how
much computing you've been exposed to, you may or may not appreciate the
fact that compatibility tends to be very important in practice, and that
often, compatibility will win over good design. ( examples include
CPUs, programming languages, and operating systems )
You may notice that the most popular OSs are the most "compatible"
ones ( Win 9x ), while some OSs that are clearly superior in terms of
design are less popular ( for example, NT )
If you want to design and implement the perfect OS, well that's certainly
a reasonable thing to want to do, but it's not going to get done
as a result of someone saying nasty things about developers in
.advocacy.
[ snip ]
Your idea regarding a command shell is certainly interesting. I can't
say that I'd use it, but that doesn't alter the fact that it's interesting to
me .
Part of the reason it's interesting is that I haven
't seen anyone come up with anything like it.
You might find that surprising, but though the idea seems obvious to
you, I haven't seen it before. ( Maybe you should go get a patent ;-)
>IOW, I don't think that associations belong in the GUI.
It's worth mentioning that some typing occurs at a lower level than
the GUI. As I said, see "magic" and "file". But even this is not at as
low a level as you seem to want.
>Unix counting on processes being one-off means that it's not possible
>to shut down the computer and retrieve the processes you had (with all
>of their state) after you reboot. By all rights, I *should* be able to
>reboot my machine right now and get back all of the machine state I
>left it in (including an open text editor window, and all the text I
>have typed in so far). None of this "saving" something *somewhere* and
>then manually retrieving it; I already know where my email is, it's on
>my monitor right in front of me! Why should this be destroyed just
>because I want to switch OSes for a moment?
FYI, GNOME and KDE have session management. Again,m this is
somewhat superficial compared to what you are describing. Is there
an OS that actually implements this kind of thing ? ( I mean at a
kernel level ).
>That's right, I'm concerned with Users and Software Developers. What
>I'm not interested in is anyone who wants to maitain the status quo
>for some bizarre reason, or anyone who wants to maintain a difference
I don't think anyone "wants to maintain the status quo". The reason that
compatibility tends to win over design has a lot to do with the fact that there
are a lot of software systems and applications that need to be rewritten
when you create a "new thing".
Personally, I have no problem with someone writing a wonderfully designed OS,
but I don't expect to be shouted at for not writing one -- I neither have
the technical skills, the time, or the interest to do so.
>Unix maintains a sharp divide between users and programmers (so does
>every other OS I know of but that's not the point) and one of the
>consequences of that divide is that the GPL is pretty meaningless
I disagree with this. I am personally not clear on whether I am a "user" or
a "programmer", I mean, really I am both. I am a Qt and libstdc++ user,
and I'm a "dumb user" for that matter -- I am not capable of writing these
things I'm using myself.i
I write code, but I also write documentation for users, and
since I usually write just after
I've learned to do it, it tends to be from a user-perspective.
Projects like KDE and GNOME actively seek input from users and non-programmers
( for example, they have artists, translators, documentation writers,
and simply "users" all of who contribute )
>to users. Well, I'm interested in winning this class war for the
>users and if the other side gets hurt in the process, I don't care.
There are no two sides and you are charging head first at a windmill.
>What's interesting to note is that programmers, as individuals,
>hurt themselves by waging this war against users and maintaining
I don't see any war. I just see someone trying to pick fights on usenet.
The failure of programmers to design some perfectly designed, elegant
OS is not the result of some evil conspiracy. It has more to do with
compatibility ( which the *users* demand ) , and the fact that some things
are not that easy to implement. () If you think your ideas are easy to put
into practice, well, go do it. )
>their, collective, superiority towards users. Programmers are sadled
>with an OS that's horrible to use and program for just so they can
>scare away users.
Well, I've done UNIX programming, and I can tell you that the
nastiest thing about programming UNIX is that it's saddled with a lot of
legacy stuff. The problem has more to do with the need for compatibilty
than anything else. For example, you want to write nice OO code.
Java isn't in a very good state yet. So you use C++. But all the
APIs you need to use are in C. So you need to saddle your code with these
messy "C-isms".
Toolkits that don't come saddled with C-isms ( such as QT and KDE ) are
a pleasure to use.
So I'd say that the need for compatibility is what makes life a pain.
It's not because programmers are "nasty".
>exclusion or inclusion, I just want the language to make sense, to
>be powerful, to be elegant, et cetera. And "powerful" to me refers
>to what *users* can do with it, not what a clique of programmers
>can do with it.
THis raises the compatibility vs design issues. If you don't care about
compatibility, "good design" is easier, but the uisers will not appreciate
the lack of compatibility much more than they appreciate bad design.
--
Donovan
------------------------------
** 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
******************************
