Software just feeds a similar list of steps (mathematical transformations) into a computer and does something.
That'd be just fine IMO. Most software patents show vague pictures of the inputs and outputs of those transformations, and then claim to have patented the transformations themselves. Its as if the cotton gin patent simply showed cotton growing in fields, then t-shirts, and had a large box in between them that was patented under "a method for transforming cotton from its natural state," which was then used to attack the loom.
The two things that can make slide to unlock physical are the rough specifics of the action (size of slider, size of track, visual/tactile feedback, etc) or the specific code approach used to implement it. In each completely separate case the process patented would have to be novel. The notion of a specifically designed sliding motion to unlock the phone probably was novel - the research that went into coming up with a method that was natural and yet almost impossible to happen unintentionally was not insignificant. The idea of taking a generic action because of a sliding your finger in any way over a phone is not patentable. Using a substantially different sliding method to unlock a phone would not violate Apple's patent either.
Think about simple physical patents for a second. You can't patent the idea of a bladed fan, even the idea of using one to cool a computer. You can patent a specific complex design (xx blades with different thicknesses and pitches) that produces a specific response (less noise, less space, more cooling), but in doing so the patent also has to be specific enough for someone to reproduce your invention once the patent has expired.
Rewrites often work well if the original goal for the software has morphed over time, so that its overall structure just no longer makes sense. In other cases codebase does contain a ton of good tribal knowledge that's often lost and has to be relearned during a rewrite process. Confusing things is the fact that in many areas the tools available to developers now (libraries, etc) are far more powerful than they were even 4-5 years ago, so removing code that isn't necessary to meet a business need can really help.
But the fact that it hid it until someone finally tried it on a device is the simulator's fault.
The same thing would happen if you'd tested on an iPhone 5S and then your users tried to run it on an iPhone 4. Is that their fault also?
And you've never had websites that did anything even somewhat complicated in JavaScript, huh? Since you aren't allowed to run interpreted code on iOS, it had to be redone in Objective-C, and the initial version turned out to be very slow. (Think "charting.")
Odd to hear this from you, since we deploy many apps written extensively in JavaScript, but do go on.
I mean, sure, we could have just embedded a webpage and done it that way, but the existing JavaScript was already unacceptably slow or we wouldn't be looking at making an iOS app, now, would we?
Aha! Sounds like you had slow code in one language and replaced it with slow code in another language. FWIW, there are plenty of free JS charting libraries that run really well generating complex charts blindingly fast even on very old iOS devices.
What's that saying about a craftsman blaming his tools again?
The DPI in some tablets / laptops is so high that applications running on desktop operating systems (Windows, OS X and Linux) render like postage stamps with tiny fonts, toolbars and other buttons. To counter this the OS can upscale any non-high-dpi-aware app's window but that makes everything looks blurry.
I'm with you on Windows and Linux. OSX has been doing this natively, with no blurriness, since they first started shipping retina laptops. It really is amazingly nicer than the old low-res screens. Source: been using it personally since 2012.
Actually, you don't really need much of the FirefoxOS when doing the design job since the HTML/CSS will render with Firefox quite exactly as it would in any FirefoxOS phone.
The simulator is very useful for developing all sorts of apps. The fact that it didn't work well for yours because it was hiding some poorly optimized code doesn't mean that a huge majority of apps don't benefit from it.
Most apps in the app store are not the latest and greatest video epic.
If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first place, well... that's not the simulator's fault.
Even silly things like old elevator control software that thought it was 1900 instead of 2000, "calculated" the wrong day of the week because of that, and idled out a bunch of elevators because "Hey, its Sunday, right?" The invisible impact was potentially huge.
The Y2.038K problem should be a fun one. Lots and lots of userland programs out there use ints to hold time values instead of something that can just be recompiled. Lots of them.
Surprisingly, Comcast is now giving out/64 IPv6 addresses in my area (south-eastern Massachusetts). Spent a couple of evenings last week getting it all connected. Works fine.
Emphasis added. Until the freebie routers start handing out IPv6 blocks by default and routing IPv6 traffic cleanly, this will never work. Why on earth would you need to actually do any work by hand?
Next up, I'm going to the local Islamic bakery and asking for a cake with a topper depicting a pig defecating on the Koran. I'm sure they'll be happy to accommodate my particular tastes.
And, assuming that they regularly made cakes showing pigs, defecation, and the Koran for other people but not for you, you'd have a case.
When the only difference is the substitution of one regularly-used wedding topper for another regularly-used wedding topper, not so much.
Perhpas 4.30 is 1 minute after the film finishes, so I need to leave as soon as the film finishes, and the North side is not the normal side for driving home?>
So check once the house lights come on but before you magically teleport yourself to the wrong place in a fraction of a second? After all, you have to get up, wait for your row to empty, and walk to the exit - plenty of time to check a text that you seem to think you can check in a fraction of a second during the movie.
A battery big enough to record continuously on a Glass or a cellphone all day long and upload data to the cloud would weigh 5-10 pounds
Which is funny, when you think about it, since a reasonably modern laptop can happily run its camera and upload files for 7-8 hours while weighing far less, including all of the other laptop bits like a screen and keyboard.
So... why aren't camera phones banned. I can make a full HD and even 4k quality video of someone with my phone. I can even make a 50 mpix photo of people in the theatre with my phone (Oppo phone).
They are at the Alamo with the same rules - once the lights go down, all gadgets get put away. Next silly quibble please.
I have a right to wear corrective lens. I have a right to have a red light blinking on them if I want to and you can't say anything.
And the movie theater has a right to not take your money.
The difference with the bakery was that they were being asked to do something that they were completely willing to do most of the time except for the identity of the person asking. If Alamo kicked you out for needing glasses at all, or for being white, or straight, or short, that'd be the same level of discrimination.
tl;dr: they can kick you out for your actions, but not for your identity
Dwolla doesn't have federally mandated protection with which someone claiming to be a dissatisfied customer can get all of their money back. Also, the nice thing about the existing network is that I can make payments from people without Dwolla accounts. People on both ends are also not well protected from fraud.
Currently, a customer gets a credit card, debit card, or bank account. Their financial institution issues products that work with standard interchange protocols. Next, merchants choose to get a merchant account that's also designed to work with interchange. The end-user never has to opt-in or sign up for anything else. That's where the convenience comes into play - and yes, getting a ton of disparate systems to talk to one another safely and reliably costs money, as does having your merchant bank advance you funds before they really clear (Dwolla quotes "within seconds or up to 4 days").
Dwolla is a great idea, but its very much a single-owner closed system. Naturally this lets them bypass a lot of the problems (and costs) associated with an open network.
Sounds like a disposable battery and a horribly energy inefficient way to extend the range. Moving batteries back to the manufacturer when discharged and probable an insane amount of energy to reuse. For 100 KG I'd rather add a small engine / generator.
The Ford 3-cylindar ecoboost weighs around 100KG. Add to that space for fuel (another 25kg for 10 gallons, not including the gas tank which'd be 10kg even if plastic, plus all the cooling, plumbing, exhaust, intake, transmission cost and weights, driveshaft connectivity problems, and physical space constraints that a gas engine and fuel system would bring, and you're far better off with the replaceable range extending battery.
Seriously, say I wanted to drive from Dallas to Las Vegas; the battery lasts just long enough to get me there in one shot. Sure, the rechargable pack lasts long enough for the short drives once I'm there, but the return trip is going to suck with the repeated stops for recharging, especially with the lack of SuperCharger stations along the way.
Or you could rent a gas-powered car for a few days, allowing you to spend far less on your daily driver while still providing you with full road trip range (and letting you optimize both vehicles; its likely that you'd want a different sized car for each purpose, for example).
When I worked in one inner suburb of a medium-sized city, and lived in another, I commuted about 50km each way, 100km in total, and hence 3000km over the course of a little over a month. Commutes 3-4 times that long are not unheard of in larger cities. But for me, would have meant a battery swap about 10 times a year. I don't know how long the swap should take, but I do know I would not have time to visit a dealer - the closest being about a half hour away - anywhere near that frequently, even if it were a short and painless process.
So don't get one. In other news, people who tow heavy trailers could never use a Camry, yet somehow it's once again the best selling car in the country. Not every new technology needs to solve every problem.
I'm glad that internal combustion engines don't have any kind of fluids that you need to change every few thousand miles then. Just imagine how impossible a situation that would be, especially if failing to change them could actually damage or destroy the engine! Better to stick with the tried and true.
In unrelated news I saw another "jiffy lube" going up down the street from my office. When will the homosexual agenda cease their corruption of young minds?
They've brought a surprising amount of electrical power - first wired, now often solar - to remote parts of the globe simply because refrigeration helps them sell enough more product to make the investment worthwhile. This can be quite a good thing if the infrastructure remains open enough.
If you're truly in a PCI-DSS situation, the last thing you want is to have your server in house. Now your datacenter has to be fully compliant with the PCI physical access guidelines. It'd be a lot easier to lease one somewhere like Rackspace, which is even more expensive than AWS (who provides one of the few cloud environments that's PCI level 1 certified at this point).
1) I guess it goes down until it can be fixed under warranty (same or next day depending on purchase option). Redundancy is expensive.
With Amazon's multi-az, redundancy just costs double whatever your non-redundant primary server costs (or less). Less if you don't mind your backup server being a bit smaller. Getting true hot-spare failover working properly on a database server is a royal PITA. The fact that Amazon will happily sell it to you for $250/mo. is a steal, and far cheaper than actually doing it yourself would be for any significant project.
Software just feeds a similar list of steps (mathematical transformations) into a computer and does something.
That'd be just fine IMO. Most software patents show vague pictures of the inputs and outputs of those transformations, and then claim to have patented the transformations themselves. Its as if the cotton gin patent simply showed cotton growing in fields, then t-shirts, and had a large box in between them that was patented under "a method for transforming cotton from its natural state," which was then used to attack the loom.
The two things that can make slide to unlock physical are the rough specifics of the action (size of slider, size of track, visual/tactile feedback, etc) or the specific code approach used to implement it. In each completely separate case the process patented would have to be novel. The notion of a specifically designed sliding motion to unlock the phone probably was novel - the research that went into coming up with a method that was natural and yet almost impossible to happen unintentionally was not insignificant. The idea of taking a generic action because of a sliding your finger in any way over a phone is not patentable. Using a substantially different sliding method to unlock a phone would not violate Apple's patent either.
Think about simple physical patents for a second. You can't patent the idea of a bladed fan, even the idea of using one to cool a computer. You can patent a specific complex design (xx blades with different thicknesses and pitches) that produces a specific response (less noise, less space, more cooling), but in doing so the patent also has to be specific enough for someone to reproduce your invention once the patent has expired.
Rewrites often work well if the original goal for the software has morphed over time, so that its overall structure just no longer makes sense. In other cases codebase does contain a ton of good tribal knowledge that's often lost and has to be relearned during a rewrite process. Confusing things is the fact that in many areas the tools available to developers now (libraries, etc) are far more powerful than they were even 4-5 years ago, so removing code that isn't necessary to meet a business need can really help.
tl;dr: its complicated, and it all depends.
But the fact that it hid it until someone finally tried it on a device is the simulator's fault.
The same thing would happen if you'd tested on an iPhone 5S and then your users tried to run it on an iPhone 4. Is that their fault also?
And you've never had websites that did anything even somewhat complicated in JavaScript, huh? Since you aren't allowed to run interpreted code on iOS, it had to be redone in Objective-C, and the initial version turned out to be very slow. (Think "charting.")
Odd to hear this from you, since we deploy many apps written extensively in JavaScript, but do go on.
I mean, sure, we could have just embedded a webpage and done it that way, but the existing JavaScript was already unacceptably slow or we wouldn't be looking at making an iOS app, now, would we?
Aha! Sounds like you had slow code in one language and replaced it with slow code in another language. FWIW, there are plenty of free JS charting libraries that run really well generating complex charts blindingly fast even on very old iOS devices.
What's that saying about a craftsman blaming his tools again?
The DPI in some tablets / laptops is so high that applications running on desktop operating systems (Windows, OS X and Linux) render like postage stamps with tiny fonts, toolbars and other buttons. To counter this the OS can upscale any non-high-dpi-aware app's window but that makes everything looks blurry.
I'm with you on Windows and Linux. OSX has been doing this natively, with no blurriness, since they first started shipping retina laptops. It really is amazingly nicer than the old low-res screens. Source: been using it personally since 2012.
Actually, you don't really need much of the FirefoxOS when doing the design job since the HTML/CSS will render with Firefox quite exactly as it would in any FirefoxOS phone.
What, both of them?
The simulator is very useful for developing all sorts of apps. The fact that it didn't work well for yours because it was hiding some poorly optimized code doesn't mean that a huge majority of apps don't benefit from it.
Most apps in the app store are not the latest and greatest video epic.
If you had a "bog-standard iOS app that was a very simple UI in front of a website" that has complex long-running code in the UI thread, or for that matter complex code that takes "nearly a minute" to run in the first place, well ... that's not the simulator's fault.
Its a good thing that C never encouraged fixed-width record constructs...
Even silly things like old elevator control software that thought it was 1900 instead of 2000, "calculated" the wrong day of the week because of that, and idled out a bunch of elevators because "Hey, its Sunday, right?" The invisible impact was potentially huge.
The Y2.038K problem should be a fun one. Lots and lots of userland programs out there use ints to hold time values instead of something that can just be recompiled. Lots of them.
Surprisingly, Comcast is now giving out /64 IPv6 addresses in my area (south-eastern Massachusetts). Spent a couple of evenings last week getting it all connected. Works fine.
Emphasis added. Until the freebie routers start handing out IPv6 blocks by default and routing IPv6 traffic cleanly, this will never work. Why on earth would you need to actually do any work by hand?
Next up, I'm going to the local Islamic bakery and asking for a cake with a topper depicting a pig defecating on the Koran. I'm sure they'll be happy to accommodate my particular tastes.
And, assuming that they regularly made cakes showing pigs, defecation, and the Koran for other people but not for you, you'd have a case.
When the only difference is the substitution of one regularly-used wedding topper for another regularly-used wedding topper, not so much.
Perhpas 4.30 is 1 minute after the film finishes, so I need to leave as soon as the film finishes, and the North side is not the normal side for driving home?>
So check once the house lights come on but before you magically teleport yourself to the wrong place in a fraction of a second? After all, you have to get up, wait for your row to empty, and walk to the exit - plenty of time to check a text that you seem to think you can check in a fraction of a second during the movie.
A battery big enough to record continuously on a Glass or a cellphone all day long and upload data to the cloud would weigh 5-10 pounds
Which is funny, when you think about it, since a reasonably modern laptop can happily run its camera and upload files for 7-8 hours while weighing far less, including all of the other laptop bits like a screen and keyboard.
So... why aren't camera phones banned. I can make a full HD and even 4k quality video of someone with my phone. I can even make a 50 mpix photo of people in the theatre with my phone (Oppo phone).
They are at the Alamo with the same rules - once the lights go down, all gadgets get put away. Next silly quibble please.
I have a right to wear corrective lens. I have a right to have a red light blinking on them if I want to and you can't say anything.
And the movie theater has a right to not take your money.
The difference with the bakery was that they were being asked to do something that they were completely willing to do most of the time except for the identity of the person asking. If Alamo kicked you out for needing glasses at all, or for being white, or straight, or short, that'd be the same level of discrimination.
tl;dr: they can kick you out for your actions, but not for your identity
And of course ever since this happened they show it periodically as their "before the movie" video to tell you not to use your phone.
Dwolla doesn't have federally mandated protection with which someone claiming to be a dissatisfied customer can get all of their money back. Also, the nice thing about the existing network is that I can make payments from people without Dwolla accounts. People on both ends are also not well protected from fraud.
Currently, a customer gets a credit card, debit card, or bank account. Their financial institution issues products that work with standard interchange protocols. Next, merchants choose to get a merchant account that's also designed to work with interchange. The end-user never has to opt-in or sign up for anything else. That's where the convenience comes into play - and yes, getting a ton of disparate systems to talk to one another safely and reliably costs money, as does having your merchant bank advance you funds before they really clear (Dwolla quotes "within seconds or up to 4 days").
Dwolla is a great idea, but its very much a single-owner closed system. Naturally this lets them bypass a lot of the problems (and costs) associated with an open network.
Gosh, it sounds almost as if you've read the article!
Sounds like a disposable battery and a horribly energy inefficient way to extend the range.
Moving batteries back to the manufacturer when discharged and probable an insane amount of energy to reuse.
For 100 KG I'd rather add a small engine / generator.
The Ford 3-cylindar ecoboost weighs around 100KG. Add to that space for fuel (another 25kg for 10 gallons, not including the gas tank which'd be 10kg even if plastic, plus all the cooling, plumbing, exhaust, intake, transmission cost and weights, driveshaft connectivity problems, and physical space constraints that a gas engine and fuel system would bring, and you're far better off with the replaceable range extending battery.
Seriously, say I wanted to drive from Dallas to Las Vegas; the battery lasts just long enough to get me there in one shot. Sure, the rechargable pack lasts long enough for the short drives once I'm there, but the return trip is going to suck with the repeated stops for recharging, especially with the lack of SuperCharger stations along the way.
Or you could rent a gas-powered car for a few days, allowing you to spend far less on your daily driver while still providing you with full road trip range (and letting you optimize both vehicles; its likely that you'd want a different sized car for each purpose, for example).
When I worked in one inner suburb of a medium-sized city, and lived in another, I commuted about 50km each way, 100km in total, and hence 3000km over the course of a little over a month. Commutes 3-4 times that long are not unheard of in larger cities. But for me, would have meant a battery swap about 10 times a year. I don't know how long the swap should take, but I do know I would not have time to visit a dealer - the closest being about a half hour away - anywhere near that frequently, even if it were a short and painless process.
So don't get one. In other news, people who tow heavy trailers could never use a Camry, yet somehow it's once again the best selling car in the country. Not every new technology needs to solve every problem.
I'm glad that internal combustion engines don't have any kind of fluids that you need to change every few thousand miles then. Just imagine how impossible a situation that would be, especially if failing to change them could actually damage or destroy the engine! Better to stick with the tried and true.
In unrelated news I saw another "jiffy lube" going up down the street from my office. When will the homosexual agenda cease their corruption of young minds?
They've brought a surprising amount of electrical power - first wired, now often solar - to remote parts of the globe simply because refrigeration helps them sell enough more product to make the investment worthwhile. This can be quite a good thing if the infrastructure remains open enough.
If you're truly in a PCI-DSS situation, the last thing you want is to have your server in house. Now your datacenter has to be fully compliant with the PCI physical access guidelines. It'd be a lot easier to lease one somewhere like Rackspace, which is even more expensive than AWS (who provides one of the few cloud environments that's PCI level 1 certified at this point).
1) I guess it goes down until it can be fixed under warranty (same or next day depending on purchase option). Redundancy is expensive.
With Amazon's multi-az, redundancy just costs double whatever your non-redundant primary server costs (or less). Less if you don't mind your backup server being a bit smaller. Getting true hot-spare failover working properly on a database server is a royal PITA. The fact that Amazon will happily sell it to you for $250/mo. is a steal, and far cheaper than actually doing it yourself would be for any significant project.