No software in common use today is mathematically proven to be correct; therefore, all software is buggy.
Absence of proof is not proof of absence. Yes, very little code can be mathematically proven to be correct, but there’s still some room for either getting lucky, or having enough skill to recognize the portions of the code which are exposed to outside control and exercising extreme care & diligence in crafting that code to ensure that it can safely respond to every possible input.
The entirety of Flash doesn’t need to be 100% bug free for it to be secure from the stand point of resisting remote (native) code execution or sandbox escape. It’s most likely sufficient for its network and file format parser layers to be completely accurate and leave it at that. If a bug in Flash’s animation makes my little gamer dude go flying off the screen or draws some corrupt garbage in my browser window, odds are I didn’t just get 0wn3d. As long as Flash rejects anything but completely valid Flash code (and the Flash VM can correctly react to every possible valid Flash bytecode combination), then Flash itself should be “good enough.” Not saying that’s an easy task, but it’s certainly order of magnitude than trying to ensure that the entire codebase from top to bottom is provably correct.
They certainly seem to be willing to fix Bugs and Exploits made known to them from outside 3rd parties
There’s a word for that, and “proactive” isn’t the word. Close, but off by three letters.
I certainly can’t prove they haven’t taken these steps, but considering Microsoft made a BigThing years ago when they sent all their developers to security school and focused on Windows security (for what that was worth), you’d think Adobe might also want to highlight the fact if they had taken some significant active step to secure Flash. Given the number of “outside 3rd parties” who seem to have little trouble finding exploitable bugs in Flash without the source, you’d think the folks with the source might be able to do a bit better.
I regard Flash (and other plugins) at about the same level I do firewall vendors. The browser itself is (relatively) immune to running executable code from the outside (yes, there have been bugs, but in terms of numbers they’re comparatively few). Plugins like Flash circumvent much of the security model by allowing executable code (albeit bytecode) to be downloaded and run by untrusted third parties with little chance for the user to decide whether to run it or not.
Adobe markets Flash as way to allow dynamic code to execute in a safe & secure manner. Publishing software that’s sole intent is to allow remote code execution should hold Adobe to a much higher standard to make sure that the holes they’ve opened are done in a controlled and secure way. They don’t have a great track record living up to that responsibility.
I dunno about you, but I’ve never had any code I’ve written pass a Turing test then demand emancipation. Ultimately, the person who spent the time to create something is the one who should get to choose what “free” means to them and release their work with the appropriate terms.
Some developers prefer to favor the freedom of the people who get code from them, over the freedoms of people who might (or might not) get the code from someone else, second hand. That’s BSD licensing. I give you my code, you do what you want with it, including telling other people they can’t do the same.
Other developers prefer to make commercial exploitation of their work difficult. They say you can use their code, but you have to give both the original code and your changes to everyone else. That’s GPL.
Both are valid options, and there’s no reason the developers shouldn’t be “free” to release their code under whichever terms are most attractive to them. RMS’ claim that LLVM is somehow a “setback” because its developers choose to favor their immediate users’ freedoms is offensive. Stallman is in effect saying that developers *shouldn’t* have the freedom to decide how other people can use their code.
Based on what I’ve read of RMS’ writings, I don’t buy his assertion that it’s about freedom of the code. It’s about undermining proprietary commercial software and moving towards a communism of software. I also think he’s a little bit jealous that LLVM really is a technically superior compiler suite and much more clearly written to boot.
I really don’t have very much tolerance left for people claiming you can only be free if you do it their way. You keep using that word, but I don’t think it means what you think it means.
Before you have grounds for a suit based on liability, you have to show harm that wasn’t already reimbursed by anyone who you might seek to hold liable.
There’s no “harm” done to you by having your password stored in the clear on your device. If someone got that password, used it to run up charges on your account, then there’s harm done. If Starbucks policy results in you being refunded and not being held accountable for those charges, then there’s still no harm. You’ve already been made whole in monetary terms before any legal proceeding might have commenced, QED no grounds for any legal proceeding.
Also, as others have pointed out, the harm isn’t actually perpetrated by Starbucks in this case. It’s done by whoever got your phone, extracted the password, and used it for mayhem. A defense attorney for Starbucks would make a (rather valid IMHO) argument that by allowing someone else to take your phone and plug it into their computer, you failed to take reasonable actions to secure your own system. At best, Starbucks is responsible for only a portion of the liability, and then you’re talking civil juries deciding percentages of fault to assign damages.
I do think the “left your house unlocked, got robbed” analogy is a bit off for this though. As far as the user could reasonably know, setting a lock code on your phone should be enough to qualify as “locking the house.” Unbeknownst to the user/homeowner, there was a flaw in the lock that allowed it to be trivially picked even if it was properly locked. Some liability is due the lock maker in this case, as it could be reasonably argued the product wasn’t fit for the purpose it was sold. I don’t think that applies quite as cleanly to Starbucks in this case as 1) the app is free (not sold), and 2) the app’s purpose for which it’s marketed isn’t to keep your password secure. That’s something one might expect/hope of it, but it’s a stretch to turn that expectation into grounds for a lawsuit.
The harm in any such case is likely to be well below that of the legal fees to pursue it unless you manage to get them on some statutory minimum penalties (in excess of the actual value of the harm) or turn it into a class action which would require significant numbers of people who were actually harmed (their passwords were used). I’m not aware of any such statute for something like this. Maybe some kind of treble damages thing for gross negligence, but you’re still talking triple the cost of a couple of cups of coffee, so not something worth suing over. Given how trivially, stupidly easy it is in iOS to store a password like this in Keychain in such a way that it can’t be dumped by simply plugging in the device, calling this gross negligence isn’t much of a stretch.
The only way to fix something like this would be to pass new legislation that specifically creates a tort for the act of storing user’s credentials (or perhaps PII in general) in an insecure manner. I’d personally like to see that done, but the details of how to define “a secure manner” and what information should be covered would take a lot of work to hash to prevent loopholes or making it so onerous that developers couldn’t actually comply with it for any non-trivial app.
Actually, given how much work the NSA put into SELinux, and the fact that had Target run their POS systems on Linux with full SELinux lock down instead of on wide-open Windows, it’s unlikely an attack like this would have been possible.
Sounds like the NSA could have been our saviors here. Shame Target had to go and foul up NSA’s big chance.
Fortunately the odds of a reactor in Japan “melting down to China” are even lower than they are in the general ameri-centric case. Or at least they would be if odds could go negative.
And, no, I don’t know a damned thing about nuclear reactions in any meaningful sense of the word, so maybe the answer is fairly obvious to someone who does.
You kind of answered your own rant there. The physics behind nuclear fission reactions are well understood in terms of the worst case scenario for a run away reaction and the greatest possible magnitude of heat and other high-energy products for a given input of fissionable material.
There is no question that a controlled environment can be created where this type of experiment can be conducted safely. I personally know nothing in any meaningful sense about the internal functioning of my car’s engine. Were I to attempt to dismantle it or otherwise experiment on it, it’s nearly certain that I’d be taking a taxi for the foreseeable future. My lack of useful knowledge on the subject in no way precludes the existence of subject matter experts who can safely modify and repair the technology with acceptably minimal risk of adverse outcomes.
The advantage of a simple SoC system with soldered in components is that it’s less likely to break.
Sure, that makes sense in theory, but.. Show of hands here: How many people have buried more than five "simple SoC" routers in the past five years? I’m counting parents & friends that I support in that number, admittedly, but there’s nothing the least bit difficult about making SoC simplicity with crap quality standards that lead to crazy-high failure rates.
OK. Hands down. Now how many have buried more than one “old PC” based router in the last five years?
The encrypted PIN block is only a password to the processor / merchant combination for which that PIN pad was provisioned. The encrypted block couldn’t be substituted in like (for example) an unsalted hash of a password since the key “should” be different for each set of PIN pads (possibly/preferably each individual PIN pad) that is issued.
The GPL is a poison pill for many commercial operations; it becomes problematic to utilize existing work and bootstrap commercial products.
That’s lovely FUD. What you meant to say is more like, “It’s problematic for companies to steal others’ work to create derivative commercial closed source works from freely available open source.” It’s not “problematic” to bootstrap commercial projects from GPL source. It’s denied by design because the original authors (who gave you their work for free) didn’t want you to do that. It’s really a shame that you can’t take something you didn’t pay anything for any turn around and charge other people money for it. Give me a minute to mop up the river of tears I’m crying for these companies.
There’s nothing the least bit problematic about using Linux as a platform to build closed source solutions. Nor is there a problem with using open source packages as building blocks in what will ultimately be a commercial solution. You need to release source for your changes to GPL projects, but boo hoo.
If you want to keep your source closed, that’s easy. Don’t use someone else’s open source project as a source code starting point. That still doesn’t bar you from using open source projects to help you deliver a final product. Just don’t link to them. It’s really not that hard.
I’ll grant that this gets somewhat more difficult with GPL-3 or the Affero variations, but this started out as a FUD fest about Linux which is plain-old GPL-2, so none of those issues apply.
Summary is an over simplification based reading T.F.Email from Apple. Nothing that Apple is doing at this time will prevent developers from targeting older devices than they previously have been able to target. I *think* the current oldest supportable iOS given their requirements is iOS 5, but I haven’t verified that with the latest Xcode build.
All apps published after the cut-off date must be built with the latest version of Xcode and must have imagery & design that will support iOS 7 devices’ look & feel. They must use iOS 7 as the Base SDK, but they are not required to use iOS 7 as the Minimum Deployment Target. The minimum target supported by latest Xcode is the one thing I’m uncertain of right now, but I’m pretty sure it’s iOS 5.something.
The two settings on your project (Base SDK and Min. Deployment Target (MDT)) control the newest and oldest features you have access to, respectively. An app with a newer Base SDK will still run on an older device (down to MDT). Any features added to an iOS release that’s newer that the MDT will be weak linked. The developer can check at runtime whether particular functionality is available. Unavailable classes will return nil when you try to access them (which you can ignore or check for depending on your needs), and newer methods will be unavailable on old devices (so check with respondsToSelector: or similar before calling). Additionally, when running on an older device, you keep the old device look & feel. You don’t suddenly start looking like iOS 7 on an older device.
As for what developers must do to comply with the new requirements:
1) Make sure all artwork, screen layouts, etc. are available in the higher resolution / size needed by the larger iPhone 5+ screens & Retina iPads.
2) If changing the MDT, update any code referencing methods/classes that were deprecated in between whatever the previous MDT was and the new one. Any methods/classes deprecated between the new MDT and the Base SDK version can stay unchanged,since in many cases, the newer method/classes wouldn’t be available at runtime on the older devices.
Apple has definitely cut off older devices in the past. It’s currently Very Difficult to target 3GS or earlier devices as the current Xcode doesn’t generate ARMv6 code any more. It’s still possible to make that work if you’re very dedicated by building an ARMv6 binary with an older Xcode, ARMv7(s) with the latest Xcode, and manually merging the binaries with the `lipo` command. Anecdotal evidence suggests Apple will still approve such binaries, though I’ve not personally tried to submit one.
Lemme dig up my original Core Duo Mac Book Pro. Pretty sure you could roast meat on that thing when it got cooking. At least roasted my leg a couple of times when the cores hit 99C!
And tax payer funds, to the tune of near enough to a half million a piece. Given the cost of these things, that seems like almost as big a crime as going fishing through peoples’ personal communications without due process. About eight times the median household annual income to *maybe* find out about somebody cooking some meth. Really can’t see any way that’s justifiable.
All US courts should automatically throw out any phone records for which the officers can’t provide proper documentation that the data was legally acquired (i.e. a legal warrant was issued BEFORE the data was collected that was issued FOR the crime being prosecuted).
It’s unfortunate, but under US law, this is actively unnecessary in many cases. IE if the prosecution can show that they had some other legal way to find a thing, then the fact that the thing was in fact illegally found is ignored. Investigators can pretty much do what they like, and if they can possibly find a way to justify after the fact that they inevitably would have found it, then the abuse is ignored. They even get to use the illegally acquired information in further investigative steps to find something legit. They get to peek at what they broke the law getting, and if they can use that information to discover a way to get it without having to break the law, then the whole lot stays in as evidence.
1) Tap the phone, hear about a drug deal time & place 2) Setup a “random” traffic stop at the right time & place 3) “Randomly” stop & search the car, find drugs, seize the phone, arrest one of the people on the phone. 4) Phone was legitimately seized in a search incident to arrest, so they get to search the phone & “find” the other party to the conversation. 5) Now they get to arrest both sides of the phone conversation, all based on illegal phone tap.
Creating a copyright law that prevents you from selling exclusive right to use your work is worse than the current situation. That's pure Nanny State thinking. As a legal adult, I should be able to choose whether or not I want to transfer full ownership of my work to another person. The fact that I have the choice as to whether to transfer exclusive right or just grant non-exclusive use (thus retaining the right to self publish or make additional deals with others) can act as a bargaining chip. IE I'll grant you exclusive use for extra money.
Copyright law a it stands (in the US) already grants sufficient protection to copyright owners, and in some cases excessive protection. Restricting how an author can dispose of ownership to their creation isn't a beneficial change.
The problem fixed by a single real person ownership modification is that if corporations can own copyright, corps never die, and copyright never expires. Tying copyright life to the lifetime of a real person allows works to enter the public domain in a reasonable time frame. The original author is free to sell his copyright (even to a corp), but the creator is fixed at the time of creation, and the copyright will eventually expire. Whether you tie it to author's lifetime (life + 20), or just an absolute expiration from the date of creation (50 years), the perpetual lifetime of corporations shouldn't short circuit the intent that all copyrights should eventually expire.
The stated intent of US copyright law was to encourage the creation of literary and other valuable works by ensuring that the author could make a living from creating them. There's more benefit to ensuring an author can get paid, but should still keep writing more to keep getting paid than there is to making one act of creation a perpetual payoff for all time.
How much does the culture benefit from yet another Mickey Mouse cartoon versus actually having someone with some creative talent create something new, and develop a new character?
Because contractually, it’s largely irrelevant. They may be the author of the paper, but if they’ve signed a contract pledging to not publish the papers and they’re doing it anyway, they’re in breach of contract.
No idea what’s in the contracts in question, but sending a C&D might actually be the polite thing for Elsevier to be doing. If the contract has any penalty or breach clauses, Elsevier might be entitled to damages, withheld payments, etc. against authors who violate their contract.
Leasing doesn’t fix this problem. There’s no reason Slimy Pub Corp, Inc. can’t require authors to sign an exclusive 100 year agreement to lease the copyright only to them, their successors, and assigns. Perfectly valid under (US at least) contract law, and still gives the same end result where authors can no longer self-publish or otherwise distribute their own work. They still “own” the copyright, but they’ve contracted away their rights to do anything with it.
I don’t know enough about the academic publishing situation to know why authors would agree to sign away self publishing rights, but presumably there’s some value to using Elsevier’s services, even if the “value” is only in the sense that authors are required to do it in order to be “published” and advance their careers.
Requiring copyright ownership tied to the lifetime of a single real person would help against the destruction of the public domain (Sonny Bono Copyright Term Extension Act, and Disney’s perpetual ownership of what’s become intwined in common US culture), but it doesn’t prevent copyright owners from being compelled to sign away their rights in situations such as this one.
the engine is still being spun by the momentum of the car, so your hydraulic assist on steering AND brakes will work as expected.
This is false, at least on my old '84 Plymouth Voyager back in the day. It had a loose wire in the distributor cap position sensor which caused the car to stall semi-randomly. ($20 part, labor to find it: $priceless!...)
As soon as the engine stalled, even coasting along, you lost 100% of power assist on the steering. Power assist on the brakes lived a little bit longer, but it faded with each press of the brake pedal, and you'd run out long before you were able to stop the car at even 40MPH. Had to practically stand on the brake pedal (use the seat as leverage to put most of my weight into it) to get the car to stop at that point. That and put my shoulders into the steering to try & get off the road. The problem only happened at low speed for whatever reason, so I never had to attempt stopping from highway speeds, but I can't imagine it would have been fun.
As far as engine momentum, on an automatic transmission that's almost nil. The car itself is moving forward yes, but the torque converter won't push that momentum back into the engine to keep it spinning when the ignition cuts out. Think about trying to push-start an automatic transmission (you can't). The car's momentum will keep the car itself rolling, but anything else that's driven off the engine (various vacuum and hydraulic pumps for power assist brakes, steering, suspension, etc.) is gone within a second or two. Long before you're safely stopped at any rate. I'm not as up on torque converter operation as I might be (software geek), but I think as soon as the engine-side isn't pushing on it, you essentially drop back to neutral. There's no way for it to run "backwards" with torque pushed from the car's wheels.
I'm going to go out on a limb and guess the "hardened criminal" type they're undoubtedly going to reassure us all this would only ever be used against probably has enough experience driving to safely control a car in this state. A younger or less experienced driver could easily panic at highway speeds, and I doubt the result would be all that Safe of a Stop.
Given the progression of how Tasers have been used, it seems inevitable this will be used against an increasing number of drivers. These days you look at a cop wrong, and he's unsnapping his Taser from his belt. I doubt it will be terribly long before this technology is used against an increasing number of drivers.
The result will likely be accidents or deaths, quite probably of innocent bystanders in the path of uncontrolled vehicles. All of which will be blamed on the driver, even though it's probable few of those deaths would have occurred had police not intervened. Not unlike how so many cases of Taser deaths are swept under the rug with the assurance that it's "less lethal" and therefore reasonable to use it against a wide range of innocent-until-proven-guilty people even where deadly force per-se would have been considered unacceptable.
Personally, unless a shoot-to-kill is merited, I don't see how it's acceptable to employ techniques that can so easily end in death. It'd be nice if law enforcement had to take the Hippocratic Oath.
Simple reason why not: Rhode Island (to pick the smallest state) passes a law saying sales tax 1% for all online sales. Every online retailer “moves” to RI, and every other state loses piles of revenue.
Emphasizing the “use tax” aspect requires tax be paid where the product is in fact “used” and makes it harder to game the system. Unless you happen to have a very accommodating friend/relative in a particular low-tax state, you pay what your local law makers have decreed. No tax havens emerge.
An HDMI provider needn’t implement HDCP (IE the “hard” part) unless the designer wants to secure content produced on it. A HDMI consumer (a TV) must implement HDCP if it wants to receive signals from anything other than OpenSource hardware toys like a R-Pi. I rather doubt the designers of the R-Pi felt it necessary to encrypt signals produced by it. Any TV is going to accept unencrypted HDMI (basically DVI) signals without a complaint. It’s only going to cause trouble if a provider attempts to implement the encryption and gets it wrong.
I expect Sony would have strong incentive to make their signal encryption as strong as possible, and it’s certainly plausible that they might have tripped on an edge-case in the process, locking some image consumers out.
I have no specific knowledge of the situation at play here, and the last console I bought was a GameCube, but it’s perfectly plausible that Raspberry Pi’s would JustWork(tm) in terms of HDMI, but something from Sony (who’s track record on DRM leaves much to be desired) wouldn’t.
Slashdot Mirror
Absence of proof is not proof of absence. Yes, very little code can be mathematically proven to be correct, but there’s still some room for either getting lucky, or having enough skill to recognize the portions of the code which are exposed to outside control and exercising extreme care & diligence in crafting that code to ensure that it can safely respond to every possible input.
The entirety of Flash doesn’t need to be 100% bug free for it to be secure from the stand point of resisting remote (native) code execution or sandbox escape. It’s most likely sufficient for its network and file format parser layers to be completely accurate and leave it at that. If a bug in Flash’s animation makes my little gamer dude go flying off the screen or draws some corrupt garbage in my browser window, odds are I didn’t just get 0wn3d. As long as Flash rejects anything but completely valid Flash code (and the Flash VM can correctly react to every possible valid Flash bytecode combination), then Flash itself should be “good enough.” Not saying that’s an easy task, but it’s certainly order of magnitude than trying to ensure that the entire codebase from top to bottom is provably correct.
There’s a word for that, and “proactive” isn’t the word. Close, but off by three letters.
I certainly can’t prove they haven’t taken these steps, but considering Microsoft made a BigThing years ago when they sent all their developers to security school and focused on Windows security (for what that was worth), you’d think Adobe might also want to highlight the fact if they had taken some significant active step to secure Flash. Given the number of “outside 3rd parties” who seem to have little trouble finding exploitable bugs in Flash without the source, you’d think the folks with the source might be able to do a bit better.
I regard Flash (and other plugins) at about the same level I do firewall vendors. The browser itself is (relatively) immune to running executable code from the outside (yes, there have been bugs, but in terms of numbers they’re comparatively few). Plugins like Flash circumvent much of the security model by allowing executable code (albeit bytecode) to be downloaded and run by untrusted third parties with little chance for the user to decide whether to run it or not.
Adobe markets Flash as way to allow dynamic code to execute in a safe & secure manner. Publishing software that’s sole intent is to allow remote code execution should hold Adobe to a much higher standard to make sure that the holes they’ve opened are done in a controlled and secure way. They don’t have a great track record living up to that responsibility.
Only free if you’re a registered 501(c)(3) non-profit with the IRS. Otherwise, you pay full price for enterprise level Google domains stuff.
You can still use the free stuff under “just a gmail account,” but if you want your own domain, there’s no more free option from Google.
I dunno about you, but I’ve never had any code I’ve written pass a Turing test then demand emancipation. Ultimately, the person who spent the time to create something is the one who should get to choose what “free” means to them and release their work with the appropriate terms.
Some developers prefer to favor the freedom of the people who get code from them, over the freedoms of people who might (or might not) get the code from someone else, second hand. That’s BSD licensing. I give you my code, you do what you want with it, including telling other people they can’t do the same.
Other developers prefer to make commercial exploitation of their work difficult. They say you can use their code, but you have to give both the original code and your changes to everyone else. That’s GPL.
Both are valid options, and there’s no reason the developers shouldn’t be “free” to release their code under whichever terms are most attractive to them. RMS’ claim that LLVM is somehow a “setback” because its developers choose to favor their immediate users’ freedoms is offensive. Stallman is in effect saying that developers *shouldn’t* have the freedom to decide how other people can use their code.
Based on what I’ve read of RMS’ writings, I don’t buy his assertion that it’s about freedom of the code. It’s about undermining proprietary commercial software and moving towards a communism of software. I also think he’s a little bit jealous that LLVM really is a technically superior compiler suite and much more clearly written to boot.
I really don’t have very much tolerance left for people claiming you can only be free if you do it their way. You keep using that word, but I don’t think it means what you think it means.
Before you have grounds for a suit based on liability, you have to show harm that wasn’t already reimbursed by anyone who you might seek to hold liable.
There’s no “harm” done to you by having your password stored in the clear on your device. If someone got that password, used it to run up charges on your account, then there’s harm done. If Starbucks policy results in you being refunded and not being held accountable for those charges, then there’s still no harm. You’ve already been made whole in monetary terms before any legal proceeding might have commenced, QED no grounds for any legal proceeding.
Also, as others have pointed out, the harm isn’t actually perpetrated by Starbucks in this case. It’s done by whoever got your phone, extracted the password, and used it for mayhem. A defense attorney for Starbucks would make a (rather valid IMHO) argument that by allowing someone else to take your phone and plug it into their computer, you failed to take reasonable actions to secure your own system. At best, Starbucks is responsible for only a portion of the liability, and then you’re talking civil juries deciding percentages of fault to assign damages.
I do think the “left your house unlocked, got robbed” analogy is a bit off for this though. As far as the user could reasonably know, setting a lock code on your phone should be enough to qualify as “locking the house.” Unbeknownst to the user/homeowner, there was a flaw in the lock that allowed it to be trivially picked even if it was properly locked. Some liability is due the lock maker in this case, as it could be reasonably argued the product wasn’t fit for the purpose it was sold. I don’t think that applies quite as cleanly to Starbucks in this case as 1) the app is free (not sold), and 2) the app’s purpose for which it’s marketed isn’t to keep your password secure. That’s something one might expect/hope of it, but it’s a stretch to turn that expectation into grounds for a lawsuit.
The harm in any such case is likely to be well below that of the legal fees to pursue it unless you manage to get them on some statutory minimum penalties (in excess of the actual value of the harm) or turn it into a class action which would require significant numbers of people who were actually harmed (their passwords were used). I’m not aware of any such statute for something like this. Maybe some kind of treble damages thing for gross negligence, but you’re still talking triple the cost of a couple of cups of coffee, so not something worth suing over. Given how trivially, stupidly easy it is in iOS to store a password like this in Keychain in such a way that it can’t be dumped by simply plugging in the device, calling this gross negligence isn’t much of a stretch.
The only way to fix something like this would be to pass new legislation that specifically creates a tort for the act of storing user’s credentials (or perhaps PII in general) in an insecure manner. I’d personally like to see that done, but the details of how to define “a secure manner” and what information should be covered would take a lot of work to hash to prevent loopholes or making it so onerous that developers couldn’t actually comply with it for any non-trivial app.
$20k/year power bill in the US? The DEA would already have leveled the whole house on suspicion of drug production.
Based on observation, on through retirement in a lot of cases. . .
Actually, given how much work the NSA put into SELinux, and the fact that had Target run their POS systems on Linux with full SELinux lock down instead of on wide-open Windows, it’s unlikely an attack like this would have been possible.
Sounds like the NSA could have been our saviors here. Shame Target had to go and foul up NSA’s big chance.
Or something . . .
Fortunately the odds of a reactor in Japan “melting down to China” are even lower than they are in the general ameri-centric case. Or at least they would be if odds could go negative.
That sounds like a worst case scenario to me, at least in the scope of a single experiment. Rinse, repeat, SCIENCE!!!!
You kind of answered your own rant there. The physics behind nuclear fission reactions are well understood in terms of the worst case scenario for a run away reaction and the greatest possible magnitude of heat and other high-energy products for a given input of fissionable material.
There is no question that a controlled environment can be created where this type of experiment can be conducted safely. I personally know nothing in any meaningful sense about the internal functioning of my car’s engine. Were I to attempt to dismantle it or otherwise experiment on it, it’s nearly certain that I’d be taking a taxi for the foreseeable future. My lack of useful knowledge on the subject in no way precludes the existence of subject matter experts who can safely modify and repair the technology with acceptably minimal risk of adverse outcomes.
Sure, that makes sense in theory, but.. Show of hands here: How many people have buried more than five "simple SoC" routers in the past five years? I’m counting parents & friends that I support in that number, admittedly, but there’s nothing the least bit difficult about making SoC simplicity with crap quality standards that lead to crazy-high failure rates.
OK. Hands down. Now how many have buried more than one “old PC” based router in the last five years?
The encrypted PIN block is only a password to the processor / merchant combination for which that PIN pad was provisioned. The encrypted block couldn’t be substituted in like (for example) an unsalted hash of a password since the key “should” be different for each set of PIN pads (possibly/preferably each individual PIN pad) that is issued.
That’s lovely FUD. What you meant to say is more like, “It’s problematic for companies to steal others’ work to create derivative commercial closed source works from freely available open source.” It’s not “problematic” to bootstrap commercial projects from GPL source. It’s denied by design because the original authors (who gave you their work for free) didn’t want you to do that. It’s really a shame that you can’t take something you didn’t pay anything for any turn around and charge other people money for it. Give me a minute to mop up the river of tears I’m crying for these companies.
There’s nothing the least bit problematic about using Linux as a platform to build closed source solutions. Nor is there a problem with using open source packages as building blocks in what will ultimately be a commercial solution. You need to release source for your changes to GPL projects, but boo hoo.
If you want to keep your source closed, that’s easy. Don’t use someone else’s open source project as a source code starting point. That still doesn’t bar you from using open source projects to help you deliver a final product. Just don’t link to them. It’s really not that hard.
I’ll grant that this gets somewhat more difficult with GPL-3 or the Affero variations, but this started out as a FUD fest about Linux which is plain-old GPL-2, so none of those issues apply.
Summary is an over simplification based reading T.F.Email from Apple. Nothing that Apple is doing at this time will prevent developers from targeting older devices than they previously have been able to target. I *think* the current oldest supportable iOS given their requirements is iOS 5, but I haven’t verified that with the latest Xcode build.
All apps published after the cut-off date must be built with the latest version of Xcode and must have imagery & design that will support iOS 7 devices’ look & feel. They must use iOS 7 as the Base SDK, but they are not required to use iOS 7 as the Minimum Deployment Target. The minimum target supported by latest Xcode is the one thing I’m uncertain of right now, but I’m pretty sure it’s iOS 5.something.
The two settings on your project (Base SDK and Min. Deployment Target (MDT)) control the newest and oldest features you have access to, respectively. An app with a newer Base SDK will still run on an older device (down to MDT). Any features added to an iOS release that’s newer that the MDT will be weak linked. The developer can check at runtime whether particular functionality is available. Unavailable classes will return nil when you try to access them (which you can ignore or check for depending on your needs), and newer methods will be unavailable on old devices (so check with respondsToSelector: or similar before calling). Additionally, when running on an older device, you keep the old device look & feel. You don’t suddenly start looking like iOS 7 on an older device.
As for what developers must do to comply with the new requirements:
1) Make sure all artwork, screen layouts, etc. are available in the higher resolution / size needed by the larger iPhone 5+ screens & Retina iPads.
2) If changing the MDT, update any code referencing methods/classes that were deprecated in between whatever the previous MDT was and the new one. Any methods/classes deprecated between the new MDT and the Base SDK version can stay unchanged,since in many cases, the newer method/classes wouldn’t be available at runtime on the older devices.
Apple has definitely cut off older devices in the past. It’s currently Very Difficult to target 3GS or earlier devices as the current Xcode doesn’t generate ARMv6 code any more. It’s still possible to make that work if you’re very dedicated by building an ARMv6 binary with an older Xcode, ARMv7(s) with the latest Xcode, and manually merging the binaries with the `lipo` command. Anecdotal evidence suggests Apple will still approve such binaries, though I’ve not personally tried to submit one.
Lemme dig up my original Core Duo Mac Book Pro. Pretty sure you could roast meat on that thing when it got cooking. At least roasted my leg a couple of times when the cores hit 99C!
And tax payer funds, to the tune of near enough to a half million a piece. Given the cost of these things, that seems like almost as big a crime as going fishing through peoples’ personal communications without due process. About eight times the median household annual income to *maybe* find out about somebody cooking some meth. Really can’t see any way that’s justifiable.
It’s unfortunate, but under US law, this is actively unnecessary in many cases. IE if the prosecution can show that they had some other legal way to find a thing, then the fact that the thing was in fact illegally found is ignored. Investigators can pretty much do what they like, and if they can possibly find a way to justify after the fact that they inevitably would have found it, then the abuse is ignored. They even get to use the illegally acquired information in further investigative steps to find something legit. They get to peek at what they broke the law getting, and if they can use that information to discover a way to get it without having to break the law, then the whole lot stays in as evidence.
1) Tap the phone, hear about a drug deal time & place
2) Setup a “random” traffic stop at the right time & place
3) “Randomly” stop & search the car, find drugs, seize the phone, arrest one of the people on the phone.
4) Phone was legitimately seized in a search incident to arrest, so they get to search the phone & “find” the other party to the conversation.
5) Now they get to arrest both sides of the phone conversation, all based on illegal phone tap.
Probable cause, after the fact.
Creating a copyright law that prevents you from selling exclusive right to use your work is worse than the current situation. That's pure Nanny State thinking. As a legal adult, I should be able to choose whether or not I want to transfer full ownership of my work to another person. The fact that I have the choice as to whether to transfer exclusive right or just grant non-exclusive use (thus retaining the right to self publish or make additional deals with others) can act as a bargaining chip. IE I'll grant you exclusive use for extra money.
Copyright law a it stands (in the US) already grants sufficient protection to copyright owners, and in some cases excessive protection. Restricting how an author can dispose of ownership to their creation isn't a beneficial change.
The problem fixed by a single real person ownership modification is that if corporations can own copyright, corps never die, and copyright never expires. Tying copyright life to the lifetime of a real person allows works to enter the public domain in a reasonable time frame. The original author is free to sell his copyright (even to a corp), but the creator is fixed at the time of creation, and the copyright will eventually expire. Whether you tie it to author's lifetime (life + 20), or just an absolute expiration from the date of creation (50 years), the perpetual lifetime of corporations shouldn't short circuit the intent that all copyrights should eventually expire.
The stated intent of US copyright law was to encourage the creation of literary and other valuable works by ensuring that the author could make a living from creating them. There's more benefit to ensuring an author can get paid, but should still keep writing more to keep getting paid than there is to making one act of creation a perpetual payoff for all time.
How much does the culture benefit from yet another Mickey Mouse cartoon versus actually having someone with some creative talent create something new, and develop a new character?
Because contractually, it’s largely irrelevant. They may be the author of the paper, but if they’ve signed a contract pledging to not publish the papers and they’re doing it anyway, they’re in breach of contract.
No idea what’s in the contracts in question, but sending a C&D might actually be the polite thing for Elsevier to be doing. If the contract has any penalty or breach clauses, Elsevier might be entitled to damages, withheld payments, etc. against authors who violate their contract.
Leasing doesn’t fix this problem. There’s no reason Slimy Pub Corp, Inc. can’t require authors to sign an exclusive 100 year agreement to lease the copyright only to them, their successors, and assigns. Perfectly valid under (US at least) contract law, and still gives the same end result where authors can no longer self-publish or otherwise distribute their own work. They still “own” the copyright, but they’ve contracted away their rights to do anything with it.
I don’t know enough about the academic publishing situation to know why authors would agree to sign away self publishing rights, but presumably there’s some value to using Elsevier’s services, even if the “value” is only in the sense that authors are required to do it in order to be “published” and advance their careers.
Requiring copyright ownership tied to the lifetime of a single real person would help against the destruction of the public domain (Sonny Bono Copyright Term Extension Act, and Disney’s perpetual ownership of what’s become intwined in common US culture), but it doesn’t prevent copyright owners from being compelled to sign away their rights in situations such as this one.
This is false, at least on my old '84 Plymouth Voyager back in the day. It had a loose wire in the distributor cap position sensor which caused the car to stall semi-randomly. ($20 part, labor to find it: $priceless!...)
As soon as the engine stalled, even coasting along, you lost 100% of power assist on the steering. Power assist on the brakes lived a little bit longer, but it faded with each press of the brake pedal, and you'd run out long before you were able to stop the car at even 40MPH. Had to practically stand on the brake pedal (use the seat as leverage to put most of my weight into it) to get the car to stop at that point. That and put my shoulders into the steering to try & get off the road. The problem only happened at low speed for whatever reason, so I never had to attempt stopping from highway speeds, but I can't imagine it would have been fun.
As far as engine momentum, on an automatic transmission that's almost nil. The car itself is moving forward yes, but the torque converter won't push that momentum back into the engine to keep it spinning when the ignition cuts out. Think about trying to push-start an automatic transmission (you can't). The car's momentum will keep the car itself rolling, but anything else that's driven off the engine (various vacuum and hydraulic pumps for power assist brakes, steering, suspension, etc.) is gone within a second or two. Long before you're safely stopped at any rate. I'm not as up on torque converter operation as I might be (software geek), but I think as soon as the engine-side isn't pushing on it, you essentially drop back to neutral. There's no way for it to run "backwards" with torque pushed from the car's wheels.
I'm going to go out on a limb and guess the "hardened criminal" type they're undoubtedly going to reassure us all this would only ever be used against probably has enough experience driving to safely control a car in this state. A younger or less experienced driver could easily panic at highway speeds, and I doubt the result would be all that Safe of a Stop.
Given the progression of how Tasers have been used, it seems inevitable this will be used against an increasing number of drivers. These days you look at a cop wrong, and he's unsnapping his Taser from his belt. I doubt it will be terribly long before this technology is used against an increasing number of drivers.
The result will likely be accidents or deaths, quite probably of innocent bystanders in the path of uncontrolled vehicles. All of which will be blamed on the driver, even though it's probable few of those deaths would have occurred had police not intervened. Not unlike how so many cases of Taser deaths are swept under the rug with the assurance that it's "less lethal" and therefore reasonable to use it against a wide range of innocent-until-proven-guilty people even where deadly force per-se would have been considered unacceptable.
Personally, unless a shoot-to-kill is merited, I don't see how it's acceptable to employ techniques that can so easily end in death. It'd be nice if law enforcement had to take the Hippocratic Oath.
Observed Traffic Pattern: Candy Crush level 263
Analyzing . . .
User Profile: Addictive personality, drug seeking.
Marketing Plan: Serve coupon for free fries with McHog Burger purchase.
Simple reason why not: Rhode Island (to pick the smallest state) passes a law saying sales tax 1% for all online sales. Every online retailer “moves” to RI, and every other state loses piles of revenue.
Emphasizing the “use tax” aspect requires tax be paid where the product is in fact “used” and makes it harder to game the system. Unless you happen to have a very accommodating friend/relative in a particular low-tax state, you pay what your local law makers have decreed. No tax havens emerge.
An HDMI provider needn’t implement HDCP (IE the “hard” part) unless the designer wants to secure content produced on it. A HDMI consumer (a TV) must implement HDCP if it wants to receive signals from anything other than OpenSource hardware toys like a R-Pi. I rather doubt the designers of the R-Pi felt it necessary to encrypt signals produced by it. Any TV is going to accept unencrypted HDMI (basically DVI) signals without a complaint. It’s only going to cause trouble if a provider attempts to implement the encryption and gets it wrong.
I expect Sony would have strong incentive to make their signal encryption as strong as possible, and it’s certainly plausible that they might have tripped on an edge-case in the process, locking some image consumers out.
I have no specific knowledge of the situation at play here, and the last console I bought was a GameCube, but it’s perfectly plausible that Raspberry Pi’s would JustWork(tm) in terms of HDMI, but something from Sony (who’s track record on DRM leaves much to be desired) wouldn’t.