Regardless of the infection, you still need physical access to the APK in question in order to circumvent its security, which seems like a feat in itself. I suppose this is akin to a local security rights elevation. Its a big deal, but doubtfully something that would reach mass infection levels.
Trust me, this Bullshit you arribute to unions happens in non-union shops all the time anyways. Poorly functioning companies and poorly functioning unions both suck all the same. Gripe about unions, but what about the countless companies that have folded up and ended up killing individual's / towns livelihoods because of incompetence or miss-maangement. Its all the same. Lazy/incompetent people find a way to dig in and stay relevant enough to seem valuable. It may be intrinsicly harder to get fired in a union, but you're truely diluded if you think laziness or incompetence is somehow only on that one side of the fence.
A union much like a pilot fish only succeeds to the extent of the host staying alive. Any union worth its salt needs to adapt to the conditions of its industry. Look at movies and most professional sports as some very strage yet still functionally unionized imdustries. A union isn't just a rep stitting in a corner sleaping when they aren't poking your boss's eyes with a stick.
Rewrites vs refactoring are all to common and this pattern is surely nothing new. One way is to design for change up front. This can be accomplished in many ways, but can be vastly simplified by cgood coupling/cohesion, as well as avoiding any kind of fixed constants. It may make initial implementation slower, but it'd leave the system in a better state for change in the future. Of course this flexability can itself lead to greater complexity, so buyer beware.
Ultimately, we all code in different ways at vastly varying backgrounds and skill levels. If coding was just about me, it would do exactly what I want, and it would be quite simple, becase any code that I write (with appropriate comments) -should- be understandable by myself a year or two out. Introducing new people without perfect vision of how I code means there's always complexity. Thats why we establish common patterns. If nothing else they establish a language of coding which one would hope your co-workers understand enough to comprehend.
Eg. In OO, if I have a class has words like Factory, Abstract, DAO/DTO, etc.. a developer should be able to infer the general use for these classes.
If I remember the laws correctly, you either fall into: 1. Gift cards -- Not taxed on sale and are treated as cash in terms of its issuing currency 2. Point systems (like xbox/online games) -- Only convert INTO a virtual currency and can only be used in that world, though they can be exchanged for real things. Since there's no direct way to convert from XBox points back into real money, they are exempt. PS: Are Xbox points even transferable? That would be another important facet of regulation. I don't know if regualtors care if a company is simply holding money. If you want to look at how systems like this getting exploited, look at Pachinko parlors in Japan about the whole three way conversion scams which are basically built to get around gambling restrictions
But your comment over the wieldiness of one over the other baffles me. Fundamentally, Java's futures should operate in the exact same way as C#'s version with the same caveats. Do you know any real world example to help clear up this dissonance?
Once again, its part of the standard library without needing to change the language's syntax. The C# variant does require less typing, but IMHO the Java equivalent makes things a lot more clear in terms of what's going on and how, though thats possibly out of familiarity.
Well, looking it over, it does save on either performance or writing extra boiler plate to create an interator that stores loop processing state itself, but it seems like something that I'd use very sparingly, or more likely end up implementing it in different ways anyways. Leaving the code as such seems finnicky to me considering that either the inner or outer blocks could mutate the control flow (Like iterating over a list while adding/removing entries from it as a side-effect).
And just a side note, taking threads out of the equation, the internal state of the power iterator and its state must be stored somewhere, regardless if you're seeing it or not. Don't get me wrong, the technique seems intreguing, but not something I'd doom a language upon.
For curiosity sakes, can I write nested generators? Now that would be plenty of fun!
"Async methods (huge!)" NIO / NIO2 ? I'm not sure what you're referring to. You can write anything you like with things like Runnable or Executor's. The big limitation is tail processing in java, but there are third party frameworks that make resuming blocks easier (though not a first class language feature). When you introduce this to a top level, you have to handle what to do with that now parked thread stack and how to clean it up when something bad happens. Its not a trivial problem, but hopefully one that lambda expressions will iron out in Java 8.
"Generator methods" I'm assuming you're talking about re-implementing common framework service implementations, and if so Java has a ton of non-standard techniques to do this that most developers work with. It'd be nice if they were more consistent of the implementation though.
"Partial classes/methods" Java 8 roadmap I believe
"Reified generics" Yup, Java needs this
"LINQ (as in LINQ to objects, LINQ to Entities, LINQ to XML - all part of the core framework)" JPQL / CriteriaQuery is the closest thing in JavaEE which do the same thing, though in a more ugly way. The one plus of Java's impl is that they didn't need a core language change to support it. I generally like simpler languages that rely on libraries to enrich vs. stuffing more and more into the core syntax.
"Dynamic typing and -interop" I personally hate this, but there are half a dozen JVM based languages that support it.
"Value types" Overrated and as mentioned in the article fully supportable as long as you create immutable objects. If you want the idea of value objects, create cloner or serialization (which is probably what.NET is doing behind the scenes anyways). Honest question, is the value object copy shallow or deep? Either way could be potentially horrible depending on the usage scenario.
"Operator overloading" Thank fcking god this was never implemented. What a horrible horrible idea than changing the behaviour of +,-, etc.. Leave a method to do 100% the same thing and make it VERY clear wtf is happening vs. burying cleaver code behind common syntax patterns.
"Implicit/explicit type conversions" Same as previous? Why not have.toInt() or toString() vs. burying the magic behind things?
You're right, the article does a pretty accurate reflection of the realities of both systems. I'd love to have runtime generics to work with under very rare conditions, but just as the article mentioned, there are workarounds that lead to slightly less elegant code to do so. Mind you, this is generally only a problem for generalized frameworks more so than day coding tasks, but its still a nice to have.
" Coin's primary use will continue to be in international transactions. While people wonder "When will I be able to pay for groceries and utilities with Bitcoin?", that use might never come. But Coin already shines in international transactions, where it provides a clear advantage over current systems, which are expensive and complicated hassles. That's why PayPal has become the go-to solution: it just works, albeit with typical fees around 3-5%."
The reason why existing systems cost so much and take non-trivial delays is because these systems can be attacked or exploited in ways that cost people real substantial amounts of money. If you see BitCoin carrying millions of dollars of transactions daily / hourly / in minutes, do you still think it'll be the hot sexy magical fairy of transactions that it is now? No, you'll have to raise fees to buff up the infrastructure against attack, and build in extra fees to compensate against fraud, or no legitimate business will deal with it.
There are a ton of bank to bank transfers that are generally a lot slower, but you're all but guaranteed against fraudulent transfers (and the ability to claw back accidental ones). BitCoin may be a fun geek interest area like HAM radios and DIY projects, but the realities of international commerce are fraught with realities that go far beyond any of the problems solved by this technical solution.
Have a patch update install that appends to the hosts file redirecting said offending domain to 127.0.0.1 or the like. At least then you'd be sure most potential users don't get infected..
Well now that Amazon basically has to charge taxes on their sales where appropriate, the boundary between the two is shrinking. Of course Amazon is still ahead and it means that Best Buy actually has to compete head to head.
I'd love to see a business who's pure existence is to give manufacturers a central drop point in towns (reducing their own shipping costs) while allowing for a small amount of store space which can be bought by internet sellers who want some form of physical marketing space.
Assuming it takes about 0.2 kWh to boil one's daily water needs at 365 days == 73kWh per person per year. Even if you assume that only half of the population requires water boiling, that's 175200000 kWh more electricity being expended on boiling water yearly or about 12k US household's current yield which actually doesn't seem so bad as long as the grids are in place to provide it to those that need it, and of course there's the supply of relatively clean desalinated water available (which themselves can add a large overhead).
(can't find a better figure for boiling 1.8 litres, so cherp up if you have a better number, and assumed that there'd be 50% of the roughtly 4800000 more people requiring boiled water)
Yes, so lets talk about merits. Lets say retraining costs are zero and every one of your admin's is a rock star 10 years ahead of the crufty enterprise OS, you still have to deal with: 1. Is the new system cheaper/better for productivity? 2. Will the new system help retain cheaper/better staff? 3. Will the new system help other systems work cheaper/better with this one?
If you can't answer these questions about the new design honestly, you'll start to understand why companies stick to things they know and understand. You'll still see eg. netware based enterprises out there today for no other reason than its a known quantity even though huge parts of their stack are so obsolete even the vendors want to stop supporting the products (but don't stop support because cash is king).
Why is there money to be made by making potential customers more angry at you? Sony got smacked throughout the PS3 because they were king of the hill. Maybe they as a group have actually learned that being smug ass-holes to their customers does not convert to higher sales. They LEARN, well one would hope.
Personally, I won't even consider a console this gen unless it works as an amazing media screener ala xbmc without the crap storm which is DLNA, supports simple 'open' marketplaces that actually support indy dev's to succeed. I'm not holding my breath though.
There is no 'body' in Linux to tackle this problem. The kernel is well managed because by and large its run by one group and they steer with a very clear set of goals. Generally the goals of EVERYONE's use of the kernel is relatively narrow, so there's little need to fork the kernel for any specific work (it usually happens more often as a continuous branch/patch than an actual fork when done).
Now you look into the desktop space, you see many groups operating independently, each of which has philosophical/design/financial/NIH/licensing/etc.. reasons to create another tool vs. using something that people have already invented. You also have the idea that these developers are generally 'chasing innovation' as if they want to invent something that'll be amazing for Z even though we haven't hit X or Y yet.
Ideally, we'd have a world where: 1. Applications were 100% agnostic of Desktop (Any common frameworks would have to be 100% agnostic of desktop, or add very pluggable modular integration so that any desktop could implement)
Eg. If I install Gimp on KDE/XFCE/etc.. desktops, I'd pull in something like this Gimp GnomeDependenyLibraries (small direct use libraries) GTK_compat_common-ui-foundations
Instead, I get Gimp GimpDepenenyLibraies (small direct use libraries) TheKitchenSinkWhichIsMostOfGnome
2. Service layer components should equally be standardized per their function, not per their desktop environment. If they need integration points with the desktop, then as with applications, a clear set of API implementation points should exist to make this straight forward for a desktop developer to implement.
I hate seeing SO many redundant packages being installed because people just don't communicate, or they don't want to use code written by 'those people' or they didn't bother to see that it was already invented, or some other equally pointless meaning. We're generally all adults and we should be doing the mature steps in moving the platform in the right direction. Sadly, unless a very large company comes along and clubs all these other org's over the head with their amazing flexible solution, I don't see things changing any time soon.
Not all users use their desktops the same way. If window groups on by default adds extra complexity for everyone else, then its a lot less appealing for mass adoption. If you can trivially add an extension that does exactly what you need it to, I fail to see the problem with this solution. If I want to add ad-blocking, or development tools, or custom search providers on my web browser, I'm glad that Firefox makes it fast and trivially easy to do so.
Maybe giving a better explorability or curation for commonly used extensions could help that, but honestly I don't use Cinnamon, so I'm not the one to say.
I'll be generous and say there are probably all of 50 generic display device drivers written specifically for X11, probably the same for Apple, and maybe double-triple that for Windows drivers. It isn't exactly a large playing field for development efforts to just pick up from nothing, which is also why 99% of drivers are written by the manufacturer of the device.
You could always look into http://www.x.org/wiki/Development for guidance, but in the end code is king. X Development is not simple, but neither is graphics development in general, which is why every card on the planet has a large set of incompatible surfaces that all get crushed together behind huge drivers in order to spit out a more or less coherent systems interface that a display server will interoperate with.
I'm not philosophically against clean fast code, but to your point my desktops are probably 98% CPU idle when doing a normal workload, and only really pick up when: Playing games, Playing flash, Doing a compile, Running a development server and testing. The age of low level fast optimization is all but dead. For a brief time during the smart phone revolution, pathetic CPU's were a bottle-neck, but with my N4, nothing I throw at it feels slow or choppy. It has 2GB of ram IN A PHONE. Sure limited spec and fit for purpose devices will need fast low level access to optimize, but that takes time, and quite often we're finding that hardware's faster and cheaper than wasting time optimizing for the apex solution.
Take your question again: In 10 years when our entire assortment of devices has as much horsepower as my desktop computer does today, are we really going to need significantly tight processing? I'd say the better long term solution will be making development faster and hopefully more expressive.
Maybe you don't understand the technology. The battery is a POS and its lucky to stay on for 10 seconds when the user isn't actively engaging it, and even then the charge won't last a day. The laws of physics are against your inherent fear of random boogy-men tapping in and recording your every move (at least for the foreseeable future).
So are you afraid of: 1. A company having access to the images 2. Someone (everyone) deciding to FILM YOU 3. Law enforcement someone knowing who / when / where a person was wearing glass at a moment in time at a location in the world in order to capture your picture
At least in the US, there's is no law that says you can't be filmed in public places (distribution is another matter). If you want to talk about people abusing glass, fuck glass. There's off the shelf speciality products that can record your every move more covertly than this tool will ever do. So what exactly is your problem with this product specifically? You should've lobbies your local politicians years ago. Just kill the photography industry entirely, and we can all knit our whicker baskets in peace.
Slashdot Mirror
Pfft... they're just jilted because no girls wanted to lick their eye-balls.
Regardless of the infection, you still need physical access to the APK in question in order to circumvent its security, which seems like a feat in itself. I suppose this is akin to a local security rights elevation. Its a big deal, but doubtfully something that would reach mass infection levels.
Trust me, this Bullshit you arribute to unions happens in non-union shops all the time anyways. Poorly functioning companies and poorly functioning unions both suck all the same. Gripe about unions, but what about the countless companies that have folded up and ended up killing individual's / towns livelihoods because of incompetence or miss-maangement. Its all the same. Lazy/incompetent people find a way to dig in and stay relevant enough to seem valuable. It may be intrinsicly harder to get fired in a union, but you're truely diluded if you think laziness or incompetence is somehow only on that one side of the fence.
A union much like a pilot fish only succeeds to the extent of the host staying alive. Any union worth its salt needs to adapt to the conditions of its industry. Look at movies and most professional sports as some very strage yet still functionally unionized imdustries. A union isn't just a rep stitting in a corner sleaping when they aren't poking your boss's eyes with a stick.
Rewrites vs refactoring are all to common and this pattern is surely nothing new. One way is to design for change up front. This can be accomplished in many ways, but can be vastly simplified by cgood coupling/cohesion, as well as avoiding any kind of fixed constants. It may make initial implementation slower, but it'd leave the system in a better state for change in the future. Of course this flexability can itself lead to greater complexity, so buyer beware.
Ultimately, we all code in different ways at vastly varying backgrounds and skill levels. If coding was just about me, it would do exactly what I want, and it would be quite simple, becase any code that I write (with appropriate comments) -should- be understandable by myself a year or two out. Introducing new people without perfect vision of how I code means there's always complexity. Thats why we establish common patterns. If nothing else they establish a language of coding which one would hope your co-workers understand enough to comprehend.
Eg. In OO, if I have a class has words like Factory, Abstract, DAO/DTO, etc.. a developer should be able to infer the general use for these classes.
If I remember the laws correctly, you either fall into:
1. Gift cards -- Not taxed on sale and are treated as cash in terms of its issuing currency
2. Point systems (like xbox/online games) -- Only convert INTO a virtual currency and can only be used in that world, though they can be exchanged for real things. Since there's no direct way to convert from XBox points back into real money, they are exempt. PS: Are Xbox points even transferable? That would be another important facet of regulation. I don't know if regualtors care if a company is simply holding money. If you want to look at how systems like this getting exploited, look at Pachinko parlors in Japan about the whole three way conversion scams which are basically built to get around gambling restrictions
Visit Singapore and say that again (if you haven't been arrested mind you).
Java does have them:
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html
But your comment over the wieldiness of one over the other baffles me. Fundamentally, Java's futures should operate in the exact same way as C#'s version with the same caveats. Do you know any real world example to help clear up this dissonance?
Once again, its part of the standard library without needing to change the language's syntax. The C# variant does require less typing, but IMHO the Java equivalent makes things a lot more clear in terms of what's going on and how, though thats possibly out of familiarity.
Well, looking it over, it does save on either performance or writing extra boiler plate to create an interator that stores loop processing state itself, but it seems like something that I'd use very sparingly, or more likely end up implementing it in different ways anyways. Leaving the code as such seems finnicky to me considering that either the inner or outer blocks could mutate the control flow (Like iterating over a list while adding/removing entries from it as a side-effect).
And just a side note, taking threads out of the equation, the internal state of the power iterator and its state must be stored somewhere, regardless if you're seeing it or not. Don't get me wrong, the technique seems intreguing, but not something I'd doom a language upon.
For curiosity sakes, can I write nested generators? Now that would be plenty of fun!
"Async methods (huge!)"
NIO / NIO2 ? I'm not sure what you're referring to. You can write anything you like with things like Runnable or Executor's. The big limitation is tail processing in java, but there are third party frameworks that make resuming blocks easier (though not a first class language feature). When you introduce this to a top level, you have to handle what to do with that now parked thread stack and how to clean it up when something bad happens. Its not a trivial problem, but hopefully one that lambda expressions will iron out in Java 8.
"Generator methods"
I'm assuming you're talking about re-implementing common framework service implementations, and if so Java has a ton of non-standard techniques to do this that most developers work with. It'd be nice if they were more consistent of the implementation though.
"Partial classes/methods"
Java 8 roadmap I believe
"Reified generics"
Yup, Java needs this
"LINQ (as in LINQ to objects, LINQ to Entities, LINQ to XML - all part of the core framework)"
JPQL / CriteriaQuery is the closest thing in JavaEE which do the same thing, though in a more ugly way. The one plus of Java's impl is that they didn't need a core language change to support it. I generally like simpler languages that rely on libraries to enrich vs. stuffing more and more into the core syntax.
"Dynamic typing and -interop"
I personally hate this, but there are half a dozen JVM based languages that support it.
"Value types" .NET is doing behind the scenes anyways). Honest question, is the value object copy shallow or deep? Either way could be potentially horrible depending on the usage scenario.
Overrated and as mentioned in the article fully supportable as long as you create immutable objects. If you want the idea of value objects, create cloner or serialization (which is probably what
"Operator overloading"
Thank fcking god this was never implemented. What a horrible horrible idea than changing the behaviour of +,-, etc.. Leave a method to do 100% the same thing and make it VERY clear wtf is happening vs. burying cleaver code behind common syntax patterns.
"Implicit/explicit type conversions" .toInt() or toString() vs. burying the magic behind things?
Same as previous? Why not have
You're right, the article does a pretty accurate reflection of the realities of both systems. I'd love to have runtime generics to work with under very rare conditions, but just as the article mentioned, there are workarounds that lead to slightly less elegant code to do so. Mind you, this is generally only a problem for generalized frameworks more so than day coding tasks, but its still a nice to have.
" Coin's primary use will continue to be in international transactions. While people wonder "When will I be able to pay for groceries and utilities with Bitcoin?", that use might never come. But Coin already shines in international transactions, where it provides a clear advantage over current systems, which are expensive and complicated hassles. That's why PayPal has become the go-to solution: it just works, albeit with typical fees around 3-5%."
The reason why existing systems cost so much and take non-trivial delays is because these systems can be attacked or exploited in ways that cost people real substantial amounts of money. If you see BitCoin carrying millions of dollars of transactions daily / hourly / in minutes, do you still think it'll be the hot sexy magical fairy of transactions that it is now? No, you'll have to raise fees to buff up the infrastructure against attack, and build in extra fees to compensate against fraud, or no legitimate business will deal with it.
There are a ton of bank to bank transfers that are generally a lot slower, but you're all but guaranteed against fraudulent transfers (and the ability to claw back accidental ones). BitCoin may be a fun geek interest area like HAM radios and DIY projects, but the realities of international commerce are fraught with realities that go far beyond any of the problems solved by this technical solution.
Self managed OS based hosting entirely from the internet (no physical access). That's it bud. Anything else is just window dressing.
Have a patch update install that appends to the hosts file redirecting said offending domain to 127.0.0.1 or the like. At least then you'd be sure most potential users don't get infected..
Well now that Amazon basically has to charge taxes on their sales where appropriate, the boundary between the two is shrinking. Of course Amazon is still ahead and it means that Best Buy actually has to compete head to head.
I'd love to see a business who's pure existence is to give manufacturers a central drop point in towns (reducing their own shipping costs) while allowing for a small amount of store space which can be bought by internet sellers who want some form of physical marketing space.
Assuming it takes about 0.2 kWh to boil one's daily water needs at 365 days == 73kWh per person per year. Even if you assume that only half of the population requires water boiling, that's 175200000 kWh more electricity being expended on boiling water yearly or about 12k US household's current yield which actually doesn't seem so bad as long as the grids are in place to provide it to those that need it, and of course there's the supply of relatively clean desalinated water available (which themselves can add a large overhead).
(can't find a better figure for boiling 1.8 litres, so cherp up if you have a better number, and assumed that there'd be 50% of the roughtly 4800000 more people requiring boiled water)
Yes, so lets talk about merits. Lets say retraining costs are zero and every one of your admin's is a rock star 10 years ahead of the crufty enterprise OS, you still have to deal with:
1. Is the new system cheaper/better for productivity?
2. Will the new system help retain cheaper/better staff?
3. Will the new system help other systems work cheaper/better with this one?
If you can't answer these questions about the new design honestly, you'll start to understand why companies stick to things they know and understand. You'll still see eg. netware based enterprises out there today for no other reason than its a known quantity even though huge parts of their stack are so obsolete even the vendors want to stop supporting the products (but don't stop support because cash is king).
Why is there money to be made by making potential customers more angry at you? Sony got smacked throughout the PS3 because they were king of the hill. Maybe they as a group have actually learned that being smug ass-holes to their customers does not convert to higher sales. They LEARN, well one would hope.
Personally, I won't even consider a console this gen unless it works as an amazing media screener ala xbmc without the crap storm which is DLNA, supports simple 'open' marketplaces that actually support indy dev's to succeed. I'm not holding my breath though.
How can we flame you if there's no story!! Wahh!
There is no 'body' in Linux to tackle this problem. The kernel is well managed because by and large its run by one group and they steer with a very clear set of goals. Generally the goals of EVERYONE's use of the kernel is relatively narrow, so there's little need to fork the kernel for any specific work (it usually happens more often as a continuous branch/patch than an actual fork when done).
Now you look into the desktop space, you see many groups operating independently, each of which has philosophical/design/financial/NIH/licensing/etc.. reasons to create another tool vs. using something that people have already invented. You also have the idea that these developers are generally 'chasing innovation' as if they want to invent something that'll be amazing for Z even though we haven't hit X or Y yet.
Ideally, we'd have a world where:
1. Applications were 100% agnostic of Desktop (Any common frameworks would have to be 100% agnostic of desktop, or add very pluggable modular integration so that any desktop could implement)
Eg. If I install Gimp on KDE/XFCE/etc.. desktops, I'd pull in something like this
Gimp
GnomeDependenyLibraries (small direct use libraries)
GTK_compat_common-ui-foundations
Instead, I get
Gimp
GimpDepenenyLibraies (small direct use libraries)
TheKitchenSinkWhichIsMostOfGnome
2. Service layer components should equally be standardized per their function, not per their desktop environment. If they need integration points with the desktop, then as with applications, a clear set of API implementation points should exist to make this straight forward for a desktop developer to implement.
I hate seeing SO many redundant packages being installed because people just don't communicate, or they don't want to use code written by 'those people' or they didn't bother to see that it was already invented, or some other equally pointless meaning. We're generally all adults and we should be doing the mature steps in moving the platform in the right direction. Sadly, unless a very large company comes along and clubs all these other org's over the head with their amazing flexible solution, I don't see things changing any time soon.
Not all users use their desktops the same way. If window groups on by default adds extra complexity for everyone else, then its a lot less appealing for mass adoption. If you can trivially add an extension that does exactly what you need it to, I fail to see the problem with this solution. If I want to add ad-blocking, or development tools, or custom search providers on my web browser, I'm glad that Firefox makes it fast and trivially easy to do so.
Maybe giving a better explorability or curation for commonly used extensions could help that, but honestly I don't use Cinnamon, so I'm not the one to say.
I'll be generous and say there are probably all of 50 generic display device drivers written specifically for X11, probably the same for Apple, and maybe double-triple that for Windows drivers. It isn't exactly a large playing field for development efforts to just pick up from nothing, which is also why 99% of drivers are written by the manufacturer of the device.
You could always look into http://www.x.org/wiki/Development for guidance, but in the end code is king. X Development is not simple, but neither is graphics development in general, which is why every card on the planet has a large set of incompatible surfaces that all get crushed together behind huge drivers in order to spit out a more or less coherent systems interface that a display server will interoperate with.
I'm not philosophically against clean fast code, but to your point my desktops are probably 98% CPU idle when doing a normal workload, and only really pick up when: Playing games, Playing flash, Doing a compile, Running a development server and testing. The age of low level fast optimization is all but dead. For a brief time during the smart phone revolution, pathetic CPU's were a bottle-neck, but with my N4, nothing I throw at it feels slow or choppy. It has 2GB of ram IN A PHONE. Sure limited spec and fit for purpose devices will need fast low level access to optimize, but that takes time, and quite often we're finding that hardware's faster and cheaper than wasting time optimizing for the apex solution.
Take your question again: In 10 years when our entire assortment of devices has as much horsepower as my desktop computer does today, are we really going to need significantly tight processing? I'd say the better long term solution will be making development faster and hopefully more expressive.
Maybe you don't understand the technology. The battery is a POS and its lucky to stay on for 10 seconds when the user isn't actively engaging it, and even then the charge won't last a day. The laws of physics are against your inherent fear of random boogy-men tapping in and recording your every move (at least for the foreseeable future).
So are you afraid of:
1. A company having access to the images
2. Someone (everyone) deciding to FILM YOU
3. Law enforcement someone knowing who / when / where a person was wearing glass at a moment in time at a location in the world in order to capture your picture
I just don't get your rampant paranoia, sorry.
At least in the US, there's is no law that says you can't be filmed in public places (distribution is another matter). If you want to talk about people abusing glass, fuck glass. There's off the shelf speciality products that can record your every move more covertly than this tool will ever do. So what exactly is your problem with this product specifically? You should've lobbies your local politicians years ago. Just kill the photography industry entirely, and we can all knit our whicker baskets in peace.