Self-driving cars don't and won't have morals, ethics, logic, or philosophy. They don't need any of that. They simply have a wide array of input sensors connected to a set of complex algorithms that provides the necessary vehicle inputs to drive from point A to point B while avoiding crashes. Not infallible avoidance, of course – if there's no room to stop when an obstacle pops up, there's no room – but better than human drivers can. And the truth is that this is a pretty low barrier. Regular cars result in about 35,000 crash fatalities a year in the U.S. alone. Self-driving cars just have to do better than that, not achieve absolute perfection all the time.

The question discussed by Patrick Lin and Eric Sofge is how the programmers designing the vehicle algorithms should configure them to behave when a collision is truly unavoidable. Lin and Sofge advocate that the programmers should use strict utilitarian philosophy when deciding what to hit. I don't think that is going to fly, either from a legal or a sales perspective; the least damaging choice is just to try to stop the vehicle even if there is no time, rather than trying to "select" a crash for the least possible damage.

From what I can tell, the only one assuming sci-fi-style robotic super-competence is Sofge himself (and perhaps his interview subject, Patrick Lin). The original Pop.Sci. article postulates that self-driving cars can and should make accurate split-second utilitarian ethical calculations. That seems a lot more "sci-fi" to me than what most of the Slashdot commenters said in response: namely, that the car's programming can't tell with a good enough degree of accuracy what might happen if it tries to choose one crash over another, so if such a collision is imminent, the car should just follow traffic laws and slam on the brakes rather than jumping out of its lane.

I don't necessarily disagree. Peter Singer's utilitarian views in particular seem especially loathsome. That said, the average person is utilitarian enough that they will usually agree to flip the switch in the "trolley problem", killing one person to save five others. (They're more reluctant in the variant where you push a fat man onto the track to try to derail the train. Philosophers wonder why, but I suspect it's simply a matter of plausibility – no matter what the formal wording of the question says, most people don't think that the fat man actually will derail the trolley.)

One major part of the problem with pure utilitarianism is that it fails on its own terms. People are not Vulcans, and they will often be very upset and disturbed (disutility!) when you try to treat them as if they are. Another traditional utilitarian dilemma is whether a doctor should kill one innocent patient and harvest his organs if it's necessary to save half a dozen other lives. For utilitarians, this is a hard question. But it should actually be easy: as soon as people find out that doctors will kill them if they think it's for the "greater good", then they will stop seeing the doctor in all but the most extreme exigencies (preventive care, etc., goes out the window) and the overall result will be much worse for everyone than following the Hippocratic Oath. In other words, following deontologial rules can often be the appropriate thing to do from a long-term utilitarian perspective.

It's important to keep in mind that when such crashes happen, the programmers/manufacturers/insurance companies won't have to defend them to a committee of ivory-tower utilitarian philosophers. They're going to have to defend them to a jury made up of ordinary citizens, most of whom believe that strict utilitarian ethics is monstrous sociopathy (and probably an affront to their deontological religious beliefs as well). And of course, these jury members won't even realize that they are thinking in such terms.

Thus, whatever the programming decisions are, they have to be explicable and defensible to ordinary citizens with no philosophical training. That's why I agree with several other commenters here that "slam on the brakes" is the most obvious out. It's a lot easier to defend the fact that the car physically couldn't stop in time than to defend a deliberate choice to cause one collision in order to avert a hypothetical worse crash. This is especially true since a well-designed autonomous car drives conservatively, and would only be faced with such a situation if someone else is doing something wrong, such as dashing out into traffic right in front of the vehicle at a high rate of speed without looking. In any other situation, the car would just stop before any crash with anything took place. If you absolutely can't avoid hitting something, slamming on the brakes makes it more likely that at least you hit the person who did something to bring it on themselves, rather than one who's completely innocent.

Of course, the vast majority of people doing programming in 1983 didn't do any of this. If you count everyone who was entering any code (from "Hello World" on up), the vast majority of programmers were working on 8-bit microcomputers that didn't require jumping through any such hoops. If you had a Commodore 64, you could get a basic test program working in less than a minute:

10 PRINT"HELLO WORLD"
20 GOTO 10
RUN

Then once you figured that out you could learn about variables, figure out how to write to the screen RAM, and eventually figure out sprites. And then once you figured out that interpreted BASIC at 1 MHz wasn't fast enough to do a decent arcade game, you'd move on to assembly. I'd wager a majority of the people programming today learned in an environment like this. Edsger Dijkstra and other academic computer scientists hated BASIC, which they thought taught bad habits and caused brain damage, but they were wrong. It was this kind of hacker culture that created the flourishing IT industry we have today, not the dead-end bureaucracy represented by Thatcherite Britain.

One of the problems with Gigabyte's design is that they used an inadequate heatsink/fan, which not only causes the CPU/GPU to throttle, but also makes a great deal of irritating noise. They would have been better off going with a design similar to the Akasa Euler, where the whole exterior of the case is a giant heatsink and is connected to the die with heatpipes. In all likelihood they could have gotten passive cooling better than the crappy and noisy active solution they used. Of course, it would have cost a few bucks extra in bill of materials costs, plus added engineering expense.

userChrome stuff will break, at least partly. The coloring of the tabs appears to be uncontrollable through CSS now without having your own SVG file.

I don't want to see any tabs at all. Currently I use some userChrome.css magic to make tabs not appear when there is 1 tab, and various other entries to hide all the 'new tab' context menus and so forth. I have a bad feeling that this will break with the update, and I'll be really pissed off.

I haven't gotten this update yet but it looks like they turned the user interface into a Chrome rip-off.

I am going to be very upset if all of my userChrome customization work breaks as a result of this. I don't want tabs; I want traditional Windows-style menus, not an all-in-one dropdown; I want the toolbar (including Back and Forward buttons) on its own line. A couple of releases ago I had to add some extra userChrome lines so it wouldn't show 1 useless tab, because they removed the setting for that. And now these genius "UI designers" are screwing everything up again.

Dammit, just leave it alone. I hate UI designers. They break everything they touch.

That was my first thought, too. Decades-old floppy disks might well have developed bad sectors – they do have backups, don't they?

Yuck. More "programming requires a special mind" nonsense.

The cold hard truth is that programming is incredibly easy. Why, it's so easy that children can and do teach themselves. Remember the 80's? You couldn't through a rock without hitting a kid who wrote their own simple games for their micro.

Sure, almost anyone can learn to write simple programs in BASIC or another similar language that is specifically designed for ease of use. This was my introduction to programming, as it was for so many others, as you note.

But how many people can understand, for example, pointers in C? Data structures and objects? Linked lists? I don't know what the exact figure is, but it's nowhere near 100% – no matter how much training or education you provide.

Some states have had to reconsider or drop Algebra II requirements for high school graduation because a sizable number of students simply cannot do it, no matter how hard they try. Not everyone has the raw IQ needed for this sort of abstract thinking.

I wonder if this is going to be one of the first big exploits that will affect Windows XP and leave the masses of users still using it vulnerable.

Since this appears to be an IE-specific exploit, couldn't they mitigate by using Chrome or Firefox instead?

Admittedly, that may not be a feasible solution for the dinosaur businesses stuck with IE6 ActiveX apps, but for Grandma it should work fine. (And these dinosaur businesses can pay out the nose for extended support from MS.)

Preprocessor macro's containing code specific to VMS don't hurt anyone but VMS users.

Yes, it does. Using these macros everywhere makes the code more opaque, thus less legible, and therefore less secure. "Many eyes" can't make all bugs shallow if those eyes don't understand what the hell they are looking at.

That code is not dead, there are actually still people using OpenSSL on OpenVMS and actively providing patches for it

Then maybe they should be maintaining their own version of OpenSSL, rather than inflicting their unnecessary complexity on the other 99.9% of users and dragging down everyone else's code quality along with them.

Their solution was to use read and write which won't even compile on win32

Actually, those POSIX functions do exist and work just fine on modern Windows. See here: "Functions like open, fopen, read, write and others are available in the Visual C++ run-time library."

(In case you were wondering, they work fine on MinGW, too.)

The OpenSSL code was probably written back in the Win9x days when you really did need to do things completely different on Windows. Now that the industry-standard functions are supported, why include extra, completely unnecessary cruft behind an #ifdef? The more code, the more difficult to maintain and the more potential for bugs. Some of the "Windows-specific" code in the OpenSSL code base was hacks to make it compile on Visual C++ 5.0. Do you have any idea how ridiculously outdated that is?

Indeed, and you might want to take it even one step further, and test for --i = 0.

None of this will make any difference on any compiler with half a clue. Figuring out how best to translate these constructs into machine language is the compiler's job, and modern compilers (gcc, clang, and VC++) are pretty good at it. If decrementing and comparing to 0 is faster, then a modern optimizing compiler will do that automatically even if you use for(i = 0; i < 8; i++) instead of the other way around.