Consider that there are basically two types of users, where privacy is concerned: people who are oblivious and/or don't care about their privacy, and people who try to preserve some of their privacy. For the former group, this change will not affect their app usage, and will make it easier for them to get app updates automatically, which will make their experience better. For the latter group, the Android developers are actively hostile toward your privacy desires, have no desire to help you, and in fact probably _want_ to drive you away from the platform. In both cases, it's a win for Android, the "all your data belongs to us and everyone else, and there isn't anything you can do about it" platform.
I personally think there's a market for platforms which allow some privacy (Apple does a much better, but still imperfect, job of this), but I acknowledge that there's also a market (and probably a larger one) for platforms which cater to people who share all their personal data with everyone, and are totally oblivious to what any/all of their apps are doing behind their backs. Google is making it crystal clear which type of platform Android, and their other services (see also: Nearby), will be.
Questionable, in the sense that the theory is a very speculative extrapolation of the data we have been able to observe, about the origins of the universe before the "time" we can actually observe. Just because something fits a mathematical model doesn't mean we have solid evidence for it; it simply means it's a model which matches what we've been able to [indirectly] observe. You could say the same thing about n-dimensional string theory as a unified model, for example.
It's gratifying to see that the public's general acceptance of scientific theories is roughly proportional to the actual evidence to support the theories themselves. For things which there is good evidence, there is broad understanding; for things which are highly questionable and politicized, there is much skepticism.
It is an interesting conceptual argument, although it ignores a couple a real-world points.
First, not all bugs are equal, in terms of exploitation opportunity, as he's glossing over; the vulnerability is only as valuable as what it can be exploited to allow access to, in monetary exploitation terms. A bug in something which cannot be exploited for any particular gain is next to worthless, in market terms.
Second, not all companies will pay for vulnerability information, because it's not just a value proposition, but also a risk and resources assessment. If nobody expects your software to be "secure", there's no point is spending too much money on software security; for example, nobody pays much attention to the software in cars (yet), so manufacturers have little financial incentive to make it secure. Moreover, if you don't have deep pockets, you're not going to pay for exploits, especially if you're struggling to simply produce features that potential customers want. In either of those scenarios, the value proposition for paying for exploits is inconsequential.
Most (by volume) software has an effectively unlimited amount of bugs, which nobody will pay for. That's the real world of software.
In my profession, there are certainly certifications one can get, and ethical considerations (as a general statement), although there is no particular licensing. Regardless of these, though, I am employed to write software, but I would not certify that the software I write is flaw-free (nor would anyone else that I know). It's entirely possible that, due to flaws in my work product, someone will lose money, or have other negative outcomes befall them.
If that happened, and my employer blamed me publicly (explicitly or implicitly), I would be seeking large monetary damages, even if the flaw was my fault. My argument would be that I'm employed to write software, not write flaw-free software, and if the company causes me damages (in current or future income) by stating or implying that I did not perform by work duties appropriately, then that is slander, and they are liable. In this case, the "lie" would be to imply that my work product was supposed to be flaw-free, which I never asserted or consented to, regardless of what they desired. Implying that someone is unable to perform one's occupation is textbook slander, and the company would find themselves writing a large check. And yes, even naming the engineer in this context, without strong evidence of gross or malicious negligence, would be cause for civil penalty (imho).
I guess it just comes down to this: there are laws which protect people from having their lives and/or livelihood ruined by false accusation (direct or implied), and implying that an engineer must create a flaw-free work product to be proficient is a false accusation (unless there's a specific contractual obligation to do so, and that would seem suspicious). If I were a company considering this, I'd think twice, and then not expose myself to the obvious liability.
I could see two potential outcomes, if blaming engineers for product flaws becomes commonplace...
First, engineers will (or should) demand an indemnity clause as part of their employment contract, where the company agrees not to blame them publicly for any product flaws, and/or take any action which would identify them. Depending on the repercussions for the test cases, this might become a necessity for employees.
Second, I could see some significant lawsuits for slander, since the company is causing real (and substantial, and more importantly provable) financial loss for the engineers they blame for product deficiencies. Unless they have a pretty solid intentional negligence defense, they could (and absolutely should) find themselves paying out a few million more to each engineer they throw under the metaphorical bus.
Companies are responsible for their products, not the people they employ to make/provide them. Companies reap the rewards when they work, and bear the responsibility when they don't. Absent malicious negligence, naming/blaming individual employees is irresponsible at best, and should absolutely expose the company to civil liability.
This may seem infeasible and/or culture-prohibitive, but there's another way Microsoft could go, which could see them gaining market share in mobile, and perhaps even surpassing google/Apple eventually.
Instead of trying to figure out how to optimally leverage the technology and assets they currently have (Nokia, Office, Windows Phone, patents, etc.) to optimize their own profit, as they have been doing for the last decade or so, they could try something new: building something which actual customers want. I know it's somewhat unheard of in the age of big companies, patent portfolios, and quarterly reports, but anyone who think there's not substantial room for innovation in virtually all aspects of the mobile space is simply not trying to think.
Microsoft had (and still has remnants of) the technical might to pursue multiple avenues of innovation at the same time. If they could simply change focus away from brow-beating their reluctant customers with their latest profit-optimized business plan, and toward giving customers what they actually want (here's a free hint: a phone where you are in control of where your data is, and what apps can access it), they could still do quite well. If they continue their current business mindset, though, it won't matter what they pick to focus on: eventually, they will be toast.
That's what I "love" about my "representative": never afraid to state the blindingly obvious, while completely and derisively ignoring the will of the people she nominally speaks for. Of course the government is not going to willingly give up their police-state surveillance powers; governments never give up power they have taken, legally or otherwise. Blah blah, security, protection, something about terrorism, etc.
Just to point at one example: Elementary. The commercial volume is consistently MUCH higher than the show volume, which itself fluctuates enough during the show to make it annoying to watch. If the FCC really wanted results, they could just have some automated application "listening" to programs, and fining broadcasters automatically, rather than judging effectiveness based on quantity of people with enough time to waste to go through their complaint process. Based on how easy that is, I'd say they have no desire to actually help anyone.
I would expand on the designing things point: it's not just matching requirements with implementation, but also designing something which will still work 10 years and 20+ design and technology iterations from now. It's designing something to anticipate future changes, and code in flexibility where appropriate. It's making something which doesn't just perform the function, but doesn't have subtle flaws which will cause very hard to diagnose issues down the road. It's building code which will still be maintainable, even after various future iterations. The ability to design code properly is what differentiates between a "normal" developer, and and extraordinary one.
No worries, the Kinect only needs to be connected and powered on for the system to function, you can "turn it off" (in software), and it won't do "anything" [that you can see]. Moreover, the XBone doesn't need an always-on internet connection, so even if it were watching your every move and listening to you 24/7, it wouldn't be uploading that information until the next time you connected. And even if it were secretly doing that, Microsoft wouldn't be sharing that data with the government unless legally required to. And even if we were sharing the data voluntarily through a well-documented Prism access tunnel, you have nothing to worry about unless you are a terrorist. And you're not a terrorist, are you?
The system could be fixed trivially, if people cared to do so. For example, add a provision to the law which allows an affirmative defense of independent discovery; after all, an innovation worthy of a patent is supposed to be innovative enough that other people cannot just stumble upon it through normal evolutionary work. That would put the onus on the patent holder to prove that the patent information was accessed by the accused-infringer during development, which would make it substantially harder for patent trolls to exist (that is, it's much easier to assert that you didn't see the patented item in the Patent Office publications, than in a competitor's widely distributed implementation).
The fact that it's not fixed points to malfeasance on the part of Congress, as much as private individuals taking advantage of the system.
(I work in a small but successful company as the lead developer.)
To be honest, most companies produce fairly bad software, fairly inefficiently, and you really don't need really good developers to do that. You can make a good amount of money just supporting existing products someone wrote a while ago, adding small improvements for marketing purposes, and/or writing something which is not particularly complicated, but profitable (see: 95% of apps for mobile, internal enterprise apps/scripts, template-based web sites, etc.).
You need "rock star" developers for only a few things: - Doing cutting-edge research type programming and/or optimization (eg: DB design work, compiler design, optimizing embedded firmware, etc.) - Doing necessarily complex functionality, and only if you _need_ it (eg: highly multi-threaded apps, lock-free programming, etc.) - High-level design, organization, and/or refactoring for large/critical projects (eg: re-organizing the Windows/Linux kernels) - Writing "optimal-to-maintain" code to do more with less people/time/resources (eg: having less than five people writing and supporting high value, expansive enterprise apps)
If you don't have one of those cases, "normal" developers will probably be fine (assuming reasonable management and organization structure). My 2c.
Based on (at least) the Barry Bonds prosecution by Congress, any potential witness should be able to assert their 5th Amendment right. Why? Because in that case, it was established that the government could prosecute you solely for your testimony, if they felt your testimony was not revealing enough, regardless of how accurate it was.
Under that precedent, it would be impossible to give any testimony without potentially incriminating yourself. Thus, you have a 5th Amendment right to refuse to offer testimony (unless the state offered you transactional immunity at all government levels for anything arising from your testimony, which would be highly unlikely). I'm somewhat surprised more people haven't realized the implications of that prosecution, but it seems pretty clear-cut to me.
Thoughts on a way to fix this sort of thing generally:
The government should define a minimum support window for software, say 5 years or so. From the point where you purchase a software product at retail (not resold), you are entitled to support for critical security flaws (ie: exploitable risks which you cannot mitigate with normal usage) during that period. At the vendor's option, that support can be either free software patches (with no degradation of functionality or additional licensing requirements/terms), full version upgrades (under the same conditions), or the release of the complete source for the product into the public domain (BSD-style). The last option would be the legally-mandated requirement if the vendor was unwilling or unable to supply one of the first alternatives. Companies could, of course, adjust pricing of their software as appropriate to comply with the mandate.
It's not a very clean solution, but it would do wonders to curtail the "forced paid upgrade" trend in software. Plus, companies with "good" support policies in place (both large and small) would benefit.
(Note: Developer, small dev shop, higher-priced software, same situation.)
If you distribute an "unlimited" version, this will be what is pirated; there's no value in having different versions. Also, if you have a key which allows "unlimited" access without secondary verification, this is what will be distributed on pirate sites.
In our experience, it took about a week from changing the key format to a new crack key being distributed. Obviously, this is for software which is "in-demand", but don't expect that implementing a new scheme with the same underlying characteristics will buy you much time.
For "good" protection, you basically need secondary verification which is "hard" to fake. Currently, that is hardware dongles or an online verification loop. Both of these can be pains for the users, costly for you, and/or prohibitive in some environments (online, in particular, doesn't play nice with classified government envs).
Keep in mind also: most people who pirate are not potential customers, at least at anything close to full price, but their experience using the tool may turn into a sale at a company later.
My suggestion: do what you can to track usage, but don't be overly obtrusive and/or try to prevent all piracy usage. Being able to watch and track, and act when appropriate, is much better than trying to prevent all piracy.
I'd upvote this more if I could. As someone who both codes for a living and hires engineers to do the same, what you are describing is exactly what I look for in an engineer. You can become familiar with more tools and methods, but at the end of the day, you [just] need to be able to solve problems well. The only additional challenge in the "real world" is breaking down larger problems, and solving them in "better" ways (ie: fits better with the rest of the system, is maintainable, is flexible, etc.).
Also, to add to this, the tools for creating eBooks (at least Kindle books) are pretty awful. For example, the "recommended" method uses a two-stage conversion, with a third-party app which isn't even supported any more. All the conversion paths mangle any custom formatting, in different (and seemingly unpredictable) ways, and generate "messy" HTML for everything. Alternatively, you can hand-edit HTML, and manually create any extra parts (eg: the TOC), because there are no automatic mechanisms to support features that office apps have had for literally decades.
As someone who has published an eBook on Kindle, I can tell you that it looks "bare bones". It looks better in google docs where I wrote it, but it was a PITA to just get it into Kindle format, and the tooling to "make it nice" without lots of additional effort was just not there. If Amazon et all could address that problem, it might go a long way toward getting nicer looking eBooks.
I think the brain teaser has a place, but mainly to gauge how someone approaches and thinks through a problem, not for any specific answer. I agree with the OP, though: real code and big picture thinking is the best indicator of longer-term success. On the other hand, you can be a good coder without big picture thinking too, especially in a larger organization with good engineering management.
Personally, I look for people who know how to code (ie: can answer intermediate questions), understand what the code is doing (eg: in C++, why you normally use virtual destructors, but in what conditions you may not want to), and can think through problems (ie: here's an arbitrary hypothetical problem, tell me how you solve it). If you can do those things, you can be a productive developer; the rest (eg: specific knowledge, familiarity with tools/paradigms, coding trivia, etc.) is gravy.
I do think this is valuable information, but it doesn't go far enough. You should be able to filter apps by permissions as well, on platforms which support per-operation permissions for applications.
You know what would be even better, though? If the per-operation permissions were settable on a per-application basis, and then spoofed/failed if the app can't work without it. There are plenty of apps that I want to use, but require extraneous permissions for things I don't care about, and/or don't want the app to access. If someone could build a platform which put the permission usage into the user's hands (even as an Android variant, for example), that would be awesome.
Not just local law enforcement. Any government entity, law enforcement or otherwise, without the bothersome inconvenience of probably cause, warrants, or any of that other pre-telematics nonsense. Hope you're not engaging in any activities which the government might think are supportive of terrorists (like, say, talking about seditious thoughts).
The fact that people buy cars equipped with OnStar is either a sign that we deserve our oppressive government, or is a testimony to the ignorance of the voting public...
I don't think the marketing is anything more than typical marketing optimism/BS, but to be fair...
If someone could make a smartphone that: - Had a smooth ease-of-use of an iPhone - Didn't require you to root it to fully customize it - Didn't pack it with carrier bloatware - Had good battery life and talk quality without building/flashing your own custom ROM - Had lots of free and/or nearly free apps to cover common usage scenarios - Guaranteed to respect your privacy (no CarrierIQ, tracking, logging, etc.)... you could probably sell it pretty well. There's not a snowball's chance in hell that Microsoft/Nokia will produce such a phone, but it's true to say that there is a large-ish market which is being largely under-served by the current smart-phone offerings.
(Disclosure: I have a relationship with Lieberman Software, although I was not involved in this survey.)
Just because the company initiating the survey has a business interest related to the subject material doesn't mean the results are inherently BS. Sure, you should be skeptical, but to call BS purely due to bias seems... misguided.
For example, you readily state that you have access to shared passwords; thus, you would be included in the affirmative for the first question quoted. Presumably you wouldn't know if other co-workers thought you or other admins had misused access, but if so, then perhaps the second as well. You sound fairly security-conscious, so I'll assume your organization would not be included in the third... unless perhaps other admins are not as diligent as you (which, I realize, never happens in large organizations, but consider the hypothetical). Are the results of the survey really that hard to believe?
Sure, Lieberman Software is selling stuff, but it's not like they are trying to hide it, or hide behind proxy "unbiased" survey organizations. Read the info with a critical eye as appropriate, but calling BS due to non-obfuscated bias is as bad as believing the info on face value.
There's some humor on the page for browser features, if you're using a browser without Flash installed/enabled. The #1 "bad" item is Dangerous Downloads, just to the left of the prompt to download/install Flash. I lol-ed.
+1 for this (if I could). G+ was a good idea, right up until the point that google decided it wanted to create something more privacy-repugnant than even FB. I think a lot of people liked the idea before they clarified their intentions, but afterward it became clear that all the paradigm changes in the world could not overcome the basic design choice to be evil.
Slashdot Mirror
This could turn out to be a good thing, imho.
Consider that there are basically two types of users, where privacy is concerned: people who are oblivious and/or don't care about their privacy, and people who try to preserve some of their privacy. For the former group, this change will not affect their app usage, and will make it easier for them to get app updates automatically, which will make their experience better. For the latter group, the Android developers are actively hostile toward your privacy desires, have no desire to help you, and in fact probably _want_ to drive you away from the platform. In both cases, it's a win for Android, the "all your data belongs to us and everyone else, and there isn't anything you can do about it" platform.
I personally think there's a market for platforms which allow some privacy (Apple does a much better, but still imperfect, job of this), but I acknowledge that there's also a market (and probably a larger one) for platforms which cater to people who share all their personal data with everyone, and are totally oblivious to what any/all of their apps are doing behind their backs. Google is making it crystal clear which type of platform Android, and their other services (see also: Nearby), will be.
Questionable, in the sense that the theory is a very speculative extrapolation of the data we have been able to observe, about the origins of the universe before the "time" we can actually observe. Just because something fits a mathematical model doesn't mean we have solid evidence for it; it simply means it's a model which matches what we've been able to [indirectly] observe. You could say the same thing about n-dimensional string theory as a unified model, for example.
It's gratifying to see that the public's general acceptance of scientific theories is roughly proportional to the actual evidence to support the theories themselves. For things which there is good evidence, there is broad understanding; for things which are highly questionable and politicized, there is much skepticism.
Good for the US population. :)
It is an interesting conceptual argument, although it ignores a couple a real-world points.
First, not all bugs are equal, in terms of exploitation opportunity, as he's glossing over; the vulnerability is only as valuable as what it can be exploited to allow access to, in monetary exploitation terms. A bug in something which cannot be exploited for any particular gain is next to worthless, in market terms.
Second, not all companies will pay for vulnerability information, because it's not just a value proposition, but also a risk and resources assessment. If nobody expects your software to be "secure", there's no point is spending too much money on software security; for example, nobody pays much attention to the software in cars (yet), so manufacturers have little financial incentive to make it secure. Moreover, if you don't have deep pockets, you're not going to pay for exploits, especially if you're struggling to simply produce features that potential customers want. In either of those scenarios, the value proposition for paying for exploits is inconsequential.
Most (by volume) software has an effectively unlimited amount of bugs, which nobody will pay for. That's the real world of software.
Well, speaking as a [software] engineer...
In my profession, there are certainly certifications one can get, and ethical considerations (as a general statement), although there is no particular licensing. Regardless of these, though, I am employed to write software, but I would not certify that the software I write is flaw-free (nor would anyone else that I know). It's entirely possible that, due to flaws in my work product, someone will lose money, or have other negative outcomes befall them.
If that happened, and my employer blamed me publicly (explicitly or implicitly), I would be seeking large monetary damages, even if the flaw was my fault. My argument would be that I'm employed to write software, not write flaw-free software, and if the company causes me damages (in current or future income) by stating or implying that I did not perform by work duties appropriately, then that is slander, and they are liable. In this case, the "lie" would be to imply that my work product was supposed to be flaw-free, which I never asserted or consented to, regardless of what they desired. Implying that someone is unable to perform one's occupation is textbook slander, and the company would find themselves writing a large check. And yes, even naming the engineer in this context, without strong evidence of gross or malicious negligence, would be cause for civil penalty (imho).
I guess it just comes down to this: there are laws which protect people from having their lives and/or livelihood ruined by false accusation (direct or implied), and implying that an engineer must create a flaw-free work product to be proficient is a false accusation (unless there's a specific contractual obligation to do so, and that would seem suspicious). If I were a company considering this, I'd think twice, and then not expose myself to the obvious liability.
I could see two potential outcomes, if blaming engineers for product flaws becomes commonplace...
First, engineers will (or should) demand an indemnity clause as part of their employment contract, where the company agrees not to blame them publicly for any product flaws, and/or take any action which would identify them. Depending on the repercussions for the test cases, this might become a necessity for employees.
Second, I could see some significant lawsuits for slander, since the company is causing real (and substantial, and more importantly provable) financial loss for the engineers they blame for product deficiencies. Unless they have a pretty solid intentional negligence defense, they could (and absolutely should) find themselves paying out a few million more to each engineer they throw under the metaphorical bus.
Companies are responsible for their products, not the people they employ to make/provide them. Companies reap the rewards when they work, and bear the responsibility when they don't. Absent malicious negligence, naming/blaming individual employees is irresponsible at best, and should absolutely expose the company to civil liability.
This may seem infeasible and/or culture-prohibitive, but there's another way Microsoft could go, which could see them gaining market share in mobile, and perhaps even surpassing google/Apple eventually.
Instead of trying to figure out how to optimally leverage the technology and assets they currently have (Nokia, Office, Windows Phone, patents, etc.) to optimize their own profit, as they have been doing for the last decade or so, they could try something new: building something which actual customers want. I know it's somewhat unheard of in the age of big companies, patent portfolios, and quarterly reports, but anyone who think there's not substantial room for innovation in virtually all aspects of the mobile space is simply not trying to think.
Microsoft had (and still has remnants of) the technical might to pursue multiple avenues of innovation at the same time. If they could simply change focus away from brow-beating their reluctant customers with their latest profit-optimized business plan, and toward giving customers what they actually want (here's a free hint: a phone where you are in control of where your data is, and what apps can access it), they could still do quite well. If they continue their current business mindset, though, it won't matter what they pick to focus on: eventually, they will be toast.
That's what I "love" about my "representative": never afraid to state the blindingly obvious, while completely and derisively ignoring the will of the people she nominally speaks for. Of course the government is not going to willingly give up their police-state surveillance powers; governments never give up power they have taken, legally or otherwise. Blah blah, security, protection, something about terrorism, etc.
Just to point at one example: Elementary. The commercial volume is consistently MUCH higher than the show volume, which itself fluctuates enough during the show to make it annoying to watch. If the FCC really wanted results, they could just have some automated application "listening" to programs, and fining broadcasters automatically, rather than judging effectiveness based on quantity of people with enough time to waste to go through their complaint process. Based on how easy that is, I'd say they have no desire to actually help anyone.
I agree with the list, generally-speaking.
I would expand on the designing things point: it's not just matching requirements with implementation, but also designing something which will still work 10 years and 20+ design and technology iterations from now. It's designing something to anticipate future changes, and code in flexibility where appropriate. It's making something which doesn't just perform the function, but doesn't have subtle flaws which will cause very hard to diagnose issues down the road. It's building code which will still be maintainable, even after various future iterations. The ability to design code properly is what differentiates between a "normal" developer, and and extraordinary one.
IMHO, anyway.
No worries, the Kinect only needs to be connected and powered on for the system to function, you can "turn it off" (in software), and it won't do "anything" [that you can see]. Moreover, the XBone doesn't need an always-on internet connection, so even if it were watching your every move and listening to you 24/7, it wouldn't be uploading that information until the next time you connected. And even if it were secretly doing that, Microsoft wouldn't be sharing that data with the government unless legally required to. And even if we were sharing the data voluntarily through a well-documented Prism access tunnel, you have nothing to worry about unless you are a terrorist. And you're not a terrorist, are you?
The system could be fixed trivially, if people cared to do so. For example, add a provision to the law which allows an affirmative defense of independent discovery; after all, an innovation worthy of a patent is supposed to be innovative enough that other people cannot just stumble upon it through normal evolutionary work. That would put the onus on the patent holder to prove that the patent information was accessed by the accused-infringer during development, which would make it substantially harder for patent trolls to exist (that is, it's much easier to assert that you didn't see the patented item in the Patent Office publications, than in a competitor's widely distributed implementation).
The fact that it's not fixed points to malfeasance on the part of Congress, as much as private individuals taking advantage of the system.
(I work in a small but successful company as the lead developer.)
To be honest, most companies produce fairly bad software, fairly inefficiently, and you really don't need really good developers to do that. You can make a good amount of money just supporting existing products someone wrote a while ago, adding small improvements for marketing purposes, and/or writing something which is not particularly complicated, but profitable (see: 95% of apps for mobile, internal enterprise apps/scripts, template-based web sites, etc.).
You need "rock star" developers for only a few things:
- Doing cutting-edge research type programming and/or optimization (eg: DB design work, compiler design, optimizing embedded firmware, etc.)
- Doing necessarily complex functionality, and only if you _need_ it (eg: highly multi-threaded apps, lock-free programming, etc.)
- High-level design, organization, and/or refactoring for large/critical projects (eg: re-organizing the Windows/Linux kernels)
- Writing "optimal-to-maintain" code to do more with less people/time/resources (eg: having less than five people writing and supporting high value, expansive enterprise apps)
If you don't have one of those cases, "normal" developers will probably be fine (assuming reasonable management and organization structure). My 2c.
I am not a lawyer, but...
Based on (at least) the Barry Bonds prosecution by Congress, any potential witness should be able to assert their 5th Amendment right. Why? Because in that case, it was established that the government could prosecute you solely for your testimony, if they felt your testimony was not revealing enough, regardless of how accurate it was.
Under that precedent, it would be impossible to give any testimony without potentially incriminating yourself. Thus, you have a 5th Amendment right to refuse to offer testimony (unless the state offered you transactional immunity at all government levels for anything arising from your testimony, which would be highly unlikely). I'm somewhat surprised more people haven't realized the implications of that prosecution, but it seems pretty clear-cut to me.
Thoughts on a way to fix this sort of thing generally:
The government should define a minimum support window for software, say 5 years or so. From the point where you purchase a software product at retail (not resold), you are entitled to support for critical security flaws (ie: exploitable risks which you cannot mitigate with normal usage) during that period. At the vendor's option, that support can be either free software patches (with no degradation of functionality or additional licensing requirements/terms), full version upgrades (under the same conditions), or the release of the complete source for the product into the public domain (BSD-style). The last option would be the legally-mandated requirement if the vendor was unwilling or unable to supply one of the first alternatives. Companies could, of course, adjust pricing of their software as appropriate to comply with the mandate.
It's not a very clean solution, but it would do wonders to curtail the "forced paid upgrade" trend in software. Plus, companies with "good" support policies in place (both large and small) would benefit.
(Note: Developer, small dev shop, higher-priced software, same situation.)
If you distribute an "unlimited" version, this will be what is pirated; there's no value in having different versions. Also, if you have a key which allows "unlimited" access without secondary verification, this is what will be distributed on pirate sites.
In our experience, it took about a week from changing the key format to a new crack key being distributed. Obviously, this is for software which is "in-demand", but don't expect that implementing a new scheme with the same underlying characteristics will buy you much time.
For "good" protection, you basically need secondary verification which is "hard" to fake. Currently, that is hardware dongles or an online verification loop. Both of these can be pains for the users, costly for you, and/or prohibitive in some environments (online, in particular, doesn't play nice with classified government envs).
Keep in mind also: most people who pirate are not potential customers, at least at anything close to full price, but their experience using the tool may turn into a sale at a company later.
My suggestion: do what you can to track usage, but don't be overly obtrusive and/or try to prevent all piracy usage. Being able to watch and track, and act when appropriate, is much better than trying to prevent all piracy.
I'd upvote this more if I could. As someone who both codes for a living and hires engineers to do the same, what you are describing is exactly what I look for in an engineer. You can become familiar with more tools and methods, but at the end of the day, you [just] need to be able to solve problems well. The only additional challenge in the "real world" is breaking down larger problems, and solving them in "better" ways (ie: fits better with the rest of the system, is maintainable, is flexible, etc.).
Also, to add to this, the tools for creating eBooks (at least Kindle books) are pretty awful. For example, the "recommended" method uses a two-stage conversion, with a third-party app which isn't even supported any more. All the conversion paths mangle any custom formatting, in different (and seemingly unpredictable) ways, and generate "messy" HTML for everything. Alternatively, you can hand-edit HTML, and manually create any extra parts (eg: the TOC), because there are no automatic mechanisms to support features that office apps have had for literally decades.
As someone who has published an eBook on Kindle, I can tell you that it looks "bare bones". It looks better in google docs where I wrote it, but it was a PITA to just get it into Kindle format, and the tooling to "make it nice" without lots of additional effort was just not there. If Amazon et all could address that problem, it might go a long way toward getting nicer looking eBooks.
As someone who interviews and hires developers...
I think the brain teaser has a place, but mainly to gauge how someone approaches and thinks through a problem, not for any specific answer. I agree with the OP, though: real code and big picture thinking is the best indicator of longer-term success. On the other hand, you can be a good coder without big picture thinking too, especially in a larger organization with good engineering management.
Personally, I look for people who know how to code (ie: can answer intermediate questions), understand what the code is doing (eg: in C++, why you normally use virtual destructors, but in what conditions you may not want to), and can think through problems (ie: here's an arbitrary hypothetical problem, tell me how you solve it). If you can do those things, you can be a productive developer; the rest (eg: specific knowledge, familiarity with tools/paradigms, coding trivia, etc.) is gravy.
I do think this is valuable information, but it doesn't go far enough. You should be able to filter apps by permissions as well, on platforms which support per-operation permissions for applications.
You know what would be even better, though? If the per-operation permissions were settable on a per-application basis, and then spoofed/failed if the app can't work without it. There are plenty of apps that I want to use, but require extraneous permissions for things I don't care about, and/or don't want the app to access. If someone could build a platform which put the permission usage into the user's hands (even as an Android variant, for example), that would be awesome.
Not just local law enforcement. Any government entity, law enforcement or otherwise, without the bothersome inconvenience of probably cause, warrants, or any of that other pre-telematics nonsense. Hope you're not engaging in any activities which the government might think are supportive of terrorists (like, say, talking about seditious thoughts).
The fact that people buy cars equipped with OnStar is either a sign that we deserve our oppressive government, or is a testimony to the ignorance of the voting public...
I don't think the marketing is anything more than typical marketing optimism/BS, but to be fair...
If someone could make a smartphone that: ... you could probably sell it pretty well. There's not a snowball's chance in hell that Microsoft/Nokia will produce such a phone, but it's true to say that there is a large-ish market which is being largely under-served by the current smart-phone offerings.
- Had a smooth ease-of-use of an iPhone
- Didn't require you to root it to fully customize it
- Didn't pack it with carrier bloatware
- Had good battery life and talk quality without building/flashing your own custom ROM
- Had lots of free and/or nearly free apps to cover common usage scenarios
- Guaranteed to respect your privacy (no CarrierIQ, tracking, logging, etc.)
(Disclosure: I have a relationship with Lieberman Software, although I was not involved in this survey.)
Just because the company initiating the survey has a business interest related to the subject material doesn't mean the results are inherently BS. Sure, you should be skeptical, but to call BS purely due to bias seems... misguided.
For example, you readily state that you have access to shared passwords; thus, you would be included in the affirmative for the first question quoted. Presumably you wouldn't know if other co-workers thought you or other admins had misused access, but if so, then perhaps the second as well. You sound fairly security-conscious, so I'll assume your organization would not be included in the third... unless perhaps other admins are not as diligent as you (which, I realize, never happens in large organizations, but consider the hypothetical). Are the results of the survey really that hard to believe?
Sure, Lieberman Software is selling stuff, but it's not like they are trying to hide it, or hide behind proxy "unbiased" survey organizations. Read the info with a critical eye as appropriate, but calling BS due to non-obfuscated bias is as bad as believing the info on face value.
There's some humor on the page for browser features, if you're using a browser without Flash installed/enabled. The #1 "bad" item is Dangerous Downloads, just to the left of the prompt to download/install Flash. I lol-ed.
+1 for this (if I could). G+ was a good idea, right up until the point that google decided it wanted to create something more privacy-repugnant than even FB. I think a lot of people liked the idea before they clarified their intentions, but afterward it became clear that all the paradigm changes in the world could not overcome the basic design choice to be evil.