Why? Because voice processing and searching on the scale of some of the applications such as SIRI require centralized processing. Therefore your voice commands have to be sent someplace else and processed.
At the moment. As the technology improves more and more will be done client side because round-tripping audio is stupid if you could do it locally. If SIRI or something like it was completely local, then there would be no issue. Unfortunately there has been little or no work on practical on-the-spot voice recognition lately because the money is all in spying - be it for surveillance or ads.
It's not like appliance controls are complicated - there's only a handful of "TV: Change channel to ESPN" or "Kettle: Tea, Earl Grey, Hot" phrases that need to be trained in. But since the business models of operators like Nuance are predicated on licensing access to their huge server farms, no other option is even considered except the one that destroys privacy.
We need regulation - no server-side processing of client-side controls. If you could do it locally, then you MUST.
strip clubs...they dont exist in Pakistan, Iran, or North Korea
Oh, you can be sure strip clubs exist there too. It's just that the average Schmoe is not rich enough or well connected enough to swing an invite. The same economic rules apply everywhere: money can buy anything and corrupt religious hypocrites can usually be found living it up in the local red light district.
Note to Chad: The issue is not how accurate the information is or isn't. This issue is that a truly anonymous service has no need for this information.
If you are providing an anonymous service, then accept the incoming socket, provide the service, and then promptly forget everything about the session. If it is logged, those logs can be requested or outright stolen by the world's TLA's. Even performing a GeoIP lookup without logging it has the potential to leak information from your service that can be collected by mass surveillance and correlated with other information.
Do not collect information that is not relevant to the service being provided. Period.
The next thing is you tell me to test getters and setters
You damn well better test the getters and setters. In my experience they are usually the buggiest part of a class. To save time, sooner or later you will cut-and-paste the previous getter/setter pair and modify the name
Yes, because I would just love having to go through regulatory channels and potentially paying fees in order to publish software that I don't even make any money from.
Depends on the regulations: "Commercial software can pick from one of the 5 following standard commercial licenses:
You are then perfectly free to make money from your software. Pick whichever one of the standard licenses suits your purpose and carry on. But what you cannot do is employ a lawyer to invent a creative way to screw your users in the fine print. If you do, your license is automatically torn up and replaced with something sane.
I wonder if anyone actually takes the responsibility to do this check. Maybe there are GCC binaries in the wild which replicate a backdoor.
Even if there were, you need only recompile your gcc source with llvm, icc, visual studio, or basically anything that isn't gcc to get a new compiler that won't replicate the backdoor any more. For extra fun, randomise the order of this compiling that compiling something else so that even backdoor reinsertions that cross the vendor boundary will eventually fail. Or write your own C++ interpreter in Python/Perl/whatever and use it to (very slowly) run gcc on itself - even if it takes a week you'll have a clean binary at the end. Yes, hiding such a backdoor seems scary to the untrained eye. It's also trivial to get rid of if you're paranoid enough to care.
If you want "networked" configuration nodes, an isolated network should be the only thing accessing equipment. That node should not access anything else, or any other networks...
Because those experts are morons. It ignores the economic cost of companies having to run a separate parallel Internet. Take electricity suppliers that need to monitor and control remote switching devices, for example. GSM/CDMA networks are just there, already deployed by the telecommunications industry. A cheap GSM modem and an account with the local telecomms supplier is economically better at contacting remote stations than running ones own wires out to single-point stations in the suburbs and the bush.
Isolated networks also don't work. Putting a dodgy default-passworded device on an internal network doesn't work when your attacker walks up to the remote station, cuts off the padlock, and installs their own device straight onto your wide-open "no one could possibly hack this because it's disconnected" network. Which is basically how Stuxnet got deployed - direct intervention onto a private network at a weak point.
This problem cannot be solved with simplistic "if you don't want people to hack it, don't connect it to the Internet" solutions. How about building it to be difficult to hack in the first place? Or making VPN layers the default way the Internet works rather than an afterthought? Or teaching (mostly non-software) engineers security techniques that were honed over decades of fighting malware on the open Internet? Or any of a million other practical solutions that don't boil down to "la la, I can't hear you so you can't hear me".
As an Android and iOS developer, it is tough to support all possible screen sizes, aspect ratios, hardware specs and versions of Android. Sometimes not having a newer version of Android(>= 4.0) you miss a lot of features that people come to expect and your code is riddle with backwards compatibility stuff just to support Gingerbread, or worse(ie: Donut).
And none of this would be a problem if PBS would simply publish the specification for whatever JSON/XML/etc back end they are using to transmit information to the clients about shows and episodes, and use standard RFC-compatible video formats and streaming protocols with no DRM or other nonsense.
Why would it not be a problem? Because the next day the app stores would be full of "SparkleVideoPlayer now supports PBS!" updates for all of the existing streaming video apps and their loyal users. Or if my screen size, aspect ratio, blah, blah, blah is not supported, I can write my own app!
I can understand why the commercial TV outfits want to control everything - they think it's the only way to poison the experience with ads. But why are public broadcasters like PBS, BBC, and Australia's ABC doling the same thing? It's idiotic - the solution to "how do I support a million devices" is simple: "publish the spec so that the taxpaying public can write their own apps".
Do you need to earn "Crime pays" kind of money to fund college funds for 4 children in America?
I don't know whether he wants his kids to have a good education or whether he thinks they'll make better master criminals with a degree & a job in Wall Street
But at the very least he thinks a child's education is important, which is more than most.
I started using Linux before I got internet or was in a university. I wouldn't have started on Linux (and eventually interned at FSF India) if not for those streams of CDs that were available for a very expensive 100rs (approx 3$ back then).
This wouldn't have been possible without the efforts of toolz. And several others who were behind the curtain (I remember calling up the Digit phone # to ask for help with my i810 video card).
The result was a grass-roots up linux community that sprung up all over India, out of curiousity and tolerating lots of lost partitions.
Both toolz & OldMonk, linux-india old-timers recently lost to us, will not be forgotten (at least by me).