Batteries for grid storage have different properties than batteries for cars.
So grid storage tends to use different battery technologies than vehicles.
This is Yet Another Crap Extruder based printer. That whole class of machines sort of works on good days. None of them Just Work.
The fundamental problem is that they're welding a hot thing to a cold thing. That sucks for metal welding, it sucks for soldering, and it sucks for plastic welding. It's how you get bad welds, cold solder joints, and fractures in 3D printing. The heated build plate systems usually start a build OK, but a few cm from the build plate, that heat source isn't close enough to help much. So many taller builds fail around 2-5 cm.
For this process to work, it needs better temperature control. A heated build chamber (that's patented). A hot air jet or small laser aimed at the target just before the weld (larger plastic welders do this). But nobody seems to be doing that. They just keep coming up with variations in the 3-axis motion mechanism (not hard to get right) and the software (not really the problem). Or they add DRM and overcharge for "print cartridges".
Here's the programming manual for FIRST robotics competitions. This is not dumbed down.
It turns out that large pad + IV + crypto-secure hash...
Did this guy just reinvent a book cypher?
It's just 70 gallons of crude oil left in an unused pipeline. No fire. No explosion. Just a mess.
It's not like a few years ago, when a high pressure gas pipeline exploded in Daly City and took out a small subdivision. Now that was a serious problem and an indication of a worse one. The column of smoke was visible 20 miles away. The state of California made PG&E do hydrostatic testing on all their major gas pipelines, over PG&E's claims that it was unnecessary. During hydrostatic testing with water, there were two pipeline bursts. One caused a landslide that blocked parts of I-280 at Woodside CA. No fire, of course; just water and mud, since this happened during testing.
OK, first bypass the click troll and get to the actual paper.
The general idea seems to be to transmit a large amount of noisy data per plaintext bit. Historically, crypto schemes which make the input much bigger are disfavored, but communications bandwidth is cheaper now and that might be OK.
The author of the paper seems to have fallen into the old trap of thinking that that analog signals have infinite amounts of data in them. He writes things like ''The encrypting key space is unbounded." and "The choice of the form of coupling functions comes from a set of functions that is not bounded." ("High-end" audio people also fall for this.) In reality, at some point you hit a noise threshold, and, anyway, down at the bottom, electrons and photons are discrite. Also, to be usable, whatever is used for the key has to be of finite size, and preferably not too big.
"No new cypher is worth looking at unless it comes from someone who has already broken a very hard one. - Friedman.
That looks like library code that the compiler generated. Maybe some kind of strcpy variant.
Read the analysis of the code. It's not. It is, however, decompiled assembly code; the people doing the analysis don't have access to the source.
What you have to keep in mind is that this software was written for Windows 98.
Irrelevant. This code is vulnerable on any OS that lets it get UDP packets.
We don't have enough context to know.
Read the actual vulnerability report. There's enough context there.
The real morons are the ones who tried to network it, presumably against Yokogawa's recommendations.
You have to assume today that if it has an Internet-accessable interface, an attacker will find a way to get to it from the public Internet. Because, in practice, attackers do.
Google already has several TV interface devices on the market. There's Google Chromecast, of course. Google also sells a set top-box used with Google Fiber That also comes with the Google Storage Box, which is a 2TB file server for storing downloaded content. There's the old Google TV, which is mostly Android software inside.
So Google has this covered already. They have a device for viewing TV over the Internet, and they have a cable box for their cable system. They're probably going to tweak the UI on one of those and promote that as a new product.
Neither Google nor Facebook has ever successfully built a product users will actually pay for. (Google's Nexus phones are rebranded LG, Samsung, and Asus products). For both, all significant revenue is from ads. Yet both have now acquired hardware companies. Now they have to make a business out of them. They may not succeed.
Google acquired Motorola and had no idea what to do with it. Now they're selling it. Google has an automatic driving R&D project, but they acquired DARPA Grand Challenge technology and seem no closer to deployment than a few years ago. Google acquired a half dozen advanced robotics R&D firms, but none of those have commercial products or profits yet. Google now has to build an entire industrial business in robotics, which is slow, hard, and will take years to pay off. Google hasn't shown the corporate patience for that. Google products that didn't take off quickly are usually killed. I'm worried that Google will end up trashing the US robotics industry once they realize it's not a Make Money Fast business.
Facebook hasn't really tried yet in hardware. But they have no expertise at it. The Oculus Rift is still a prototype/low volume device. Facebook has never run a factory. They'll have to outsource manufacturing, which means everybody else will be making goggles if it turns out to be profitable to do so.
What's a good no-nonsense registrar for major TLDs? It doesn't have to be super cheap. I want to dump Network Solutions because they gave me an unsolicited domain (I had
I have about five domains. I want to avoid the "bulk" domain companies like GoDaddy.
I'm afraid, however, that the Real Men Don't Need Bound Checks mentality that is prevalent among C programmers will be a big obstacle.
I've run into that. Usually from second-rate programmers. Programmers who think that way should be put them on maintenance programming for a while. Have them debug program crashes in code written by others.
The code:
for ( i = 0; v3 != '\n'; ++v2)
// Dangerous loop, copying data to a stack buffer, until an end of line is found
{ if ( v3 == '\r' ) break;
*(_BYTE *)(i + a1) = v3;// Byte copy to the stack, without having destination size into account.
v3 = *(_BYTE *)(v2 + 1);
++i;
}
The company that let that code out the door should be sued for gross negligence, and managers fired. That's not the only example; they failed to do basic checks at least three times. This isn't a subtle bug. This is failing C Programming 101.
(Several times, I've tried to convince the C standards committee to put a "strict mode" in the language and move towards a form of C that's resistant to buffer overflow problems. Maybe I should try again.)
C - now with over thirty years of buffer overflows.
Google has re-invented LittleBits, a family of electronics modules which are attached with magnets. With their new "Cloud" module and their Arduino module, you might even be able to build a wireless VOIP phone.
This is a fun hobbyist concept, but you don't actually use things built that way. Either this will be bulky or the components will be fragile. You pay a penalty for all that casing and standard form factor.
Somebody (Wyse, I think) built a PC like this in the early 80s. Each module looked like a book, and plugged into the module next to it. You lined up all the modules, pushed them together, and put a big pin with a knob through the stack to lock them all together. Total failure as a product.
What Google should be doing, after buying all those robotics companies, is designing a phone for 100% robotic assembly, so they don't need Foxconn. (Except that Motorola did that a decade ago.)
I think a fire alarm is an instance where I'd like something to have as simple and foolproof a mechanism as possible.
Yes. That's why fire sprinklers are so successful. There's nothing between the water and the fire except a low-melting-point component in the sprinkler head.
This is an example of webcrap-level programmers doing things they're not qualified to do. I'm beginning to think that "Internet of Things" programmers should be required to have Registered Professional Engineer credentials, like structural engineers.
Genetics explains why you look like your father, and if you don't, why you should.
