Slashdot Mirror

One alternative is Ken Perlin's QuikWriting, which has been discussed on slashdot and covered by Wired.

"Quikwriting is significantly faster and less stressful to use than Graffiti, and lets you write very quickly without ever picking your stylus up off the surface, although it has the disadvantage that you need to learn a special alphabet. For further info, you can preview a Technote in either PDF or PostScript, which was published at the ACM UIST'98 conference."

Another alternative that builds on Perlin's QuikWriting work, is Francois Guimbretiere's and Terry Winograd's FlowMenus, published at UIST'00.

"We present a new kind of marking menu that was developed for use with a pen device on display surfaces such as large, high resolution, wall-mounted displays. It integrates capabilities of previously separate mechanisms such as marking menus and Quikwriting, and facilitates the entry of multiple commands. While using this menu, the pen never has to leave the active surface so that consecutive menu selections, data entry (text and parameters) and direct manipulation tasks can be integrated fluidly."

I'm currently designing and programming a user interface on the Palm for a remote control application. So I've implemented "Finger Pies", which are simply pie menus that you can use with your finger!

To paraphrase Ben Shneiderman: Finger Pies work well for implementing direct manipulation user interfaces on handheld personal touch screen devices, in which the application provides meaningful, engaging, tightly coupled feedback on the screen, in response to your gesture. By integrating immediate gratification over time, the user enjoys the satisfaction of direct engagement in an immersive experience, and achieves the cognitive resonance of continuous gratification. [My apologies to Ben for the tongue in cheek impression.]

Finger Pies are not meant to replace character input systems like Graffiti, but they are extremely useful and reliable for many applications of handheld input devices, because they're easy enough to use with your finger instead of a pen.

Finger pies are good for reliably selecting between two, four or eight options at a time (which can be nested as pop up submenus), and they're much more robust and resistant to noise than gesture recognition.

One problem with gesture recognition in general, is that it doesn't allow for "reselection" or in-flight refinement and error correction. That is, once you've made a mistake in a gesture, there's no way to change or cancel it, so you will often get characters that you don't mean, and you have to stop what you're doing and erase the mistake.

Pie menus allow you to cancel or change the selection at any time before you commit to the selection, so you can easily browse the menus. So pie menus are most appropriate when there aren't too many items, the items don't change dynamically over time, and when you need to minimize the error rate and selection time.

Most gesture recognition systems are not "self revealing" like pie menus, which can pop up a "map" showing the directions. So pie menus are much easier to learn than gesture recognition, and more appropriate for novice users. Best of all, they naturally train users to "mouse ahead" and select without looking, so they have a smooth, gentle learning curve.

Another advantage of pie menus is that they're not patented or restricted, and there are several freely available open source implementations.

-Don

Penny Lane: "This song was written about the roundabout in liverpool where John and Paul grew up. Half of the song is fact, half is fiction, but most of it is nostalgia. John was starting to write about personal places, and Paul really took this one and ran. "I wrote that the barber had photographs of every head he'd had the pleasure of knowing. Actually, he just had photos of different hair styles. But all the people do stop and say hello." say Paul. Also, "finger pie" is actually an old obscenity in Liverpool. The girls would never thnk of saying the word. It was used in the song as a fun joke for the lads back home. Months after, waitresses in Liverpool had to put up with lads asking for "fish and finger pie." There is also a phallic reference to the "fireman who keeps his fire engine clean." Penny Lane has become a Beatles landmark, and like Blue Jay Way, has it's problems with stolen signs, which are now nicely bolted down. Penny Lane was recorded on December 29, 1966 and released as a single with Strawberry Fields.The song also has a promotional video." -http://members.aol.com/Sumacca/songs.html

One alternative is Ken Perlin's QuikWriting, which has been discussed on slashdot and covered by Wired.

"Quikwriting is significantly faster and less stressful to use than Graffiti, and lets you write very quickly without ever picking your stylus up off the surface, although it has the disadvantage that you need to learn a special alphabet. For further info, you can preview a Technote in either PDF or PostScript, which was published at the ACM UIST'98 conference."

Another alternative that builds on Perlin's QuikWriting work, is Francois Guimbretiere's and Terry Winograd's FlowMenus, published at UIST'00.

"We present a new kind of marking menu that was developed for use with a pen device on display surfaces such as large, high resolution, wall-mounted displays. It integrates capabilities of previously separate mechanisms such as marking menus and Quikwriting, and facilitates the entry of multiple commands. While using this menu, the pen never has to leave the active surface so that consecutive menu selections, data entry (text and parameters) and direct manipulation tasks can be integrated fluidly."

I'm currently designing and programming a user interface on the Palm for a remote control application. So I've implemented "Finger Pies", which are simply pie menus that you can use with your finger!

To paraphrase Ben Shneiderman: Finger Pies work well for implementing direct manipulation user interfaces on handheld personal touch screen devices, in which the application provides meaningful, engaging, tightly coupled feedback on the screen, in response to your gesture. By integrating immediate gratification over time, the user enjoys the satisfaction of direct engagement in an immersive experience, and achieves the cognitive resonance of continuous gratification. [My apologies to Ben for the tongue in cheek impression.]

Finger Pies are not meant to replace character input systems like Graffiti, but they are extremely useful and reliable for many applications of handheld input devices, because they're easy enough to use with your finger instead of a pen.

Finger pies are good for reliably selecting between two, four or eight options at a time (which can be nested as pop up submenus), and they're much more robust and resistant to noise than gesture recognition.

One problem with gesture recognition in general, is that it doesn't allow for "reselection" or in-flight refinement and error correction. That is, once you've made a mistake in a gesture, there's no way to change or cancel it, so you will often get characters that you don't mean, and you have to stop what you're doing and erase the mistake.

Pie menus allow you to cancel or change the selection at any time before you commit to the selection, so you can easily browse the menus. So pie menus are most appropriate when there aren't too many items, the items don't change dynamically over time, and when you need to minimize the error rate and selection time.

Most gesture recognition systems are not "self revealing" like pie menus, which can pop up a "map" showing the directions. So pie menus are much easier to learn than gesture recognition, and more appropriate for novice users. Best of all, they naturally train users to "mouse ahead" and select without looking, so they have a smooth, gentle learning curve.

Another advantage of pie menus is that they're not patented or restricted, and there are several freely available open source implementations.

-Don

Penny Lane: "This song was written about the roundabout in liverpool where John and Paul grew up. Half of the song is fact, half is fiction, but most of it is nostalgia. John was starting to write about personal places, and Paul really took this one and ran. "I wrote that the barber had photographs of every head he'd had the pleasure of knowing. Actually, he just had photos of different hair styles. But all the people do stop and say hello." say Paul. Also, "finger pie" is actually an old obscenity in Liverpool. The girls would never thnk of saying the word. It was used in the song as a fun joke for the lads back home. Months after, waitresses in Liverpool had to put up with lads asking for "fish and finger pie." There is also a phallic reference to the "fireman who keeps his fire engine clean." Penny Lane has become a Beatles landmark, and like Blue Jay Way, has it's problems with stolen signs, which are now nicely bolted down. Penny Lane was recorded on December 29, 1966 and released as a single with Strawberry Fields.The song also has a promotional video." -http://members.aol.com/Sumacca/songs.html

A proper p2p network needs to scale to millions of nodes, provide consistent and spam-proof search capabilities, and have some notion of locality. That is, no operation should require a global broadcast, and downloads should be automatically directed to the closest available replica. Better yet, downloads should be interleaved from multiple nearby replicas.

Take everything that's good about FastTrack, Napster, CHORD, and CAN. Stir. Maybe then we'd have a p2p system worthy of our praise and our software.

--Patrick

Basically, he hacked the C compiler to allow a backdoor for him if it was compiling login. He also hacked the compiler to produce a hacked version of the compiler if it was recompiling itself.

If you want to see some of the work of the people cited in the article check out LifeStreams, Data Mountain, and The Task Gallery.

The real question is what task is it that the Desktop doesn't support. Is it finding files, managing files, starting applications, managing windows, etc... I guess if the article had talked more about the whole problem of "metaphors" then maybe I would agree that the Desktop as a metaphor is dead. The metaphor is useful insofar as it allows people to carry over skills from one domain to another. There are many aspects of the Desktop that do not have analogs in physical desktops - for example, menus (to use one from WIMP). This doesn't mean that menus aren't useful, just that people have to learn how they work rather than relying on skills they know from the physical desktop.

The argument in the article seems to be about managing files - the problem is that the Desktop is used for much more than that. That aside, I do think that current file systems usually force me to make up folders and filenames when that isn't really what I care about. I think I would often like to think about my files more in the way of LifeStreams.

I find it a bit absurd that the article implies that folders are an abstraction but stacked desktops are not.

If you want to see some of the work of the people cited in the article check out LifeStreams, Data Mountain, and The Task Gallery.

The real question is what task is it that the Desktop doesn't support. Is it finding files, managing files, starting applications, managing windows, etc... I guess if the article had talked more about the whole problem of "metaphors" then maybe I would agree that the Desktop as a metaphor is dead. The metaphor is useful insofar as it allows people to carry over skills from one domain to another. There are many aspects of the Desktop that do not have analogs in physical desktops - for example, menus (to use one from WIMP). This doesn't mean that menus aren't useful, just that people have to learn how they work rather than relying on skills they know from the physical desktop.

The argument in the article seems to be about managing files - the problem is that the Desktop is used for much more than that. That aside, I do think that current file systems usually force me to make up folders and filenames when that isn't really what I care about. I think I would often like to think about my files more in the way of LifeStreams.

I find it a bit absurd that the article implies that folders are an abstraction but stacked desktops are not.

That said, there are many excellent books about specific area's of computing and computation science in general. They would probably bore your father, or most people who arn't interested, to tears. Most of the good works on general computing arn't books, there articles and such. Acm classics probably has the best articles on the subject, but thats just my opinon, and you can't forget the jargon file. And not forget BOFH if he's had to do any support work. Anything much more specific than that, and you get into extreamly specific realms.

You can login as kt and get root.

The whole Internet depends on protocols that have built-in congestion responses that mimic those of TCP. Protocols that don't either starve TCP flows, or are starved by them. Protocols with no real congestion response at all rapidly destabilize Internet links by consuming all available resources. Digital Fountain originally targeted multicast media transfer. Congestion avoidance in multicast schemes is still an open research question. Does this protocol really scale?

Yes, their protocol uses TCP-friendly congestion control - read about it in their SIGCOMM paper.

Interested parties should read this article... Ken Thompson created one of the coolest back doors ever... Compile the compiler to introduce code that creates a login backdoor every time login is compiled, and code so that everytime the compiler itself is compiled, the hack goes into the binary... after one compile, the hack isnt in the source... "Reflections on Trusting Trust"

For those of you who don't know it, this stuff is based on some very serious research performed at the University of California in Berkeley (yes, the same place that spouted the famous BSD system) together with Digital Systems research center in Palo Alto. It was published at one of most well-renowned networking conferences, SIGCOMM, in 1998. Here is a link which provides not only the paper, but also slides from the presentation.

The digital fountain approach is not a way to transmit information without transmitting it as the brurb suggests. Rather, it is an ingenious way of using forward error correction (so-called erasure codes) and broadcast (or multicast for that matter) to distribute data to a large amount of receivers.

In short, each data packet includes enough reduntant information to allow a receiver that has lost a few packets to get back in sync after receiving a number of the broadcasted packets. This way, the sender does not need to do any retransmissions; losses are repaired by the new packets that is sent out.

One place where this kind of technique could be used would be when a new, large, software package such as KDE, GNOME, or the Linux kernel, is to be distributed to a large number of receivers. The sender would just send data in a fixed rate and the receivers would just have to "tune in" to the data stream. After some time, the whole package is received. No more spikes in bandwidth consumption and no more slashdot effects.

Reflections on Trusting Trust

Josh

As I understand it the Rear makes a lot of difference. It's like the rank distinction between a General and Four Star General. Admirals as far as I understand command bases and carrier groups. Rear Admirals tell them what to do with those bases and carrier groups.

She didn't actually win the Turing Award. They made the Grace Murray Hopper Award in 1971. On the whole I think I'd prefer having an award in my name too.

As I understand it the Rear makes a lot of difference. It's like the rank distinction between a General and Four Star General. Admirals as far as I understand command bases and carrier groups. Rear Admirals tell them what to do with those bases and carrier groups.

She didn't actually win the Turing Award. They made the Grace Murray Hopper Award in 1971. On the whole I think I'd prefer having an award in my name too.

The classic paper on this is Ken Thompson's Reflections on trusting trust

Ken Thompson wrote a paper a few years back that demonstrates that source code alone is insufficient to gaurantee security. Suppose that you have source code for the OS and all the various utilities and applications. You inspect the source code, then compile it, and you now feel pretty secure - yes? No, because, what about the tools used to compile the code? What Thompson demonstrated was a compiler, that a) looks for and hacks the Unix login code to add a back door and b) recognises and similarly compromises compilers that it builds! Here's a link to a subsequent article Thompson wrote for the ACM revisiting the issue.

Actually, what came before both of them, I imagine, was Apple's long-lost *other* Cocoa. Cocoa was a multimedia authoring environment for kids.

Yes, it did come first, but it's not lost! That project was spun off from Apple into the company Stagecast. Apple retained rights to the original name. Actually, the earlier name for the project was KidSim. The prime movers for KidSim were David Smith and Alan Cypher. Larry Tesler was Stagecast president. Both Smith and Tesler originally came from Xerox PARC.

That's not quite correct. BMRT was used in the creation of A Bug's Life (and other movies), but it was not the sole program for for creating and rendering. Here's my little odyssey searching for info on this :)

An abstract from a paper suggesting a connection between BMRT and Pixar's RenderMan standard:
BMRT: A Global Illumination Implementation of the RenderMan Standard

But then here is a disclaimer that BMRT is not associated with Pixar and is not a replacement for Renderman:

"BMRT uses some APIs that are very similar to those described in the published RenderMan Interface Specification. However, BMRT is not associated with Pixar, and no claims are made that BMRT is in any way a compatible replacement for RenderMan. Those who want a licensed implementaion of RenderMan should contact Pixar directly. Exluna.com Docs

But then got to the BMRT site, we find something which seems contradictory:

"BMRT is a ray tracer that we distribute free of charge. BMRT has been used in the production of several feature films, including A Bug's Life, Stuart Little, The Cell, Hollow Man, and Woman on Top."
BMRT FAQ

Finally, from the links section of the BMRT site:

"Pixar's RenderMan Toolkit (a.k.a. PhotoRealistic RenderMan, a.k.a. PRMan), now in release 3.9, is the oldest RenderMan implementation. PRMan has been used to render effects for ... Toy Story (Classic and II), A Bug's Life.

The Blue Moon Rendering Tools (BMRT) package ... has been used on several productions, including A Bug's Life"
Links on Compatible Renderers

Check out ACM's Software Engineering Code of Ethics. It seems like a good starting point, and can perhaps be incorporated in the GPL.

You couldn't be further from the truth. Someone's already mentioned CiteSeer. I've read and downloaded hundreds of papers from there. Google is great for tracking down papers, too.

Another nice resource is library.readscheme.org. It's Scheme-specific, but Scheme is the root of much research about programming languages and the underlying concepts - it pretty much spawned the field of functional programming.

The biggest barrier to entry for this sort of stuff is your own existing knowledge. There's no pill you can take to pick it all up overnight. You have to work hard at it. This is the real reason to go to a real universities - not to learn how to program in the language du jour, but to learn about what some very smart people have already figured out over decades, centuries, millenia, and to learn how to think like those people.

There aren't many shortcuts here. It doesn't help to be told that there's a simple solution to the problem you're working on, if it involves a network of deep concepts you've never heard of and are totally unfamiliar with. To take some examples from functional programming: closures, continuations, continuation passing style, fold operators, polymorphic type inference... If you don't know what all those things mean, and can't use them in your code, you're unnecessarily limiting yourself and denying yourself leverage that can help get big, complicated things done more quickly, with less fuss.

One way to start out is to learn some advanced languages. Scheme is a good starting point because there's so much tutorial literature for it. You can pick up the computer science concepts as you go along. Read Structure and Interpretation of Computer Programs (SICP) and How to Design Programs (HTDP). Join the ACM. There's so much stuff out there, go look for it, and apply yourself!

...richie

The Association for Computing Machinery withdrew its support for this SWEBOK effort, after deciding that their approach to licensing practioners was inappropriate. So this probably isn't going anywhere.

In comparison with other engineering disciplines, the real problem is that we don't have a good handle on how to build software with huge safety margins so that it doesn't need to be engineered.

This seems confusing, until you look at, say, structural engineering. If you want to build something, there are standard handbooks that will tell you how to build something that's much stronger than it really needs to be, but won't fall down. That's how most houses are designed. Only when you get into more complex construction (steelwork, arches, laminated wood beams, etc.) do you need a licensed professional engineer to sign off (literally) on the blueprints.

We don't explicitly make that distinction for software. With fifty years of computing behind us, it may be time to do that.

A good place to start would be control software for anything with more than some minimal amount of energy. (For example, programming a VCR control CPU wouldn't require certification, but a garage door opener control would.) We could then go on to, say, software that handles the money of others, and perhaps to networking software that can affect more than 100 users at a time.

A formal distinction of which software matters and which doesn't is the first step. The industry needs to take that step.

ACM's position is that our state of knowledge and practice in software engineering is too immature to warrant licensing. Moreover, Council felt licensing would be ineffective in providing assurances about software quality and reliability.

There was a reason that I wrote a book about Software Craftsmanship The whole idea of applying a mechanical metaphor to software development is inappropriate.

Sounds truly interesting. I suppose you don't have any links yet?

Sorry, no. The only thing that's close to release is a related framework component, STEnterprise (heh, let's see if we get sued for that name :-), which is intended to be a database independent object persistence layer (needed by some of the specialized managers in the MOM) intended to address the fact that Apple has mishandled EOF. That's due out at the end of the month, but it's not a major part of the STMOM framework, which is the core of Mary and MaryTool (the command line version).

Since there is growing interest in an updated user experience, I can provide a few links that I found inspirational in my work on Mary as a MOM.

• The Anti-Mac Interface got it right in 1996, but we didn't have the vast datastore on the desktop to make it worth it, or the processing power to make it happen.
• Liquid File System, insightful enough for me to say "screw it" to my own white paper and just implement the damn thing. :-)
• Placeless Documents, an excellent paper, as you might expect from Xerox PARC.
• SQLite, useful if you need to release software that would benefit from a database on a system that might not have one.
• Shore, which interestingly can have the object store accessible using directory navigation, addressing some migration issues.

There were a couple of interesting papers at the ACM's SIGIR this year that use only the anchot text that points to a webpage to get a description of the pointed to page and they could do some cool things like language translations with just that data.

Tim

As the commenter above notes, the now standard WIMP (windows, icons, menus, pointer) interface isn't necessarily the optimal way to interact with a computer; it's just what we've all learned to work with. And it's worth noting that even that interface took several iterations to get right, just as it does for a lot of MS software (IE, Office, Windows, etc all seemed to come of age with the 3.x versions, and start surpassing the competition that they copied with the 4.x & 5.x versions. They of course start bloating by the time they get to 5.x & 6.x, but that's a separate problem... :)

Computer hardware is now drastically more capable than it was when Bob came out, to the point that software developers are always looking for ways to fill up all those extra clock cycles -- anything from running Seti in the background to having hooks in the Windows interface that pause for a few hundred milliseconds before opening a menus so that "it feels like the computer is working harder" -- surely my least favorite part of the Windows interrface and the first thing I try to disable with TweakUI on any computer I'll be using regularly. The really "revolutionary" releases of the recent past -- Mac OSX and Win XP -- aren't really revolutionary at all, but glossier and more refined versions of what we've been using for well over a decade now -- and in the case of OSX at least, you could argue that the interface is a step backwards in terms of flexibility and usability, emphasizing style over substance at the UI level, even if the underpinnings are surely much more advanced than before. XP might also be guilty of this, but I haven't used it yet so I can't say; I do know that the dissolving menus that Win2k had were guilty of the same sort of cute wastefulness that OSX/Aqua's pervasive translucence & drop shadows represent...

Maybe it's time to consider abandoning the WIMP interface. Maybe the world is ready for Bob or something like Bob to give it another shot. Or is it? Bob tried to represent the computer 'space' as the interior of a home, and for a desktop computer of sufficient power (i.e. what most of us have now, but didn't have when Bob came out), this isn't so bad. But in a networked world? Can you achieve some sort of network transparency & represent it in that sort of metaphor? I dunno, maybe. I am sure that it's an interesting challenge, much more than ever more glossy iterations of the same old Mac & Win interfaces could ever be, as they both try to refine their implementations of the Macintosh Interface Guidelines ever further.

Maybe it's time to give the Anti-Mac Interface a try -- a system that inverts all the assumptions that we've been working with for years now.

Not only on mainframes, but on comtemporary platforms. For example, there are Linux implementations, and there have been commercial UNIX releases for many years now, as well as some other platforms. APL continues to be critical, not only in insurance, but also financial services, manufacturing, software prototyping, and all kinds of R&D.

Other APL vendors anticipate moving to Linux as they see the benefits; there are two commercial grade Linux APL systems, a free software project, and several related development efforts to continue the evolution of this outstanding, high-productivity language.

I would suggest that anyone interested in really making their time valuable in software development would benefit by taking a look at the APL community, our newsgroups, products, services, and facilities. We want to accelerate our path to growth again, and one way to do this is to show others what we can do.

Stop by some time, you'll be glad you did!

The ACM (Association for Computing Machinery) has held college-level programming competitions for many years. Though the actual problems may be at a level beyond what you are looking for, they have long ago solved the issues of how to hold such a contest.

Here is the 2001-2002 ACM International Collegiate Programming Contest page which lists, by region: a report, the standings, and the programming problems.

The basic format is to have a number of problems for the contestant teams to try and solve in a fixed amount of time. (The first one I checked out listed 8 problems for a 5-hour contest.) It included explicit problem specifications, sample input, and sample output for each problem.

I'm sure that by looking down the list, you'll find a baseline of informationt that will go well towards helping you to design your own competition. Good Luck!

The paper that started this Slashdot discussion is sort of silly, but it does reference a good empirical work in the CACM which finds that function point analysis works and most other methods don't.

Of course there are projects which have vague, always-changing requirements that even this wouldn't work.

The Eclipse Project got a lot of buzz at the last OOPSLA conference. A follow-on to IBM's VAJ, it's intended to be a programmer's workbench and include current tools like a refactoring browser, continuous integration. Too bad it seems slashdotted.

Plus, you need to build your own compiler, starting with hand-built machine code and bootstrapping your way up (see the classic C Compiler hack).

Of course, you then need to build your own processor to ensure there are no hacks in the processor too...

Summer 2000 I worked for a company that was testing some software from IBM based on their ViaVoice voice recognition software that would allow you to feed in an mpeg (video or audio) stream and the program would output a transcript of it. Honestly it was pretty bad at the time, but that was a long time ago and I don't have any idea what kind of progress has been made since then. It also had some other features like taking snapshots of the video and indexing them to the text and all sorts of cool stuff.

Ahh, here it is: It's called CueVideo and it's aimed at Multimedia indexing: http://www.almaden.ibm.com/cs/cuevideo/

---

Here's an almost unrelated article: http://www-4.ibm.com/software/speech/news/20000825 -iw.html

http://www.acm.org/sigs/sigmm/MM98/electronic_proc eedings/ponceleon/

The quote by Ken Thompson at the bottom of the article referenced in the Slashdot story is from a very interesting speech, Reflections on Trusting Trust.

Here is the quote:

"I have watched kids testifying before Congress. It is clear that they are completely unaware of the seriousness of their acts. There is obviously a cultural gap. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor's house. It should not matter that the neighbor's door is unlocked. The press must learn that misguided use of a computer is no more amazing than drunk driving of an automobile."


What should be the Response to Violence?

Incidentally, APL was invented by Kenneth Iverson, who never taught at Pomona. Perhaps you're thinking of somebody involved in APL's descendent, J. But neither language was the pet project of one prof.

http://www.acm.org/uist

I attended UIST 94 (in Marina del Rey), and a lot of the work was cutting edge (for that time, and some even for now!). Somebody did some presentation there that was similar to the visual pipe concept. I'll have to drag the proceedings out of storage, though...

What surprises me is that, while many of the arguments against crypto-strangulation are quite well stated and carefully ordered, they have given only peripheral awareness to the most glaring fact. Namely, that crypto is already, and will continue to be, free software. Also not to mention the fact that it's been available on the Internet (for free) for a long, long time. relatively speaking anyways.

The propogation and long-term storage realities of the internet simply make it impossible to un-ring this bell.

Again, the only way to win this fight, is for the good guys to learn crypto as well as the bad guys. This includes ALL of the "relatively unsophisticated users", that Spaff mentions, too.

In the ACMs, you get three people, four problems, four hours, and one computer.

I haven't done it yet (I'm a sophomore; its pretty difficult to get very far), but I know I will at least be going to prelims this year.

Maybe this is something profs should recommend for students that have a hard time integrating themselves. Don't force it like torture, but the competition aspect can make it pretty fun, and so non-team-oriented students might find it interesting and challenging.

A classic paper on the topic by Ken Thompson: Reflections on Trusting Trust

1. DMCA - 300 letters,
2. Health care privacy - 40,000
3. Home Schooling - 500,000+

Find your congressman and senators, write them letters, and mail them. Mail your own representatives. As a voter in their district you matter most to them. (Email is much less effective. They know about spam just like you do.) Whenever this issue moves into another stage (e.g., draft, committee, floor) write another.

If you want handbooks, check out Congressional Quarterly. The book Lobbying Congress, How the system works is quite relevant, although perhaps disturbing to some. It was written by lobbyists for lobbyists. You will also get other relevant hits with a "lobbying congress" query on Amazon.

As a CS senior at Concordia University Wisconsin, I feel that a well rounded, theory based approach to computing is important. Our major's curriculum is based off of the CS-0 model from the ACM/IEEE-CS. This stresses a wide approach to CS. The reason for learning theory in CS classes is that in the four years of my studies, the computing world has changed drastically, while the theory underlying it has not. A program that teaches logical thinking and problem solving, rather than programming at first has benifits: The CS student will learn how to solve problems through the use of CS rather than how to code a program in one specific language. In addition most 4 year programs stress on the job training through internships. Another important factor is personal motivation, a student should go beyond the classroom and apply that which he/she has learned and actually use it. ACM IEEE-CS Joint Task Force on Computing Curricula.

http://www.science.uva.nl/~mes/jargon/b/backdoor.h tml

back door: n. [common] A hole in the security of a system deliberately left in place by designers or maintainers. The motivation for such holes is not always sinister; some operating systems, for example, come out of the box with privileged accounts intended for use by field service technicians or the vendor's maintenance programmers. Syn. trap door; may also be called a `wormhole'. See also iron box, cracker, worm, logic bomb. Historically, back doors have often lurked in systems longer than anyone expected or planned, and a few have become widely known.
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.
The talk that suggested this truly moby hack was published as "Reflections on Trusting Trust", "Communications of the ACM 27", 8 (August 1984), pp. 761-763 (text available at http://www.acm.org/classics). Ken Thompson has since confirmed that this hack was implemented and that the Trojan Horse code did appear in the login binary of a Unix Support group machine. Ken says the crocked compiler was never distributed. Your editor has heard two separate reports that suggest that the crocked login did make it out of Bell Labs, notably to BBN, and that it enabled at least one late-night login across the network by someone using the login name `kt'.

I don't think that's a fatal flaw

Well, it is, assuming you're trying to make the kind of generalization that the original paper was trying to make. The original author took a randomly selected bunch of programmers who claimed to know either Java, C, or C++ and assigned them the task. In comparison, Mr. Gat's paper was based on a call to a bunch of dedicated LISPers. whose expertise one could reasonably expect to be much higher than someone who might have taken a LISP programming class N years ago.

You really can't compare the two papers. Either you get "experts" on both sides, or you get randomly chosen programmers on both sides, but not a mix.

Those aren't links, they're text with too much punctuation to be English sentences. Original and Description are links.

Quoted from the article:

"... For many years, programmers were taught that global variables and GOTO statements are poor programming practice. In some situations though, these constructs may be exactly what the software needs to marry form with function."

This poor guy has just ignored more than half a century worth of Computer Science developments in order to tell us to go back to the way of the GOTO, even for "some situations", because it has been proven mathematically by Dr. Edsger Dijkstra himself that every piece of code that can be done with GOTOs can also be done using if's, while's and their kin. (And it's more *koff*aesthetically pleasing*koff* that way, too, as opined by Dijkstra in his article)

IMHO, marrying form with function is what this whole evolution from spaghetti code to structured programming to object orientation (and especially object orientation) is all about.

And even more shameful is that NO ONE in the computer industry is willing to honor the man in a way where their name will be seen.

You're kidding, right? The greatest award which a Computer Scientist can receive (since there isn't a Nobel Prize for computer science) is the A.M. Turing Award. Take a look at the list of past winners and you'll see all the great names (since the 60s, anyway).

Are you sure you've read the code properly? Just because you don't agree with the executives of the society doesn't mean you can't argue against them. That what scientific debate is for, and from what I can tell having just checked, those executives haven't influenced the idea behind the code of ethics at all.

As it should be with any good society, the ACM does not dictate to its members. On the contrary, the members define the ACM and what it stands for. This isn't rhetoric, it's realtime definition generation and the ACM's code of ethics demonstrates it perfectly.

In the past couple of weeks I've been looking around for papers crossing ethics and databases for some postgraduate work I'm doing. The presence of papers in the ACM digital library was strangely vacuuous, but I did find one paper by Donn B. Parker titled Rules of Ethics in Information Processing. It was published in 1968 in the Communications of the ACM. You can see the abstract here, but you might need an ACM login for the abstract and probably a member to download the pdf.

When he wrote it, Donn Parker was the Secretary of the ACM as well as the Chairman of the ACM Professional Standards and Practices Committee. He was arguing in favour of the first ever edition of the ethical rules of conduct for ACM members that was adopted in 1966.

One of the major points of his argument was that it was important to have guidelines to effectively say that "members must be ethical". On the other hand, the guidelines were very cleverly written so as not to say what ethical was. Everything that mattered was left to the judgement of the member.

The idea was not to impose any specific rules on members, but to simply require them to use good judgement and common sense in what they consider ethical, and abide by it. If, on the other hand, a member did something that they clearly should have known was wrong and couldn't offer a reasonable argument against it, there would be grounds to have them thrown out of the society.

Even looking at it now though, I think it would be possible to argue that it's written in the same form. Consider section 1.5 where it says "Copies of software should be made only with proper authorization. Unauthorized duplication of materials must not be condoned."

Nowhere does it define what "proper authorization" actually is. This is left up to the member to decide, and it's feasible that under some circumstances someone might argue that proper authorization doesn't require consent of the copyright holder.

Section 2.3 specifically says "ACM members must obey existing local, state,province, national, and international laws unless there is a compelling ethical basis not to do so. Policies and procedures of the organizations in which one participates must also be obeyed. But compliance must be balanced with the recognition that sometimes existing laws and rules may be immoral or inappropriate and, therefore, must be challenged. Violation of a law or regulation may be ethical when that law or rule has inadequate moral basis or when it conflicts with another law judged to be more important. If one decides to violate a law or rule because it is viewed as unethical, or for any other reason, one must fully accept responsibility for one's actions and for the consequences."

This is a complete let-off by the ACM if you want to protest against the DMCA with civil disobedience. It's saying that you shouldn't drag other people (eg. employer) down with you unless they consent. But if you seriously disagree with the ethics of the law then go ahead and protest.

Whether it was in 1966 or 2001 and regardless of how many words there are, the ACM code of ethics has been very cleverly written. In so many words, it basically tells people to trust their common sense and don't do anything stupid. That's exactly what ethics are, and the ACM isn't telling you otherwise. I think you should consider rejoining.

(That code of conduct is, generally, in my opinion, excellent, and well worth reading and abiding by, to the extent it's possible.)

Unlike most any other industry, the computer industry is one in which research on the technology is often presented as the technology itself. In that sense, even well-established, free, "production" software like GNU Emacs, GCC, and the Linux kernel can be reasonably considered "research" as well -- they're distributed as source code, and everyone is encouraged to study it, learn from it, modify it, and distribute what they learn and/or their modifications.

Since the existence of software patents directly infringes peoples' individual rights to distribute research in that form (free source code), I found the ACM's requirements, as much as I agree with the basic ethical, moral, and practical basis for them (that is, it's generally ethical, moral, and practical to obey existing laws), to be too much for me in the case of software patents.

So, while I'm happy to see the ACM recognize the specific new threat, I wonder how they view software patents today, since software patents can easily render much practical research either infeasible (can't be distributed as free software without authors losing their houses and other property in court due to patent-infringement lawsuits) or illegal?

For example, without things like the DMCA, software patents can be used to prevent (or punish for) distributing things like DeCSS and other "IP-security" softwarez. (I used that term on purpose; "warez" denotes illegal software, it should perhaps also denote immoral, self-delusional, or tyrannical software as well. ;-)

True, ideally, software patents make an invention's nature plain enough for all (adequately schooled in the arts) to understand, and what the ACM's complaining about here is the "security-through-obscurity" approach presently used by certain companies enjoying an artificial, and ultimately too-fragile, legal fence built around it, known as the DMCA.

But, in practice, software patents are not used by typical programmers or computer-science researchers as a source of information on how stuff works; and, further, the lawyers who help write them up apparently try to make sure they are as inscrutable as possible (while still passing muster with the Patent and Trademark Office, or whatever it's called), so as to provide the least useful information, while carving out the most intellectual "property" possible.

So, even absent the DMCA, it seems to me that a much broader problem, including much of what the ACM is presently worried about, is posed by software patents, which too-often amount to inscrutable, unhelpful "explanations" of just what a person (or even a computer program) might, on its own, be doing, that is illegal, because the owner of the software patent a) says so and b) can afford expensive lawyers.

I guess what I'm asking is, given that the DMCA and software patents do exist:

• Does the ACM expect its members to abide by the legal restrictions of the DMCA, even if the result (not publishing weaknesses in a timely fashion) might be loss of property or even life of innocents?

• Similarly, does the ACM expect its members to strive to avoid infringing software patents, by:

  • not publishing software that even might infringe
  • not publishing research papers that describe patented properties, if it's fairly straightforward to convert any pseudocode or descriptions in the papers into software (in languages ranging from assembly code to Haskell, ML, Prolog, and so on)
  • spending so much time researching the constant stream of software patents which they might otherwise infringe that they have little or no time to actually research and publish computer technologies?

  And does it expect its members to do these things even if doing so prevents them finding and/or publishing security flaws, again, even if the result of withholding such information might include the loss of property or life?

• Beyond specifics such as the DMCA and software patents, does the ACM generally expect its members to abide by legal restrictions when the result of doing so could have severe moral repercussions, such as loss of life or property due to inadequate, or even hostile, computing technology being deployed by companies using "intellectual-property" law to protect such deployments against ACM members dutifully informing the public?

I think you meant Ken Thompson.

A search for "documentation security" on the HP site takes you to an interesting page - follow the hp-tlx link in the index for Administration Guide, Installation Guide and Release Notes.

The paper "An Operating System Approach to Securing e-Services" published in Communications of the ACM Feb 2001 is also of interest since it describes some of the features of the system.