Except, of course, that such apps have been available on other platforms already, and that they shouldn't be patentable at all as mere computer versions of simple manual processes.
I don't know whether the patent is on prior art from that particular app; arguably it actually may be. It certainly isn't "unrelated". And it is likely that the Apple engineers got their ideas by looking at that particular app and asking themselves "what can we patent that's kind of like an extension of this app?"
More importantly, if you actually read the patent, it's clear that the patent is (1) merely a computer embodiment of a manual process, (2) something lots of other apps have been doing already, and (3) devoid of new technical ideas.
Quantifying performance and cutting projects that don't work is a good principle. However, it only works if you pick the right performance measures and targets. For Wave, the performance measure seems to have been "widespread adoption after three months of public release". That's just a dumb measure.
In addition, another measure that is important to Google is not just "how many people are using this right now", but also "what attitudes do developers have towards our company". I can tell you: the latter measure has taken a big turn for the worse.
Also, how you cut poorly performing projects matters as well. They could have cut Wave during limited beta with little damage. But what they did is first release it to the public at large, and then elevate it into the select circle of apps that are available on Google Apps. And after all that, they drop it.
Sorry, but citing good engineering principles is not an excuse for stupid decisions and bad management, and what Google did with Wave was both, and it's going to hurt them for years to come.
Google Wave was on track: an odd-ball separate product with a small user community that had the potential to take off in the future. The next logical steps would have been integration with GMail and Google Talk and Google Docs, cleaning up and speeding up the UI, creating a mobile client, extensiblity in App Script etc. In a few years, Google could have had a kick-ass mainstream platform or it could have fizzled. It would still have been a good try.
However, nothing like Wave will ever catch on three months after its first open, public release. It's just not going to happen. And by killing it so quickly, Google has not just killed a nice platform with good potential, they've also seriously damaged trust developers have in them.
So now the projects will actually have to have some merit? Sounds good to me.
Google Wave had tons of merit. But three months out of closed beta just isn't enough time for any new software product to prove itself. None of the big, successful tools you use today would be here if they had been dropped that quickly.
Google may allow you to convert an existing E-mail and/or chat into something that looks like a Wave, but it won't be a Wave. Google Wave wasn't just about the threaded chat, it was a server and communications infrastructure that let people build robots and gadgets. Even if Google tries to recreate equivalent functionality, gadgets and bots will basically start from scratch. Furthermore, do you really think that people or businesses who invested a lot of time and effort into figuring out how to do that for Google Wave are going to do that again for an entirely new Google platform?
Integrating Google Wave and GMail was an obvious and necessary step, but Google should have done it by keeping the Wave server and application infrastructure and merging the services at the UI level. Dropping the Wave server and implementing something new that looks like Google Wave within GMail, while useful, is simply nowhere near the same.
Wave only became generally available three months ago. And the APIs only reached a usable a few months back, too. So, most users and developers didn't seriously consider using Wave for anything until three months ago. In those three months, I have seen a lot of uptake in my company and among my friends. In that short time, Google Wave has been a really useful tool, and it's shown a lot of potential. And that's only the beginning, as several people I know have started developing new and interesting robots and gadgets for it.
I think Google is seriously hurting themselves with this decision; even if Wave wasn't going to catch on in the long run, if they discontinue a service that has received so much buzz after so little time, they are going to have an even harder time attracting developers and users next time they try to create some new and innovative service.
3D movies exaggerate the 3D effect in order to impress. Actual, accurate 3D would be pretty boring, because anything more than a dozen feet away would be basically little different from a flat projection.
Oh, I agree. However, I would assume that the Verizon "backdoor" doesn't use the same password as the user login.
I seriously doubt it. It would be nearly useless then.
However, if you remove that firewall exception, it should stop Verizon from accessing your router if you wish to run your own network.
Again, I doubt it. The purpose of remote administration is to allow the ISP to help the customer with network problems. That port needs to be up and available as much as possible.
Imagine, for instance, a large delivery van blurred across the frame from left to right while the image is blurred due to camera motion from right to left. What should be the correction to remove camera shake blur? And how would that be determined merely from the data in the photo?
Well, in that case, you get two sets of deconvolution parameters if you determine them without hardware assist: one for the region corresponding to the van, one for the background. You can choose to deblur one or the other or both. And who said you don't want to deblur subject motion?
I don't doubt that merely processing the photo could make it "better"... but I do doubt it would do as good a job of removing camera shake in the general case as the external rig does.
What "it" can do and what is possible in principle are two different things. "It" can obviously remove camera shake a bit better if it gets the hardware information; deblurring becomes faster and more reliable. But in principle, the hardware info is not needed, you just need a lot more computation and better algorithms.
That "remote administration" refers to user-level administration. The Verizon router has a separate option for remote management by the provider that's not disabled that way. It also doesn't use the user's password.
There's nothing really nefarious about it; most people need customer support for their networks. Those people who don't need customer support should be smart enough to set up their own internal networks that Verizon can't access.
Looks to me like that thing is a modem + router, not just a router. Cable companies always have access to modems. They use that to test lines, for example. Access to your router may also make sense if they actually help you with your network.
Most people who leave the default password on their router probably need help from their ISP. Since this thing is a wireless router as well, it's probably fairly easy to get onto your internal network, so leaving the default password around was pretty careless.
If you don't like them getting into your network, put your own router in front of their modem+router combo or ask them for just a modem.
On the whole, I think Verizon did the right thing.
High reject rates are not necessarily an indicator of scientific quality, they simply may mean that the conference gets a lot of crap submitted. They are often more an indication of the perception of a conference as being important, not an actual indicator of quality. And for SIGGRAPH, you know what counts: nice pictures and videos. It's not really a surprise that Microsoft is good at producing those.
If you want to know about the quality of Microsoft Research, you need to look at how much they're spending on it and what the overall output is; I suspect it's below many universities.
Information theory tell us that once some info has been lost, it can't be recovered. If the picture has been somehow "damaged" by some motion blur, the original picture can't be reconstructed.
You're making a lot of implicit assumptions. If you know ahead of time that an image is a black-and-white image of a square, you can recover it quite well even in the presence of lots of noise and motion blur. You lose a lot of information about the individual pixel values, but you can reconstruct them with prior knowledge. Furthermore, the point of these deblurring algorithms is not to produce a pixel accurate picture, it's to produce a picture that looks sharp. So, you don't have to recover the original data, you only have to replace it with data that makes the resulting image look good.
Sorry, your analysis is wrong. The information added by the gyroscope is tiny compared to the information that was "lost" (and it wasn't really "lost" in the sense of the GP).
Blind deconvolution and computational photography have been around for a long time. They are being used, for example, to enhance astronomical images.
Microsoft is making an incremental improvement to this field. That's nice, but why is it worth reporting any more than any of the other papers on this field?
To use your words: "let me spell this out slooooowly for you".
Assume I have some asset that I expect to appreciate at 10% annually. Your 90% tax effectively reduces this to 1%. Who the hell is going to invest with that type of return?
You get hit with the 90% tax only if you keep it for less than a year. If you keep it for more than a year, you get taxed at a lower rate. Note that if you sell after a year, your entire gains (even those during the first year) are subject to the lower tax rate.
Who the hell is going to invest with that type of return?
People with a time horizon of more than a year. People who expect that they need to sell sooner in order to realize a gain will not invest. And that is exactly what the policy is supposed to achieve.
And I still stand by my 99.9% statement. If you think 90% is good, isn't 99.9% better? What's wrong with 100% then?
Getting that close to 100% is probably not such a good idea. If there are really huge gains to be made on a short term trade, there is probably some significant inefficiency in the market, so you want to allow that and give people a little bit of return. 90% is a reasonable tradeoff for that.
So, EFFECTIVELY, you have outlawed it.
No, outlawing the trade would mean that you can't do it at all; if the investment starts going into loss territory, you'd be stuck with it. On the other hand, if we tax only short-term gains at a high rate, you can simply sell and not be penalized.
If the investment hasn't gone down yet but merely turns more volatile, then you can't lock in short term profits, but you can still get out if the risk gets too high for you. Again, that's what we want.
Taxing short-term gains encourages exactly the behavior we want to encourage in the market: we want investors to look at the long-term potential of investments, instead of speculating on short-term fluctuations.
No, not at all. High taxes on short term gains don't affect your liquidity; you can buy and sell all you want. You simply can't make much profit doing so. For that, you need to hold it longer than a year.
Who is going to sell something at >1year if they know they'll receive almost zero profit.
After >1 year, they can make a lot of profit because then the taxes go down. That's the point: you have to pick your investments based on long term trends, not random market fluctuations.
It's constitutional, it works, and there is precedent.
Right, that's why setting minimum transaction times isn't a good idea.
What works well, however, is to tax short term gains at a high rate. That way, you can buy and sell short term and you don't lose liquidity, but if you try to engage in short term gambles, you won't profit much from it.
You can't make it illegal to buy and sell things quickly, nor do I think you would want to.
However, what you can do is tax gains on short term investments aggressively. You might tax gains on assets held less than a year at 90%, then going down to 50% until 3 years, and then going down to 10% or less beyond that.
Slashdot Mirror
Except, of course, that such apps have been available on other platforms already, and that they shouldn't be patentable at all as mere computer versions of simple manual processes.
I don't know whether the patent is on prior art from that particular app; arguably it actually may be. It certainly isn't "unrelated". And it is likely that the Apple engineers got their ideas by looking at that particular app and asking themselves "what can we patent that's kind of like an extension of this app?"
More importantly, if you actually read the patent, it's clear that the patent is (1) merely a computer embodiment of a manual process, (2) something lots of other apps have been doing already, and (3) devoid of new technical ideas.
Quantifying performance and cutting projects that don't work is a good principle. However, it only works if you pick the right performance measures and targets. For Wave, the performance measure seems to have been "widespread adoption after three months of public release". That's just a dumb measure.
In addition, another measure that is important to Google is not just "how many people are using this right now", but also "what attitudes do developers have towards our company". I can tell you: the latter measure has taken a big turn for the worse.
Also, how you cut poorly performing projects matters as well. They could have cut Wave during limited beta with little damage. But what they did is first release it to the public at large, and then elevate it into the select circle of apps that are available on Google Apps. And after all that, they drop it.
Sorry, but citing good engineering principles is not an excuse for stupid decisions and bad management, and what Google did with Wave was both, and it's going to hurt them for years to come.
Google Wave was on track: an odd-ball separate product with a small user community that had the potential to take off in the future. The next logical steps would have been integration with GMail and Google Talk and Google Docs, cleaning up and speeding up the UI, creating a mobile client, extensiblity in App Script etc. In a few years, Google could have had a kick-ass mainstream platform or it could have fizzled. It would still have been a good try.
However, nothing like Wave will ever catch on three months after its first open, public release. It's just not going to happen. And by killing it so quickly, Google has not just killed a nice platform with good potential, they've also seriously damaged trust developers have in them.
So now the projects will actually have to have some merit? Sounds good to me.
Google Wave had tons of merit. But three months out of closed beta just isn't enough time for any new software product to prove itself. None of the big, successful tools you use today would be here if they had been dropped that quickly.
Google may allow you to convert an existing E-mail and/or chat into something that looks like a Wave, but it won't be a Wave. Google Wave wasn't just about the threaded chat, it was a server and communications infrastructure that let people build robots and gadgets. Even if Google tries to recreate equivalent functionality, gadgets and bots will basically start from scratch. Furthermore, do you really think that people or businesses who invested a lot of time and effort into figuring out how to do that for Google Wave are going to do that again for an entirely new Google platform?
Integrating Google Wave and GMail was an obvious and necessary step, but Google should have done it by keeping the Wave server and application infrastructure and merging the services at the UI level. Dropping the Wave server and implementing something new that looks like Google Wave within GMail, while useful, is simply nowhere near the same.
Wave only became generally available three months ago. And the APIs only reached a usable a few months back, too. So, most users and developers didn't seriously consider using Wave for anything until three months ago. In those three months, I have seen a lot of uptake in my company and among my friends. In that short time, Google Wave has been a really useful tool, and it's shown a lot of potential. And that's only the beginning, as several people I know have started developing new and interesting robots and gadgets for it.
I think Google is seriously hurting themselves with this decision; even if Wave wasn't going to catch on in the long run, if they discontinue a service that has received so much buzz after so little time, they are going to have an even harder time attracting developers and users next time they try to create some new and innovative service.
3D movies exaggerate the 3D effect in order to impress. Actual, accurate 3D would be pretty boring, because anything more than a dozen feet away would be basically little different from a flat projection.
Oh, I agree. However, I would assume that the Verizon "backdoor" doesn't use the same password as the user login.
I seriously doubt it. It would be nearly useless then.
However, if you remove that firewall exception, it should stop Verizon from accessing your router if you wish to run your own network.
Again, I doubt it. The purpose of remote administration is to allow the ISP to help the customer with network problems. That port needs to be up and available as much as possible.
Imagine, for instance, a large delivery van blurred across the frame from left to right while the image is blurred due to camera motion from right to left. What should be the correction to remove camera shake blur? And how would that be determined merely from the data in the photo?
Well, in that case, you get two sets of deconvolution parameters if you determine them without hardware assist: one for the region corresponding to the van, one for the background. You can choose to deblur one or the other or both. And who said you don't want to deblur subject motion?
I don't doubt that merely processing the photo could make it "better"... but I do doubt it would do as good a job of removing camera shake in the general case as the external rig does.
What "it" can do and what is possible in principle are two different things. "It" can obviously remove camera shake a bit better if it gets the hardware information; deblurring becomes faster and more reliable. But in principle, the hardware info is not needed, you just need a lot more computation and better algorithms.
That "remote administration" refers to user-level administration. The Verizon router has a separate option for remote management by the provider that's not disabled that way. It also doesn't use the user's password.
There's nothing really nefarious about it; most people need customer support for their networks. Those people who don't need customer support should be smart enough to set up their own internal networks that Verizon can't access.
Looks to me like that thing is a modem + router, not just a router. Cable companies always have access to modems. They use that to test lines, for example. Access to your router may also make sense if they actually help you with your network.
Most people who leave the default password on their router probably need help from their ISP. Since this thing is a wireless router as well, it's probably fairly easy to get onto your internal network, so leaving the default password around was pretty careless.
If you don't like them getting into your network, put your own router in front of their modem+router combo or ask them for just a modem.
On the whole, I think Verizon did the right thing.
What works really depends on the professor, the student, and the subject; there's no one-size-fits-all.
In principle, you can probably deblur just as well without that information, it's just algorithmically and computationally a lot harder.
Is ShopSafe actually back? It had stopped working for a while, and support knew nothing about it. I eventually just canceled my accounts with them.
High reject rates are not necessarily an indicator of scientific quality, they simply may mean that the conference gets a lot of crap submitted. They are often more an indication of the perception of a conference as being important, not an actual indicator of quality. And for SIGGRAPH, you know what counts: nice pictures and videos. It's not really a surprise that Microsoft is good at producing those.
If you want to know about the quality of Microsoft Research, you need to look at how much they're spending on it and what the overall output is; I suspect it's below many universities.
Information theory tell us that once some info has been lost, it can't be recovered. If the picture has been somehow "damaged" by some motion blur, the original picture can't be reconstructed.
You're making a lot of implicit assumptions. If you know ahead of time that an image is a black-and-white image of a square, you can recover it quite well even in the presence of lots of noise and motion blur. You lose a lot of information about the individual pixel values, but you can reconstruct them with prior knowledge. Furthermore, the point of these deblurring algorithms is not to produce a pixel accurate picture, it's to produce a picture that looks sharp. So, you don't have to recover the original data, you only have to replace it with data that makes the resulting image look good.
Sorry, your analysis is wrong. The information added by the gyroscope is tiny compared to the information that was "lost" (and it wasn't really "lost" in the sense of the GP).
Blind deconvolution and computational photography have been around for a long time. They are being used, for example, to enhance astronomical images.
Microsoft is making an incremental improvement to this field. That's nice, but why is it worth reporting any more than any of the other papers on this field?
To use your words: "let me spell this out slooooowly for you".
Assume I have some asset that I expect to appreciate at 10% annually. Your 90% tax effectively reduces this to 1%. Who the hell is going to invest with that type of return?
You get hit with the 90% tax only if you keep it for less than a year. If you keep it for more than a year, you get taxed at a lower rate. Note that if you sell after a year, your entire gains (even those during the first year) are subject to the lower tax rate.
Who the hell is going to invest with that type of return?
People with a time horizon of more than a year. People who expect that they need to sell sooner in order to realize a gain will not invest. And that is exactly what the policy is supposed to achieve.
And I still stand by my 99.9% statement. If you think 90% is good, isn't 99.9% better? What's wrong with 100% then?
Getting that close to 100% is probably not such a good idea. If there are really huge gains to be made on a short term trade, there is probably some significant inefficiency in the market, so you want to allow that and give people a little bit of return. 90% is a reasonable tradeoff for that.
So, EFFECTIVELY, you have outlawed it.
No, outlawing the trade would mean that you can't do it at all; if the investment starts going into loss territory, you'd be stuck with it. On the other hand, if we tax only short-term gains at a high rate, you can simply sell and not be penalized.
If the investment hasn't gone down yet but merely turns more volatile, then you can't lock in short term profits, but you can still get out if the risk gets too high for you. Again, that's what we want.
Taxing short-term gains encourages exactly the behavior we want to encourage in the market: we want investors to look at the long-term potential of investments, instead of speculating on short-term fluctuations.
Perl will figure out which it is automatically and correctly every time
You just go on believing that. Fortunately, most programmers these days know better.
There's plenty of ways to do it. I really don't care how.
But how you do it makes a big difference, both in how well it works and whether you can push it through politically.
Taxing short term gains higher both works and has a good track record. Flat transaction fees or ownership restrictions do not.
Then you are effectively outlawing it.
No, not at all. High taxes on short term gains don't affect your liquidity; you can buy and sell all you want. You simply can't make much profit doing so. For that, you need to hold it longer than a year.
Who is going to sell something at >1year if they know they'll receive almost zero profit.
After >1 year, they can make a lot of profit because then the taxes go down. That's the point: you have to pick your investments based on long term trends, not random market fluctuations.
It's constitutional, it works, and there is precedent.
Right, that's why setting minimum transaction times isn't a good idea.
What works well, however, is to tax short term gains at a high rate. That way, you can buy and sell short term and you don't lose liquidity, but if you try to engage in short term gambles, you won't profit much from it.
You can't make it illegal to buy and sell things quickly, nor do I think you would want to.
However, what you can do is tax gains on short term investments aggressively. You might tax gains on assets held less than a year at 90%, then going down to 50% until 3 years, and then going down to 10% or less beyond that.