Forgot your password?
typodupeerror

Comment: Battery life (Score 3, Interesting) 56

by ensignyu (#47421141) Attached to: The Future of Wearables: Standalone, Unobtrusive, and Everywhere

No, the biggest irritants are battery life and price. Putting a standalone cell radio in a watch will make the battery life even worse than the 24-48 hours that the latest crop of Android-based watches get with real usage. And the cell radio costs more and will probably have lousy antennas.

I can see why AT&T would want a cell-connected watch: so they can charge you an extra $5-$10 a month to add another device to your plan.

Comment: Robots are useful on Earth, too (Score 1) 95

by ensignyu (#47116327) Attached to: Robots Will Pave the Way To Mars

Research in robotics is especially useful because it has direct applications here on Earth, which makes it more likely to attract private investment and increases the likelihood of being able to spin off space tech for consumer purposes.

Maybe in the future we'll be able to build robots using off-the-shelf parts to do boring, dangerous tasks here on Earth, and use slightly more robust versions (still made of mostly off-the-shelf parts) on Mars without spending billions on R&D.

The easiest way to build billions of affordable robots is to have a dozen of them in every home. I'm still waiting for a robot personal chef, dammit!

Comment: Re:Simple (Score 1) 311

by ensignyu (#46910043) Attached to: Steve Jobs Defied Convention, and Perhaps the Law

Credit card companies charge 20-30 cents per transaction, so for $0.99 apps it's a good deal (Apple has probably negotiated lower transaction fees).

Where it gets unfair is that Apple wants the same cut of recurring subscriptions like magazines, etc, which may be a lot more than $0.99. You're prohibited from providing a link to go to your website to sign up for the subscription because Apple wants the cut they get when you buy using in-app purchases.

That's the reason why on iOS you can use the Amazon app to buy physical goods, but not music or other digital items.

Comment: Re:Seriously, $250,000? (Score 1) 44

by ensignyu (#46722893) Attached to: NASA Setting Up $250,000 Mars Lander Competition

None of these X-prize style challenges offer anywhere near the R&D cost of even attempting the challenge.

It's mostly about the prestige -- though I guess people might consider a $10 million challenge more prestigious than a $250,000 one.

And if organizations started offering $10,000 for a bunch of smaller challenges (that still cost a couple orders of magnitude over $10,000 to develop) I'd imagine the novelty would wear off.

Comment: Libraries (Score 2) 391

by ensignyu (#46607065) Attached to: Toward Better Programming

Some interesting points in the article. I think there's nothing really stopping you from creating a high-level representation that lets you work abstractly. A graphical programming model is probably going to be too simplistic, but the card example could easily be something like Cards.AceOfSpades. Or being able to call something like Math.eval(<insert some math here>).

Where it falls apart is when you have to hook this up to code that other people have written. If there was a single PlayingCard library that everyone could agree on, you might be able to create a card game by adding a "simple" set of rules (in reality, even simple games tend to have a lot of edge cases, but this would at least free up the nitty gritty work to allow writing something more like a flowchart expressing the various states).

Unfortunately, it's unlikely that a single library is going to meet everyone's needs. Even if you manage to get everyone to stick to one framework, e.g. if all Ruby developers use Rails -- as soon as you start adding libraries to extend it you're bound to end up with different approaches to solving similar problems, and the libraries that use those libraries will each take a different approach.

Comment: Too bad we didn't have this 2-3 years ago (Score 2, Insightful) 86

by ensignyu (#44191589) Attached to: Digia Releases Qt 5.1 With Preliminary Support For Android and iOS

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.

Comment: Re:Not a good architecture for alternate guis (Score 1) 240

by ensignyu (#43944177) Attached to: Clearing Up Wayland FUD, Misconceptions

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.

Comment: Re: Congratulations! (Score 1) 446

by ensignyu (#43799579) Attached to: Tesla Motors Repays $465M Government Loan 9 Years Early

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).

Comment: Re:Deck chairs arrangements (Score 1) 126

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.

Comment: Just another OS (Score 3, Insightful) 201

by ensignyu (#43261807) Attached to: A Glimpse of a Truly Elastic Cloud

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.

Chemist who falls in acid will be tripping for weeks.

Working...