If you are really really paranoid you could build your own processor using TTL logic (or perhaps CMOS logic may be better). It is not going to be very fast, but it is unlikely that the TTL chips are backdoored (and even if they are backdoored it is unlikely that the backdoor will be able to harm this system since the design of your processor is unlikely to be known by the vendor). The performance will of course not be good enough for running a web browser for example, but it could be good enough in many embedded situations.

I've been toying with the idea of doing this together with a very minimal compiler designed to be easy to inspect for security hole and easy to assemble by hand to minimize the risk of backdoors in order to ensure that really paranoid people can bootstrap a system which is extremely unlikely to contain backdoors. (I'm not that paranoid myself, I would just like the challenge of building a TTL based computer good enough to boot Linux :))

Just wanted to chime in with some notes on conditional execution:

First of all, if all you care about is single-issue non-superscalar with a relatively deep pipeline, conditional execution is probably a good idea in my experience due to the very low implementation cost. Especially if your branch prediction is lousy. However, if you are aiming for high-end systems conditional move may not be that big of a deal. See for example the following analysis from Linus Torvalds regarding cmov: http://yarchive.net/comp/linux... where it can be seen that cmov is basically a win only if you have situations where a branch predictor wouldn't do a good job. However, it may still be a good idea to keep some sort of conditional instruction around since it is likely to be useful if you are dealing with for example lossless compression/decompressions since you are typically dealing with unpredictable data in this case.

I could also chime in with an interesting tidbit from ARM1. Conditional execution was probably a really big deal here since the ARM1 didn't have any caches. It did however have support for burst reads from memory. As long as it was fetching instructions sequentially it could basically sustain a very high instruction throughput. A branch would however reduce the performance significantly since the burst had to be aborted. Conditional execution could be done while maintaining the burst however. This is one of the reasons why ARM1 with about 30000 transistors was competitive in performance with for example the 68020 which had close to 200000 transistors. If the ARM instruction set was designed today however it is likely that the designers would not go crazy with conditional execution since the bits could be better used for something else.

Oh, look, closest thing I've seen to a UID neighbour in years :)

Since I had already perfected my FVWM config I was able to register my account early on instead of tinkering with my window manager :) (Speaking of longevity, I'm still using more or less the same FVWM config...)

I don't think there are many websites that have made such a big impact as this site has made. Even though I don't really have time to partake in the discussions here (or at other websites for that matter due to real life) I still visit slashdot more or less daily and I often find interesting news here. Lets hope the site continues to run for 20 more years (by that time we will all be highly paid consultants working to fix the imminent 2038 year bug :) )

I too have little use for the menus (not to mention the screen wasting toolbar) of emacs. However, I do like the idea of running a webbrowser from within emacs (a webkit based webbrowser widget was actually the only thing that was merged. The full xwidget branch isn't merged yet). I especially hope that this will make it possible to add words from the webbrowser to emacs autocomplete. That would be really convenient in many cases.

There seems to be at least an attempt at interfacing with facebook: http://www.emacswiki.org/emacs...

That is really great news. Good enough that I actually logged in to comment rather than commenting anonymously as I usually do. I've been following the xwidgets branch from the sidelines for some time but never bothered to build Joakim Verona's branch myself. It should be noted though that what was merged was not the full xwidgets experience, rather the xwidgets_mvp branch. This branch only contains support for embedding a webkit browser widget. (Although even that will be extremely useful I believe.)

The xwidgets branch however promises even more. The main use case (at least from my point of view) isn't really to put normal widgets such as gtk buttons or sliders or anything like that in an emacs window. From my point of view the most important thing is that you will be able to embed whole applications using the GtkSocket widget. This means that you could, for example:
* Have a good PDF viewer embedded in one buffer while you are editing latex source code in another and be able to easily switch between those buffers using emacs commands.
* You could have inkscape running in one buffer and use normal inkscape editing commands for almost everything, except when you are editing text. In those situations you may want to use emacs commands instead.
* You could have a *good* webbrowser running inside emacs to search for documentation online while coding

Of course, the main xwidgets branch also opens up possibililties when it comes to prettyifying a lot of built in emacs applications. However, I don't find that very necessary in many cases. One of the main advantages with emacs is that (almost) everything is text, which means that you get a synergistic effect the more you do inside emacs.

; Witty end of comment for emacs aficionados:
(animate-string "Congratulations to Joakim Verona for getting this merged" 10 10)

If you read the article in PNAS ( http://www.pnas.org/content/ea... ) you can see that they consider the question of examination equivalence by only looking at previous studies that "were largely or solely limited to changes in the conduct of the regularly scheduled class or recitation sessions;" So based on what I have read in the paper I would classify this as very far from junk science.

The article (available at http://www.pnas.org/content/ea... ) is a meta-analysis of earlier studies. So this study can be seen as a validation of the earlier research rather than presenting something completely novel.

(One possible reason why lectures are still so common: It is a cheap teaching method that scales well with class size.)

... that it is easier to take cheap shots at research if you only read the slashdot summary rather than the actual publication.

So to answer your concerns I tracked down the publication in PNAS: http://www.pnas.org/content/ea...

To quote from the article:

The data we analyzed came from two types of studies: (i) randomized trials, where each student was randomly placed in a treatment; and (ii) quasirandom designs where students self-sorted into classes, blind to the treatment at the time of registering for the class

In other words, if I understand the article correctly, the authors only considered studies where active learning was contrasted with traditional lectures in the same course! Therefore it seems likely that active learning is a good idea, regardless of whether the topic is hard or easy. (By the way, active learning doesn't necessarily have to involve fun and games, although if a student, in general, doesn't think that learning is fun, perhaps he or she should consider doing something else...)

It is late here and I'm in a negative mood. However, the fact that at least one staff member seems to actually listen to the comments written here is a hopeful indication. (Also, the mock-ups on dropbox in the grandparent looks promising. I'll have to look into the Stylish plugin which I didn't know about before.)

Personally I'm very interested in the Discourse platform which is being created by some of the stackexchange people. I suspect that a website based on Discourse might become the new "slashdot" in the future.

Although I'm not volunteering to knock up a new slashdot based on discourse :)

I think the most damning thing about the new comment system is that I had to go back to the old version of the site to read through the comments in an efficient manner. (And I'm not talking about the fact that the "reply" button is not implemented yet...)

Also, the exact user id is mostly for bragging rights anyway, but it does give an indication as to whether the user is a long time user of slashdot or not. Although other indications such as the karma of the user might be more useful in most situations...

I'm using A3 paper when appropriate and A4 paper when appropriate. However, if my printer suddenly starts to print A4 sized content (or even A5 sized content) on the A3 paper I actually wanted to print it to I'm getting mighty irritated.