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.

I have been wondering about this myself. This situation is not really that well explored and I'd really like to see a license for HDL-like code with some high quality lawyering behind it.

One problem is that hardware such as ASICs are typically not protected by copyright. Instead it is protected by maskworks laws which are similar to, but not as strong as copyright. The intention is that ASIC-like hardware should be protected by patents. (Although I guess an exception would be made for ROMs where the layout itself would be protected by maskworks whereas the actual metal configuration of the ROM array would be protected by copyright.)

For FPGAs I have heard people claim that their lawyers consider the bitstream to fall under copyright law -> e.g., the GPL would be fully enforcable. Another interesting case in point is that SUN choose the GPLv3 as the license when releasing the source code for the Niagara processor. Personally I've used an MIT-style license when releasing open source hardware because I was more interested in getting the (fairly small) designs out there than to try to enforce the GPL license for something it wasn't really designed to protect.

Also note that the GNU FAQ has the following to say about hardware:

Any material that can be copyrighted can be licensed under the GPL. GPLv3 can also be used to license materials covered by other copyright-like laws, such as semiconductor masks. So, as an example, you can release a drawing of a physical object or circuit under the GPL.

In many situations, copyright does not cover making physical hardware from a drawing. In these situations, your license for the drawing simply can't exert any control over making or selling physical hardware, regardless of the license you use. When copyright does cover making hardware, for instance with IC masks, the GPL handles that case in a useful way.

Here is one old timer checking in. Although I'm more of a passive consumer of slashdot these days. Although this is not really slashdot's fault, I'm more of a passive consumer of mailing lists, discussion groups, usenet, etc these days as well. (Having a day job and a family does have a higher priority for me than participating in forum discussions these days.)

> MIT please get out of the dreams lab once in a while

Actually, no chip-designer wants to use a network-on-chip if they can avoid it due to the added complexity. However, for future SoC designs with hundred of modules it will simply not be efficient to have direct parallel links between every module on the chip. A network will in many cases therefore be the best trade-off between silicon area, bandwidth, and energy efficiency.

Also, note that a typical SoC used in for example a mobile phone already have significantly more eight cores (although most of these cores are not processors, they still require communication links of some sort). (Take the OMAP4470 as an example [1] - it has at least, two Cortex-A9, one IVA3 accelerator, powervr graphics, a signal processor, SDRAM controller, flash controller, MMC controller, HDMI output, SPI controllers, I2C controllers, SDIO controller, UART controller, USB controller, GPIO controller, etc). So if MIT is in a dream lab, the only thing they are doing is trying to come up with a way to handle the nightmare that future on-chip communication entails.

Actually, the networks used in Network-on-Chips are quite unlike the networks used for TCP/IP. For example, when you develop a System-on-Chip you have a very good idea of your workload, so you can optimize the network topology based on that information. The networks proposed in NoC research typically also have other features not found on the Internet such as guaranteed and in-order delivery of packets. (Which is fairly easy to do in a small network with low latencies.) In many cases you can also reserve bandwidth between nodes so that you can give real-time guarantees. However, in some systems circuit-switching may be better than packet switching, although most researchers seem to focus on packet-switching NoCs.

A good paper to read for an introduction to NoCs is "Route Packets, Not Wires: On-Chip Interconnection Networks" by Dally and Towles. (You can find it at http://www.cs.berkeley.edu/~vwen/backgrnd_papers/41_4.pdf if you are interested.)

Anyway, the basic idea behind a NoC is that it is a good trade-off between the two extremes of a bus and a cross-bar. If you implement a chip with just a single bus on it, the silicon-area used for communication will be very low, but the bandwidth will also be relatively low. On the other hand, if you create a huge cross-bar to which every module is connected to, the silicon area used for communication is extremely high (the area for a cross-bar grows quadratically with the number of ports), although the theoretical maximum bandwidth is also very high. In most systems, the optimum point will be somewhere in between, where you have several buses and/or cross-bars connected by a network.

Actually, even the first computers used buses. For example the Z3, which was built in the early 40's, used buses to transport data. (Actually, the Z3 architecture was very advanced for its time and it is much closer to a modern simple processor than for example ENIAC.)

Regarding the article summary I could note that it is not only researchers from MIT that says that a network-on-chip (NoC) is a promising concept for the future of chip design. Almost every researcher I've talked to seem to agree that NoCs of some form are needed for future chips. Note that the concept of packet switching networks are not new in computers. It has been used in supercomputers for a long time, and HyperTransport is based on a packet switching architecture.

That being said, the work the researchers have actually done seem interesting, especially the concept of virtual bypassing which I'll have to read up on at some point.