Comment Re:I've always hated this "card" concept (Score 2) 115
You can disable Google Now (I think) and just use the search. Check the setting in Google Now, and/or try disabling the Google Now app itself from your device's main settings > apps.
You can disable Google Now (I think) and just use the search. Check the setting in Google Now, and/or try disabling the Google Now app itself from your device's main settings > apps.
Isn't that the point of these seeds though? They are designed to work with Roundup, thus he was using the product as intended? Except Monsato doesnt allow that.
Monsanto has a policy to protect its investment in seed development that prohibits farmers from saving or reusing the seeds once the crop is grown. Farmers must buy new seeds every year.
Also, I dont think you are correct. This is exactly what the court said was wrong. I also dont think it helped his case that he already had first purchased Monsato seeds, then went and bought cheaper mixed seeds in the hope of getting similarly resistant seeds (unclear from TFA how many, if any, were Monsato).
From TFA
[ Justice Elena Kagan said ]
"Bowman planted Monsanto's patented soybeans solely to make and market replicas of them, thus depriving the company of the reward patent law provides for the sale of each article," she said. "Patent exhaustion provides no haven for such conduct."
Well, there are a few "interesting" gems there. Though it's mostly business fluff. From TFA:
Such companies as Facebook (FB) and Google also have special teams that review the lines of code written by developers. It’s these people who get to decide when a new feature is ready to make its way to their websites. Not LinkedIn. It has one, huge stash of code that everyone works on, and algorithms do the code reviewing. “Humans have largely been removed from the process,” Scott says. “Humans slow you down.”
Uh, Okay. Automated code review? Um, where to begin? I think there an obvious misunderstanding on the part of the author of the article. Surely Google, FB, et. al., do CI and all sorts of automated testing. They just *also* use humans.
Incidentally, Google clearly has more products, thus more specialties and codebases. FB also, to a lesser extent. I dont think the Google Search team is the same as the Google Maps team or the Android team.
LinkedIn is a website, they have an API, messaging, maybe some mobile apps? It's not trivial, but it's probably not very close to the technical complexity of FB, and no where near the technical complexity of Google.
LinkedIn initiated Project Inversion to fix its issues and has since evolved into one of the poster children for continuous development
I think TFA misses the point in a very "PHB way" sadly. They took the time to make the devs happy and give ownership of features to devs. The result was the devs created an environment that was productive and could be continuously updated with less fuss.
To me, this is the poster child for creating a dev focused culture, and taking the time to do things the right way. Which, sadly, is the exact opposite of the conclusion of TFA and the LinkedIn PHB.
For anyone else who hasn't heard that term before: http://en.wikipedia.org/wiki/Vitality_curve
Luckily the Barns & Noble case revealed some of what MS has been hiding. I dont have the info top of mind, but IIRC it was a lot of nonsense related to calendar syncing.
LED's do not emit a sense of humor.
LED's don't emit a 'whooshing' sound (unless you catapult them or use a trebuchet)
I'd rather see someone side-step Verizon. They seem to have the LTE network to beat. Good for HTC though, every little bit to weaken carrier grip is welcome, be it from HTC, Apple, Google, or whoever.
why is SD card access a boolean decision? And why are all permissions granted permanently to apps?
Fair questions, but how would you have designed it? Think carefully about the edge cases and user experience for both questions. I think it also helps to keep in mind lessons learned from incessant dialogs. Users are now desensitized and trained to click OK, despite not having read the message.
You know, I got that same feeling when the article said this was from "Russian security firm Doctor Web" and the malware dates back to October 2012.
They may be legit, but I did a double take on the name and country of the company, as well as the date.
Looks like it comes from TFA, which is next to useless for actual helpful information. No mention of what ad networks, or what apps theses were found in. They even blur the website name of where they encountered an ad. The Next Web article seems to be copy-pasta from the AV 'article' (probably better described as a press release). I clicked around their site and their links are broken and redirect to a scary 404 page that gives me instructions on how to recover Windows. Pot, kettle, anyone?
But sure enough, they sell Android antivirus software.
(Full disclosure: I sell an app meant to teach new users about Android permissions, but also give the text of the guide away -- still, take what I say with a grain of salt, like anyone else).
This is something I have been hoping to get time to write for awhile, more of a Wiki with statistics of how apps creep in their permission usage. Basically a community informational tool. Unfortunately I haven't had the time, nor much server coding experience. (If anyone is interested in contributing please feel free to contact me through my website).
And while your cynical take on the "developer first market" is not far off the mark, I think we should remember that there is a social contract between dev and user. I write a program and you pay me to buy it, or look at ads to use it. This part isn't really one sided at all. The problem is actually that permissions are granted before the user has a real chance to evaluate the application. This puts the users on the defensive.
I think if the social contract between dev and user was something agreed to at the time a feature was used, that would be better. It would put both dev and user on equal ground. If an app dev needs that permissions (for technical or business reasons), and they are denied it, they can shut down the app gracefully. If a user wants to deny some overreaching, they can also do so. With this case, either side can walk away at any time.
However, when the OS starts spoofing data (like the IMEI) in place of things (ala the rejected cyanogen patch), it breaks that contract both figuratively, and possibly literally. (For example if the user has agreed to TOS, and is now breaking them). I worry as a user that if we ever hope to have a system by which we retain control over permissions, we cannot break the contract, it will start a arms race (akin to ad blocking on websites).
What we need is to give users better tools to push back against permission creep, and for devs to have opportunities to cut back to what they really need.
It's not a contest -- the fact that iOS handles it well is a good thing. But it doesnt change the fact that what tepples said was also correct (though seems deprecated AFAICT). This was unfortunately the problem with that permission. It had very legitimate uses, and very nefarious ones too.
Nevertheless, you brought up the comparison to iOS. So kindly spare us the "only on slashdot" stuff when it was you who seemed to be spoiling for a brand fight.
Correction: I'm not sure media players even need it either as of API 8:
http://developer.android.com/training/managing-audio/audio-focus.html
"Luke, I'm yer father, eh. Come over to the dark side, you hoser." -- Dave Thomas, "Strange Brew"