Slashdot Mirror

..Believe me...I should know. :) I published a paper on the subject back in '97. It's not a new idea by any stretch.

Anyway, Color-reactivity has been around for ages. Even within the scope of involving computers in one form or another.. There are two examples that i'm aware of, both were implemented w/ early 60's technology:

1) I wish I could remember the name. It was basically a computer-controlled art exhibit. They set aside a room in an art gallery with an old IBM 704, rigged the room up with motion sensors and microphones, and used the input levels to drive color wheels and light projectors... So if the gallery was quiet, the walls and all the stuff hanging from the ceiling would turn deep blue and move slowly. If there were alot of people visiting the gallery, the color of the room would turn more pink and yellow. If there was alot of chatter going on inside the gallery, with people talking to eachother, the more psychedelic the room became.

2) There used to be a device back in the early-mid 60's called an Audiovox, if i'm not mistaken...The Audiovox was just a simple amplifier with three colored lights on the front.... Red, Yellow,and Green. It was used to help deaf children learn how to modulate their speech, based upon the feedback the lights produced.... If the lights flickered red, the user would know that their pronunciation was way off. By trying to make (and keep) the green light as solid as possible, deaf children could refine their speech without necessarrily knowing what it sounded like. Neat stuff..

Anyway. Not a new idea. Not even when I had written about it.

I think the game is called "Pegged". My dad made one for me when I was a boy.

Your problem reminds me of the classic article by Niklaus Wirth: "Program Development by Stepwise Refinement" in which he describes different approaches to the Eight Queens Problem. This is highly recommended reading, demonstrating that the algorithm can mean a world of difference.

That's funny since the core functions for the Ti-89 and family was written in C and have self optimizing abilities for specific functions. I know this because the functions are based on Derive, and you can see an ACM paper by the authors of Derive talking about their system.

While starting Computer Science students off with assembly (without first introducing them to a high-level language) may be a relatively new concept these days, the idea of teaching low-level languages to Computer Science students is not a revolutionary technique whatsoever.

I will say however, having had to TA many students through the course based on those works, that starting with assembly language works well for some but not for most. And the ones it works for probably didn't need the class anyway.

NIP and SNORE forever!

sPh

The concept of lifestreams seems interesting and is an approage really different from the "classic" desktop.

The ACM is currently surveying its members on whether or not to oppose this and similar measures. If you're a member, you've probably already gotten e-mail. Be sure to follow up on it if this issue is important to you!

The current policy committee positions are viewable on the ACM web site.

If you're referring to "Go To Statement Considered Harmful" by E. Dijkstra, I find that paper's condemnation of the BASIC programming language a bit outdated. Modern BASIC doesn't use GOTO much anymore. Instead, it uses IF ... THEN ... ELSE ...END IF, DO WHILE ... LOOP, DO ... LOOP WHILE, FOR ... NEXT, SELECT CASE ... CASE ... END SELECT. These came ultimately from the same language where C and Pascal ripped off their control structures: ALGOL.

Hold the phone. I tried that route (unintentionally), and it takes several years of living independently before only your income will be considered and not your income plus your parents' income according to IRS rules. Your school financial aid office can override this in extenuating circumstances, but you have to provide an assload of information proving you are actually independent. Even still, it's no guarantee you'll be considered independent for financial aid purposes.

Stay on your parents' taxes, fill out scholarship/grant applications like mad, and keep the grades up. It also doesn't hurt to get involved in a professional organization at your school such as IEEE, ACM, or NSPE. They either provide scholarships directly or will get you exposure with professors and administrators in order to get other scholarships.

Avoid loans if at all possible, but don't put off your education unnecessarily. Get a co-op job where you can - at least you're getting experience in your field.

When I was first applying, among other schools, I applied to UCI, UCLA, and UC Berkeley. They all gave varying degrees of financial aid and scholarship opportunities. In fact, the degrees of aid varied so much that it taught me some schools want you more than others. Are you dead set on going to the school you want to attend? If so, why? Will a degree from the school you've chosen make a truly night-and-day difference in career opportunities for you?

I mean, if you want to attend MIT or Harvard, then you may, in fact, initially have more opportunities as a result of graduating from those schools. But my own experience has taught me that the cream rises to the top, regardless of the school you attend. Yes, as an MIT grad you might be given extra consideration for certain jobs in the future. But your co-workers will very quickly find out who you are, no matter where you've gotten your degree. I've worked with some brilliant people that came from some very modest schools, that have done extremely well for themselves. I've worked with some smart people, too, that have come from some amazing schools, that have done just so-so. A school's name might get you consideration, but it never guarantees success.

My advice? Just get your freakin' degree, and don't be so picky about where you go. If another school offers you better opportunities, go there. Remember, both Roy Fielding, the architect of HTTP and founder of the Apache HTTP Server Project, and Paul Mockapetris, author of the first implementation of Simple Mail Transfer Protocol (SMTP) and creator of the Domain Name System (DNS), graduated from UCI (Go Anteaters!). It's how good you are that matters. The rest will come to you after you demonstrate that you can do stuff.

As far as specific scholarships go, well, hit up companies, bud. Sun, IBM, Microsoft, Oracle, Novell, all those dudes, they're the ones with the need, the bucks, and the motivation, and I'll bet they all have some kind of academic assistance programs, including internships and scholarship opportunities. But they'll be merit-based, you can count on that, and the competition will be stiff, so start competing on TopCoder, join the ACM, and start competing with them, too, because you're going to need some serious chops.

Good Luck!

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

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

SourceForge Mentifex Donations Page

See this paper. I remember reading the original document in (CACM IIRC) and was pleased to see it updated showing just how far "forward" we've come.

Its a joke/omage. There's a very (in)famous computer science article by one of the founders of computer science titled "Goto Considered Harmful". The article details the "harmful" effects of the "goto" construct in the C/C++ langauges. (I wont editorialize on this subject).

Looks like we were both wrong. It was the other Unix guy, Ken Thompson.

Looking at the source code would be interesting, but it shouldn't give you any confidence in the system. Even in the (practically unattainable) ideal case, where the code is thoroughly analyzed by all the experts and they all agree the code is correct... there is still no proof that the code everybody looked at is the code that will actually be running on the voting machines. Even if you stand over the Diebold employees and watch them compile the source code and install the resulting binary on the machine, you still don't know if that code is what will be running on the machine during the election.

The point is, having access to the (alleged) source code is no guarantee of accuracy. The only reliable guarantee of accuracy is having the system print out a paper receipt that the voter hand-verifies and turns in at the poll. Once you have that, the vote can be recounted by hand, if necessary, and any inaccuracies will be detected. Without that, no electronic system will ever be trustworthy.

Onion routing is a general concept, of which that page is one example. Look at crowds for another example.

Actually, even if you have the source to the compiler and to the application, you can never trust that there won't be a trojan in the resulting executable. There's a well known example designed by Ken Thompson of a compiler that would add a backdoor to the login program every time it compiled it, and would add code to a compiler every time you compiled the compiler. The result of this is that as long as you installed the original compiler from binaries, you would always have executables with exploits.

So, downloading executables even with source availability is a risk. A manageable risk. And a smaller risk than downloading executables without source available. But a risk nevertheless.

Improved XPilot

The first version of Xpilot was ready in 1991 and it was split into a server and a client in 1993 to facilitate internet play. See The Story of XPilot.

Fortunately the developers of XPilot were clever (or lucky) enough to separate the model and the view into the server and the client, respectively. Since the the model resides in the server exclusively, a client can't break the 'physical laws' of the game, which unfortunately is possible by clients of some other games.

An additional benefit of the strong separation of model and view is that players are not influenced by other players network latency (lag), since the server is aware of all the players positions and current action (e.g. key press/mouse click). In relation to the server, clients merely act as 'dumb terminals', sending input events from the user to the server and displaying info it receives from the server as graphics in the game window.

The downside of this is of course that 'locals' get an (unfair) advantage over 'lagged' players by receiving information earlier and thus are able to act faster.

The XPilot client is very configurable and it's easy to change it to display as much graphics as one prefer or one's system can handle. Since the client (and server) is open source, you can even (easily) change it to display information differently from 'official' versions, or synthesize information to 'enhance' your client, but still you can't break any of the game's (server's) physical laws by 'hacking' your client ;-)

In addition to the WWW, there's video-on-demand, TiVO, open source, shirt pocket-sized cell phones and digicams, Aquatred tires, night vision goggles, cordless drills, instant messaging, e-mail, Usenet, IRC, astonishingly photorealistic videogames, Pixar, digital 7.1 surround sound, plasma displays, flu vaccines, Viagra, DVD movies, compact discs, kinetically recharged watches and flashlights, LCD monitors, the iTunes Music Store, the iPod...technological evolution is a gradual thing. But when you add it all up, it's pretty damn cool.

I'm not allowed to know what my copy is doing

An AC above pointed out that Intel are part of the Trusted Computing group. This all reminds me of Ken Thompsons compiler trojan. (where he hacked a c compiler to add a backdoor whenever it is compiling "login".)

So, what might icc add to the security functions of glibc? to gnupg, sshd, lsh?

In a way, the idea of using a proprietary compiler is very similar to that of proprietary voting software.

This is incorrect. It is indeed possible to determine how an arbitrary program will function by looking at and analyzing the code. Rather, the Halting Problem states that it is impossible to write a program that will make this determination.

The Halting Problem has nothing to do with the execution environment (compiler, OS, hardware, etc). The idea that you cannot trust software because of the execution environment was popularized by Brian Kernighan.

WARNING: SPOILER - the Halting Problem is interesting enough that it should be studied in proper context (in a Complexity class), and not from me, who may fubar it up.

The Halting Problem works on Turing Machines, which are a simplified model of computation, but provably equivalent to most other reasonable models of computation. You can think of a Turing machine as a software function/subroutine or a hardware machine, but that does not change what it can compute (they were originally described as mechanical devices - there were no electronic computers at that time). It is very tedious to write Turing machines but they can be analyzed with a level of mathematical rigor not feasible with modern programming languages, or even assembly languages. The relevant properties of Turing machines is that a Turing Machine M is given input A before starting. M may do one of two things: it may halt or it may loop forever. If M halts, it will output an answer, a binary yes or no.

The Halting Problem states:

It is impossible to writing a Turing machine "HALTS(M, A)" which on input (M, A) halts with TRUE if M(A) halts and halts with FALSE if M(A) does not halt.

Proof:

Consider a new program FOO(M). FOO can be described as follows:
If HALTS(M, FOO) returns FALSE, then halt and return TRUE.
If HALTS(M, FOO) returns TRUE, then loop infinitely.
Does FOO(FOO) halt?

FOO can be described as a Turing machine and HALTS must be a Turing machine as well, so FOO is a perfectly valid Turing machine. However, FOO either leads to a contradiction or has unspecified behaviour, so some part of FOO must not be a valid Turing machine. The only unspecified part is the subroutine HALTS, so it must not be a valid Turing machine.

This does not mean that programs cannot be analyzed mathematically (and there are various techniques to do this, loop invariants being one real-world-applicable example), but it means that it is impossible to write programs that do certain things (that is, the Halting Problem helps define what's computable).

Imagine if Turing machines could ask for input from a human during their execution and you were the subroutine HALTS(M, A). What would you answer when asked HALTS(FOO, FOO)? I would answer that humans are not a reasonable model of computation :)

Sun graphics hardware uses intelligent FBRAM (framebuffer RAM). The transparency calculations are handled by the video memory chips themselves, so you need only write the alpha you want, then pixblt the data to memory instead of the read/blend/write cycle.

You might want to read the paper titled FBRAM: A new Form of Memory Optimized for 3D Graphics

regarding your languages point... great languages do exist, and have existed for decades. Two in point:

1. APL is probably the definitive data manipulation programming language, very concise, very very powerful. It dates from the 1960s, is symbol orientated and needs the programmer to have a good understanding of linear algebra or be intelligent enough to pick it up. 1 'line' of APL code can do what it takes 300 lines of the most concise C to do... and APL will do it faster and ore efficiently.

2. Smalltalk, a truely object orientated language, created in the late 70s. Smalltalk programmers refer to languages like C++ as nailing legs onto a dog to make it an octopus, and C being as powerful as assembly and as nice to program as assembly. Smalltalk is 100% object, the language is all nouns and verbs, very 'human'... .

So here is the crux: great languages do exist and are very successful in their academic and high level applications, but the reason they are not totally widespread is they need intelligent people to use them, and highly intelligent people are rarer and cheaper than a bank of code-monkeys to which C/C++/C#/VB etc work can be deligated to.

As a sidenote to this comment, there's an interesting interview with Peter Denning, past president of the ACM, talking about the future of the IT "Profession", and what being an IT professional would or should entail. Dated March, 2000. Take a gander.

here is a recent SOSP paper that discusses using a P2P system to preserve the integrity of publications.

Those interested in Algorhyme can find it in the abstract to Perlman's paper on spanning trees

Let's call that arithmetic game "Numbo". Now imagine playing that against a computer? How much fun can it be? Of course, you think, it's unfair! The computer is much better equipped to do simple (and quite complicated) math, so it could brute force it's way faster then you could pick up a pen.

Well, that's exactly what Daniel Defays did in 1986. But he didn't program the computer "as" a computer to brute force results. Even 17 years ago it was obvious and not too interesting.

If you want more info, here's a bibiographical note refering to a most interesting book on AI.

• Codd: "A Relational Model of Data for Large Shared Data Banks"
• Dijkstra: "Go To Statement Considered Harmful"
• Dijkstra: "Appendix of The Structure of the "THE"-Multiprogramming System"
• Hoare: "Monitors: An Operating System Structuring Concept"
• Metcalfe & Boggs: "Ethernet: Distributed Packet Switching for Local Computer Networks"
• Parnas: "On the Criteria to be Used in Decomposing Systems into Modules"
• Thompson: "Reflections on Trusting Trust"
• Wirth: "Program Development by Stepwise Refinement"

• Codd: "A Relational Model of Data for Large Shared Data Banks"
• Dijkstra: "Go To Statement Considered Harmful"
• Dijkstra: "Appendix of The Structure of the "THE"-Multiprogramming System"
• Hoare: "Monitors: An Operating System Structuring Concept"
• Metcalfe & Boggs: "Ethernet: Distributed Packet Switching for Local Computer Networks"
• Parnas: "On the Criteria to be Used in Decomposing Systems into Modules"
• Thompson: "Reflections on Trusting Trust"
• Wirth: "Program Development by Stepwise Refinement"

...one of my professors introduced me to Scott Savage, the creator of the OOPIC. He wanted us to brainstorm on a security implementation for his device. I suggested something similar, but since the OOPIC is most often used in robotics, he wanted something for physical access security since that has been a hot topic since 9/11 and I work company whose primary business division is security guards. Unfortuneately, he didn't go for it and I ended up submitting a P2P security article to CACM which got accepted but has not yet been printed (they advised it would be 14 months or so, so I'm anxious!).

Yes! Amazing in this day of attempts to install back doors in the Linux kernel and the nearly daily discovery of buffer overflow exploits in that other, integrated operating system that this is the first mention of Thompson's classic. Every would be programmer should read Reflections on Trusting Trust

The (re)discovery of the FFT was a major achievement in itself, and was the algorithm that popularized divide-and-conquer strategies for solving computational problems.

See also; How the FFT gained acceptance for more information about this groundbreaking work.

You have to register to get most papers from ACM (the Association for Computing Machinery who published "GOTO considered harmful"). However, the full text can be found free in their classics series.

Everybody should read this paper, then read Linus Torvalds et. al. discussing the matter on kernaltrap.org

Though it has very few entries, and is no longer updated, there are at least two papers in that list that the typical Slashdotter may have heard about: Go To Statement Considered Harmful, by Dijkstra, and Reflections on Trusting Trust, by Ken Thompson.

The remaining ACM Classics of the Month are here.

Though it has very few entries, and is no longer updated, there are at least two papers in that list that the typical Slashdotter may have heard about: Go To Statement Considered Harmful, by Dijkstra, and Reflections on Trusting Trust, by Ken Thompson.

The remaining ACM Classics of the Month are here.

Though it has very few entries, and is no longer updated, there are at least two papers in that list that the typical Slashdotter may have heard about: Go To Statement Considered Harmful, by Dijkstra, and Reflections on Trusting Trust, by Ken Thompson.

The remaining ACM Classics of the Month are here.

John Backus is often regarded as one of the greatest computer scientists ever to live - I personally like his denouncing of procedural languages in favour of a new functional approach.

John Backus - Can Programming Be Liberated From The Von-Neumann Style?

Go To Statement Considered Harmful.

We ought at least to give Slashdot readers the chance to read these papers...

ACM and IEEE are just the places I would look for such papers. The proceedings of ACM SIGCOMM for example are a very good "filter" for the flood of papers on networking.

ACM and IEEE are just the places I would look for such papers. The proceedings of ACM SIGCOMM for example are a very good "filter" for the flood of papers on networking.

I wonder how many IT gurus are members of ACM or IEEE Computer Society? The % of /. members who are in ACM must be very small because ACM only has 75,000 members in total.

Even if you compile it yourself, it may not be free of trojans. See the following link Reflections on Trusting Trust by Dennis Ritchie.

Yep. I'm thinking about that guy in the very first Unix systems that trojaned the C compiler to trojan itself to trojan the login program.

For those who don't know, that guy in the very first Unix was the Unix coinventor, Ken Thompson himself. He wrote about this Trojan horse (the most brilliant one in the history, I might add) in Communication of the ACM, Vol. 27, No. 8, August 1984 -- Reflections on Trusting Trust. Truely outstanding article.

I wonder if there is not a way to defeat such a method?

For those who didn't read the article by Ken Thompson ( read it here) a compiler is corrupted so that it inserts a bug into all compilers that it compiles, and the purpose of that bug is to insert a bug into another program (such as login) when it compiles it (such as accepting a certain password as the root password)

Both bugs have to be a pattern based search method. They look for some string or some sequence of characters that the original hacker believes will be consistent in future code, and then make their modifications.

Running the code through a obfuscating precompiler that both randomized variable names and added random white space would potentially remove any pattern that the trojan was looking for.

Can anyone think of things that I missed (or ways to make the trojan continue to work in the face of obfuscation)

the obfuscator would, of course, be written in an interpreted language... ( [raises pink to corner of mouth and channels Dr. Evil] whose interpreter has of course been corrupted so that it inserts naughty limericks into every application it "obfuscates".... MUWAHAHAHA... MUWAHAHAH....)

--

Was it the sheep climbing onto the altar, or the cattle lowing to be slain,
or the Son of God hanging dead and bloodied on a cross that told me this was a world condemned, but loved and bought with blood.

Yep. This is old news. The oldest reference I have come across is 1999 (near the bottom).

Small picture in second page of pdf file.

Bit more info

Paper writen on technology used (reg required)

The same guy has also been involved in wearable keyboards which uses finger rings to detect finger movement and 10Mb indoor network that uses human bodies as portable ethernet cables. Masaaki Fukumoto is a busy man.

Turns out you need an ACM subscriptiong to the link to the PDF above.
Ken Thompson has been kind enough to post a link to a free online version in the classics library at the ACM.

Of course, at some point, we do have to trust someone.
Ken Thompson wrote an original speculative essay on this for CACM back in 1984 of all years.

It is really well worth the read. The short form is that there exists a way to subvert the compiler such that it is no longer trustable and it will build a back door into the OS forevermore. This paper is a must read.

Of course, at some point, we do have to trust someone.
Ken Thompson wrote an original speculative essay on this for CACM back in 1984 of all years.

It is really well worth the read. The short form is that there exists a way to subvert the compiler such that it is no longer trustable and it will build a back door into the OS forevermore. This paper is a must read.

Other than manual inspection of the resulting compiler binary, a solution for this is too use many third party C compilers and enviroments for the original bootstrap compiler build and compare the resulting code after the resulting compiler has rebuild itself for the third time. If the result greatly differs then manualy inspect the generated code where it differs.

You can do this with GCC, but I don't know if the source Microsoft's C compiler is currently portable enough to do this.

The rest just good secure housekeeping, Don't build as Root and keep the build systems isolated and secure as you should be doing for vital public key signing enviroments.

My post was actually related to the Speech the parent poster was referring to.

Yours was just innane.

You mean like this?