Slashdot Mirror

No, I don't [know who Don Norman is]. I noticed some other books on his blog that looked interesting, but I'm writing based specifically on this article. Not on prior achievements.

Don Norman is a very well known cognitive scientist, and well known figure in the field of HCI. His book "The Design of Everyday Things" is probably on the reading list of every HCI course there is. For more details, check out wikipedia

In any case, it's a poorly thought-out article regardless of his intentions.

I do not share your view in this matter. Both linked articles of Don Norman have, imho, merrit.

Lets start with the one about Google:
The piece reads like Mr. Norman has heard people say "OMG!!!11!1! GOOGLE IS SO SIMPLE!!!1!!!!11!!eleven" so often, that he could not stand it anymore. Actually, he says so in the fifth sentence.

His point is not that the search engine part of google is hard to use. He admits that is very nice and clean and easy to use. His real point is this:that's because you can only do one thing from their home page: search.

My condensed version of that essay: "Simplicity" (meaning lack of features, or having hidden the features) and "Ease of Use" are not to be confused.

The second piece, his column from the upcomming <interactions> is more about the question if we really want "simple" products as much as we say we do. His verdict is that we rather talk about simple products than use them. Arguing that if you would build products as simple as possible, you might very well go out of business. Marketing in their featuritis might for once be correct. His punchline tells all Yes, we want simplicity, but we dont want to give up any of those cool features. Simplicity is highly overrated.

I personally think those two pieces of writing are very well argued. Read them again when you have cooled down a bit. ;-)

I agree with all of that. Joining a professional organization like The ACM or The IEEE and reading their journals is also a good place to get informed about some of the broader trends in the industry. This is not necessarily writing of code, but learning about the things that underly the code. Core ideas IMHO are much more important than code itself. When you reach a certain level the act of coding should become trivial, like picking up a book and reading it. Its the ideas behind the code that are interesting and what keeps us moving forward. I can't speak for IEEE personally, but I've been a member of ACM since my college days and have learned a lot from reading "Communications of the ACM".

You should read about the Y operator, or if you are an ACM member (why not, you have CS homework?), read Taming the Y Operator).

This fantastic new math is also helpful in solving this intractable problem: http://mcraefamily.com/MathHelp/JokeProofFactoring .htm

How cool is that?

Seriously, it's hard to take someone like this seriously when he uses ignorant scare tactics such as his autopilot example. Either he's performing self aggrandizing hand waving, or he really is completely ignorant about the real world. Trust me - we do account for division by zero in autopilot systems. And - believe it or not - not only does the computer not "stop working" but we actually get a result back. It's called NaN. Furthermore, not only are our systems built with robust libraries that allow us to carry on (no pun intended) we also write downstream code to mitigate propagation of these types of errors. [see Celarier, Sando for a good example of this].

An "original design goal of the language" for C was that the compiler had to fit in a PDP-11 with 64K. That's why the language is so close to PDP-11 hardware. (The "++" operator reflects a PDP-11 hardware feature.) It wasn't until the late 1980s that C compilers started to optimize significantly.

Once you have an optimizing compiler, the speed issues are quite different. The question is not how close the language is to the hardware; it's how well the compiler can understand the language. Issues like aliasing assume greater importance, because they interfere with optimization. Issues like whether you write *p++ or tab[i++] assume less importance, because the compiler will usually generate optimal code for both approaches.

Once subscript checks can be optimized, about 95% of them go away or are hoisted out of loops.

Subscript checking has a bad reputation because many existing implementations are terrible. The one in 1980s Berkeley Pascal was notoriously bad; it called a subroutine for every subscript check. A whole generation of programmers had their minds damaged by that. Some modern implementations do it by carrying around extra information with each array and pointer, which is similarly inefficient. It has to be done right, and in the compiler, to be efficient.

Worse, C and C++ don't carry around the information to do it right. Previous postings in this thread indicate how the problem could be solved.

Yep. Download pirated software (or any software) from an untrustworthy source and you deserve what you get. Heck, even trusted sources can distribute software with malware built in: http://www.acm.org/classics/sep95/ . And this goes for open source, too--I don't think many people bother to audit the code responsible for running their computer.

The only thing I'm curious about is what legit vendors, ie CompUSA, Circuit City, Dell, etc. will do or how their current practices will change. I've never bought a computer from one of those sources, but I do know they tend to bundle a bunch of junk with Windows such as AOL trials and other crap like that. Perhaps this will make that problem even worse, or maybe it won't change anything at all.

Also... electronic voting is a far more complex, so the number of people who would recognize something fishy going on shrinks dramatically.

As to "one programmer" have you read Ken Thompson's thoughts on trusting trust? Okay. So maybe it's got to be a *smart* programmer. One guy can certainly do it.

Start by making sure you understand the distinction between Computer Science and its related disciplines, and that this is a CS course. Read the overview report from the ACM Curricula Recommendations..

It is apparent from the ACM's recommendations (amongst others) that a lot of mathematics traditionally covered at universities(such as calculus) is not strongly related to Computer Science. That said, there are many applications of computing that require strong skills in these areas (scientific computing and cryptography for example) so they are not a bad option.

Important numerical and logical fundamentals that support the learning and use of undergraduate Computer Science include:

• Basic computing theory (formal grammars and finite automata). Understanding the qualities and use of state machines and formal grammars is essential in many fields of computer science including algorithm and protocol design, modeling robust systems, and creating parsers (e.g. for domain specific languages). It is also necessary to understand the halting problem and turing theory. Most of the theory requires the use of proof by induction or construction, which (in my experience) are the most common proof techniques in CS.
• First-order logic (predicate calculus). Also exceptionally valuable in the development of data structures and algorithms, and for communicating between domains.
• Graph theory. Understanding complexity, efficiency and optimisation in many aspects of CS (including compilers, algorithms, networks, data structures, etc) requires an understand of graph theory.
• Statistics. You will use it in most forms of analysis, at least to verify that a real-world realisation matches the predictions of a theory. Also valuable for performance analysis and optimisation to determine performance distribution and bounds.

To answer your questions about languages my opinion is as follows.

A student needs at least 4 semesters with C++. C++ is the mother language and if you learn it you can program in about any other language for the rest of your life.

A student needs at least two semesters in software architecture and requirements gathering.

A student needs at least 2 semesters of data structures.

A student needs at least 2 semesters of networking.

A student needs at least 2 semesters of operating systems.

A student needs at least 2 semesters in secure software coding (and integral with every other class)

A student needs at least 1 semester in structured scripting like bash, ksh, csh.

A student needs at least 1 semester of compiler theory.

A student needs at least 1 semester of language structure, grammars, syntax, etc...

A student needs at least math theory through discrete mathematics, and better yet through calculus.

These of course are just simple undergraduate courses and there is so much more that can be done beyond this.

I thought this would be of interest. I texted a friend of mine who works as a pole worker volunteer about the system used in Orange County California. The "OC" uses a paper audit trail system developed by Hart-Intercivic.

Here is what my friend had to say:

The current electronic voting machines consist of a Judge's Booth Controller (JBC) & a daisy chain of (usually) 8 electronic voting screens w/Voted Paper Audit Transaction Systems (VPATS). The JBC governs all of the screens, but is not connected to any VPATS, each of which is independent to its own voting screen. The entire system is completely self-contained -- it does not hook into any other computer system. It only hooks into the wall plug to give it power.

The first voter (a non-volunteering, random citizen who just happens to be first in line) signs the OPEN POLLS paper tape that verifies that no votes have been cast on the JBC for that election. Each voter is given a temporary access code that allows him/her to vote on an assigned electronic screen. The number is randomly assigned by the JBC volunteer & has no connection to the voter's identity. It expires as soon as the voter casts his/her ballot and/or a brief period of time elapses with no voting activity on the electronic screen. The voter enters his/her access code, then chooses his/her vote for each candidate/race on the electronic screen. When he/she is finished choosing, a review screen displays all of the choices & prints the same review on the attached VPAT, which the voter can see, but cannot touch (it is sealed inside the VPAT machine). When the voter verifies that this is his/her correctly voted ballot, the ballot is cast electronically & is reprinted on the VPAT (again, the voter can read it, but cannot access it).

No poll worker can access the VPATS (actually for the duration of the election & counting, neither can a ROV employee), nor can they change the electronic screen. If the voter makes a mistake, the entire ballot must be cancelled & the voter must start again. Once the voting day is finished, & the JBC prints out an additional summary of all the votes cast during the day at that polling place, everything is turned back into the ROV (through a system of manual labor all done by community volunteers, supervised by a ROV employee). The VPATS go to one location. The printed JBC summaries (beginning & ending) go to another location. The JBC goes to a third location. All votes are tallied (by a mixed group of employees & community volunteers) in each of the 3 locations, & compared. If there are discrepancies, the VPAT tally is generally preferred first, then the JBC printed summary, then the JBC electronic count. (There could be legitimate reasons to change the ranking, but I don't know what those are. They are printed out & available to the public.)

About absentee ballots (which I am using this time since we are working a polling place not near our own precinct) -- once they reach the Registrar of Voter's (ROV) office, the unopened envelope is recorded so that you cannot vote again by showing up at the polls, & then it is transferred to a completely different office before it is ever opened. The different office has no access to the list of registered voters. There the envelope is opened & the ballot is taken out & separated from the envelope. All the envelopes are isolated elsewhere, the ballots are bundled together & transferred to a different office, where they are counted by non-employee community citizen volunteers like me.

I am still undecided if the safeguards are sufficient, but this sounds pretty good. The "OC" is a Republican area, but the paper audit trail requirement reforms are due to requirements by the California Secretary of State, a Democrat.

Personally, I have no confidence in any system without the p

Maybe they could just ask to see the source code and audit it themselves, or just use software with the source code available. Its not as though they need to write it themselves, just be able to examine the source code. If they don't want to, well, they get what they deserve.

Having access to the source code is not a solution to this problem. Ken Thompson has demonstrated that in his paper Reflections on Trusting Trust twenty years ago.

To really fix the problem we need to leverage the one thing that all modern operating systems (including Windows) do right at the core level - access control. Why would anybody want to run a codec at the privilege level of the program that's using it? Why not run it under an account where it can't touch anything except its input and output streams? (This doesn't have anything to do with whether you are logged in as admin/root. Even if you are not an admin you don't want the codec to upload your documents somewhere.)

A related issue is installation programs. We need to make these declarative instead of executable. As it is right now, you run installations as an admin/root, and give them the rein to do anything. God knows what goes on in those MSIs and makefiles. If these were declarative then setups would declare at the beginning what kind of access they need (simple installation, shared component installation, mucking with the system, codec, &c) and you would be able to make a finer grade decision on whether you want to let them run.

Dejan

If you have a reductionist approach, you should name it.

Secondly, there is definitely more to consider if you talk about intelligence, be it artificial or not.

Third, a set of reasons for the state (better the dynamics) of AI research that certainly still applies was given by Drew McDermott thirty years ago: "Artificial intelligence meets natural stupidity".

CC.

If you have a reductionist approach, you should name it.

Secondly, there is definitely more to consider if you talk about intelligence, be it artificial or not.

Third, a set of reasons for the state (better the dynamics) of AI research that certainly still applies was given by Drew McDermott thirty years ago: "Artificial intelligence meets natural stupidity".

CC.

Are we saying that purpose built computer Hardware/Software cannot be made unhackable?

The research paper InfiniteReality: a real-time graphics system provides some clues as to why.

It's more than just saying:

float framebuffer[1024][1280][4];

The engineers had to resolve the problems of increased video memory bandwidth requirements (512 bits or 64 bytes per pixel) at a 1280x1024 resolution at a consistent 60Hz, and use parallel processing techniques to eliminate major bottlenecks (4 geometry processors built from custom ASIC's, 80 image engines, and texture mapping hardware to support virtual 2048x2048 textures using clipmaps).

If it weren't for the fact that the current voting-machine companies are conspiracies(get several completely independent companies) machine voting would be much less corruptible than paper ballots--it's much easier to fake a ballot with only human-readable text on it than one with a cryptographic signature.

Read this and then tell me if you still believe that machine voting would be much less corruptible than paper ballots. Remember to include in your re-thinking that it may be easier to fake one paper ballot but it is surely harder to fake them in bulk.

--MarkusQ

> Maybe we need an "Association of Principled Technologists".

Seek and ye shall find

Professional tablets often come with mouse-like "pucks" and there were some attempts to use them for panning. A dedicated device for panning and zooming would contribute to greater ergonomy for professional artists, but for most users the mouse is the only option they have at hand.

Professional tablets often come with mouse-like "pucks" and there were some attempts to use them for panning. A dedicated device for panning and zooming would contribute to greater ergonomy for professional artists, but for most users the mouse is the only option they have at hand.

It's been discussed on Slashdot before, but what's your take on procedural graphics (PDF)? Did you use any strategy to thin the client application while managing the load on the CPU? Is this common in online game design where a client is involved?

Try changing one vote per precinct.

Diebold has been known to install uncertified software. Anyone here incapable of making an off-by-one error look like an accident?

Expect it more in proprietary code where the compiler to use is strictly controlled, thereby ensuring a consistent result while also providing headaches for anyone who tries to steal the code and run it in a compiler that produces a different result.

But then implementing the ideas in Reflections on Trusting Trust would be more effective, and wouldn't show up in a Google Code Search unless you knew specifically what to look for. (And if an employee has access to modify the company's compiler, that employee can hardcode job security for life.)

• Most of those toolbars are about search. Is finding things on the Internet still this hard?
  
• I've seen people with 4-5 toolbars installed and loving it. How do people deal with all that clutter, when people can be shown to improve with streamlined User Interfaces?
  
• A large amount of graphics design was put into 'cute.' The Bonzi Buddy 'thing' nonwithsanding, do people really think that kittens = cute implies kittens = harmless? Cute was invented by babies so we wouldn't throw them away on the first, second or third night-of-all-screaming followed by the endless stream of steaming stinky poo. Considering the massive carpet saturation a kitten can cause when denied litterbox access, when does cute not equal trying to harm you?
  
• Some of these were IM feature enhancers (smiley.com?) which begs the question, beyond Meebo, why is there such a draw for IM-features via your web browser? Do online forms suck so much they need :-) and ;-} and ;-P liberally scattered about? (Or do I just frequent the wrong forums?)
  

I'm no security expert, but I'm not convinced that such attacks are necessarily difficult for those who have the motivation to do so.

Every Unix sysadmin, programmer and maybe computer user would be advised to read "Reflections on Trusting Trust", the lecture given by Ken Thompson when accepting the 1983 Turing Award with Dennis Ritchie. These two together created the original C and Unix.

In his lecture, Ken demonstrates how (with the appropriate access) one can introduce multiple trojans into the compiler, so that every time either gcc or login are compiled a back door is compiled in. In another comment, I speculated on the possibility that the common practice of installing an autoconf-generated package, using the sequence "./configure; make; sudo make install" might make it possible for a carefully constructed autoconf build to take advantage of this root access to do evil; Dr. Thompson's lecture provides an excellent example of how this might be exploited.

The lesson is that social engineering can often provide the security breach necessary to become root, regardless of the system. Just as the only way to absolutely prevent network attacks is to disconnect, the only way to absolutely prevent local attacks is to never turn the machine on.

In my own experience, someone at the school I attended some years ago discovered he could print to the timesharing system's console terminal, and wrote a program that duplicated the output headers of the OS control program (called VULCAN). His program 'informed' the operator that it was erasing every program on the main hard drive, one after another: "deleting FORTRAN; deleting BASIC; deleting VULCAN; ..." The operator dove for the Big Red Switch, instantly cutting power. The entire computing facility was down for days as they had to repair hardware problems that resulted from the sudden loss of power and reconstruct the disk state from backups. This exploit didn't require root (admin) access, but he could easily have written a program that asked for confirmation from the operator and required entering the password.

I'm no security expert, but I'm not convinced that such attacks are necessarily difficult for those who have the motivation to do so.

Every Unix sysadmin, programmer and maybe computer user would be advised to read "Reflections on Trusting Trust", the lecture given by Ken Thompson when accepting the 1983 Turing Award with Dennis Ritchie. These two together created the original C and Unix.

In his lecture, Ken demonstrates how (with the appropriate access) one can introduce multiple trojans into the compiler, so that every time either gcc or login are compiled a back door is compiled in. In another comment, I speculated on the possibility that the common practice of installing an autoconf-generated package, using the sequence "./configure; make; sudo make install" might make it possible for a carefully constructed autoconf build to take advantage of this root access to do evil; Dr. Thompson's lecture provides an excellent example of how this might be exploited.

The lesson is that social engineering can often provide the security breach necessary to become root, regardless of the system. Just as the only way to absolutely prevent network attacks is to disconnect, the only way to absolutely prevent local attacks is to never turn the machine on.

In my own experience, someone at the school I attended some years ago discovered he could print to the timesharing system's console terminal, and wrote a program that duplicated the output headers of the OS control program (called VULCAN). His program 'informed' the operator that it was erasing every program on the main hard drive, one after another: "deleting FORTRAN; deleting BASIC; deleting VULCAN; ..." The operator dove for the Big Red Switch, instantly cutting power. The entire computing facility was down for days as they had to repair hardware problems that resulted from the sudden loss of power and reconstruct the disk state from backups. This exploit didn't require root (admin) access, but he could easily have written a program that asked for confirmation from the operator and required entering the password.

Of course I'm familiar with Maya's marking menus and Gordon Kurtenbach's work, which are based on the ideas from (and refer to) the paper, "An Empirical Comparison of Pie vs. Linear Menus", that we (Jack Callahan, Don Hopkins, Ben Shneiderman, Mark Weiser) published in 1988.

The first publication that described the basic idea of pie menus was "PIXIE: A New Approach to Graphical Man-Machine Communications"; by Wiseman, N. E., Lemke, H. U., and Hiles, J. O.; Proceedings of 1969 CAD Conference Southhampton, IEEE Conference Publication 51, p. 463. The basic idea was also described in "Principles of Interactive Computer Graphics, 2nd. edition"; by Newman, W. M. and Sproull, R. F.; McGraw-Hill, 1979, 1973. Both of those came out a long time before Maya/Alias/PowerAnimator.

In the mean time, I've developed pie menus for many different platforms, including X10 (uwm+forth), X11 (piewm, TCL/Tk), NeWS 1.0, 1.1 (Lite Toolkit), OpenWindows (TNT/Open Look), Multi Player SimCity (X11/TCL/Tk), The Sims (C++/DirectX), ActiveX/OLE (C++), Internet Explorer DHTML Behaviors (JavaScript/XML), Palm (C++/XML), Pocket PC (C++/Lua), SVG (JavaScript), and OpenLaszlo (JavaScript/XML). In my copious spare time I'm also working on developing pie menus for World of Warcraft (Lua/XML)!

-Don

Someone needs to write a new paper for the peer reviewed journals to counter this paper in light of the "Johnny can't code" factor.

I suppose they could title it "Lack of Go To Statement Considered Harmful"

Actually perl has a goto statement , so feel free use perl like a line programming language if you really want to.

If the voting machines were open but anonymizing each vote, everything would be fine and dandy. So the proper way is to fix the voting machines, not to open the voting process.

Not so. Unless I can verify that my vote was counted towards the person it was supposed to have counted towards, and you can do likewise, there is the potential for fraud. Even having the source to the voting machine code won't help us, as there are ways around that.

Geez, the stupidity. Sometimes one thinks you deserve the government you have.

You may want to refrain from saying things like that unless you are absolutely sure the point you're making wasn't disproved twenty years ago.

--MarkusQ

Rather than speculating wildly, why don't you perform a web search and check out some real-time raytracing demos? These run very slowly in DOSBox (1-3FPS), but some have windows executables that work quickly in WINE.

But when we get into presentation-quality raytraces (at least with Povray), my P4-2.4HT takes 3-4 minutes per frame.

I don't know that povray rendering time is necessarily a good indicator of the maximum performance of a real-time ray tracer. From Ray Tracing News:

The Saarbrucken folks presented their design for an RPU, a ray-tracing processing unit. It's not considerably different than today's GPUs, having just a bit more specialized hardware here and there. Interesting stat: their *software* ray tracer is about 30x faster than the freely-available POVRay ray tracer. Now, I could probably speed POVRay up by 2x by some tuning of this and that, but 30x is pretty incredible. More on this topic later in this issue.

Not that I'm disparaging povray; it has many interesting features and a wonderful programmer-friendly scene description language. However, I don't think rendering speed is necessarily its strong point.

When CareerBuilder and Monster fail to help me find a job in my home town that uses my degree, I become frustrated. ... What am I missing?

So I guess the moral is "only run open-source software."

That might help, but it's not a complete solution, as anyone who has read Ken Thompson's Reflections on Trusting Trust knows.

It's open source. We'll just change what's inside the gifts from Greeks so it won't be dangerous.

Of course, that's only if you *notice* that it looks dangerous. Even Open Source can contain some subtle things that appear innocuous. See the classic "Reflections on Trusting Trust" -- great little read.

Keep dreaming. OSS doesn't solve all your problems.

Some Crackers have been doing this for a while, (we are way behind) look within your disk formats and OpenFirmware/Mac, Bios/PC, crack once - stay forever.
Time to start really paying attention, look for "bad boot blocks" for pre boot networking prefs.

This guy's got a clue:

http://www.securityfocus.com/columnists/402

Check the comments too.
Think about an intentional miconfig of your monitor settings (UNIX) now.

Required reading:
Reflections on Trusting Trust
Ken Thompson

http://www.acm.org/classics/sep95/

You'd have to provide cites for GC being "often faster". I really can't see how scanning the stack and globals for pointers that might either point to an entity or, worse, to the interior of an entity can be fast.

The only quantitative study I know of is this one, which finds that performance of GC is equivalent to manual memory management where sufficient memory is available, but can become much slower where memory is constrained.

However, the results are likely very much dependent on the specific programming style. It may be that GC can be faster if the code is designed differently.

I spend my days working with code that does lots and lots of pointer math

Then you don't want GC. GC and pointer arithmetic are fundamentally incompatible, since most GC strategies rely on being able to move objects in memory. However, if you're doing that kind of thing, then you're working on very low-level code. Where GC wins is with high-level code, GUI applications and the like, where performance is less important than developer time.

Yup. Read up on Ken Thompson's Reflections on Trusting Trust.

I don't know about other folk, but I subscribe to these:

http://www.acm.org/constitution/code.html
http://www.sage.org/ethics.mm

Ask your IT colleagues if they've heard of them.

I believe he talked about how it could be done, not an admission that he had actually done it (at least not in any form other than proof-of-concept).

http://www.acm.org/classics/sep95/

Man! How long did it take evolution to figure that one out?

What time is it?

(Did you meant figure out how to do it, or figure out how it does it?)

I'm anticipating the time when we realize that life and evolution is an example of Reflections on Trusting Trust and thus that the origin of some aspects of DNA and life may be unknowable, and yet explicable, and thus not be of divine origin.

http://delivery.acm.org/10.1145/810000/803691/p303 -mclean.pdf?key1=803691&key2=8402792511&coll=porta l&dl=ACM&CFID=15151515&CFTOKEN=6184618 Write it right the first time you're in good shape. If you didn't write it right, it's probobly faster to throw it away and start over anyway.

This battle has been fought and lost. The term 'cracker' was a belated attempt to create a good witch/bad witch distinction after the press took a dim view of hacking, but it is totally artificial. To take but one example, Ken Thompson's seminal Reflections on Trusting Trust, spends some time moralizing (his word) about the 414 and Dalton gangs, saying "The acts performed by these kids are vandalism at best and probably trespass and theft at worst. It is only the inadequacy of the criminal code that saves the hackers from very serious prosecution." This is from the mid-80s, when breaking and entering was clearly described as hacking by one of the giants of the field. Hacking historically covered all forms of unapproved exploration of computer systems; in a more halcyon time, the gray area was wide, and the black area was not too black. Times have changed, but the fact that some hacking is now explicitly criminal, as Thompson predicted, does not make it not hacking.

The solution for OSS is simple. Any OSS software that goes into a Command and Control system needs to have it's source code audited by an independent authority.

Unfortunately, it's not as simple as auditing the source code. You also need to have complete control over the compiler, as implemented in machine code. For example, see Ken Thompson's comments on how to imbed self-replicating code into a compiler so that every program has a back door.

... you cannot predict in front how much time you need as you don't know the problems you will encounter ...

This is by some called 2OI, second order of ignorance. The following is a short extract from my master thesis.

One particular interesting article about software development is The Laws of Software Process by Phillip G. Armour which has a telling observation:

In some circles, software process is considered to be the issue that needs to be resolved to fix "the software crisis". Improving process has become an article of faith in some corners, while avoiding it has assumed the status of guerrilla warfare in others.

The author states that "Perhaps our problem isn't process, it's what we are asking process to do, and when and where we apply it." He then formulates three laws of software process based on what he defines as "The Five Orders of Ignorance":
0OI - Lack of Ignorance. You know something.
1OI - Lack of Knowledge. You know that you do not know something.
2OI - Lack of Awareness. You do not know that you do not know something.
3OI - Lack of Process. You have no method of converting 2OI into either 1OI or 0OI.
4OI - Meta Ignorance. You do not know about the Five Orders of Ignorance.

0th Order Ignorance, 0OI, represents when you have the answer and 1OI represents that you have a well defined question that can be answered. For these two levels detailed, well defined processes work well. On the other hand, for 2OI a detailed process, based on some pre-existing knowledge which might or might not be relevant, does not make sense. The different levels of ignorance must therefore be handled differently.

The challenge is all projects have different quantities of 0OI, 1OI, 2OI, and even 3OI, and therefore require different types of processes.

An alternative source should be "Armour, P.G. The five orders of ignorance. Commun. ACM 43, 10 (Oct. 2000), 17-20."

Apple is different from MS in a somewhat larger way though, they don't have the same resources and so they probably generate a lot less code. They also have to please Steve and rather than adding feature after feature which has kind of been the MS way, they've taken a much more simple route. Less code is less bugs. More features probably does mean more bugs but I'm not sure I've seen that really established as a general truth anywhere.

This is a big issue. Apple has a few hundred programmers total. Microsoft has thousands of programmers just working on Windows and its core technologies (like DirectX). Smaller teams with more limited scopes just plain result in better code.

There is a good ACM article talking about this here.

While I don't know if we ever applied for a patent on the idea, I would bet that there is a lot of prior art out there... I just hope that Red Hat's lawyers are good enough to find it and use it appropriately.

Easy. Dozens, if not hundreds, of published examples should be here. I didn't even bother to log in and search, because it's an area of interest of mine, and I know I've read lots of research articles about it, going back well into the 90's and I believe probably even to the late 80's. The patent system makes it hard for defendents, but it seems to me that invalidating this turkey will be as close to a slam-dunk case as one can get. Especially now that the Supreme Court has ruled that patent holders are not entitled to automatic injunctions against distribution of infringing products ;-)

The fundamental question of systems administration: once you have had a root compromise, what can you do to the machine to get it back up and running, in a known good configuration, with all chances of future compromise as a result of the initial compromise removed?

Answer: either compare the system (booted from known good media) to a known good set of files, or reinstall from known good media.

There's no other answer. Any tools you run on the compromised system are by definition suspect; they might be good, or they might be compromised. You have no way of knowing; anything they tell you is suspect. Even if you have tool binaries that you know are good, you don't know that the data they're gathering reflects reality or has been altered to give you a wrong impression.

So the fact that this software is undetectable doesn't really change anything; you're still finding out about the compromise through unusual activity, so that's 'status quo'. The only thing that's different is the layer that's compromised.

The interesting question is how the software gets in place in the first instance to compromise the system. The answer is that it was run as root (or administrator, or supervisor, or whatever the super-user is called). How did it get root privileges? Two possible answers: (1) a flaw in the OS (defined as the kernel, and any processes running with root privileges); or (2) the end user ran it somehow as root.

In the first case, it's the standard security problem. The OS is flawed; anything can get root. That's a bug. In the second case, it's end user stupidity. Nothing you run as an end user should require root privileges. (If the OS is designed in such a way that you do, again, that's a flaw in the OS. If the application expects it when it doesn't really need it, that's a bug in the application, and the vendor should be shot.)

So there's another layer the rootkit can hide in. Be still, my beating heart! This is, and remains, nothing fundamentally new.

There was a paper at Webmedia 2005 describing a system -- deployed in early 2005 -- used for real-time audio finger printing that does the same, AFAIK.

http://doi.acm.org/10.1145/1114223.1114238
This paper describes a scalable real-time audio fingerprinting system developed by IBOPE Midia for radio and TV broadcast monitoring. A special temporal feature extraction strategy based on the Short-Time Fourier Transform has been designed. When given an input stream to analyse, the system matches it against the database and automatically recognizes instances of the previously registered samples within the input stream. The algorithm exploits the temporal evolution of the signal frequency spectrum in order to identify patterns and produce the final classification. The database is clusterized in order to provide an efficient and scalable search strategy. The system has been assessed using a database containing 393 distinct commercials. A 41-hour audio stream from three different TV channels has been analysed in less than 3 hours, attaining a 95.4% recognition rate.