Slashdot Mirror

Does breaking the PKI consist of break TLS?

What "breaking of PKI" are you referring to? If you mean certificates generated with non-random keys then this does not break TLS itself - though of course connections using weak certificates could be compromised. Ditto to certificates issues with short keys. The compromised CAs then this could be seen as a weakness in the whole idea of centralised trusted CAs. While I like the idea of decentralised CAs but think that it is not something to be rushed in to.

An interesting read on the relationship between water and energy
IEEE Spectrum report on water versus energy

While it's true you can get water from the ocean via desalination, it has environmental problems of its own, like what to do with the concentrated briny effluent you output. The big knock against widespread desalination is that it takes a lot of energy. Most energy now and for the foreseeable future will be made in power plants that require, you guessed it, lots of water. You can do both, but you get deminishing returns. See this IEEE series (not paywalled) that goes into great depths about the difficult tradeoffs between water and energy.

IEEE disagrees with you.

http://spectrum.ieee.org/at-work/tech-careers/engineering-is-not-science

Not quite. If all the retail stores are going broke because everyone is buying stuff off the internet, then USPS should be doing a roaring trade in package deliveries.

Not sure why USPS don't seem to be able to leverage off all that traffic to make a profit.

They are making tons through parcel deliveries. The problem is, congress prevents them from adapting.

USPS is required to be revenue neutral and non-profit (i.e., they make as much money as they need). Congress controls how much a stamp costs (and other basic services - so their income is hobbled), and congress controls how much they're required to pay out (e.g., USPS is required to pre-pay retirement for 75 years over the next 10. Yes, that means they're paying NOW for a retirement package for employees who have not even been hired yet).

In fact, because of changes signed in by George Bush (notably, USPS was running a pretty damn tight ship until 2006 when the requirement mandate kicked in.).

http://spectrum.ieee.org/telecom/internet/email-isnt-killing-the-post-office

Basically, the government has set up USPS to fail as an example of "government inefficiency" by making it have obligations that go above and beyond what any company has to provide, including USPS' competitors.

Then again, I suppose it's better paying $8 to have FedEx send a letter across the US than 50 cents.

> It's not "directly derived from"; it's "loosely inspired by"

Correct, but in some places it was "tightly inspired". While QDOS didn't copy CP/M it *definitely* copied some of the data structure fields verbatim. Back in the early '90's there was a "Ralph Brown's Interrupt List" that was essential for x86 assembly programmers. It documented the FCB (File Control Blocks) that started in MSDOS 1.x to open / read / write / close files (and existed in all Dos version until ~ Win95) before file handles were implemented in MS-DOS 2.x.

http://en.wikipedia.org/wiki/File_control_block
http://en.wikipedia.org/wiki/MS-DOS_API

While the FCB wasn't identical to the CP/M it definitely had some of the *exact* same fields -- so QDOS was most definitely "inspired" by CP/M as any assembly language programmer could tell.

For more details this is an interesting read:
http://spectrum.ieee.org/computing/software/did-bill-gates-steal-the-heart-of-dos/0

http://spectrum.ieee.org/semiconductors/processors/the-battle-between-arm-and-intel-gets-real

288 in a single RU, so less than one RU would be an acceptable answer.

According to TFA, the control room featured is mostly Shuttle era equipment, with SOME Apollo era consoles and equipment.

Interesting things I learned from the article:
- Bare information from the mainframe (IBM System/360) was combined with an automated slide overlay to make it more readable with column headings and threshold levels etc.
- Each person manning a console had a small team of people in another room helping them and communicating with them.
- These people were the real deal, and were hand picked for their positions. People who couldn't deal with the weight of the position were washed out within a year before they ever made it to a live mission.
- From TFA " Sy recommends the IEEE's three-part article, "Houston, We Have a Solution" as the most complete and accurate retelling of the entire Apollo 13 explosion and its aftermath."
That is HERE: http://spectrum.ieee.org/aerospace/space-flight/apollo-13-we-have-a-solution and it is a FANTASTIC read. The lessons learned from Apollo 13 were fantastic, and upgrades were applied before Apollo 14. One major one was that if something went out of spec, a light would come one advising that there was an anomaly. But, if it went away, so did the light. So an intermittent problem had to be caught red handed. By Apollo 14, they'd changed it so that the light *stayed* on until dismissed. Seems obvious now, but back then it wasn't. These people were true pioneers.

Apollo 13, We Have a Solution

Here's the funny thing: Industry develops a standard and the IEEE gets together to approve it, but once they do they own the copyright on the standard and you can only get a copy from them, costing several hundred bucks. Some standards are split up, so instead of one fat book you are buying many small thin ones. Not a problem for big business, but a sizable expense for smaller ones and hardly an 'open' standard we want for voting machines.

Examples: http://www.techstreet.com/cgi-bin/browse?publisher_id=95&subgroup_id=36802
A small number are free, though not many. http://standards.ieee.org/about/get/index.html

The IEEE, just like academic publishers, restricts who papers can be shown too. The IEEE is a professional organization - not a for-profit publisher, but they act just another information monopoly.
http://www.techdirt.com/articles/20100127/0423477913.shtml

Not really, this has been used to manufacture photovoltaic cells. Its called kerfless wafering http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6317951&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6317951

http://ewh.ieee.org/r7/hamilton/biographies/JacksonS.htm

That quy is a fruitcake and a nutcase. Wow.

Why don't we cut out the middle man (batteries) and just go to wireless powering of devices? http://ewh.ieee.org/r7/hamilton/biographies/JacksonS.htm

If you thought cellphone coverage was bad...

Why don't we cut out the middle man (batteries) and just go to wireless powering of devices?

http://ewh.ieee.org/r7/hamilton/biographies/JacksonS.htm

MS-DOS took a very similar approach from an interface perspective but that's about it. Underneath the hood its neither a clone nor a clean room re-implementation of CP/M.

There's a very thorough article in IEEE Spectrum by an author who used modern disassembly, debugging, and code similarity techniques and applied them against various versions of DOS and CP/M. Everything led him to a dead end.

http://spectrum.ieee.org/computing/software/did-bill-gates-steal-the-heart-of-dos/0

Growing up in Adelaide, Australia, Cheok had often played with the chickens kept by his grandfather, so he decided to focus on poultry (rule one). He built haptic jackets for the chickens himself (rule two), embedding them with vibrating elements. Tinkering taught him just how difficult it is to produce a gentle, humanlike touch. “The system develops as you build it,” Cheok says. “I see research as iterative—you’re learning from what you’re making.”

802.11 is a MAC standard, not a radio standard.

This is incorrect. 802.11 is both -- it specifies both the MAC and a number of physical (PHY) layers, better known as the "radio" part. The standards can be downloaded here -- for free -- if you'd like to see for yourself.

"McKinnon claimed that UFOs were the reason for his hack. Convinced that the government was hiding alien antigravity devices and advanced energy technologies, he planned to find and release the information for the benefit of humanity. He said his intrusion was detected just as he was downloading a photo from NASA's Johnson Space Center of what he believed to be a UFO." http://spectrum.ieee.org/telecom/internet/the-autistic-hacker/0

I'd rather trust a western company... http://spectrum.ieee.org/riskfactor/telecom/security/nortel-penetrated-by-hackers-since-at-least-2000

A report EFDA in preparation for ITER here. It gives shot cycle times:

• Jet: 30 minutes
• DIII-D: 14 minutes
• ASDEX: Just under 30 minutes
• FTU: 20 minutes
• RFX: 10 minutes

It even discusses replacement schedule of some equipment for ITER, with only a few blanket modules replaced per year and a complete replacement only every 10 years, for example. The time between shots is referenced as 1600 seconds here due to the limitations it places on computing requirements (so repetition rate would be ~2000 seconds since the plasma shots will be up to 400 seconds).

The introduction in the full text of the paper here discusses how HiPER will be designed with a target of 10 Hz repetition rate for a 100 full power shot sequence.

The report here mentions how the Omega laser system is designed around a 30 minute repetition rate.

3 minutes for LHD

15 minutes for NSTX

2 minutes for MST

5-15 minutes for TFTR

20-30 per working day for JT-60

Even the ones I references as being kind of slow, NIF and Z-machine, are one shot per day, not weeks and months between shots.

The smaller projects I've worked on typically ran every 2-5 minutes when cycling during a normal day, limited by them typically using underpowered, but free (due to inheriting from previous experiment) cooling system. Their run campaigns were limited by staffing, as when the handful of people were busy analyzing data, no one was left to run the machine. Larger machines I've worked on had technicians and large teams to run 5+ shifts a week, and would run for at least a third of the year. Time not running was typically spent calibrating, repairing, upgrading diagnostics, and occasionally power supplies, most of which are components a production reactor would not have. Larger machines had a much more diverse diagnostic suite, so were much harder to organize and get things ready for a full run campaign, for reasons unrelated to plasma or neutron damage. The larger machines also could run into budget reasons running for a larger part of year due to staffing (technicians assigned to more than one thing) and power costs.

Neutron damage, failures due to plasma damage, and over all maintenance costs and cycling are a MAJOR issue that fusion research needs to address before becoming commercial. But that still doesn't mean your "hours, days, and even weeks" accurate for anything currently or in the near future.

It looks like someone else has taken tech like that and done something geared toward finding biomedical applications for it. The ideas and experiments in this abstract could perhaps be useful as a building block for some sort of basic tricorder. Reading the body's reaction to drugs and stress, screening neuropsych deficits, and possibly lots more by just simply scanning them with one single machine? That's Star Trek stuff.

IEEE Spectrum reported last year on new RNG tech from Intel, called Bull Mountain, and implemented in Ivy Bridge processors. It uses a large array of cross-coupled inverters. Thermal noise (a semi-random process) causes them to each inverter pair to latch to 1 or 0 very quickly. The inverters are reset, then allowed to re-latch, many times per second. This isn't particularly new. But they also add circuitry that continuously checks the statistical randomness of the output, and combines multiple number streams to ensure maximum randomness. The result then becomes the seed for a more conventional PRNG. The upshot is the ability to produce billions of demonstrably random numbers per second, all in a low-power peripheral on the microprocessor.

http://www.medicalnewstoday.com/articles/247321.php
http://spectrum.ieee.org/geek-life/tools-toys/this-is-your-brain-on-fmri

http://gizmodo.com/5922208/scientists-invent-mind+reading-system-that-lets-you-type-with-your-brain

http://www.aclu.org/blog/technology-and-liberty/high-tech-mind-readers-are-latest-effort-detect-lies

http://www.hlntv.com/article/2012/04/06/mobile-brain-scanner-ibrain-stephen-hawking

Do more research. It's already here even if you don't know about it.

Was making the exact same post as parent. Many people are thinking about privacy in vehicular networks. For example, most systems for aggregating data from cars for showing traffic speed anonymize the data in various ways to try to protect privacy. Here are some details:

A project at the University of Illinois preserves privacy when reconstructing global maps based on data collected from cars: http://www.springerlink.com/content/h545111k4g217374/

Abstract: "The proliferation of sensors in devices of frequent use, such as mobile phones, offers unprecedented opportunities for forming self-selected communities around shared sensory data pools that enable community specific applications of mutual interest. Such applications have recently been termed participatory sensing. An important category of participatory sensing applications is one that construct maps of different phenomena (e.g., traffic speed, pollution) using vehicular participatory sensing. An example is sharing data from GPS-enabled cell-phones to map traffic or noise patterns. Concerns with data privacy are a key impediment to the proliferation of such applications. This paper presents theoretical foundations, a system implementation, and an experimental evaluation of a perturbation-based mechanism for ensuring privacy of location-tagged participatory sensing data while allowing correct reconstruction of community statistics of interest (computed from shared perturbed data). The system is applied to construct accurate traffic speed maps in a small campus town from shared GPS data of participating vehicles, where the individual vehicles are allowed to “lie” about their actual location and speed at all times. An extensive evaluation demonstrates the efficacy of the approach in concealing multi-dimensional, correlated, time-series data while allowing for accurate reconstruction of spatial statistics."

The Mobile Millennium project ( http://traffic.berkeley.edu/ ) from Berkeley uses "virtual trip lines": http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5871633

Abstract: "Traffic monitoring using probe vehicles with GPS receivers promises significant improvements in cost, coverage, and accuracy over dedicated infrastructure systems. Current approaches, however, raise privacy concerns because they require participants to reveal their positions to an external traffic monitoring server. To address this challenge, we describe a system based on virtual trip lines and an associated cloaking technique, followed by another system design in which we relax the privacy requirements to maximize the accuracy of real-time traffic estimation. We introduce virtual trip lines which are geographic markers that indicate where vehicles should provide speed updates. These markers are placed to avoid specific privacy sensitive locations. They also allow aggregating and cloaking several location updates based on trip line identifiers, without knowing the actual geographic locations of these trip lines. Thus, they facilitate the design of a distributed architecture, in which no single entity has a complete knowledge of probe identities and fine-grained location information. We have implemented the system with GPS smartphone clients and conducted a controlled experiment with 100 phone-equipped drivers circling a highway segment, which was later extended into a year-long public deployment."

Everyone is working on this. This article blatantly contradicts a decade of VANET research. Even the car industry is involved in providing privacy-preserving protocols of all kinds. Here is a sample of papers covering this topic:
Privacy and identity management for vehicular communication systems: a position paper (2006)
A tutorial survey on vehicular ad hoc networks (2008)
Support of Anonymity in VANETs - Putting Pseudonymity into Practice (2007)
Towards a security architecture for vehicular ad hoc networks (2006)
Anonymity Analysis on Social Spot Based Pseudonym Changing for Location Privacy in VANETs (2011)
A Robust Conditional Privacy-Preserving Authentication Protocol in VANET (2009)

Also, the sevecom project and the preserve project just some examples of projects that work on this topic. In the US, pseudonyms have been standardized by IEEE 1609.2.

In other words, the claim that no-one works on it is bullcrap. Is it still bad for privacy? Maybe. With the right choices, we can build a secure and privacy-preserving system that is a lot safer than what we see on the road now. Recall the discussion on vaccination from yesterday? There, the /. hivemind tells us how the good of the community comes first if my right to choose harms others. This is the same here. Your privacy is important, and we try to protect it, but if there's a small decrease in privacy for a huge gain in safety, then you're out of luck.

Everyone is working on this. This article blatantly contradicts a decade of VANET research. Even the car industry is involved in providing privacy-preserving protocols of all kinds. Here is a sample of papers covering this topic:
Privacy and identity management for vehicular communication systems: a position paper (2006)
A tutorial survey on vehicular ad hoc networks (2008)
Support of Anonymity in VANETs - Putting Pseudonymity into Practice (2007)
Towards a security architecture for vehicular ad hoc networks (2006)
Anonymity Analysis on Social Spot Based Pseudonym Changing for Location Privacy in VANETs (2011)
A Robust Conditional Privacy-Preserving Authentication Protocol in VANET (2009)

Also, the sevecom project and the preserve project just some examples of projects that work on this topic. In the US, pseudonyms have been standardized by IEEE 1609.2.

In other words, the claim that no-one works on it is bullcrap. Is it still bad for privacy? Maybe. With the right choices, we can build a secure and privacy-preserving system that is a lot safer than what we see on the road now. Recall the discussion on vaccination from yesterday? There, the /. hivemind tells us how the good of the community comes first if my right to choose harms others. This is the same here. Your privacy is important, and we try to protect it, but if there's a small decrease in privacy for a huge gain in safety, then you're out of luck.

Everyone is working on this. This article blatantly contradicts a decade of VANET research. Even the car industry is involved in providing privacy-preserving protocols of all kinds. Here is a sample of papers covering this topic:
Privacy and identity management for vehicular communication systems: a position paper (2006)
A tutorial survey on vehicular ad hoc networks (2008)
Support of Anonymity in VANETs - Putting Pseudonymity into Practice (2007)
Towards a security architecture for vehicular ad hoc networks (2006)
Anonymity Analysis on Social Spot Based Pseudonym Changing for Location Privacy in VANETs (2011)
A Robust Conditional Privacy-Preserving Authentication Protocol in VANET (2009)

Also, the sevecom project and the preserve project just some examples of projects that work on this topic. In the US, pseudonyms have been standardized by IEEE 1609.2.

In other words, the claim that no-one works on it is bullcrap. Is it still bad for privacy? Maybe. With the right choices, we can build a secure and privacy-preserving system that is a lot safer than what we see on the road now. Recall the discussion on vaccination from yesterday? There, the /. hivemind tells us how the good of the community comes first if my right to choose harms others. This is the same here. Your privacy is important, and we try to protect it, but if there's a small decrease in privacy for a huge gain in safety, then you're out of luck.

Everyone is working on this. This article blatantly contradicts a decade of VANET research. Even the car industry is involved in providing privacy-preserving protocols of all kinds. Here is a sample of papers covering this topic:
Privacy and identity management for vehicular communication systems: a position paper (2006)
A tutorial survey on vehicular ad hoc networks (2008)
Support of Anonymity in VANETs - Putting Pseudonymity into Practice (2007)
Towards a security architecture for vehicular ad hoc networks (2006)
Anonymity Analysis on Social Spot Based Pseudonym Changing for Location Privacy in VANETs (2011)
A Robust Conditional Privacy-Preserving Authentication Protocol in VANET (2009)

Also, the sevecom project and the preserve project just some examples of projects that work on this topic. In the US, pseudonyms have been standardized by IEEE 1609.2.

In other words, the claim that no-one works on it is bullcrap. Is it still bad for privacy? Maybe. With the right choices, we can build a secure and privacy-preserving system that is a lot safer than what we see on the road now. Recall the discussion on vaccination from yesterday? There, the /. hivemind tells us how the good of the community comes first if my right to choose harms others. This is the same here. Your privacy is important, and we try to protect it, but if there's a small decrease in privacy for a huge gain in safety, then you're out of luck.

You're assuming perfect distribution of MAC-48 AKA EUI-48 addresses among manufacturers and their products, which is far away from true. 1/2 of the 48 bits here are assigned to a manufacturer. 24 bits there make about 16M unique addresses available to each manufactured device. The flip side to that is that every manufactured device gobbles up 16M addresses, whether they use them all or not. Every time someone releases a new device assigned its own NIC address, another 16M addresses die, even if they only sell 1 of them.

That means the important part then is that there are only ~16M Organizationally Unique Identifier (OUI) blocks, the other 24 bits here. Those are getting consumed at some rate, bigger manufacturers will need more than one of them, and therefore want to ask for a larger block of them. The IEEE is already aiming to reclaim them after 100 years and otherwise tightening standards for keeping companies from getting more OUI "space" than they need. As they state there, "The total number of EUI-48 identifiers available, while large, is NOT inexhaustible.". It's similar to the situation with IPv4 addresses, where the capacity looked practically infinite at first, but waste forced the size of the average block allocations down hard over time to keep from running out. Now you have to use 95% of the addresses you've already got before you can get more OUIs.

MAC addresses have started to move from 48 bits to 64 in order to make this problem go away, because then you're at a "atoms in the universe" scale. I believe that's going about as well as the IPv6 migration. We're a long time from the 48 bits running out, but it's not as impossible as you might think just from computing against 2^48.

they're patenting a specific method of doing so.

There is nothing specific about the methods they're patenting. I just worked on a very similar project, and after reading the patent, I see very little separating what they patented from what we did. Indeed we don't use dimensionality reduction the way they suggest (although we did use it for a while), and we don't provide specific names for the objects we discover (though we have talked about doing so via crowdsourcing). Indeed our work is more recent than the patent filing, but people have been attempting similar things for ages (e.g. [1], [2]...they are very easy to find). Worse, the two papers I cite provide enough detail to actually produce a working system, whereas the patent provides little detail beyond a few references to well-known machine learning and computer vision techniques. And even when they suggest methodology, it's always "maybe we'll use this, maybe not", and further they tend to list several potential methods without any indication that they've researched which ones work.

You remember correctly, people have been doing this for years. I have no idea why TFA calls this "world first bionic eye", perhaps there is something new about their particular method, although it doesn't sound very impressive compared to other options.

Here is a list of some companies producing retinal implants (incl. Bionic Vision from TFA): http://www.upgradeyourbody.com/catalog/bionics/eyes/ At least some of those are already past clinical trials and available commercially.

The latest, greatest breakthrough:
Scientists reverse engineer eye-brain signaling, enabling next generation of implants

More links on retinal implants:
Wikipedia - Retinal implant
1000-electrode implant developed in Stanford
Long-term trials started in Oxford in 2010
Phase II trials of 1500-electrode implant by Retina Implant AG (2011)
Argus II implant goes to market
Bio-Retina 576-pixel implant to start trials in 2013

There's an article in this month's IEEE Spectrum about the Air Force pursuing the idea of "plug-and-play" satellites;

http://spectrum.ieee.org/aerospace/satellites/us-air-forces-plugandplay-satellites

Note that RBSP is engineered to function to a region which most spacecraft avoid or pass through only briefly. There's a lot that's different in the design of these craft relative to a typical LEO satellite.

BTW, launch video is available here;

http://www.youtube.com/watch?v=9mlaQothGWA

"Or there's always the angry Martians hypothesis."

Fear not, for the battle continues, but know, o ye Citizens, how far we have fallen. Back in my day, when I was but a podling barely capable of any form of speech, let alone speaking on behalf of my fellow podmates, "twenty seconds to comply" wasn't just a good idea, it was the law.

When a retired news reporter suggested that maybe the Blue World had temporarily overestimated its engineering capabilities and had compounded this miscalculation by dropping the primitive contraption into a middle of an electrically-active dust storm, the Speaker's podseniors had the retired reporter's gelsacs affixed to his belt, which was the fashion at the time.

When it comes to SSD's I was talking solid state, which can be attached via FC on the z, but the performance is nowhere near what can be achieved with something like the fusionIO PCIe based adapters.

So how about attaching them to the z with a fusionIO PCIe-based adapter? "Overview of IBM zEnterprise 196 I/O subsystem with focus on new PCI Express infrastructure" says that PCIe adapters can be directly attached. Perhaps there are no z/OS drivers for them, but Linux drivers might exist. You can't directly memory-map PCI devices - special instructions are required - but, at least as I remember from my NetApp days, on Alpha you couldn't necessarily make the same sort of direct references to PCI space that you could on x86, so Linux might provide kernel APIs for accessing PCI space rather than having drivers directly make memory-mapped accesses to registers, so those instructions could be put behind those APIs on the z/Architecture port.

(I.e., in that particular case, it's probably a software issue, not a hardware issue.)

and 64 bit doesn't automatically take 2x the footprint

Are you referring to instruction density, or to data structure density with 64-bit pointers?

unlike Intel, who still can't get it right.

Actually, that's actually AMD's fault, if you're complaining about the x86-64 architecture (unless you blame Intel for not having done a better job than AMD).

Intel's stuff is also microcoded and implemented as RISC under the covers.

Yup, the whole "translate the "complicated" instructions to microops and schedule and run the microops independently" stuff is also being done in the z196 and, presumably, its zEC12 successors. As IBM zEnterprise 196 microprocessor and cache subsystem (not available for free) says:

In the z196 microprocessor, the traditional System z CISC (RX) pipelines are split into multiple shorter latency reduced-instruction-set computing (RISC)-like execution units, and the complex z/Architecture* instructions are cracked into RISC-like microoperations.

("RX" means "memory-to-register or register-to-memory instructions" - they include loads and stores, but also include memory-to-register arithmetic instructions).

In modern x86 processors (dating back at least as far as the Pentium Pro), most instructions are, as far as I know, directly implemented in hardwired logic (or translated into microops that are directly implemented in hardwired logic).

So, at the fetch/decode/execute level, a Shiny New Core i{3,5,7} and a Shiny New zEC12 are rather similar - directly executing register-to-register ops in one clock tick, carving register-to-memory/memory-to-register instructions into microops and directly executing each microop in, I suspect, one clock tick (modulo waiting for memory in the load or store microops), and executing multiple microops in parallel, out of order, register renaming, blah blah blah. The more complicated instructions might be implemented in Shiny New x86 processors by jumping to microcode (which I suspect is made out of microops in Pentium Pro and later) and in Shiny New z/Architecture processors by a fast trap to millicode (which is z/Architecture code + some special millcode-mode-only instructions - think "PALcode"), but even that's not a huge difference.

I.e., yes, the person to whom you're replying is very mistaken. Current z/Architecture machines (and at least the CMOS S/390's) don't interpret the instruction set in microcode, with the clock rate being the speed at which microinstructions are run, with several microinstructions being required for every instruction; I'd say "the clock rate is the instruction rate", except that the processors are superscalar, so more than one instruction could be processed in a single clock tick.

No, that's not a correct supposition -- quite the opposite, actually. All processors, including Intel X86, use microcode (or what IBM calls millicode) to a degree.

At least from what I've read about the past few generations of S/3x0 chips, millicode is more like PALcode on the Alpha processor than like traditional microcode, i.e. it's a combination of regular machine code and processor-specific instructions that access specialized registers etc., running in a special processor mode with (presumably) fast entry and exit, support for said processor-specific instructions (which presumably trap in either both "problem state", i.e. user mode, and "supervisor state", i.e. kernel mode), and its own bank of general-purpose registers (part of the "fast entry and exit"). Instructions implemented in millicode trap to millicode routines that implement them.

What IBM called "microcode" rather than "millicode" was implemented using processor-specific instructions completely different from the machine's instruction set (instructions often having fields that directly controlled gates).

(And then there's System/38 and the pre-PowerPC AS/400, where the processor instruction set was a CISC instruction set implemented using microcode, and where the compilers available to customers generated code in an extremely CISCy instruction set that the low levels of the OS translated into machine code and ran. For legal reasons - they didn't want to have to be required to make the low-level OS code available to "plug-compatible manufacturers", i.e. cloners - they not only called the microcode that implemented the processor instruction set "microcode" ("horizontal microcode", as it probably was "fields directly control gates"-style horizontal microcode), they also called the aforementioned low level OS code "microcode" as well, even though it ran from main memory and its instruction set was the instruction set that was actually executed in application code ("vertical microcode"), and had the group working on that code report to a manager in the hardware group. See Frank Soltis's Inside the AS/400.)

IBM knows it well. After all, they invented microcode/millicode in the System/360 in 1965.

"Invented", no; the paper generally considered to have introduced the concept was "Microprogramming and the Design of the Control Circuits in an Electronic Digital Computer", by Maurice Wilkes and J. B. Stringer, from 1953. S/360 may have been the first line of computers to use microcode in most of the processors (S/360 Model 75 was, I think, implemented completely in hardwired logic).

Very cutting edge -- so cutting edge I've got to crack open some engineering manuals to try to figure out what they've done, although they probably need to write those manuals.

Well, for the previous generation, there's Volume 56, Issue 1.2 of the IBM Journal of Research and Development has some papers on the z196, but, alas, not for free online. They may publish an issue on the zEC12 at some point.

The urban legend (unproven AFAIK) was that Gary Kildall used that stunt to prove that Microsoft ripped of CP/M. From an article in Spectrum:

In 2006, science fiction writer and technology reporter Jerry Pournelle said on “This Week in Tech,” an Internet radio show, that this secret command triggered the display of a copyright notice for DRI and Kildall’s full name. According to Pournelle, Kildall had demonstrated this command to him by typing it into DOS; it produced the notice and thus proved that DOS was copied from CP/M.

This story, circulated for years, has a few problems. First, no one knows the secret command; Pournelle claims he wrote the command down but has never shown it to anyone. In addition, such a message would be easily seen by opening the binary files in a simple text editor unless the message was encrypted. CP/M had to fit on a floppy disk that held only 160 kilobytes; Kildall’s achievement was squeezing an entire operating system into such a small footprint. But it is difficult to imagine he could do this and also squeeze in an undetectable encryption routine. And although we’re now in an era of hackers breaking into heavily secured computers, no one has ever cracked DOS to find this secret command.

But I set out to look for it anyway. I used a utility program developed at SAFE to extract strings of text from binary files. Not only did Kildall’s name not show up in any QDOS or MS-DOS text strings, it did not show up in CP/M either. The term “Digital Research” did appear in copyright notices in the CP/M binary files, but not in MS-DOS or QDOS binary files.

If Jerry Pournelle did indeed see a hidden message revealed by a secret command, it was not in MS-DOS.

s/Pentium/Ivy Bridge

(...though it's not the first chip to have a hardware RNG.)

I hope NASA does the right thing and releases the fellow's name.

While I always love to hear stories where MIT students are the heroes, I find this story a little odd. The lunar-swingby return trajectory was always the abort option. So I'm not sure what this article is implying-- a MIT student said "say, why doesn't NASA implement their backup plan?" and Gene Kranz said "the backup plan! That's it! We never would have thought of that!" ?

With that said, it's worth noting that Apollo 13 had already modified their path from the initial free-return trajectory to one that required an engine burn to put them on the lunar-swingby return, in order to target the desired landing site. The important decision wasn't whether to make a burn to do the return; the real question was which engine to use, since it was not known (at the time) whether the explosion had damaged the main engine on the service module (turns out it had; and they made the right choice.)

It was, of course, actually more complicated than that. IEEE Spectrum has a more detailed timeline and analysis: http://spectrum.ieee.org/aerospace/space-flight/apollo-13-we-have-a-solution-part-2

Never seen the time !! Does anybody really know what time it is ?? Does anybody really care ?? Know what time ??

If you'd have clicked through to the article, you'd see the whole timeline. Though I'm not sure why you were modded down as a troll, it's a valid question and it seems that many news sources only say "late Sunday night" without giving any times. in any case:

The landing stage separates from the cruise stage at 10:14:34pm PST.

Here's the last few seconds of the timeline (again, see the linked article for the full timeline):

10:31:08 PM: At about 20 meters above the surface, MSL keeps decelerating down to 0.75 m/s.
10:31:14 PM: Less than 20 meters from the surface, the sky crane shuts off four of its eight engines as the rover separates and begins to descend on cables.
10:31:15 PM: MSL releases its "bogie" wheels, getting ready for touchdown.
10:31:30 PM: TOUCHDOWN! WOOHOO!!! Curiosity knows when she's on the ground when the load on the tether that she used to get from the skycrane to the ground goes slack.
10:31:33 PM: Cables connecting Curiosity to the skycrane are cut, and the skycrane flies off for a crash landing. /quote>

I just watched the related videos, and it is impressive just what an up and down tail can do. But you're right that a tail that can move side-to-side, or that can curl or corkscrew can probably do even more to maintain a desired 3D orientation. No doubt that will be future directions for this work. So, in the real world, it seems like a common situation that you want to maintain the orientation of 90% of the mass of an object, and are willing to sacrifice the 3D orientation of 10% for a short time to do that (until the tail orientation can be reset at no body-orientation cost when the creature is on a surface again). Brilliant. These robot videos really show how amazing nature can be. I really appreciate tails in a way I never had before watching those videos. I especially found of interest video about a predecessor robot to this which includes video footage of the long-tailed lizard used as a prototype:
http://spectrum.ieee.org/automaton/robotics/diy/dinosaurlike-tails-make-terrestrial-mobile-robots-more-agile

SAIC used to pretty much OWN the FBI's data center contracts. They are pretty much gone now, and Lockheed-Martin now runs the show out at Clarksburg, WV. . .

Why do you even bother with the "all parties are corrupt, except mine" argument ?

When it comes to doling out subsidies, AGW is responsible for so many subsidies that it is actually part of the reason Spain's economy broke. Do you honestly believe that with those amounts of money involved, there is any chance of avoiding corruption ? Isn't IEEE peer-reviewed btw ?.

http://slashdot.org/story/06/07/13/0822206/darpas-cortically-coupled-computer-vision-system

http://spectrum.ieee.org/biomedical/imaging/a-brainy-approach-to-image-sorting

Posted wrong link - intel-3d-transistors

This is an ominous sign of things to come. Intel already has significant advantages in the foundry business. These could be leveraged further to give its x86 chips a boost vis-a-vis ARM. The other players need to pull their act together & pool resources to counter this. If there is no level-playing field because the foundries can't keep up we could well be facing an x86 monopoly in the low-power chip market too.

Your little brain freeze notwithstanding, that was an exemplary summary of a complex report. The mea culpa is also appreciated.

For those who want to read a little more, there's a very good article over at Ars Technica, which in turn links to the full English report from the Japanese parliamentary inquiry as well as an IEEE Spectrum account of the immediate aftermath.

Yep, see for example Nonintrusive appliance load monitoring. It's possible to identify common appliances reasonably well using the size of changes to power consumption and, depending on the smart meter hardware used, the shape of the power-usage curve (e.g. the brief initial surge when turning on compact fluorescents). It's not perfect but it's not too bad and it's getting more accurate.

Not sure where you've worked, but I've yet to find any H1Bs in tech living anything like you're describing. Okay, so during his (and my) first year at my old job, my H1B co-worker and I rented a four bedroom apartment together. So that's kind of close, although he later married and bought a house. It only has a small lawn, so he mostly has to stick to around the deck or BBQ and sadly look over Puget Sound, thinking of how unfortunate he is.
 
The other H1Bs included the guy with the brand new 3-series living in a fancy glass and steel downtown condo, and the guy with the Range Rover who had restrained but expensive tastes. The other H1B in my group was rather stoic so perhaps he lived with 5 other H1Bs in an apartment, although it'd be weird since his salary was well into six figures and a decent studio in the most expensive parts of the city were ~$1000/month with parking.
 
Yes, H1Bs can be paid on the low end of the scale since they're at a major disadvantage if they're unhappy with their job. But it's not a huge difference, it's just that corporations would be happy to sell out their own country for a penny. In fact, because I went front-end and my ex-roommate went server-side, he was making more than me within 3-4 years on the job.
 
That said, there is very little need for H1Bs in terms of supply and demand as was pointed out in this recently posted transcript, and it'd be nice if lawmakers and other people involved in immigration policy recognized this fact.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6059486 PDF for those with no IEEE access: http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=2062936&fileOId=2339120 The short version: nothing new here and equivalence to traditional multiple-antenna methods, with same bandwidth limitations; move along.