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.
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.
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.)
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.
I don't want to sound too negative, so I'll limit myself to my major concerns:
* The current version has very clear boundaries between stories in the form of the green bar. (Same for (expanded) comments.) With the new design it is simply harder to find these boundaries. * Why all the wasted space in this new design? If I want a narrow column I'll just resize my web browser. The old layout was good because it allowed me to quickly scan through a lot of stories to select the ones that interested me. Same with comments. With the new design I need to scroll quite a bit more before having seen all the content. * Speaking of comments, what is going on with the comment system? I hope the limited comment functionality (for example, lack of folding, etc) is just due to the fact that this is a beta.
What is even more annoying is when the webserver serves up an error page after you have just written a very long comment (or similar) hit "post". My solution (in Linux) is to simply dump/dev/mem to/tmp/memorydump and then search this file for keywords present in the recently written form. While this is not a perfect solution, it has certainly saved me a lot of extra work in a few situations. (Nowadays I mostly write longer entries in emacs and cut&paste everything into the form to avoid this kind of issues.)
If you are going to try this out, note that you'll need to do this immediately, before the memory has been overwritten by another process. (And you obviously need to be root to be able to access/dev/mem in most situations.)
There is at least one car model where researchers has been able to get access to the CAN bus and do all sorts of shenanigans through the following means:
* Specially crafted file on a CD inserted into the CD player
* Exploit weakness in the car bluetooth interface
* Exploit weakness in built in GSM modem
For the details, see http://www.autosec.org/pubs/cars-usenixsec2011.pdf.
(Pretty scary reading. In this case they are also able to disable the brakes and they are also able to engage the brakes on only one of the front wheels for all sorts of "fun"...)
The problem seems to be (if I understand the article correctly) that for example the FMS can be hacked (presumably by buffer overflows or similar exploits) and then used to take over other functionality.
This seems similar to how a malformed RDS packet sent via FM radio can disable the brakes on a certain car: http://www.autosec.org/pubs/cars-usenixsec2011.pdf (among other things).
Exactly how similar these attacks are are difficult to ascertain as the presentation leaves a lot to be guessed, although the net-security report on his talk gives some more details.
It seems that the aircraft industry is about as security conscious as the car industry. The following page at http://lwn.net/Articles/518923/ discusses how researchers were able to take almost complete control, including the breaks, but excluding the steering IIRC by for example the following attack vectors: Malware infested CD inserted into car stereo, malformed RDS package sent via FM radio, some sort of bluetooth hacking, etc. (Also the ODBC-II port of course, although that is cheating....)
At the time I read the lwn article and the associated papers I thought to myself that the car industry should learn security and stability from the aerospace industry. Unfortunately it now turns out that they seem to have done so:(
In theory, yes. In practice no, if you consider the fact that ls might very well be exploitable through malware infested files in this scenario. (I think all sysadmins shudder at the thought that merely listing the contents of a directory with malware in it could be dangerous...)
However, there are ways around this. IIRC chrome decodes images inside a seccomp jail, causing an exploit in the image decoder to be very hard to use for anything except showing a a naughty image and eating CPU time. (I don't know if the enlightenment guys are doing this or not, but I hope they are considering it at least.)
The demo video they have look really cool and I like any idea that improves the usability of the terminal. I just hope that they have some strategies in place to minimize the security impact of adding a large amount of potentially vulnerable code to a critical service such as the terminal (e.g., using securecomp or other mechanisms to sandbox the potentially vulnerable code).
At least one x86 processor design has a special non-x86 programming mode. In the Datasheet for the VIA C3 you can find the following tidbit:
"When set to 1, the ALTINST bit in the FCR enables ex
ecution of an alternate (not x86) instruction set.
While setting this FCR bit is a privileged operation, ex
ecuting the alternate instructions can be done from
any protection level.
This alternate instruction set includes an extended
set of integer, MMX, floating-point, and 3DNow! in-
structions along with additional registers and so
me more powerful instruction forms over the x86
instruction architecture. For example, in the alternat
e instruction set, privileged functions can be used
from any protection level, memory descriptor checki
ng can be bypassed, and many x86 exceptions such as
alignment check can be bypassed.
This alternate instruction set is intended for testing,
debug, and special application usage. Accordingly, it
is not documented for general usage. If you have a ju
stified need for access to these instructions, contact
your VIA representative. "
I have tried to find some details about this alternate instruction set but haven't been able to find anything unfortunately. (And I'm not so interested in this any longer as my remaining Via C3 machine is now only used for backups and does not require very high performance...)
Anyway, I'm guessing that it didn't become very popular due to the fact that they kept the details secret.
Because there is a nice integration between the other buffers and your terminals. For example, say that you want to run a few commands in the same directory that the file you are editing exists. In that case you just type M-x shell to start a shell in that directory. (Note that this also works if you are working with a file on another computer via ssh. Your shell will then automatically start over an ssh session.)
If you are running commands that outputs a lot of text in the terminal the search capability of emacs is really useful as well.
Another use case is the integration between macros, text buffers, and terminals. Consider a use case where you are editing an HTML file and want to ensure that all images referred to in IMG tags are available at a remote location. It is then easy to create a macro in emacs that finds all IMG tags, extract the file name and copy the file name to a suitable scp command that you can paste into the terminal window.
However, I must admit that I still have a few xterms open, but I find myself gravitating towards running shell commands in a shell buffer in emacs, especially when programming. Also, there are of course other ways to solve all of these issues (scripting, file redirection, etc), but for myself I usually find myself preferring to use emacs in most of these cases.
This is a really cool application. I wonder how hard it would be to write an application to do this yourself as a way of identifying for example when a certain TV broadcast was recorded.
Also, for those of you who are interested in what the phase noise looks like there is a nice article about this over at leapsecond.net: http://www.leapsecond.com/pages/mains/ where the phase noise of the power grid is compared to a GPS clock.
Slashdot Mirror
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...
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.
(One possible reason why lectures are still so common: It is a cheap teaching method that scales well with class size.)
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.
I don't want to sound too negative, so I'll limit myself to my major concerns:
* The current version has very clear boundaries between stories in the form of the green bar. (Same for (expanded) comments.) With the new design it is simply harder to find these boundaries.
* Why all the wasted space in this new design? If I want a narrow column I'll just resize my web browser. The old layout was good because it allowed me to quickly scan through a lot of stories to select the ones that interested me. Same with comments. With the new design I need to scroll quite a bit more before having seen all the content.
* Speaking of comments, what is going on with the comment system? I hope the limited comment functionality (for example, lack of folding, etc) is just due to the fact that this is a beta.
What is even more annoying is when the webserver serves up an error page after you have just written a very long comment (or similar) hit "post". My solution (in Linux) is to simply dump /dev/mem to /tmp/memorydump and then search this file for keywords present in the recently written form. While this is not a perfect solution, it has certainly saved me a lot of extra work in a few situations. (Nowadays I mostly write longer entries in emacs and cut&paste everything into the form to avoid this kind of issues.)
/dev/mem in most situations.)
If you are going to try this out, note that you'll need to do this immediately, before the memory has been overwritten by another process. (And you obviously need to be root to be able to access
For the details, see http://www.autosec.org/pubs/cars-usenixsec2011.pdf. (Pretty scary reading. In this case they are also able to disable the brakes and they are also able to engage the brakes on only one of the front wheels for all sorts of "fun"...)
The problem seems to be (if I understand the article correctly) that for example the FMS can be hacked (presumably by buffer overflows or similar exploits) and then used to take over other functionality.
This seems similar to how a malformed RDS packet sent via FM radio can disable the brakes on a certain car: http://www.autosec.org/pubs/cars-usenixsec2011.pdf (among other things).
Exactly how similar these attacks are are difficult to ascertain as the presentation leaves a lot to be guessed, although the net-security report on his talk gives some more details.
It seems that the aircraft industry is about as security conscious as the car industry. The following page at http://lwn.net/Articles/518923/ discusses how researchers were able to take almost complete control, including the breaks, but excluding the steering IIRC by for example the following attack vectors: Malware infested CD inserted into car stereo, malformed RDS package sent via FM radio, some sort of bluetooth hacking, etc. (Also the ODBC-II port of course, although that is cheating....)
:(
At the time I read the lwn article and the associated papers I thought to myself that the car industry should learn security and stability from the aerospace industry. Unfortunately it now turns out that they seem to have done so
In theory, yes. In practice no, if you consider the fact that ls might very well be exploitable through malware infested files in this scenario. (I think all sysadmins shudder at the thought that merely listing the contents of a directory with malware in it could be dangerous...)
However, there are ways around this. IIRC chrome decodes images inside a seccomp jail, causing an exploit in the image decoder to be very hard to use for anything except showing a a naughty image and eating CPU time. (I don't know if the enlightenment guys are doing this or not, but I hope they are considering it at least.)
The demo video they have look really cool and I like any idea that improves the usability of the terminal. I just hope that they have some strategies in place to minimize the security impact of adding a large amount of potentially vulnerable code to a critical service such as the terminal (e.g., using securecomp or other mechanisms to sandbox the potentially vulnerable code).
I have tried to find some details about this alternate instruction set but haven't been able to find anything unfortunately. (And I'm not so interested in this any longer as my remaining Via C3 machine is now only used for backups and does not require very high performance...) Anyway, I'm guessing that it didn't become very popular due to the fact that they kept the details secret.
Because there is a nice integration between the other buffers and your terminals. For example, say that you want to run a few commands in the same directory that the file you are editing exists. In that case you just type M-x shell to start a shell in that directory. (Note that this also works if you are working with a file on another computer via ssh. Your shell will then automatically start over an ssh session.)
If you are running commands that outputs a lot of text in the terminal the search capability of emacs is really useful as well.
Another use case is the integration between macros, text buffers, and terminals. Consider a use case where you are editing an HTML file and want to ensure that all images referred to in IMG tags are available at a remote location. It is then easy to create a macro in emacs that finds all IMG tags, extract the file name and copy the file name to a suitable scp command that you can paste into the terminal window.
However, I must admit that I still have a few xterms open, but I find myself gravitating towards running shell commands in a shell buffer in emacs, especially when programming. Also, there are of course other ways to solve all of these issues (scripting, file redirection, etc), but for myself I usually find myself preferring to use emacs in most of these cases.
This is a really cool application. I wonder how hard it would be to write an application to do this yourself as a way of identifying for example when a certain TV broadcast was recorded.
Also, for those of you who are interested in what the phase noise looks like there is a nice article about this over at leapsecond.net: http://www.leapsecond.com/pages/mains/ where the phase noise of the power grid is compared to a GPS clock.