Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Re:Defective (Score 1) 346

You said " someone needs to get cracking with that recall" and "It doesn't invalidate anything I wrote". So what precisely do you expect to be recalled due to this case of a person accelerating a car towards a group of people?

What I wrote stands for the situation described in the headline, summary and article. We'd obviously have to allow for physics (i.e. a car won't stop immediately at 70mph, and pedestrians wearing black radar-cloaking clothing at night are probably fucked), but otherwise get it right or get it off the road.

If the car wasn't actually operating autonomously, sure, what I wrote wouldn't be directly applicable to this situation. It's still the right way to handle the failure at it was described.

Comment: Re:Defective (Score 1) 346

That's only true if the capability is supposed to be used without supervision

Hm. Legit point, but then you have to ask whether the driver reasonably understands how the assistive technology works well enough to be able to supervise it, and also how easily they can stop the process if things go wrong (i.e. if the assistive technology requires the driver to take their limbs off the wheel, brakes and accelerator in order to work reliably, then it's pretty much guaranteed that they won't be able to act quickly enough to prevent an accident).

Comment: Re:Defective (Score 2) 346

It wasn't doing any autonomous movement so your premise is garbage and thus the rest of the post meaningless.

So, you're saying the "self-parking" bit the headline, summary and article describe is a complete red herring and had nothing to do with what the car was actually doing at the time?

  If you say so. It doesn't invalidate anything I wrote, it just might not be applicable to the situation that the headline, summary, and article all apparently failed to describe.

Comment: Defective (Score 0, Flamebait) 346

Any vehicle that is capable of any kind of autonomous movement that doesn't include pedestrian (or dog, or cat, or cyclist) detection is defective, period.

Any auto manufacturer that makes such a vehicle is 100% liable for any deaths or injuries that happen during said autonomous movement, period.

This isn't rocket science. This should be considered "seat belt saves lives" level of mandatory.

Now, someone needs to get cracking with that recall...

Comment: Re:Maybe because security people are dicks? (Score 1) 150

by c (#49734495) Attached to: Survey: 2/3 of Public Sector Workers Wouldn't Report a Security Breach

Security's motto: We break stuff, put ALL the burden on the users, walk away AND we get paid for it!

This is pretty much what happens when "Security" is a separate business group. Security-oriented admin groups can usually manage to balance security versus operational requirements, but if your only job is making things more secure and there's zero penalty for making things non-functional, well... honestly, I'd probably do the same thing.

Comment: Sounds great! (Score 1) 91

by c (#49734445) Attached to: Tweets To Appear In Google Search Results

At least, assuming these tweets are ranked appropriately.

Down near the bottom, with the ad spammers.

But really... what the fuck, Google? The most "useful" kinds of tweets are the ones who reference the authoritative material that you'd want to see instead of any tweet about it. As a means to add to the page rank of good (i.e. referenced) pages tweets might be valuable, but otherwise twitter activity is pretty much the definition of irrelevant.

Comment: Re:it's a C idiom (Score 1) 264

by c (#49643425) Attached to: C Code On GitHub Has the Most "Ugly Hacks"

I'm not sure I'm following. If we're non-POSIX, then what read(2) are we talking about? Also, that sizeof is by definition 1

POSIX defines sizeof(char)==1. But C itself doesn't necessarily *require* sizeof(char)==1, just that char is the smallest non-bitfield type. Theoretically, sizeof(char)==4 could be legit on some architectures. In practice, I doubt there's a non-trivial C program on the planet that would function on such a platform, but it's there.

The *point* of this being that the bug wasn't specifically that sizeof(char)==2, but that sizeof(char) was apparently variable within one trivial function in thousands of lines of code, and that throwing a trivial assertion in front of it was enough to change the value back to what it was supposed to be.

If a no-op changes behavior of your program, then yes, it's either a compiler bug

Exactly. In this case, it was the optimizer losing its shit. I wouldn't try to diff optimized and non-optimized ASM output from the compiler these days, but at the time it wasn't too horrible.

If that was indeed mid-late 90's MSVC++, then that makes it slightly easier to believe, yes ;)

It was still better than g++ on the DEC Alpha around that same time, but that's setting the bar pretty low.

Comment: Re:it's a C idiom (Score 1) 264

by c (#49643061) Attached to: C Code On GitHub Has the Most "Ugly Hacks"

I've been coding in C long enough to know the difference between unspecified/undefined behaviour and bona-fide bugs.

For example, I'm pretty darn sure that a chunk of code such as:


unsigned char inbyte;
read(fd,&inbyte,sizeof(inbyte));

should always read at most the same number of bytes (one byte would be nice, but let's pretend we're non-POSIX, here...). And if you *change* that chunk of code to something like, say:


unsigned char inbyte;
assert(sizeof(inbyte)==1);
read(fd,&inbyte,sizeof(inbyte));

It should *still* read at most the same number of bytes as the first chunk of code. If the second chunk of code reads 1 byte while the previous chunk of code was reading 2 bytes (and, incidentally, bashing the stack while dumping those 2 bytes into a 1 byte variable), I'm comfortable in calling that a compiler bug.

Mid-late 90's Visual C++, in case you weren't aware, was not a good vintage.

Money doesn't talk, it swears. -- Bob Dylan

Working...