SpaceX started streaming a live "technical webcast" feed for the last several launches; here's the one for last night's launch: https://www.youtube.com/watch?...
In the past I think it's been linked from the webcast page, but you can also find it by searching Youtube.
Humble Bundle used to require you to sign into your Steam account and they would add the game directly to your account instead of giving you a key. It was originally keys, then the linking system, and then back to keys.
I'm guessing that Valve disabled that API because they don't want to make the process of buying games outside of Steam as seamless as their own store.
I suspect that Uber is hiring all these researchers to patent key R&D on the still-developing field of autonomous vehicles, and use it as leverage against Google (which probably has its own chest of patents already) and other self-driving automakers.
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.
So once we create new antibiotics that can defeat these types of drug-resistant bacteria, how long will it be until a completely new resistance appears? Let's hope that in the next century our ability to engineer new antibiotics exceeds the pace that bacteria can evolve to evade them.
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!
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.
Not all astronauts are trained as pilots; these days, a lot of them have scientific background. In this case, Ed Lu is a former astronaut who studied physics and published key papers about using a gravity tractor to deflect asteroids.
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.
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.
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.
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.
Slashdot Mirror
SpaceX started streaming a live "technical webcast" feed for the last several launches; here's the one for last night's launch: https://www.youtube.com/watch?...
In the past I think it's been linked from the webcast page, but you can also find it by searching Youtube.
Humble Bundle used to require you to sign into your Steam account and they would add the game directly to your account instead of giving you a key. It was originally keys, then the linking system, and then back to keys.
I'm guessing that Valve disabled that API because they don't want to make the process of buying games outside of Steam as seamless as their own store.
Hey, I didn't spend four years in image doctoring school to be called a shopper!
I suspect that Uber is hiring all these researchers to patent key R&D on the still-developing field of autonomous vehicles, and use it as leverage against Google (which probably has its own chest of patents already) and other self-driving automakers.
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.
So once we create new antibiotics that can defeat these types of drug-resistant bacteria, how long will it be until a completely new resistance appears? Let's hope that in the next century our ability to engineer new antibiotics exceeds the pace that bacteria can evolve to evade them.
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!
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.
Not all astronauts are trained as pilots; these days, a lot of them have scientific background. In this case, Ed Lu is a former astronaut who studied physics and published key papers about using a gravity tractor to deflect asteroids.
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.
Then it'd be Augmented Reality (AR), not Virtual Reality (VR).
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.
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.