Slashdot Mirror

Check out http://www.acm.org/cacm/AUG96/antimac.htm .

There he is saying exactly what I've been feeling but haven't been able to express about graphical user interfaces.

The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston).

Could it possibly look something like the Anti-Mac interface?

Jakob Neilsen has some interesting stuff on his Web site, such as his Death of File Systems paper, on why he thinks that the hierarchical directory tree model isn't necessarily what you want to expose to the end user; there's also a paper by him and Don Gentner, Anti-Mac, with thoughts on what a different-and-possibly-better user interface might look like.

Greetings! For what is worth, I found the article in the ACM Digital Library. It originally appeared in the February 1997 issue of ACM Interactions, pp. 40-53. The article includes many more graphics and photos than the article that prompted this posting on /.

I am not sure about posting this and copyright issues, though, and I'm too lazy to dig out my ACM membership to check the rules. If anyone can confirm a source where ACM says it's OK to post it I'll make the PDF file available.

For those of you who are ACM members, search for "Inventing the Lisa Interface" under title and "Ludolph Perkins Smith" under author. The PDF file is about 1024 KB.

Cheers

Makes one wonder exactly where to stop distrusting once you've become paranoida about security.

The desktop metaphor is dead. Today's children use computers before they have desks.

Anyway here is an article on possible UI alternatives from Jacob Nielsen: The Anti-Mac Interface.

...richie

I've always thought that the intent was that the subject would be sitting down at a terminal with the intention of figuring out whether the conversation was with man or machine. Of course, if that were the case, the person would probably try to dupe the subject into thinking that it was actually a machine with which they were conversing. And then the Turing program would have to model that behavior as well....

I realize this isn't directly applicable to the comment I'm replying to, but as long as I'm posting, I want to emphasize that, in general, programmers are not users. If people want to write compilers, IDEs, sysadmin tools, etc., for themselves and other techies to use, I think that's fantastic. (I love emacs, gcc, etc.) But they shouldn't fool themselves into thinking that people who aren't technically sophisticated can use their program just because they and their 10 geeky friends can. If OSS authors want their software to appeal to and be usable by "the masses", they will have to do real HCI work: design, prototyping, evaluation, and iterate until it's good enough. Designing good UIs is hard and saying it's easy or calling users stupid doesn't make it so.

• What probably saves Linux most is that most users do not run programs they own, but root-owned programs. Moreover, there is a barrier between users, as well as between the users and root, which makes it hard for viruses to spread even within the system (let alone between systems).
• However, users generally have a bin/ directory to which they have write access; they also have shell startup files (``dot files'') and the like. All these things could be contaminated by viruses running at the user level. The difficulty of leaping from one user to another still exists, but if some users have ``.'' in their path, putting an infected binary in /tmp might do the trick.
• Many users carelessly download binary packages off the web and install them as root (possibly even running an install script as root). That is extremely dangerous.
• Many programs come in source code, true. But: how often do you get a cryptographic signature with the source code? How often do you check the signature? Do you review the code before compiling it? How do you know the compiler doesn't have a back door (àla Ken Thompson)? (All right, this is far fetched.)
• Even extracting a tar archive as root, something you probably do often without thinking, is dangerous. It is possible to write an archive which contains a file foo that symlinks to /bin/sh and then the same file foo containing the contents you want to replace /bin/sh by. I am drifting away from the subject of viruses to security holes in general, but this is an important fact people are seldom aware of.
• In theory, a luser cannot become root. In practice it is, in many cases, not so difficult. That is: Unix has two security barriers, one between ``not logged in'' and ``luser'' and one between ``luser'' and ``root''. The real security system lies in the first barrier, not the second. (You have seen ``hack this box'' contests: have you ever seen ``become root on this box, we give you an account'' contests?) So actually, a virus probably could spread throughout the system. In that case, the centralized, multi-user nature of the system would make things more dangerous.
• Unix lacks flexibility in the question of security. Access Control Lists, capabilities, virtualization, are being introduced, but only slowly, and they remain distinctly alien to the entire philosophy. Contrary to more advanced systems, like the Hurd, Unix/Linux does not have the possibility of creating a virtual shell around a program, to prevent it from doing harm (well, there is ``user mode Linux'', but that is still very experimental). A luser cannot split its rights, call a program with limited rights. Heck, you are not even allowed to su to nobody if you are wary of a certain program! All this makes the viruses' life easier.
• However, Unix has a few nice features. One is the strace function call. I tend, when I run an alien binary program for the first time, to systematically strace it to see which files it opens. While that does not remove the possibility of viruses, it somewhat reduces it, because something so blatant as open("/home/me/bin/sh", O_CREAT) would jump to my eye immediately.
• Also, Unix/GNU does not have the ridiculous misfeatures that made the Melissa virus possible. No mailer will unconditionally execute something found in the mail. Even xterm control sequences are rather safe (I do not think it is possible to pirate an account with cat in an xterm).
• I think the greatest asset of Linux in this domain is its heterogeneity. All Linux distributions are different. Many people have custom kernels, and so on. See: even for legitimate purposes it has often been a pain (you need an a.out/libc4, an elf/libc5, a glibc/libc6 and a glibc2.1 version of the same binary and so on). So imagine for a virus? Madness.
• Nothing is ever completely safe. The virus situation in Linux will probably worsen in times to come. But even then, it will certainly always remain better than under a Microsoft operating system.
• Just my EUR0.02...

1. There are an enormous number of slightly different compiles of the kernel and various commonly used programs out there. Because everyone can get the source, every distribution and many users compile it for themselves. This is going to mean that a virus that attacks a binary is likely to simply break it on at least some subset of systems, making detection relatively easy.
2. The Linux security model is different from that of Windows. If you aren't running as root or another account with access to various things, such as bin, there are a lot of files you just can't change.
3. Different distributions structure their configurations differently. This makes targetting rc scripts harder, but not impossible.
4. Because a large part of the configuration is found in scripts and text files, detecting the damage and determining what was done is potentially more straightforward. Joe Average User may not find it, but the local Users' Group can probably track the source of the problem for him.
5. Because we all have documentation for the configuration of everything, building tools that detect subtle changes and keep archived copies of config files is something a good and thorough programmer on a tight budget can do.
6. Because we have source, proving that you are a Real Programmer on an Open Source OS can be accomplished by a number of constructive avenues that are only available through Open Source. These may reduce the number of people seeking attention in negative ways ... maybe.

1. J. Virus Writer has access to full documentation and source for the programs he wants to attack. Finding the existance of buffers that can be overrun and the consequences is not a trial and error effort.
2. Text is easy to manipulate and most config files and start-up scripts are text. Thus, the virus can do its work by spawning sed, perl, awk, ed, emacs or several other tools. Those scripts are likely to be smaller and more portable across releases and distributions than the equivalent binaries. And they can be embedded in binaries.
3. LILO. Somebody who can install a hacked version of LILO can do some damage. And the LILO config is easy enough to edit. See my previous point.
4. Trusted binaries can be compromised in useful ways, as described by Ken Thompson in Reflections on Trusting Trust. I have some thoughts on how to make such a compromised binary nearly undetectable on the system on which it was built. I won't detail them here.

You're thinking of a compiler and login

Then you're going to realize that because you have noone else to turn to, they have no reason to rush to provide all these other services. Then you'll realize that you'll be lucky if your grandkids get to see those services, and if they do, that Time-Warner/AOL will be under no competitive pressure to keep the price low...
This is not necessarily true, if you look at this recent article from ACM Technews you will see that DSL is giving cable-modems a good run. I use DSL and I'll tell you it really kicks-ass. There are a few really bad DSL providers but in general they are doing an amazing job and the amount of competition is amazing. So although this merger is a big deal they will definatly face competition, maybe not from other cable-modem providers but from DSL.

Is this stuff for real? Even if I tried, I couldn't write a better parady of the kind of corporate-consultantspeak nonsense that
passes for wisdom in the valley these days. Or does Engelbart have to phrase it this way to get the attention of the people who
need to hear it most? Or if I had gone to business school, would I find this sort of prose as easy to parse as I do my own area of the scientific literature?


Having seen Englebart speak before (his Turing award speech at CHI 98), I can tell you that he's anything but a practitioner of the dark and evil consultant-speak.

At this point, I'd say he's a guy with ideas that are huge, so huge that he'll never see them come to fruition in his lifetime (he's pretty old already). He generally talks over people's heads, often going off on vectors, but motivated, perceptive people usually gain a few insights when they hear him.

Anyway, he is probably sincere when he uses terms like 'paradigm shift.' If anyone can envision a true shift, in the Kuhn meaning of the term, it's Engelbart -- He truly believes he can change the world. I think he's always been ahead of his time, so think of this as a sneak preview...

I believe that we are uncosciously honouring there brilliance, commitment and dedication everytime we use a computer today. That, I think is the greatest honour, a far greater honour than any award one can receive.

Here is a list of other great people who were honoured with the A. M. Turing award

This is plain paranoia. There's no way changes in the microcode could represent a security threat: it's DoS at worse. Something as low-level as microcode has no way of knowing what's going on inside the computer, or draw any useful information from what it sees, let alone communicate it outside.

In any case, loading the microcode, on the Pentium processors, can only take place in real mode (virtual 8086 mode won't do it). Linux runs in protected mode. (Of course, we only have Intel's word on the subject.)

You can also imagine a backdoored network card that occasionally sends a special ethernet frame containing a random page of your physical memory.

If you want to be that paranoid, you can also imagine that there's a back door in gcc. I suggest you read Ken Thompson's excellent Turing Award lecture on the subject, Reflections on Trusting Trust.

Actually there is plenty wrong with the Apple interface. Take a look at this article by Gentner and Nielsen called The Anti-Mac Interface. We just seem to be stuck in the WIMP paradigm...

The real cool thing about Linux is that everyone can experiment with the UI and perhaps discover something much better.

...richie

Well, everyone loves Knuth, but it seems to me that it is somewhat heartening that there is some award that he hasn't won.

Also, it would have been really ironic if he had won. Just check the list of people that have won the prize that is named after him. If you don't know who Lasy and Andy Yao are, well, I guess I'm not surprised, but they are both CS giants.

The Knuth Prize

I had to preview this 6 times before I got the html even close to right. Doh. Last day of classes. :)

Keiter and Rubin did some interesting work in this direction. Their idea is that instead of using specific remailer, users join a network called "crowd" and each client in effect becomes a mailer. When a message is received the user tosses a coin to decide between forwarding to another link or mailing out to the ultimate destination.

Based on the number of hosts colluding, the system offers varying degrees of anonymity. (Its all worked out mathematically, eg the probability that so-and-so is the originator of the message given the observed traffic.) You can find the paper here:

Crowds: anonymity for Web transactions

BluesPower

I mean, you can't say that all software patents are invalid because someone had already invented assembly language. Or that no mechanical devices can be patented because they all make use of the classical machines (lever, wheel, whatever, I forget, I'm a software guy).

raph's mention of Sprite seems to be getting close...the "main" system determines what and when the "remote" computers execute.
--

I had a long response citing Reflections on Trusting Trust, the Ken Thomson article in which he describes trojaning the C compiler to trojan the C compiler to trojan login.c. But it vanished before my eyes (Damn you Microsoft...or was it the NSA...) So I'll try to be more brief.

In short, I don't think we need to worry about the source code generated by Linus, Alan et al. or even the asm for that matter. Peer review is great at picking out back doors. One should worry about every binary you installed on your computer and every binary that touched those binaries. Not to mention all the hardware. To be safe, I think one would have to boot the computer by hand (your computer does have a front panel with toggle switched right?) toggle in a compiler that you completely understand, then use that to compile an open source compiler, then use that compiler to compile every piece of software on your system. Even then you'd be only sort of safe.
--

Since the FSF, Linus Torvalds and Alan Cox only distribute source code, and since tons of very smart people are studying that code in detail, their room to be sneaky is limited.

If I were the NSA, I wouldn't attempt to corrupt them. I'd get inside Red Hat and f*ck with the binaries they distribute. Who'd know? You may think that you can recompile from source and see if it matches the binaries, but what if they've messed with the compiler (along the lines of the famous Ken Thompson hack)?

[...] Ken Thompson's 1983 Turing Award lecture to the ACM admitted the existence of a back door in early Unix versions that may have qualified as the most fiendishly clever security hack of all time. In this scheme, the C compiler contained code that would recognize when the `login' command was being recompiled and insert some code recognizing a password chosen by Thompson, giving him entry to the system whether or not an account had been created for him.
Normally such a back door could be removed by removing it from the source code for the compiler and recompiling the compiler. But to recompile the compiler, you have to use the compiler -- so Thompson also arranged that the compiler would recognize when it was compiling a version of itself, and insert into the recompiled compiler the code to insert into the recompiled `login' the code to allow Thompson entry -- and, of course, the code to recognize itself and do the whole thing again the next time around! And having done this once, he was then able to recompile the compiler from the original sources; the hack perpetuated itself invisibly, leaving the back door in place and active but with no trace in the sources. [...]

A detailed description of the hack by Ken Thompson himself can be found here.

See http://www.acm.org/classics/sep95/for more details.

http://www.acm.org/usacm/trademark.html

Thanks for the excellent reference.

The closest thing to a Nobel in computer science is the Turing Award, given by the ACM.

For mathematics, the closest equivalent is the Fields medal.

Sorry, that was meant to be Jakob Nielsen's essays (specially The AntiMac Interface) and Neal Stephenson's In the Beginning was the Command Line far more enlightening..

I find Jakob highly overrated (but still far better than this interface hall of shame). I consider Stephenson's essay an absolute must-read.

Alejo

As a rule of thumb to start with, universities which have their Computer Science program under the same school or department as Engineering are preferable over ones which associate it with their Math department.

Make sure the Computer Science program you attend has a curriculum with sufficiently difficult classes in

• several programming languages
• algorithms and data structures
• operating systems
• advanced classes in your choice of several areas of empahsis:
  • systems design
  • databases
  • mathematics
  • business

I got my BSCS (1988) and MSCS (1991) at California State University, Chico. As a northern California native who does not come from a wealthy background, I had to focus on state schools in my search for a college to go to.

Fortunately, you can get a good education from a state university. But you have to check how well-funded the Computer Science program is and the quality of its curriculum. At least for the 23-campus CSU system, one university can be world class in a few majors and mediocre in everything else at the campus. California's UC system is better funded (and therefore better at more subjects per campus) but more expensive. What you want to know is whether they're good in Computer Science. Depending on where you live, some of these comparisons will hopefully be helpful in what to look for.

I was lucky that the nearest CSU campus (CSU Chico) to where I went to high school had a good curriculum and reputation in Computer Science, not to mention that their MSCS program is available via satellite across North America. And I run into CSU Chico grads all over the industry now.

True, the specific name of the person was changed, but, amusing as this is, it's still inappropriate. The job of a support staff member is to help users, not judge them.

See SAGE and Computer Professionals for Social Responsibility, and the ACM for more on this subject.

Besides the "party line", which I'm sure we'll hear plenty about, what's really going on? Why so sudden? Which of the following options have come to pass?

1) NSA can factor prime numbers?
2) NSA/FBI finally gave in after the finalists for AES (successor to DES which they can brute-force) were announced since they can crack them all (and PGP, and RSA, and elliptic curve)?
3) The U.S. military has become so heavily dependent on TCP/IP that they need a secure infrastructure throughout the Internet.
4) NSA has developed effective nano-mites which effectively render all encryption obsolete via a physical side-channel attack?
5) Intel's microprocessor dominance is now assured. And the NSA has inserted a microcode hook (can you say, "mask technician?") in all Intel processors (cf Ken Thompson, "A well installed microcode bug will be almost impossible to detect.")

Reply with your speculative other options. Remember "only the paranoid survive."

--LinuxParanoid

GCH is IMO one of the most influential articles, which brought programming out of the dark ages.

GCH was certainly influential: it's been argued over passionately for the last thirty years. Brought programming out of the dark ages? Possibly - but at the same time it caused schisms reminiscent of those in the medieval Catholic church.

Dijkstra was right to argue against the 'unbridled use' of GOTO, but his cause isn't helped by the almost universal inclusion of directives such as 'GOTO will not be used under any circumstances' in programming standards (and yes, I've seen some of these and argued with the writers about them). The argument is often that GOTO doesn't conform to 'structured programming', and hence can offer nothing to the modern programmer. In the spirit of the anonymous pundit who once quipped 'real programmers can write FORTRAN in any language', structured programming isn't concerned with specific language features. GOTO has its place, and anyone who tells you otherwise just hasn't cut enough code to know what he's talking about.

Sure, SEH is a good thing, but none of the boxes I've ever worked on have offered it in hardware: it's generally provided by either the OS or the programming language used. And quite a lot of real-world programming languages (rather than the My Favourite Toy Languages beloved of CS students, researchers and profs) don't support SEH: the same is true for most OSes. GOTO - or its equivalent (computed COME ... FROMs, anyone?) are present in just about every real language, and should be used when necessary, for fear of something worse happening.

The proof of correctness stuff, by the way, is one of these fields which I've been following off and on for a while - I just wish that they'd get on and prove something of (at least) interesting complexity. Last time I looked, the bleeding edge appeared to be tools and techniques for analysing programs of the complexity of a four-function calculator. Has the field progressed since?

Agree wholeheartedly about testing, by the way. It's always cheaper to spend time on the front of a project designing it correctly than on the backend patching the whole mess together with string and gaffer tape. Sadly management like to see their programmers programming, not staring into space, chatting or doodling on sheets of paper. Some time I'm going to write a manager obfuscator: you feed it various key words and tell it a language and it churns out several KLines of code which you can progressively show your PHB to demonstrate your productivity while you've been ... staring into space, chatting, doodling etc. And of course you won't have to work 80-hour weeks in the month before delivery 'cos it'll be designed properly and will run first time....
--
Cheers

Jon

I think this ethics code, if widely followed, would help address many of the privacy and reliability disasters the crop up on the web these days. I would feel much more comfortable at work if I knew coworkers had this code in mind. Wouldn't the non-techno savvy people who might work with your programs and systems be a little more trusting if you pointed them to this code and said "I'm sticking to it"?

Bob Minich - AC because he's lazy

1. GENERAL MORAL IMPERATIVES.

As an ACM member I will ....

1.1 Contribute to society and human well-being.
1.2 Avoid harm to others.
1.3 Be honest and trustworthy.
1.4 Be fair and take action not to discriminate.
1.5 Honor property rights including copyrights and patent.
1.6 Give proper credit for intellectual property.
1.7 Respect the privacy of others.
1.8 Honor confidentiality.

2. MORE SPECIFIC PROFESSIONAL RESPONSIBILITIES.

As an ACM computing professional I will ....

2.1 Strive to achieve the highest quality, effectiveness and dignity in both the process and products of professional work.
2.2 Acquire and maintain professional competence.
2.3 Know and respect existing laws pertaining to professional work.
2.4 Accept and provide appropriate professional review.
2.5 Give comprehensive and thorough evaluations of computer systems and their impacts, including analysis of possible risks.
2.6 Honor contracts, agreements, and assigned responsibilities.
2.7 Improve public understanding of computing and its consequences.
2.8 Access computing and communication resources only when authorized to do so.

3. ORGANIZATIONAL LEADERSHIP IMPERATIVES.

As an ACM member and an organizational leader, I will ....

3.1 Articulate social responsibilities of members of an organizational unit and encourage full acceptance of those responsibilities.
3.2 Manage personnel and resources to design and build information systems that enhance the quality of working life.
3.3 Acknowledge and support proper and authorized uses of an organization's computing and communication resources.
3.4 Ensure that users and those who will be affected by a system have their needs clearly articulated during the assessment and design of requirements; later the system must be validated to meet requirements.
3.5 Articulate and support policies that protect the dignity of users and others affected by a computing system.
3.6 Create opportunities for members of the organization to learn the principles and limitations of computer systems.

4. COMPLIANCE WITH THE CODE.

As an ACM member I will ....

4.1 Uphold and promote the principles of this Code.
4.2 Treat violations of this code as inconsistent with membership in the ACM.

It was called a "Reflections on Trusting Trust" and is available here. Very interesting, and scary, if you think that having the source code automatically makes the system more secure.

the only problem is the industry at large ignores them, and it's unlikely that anything short of legislative intervention will change that...

the only problem is the industry at large ignores them, and it's unlikely that anything short of legislative intervention will change that...

But the Mac interface severely limits the power user.

Check out the research article at
http://www.acm.org/cacm/AUG96/antimac.htm .

What version of Windows is mindslip using? I've always found Mac OS applications to be a thousand times more consistent than Windows applications. Maybe he's just talking about MS Office, though, which apparently will be part of Windows soon enough.

And Microsoft spending money on usability and human interface testing? Puh-leaze! Apple wrote human interface guidelines back in the mid-80s before Windows even existed. Microsoft simply copied the Mac's GUI, and did a poor job of it at that. Windows 95 and 98 were much better than 3.1 (and even added a few features that Mac users envied and eventually copied), but 'consistent interface' are not words I'd use to describe any version Windows or its various applications.

More research needs to be done for human interface guidelines and usability in general, though. Neither X nor Mac OS nor Windows is anywhere close to the ultimate GUI.

See Jakob Nielsen's book, Coordinating User Interfaces for Consistency and his Alertbox column for May 1997 titled "Web Design vs. GUI Design" for more talk about user interface design. The Anti-Mac paper is also interesting reading.

The technology exists to spy on anyone anytime: churning the technological arms race won't help us. Any lock can be broken by a determined attacker. We need to practice social engineering and forge societies where spying is impossible. Look for solutions that lead to fewer secrets rather than more secrets and remove the necessity for complicated technological locks.

For example: Openly install monitoring tools on all police hardware with a 3 month delay before it goes public. So maybe they will be spying on us, but at least we can find out exactly what abuses they are doing. (The three month delay is to give them some time to prosecute their cases.) -ccm

At this point, it's up to the 50 states to individually ratify the UCITA into state law. So write your state legislator. Snail-mail counts most, short letters with useful arguments are easier for staffers to handle. Basically, (I think) you want to have 'em amend or strike UCC Article 2B. The remote-deactivation provisions will be the most odious and easiest to fight. You can even cite the fact that it will be bad for the commercial software indistry 'cos it'll pressure s/w-dependent businesses to switch to free and homegrown s/w just so they don't have to fear pissing off their s/w vendor.

To find your state legislator: Project Vote-Smart or the Democracy Network.

At this point, it's up to the 50 states to individually ratify the UCITA into state law. So write your state legislator. Snail-mail counts most, short letters with useful arguments are easier for staffers to handle. Basically, (I think) you want to have 'em amend or strike UCC Article 2B. The remote-deactivation provisions will be the most odious and easiest to fight. You can even cite the fact that it will be bad for the commercial software indistry 'cos it'll pressure s/w-dependent businesses to switch to free and homegrown s/w just so they don't have to fear pissing off their s/w vendor.

To find your state legislator: Project Vote-Smart or the Democracy Network.

Us SysAdmin types already have a trade organization in the form of SAGE, the System Administrators Guild, a part of USENIX. I think forming a SAGE lobbying group and/or PAC (political action commitee) would be one way to go. Of course we need a good portion of the SysAdmins out there to join and support us... It probably wouldn't hurt to have IEEE and ACM start PACs representing their members as well. I'm just surprised that all of these trade organizations were ignored by Katz *and* the Slashdot readership. I only saw one post mention the ACM! Wow.

Speaking of which, I'm about to use a nicely refined 26-year-old technology to file this column. You may have heard of it. It's called Ethernet.

You might find Metcalfe's original paper describing Ethernet interesting if you haven't read it. The thing that strikes me after reading it again are its similarities to Linux and its design. It was based on known technology, Aloha radio networks. It was designed to run on inexpensive hardware. And it achieved its reliability from its simplicity. In other words, the same recipe used by nearly every succesfull open source project today, which makes Metcalfe's last column all the more confusing.

I *highly* recommend the article "Inventing the Lisa User Interface" by Rod Perkins, Dan Smith Keller and Frank Ludolph. It was supposed to be published a long time ago but it was held back because of the then Apple vs. MS look-and-feel lawsuit. The article appears in ACM "interactions..." Jan/Feb 1997 p40-53. It includes screenshots of the early UI designs and a timeline. It talks about influence of the PARC visit and the influence an IBM technical disclosure called PictureWorld had on the final Apple Desktop Interface. I remember seeing an earlier draft is on-line someplace.

CLIs are, linguistically speaking, a more powerful way to interact with a computer compared to user interfaces built using the menus and pointer model. Here is a reference to a CACM article that discusses the shortcomings of the WIMP (windows, menus, icons, pointers) interface.

http://www.acm.org/cacm/AUG96/antimac.htm

An excerpt:

...
The Central Role of Language

Over the past million years, humans have evolved language as our major communication mode. Language lets us refer to things not immediately present, reason about potential actions, and use conditionals and other concepts not available with a see-and-point interface. Another important property of language missing in graphical interfaces is the ability to encapsulate complex groups of objects or actions and refer to them with a single name.
...

The point-and-click interaction that most GUIs offer may be initially easier to use, but to claim this kind of interface as more 'advanced' is misleading.

Women have been leaving CS at a faster rate than men. According to the ACM, the percentage of CS bachelor's degrees going to women dropped from 37.1% in 1984 to 28.4% in 1995. For more information, see The Incredible Shrinking Pipeline by Tracy Camp.

A cursory review of the latest NSF data suggests that the percentage of bachelor's degrees in engineering going to women has been holding relatively steady. (According to the NSF, CS is a mathematical science, not an engineering field.)

I teach computer science at Mills College, the first women's college to offer a computer science major. I've also written far too much on this subject.

Go read it now if you never have. <Pournelle>Recommended</Pournelle>.

Lewis Mettler is incensed in his ZDnet talkback article that the security flaw he "brought up" isn't raising SlashDot headlines around the planet. The very foundations of OpenSource aren't sinking in FUD. It comes as quite a shock to him that "almost all Linux supporters just resort to personal insults rather than address the issue."

So, why is this? Lewis's original article does raise some good points, but not new ones by any standards [1]. And his dismissal of the relevance of the problem of trust to closed-source (binary) programs is ill-founded given the ease with which an experienced person can hack binaries. Or, for that matter, replace a closed-source binary with a newly compiled open-source one.

But by far the worst problem Lewis is having with his argument is his failure to realise he is stating the obvious. Or at the very least the well known. No one with computer security knowledge can be bothered arguing, so all he's hearing from are the me-toos and ACs.

Lewis, you'll raise headlines and win the attention of serious UNIX administrators when you tell us something we don't know. And hey, you've finally got your airtime on SlashDot anyway.


[1] See "Reflections on Trusting Trust", by Ken Thompson.
Communications of the ACM, Volume 27, Number 8, August 1984.
Online at http://www.acm.org/classics/sep95/
[2] ObPersonalAbuse: bgcolor="#99FF99" really sucks.

I can see why he is getting flamed so nicely.

Has he not read Ken Thompson's Reflections on Trusting Trust , from 1984?

On section 1.2.33:
Authority should be created for the AFP, the NCA and ASIO to alter proprietary software
so that it performs additional functions to those specified by the manufacturer. Such an
authority, which clearly should be subject to warranting provisions, would, for example,
enable passive access to a computer work station of a LAN ...

They want to hide trojan horses like BO in proprietary software!
Guess what they think of Open Source...
BTW it's a good time to read Reflections on Trusting Trust By Ken Thompson
Be paranoid

Ken Thompson's paper is here

SteveM

perhaps you mean
this.

For more stuff, try
this.