The partial repeal was a Republican bill that passed the Senate on party lines:

https://en.wikipedia.org/wiki/Gramm%E2%80%93Leach%E2%80%93Bliley_Act

I suppose you can blame Clinton for not vetoing it.

Nokia could have made a compelling cross-platform play. Write one app, have it run on iOS, Android, and Meego -- and others. Like what HTML5-on-mobile was supposed to do, but without the performance and compatibility headaches.

It wouldn't necessarily have a native look-and-feel on each platform but there are plenty of apps that use non-standard themes anyways.

As far as drivers, the abstraction layer is supposedly EGL / OpenGL ES. Of course, that assumes every OpenGL ES implementation works flawlessly out of the box without hacking around bugs, etc, which is rarely the case.

AFAIK, Weston only supports Mesa right now. Nvidia doesn't provide an OpenGL ES library or Mesa support in their binary drivers, so you'd be stuck with the open source nouveau driver if you want to use Weston.

There's also the concept of nesting compositors, where the desktop window manager (kwin, gnome-shell, etc) would run as a session compositor and handle window decorations, drag events, and compositing, and then it would send the full screen image to the system compositor which would just do a dumb blit to the screen.

I'm curious about of the performance of this, since it sounds like you basically have:

1) App renders widgets/video/3D using OpenGL to a window pixmap, and sends the pixmap to session compositor.
2) Session compositor uploads window pixmaps to OpenGL textures and then renders the scene to a full-screen pixmap, and sends it to the system compositor.
3) System compositor sends full-screen pixmap to the OpenGL drivers, which displays it.

which seems like it'd use a fair amount of bandwidth shuffling back and forth pixmaps that might be nearly 2650x1600 for a maximized window, at 60fps. There might be some optimizations to pass off the images without compositing, e.g. for a full screen window or if there's no overlap, but there might also be some degenerate cases.

The next model is the Model X, which is not going to be particularly affordable either. The one after that (Tesla Bluestar) is supposed to be a $30,000 compact car with a 200 mile range, but that's at least a few years away if at all.

I wonder which we'll see first: a manned SpaceX launch (estimated 2018) or a $30,000 Tesla (estimated 2016-2017).

I mostly agree with you, but I also think that self-driving taxis could also improve public transit usage because they solve the last mile problem -- getting to and from mass transit. For medium distance commutes, it might still be faster to take a self-driving taxi to the train/subway and then get another taxi after getting off the train/subway, for locations that aren't too far from a transit center.

Also, it'd be easier to take the self-driving bus in the morning if I knew that I could call a self-driving taxi if I missed the bus, or if I needed to go home early/late.

Relying entirely on self-driving vehicles may be the cheapest, most convenient option for a period of time after they're introduced, but as energy costs rising in the long run could provide an edge towards mass transit systems. Having self-driving taxis feed into the mass transit systems could boost ridership and efficiency to the point where they're cheaper and maybe even more convenient than driving for certain commutes.

This doesn't surprise me at all. The so-called virus scanners can't actually scan for viruses (i.e. examine the code of third-party apps) because that would break the copy protection. The paper mentions this at the beginning.

If you think about it, a hypervisor is just an OS that manages other (guest) OSes. It enforces privilege separation and abstracts device access to the guest OS.

If you replace the guest OS with a guest application ... it's really just a regular OS again. You know what else takes less than 1-2 seconds to start up and shut down? A UNIX process.

From a technical perspective, maybe there's some value in moving beyond the traditional *NIX APIs, filesystems, etc, and defining a novel, possibly simpler interface for running and managing application code.

Or go in the opposite direction by extending its capabilities, taking advantage of the new hypervisor security space to let app runtimes take over traditionally OS-level "ring 0" responsibility like page tables and interrupts/handlers with full hardware acceleration.

You can't call it OS-less though, unless you really mean "less OS" rather than "without an OS". Call it OS-minus, or maybe even OS-plus.

Just to be clear, I'm sure the engineers at Google are trying to do what they can do deal with the spam problem, as quickly as they can.

I'm just feeling cynical about Google's motives and actions after what they've done with Google Reader, CalDAV, etc. Yeah, they're a for-profit corporation, but it's disappointing how they seem to be moving away from open standards.

At this point, it seems like they're looking around and saying: "Hey, we have a proprietary solution, and an open solution, but it costs extra to maintain both. If we shut down the open solution, we save money and get extra lock-in too. It's win-win! -- for us, at least."

So I'm slightly worried that when a situation like this comes up, the managers at Google (or managers' managers, or wherever the directive is coming down from) are just going to say "do the minimum amount of work and get back to that other project we have you working on", where implementing solution that's good for the users is not a priority.

Maybe instead of silently dropping invitation requests, Google should send a rejection notice (regardless of whether the target Gmail account exists, to prevent probing) with a link to a CAPTCHA; completing the captcha would allow retrying the request.

Given their track record, I'd be surprised if Google bothers to implement this kind of non-lazy approach to re-enable interoperability, though.

Not that I think that bailouts are a good idea, but I'd like to see some more factual analysis before saying that "X happened, therefore Y".

The only definitive conclusion you can draw without more background is that the bailouts did not stop the Great Depression. But for all we know, the bailouts could have been ineffective with no impact on the economy, or perhaps the depression would have been even worse without the bailouts. Maybe the bailouts were too small.

Maybe the economy was so badly screwed that the only thing that would restore it was massive government spending of 40-50% of GDP.

This was not a pressure hammer "event". It was a controlled, deliberate measure to try to free stuck/blocked valves.

Is it possible that they damaged something in the process? Yes, there can always be unforeseen problems; part of the history of space flight is being able to deal with unforeseen problems with the limited tools at your disposal. But let's not jump to conclusions or be alarmist. Leave the analysis to the engineers with the actual design schematics and simulator software to say whether something is or is not safe before they do it.

It's not accurate to say that the Dragon will be automatically docking with the ISS, since the Dragon doesn't support automated docking yet. Rather, it very slowly approaches the station, holds steady at about 10m, and then the crew (or mission control in Houston) spends hours operating a robotic arm to grab it and bring it in.

As others have pointed out, NASA has the final say over whether the Dragon can even come within a kilometer of the ISS.

The initial approach during the COTS-2 demo was 0.24 meters/second according to this link and this link, and the final approach from 30m is even slower.

I'd imagine that the ISS could manage to avoid an object traveling towards it from 30m at roughly the speed of a tortoise, considering that most other dangerous objects in space are traveling much faster.

That's not to say that the thrusters couldn't misfire at just the wrong moment, but considering the care taken in the approach, it's not like they're just aiming it in the direction of the ISS and hoping for the best. It'd have to be a failure that didn't manifest at all until close to the last second, which would be extraordinarily bad luck.

There was a Kickstarter project for that (which failed funding):

http://www.kickstarter.com/projects/934651649/hiku-lets-simplify-the-way-we-shop

Though I can't see that being practical at all. To make it convenient enough to not waste more time than it saves, you'd need multiple cameras and scanners in your fridge so it could read barcodes from any angle whenever you put stuff in and take it out. Plus some kind of image recognition software to identify non-barcoded stuff like fruits and veggies.

The quicker way to get a fast initial inventory would be to just take a photo of your grocery receipt, which also lets you figure out how much you've been spending on string cheese sticks every month.

If fridge inventory tracking were actually a "thing" I'm sure grocery stores would let you download a list of UPCs from your most recent shopping trip via a smartphone app linked to your loyalty card.

I'd like to provide public access, but I don't want trolls and other idiots getting my IP banned everywhere or criminally investigated. What I'd like to see is some kind of VPN-only / proxy-only access to the Internet. The idea is that I'm giving you access but not identity.

You'd be required to proxy through either your own server (ssh/openvpn), the Tor network, or some kind of commercial VPN/proxy service. I mean, you ought to be doing that anyway. All common ports, *especially* http/https, would be blocked.

That doesn't stop someone from ssh'ing into their hijacked zombie computer in Russia and using that to launch an attack, which could still lead to a criminal investigation if they didn't cover their tracks properly, but at least it'll hopefully stop the sysadmins and bots who assume "IP address == person responsible" from reflexively laying down the banhammer on my IP or suing me for allegedly sharing The_Hobbit_An_Unexpected_Journey_4K_xvid_LEAKED_plus_soundtrack.rar

Inexact matches. In the puzzle described in the paper, the pieces are all square (no notches). So the algorithm has to decide which edge matches best based on the similarity of the pixels, but it could be wrong or there may be multiple pieces that look like they match equally well (e.g. sky pieces which look very similar).

In the cases where it's wrong, it may have to throw out some of the fittings -- e.g. if you have a bunch of smaller groups of tiles that seem to fit together, but when you put it all together the puzzle isn't rectangular, then you have to break up the groups and try again. You can't just match one tile and be done with it.