Slashdot Mirror

I think that was over everyone's head.

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

The kindergarden theory of paint mixing is a vast oversimplification of the actual process that takes place. Most paints can both absorb and scatter light. Several purely scattering pigments mixed together should act as you say, by more or less averaging the colors involved. Bright paints like titanium white or cadmium yellow are examples of paints with very high scattering. On the other hand the darker paints like lamp black and prussian blue, have more more absorption than scattering, and consequently they act more subtractive.

There's a more accurate theory that explains the mixing of pigmented materials, known as Kubelka-Munk theory. Hasse presents a good intro to it in this paper

Windows XP my ass. They should rename it the ACME Operating System.

Does someone else have these visions of a penguin emerging from a hole and asking "Hey, what's up, Steve" to a round-headed, baby-faced bald guy with murderous intents?

You know that your C compiler might well be infected to compile some spyware and backdoors into itself and applications it compiles?

If that were the case, nearly everyone that touches the voting system would have to be in on the corruption. With the current system of outsourcing, it would take cooperation between gvt employees of both parties, as well as a private entity in a conspiracy that would have to be hundreds of people to pull that off

Actually, it would only require one corrupt person with technical expertise, and for the rest of those hundreds of people to not have the expertise to catch what they've done. Think that's impossible?

And, as I said, I've thought of other simple ways to do the same thing. I've proven the impossible can be done. All that means to me is that the people that claim it is impossible are quite incompetent. Thus, all the people currently implementing electronic voting are incompetent, as are all the people against it. Since that's just about everyone, I'm really depressed. Absolutely everyone involved in the voting system is incompetent. And they wonder why voter apathy keeps increasing.

Actually, there is a fatal flaw in your system: you should never, ever give a reciept to the voter that can be used to verify their vote. It's called "coersion".

Say someone offers them money to vote a certain way, or maybe threatens harm to them or their family. This sort of coersion is only viable when a person can be linked to a particular vote, like for example with the reciept you propose.

Hardcopy of the voting record is good, even necessary in my opinion, but it should NEVER EVER EVER be given, or tracable, to the individual voter.

. . . is that the people leading the call for paper trails or even just paper ballots are either computing professionals or extremely technically literate. It's an interesting situation when technological "progress" is opposed by the elite rather than the traditional Luddites or the masses.

Indeed. Sadly, it's only the computing professionals who seem to realise that using Open Source code on your voting machines achieves nothing.

Simply put, there's no guarantee that the Open code whose Source you're perusing is the same code that is being run on the voting machines on the day. Even if you log in and compile it yourself, how do you know to trust the compiler? The linker? The run-time loader?

Ken Thompson's paper from ACM '95 is as relevant today as it was when he wrote it.

This is why Voter Verified Paper Trails are so important. You need an indepdendent audit trail, verified by the voter when they're casting their vote, to ensure any glitches can be caught.

Irish ./ers should check out the ICTE site.

APL is the language that went out of the ASCII set to be able to be compressed farther. Here is a wiki article, Why APL and an extended code sample (slow .gif).

I read some articles about using standard GPUs for matrix and mathematical operations. Does anyone know if this is being coupled with clustering? Seems that this would give you some of the power of vector processors, but thats just my $0.02.

done, never released though. It sounded like it would have been very difficult to detect

The classic example (at least 10 years old) is to hack up gcc so that it examines the code it's compiling, and if it decides that it's compiling /bin/login to do things a little differently, inserting a back door where there was none before.

You're almost right. The hack you're referring to was done more than 20 years ago by Ken Thompson (of UNIX fame), and described in a seminal paper entitled Reflections On Trusting Trust. Actually, the hack was even cooler than you describe: not only could the complier recognize that it was compiling the login program and insert the backdoor, it could recognize that it was compiling the C compiler and insert the code to insert the backdoor. That's so cool it gives me a boner just thinking about it.

However, the compiler in question was not GCC; GCC was not released until 1987.

The auditors would have to audit every bit of the toolchain, the compiler and linker, and the rest of the system to be able successfully rely on the code audit.

Even that might be insufficient. Ken Thompson showed in his '95 Turing award speech how a compiler trojan can exist even if the backdoor is not present in the compiler's source code.

Here's the link.

For the compiler trojan, see the ACM article Reflections on Trusting Trust

Lists advantages & disadvantages of direct manipulation vs. natural language.

Compares menu selection, form fill-in, command language, natural language, and direct manipulation. Gives guidelines for using each, and for choosing which style based on task and user skill level.

Although the first focuses on natural language, many points apply to CLI, too.

Do you think you guys and the Apache guys could get together and implement pseudoserving? It would help us to greatly cut down on the slashdotting effects. P.S. The article is also available in the ACM Digital Library - get it there if you're a member, and spare my school's server the slashdotting.

No, it is not. We have to pick our problems carefully to avoid running into No-Free-Lunch, but there are problems that hillclimbing is better on, and there are problems that GAs are better on.

If you're interested in toy problems, consider the simple "deceptive" problems of David Goldberg. These tend to be difficult for hill climbers, as the derivatives for decomposable segments lead to local optima. With folded traps, for instance, there are many many local optima. Bad for hill climbers.

Hill climbers are a great first thing to try with real world hard problems. But if they fail, GAs are a good tool to try. The only problem is that there are a lot of variants currently, and some research is not generally applicable. The field is immature.

Simmulated annealing, on the other hand, is a much more mature tool. Also very respectable and very useful.

If I am not being trolled, all I can recommend is reading more or, better yet, hire someone that actually, genuinely knows what they're talking about. Jürgen Branke is a perfect example, he has a very impressive track record.

Association for Computing Machinery on Mentifex artificial intelligence

Ben Goertzel, Ph.D., on Mentifex artificial intelligence

Comprehensive Perl Archive Network: Mentifex AI mind.txt gameplan

eGovOS Open-Source Government Reference Book includes Mentifex AI

Free Software Donation Directory: Mentifex AI Project

Nanomagazine interviews Mentifex on independent AI scholarship

Redpaper archive of Mentifex documents on artificial intelligence

AI has been solved.

Agents Portal selling Mentifex AI4U textbook of artificial intelligence

GameDev.net selling Mentifex AI4U textbook of artificial intelligence

GreatMindsWorking selling Mentifex AI4U: Mind-1.1 Programmer's Manual

Given that, the only practical solution is to do the ultimate count on the basis of a voter-verified human-readable paper ballot, which no software can screw up.

We'll see how the SIGGRAPH committee likes it. From the description given in the previous slashdot article, it sounds like the images are basically generated by the same technique he presented in 1994. The main difference being he's upped the number of photons and done the computation in a distributed manner. That may be a nice piece of engineering work, but it takes a lot more than that to impress SIGGRAPH reviewers these days.

Actuall, I just did a search for this paper on ACM's digital library website and couldn't find this paper in the list of SIGGRAPH 1994 papers. Maybe I missed it, or maybe this was just a sketch or something. Can anyone find the original paper that was supposedly in SIGGRAPH?

The principle of information hiding has been known since long before VIN numbers were invented.

The sectioning was probably due to my choice of wording in the headline...

Encrpytion is computationally expensive and the average end user doesn't see the need for it

computationally expensive doesn't mean that the end user would notice. they hit send, the message sits in their "outbox" for a second while it is encrypted, then it's sent out. while it's sitting there, they user is free to go about their business.

not understanding the need for it is a different story. i think that's why the ACM publishes a Code of Ethics (see section 2.7)

Currently subscribe and read cover-to-cover:

• The Economist
• Harper's
• Flying
• Aviation Safety Letters
• SIGOPS Pubs

Read frequently:

• PHOTO (European Release (FRA)))
• Photo Techniques
• PDN (Photo District News)
• B&W
• View Camera
• AOPA Pilot

Only magazine I buy periodically is the Reader's Digest - usually at airports.

And yes, ACM CrossRoads too, though I find it has very little useful content nowadays - they need volunteers btw.

Taken from Reflections on Trusting Trust - Quoting Ken Thompson:

"Moral
The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."

Basically, the higher of a language you use, the less secure you can possibly be because of all of the implications of trusting trust. If you can't audit it, you can't trust it. End of discussion.

Here is my general view of the "secure programming" world. It goes out to all developers.

Know your tools. Choose them wisely -
Low level languages are not the problem; they are the most widely understood. Security is a process not a language. When your code inherits features and functionality that you did not intend, bad things can happen. Sure, we may not have buffer overflows, but if your RPC function allows me to execute any code that I want without overflowing buffers, who cares? Also, with these super portable "sand box" languages, I get to find one hole and exploit it everywhere. If you think Java is the answer, please tell me what language you think Java was written in? Also, please read "Reflections on Trusting Trust" by Ken Thompson.

Seeing the big picture -
Peer review is part of the security process; your attackers are becoming very skilled at finding exploitable software bugs using automated tools to help them. Everyone in the development process needs to know the type of application they are developing and the sensitivity levels of the information they are protecting.

Rule of Simplicity -
Design for simplicity; add complexity only where you must. Default to Deny, compartmentalization of code is good for more than just limiting security bugs.

Sweat the small stuff -
Just because certain attack vectors are obscure does not negate their effectiveness; writing good clean code is safer and more sane than allowing a program to "protect" bad coding practices at execution time. We have seen many examples of how this other type of protection fails.

Don't use your customers as your Q/A staff -
The Microsoft Software Release cycle is destroying security from the users and programmers perspective; it causes users to not want to upgrade, and it causes programmers to not want to fix security problems.

Don't build a $100,000 fence for a $1,000 horse -
All data is not created equal, don't treat it as such. Let the protection be commensurate with the asset.

Audit trails -
Trust with accountability. Every significant access, whether denied or permitted must maintain an audit trail.

I think you meant more trustworthy since trust is hardly ever an absolute.

Source audits don't necessarily tell you that a program is trustworthy - there could be nasties in the build chain (see Ken Thompson's Reflections on Trusting Trust) or simply very well disguised code (as I understand this Attempted backdoor insertion was spotted by an automatic checksumming process not by inspection).

Would a formal proof process (i.e. start with formal specification, prove that implementation implements the spec, then that a given executable was produced by the proven implementation) give assurance? I'm not aware of any formal proof systems that can prove that an implementation only implements the spec and nothing else - sounds like an interesting problem doesn't it?

Preventing software makers from disclaiming liability would build trust; your trust in the producer would then be equivalent to the level of liability they are willing to sign up to.

Unfortunately neither of these are likely to happen any time soon (the first for technical limitations, the second for financial reasons) so I agree is that we are stuck with available source (and hence Free Software) as the only means of building trust, but it's worth bearing in mind that there are other (potential) means of assuring trust.

IMHO there is:

IBM Systems Journal, Vol. 35, No. 3&4, 1996 - MIT Media Lab
ACM Newsletter, April 2000
Microsoft US Patent 6,754,472 - Filed: April 27, 2000
2L8? ;-/

I guess engineering, design and programming can't possibly be art.

For a start, they left out the S programming language (started in 1976), for which John Chambers won the ACM Software Systems Award. This, and its Libre dialect R (thanks to Robert Gentleman and Ross Ihaka at University of Aukland), are in daily use by folks who have to write programs to use data.

It is also noteworthy that his contributions aren't solely in the field of mathematics - he has contributed some groundbreaking work in the area of compiler research, such as this paper.

I had a go some time back. The camera rays were pre-calculated. A bounding box was calculated for each triangle in image space. These were ordered by starting row and column. Lists of the possibly visible triangles were maintained as the image space was scanned. Groups of geometry had bounding spheres. I was getting around 15 seconds/frame.

However, there seem to be many open source real-time ray-tracing projects going on:

OpenRT, with it's own FAQ. This project seems to have several games written for it.

Rearview is another game-engine based on ray-tracing

There's also the Avalon Project. There was also an article discussing the use of SSE Instructions. The Source code to a demo is available at RAVI-Demo. Other projects include RealStorm.

It certainly seems to be an active area.

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code.

I think that Reflections on Trusting Trust by Ken Thompson might be what you are referring to.

You're probably thinking of Ken Thompson's Reflections on Trusting Trust. A very good read for anyone involved in computer security.

As has already been mentioned, you should look at this paper: http://www.acm.org/classics/sep95/

A great read.

Have you read the Ken Thompson's classic paper on putting trapdoors into open source systems?

It would be great, if instead, I could hook into the compiler and tell it exactly how it should handle vectors.

Well of course that's what templates are. Yes, their syntax is horrendous but that's what comes of trying to wedge the concept into the existing crannies of C syntax (or when, as Stroustrup remarked to me once, "the ecological niche was already polluted").

If you hanker for a language in which metasyntactic extension is natural, you need Lisp macros (or here and here for a more complex example), Scheme "hygenic" macros or the CLOS MOP.

But if you really want to consider "hooking into the compiler" as you say then you should look at the reflective programming work, the ground work for which was laid down almost 25 years ago by Brian Cantwell Smith and was even implemented, by me and others, back then. Although a lot of work continued in this area that vein pretty much got mined: unless you can think up a completely new control structure there's not a huge amount more you can do with such a system than you could with a normal metasyntactic extension mechanism.

HTH
-d

It would be great, if instead, I could hook into the compiler and tell it exactly how it should handle vectors.

Well of course that's what templates are. Yes, their syntax is horrendous but that's what comes of trying to wedge the concept into the existing crannies of C syntax (or when, as Stroustrup remarked to me once, "the ecological niche was already polluted").

If you hanker for a language in which metasyntactic extension is natural, you need Lisp macros (or here and here for a more complex example), Scheme "hygenic" macros or the CLOS MOP.

But if you really want to consider "hooking into the compiler" as you say then you should look at the reflective programming work, the ground work for which was laid down almost 25 years ago by Brian Cantwell Smith and was even implemented, by me and others, back then. Although a lot of work continued in this area that vein pretty much got mined: unless you can think up a completely new control structure there's not a huge amount more you can do with such a system than you could with a normal metasyntactic extension mechanism.

HTH
-d

Where Wilson goes wrong is in assuming that this kind of environment will be built based on plug-ins. The interrelationships needed between the components to get the required level of functionality are too great. What many people have already noted is that the current Unix environment is in fact based on plug-in development. Editors, debuggers and compilers are modularized as programs, with clean lines of communication between them in the forms of files and streams (which Unix again abstracts to one concept). The limitation of this system lies in the fact that the modules all use their own separate address spaces, and hence each one has to have a private representation of the program. This can't be mitigated by having the separate tools communicate to a central database (this is the most that Wilson's proposal of using XML as the underlying format can accomplish), because then the method of communication would be the limiting factor. Of course, you can use the neutral code-data representation to make the communications between the modules and the database be in terms of sending closures (from reading the paper, I don't think Wilson even considers this), but then you've just designed a single distributed address space, and in the process removed all the encapsulation and modularity advantages of the communication links (not to mention introducing a whole slew of concurrency issues)!

One such integrated system has been built in the past, called Interlisp. Barstow, Shrobe, and Sandewall's book (mentioned above) has a few papers that describe the system, but briefly a few lessons can be distilled from it. First of all, the system itself was an integrated development environment for a dialect of Lisp, where everything was done in one in-core address space: source code (including comments) was represented by data structures in memory, upon which the structure editor (residing in the same address space) operated directly. Code could either be interpreted from the data structure or compiled by the (yes, in-core) compiler. There were several extended packages (besides a Lisp macro-like facility), notably the structure editor and "Conversational LISP," a pseudo-natural language command-prompt parsing system. Although source code (and data) could be serialized to files (there was a sophisticated change-tracking facility that took care of this), the usual way of working was by saving the core image to disk and loading it next session, so the whole environment was persistent. There were hooks for everything from the parser to the compiler to error handling down to the most basic frame-handling code of the stack-based VM, and in order to implement the facilities mentioned above (and some other ones I left out, like the ever-present DWIM automatic error-correction facility) the code took full advantage of them. This caused some trouble when it came to portability of the components and the Interlisp itself (the heavy interdependence caused many problems in bootstrapping the system). Some of these incidents are documented in Barstow et al.'s book, but the Interlisp bootstrapping difficulty has been mentioned in all of the Interlisp porting papers I've read. Unfortunately, I don't think a system with those capabilities can be built with the rescrictions of modularization, since all of the things it did are applicable to programming in any language, and to do them required precisely the

It's a pity each of them aren't more compliant with the now 12 year old SQL-92 standard or the now 5 year old SQL-99 standard.


Not to mention the brand spanking new SQL:2003 standard, see e.g. this overview of the new features.

Microsoft has tried to revolutionize the gaming world through radical software redesign once before, in the mid-to-late 90's, with a project called Talisman. Microsoft had assembled a team of CG scientists that ripped the heart out of the industry, and they put them to work on this project.

The idea of Talisman was that each frame of a game is very much like the next one. In fact, rather than render the next frame from scratch, it might be possible to do projection of the previous frames image to get the next frame. Even if this couldn't be done for the whole image, it could certainly be done for part of it. For example, in a flight simulator, even if the ground is not flat, it is piecewise flat, and those pieces could be 2D-transformed from one frame to the next without the expense of full 3D rendering.

Microsoft hired the best people in the field of DVE (digital video effects) including Steve Gabriel and Alvy Ray Smith, almost certainly to work on this project. Steve Gabriel built the Ampex ADO, the first high-quality digital video effects machine, in the early 80's. Alvy Ray Smith wrote the Siggraph paper on 2-pass transforms, the foundation upon which the ADO is built.

Well. It turns out that rendering texture-mapped polygons can be done very very quickly indeed, and the analysis necessary to "save" time using the Talisman ideas was exceedingly complex and expensive. In the best case, Talisman might have sped things up by a factor of 2 -- about six months time given the fervid pace of graphics board development.

I don't think of this as particularly reassuring, though -- Microsoft usually fails a couple of times before achieving domination. Perhaps Talisman was Rev 1, and XBOX is Rev 2...

Thad Beier

The best available modern system for formal verification is the Extended Static Checking system for Java developed at DEC SRL. This was developed at DEC before HP shut down that research operation. It's still available as a free download.

What all this machinery does is put teeth into "design by contract". With systems like this, you can tell if a function implements its contract, and you can tell if a caller complies with the contract of each thing they call. Before running the program.

Developing in this mode means spending forever getting rid of the static analysis errors. Then, the program usually just runs. That's exactly what you want for embedded systems. But it's painful for low-grade programming like web site development, where "cosmetic errors" are tolerable and time-to-market matters more than correctness.

Yeah, see "contributory negligence".

http://www.acm.org/sigchi/chi96/proceedings/papers /Harrison/blh_txt.htm
http://www.acm.org/sigchi/chi95/Electronic/documnt s/papers/blh_bdy.htm

I have no idea where that space came from.

http://www.acm.org/sigchi/chi96/proceedings/papers /Harrison/blh_txt.htm
http://www.acm.org/sigchi/chi95/Electronic/documnt s/papers/blh_bdy.htm

I have no idea where that space came from.

Try giving your query at http://portal.acm.org/, they return quite a bunch of articles, dunno how many of them are relevant. Download of article text may cost, though...

- Hubert

Thanks for the kind words about the Ray Tracing News. I actually have a new issue ready to go, it's just a matter of converting it to HTML. Tonight, I hope...

- Eric

Thanks for the kind words about the Ray Tracing News. I actually have a new issue ready to go, it's just a matter of converting it to HTML. Tonight, I hope...

- Eric

You're forgetting the granddaddy of them all, APL. oeо...OEZ¼Ss-&#24 7; ± Sheesh, it's greek to me!

This is one of the best collections of graphics algorithms on the net I'm aware of:

comp.graphics.algorithms FAQ

Another favorite of mine is Ray Tracing News, but there haven't been any new issues in a few years.

What other people's favorite collections of algorithms?

-jim