I recently put together such a lab in a room in my office space.

Electronic equipment depends completely on what kind of work you're doing: digital, analog, high-speed, low-signal, RF, etc. So it's hard to answer that question.

Pretty much everything, however, needs some basics: ESD protection, furniture, lighting, storage.

ESD protection: Install a conductive tile floor. Most vendors for this stuff prefer to work on whole buildings; finding someone to do a single room took a bit of looking. I ended up buying the tiles myself (from StaticWorx, from their odd lots selection at about $3/sqft) and hiring one of the big company's installers to moonlight over a weekend.

Other folks have talked about grounding. It's just as important as they say. Most electricians who do commercial work will understand how to get this right.

Furniture: Get one or two heavy duty lab benches with anti-static surfaces and shelves above the bench. It's a little detail, but I recommend bullnose fronts instead of square, to make chipping and other damage less likely. Benches should be 36" deep if you have the room, so you can have relatively deep equipment on the bench and still have room to work in front of it.

You should be able to get behind the bench to fuss with cabling and such (and to vacuum... dust accumulates like nobodys business if you have your test equipment pushed all the way back to the wall behind it).

I have a couple of anti-static lab chairs: conductive fabric, little chain to connect to the anti-static floor.

I also have a big folding table that I unfold when I need to lay out a bunch of stuff and reorganize it.

Lighting: This is really important. You can't have too much. I have a bunch of 4-bulb T-8 fluorescent fixtures on the ceiling (in several groups with different switches, so it doesn't have to be that bright all the time).

I also have a big magnifying lamp, and a big stereo microscope, although I'm still looking for a good solution for lighting on the microscope.

Storage: I have a bunch of little drawer cabinets. Most aren't anti-static, so I have a lot of stuff in conductive foam. It's a trede-off: anti-static is safe, but it's opaque, but clear drawers are a lot easier to work with (and cheaper). A lot of stuff (machine screws, switches, resistors) doesn't need anti-static.

I also have a bunch of open shelves filled with Akro-Mils plastic bins. These are great for storing miscellaneous stuff like multimeters, tools, small project pieces, larger components, etc. They come in many colors, which I've never figured out how to use effectively as an organizing scheme. I try to keep everything loose in one of these bins so it's easy to put a bunch of bins on the shelf to make room fo a project.

I do a fair amount of work with surface-mount devices, and I struggled with how to store them. It's a nuisance to handle the devices in cut tape form: the tape is bulky and springy and clumsy, and it's a pain to get devices out of it one at a time. Once extracted, the devices are way too small to make effective use of drawer cabinets: it's like storing grains of sand. But then I found these nice little (conductive) aluminum canisters at American Science & Surplus, and they're great: about an inch in diameter, glass window in lid, and stored 20 to small aluminum box the size of a small book. I now have a bunch of those "books".

Multimeters: Someone suggested getting a bunch of cheap multimeters; this is a great idea. $5/each from Harbor Freight (or free sometimes with a coupon). An extra cheap oscillosope isn't a bad idea, either--an old Tek 465 is cheap on eBay and very quick to use.

Lots of power outlets: I ended up bolting a ton of cheap power strips all over the benches, because there are so many things that need power. And because so many of them use power bricks, it's important to have plenty of access around the power strips--they can't be mounted under a shelf or in a corner.

Lots of USB: I also mounted a lot of easily accessible USB hubs (and some Ethernet) to accommodate the many devices that connect by one or the other. I really don't like crawlng around to mess with cables.

Articulated monitor mounts: Most of the time, I don't need to interact with the computer. It's nice to be abe to push the monitor(s) out of the way (and hang the keyboard/mouse out of the way, too)

Clearly, someone must have paid for this charming little legislative tidbit. But who?

I mean, I could understand if Lockheed-Martin had a proprietary solution that they were offering (with just a few change orders needed to satisfy NSA's requirements, of course), but the beneficiaries here seem to be the Cassandra and HBase projects, neither of which seem likely to have much of a lobbying budget. Was it their forebears at Facebook? Could they possibly care enough?

And blaming it on "conservatives-want-smaller-government" seems pretty silly, too. Sure, turfing Accumulo might conceivably further that goal in some tiny, tiny way, but it's not like some senator was likely to have figured this out by himself. No, clearly someone put them on to it, but who and why?

It's an intriguing mystery. Any ideas?

I mean, what a great opportunity for malware distribution, sabotage, spying, etc... Just connect to every "Linksys" router you can find and "upgrade" its firmware yourself! (change them all to DD-WRT, maybe?).

Since experience tells us that mechanisms like this are rarely, if ever, properly secured, this seems like a major security catastrophe in addition to a privacy debacle. Even if sound cryptography and digital signatures are employed to make sure the updates are valid, there may be implementation flaws in the routers, vulnerabilities in Cisco's upgrade servers, key leakage, bad protocol design, etc.

Wow.

Be interesting to know how this feature is "secured", too. How hard would it be for J. Random BadGuy to connect to my FIOS router and replace its firmware?

What enables Cisco to DO remote management? And what ensures that no other entity in the world can remotely "manage" my router in the same fashion?

What a great avenue this could be for malware distribution, intelligence collection, massive denial of service, etc. Be pretty cool for bad guys (or LE or TLAs) to be able to replace the firmware in millions of routers unbeknownst to their owners.

Does anyone here know how Cisco's remote management interface is "secured"? Even if there's sound cryptography involved, there's always router software flaws, bad key generation, vulnerabilities in Cisco's upgrade servers, poor operational security at Cisco, and other avenues to attack the overall system. And of course the cryptography itself might be unsound, too... usually takes folks a couple tries to get that right.

Wow.

Better and cheaper isn't necessarily a direct route to success.

Structural monopolies often have extensive mechanisms in place to deter competition. For example, look at the Nest Thermostat. It sure is better, and it's not even cheaper, yet the comfortable incumbent (Honeywell) is trying to sue it out of existence. I hope Next succeeds, but it seems likely that their legal costs will be substantial.

It's even worse in the medical field, where comfortable relationships between device manufacturers and medical personnel (oh, no, that conference wasn't a bribe, it was a valuable educational opportunity) are an incredible barrier to competition. This is balanced to some extent by the enormous egos of many medical professionals (surgeons, anyone?) that has led to disruptive medical device innovation, but on the whole, the field has a lot of structural resistance to change, and it takes a lot of sunshine to eliminate such practices.

1) And the reason that hearing aids can't use 3V lithium battery technology is? Seem like there might be some benefit there, especially in view of the impressively low-power things that can be done with small-geometry silicon when speed isn't the main issue.

2) This is a meaningful cost. A library of semi-custom versions might be a plausible intermediate step. As might laser scanning and 3-D printing.

3) Why can't analysis of the loss can be completely automated? "Press + if this sound is louder than the last one"

4) Flex PCBs (even when each one is fully custom) and 0105 components seem like a plausible solution. Automated assembly has come a long way since the invention of 32 gauge wire. Open your iPhone and count the grains of sand (resistors and capacitors) soldered to the PCB. Sure, they've always done it by hand with microscopes, but while that was a sensible approach 30 years ago, there are better approaches now.

5) This is a meaningful cost, too. But again, there's a lot of "tuning" that could be done by interaction with an automated system.

6) This is a meaningful cost. No obvious way to mitigate it, given the elderly user communicate it.

7) This isn't a cost, it's just a complaint that modern electronics isn't in the picture.

What I hear is "this is the way we've always done it, and we can't imagine a non-evolutionary approach to improvement". Is it really possible that a 3V supply (which would allow use of a $5 2mm^2 32nm-process DSP) would be the kind of disruptive change that would make hearing aids cheap enough for everyone?

Probably not, because the economic argument is unimpeachable: as long as insurance pays for it, and thus eliminates price pressure, there's no motivation to charge much less (10% off for cash, yeah, what a deal). This isn't even value-based pricing (think Mac Pro :-) ), it's structural monopoly pricing. As long as that's in the picture, there's no hope for a transition to cost-based pricing.

Actually, the U.S. does have a DoD-funded secure fabrication capability: see the Trusted Foundry program.

This is a physical-access backdoor. You have to have your hands on the hardware to be able to use JTAG. It's not a "remote kill switch" driven by a magic data trigger, it's a mechanism that requires use of a special connector on the circuit board to connect to a dedicated JTAG port that is simply neither used nor accessible in anything resembling normal operation.

That said, it's still pretty bad, because hardware does occasionally end up in the hands of unfriendlies (e.g., crashed drones). FPGAs like these are often used to run classified software radio algorithms with anti-jam and anti-interception goals, or to run classified cryptographic algorithms. If those algorithms can be extracted from otherwise-dead and disassembled equipment, that would be bad--the manufacturer's claim that the FPGA bitstream can't be extracted might be part of the system's security certification assumptions. If that claim is false, and no other counter-measures are place, that could be pretty bad.

Surreptitiously modifying a system in place through the JTAG port is possible, but less of a threat: the adversary would have to get access to the system and then return it without anyone noticing. Also, a backdoor inserted that way would have to co-exist peacefully with all the other functions of the FPGA, a significant challenge both from an intellectual standpoint and from a size/timing standpoint--the FPGA may just not have enough spare capacity or spare cycles. They tend to be packed pretty full, 'coz they're expensive and you want to use all the capacity you have available to do clever stuff.

Attributed to Albert Einstein, the full quotation sometimes reads “If you can't explain it simply, you don't understand it well enough yourself". He was a smart dude.

The most useful type of documentation is about intent and goals: WHY does the software have these interfaces, what are they supposed to accomplish, what is the overall model of operation, etc. That, I think, is where the best bugs are found. If the model isn't complete, then the code won't be. And that kind of documentation isn't bulky or repetitive--it has a very high return on effort. It's also useful to have documentation that explains particularly clever or complicated implementations.

Less useful is documentation that can easily be inferred from the code. Writing API documentation by hand is tedious and unproductive. If the API and its parameters use well-chosen names there's not a lot to add--and using something like Doxygen makes it easy to include a few hints where they are needed. But Doxygen isn't the place to explain the architecture or system model--that should be thought out first, not stapled into API comments here and there.

Many times I've found bugs by explaining to someone how a system is supposed to work. Doesn't have to be someone who knows much about it, occasionally it's even been my dog. High-level documentation is just another way to exercise that technique, with the advantage that the explanation itself can be reused.

The current DARPA leadership (and to a significant extent, the rest of DoD) is strongly supporting an open source world. This stuff they're doing with Advanced Vehicle Make, it's open. It's being made available for free. To everyone. And in particular to a whole generation of public school students. It's not going to end up as an expensive product that no one uses, or buried forever somewhere inside Lockheed-Martin. The fact that it's notionally about being a better way to build tanks is an excuse, not a motivation, for the people working on it. And this spirit--like that which built the original ARPAnet--is being pushed throughout the organization.

Yes, it's funded by the military. And yes, I'm sure that an omniscient five-year planner like AC could figure out a more optimal way to improve humanity by reallocating a lot of those research dollars to happier pursuits. But it's not like taking away those dollars would automatically put them somewhere more "worthy". And until AC is in charge, well, DARPA is a place where I'm really proud to see my taxpayer dollars going.

I'm sad that Mitch doesn't want to be associated with this effort, but from where I sit, it's doing a lot more good than harm. As opposed, say, to the Chinese Communist Party.

That's a big number. Sounds pretty serious, compared to $38bn in annual revenues.

Except that 3/4 of it is the $12.5bn purchase of Motorola Mobility, an operating business with products, sales, revenue, etc., not to mention a valuable IP portfolio and a big pending tax benefit. If there's one thing that purchase isn't, it's an "R&D Expense".

A total of $3.9bn in as-yet-unsuccessful multi-year R&D projects doesn't look so bad compared to Google' other numbers. What's that, $1-2bn/year? And some of those other projects aren't exactly R&D, like the $1.9bn investment in Atlantic Wind Connection, which is also clearly a business with a plan toward generating revenue. AWC may not succeed with that plan, but it's not R&D.

The Internet Evolution authors are intellectually dishonest frauds. They have mischaracterized their largest numbers in order to make a point that is not supported by evidence.

And, actually, the total of the projects the article lists is $16.9bn, not $16.4bn (making the non-Motorola total $4.4bn, not $3.9bn, which is still completely reasonable), so they apparently can't do simple arithmetic, either.

I've certainly been disappointed by some of Google's apparent mis-handling of R&D projects, and I'd like to believe that they are learning to do better over time, but even if they were having this rate of failed projects, it would be a pretty reasonable price to pay for a self-driving car. Imagine they get trivial revenue as a technology supplier / licensor (say $100/vehicle). In a world market of 50 million vehicles, that's $5bn/year. Not too shabby. And some of those other R&D projects might pan out, too.

By coincidence, this very week I am re-reading E.E. "Doc" Smith's Skylark series. Sure, it's a period piece, when men were men, strong-willed and lantern-jawed and inconceivably brilliant, but it's always a lot of fun and a great nostalgia trip. I'd love to read the original versions sometime, to see how the "science" evolved.

I am equally fond of his Lensmen series, although the first one is little disconnected (as it should be, since it wasn't written for that universe) and "Masters of the Vortex" was amusing but essentially unrelated. I was delighted that my daughter (age 16) loved them, too.

And where else but in Doc Smith (Spacehounds of IPC) can you find a shipwrecked hero who can singlehandedly construct a hydroeelectric power plant, smelting his own copper and steel(!)?

Another favorite of mine is George O. Smith, particularly his The Brain Machine novel and the Venus Equilateral stories. The Brain Machine is a child-prodigy story; if you enjoyed Orson Scott Card's Ender's Game, then The Brain Machine will likely reach you, too.

And I'd wholeheartedly recommend Cordwainer Smith as well. Wish he'd written more.

In the non-Smith category, there's always Michaelmas by Algis Budrys: a great story for those who like Walter Cronkite or self-aware computers that emerge to make the world a better place. His work covered a lot of other topics as well; I liked some more than others, but Michaelmas is my favorite.

I used to have a lot of Science Fiction Book Club anthologies, and they contain some gems (as well as some dross). Anthony Boucher's Treasury of Great Science Fiction and Asimov's Before the Golden Age are two of my favorites.

I have to imagine that not everyone in TSA management is a congenital idiot, and that some of them probably realize how silly the no-liquids rule is. But they also probably realize that they can't just abandon it without being accused of being "soft on crime" and various other silly problems, any of which might lead to the ultimate catastrophe: losing that coveted GS-99 civil service position and lucrative pension.

So what's a non-idiot to do? Simple: adopt a "new technology" that pretty much always blinks green when something gets put in its little hole, and blinks red occasionally just to pretend it actually accomplishes something. Such a device could easily scan a zip-lock bag containing a collection of liquids, and with further improvements could be integrated into the original X-ray apparatus so that it scans bags, too. For historical accuracy, it can claim to use N-rays.

As it happens, we already have liquid scanners just like this, although they are not heavily used. I accidentally tried to carry bottled water through the checkpoint X-ray at DCA 18 months ago, and after the goon squad got over the excitement, they explained that they'd have to dispose of it for me, but that first they would put it through a magic scanner (a suitcase-sized box with a cylindrical cavity and some buttons and lights) to be sure it was safe. To pass the time while being lectured, I asked if they would do something different to dispose of it were the scanner to say it was dangerous, and the responding goon assured me (with no trace of irony) that no, it all went in the same bin.

I have probably taken 300 flights since the "liquid explosive" scare. Since 2008, when I realized that the whole thing was ridiculous, I have never put my liquids into a quart-size baggie, nor have I taken them out for individual passage through the X-ray. In that time, I have been forced to give up my toothpaste in furtherance of the nation's security precisely twice. It's a small price to pay--a few bucks worth of toothpaste and a pious lecture about how dangerous the toothpaste might be, in exchange for significantly less hassle at the checkpoint. I have to imagine that the reason my approach works is that they really don't try very hard to find contraband of this sort. If I were a proper activist, I suppose I'd be willing to wear a "Toothpaste Smuggler" button when I fly, but I lack the courage.

Maybe they'll figure out that they can do this for other stuff, too. I must say that the full-body scanners are a major step backwards, since I can't even keep my passport and ticket in my pockets any more.

It seems possible that the Defense Department is researching this technology not just for economic savings. If technology like this existed, it could be used, for example, to remove a nifty new imaging sensor or radar component from someone else's satellite, or maybe to add a device that connects to that satellite's internal data bus (operation Ivy Bells, anyone?) and taps or modifies the data.

Most satellites have essentially no situational awareness, because being taken apart by little aliens in shiny green spacesuits (or by advanced remanufacturing robots) is just not part of the threat model. So it tends to be very hard for ground control to distinguish between a random equipment failure and a failure caused by deliberate modification of the spacecraft.

This mission probably isn't what the X-37 is for, since it's a low earth orbit vehicle, not geosynchronous.