Follow Slashdot stories on Twitter


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:Systemd, WTF? (Score 1) 166

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.

Comment Re:MSJ (Score 1) 455

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.

Comment Re:MSJ (Score 4, Informative) 455

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.

Comment Re:What updates? (Score 1) 181

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.

Comment Re:Are moon rocks special or something? (Score 4, Informative) 63

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.

Comment Re:Except they didn't. (Score 2) 455

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.

Comment Re:Web developer here (Score 1) 309

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.

Comment Re:Fix the system (Score 1) 557

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.

Slashdot Top Deals

6 Curses = 1 Hexahex