It's a lot like dating. The flashy appearance makes you drool so you buy in. It's only after you've had time to get over the initial euphoria that you realize exactly what you got yourself into...
The people who drive businesses want your buy-in; it's their sole reason for existing. They don't care if the product is actually any good.
Yeah, but then you'd have one hell of an expensive secret shopper, since that person would also have to actually qualify for the job he's interviewing for in order to pass the interview...
In my view, having followed this from the beginning, Paramount's most likely motivation was to protect the consumers.
Couple of interesting points: 1. They never sued Renegades, even though they had highly recognizable names in it. And that's a completed movie, not an "in production" movie. 2. They never sued Horizon, another completed movie, and one that was leaps and bounds more watchable than Renegades IMO, especially given the minimal budget.
There is a lot of speculation that Peters has not put the 1.4 million dollars he raised toward the actual film, but instead toward various personal expenses, the construction of a studio intended for commercial use, and the lawsuit of course (pro bono isn't actually free). Donor money should not have gone to any of those things (though in the case of the studio, it could just be a case of poor judgement on his part; rental studios are a dime a dozen in Hollywood, and far cheaper than building your own).
Lo and behold, it's only Axanar they went after.
My guess? I think they were concerned about the Star Trek brand being associated with a con man. Do some research on Alec Peters; at best, you'll find a great many questions (even if you ignore the legitimate haters -- and there are FAR fewer of those than Peters himself would have you believe).
He took entire designs wholesale; Klingon ships, at least one Federation ship, etc.; he took the exact names of the fictional nations involved; he even used actual Star Trek screen-used costumes. But most damningly, he took at least one whole character for use in Axanar.
Interestingly, the character I'm referring to isn't from TOS, but rather from Enterprise, which is much more recent.
Code is transient, in part, because it's badly written in the first place. If code was written to higher standards, less of it would have to be replaced over time.
Not true of all things, but definitely true of many.
Add 'nofail' to your nfs mount options. Now your boot won't explode on failed NFS mounts.
Or at least, that's what fixed it for me.
Systemd as a concept isn't bad, but the current implementation (and the horrid naming of the command-line utilities) is barely tolerable, and strikes me as wholly untrustworthy. I'm also quite shocked that RedHat has let it consume so much (and especially non-init-related) tried and true functionality without giving previously consumed subsystems time to bake.
I'm currently a bit unhappy with the technical leadership at RedHat. A simple replacement for init would have been great, but the snowball effect with systemd makes me cringe.
Apple was aware that the possibility existed. Apple was NOT aware of the specific driver being a douche.
There's also the fact that Texas does not have blanket "no phone while driving" laws at the state level. Some locales do, but not all. In some areas of Texas, it's perfectly legal to text (or do anything else on your phone) while driving. Stupid, yes, but legal. Each state in the Union, and, sometimes each city in each state, has different rules regarding this.
In order to respect those rules, Apple would suddenly be responsible for keeping track of the laws in every city and town in America. That's overly burdensome.
You can't have differing laws like that and then apply a stricter standard to the device manufacturer. Blaming the device manufacturer for a stupid use of the device is... stupid. It wasn't defective. It worked as advertised. That the user used it poorly is not, in ANY way, Apple's fault.
It sucks that a child died because the driver was a flaming moron, but that doesn't mean the manufacturer of an improperly used tool should be responsible for footing the bill. The driver, on the other hand, should have his wages garnished for life.
TL;DR: The fact that the technology exists and Apple was aware of it is irrelevant. Even the government can't yet agree that this should be prevented in every location in the US. Until they can, Apple shouldn't be held responsible for making a value judgement that's no different than the one the various lawmakers have made when considering this issue.
I don't know if there's actually a law on that (I suspect there is), but it's not really relevant. A firearm is deliberately designed to harm and/or destroy things. A phone is not. These two products should have different standards applied.
It's bad law because, in the end, Apple had nothing to do with the accident. He could have just as easily been eating a Subway sandwich. Should Subway have been liable because the guy was a douche and their Sandwich bag lacked a mechanism to prevent him from eating it while driving?
To put it a more relevant way: car manufacturers have the technology to prevent rear-end crashes. Some production vehicles actually implement this (Infiniti has that system if memory serves). Automatic braking. This guy's car obviously didn't have it; the kid would still be alive if it did. Should they be able to sue the car manufacturer for leaving out a safety feature that the law doesn't mandate?
The law does not currently mandate that cell phone manufacturers prevent the use of cell phones while driving.
Now, if there was a legal mandate and Apple left it out, then that's a different thing, but that's not the situation. Apple broke no laws. Apple wasn't aware of the situation. It's well known by now that you shouldn't use a phone while driving, and they're not responsible for educating drivers on that fact. Nor are they responsible for dictating what their customers may or may not due with their technology.
Drivers are held solely accountable for the responsible operation of their vehicles. Apple was not operating the vehicle in any way, shape, or form. Sandwich or iPhone running facetime, the guy was being an idiot and should have known better. There is no excuse.
If this case succeeds, it paves the way for manufacturers to be sued for just about anything that goes wrong. This is not a sane thing. You may think it's okay because "Apple had the technology and should have implemented it," but you're not thinking about the precedent this would set.
We're talking about a body of resulting case law that would end up requiring manufacturers of ALL products to predict every possible misuse of their products, and actively prevent them, or end up the victims of every ambulance-chasing lawyer in the country (more than they already are). The patent is a red herring; well known technology exists to do lots of things, and the fact that it's patented is irrelevant. The manufacturers know about these technologies.
Forcing them to be responsible for their customer's sanity in such a situation is an unrealistic goal unless you want to destroy every hardware business in the United States.
Apple was not at fault. The driver was. The driver should be nailed to the wall for it, and passing blame won't help with that.
Package-based granular updates won't solve this problem; it'll make it worse, just in different ways.
#1: Building baked images is no more difficult for a software developer than using a package manager. In many ways, it's easier: they can guarantee that all of the components are exactly the version that they're supposed to be, instead of hoping that someone didn't randomly update the package repository with an incompatible version of some library. Not to mention having to deal with the vagaries of software package management, which I can assure you from experience is far more time consuming.
#2: If you're talking publicly maintained repos (*shudder*), then the proprietary portion of the device's firmware is going to die every time someone breaks an API. See the bad old days of openssl for an example of developers breaking APIs... repeatedly. The only way to prevent this is to specify version requirements for the dependencies... at which point you may as well use a baked image, because you just killed the whole point.
#3: It's cron. C-R-O-N. Please. It really bugs those of us who use computers for a living when people don't spell common commands correctly. It's an OCD thing. Besides, other misspellings can be ignored; repeatedly misspelling common commands just makes you look like a n00b. Don't look like a n00b. </snark>
#4: The devices' firmware is going to die every time some library fails to update correctly and torches the proprietary packages.
#5: The device's firmware is going to die if you're using a public repo and there's a repeat of the Leftpad Incident, and the package manager isn't capable of error-checking or rollback (which some aren't).
#6: Updating a baked image can also be scheduled just as easily... from cron.
The problem is not the mechanism. The problem is that updates are an afterthought for most IoT manufacturers. Unless the entire device (including the manufacturer's code) is open source and maintained by an active community, you're pretty much at the mercy of the manufacturers' good will.
Hint: they don't have any to spare; they're too busy trying to sell you the 2018 model instead.
More accurately, NASA gave it away to the museum, from where it was stolen. In that light, the museum could conceivably have a claim, but NASA has no standing.
I mean, if I sell my car, and it's stolen from the new owner, can I then try to claim it back? That could be a fun scam.
One part of the fix should be that H1-B workers may only work on projects for the company that hires them. They may not then be contracted out as a low-cost talent pool to other companies.
Seems to me that the Tata's of the world are doing exactly that, which is a clear abuse of the program.
Y'know, that analogy just kinda falls apart all over the place if you're trying to promote node/mongo with it.
LAMP has been around a lot longer than nodejs and mongo. Everyone has it, and there's a reason why a lot of people still use it (hint: it isn't because they don't want to learn something new). And the tools around node for build and deployment are an egregiously overcomplicated mess. Mongo has its own pain points. And yes, I happen to use both, along with various LAMP-based applications. And some Ruby. And a number of other things.
LAMP is the knife you're talking about. It's everywhere, easy to work with, and extremely well supported. Node and friends are the garlic press -- we're just in the popular phase where everyone is buying one and telling their friends that they aren't cool if they don't have one too.
All tools have their place. If you can't understand that, then you're either (a) lazy, (b) in the wrong business, (c) a flaming idiot, or (d) all of the above.
The audit chain can't be electronic. There's no way the user can be certain that the vote they entered is the one that got written to the chain. Too much attack surface, especially from an insider wanting to subvert the system.
We shouldn't be focusing on "secure" electronic voting, at least not at first (though I do agree with Voter ID; if you don't have some form of state ID, then either you're a child, not legal to vote, or just plain irresponsible. Exceptions to that are probably very rare. But I digress).
What we need to be focused on is auditability.
I voted this year on electronic machines, and I found the process deeply untrustworthy. There's too much hidden in those hideous plastic boxes. Sure, it might show my candidate's name is checked, but how do I know that's what actually got recorded? Answer: I don't, because I can't examine the device's memory. This is a problem that everyone should be concerned about.
The answer? A receipt printer.
Have the machine print your votes onto a piece of paper. The paper gets a random ID of some sort, completely untied to your identity, time, or whatever else, but linking it to the electronic vote record. It should be printed in clear language so that the voter can examine it to ensure that their choices are correctly represented. This paper is then deposited into a ballot box for record-keeping purposes (and which is clearly marked as "DO NOT COUNT").
This won't affect the ability for people to hack the election machines during the election; that would be impossible. But it *does* make the actual votes auditable after the fact, which is sorely lacking in the current electronic systems.
Just my $0.02, for what little that's worth these days.
You do know there's a middle ground that a lot of us support, right?
Ditch winner-take-all electoral voting and move to a proportional system. Then you'll have a decently representative election while still blunting the effects of peer pressure and groupthink in extremely populous locales.
I wonder if anyone has looked to see if Trump would have won without winner-take-all?
Nitpick: OOP access modifiers are (at least in compiled-to-native languages that have real pointers, like C++) advisory, at best. The modifiers are only examined at compile time by the compiler for error checking purposes; there is no runtime restriction.
There is no actual protection; if you can calculate the address of the storage, you can access the data.
Slashdot Mirror
Depends on the perspective.
It's a lot like dating. The flashy appearance makes you drool so you buy in. It's only after you've had time to get over the initial euphoria that you realize exactly what you got yourself into...
The people who drive businesses want your buy-in; it's their sole reason for existing. They don't care if the product is actually any good.
I so love listening to people complaining that 5 or 6 megabits is "absolute shit net."
When I was your age, I had a /24 (we called it a "class C" back then...) routed over a 28.8k modem. And I liked it!
Of course, I have gigabit now, so I guess I should probably stfu. :)
No. Just, no.
Firstly, what I said above stands; even non-profits can be commercial enterprises.
Secondly, Alec has claimed to be a non-profit. AFAIK, the filing was never actually started, let alone completed.
Yeah, but then you'd have one hell of an expensive secret shopper, since that person would also have to actually qualify for the job he's interviewing for in order to pass the interview...
In my view, having followed this from the beginning, Paramount's most likely motivation was to protect the consumers.
Couple of interesting points:
1. They never sued Renegades, even though they had highly recognizable names in it. And that's a completed movie, not an "in production" movie.
2. They never sued Horizon, another completed movie, and one that was leaps and bounds more watchable than Renegades IMO, especially given the minimal budget.
There is a lot of speculation that Peters has not put the 1.4 million dollars he raised toward the actual film, but instead toward various personal expenses, the construction of a studio intended for commercial use, and the lawsuit of course (pro bono isn't actually free). Donor money should not have gone to any of those things (though in the case of the studio, it could just be a case of poor judgement on his part; rental studios are a dime a dozen in Hollywood, and far cheaper than building your own).
Lo and behold, it's only Axanar they went after.
My guess? I think they were concerned about the Star Trek brand being associated with a con man. Do some research on Alec Peters; at best, you'll find a great many questions (even if you ignore the legitimate haters -- and there are FAR fewer of those than Peters himself would have you believe).
How about paying himself a salary?
The instant you do that, it's not a hobby anymore. It's a commercial enterprise.
He didn't just copy the look and feel.
He took entire designs wholesale; Klingon ships, at least one Federation ship, etc.; he took the exact names of the fictional nations involved; he even used actual Star Trek screen-used costumes. But most damningly, he took at least one whole character for use in Axanar.
Interestingly, the character I'm referring to isn't from TOS, but rather from Enterprise, which is much more recent.
T'would be an excellent time for a new "I'm a Mac" ad.
Code is transient, in part, because it's badly written in the first place. If code was written to higher standards, less of it would have to be replaced over time.
Not true of all things, but definitely true of many.
That's what mini CD-Rs are for.
I'd forgotten about those.
Add 'nofail' to your nfs mount options. Now your boot won't explode on failed NFS mounts.
Or at least, that's what fixed it for me.
Systemd as a concept isn't bad, but the current implementation (and the horrid naming of the command-line utilities) is barely tolerable, and strikes me as wholly untrustworthy. I'm also quite shocked that RedHat has let it consume so much (and especially non-init-related) tried and true functionality without giving previously consumed subsystems time to bake.
I'm currently a bit unhappy with the technical leadership at RedHat. A simple replacement for init would have been great, but the snowball effect with systemd makes me cringe.
Apple was aware that the possibility existed. Apple was NOT aware of the specific driver being a douche.
There's also the fact that Texas does not have blanket "no phone while driving" laws at the state level. Some locales do, but not all. In some areas of Texas, it's perfectly legal to text (or do anything else on your phone) while driving. Stupid, yes, but legal. Each state in the Union, and, sometimes each city in each state, has different rules regarding this.
In order to respect those rules, Apple would suddenly be responsible for keeping track of the laws in every city and town in America. That's overly burdensome.
You can't have differing laws like that and then apply a stricter standard to the device manufacturer. Blaming the device manufacturer for a stupid use of the device is... stupid. It wasn't defective. It worked as advertised. That the user used it poorly is not, in ANY way, Apple's fault.
It sucks that a child died because the driver was a flaming moron, but that doesn't mean the manufacturer of an improperly used tool should be responsible for footing the bill. The driver, on the other hand, should have his wages garnished for life.
TL;DR: The fact that the technology exists and Apple was aware of it is irrelevant. Even the government can't yet agree that this should be prevented in every location in the US. Until they can, Apple shouldn't be held responsible for making a value judgement that's no different than the one the various lawmakers have made when considering this issue.
I don't know if there's actually a law on that (I suspect there is), but it's not really relevant. A firearm is deliberately designed to harm and/or destroy things. A phone is not. These two products should have different standards applied.
It's bad law because, in the end, Apple had nothing to do with the accident. He could have just as easily been eating a Subway sandwich. Should Subway have been liable because the guy was a douche and their Sandwich bag lacked a mechanism to prevent him from eating it while driving?
To put it a more relevant way: car manufacturers have the technology to prevent rear-end crashes. Some production vehicles actually implement this (Infiniti has that system if memory serves). Automatic braking. This guy's car obviously didn't have it; the kid would still be alive if it did. Should they be able to sue the car manufacturer for leaving out a safety feature that the law doesn't mandate?
The law does not currently mandate that cell phone manufacturers prevent the use of cell phones while driving.
Now, if there was a legal mandate and Apple left it out, then that's a different thing, but that's not the situation. Apple broke no laws. Apple wasn't aware of the situation. It's well known by now that you shouldn't use a phone while driving, and they're not responsible for educating drivers on that fact. Nor are they responsible for dictating what their customers may or may not due with their technology.
Drivers are held solely accountable for the responsible operation of their vehicles. Apple was not operating the vehicle in any way, shape, or form. Sandwich or iPhone running facetime, the guy was being an idiot and should have known better. There is no excuse.
If this case succeeds, it paves the way for manufacturers to be sued for just about anything that goes wrong. This is not a sane thing. You may think it's okay because "Apple had the technology and should have implemented it," but you're not thinking about the precedent this would set.
We're talking about a body of resulting case law that would end up requiring manufacturers of ALL products to predict every possible misuse of their products, and actively prevent them, or end up the victims of every ambulance-chasing lawyer in the country (more than they already are). The patent is a red herring; well known technology exists to do lots of things, and the fact that it's patented is irrelevant. The manufacturers know about these technologies.
Forcing them to be responsible for their customer's sanity in such a situation is an unrealistic goal unless you want to destroy every hardware business in the United States.
Apple was not at fault. The driver was. The driver should be nailed to the wall for it, and passing blame won't help with that.
Package-based granular updates won't solve this problem; it'll make it worse, just in different ways.
#1: Building baked images is no more difficult for a software developer than using a package manager. In many ways, it's easier: they can guarantee that all of the components are exactly the version that they're supposed to be, instead of hoping that someone didn't randomly update the package repository with an incompatible version of some library. Not to mention having to deal with the vagaries of software package management, which I can assure you from experience is far more time consuming.
#2: If you're talking publicly maintained repos (*shudder*), then the proprietary portion of the device's firmware is going to die every time someone breaks an API. See the bad old days of openssl for an example of developers breaking APIs... repeatedly. The only way to prevent this is to specify version requirements for the dependencies... at which point you may as well use a baked image, because you just killed the whole point.
#3: It's cron. C-R-O-N. Please. It really bugs those of us who use computers for a living when people don't spell common commands correctly. It's an OCD thing. Besides, other misspellings can be ignored; repeatedly misspelling common commands just makes you look like a n00b. Don't look like a n00b. </snark>
#4: The devices' firmware is going to die every time some library fails to update correctly and torches the proprietary packages.
#5: The device's firmware is going to die if you're using a public repo and there's a repeat of the Leftpad Incident, and the package manager isn't capable of error-checking or rollback (which some aren't).
#6: Updating a baked image can also be scheduled just as easily... from cron.
The problem is not the mechanism. The problem is that updates are an afterthought for most IoT manufacturers. Unless the entire device (including the manufacturer's code) is open source and maintained by an active community, you're pretty much at the mercy of the manufacturers' good will.
Hint: they don't have any to spare; they're too busy trying to sell you the 2018 model instead.
It's a great way to deploy software... until your 'net connection dies.
Then you're fucked.
I'll stick with my local tools, thanks.
/s
(which is starting to double for "sigh")
More accurately, NASA gave it away to the museum, from where it was stolen. In that light, the museum could conceivably have a claim, but NASA has no standing.
I mean, if I sell my car, and it's stolen from the new owner, can I then try to claim it back? That could be a fun scam.
They probably lost the notes on how to make them, and were hoping to study one to figure it out again.
One part of the fix should be that H1-B workers may only work on projects for the company that hires them. They may not then be contracted out as a low-cost talent pool to other companies.
Seems to me that the Tata's of the world are doing exactly that, which is a clear abuse of the program.
Y'know, that analogy just kinda falls apart all over the place if you're trying to promote node/mongo with it.
LAMP has been around a lot longer than nodejs and mongo. Everyone has it, and there's a reason why a lot of people still use it (hint: it isn't because they don't want to learn something new). And the tools around node for build and deployment are an egregiously overcomplicated mess. Mongo has its own pain points. And yes, I happen to use both, along with various LAMP-based applications. And some Ruby. And a number of other things.
LAMP is the knife you're talking about. It's everywhere, easy to work with, and extremely well supported. Node and friends are the garlic press -- we're just in the popular phase where everyone is buying one and telling their friends that they aren't cool if they don't have one too.
All tools have their place. If you can't understand that, then you're either (a) lazy, (b) in the wrong business, (c) a flaming idiot, or (d) all of the above.
What people should be pissed about is the continuing use a mysql/php/apache in the face of mongodb/javascript/nodejs.
The only tool you own is a hammer, isn't it...
The audit chain can't be electronic. There's no way the user can be certain that the vote they entered is the one that got written to the chain. Too much attack surface, especially from an insider wanting to subvert the system.
We shouldn't be focusing on "secure" electronic voting, at least not at first (though I do agree with Voter ID; if you don't have some form of state ID, then either you're a child, not legal to vote, or just plain irresponsible. Exceptions to that are probably very rare. But I digress).
What we need to be focused on is auditability.
I voted this year on electronic machines, and I found the process deeply untrustworthy. There's too much hidden in those hideous plastic boxes. Sure, it might show my candidate's name is checked, but how do I know that's what actually got recorded? Answer: I don't, because I can't examine the device's memory. This is a problem that everyone should be concerned about.
The answer? A receipt printer.
Have the machine print your votes onto a piece of paper. The paper gets a random ID of some sort, completely untied to your identity, time, or whatever else, but linking it to the electronic vote record. It should be printed in clear language so that the voter can examine it to ensure that their choices are correctly represented. This paper is then deposited into a ballot box for record-keeping purposes (and which is clearly marked as "DO NOT COUNT").
This won't affect the ability for people to hack the election machines during the election; that would be impossible. But it *does* make the actual votes auditable after the fact, which is sorely lacking in the current electronic systems.
Just my $0.02, for what little that's worth these days.
You do know there's a middle ground that a lot of us support, right?
Ditch winner-take-all electoral voting and move to a proportional system. Then you'll have a decently representative election while still blunting the effects of peer pressure and groupthink in extremely populous locales.
I wonder if anyone has looked to see if Trump would have won without winner-take-all?
Nitpick: OOP access modifiers are (at least in compiled-to-native languages that have real pointers, like C++) advisory, at best. The modifiers are only examined at compile time by the compiler for error checking purposes; there is no runtime restriction.
There is no actual protection; if you can calculate the address of the storage, you can access the data.