The next step will be a modification to the "stingray" fake cell site unit to brick all phones in an area and prevent uploading of audio or video. This will be used during demonstrations.
If you watch the video at the bottom of the article, you'll see photos of several prototype FarmBots that do, in fact, exist.
Those are just tabletop gardening robots. That was done 20 years ago.
There's lots of real robotic agricultural machinery, much of it mobile. Building a gantry over a tabletop doesn't scale.
Fusion power is roughly 20 years away from being viable...and has been for the last 40 years LOL.
Longer than that. Fusion power has been hyped since the 1950s. From the article:
Nuclear fusion could come into play as soon as 2050
Heard that one before.
Fusion power has some real problems. After half a century of trying, nobody has a long-running sustained fusion reactor, even an experimental one. The whole "inertial fusion" thing turned out to be a cover for bomb research. There's a lot of skepticism about whether ITER will do anything useful. It's not clear that a fusion reactor will be cost-effective even with a near-zero fuel cost. (Fission reactors already have that problem.) It's really frustrating.
Fusion reactors are a pain to engineer. They have a big vacuum chamber with high-energy particles reacting inside, and huge cryogenic magnets outside. This is far more complicated than a fission reactor, and is why the cost of ITER keeps going up.
There is no "FarmBot". There is only a Kickstarter project to start a wiki to create a social network for talking about farming-related subjects, parhaps including talking about a FarmBot.
The basic office-type products for Linux still kind of suck. I've been using them since the StarOffice/SunOffice days, and now use LibreOffice. They've improved a lot, but they're still flakier than they should be, a decade after initial release. Nobody wants to fix the hard-to-fix, boring bugs which damage usability.
Oracle buying the remnants of Sun didn't help.
Nuke the server from orbit. It's the only way to be sure.
Before "Jaws", there wasn't much of a market for shark meat. Then demand picked up. Now, the shark population has dropped so much that sharks are facing extinction.
Will this be fixed on the next Patch Tuesday? I haven't been using the Windows macines much lately, but one is powered up, idle, and accepting updates. Will it fix itself?
As usual, we have to go through two levels of blogs to get to the actual ICANN document. Which document you may find incomprehensible even if you know how DNS works.
There is no such thing as an 'ASIC proof algorithm' because you simply design the ASIC to handle that situation.
This is in theory true, but there are proposed proof-of-work algorithms for which specialized hardware doesn't have a huge edge over general-purpose CPUs. Such algorithms require more memory than the existing hashes, and are designed to be highly sequential, so they don't parallelize easily. At least one altcoin claims to have such an algorithm.
Any algorithm that requires a significant amount of 64-bit floating point computation and lots of memory, like a big matrix inversion, would be reasonably ASIC-proof, simply because that's a task CPUs are designed to do fast. An ASIC that could invert big matrices would need superscalar FPUs, which makes it as complex and expensive as a CPU with comparable performance.
So far, nobody seems to have devised a "minable" algorithm based on matrix inversion, but that's a place to look for one.
What I'm proposing is to hold up the final 250 OK until the message has been passed on, then report the result of the forwarding as an SMTP status. If immediate forwarding is not possible, return a 421 Service Not Available, so the sender will retry. If the forwarding returns an error status, return that error status. No need for local message storage or bounce messages.
I've heard Dolby's positional audio, being driven from a game, in the Dolby Labs screening room in San Francisco. It sounds great. You can hear people sneaking up behind you in the game. You can hear someone walking around you. There's a real sense of presence.
That's in a room built, at a cost of millions, as a demo for Dolby's audio technology. The room is on a separate foundation from the rest of the building, with an inner set of vibration isolated walls. The room acoustics are very good; you don't need a microphone when giving a talk there. The walls and ceiling conceal speakers everywhere, and the room with the amps and processors looks like a small server farm.
You're not going to get that in Joe Sixpack's living room. You might get close to it in some high end home theater installations, the ones that look like small movie theaters and are used for no other purpose. It's a niche market.
One of my back-burner ideas is speeding up email forwarding. Most email forwarders (sendmail, etc.) accept emails, put them in a queue, and then later spool them out to the destination. This adds a minute or so of latency. It's done this way for historical reasons. In the early days, the destination mail agent might be down, or the mail transfer might be over some polled protocol like UUCP.
That's dead. Today, if the destination mail agent exists, it's probably up and immediately reachable via a fast connection. So a modern mail fowarder should accept the incoming email via SMTP, and then, while holding the incoming connection open, send the email on to the destination mail agent. Any problems are immediately reported to the sender via SMTP status code.
This not only speeds things up a bit, it eliminates "bounce messages" generated between mail agents. Problem reports come back immediately, as SMTP errors. There's a series of open TCP connections from sender to the receiver's IMAP server. From the IMAP server to the final destination, today you usually have some kind of push notification. So you get the effect of instant messaging, using existing email protocols.
This also eliminates "joe jobs", where impersonation generates vast numbers of bounce messages. The spammer just gets lots of SMTP errors, which never bother anybody else.
It is awfully obscured in the article by general hand-waving...
Agreed. Anyone know what kind of exploit this is?
Didn't look at the source of a Youtube page, did you? Look for "http://s.ytimg.com/yts/swfbin/player-vflZsDuOu/watch_as3.swf". Videos can also play with "HTML5 video", but there's Flash code there to be executed.