> 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.
The make magazine is pretty good if you are into DIY. If you are into electrical engineering I guess Circuit Cellar or Elektor could be interesting as well.
Just wanted to thank you for creating Slashdot in the first place. It quickly became the first website I visited every morning and still remains so after many years. While I'm sure that it will remain an interesting place for years to come I can't help but feel a bit sad about the fact that the founder has handed over the keys so to say.
On the other hand, I look forward to seeing your next small personal project which just happens to turn out more successful than anyone would imagine in the beginning
Something which seems to be overlooked by most of the commenters is the fact that the human readable description of a patent does not define the patent. The part you need to read to really understand a patent is the claims. Some patents which seem fairly obvious when reading the title, and description of the patent are actually very narrow when looking at the claims. Other patents seem fairly narrow when reading the description whereas the claims are very broad.
I'm not a lawyer, so take the remaining parts of this part with a big grain of salt, but it seems as if there are fairly obvious way to work around this patent without infringing it. As I understand it, the independent claims are the most important parts of a patent. They are reproduced below for your enjoyment. Note that both claims discusses periodic queries. It seems likely that you wouldn't infringe the patent if you did away with the periodic queries and instead had the shipper computer notify you whenever it had new information available. (As a side effect, this would be less bandwidth and processor intensive, similar to how it is usually better to use IRQ driven I/O instead of polling based I/O in an operating system...)
In both independent claims they also discuss that the periodic queries are halted and restarted a day prior to the estimated delivery. If you never halted the periodic queries you may have another possibility of avoiding infringement.
Nevertheless, this seems fairly close to "System for accomplishing a well known task with a computer" as gstoddart mentioned in an earlier comment.
Independent claims:
"1. A method of providing notification of impending delivery of a shipment shipped by a shipper to a shipping address specified by a customer, comprising: periodically querying, by a broker computer system independent of the shipper and a merchant and which enabled the customer to purchase an item contained in the shipment from the merchant, a shipper computer system to obtain status information for the shipment with each query, wherein a periodic query of the shipment computer system comprises: requesting status information from the shipper computer system by providing a shipment identifier of the shipment to the shipper computer system; and receiving status information in response thereto; responsive to status information obtained with a periodic query indicating an estimated delivery date for the shipment, halting, by the broker computer system, the periodic queries and scheduling the restart of periodic queries of the shipper computer system a day prior to the estimated delivery date; restarting, by the broker computer system, periodic queries of the shipper computer system the day prior to the estimated delivery date to obtain updated status information with each query; responsive to updated status information obtained with a periodic query indicating that the shipment is out for delivery to the customer, halting, by the broker computer system, the periodic queries and calculating an estimated delivery time for the shipment based at least in part on the status information; and sending, by the broker computer system, an electronic message including the estimated delivery time to the customer. "
"11. A system for providing notification of impending delivery of a shipment shipped by a shipper to a shipping address specified by a customer, comprising: a computer processor; and a computer-readable storage medium storing computer program modules configured to execute on the computer processor, the computer program modules comprising: a shipper interface module for: periodically querying, by a broker independent of the shipper and a merchant and which enabled the customer to purchase an item contained in the shipment from the merchant, a shipper computer system to obtain status information for the shipment with each query, wherein a periodic query of the shipment computer system comprises: requesting status information from the shipper computer system by providing a shipment identifier of the shipment to the shipper computer system; and receiving status information in response thereto; responsive to status information obtained with a periodic query indicating an estimated delivery date for the shipment, halting, by the broker, the periodic queries and scheduling the restart of periodic queries of the shipper computer system a day prior to the estimated delivery date; restarting, by the broker, periodic queries of the shipper computer system the day prior to the estimated delivery date to obtain updated status information with each query; an arrival calculation module for, responsive to updated status information obtained with a periodic query indicating that the shipment is out for delivery to the customer, halting, by the broker, the periodic queries and calculating an estimated delivery time for the shipment based at least in part on the status information; and an arrival notification module for sending, by the broker, an electronic message including the estimated delivery time to the customer. "
If you aren't on friendly terms with your mouse I would recommend the conkeror web browser. This has saved me quite some hazzle in situations where I either don't have a mouse (my TV computer) or when the mouse is awkward to use (my laptop with a substandard trackpad).
For those who don't know, conkeror is a web browser based on xulrunner which is designed to be used in an effective manner without a mouse. If you happen to like emacs, you'll probably feel right at home since the keybindings (by default) are inspired by emacs. If you are not familiar with emacs you will probably need some more time to get used to conkeror. However, since conkeror allows you to use a mouse as well if you want to you can adapt to the browser without feeling too handicapped.
If this seems interesting you can find more information about conkeror at http://conkeror.org/.
Actually, at least early NVIDIA cards had pretty good hardware support for this as far as I understood it. I don't know the status of their current cards, but their early cards had hardware support for different contexts and would generate an error if a user tried to do something it was not allowed to do. (For example, rendering outside of the selected window.) So the cards could allow a user to send commands via DMA to the card (this is often called direct rendering) in a secure manner without any risk of privilege escalation.
Also, NVIDIA wasn't the first company to have this support. GPUs from SGI were designed around the concept of secure direct rendering a long time before PC level GPUs got popular. As far as I understood it, the original DRI developers for Linux were quite security conscious from the beginning as well.
Disclaimer: I haven't been involved in 3D driver development for quite some time now, so I don't know the current hardware/software status at all, but I would be surprised if NVIDIA has started to design hardware that does not allow for secure direct rendering. However, just because the hardware is secure doesn't mean that the driver is free of security related bugs...
Frankly, at least on Linux with open source drivers and/or NVIDIA hardware I would not be very worried about unknown privilege escalation bugs related to being able to issue arbitrary DMA commands. However, I would be quite worried about bugs in the driver which would allow for arbitrary native code execution as the current user. While not a problem for normal OpenGL applications (as they are already executing as native code), it is a huge problems for web application since this could be a way to escape from the javascript sandbox.
That sounds good, I don't have my N900 with me right now, but the old page was somewhat awkward to use with the N900 (but less awkward than many other sites).
Anyway, I have always liked the fact that Slashdot has always had a fairly clean design without a lot of clutter (compare the front page to for example the front page of nytimes.com and see which one you think is most elegant). And there is always the mobile version (http://slashdot.org/palm/) if you want to just read the news without any clutter at all.
According to the GPL FAQ over at gnu.org, internal corporate use does not count as distribution: http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
I'd also like to apologize for belonging to a EU country now.
(Don't blame me, I voted for Kodos!)
This is a favorite image of a wall socket, but I wouldn't want to use it myself...
http://thereifixedit.com/2009/07/23/epic-kludge-photo-amateur-conversion/
This post made me realize that I have also been using FVWM as a window manager for the past 13 years or so. (Although I sometimes use it together with KDE.)
"The medium is the massage." -- Crazy Nigel
