Self-driving car accidents: Robot drivers are 'odd, and that's why they get hit' - <AUTHOR> https://www.seattletimes.com/business/self-driving-car-accidents-robot-drivers-are-odd-and-thats-why-they-get-hit/?utm_content=buffer0acdd&utm_medium=social&utm_source=twitter&utm_campaign=owned_buffer_tw_m <comment><USER3> "Humans violate the rules in a safe and principled way...."

Thanks, it's nice to start my morning with a good laugh.

Maybe the author lives in some magical wonderland filled with good drivers, but this is not what I observe at all. People drift out of their lane for no reason. They careen past the stop line because they can't be bothered to push the brake pedal a bit farther down. They refrain from signaling because they just don't care. They blast through stop signs and red lights without heed to traffic or pedestrians. They brake spontaneously in the middle of a fast moving road. They drive fast in dangerous conditions and slow in safe conditions. They _spend half their drive texting because they think they 're the one person on the planet who is able to safely text and drive_. How is any of that safe or principled?

<comment><USER4> Would you accept "humans violate the rules in a safe and principled way, plus lots of other ways"?

I mean, you're obviously correct, human drivers do idiotic and deadly things all the time. But I think we can distinguish that from the behavior in the article.

Gently rolling a stop sign at a high-visibility intersection sounds like a safe and principled violation. Driving around a car waiting to turn left is a bit less safe, but still a principled or predictable violation. The Pittsburgh left is a (fairly) safe and principled violation.

None of those things are comparable to texting and driving, or ignoring a red light. They're informal adjustments to the traffic code that other drivers really do anticipate, and which aren't nearly as dangerous as general "bad driving".

<comment><USER5> > Gently rolling a stop sign at a high-visibility intersection

I've always heard this called a "California stop." Are you in California? Looking for a point of data.

<comment><USER4> Eh? I'm not in CA, and like the other answers I see this everywhere in the country. I suppose it's rarer in places where intersections are almost never quiet and empty, but I've seen it all over New York (not NYC), Ohio, Wisconsin, and a half-dozen other states. It's standard practice anywhere rural, and in a lot of suburbs.

</comment></comment></comment></comment><comment><USER6> "They drive funny" claims human, regarding high level of reporting of accidents where computer drivers are required to report encounters but humans are not.

If humans were required to report every bump and scrape, what would we find out? I suspect we would find that humans are just poor drivers overall, and "they don't drive like I do" is the number one cause of minor incidents worldwide.

My main submission to this argument is the ubiquitous rear-ending in the turning lane where the first car's driver starts to roll and then stops, while the second driver is turned to watch approaching traffic and thus oblivious to the behaviour of the car in front.

<comment><USER7> The issue isn't that the cars are worse drivers than humans. They're obviously going to be much better statistically. The article is just making the point that they're going to have to be programmed to break the rules just like humans do i.e. with speeding, stopping too often etc. If they are not programmed to break the rules, they will frustrate people and even cause accidents as humans try to interact with them. There's not always a good way to know that the car in front of you is being driven by a computer.

<comment><USER8> This will be an opportunity to fix the traffic rules to be more realistic. Often, the speed limits are too low in the US, and "everybody" goes faster. This leads to the problem of selective enforcement, and people not trusting speed limits when they are really neccessary.

In contrast, I've found most speed limits in Germany to be reasonable absolute maximum limits - except on one or two places on streets I know very well. And I'm not talking about the Autobahn - if I see 70 km/h in Germany (45-ish mph), its probably dangerous to go faster. If I see 45 mph in the States, it seems to mean "everybody go 55 mph".

<comment><USER9> > Often, the speed limits are too low in the US, and "everybody" goes faster.

Excessive speed is the primary cause of a third of all fatal accidents and a contributing factor in at least half. Instead of training the self-driving cars to be more human, we ought to train humans to act more like the computers! Speeding is one of the stupidest norms that exists in our society. We should definitely not try to encourage it.

<comment><USER10> No, difference in speed causes those accidents:

[https://en.wikipedia.org/wiki/Solomon_curve](https://en.wikipedia.org/wiki/Solomon_curve)

> Speeding is one of the stupidest norms that exists in our society.

Politicians arbitrarily setting the speed limits is the root cause.

The EU has many countries which have higher freeway limits, yet lower accidents per mile driven. They also have more stringent licensing.

<comment><USER11> Yeah, that's not a great study (though it was admittedly pretty groundbreaking,) and it doesn't actually prove that there is no relation between speed and accidents. Multiple studies since the 60's have shown different results.

>Politicians arbitrarily setting the speed limits is the root cause.

Of speeding, or accidents?

<comment><USER10> > Yeah, that's not a great study (though it was admittedly pretty > groundbreaking,) and it doesn't actually prove that there is no relation > between speed and accidents. Multiple studies since the 60's have shown > different results.

The link sourced multiple studies. The originals were dubious, subsequent ones not so much.

But the issue the Solomon curve and other similar studies points out is that humans (and largely Americans) will ignore the rules if they feel _they_ can safely go faster.

And sure, you can't ignore overall average speed. Crashes on roads where the average speed is 100 mph are going to be much more prone to fatalities than 55 mph roads. So, there are two rough equations: Lower average speeds mean less severe crashes; speed limits set to the 85th percentile mean fewer crashes. As the speed limit is raised (from 0), there will be at least one solution that satisfies both of those equations and results in the fewest fatal crashes (if that's your goal).

In certain situations the lower speed limits can make things less safe. For example, a straight, well maintained toll road with wide lanes, clear vision ahead, and say wildlife barriers that was designed for 75mph max speeds is constructed in a state with statewide 55mph speed limits. Construction uses the latest traffic easing and safety techniques, since you don't want to construct all roads to enforce speed limits that may change in the future.

So now most truckers and cautious drivers go 55mph, while people with less inhibitions are weaving in and out of them.

<comment><USER11> Are you talking about the wikipedia link? All the subsequent studies save one that it sourced disproved the first's premise or drew attention to serious questions as to its validity. Did you read them?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I'd say that instead of making self-driving cars as reckless as typical drivers, we should keep the cars driving by the book, and fine the people who collide into them. Will it cause frustration? Yes, but even today, people who try to drive safely and with respect to the law cause frustration too. And I think self-driving tech has enough momentum now that, frustrating or not, they _will_ get accepted anyway.

<comment><USER13> The other way to look at it is that the traffic laws, taken to the letter, are too conservative in some circumstances, and there are perfectly safe, more efficient limitations that can be employed (The 100% complete stop for example, frivolous waste of potential energy!) Maybe instead of teaching self- driving cars to break the laws like everyone else does, we should change the laws to reflect more how people drive.

<comment><USER14> > _there are perfectly safe, more efficient limitations that can be employed > (The 100% complete stop for example, frivolous waste of potential energy!)_

Genuine question: what do you think is the better alternative to the 100% complete stop? I'm not saying I think there is or isn't a better alternative, just wanted to know what you had in mind.

<comment><USER15> In the UK we have very few stop signs. In fact, in my entire life, I only recall ever coming across 2. We usually have a yield action at intersections so that you only even need to slow if the line of sight at the intersection is impeded to the point you cannot see the flow of traffic. Consequently there is no need to come to a full and complete stop unless the flow of traffic prevents your ability to turn where the yield sign actually requires that you come to a stop while you wait to merge into traffic. This functions far better than the ridiculousness that is stop signs that require you to come to a complete stop even if you are the only car on the road.

<comment><USER16> I'm a British person who had immigrated to North America. A four (or more) way stop sign is not replacing a yield at an intersection, it is replacing a roundabout. The reason you must come to a full stop is to signal to other drivers the time you arrived, since that is strictly the order that people use to go. It's also a safety issue since you need to check right and left for out of control cars, bikes and so on. As s system I prefer roundabouts as they keep the traffic flowing, but anecdotally the stop sign seems much safer. Finally it's a an enforcement issue. Cops don't have to argue that you didn't slow enough. If you didn't stop completely you broke the law.

<comment><USER15> Roundabouts instead of 4 way stops... you know what happens to a roundabout when the power goes out? Nothing.

<comment><USER16> Exactly the same happens with a four way stop. It needs 4 sign posts with stop written on

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> I wrote something similar on this subject a few days ago.[1] Autonomous vehicles (the good ones) have sensor-generated maps of what's around them, and those maps indicate what's unknown due to occlusion. Cautious behavior at intersections comes from that. If visibility is good, there's no hesitation.

This is fine. There are no CA DMV reports of "autonomous vehicle entered blind intersection and was hit by cross traffic". Near term solution: put a rear bumper on your autonomous vehicle which meets the old 5MPH bumper standard from the 1980s. Longer term solution: manually driven cars need basic anti- collision radar, which is now standard on many high-end cars and all Volvos, and may be mandated in the US just as ABS is now.

Useful temporary fix: brake lights that go up to super-bright ambulance level when the autonomous vehicle's sensors indicate something close behind and there's a need to brake.

[1] [https://news.ycombinator.com/item?id=15437322](https://news.ycombinator.com/item?id=15437322)

<comment><USER18> "Useful temporary fix: brake lights that go up to super-bright ambulance level when the autonomous vehicle's sensors indicate something close behind and there's a need to brake."

this seems like a pretty clever solution if it would actually encourage the correct behaviour in human drivers. unexpectedly bright tail-lights might just have the opposite effect though, and further distract the driver who is about to rear end you.

</comment></comment><comment><USER19> > the reality is that the self-driving vehicles are overly cautious.

Humans contribute to lots of accidents when they unconventionally yield the right of way. Other drivers which should be yielding are now faced with the unpredictability of the too-cautious ("dangerously" cautious IMO) driver re- claiming their right of way. Or they face the problem of other drivers in other lanes who don't notice that the incorrectly-yielding driver is letting another vehicle into their right-of-way.

<comment><USER20> Inappropriate yielding should be penalised just like lack of appropriate yielding.

At sea the COLREGS require ships with right of way to maintain their course and speed (unless of course they have to give way to another ship, or make evasive maneuvers). Of course fishermen tend to ignore this rule, changing their course and speed whenever convenient to them.

<comment><USER21> > Inappropriate yielding should be penalised just like lack of appropriate > yielding.

Uh, yeah, I've had too many close calls with people merging to just blindly assert my right of way every time.

<comment><USER20> COLREGS don't say do it blindly, why should you?

</comment></comment></comment></comment><comment><USER22> My friend was driving in Boston for the first time, and was rear-ended when he stopped for a light that just turned red, while the rain was just starting to sprinkle (so the oil was freshly slicking up the road). The guy was PISSED OFF: "I thought you were going to run the red light too!"

<comment><USER23> Almost got rear ended on my motorcycle because of this absurd behavior. Guy just blew by me on the right and ran the red light after I stopped. If there was a car parked on my right I would likely ended up on the pavement and likely the hospital. I've lived in MA most of my life but (and especially after spending the last four years in Austin), Boston is some next level bad driving.

I think the most infuriating part about driving in Boston is every week I can feel myself drifting farther and farther from the rules. I _always_ stop at stop signs and red lights. I mean, as a motorcycle rider, you follow the rules or you die. But here, I'm often forced to break the rules so I don't get hit by all the other people breaking the rules. My road-humanity is slowly slipping away.

I always used wonder how people get to be so absolutely terrible at driving. It's not like a minor slip up, a rolling stop here, a cutoff that they feel bad about there. It's this insane either A) extreme aggressiveness and willful disdain for the safety of other drivers around them or B) a complete and utter lack of awareness of where they are in relation to other cars and pedestrians. Usually a mix between the two. But what I realized is a good portion of the drivers around cities like Boston have _only_ ever driven around Boston. They've only ever driven in a place that, due to its layout, is a hodgepodge of hard-to-read intersections, a mish-mash of people who don't know where they're going and people who needed to be where they're going 30 minutes ago and heaven forbid you slow them down by another 2 minutes. They learned the rules of Boston, not the rules of a sane, conscientious, _safe_ driver.

I swear, if all these people rode a motorcycle for a month or took a MSF class, they'd all become much better drivers and realize the heinous unsafe conditions they perpetuate on a daily basis. That or they'd die because that behavior does _not_ work on a motorycle. At least, not for very long.

</comment></comment><comment><USER24> If autonomous cars become more common this seems like a problem that would solve itself. If more cars on the road are following the letter of the law then people will stop being so surprised to find a car following the law and won't be caught by surprise.

<comment><USER25> Exactly. And then there will be a tipping point where autonomous cars are the norm with people 'riding' in them and all of our lives will be made easier because autonomous cars will do the driving, and the traffic laws pretty much will be obsolete. It will just be routing autonomous cars various places.

</comment></comment><comment><USER26> At first (and probably for quite a while) self-driving cars probably need a big sticker that's easy to see so people know that they are going to be "different" on the road.

People will rapidly learn to recognize those "damn robot drivers" and adapt the same way they do now when they see the "student driver" placard or the unmistakable sway and surge of an intoxicated driver.

<comment><USER27> I wonder if having the sign the same colour as the L plates but with an A would help, given that learners are often much closer to following the rules and the colour might help human drivers pattern match even if they're not really aware of the A plate yet.

</comment></comment><comment><USER28> I take this as evidence to support my argument that (at least in North America) stop signs are mostly unnecessary and utilized badly. 90% of them could go, some replaced by yield signs, some just removed. An intersection with a line of sight onto cross traffic should not have a stop sign.

Maybe the robot drivers will finally drive home how dumb some of our road infrastructure is.

<comment><USER29> This is purely an anecdote, but in my city it's hard to cross a road as a pedestrian even when there's a stop or a priority light for pedestrians. I've been honked and yelled at for "not crossing fast enough" or whatever. Of course it's not the norm and most drivers are respectful and doing just fine, but even a couple of those in a month gets annoying.

I shiver at the thought of having to cross any of these if there was only a yield sign. The principle that I have priority is not important enough over not getting hit by a bad driver.

TL;DR: I agree 100% with your point, but I do think bad drivers should be taken into consideration.

<comment><USER30> You're definitely correct that yield signs make it harder to be a pedestrian–most American cities are awful for pedestrians to begin with, outside of a small core downtown area. Even intersections with proper crosswalks and lights are often massively wide with no middle refuge, have traffic crossing the crosswalk from multiple directions/lanes and poor sight lines, require multiple long waits at lights to cross all the various lanes etc.

There seems to be a growing use of traffic circles (with yield signs) in the US, which are very much like playing real life Frogger as a pedestrian: cars coming quickly around the circle, often not 100% comfortable with how it works, watching for cars around them instead of paying attention to people crossing at the exits. In a busy intersection you sort of have to step out and try to get someone to stop for you or dash across a gap in traffic–a firm stop required for cars makes for a much more pleasant crossing.

</comment></comment></comment><comment><USER31> > "Humans violate the rules in a safe and principled way"

I don't share this optimism. I've been driven by folks who violate the rules in totally unsafe and scary ways (though "principled" in a way, in that they do it consistently -- unless a cop is looking).

<comment><USER32> Spend some time driving in Latin America or West Africa.

The rules mean nothing, everyone drives freestyle. In towns and cities, it works extremely well because everyone is very attentive and ready for anyone else to do anything, at any time.

My experience in over 60,000 miles in those parts of the world through more than 30 countries would say they are an order of magnitude less crashes there than in US/Australia/Europe, in the towns and cities.

(Note: highway driving is a whole different story)

<comment><USER33> > My experience in over 60,000 miles in those parts of the world through more > than 30 countries would say they are an order of magnitude less crashes > there than in US/Australia/Europe, in the towns and cities.

Do you have any statistics that indicate that there are 90% fewer accidents in Latin American and West African cities than in Western, adjusted for the number of drivers? Seems rather optimistic.

<comment><USER32> No stats, because they would include highway, which will show Latin America and West Africa having much, much, much worse stats.

Certainly not scientific, though other people I know that have driven the world agree, driving "freestlye" is safer than following the rules.

</comment></comment></comment></comment><comment><USER34> As the number of autonomous vehicles increase, people's behavior will change in time. It is shortsighted to relax the rules for the benefit of current human drivers. Once there is a critical mass of autonomous vehicles, then you can then start modifying the rules to make traffic more efficient with the guarantee that the rules will be followed.

If and when rear ending an autonomous vehicle becomes a common problem, awareness will rise and it will become less of a problem. Besides, rear-ending something with a dozen cameras and indisputable telemetry is just a bad idea, financially speaking.

</comment><comment><USER35> This article is a good example of stupid tech reporting. Someone who's supposed to be a knowledgeable reporter does some speculating, without bothering with any actual data, and comes up with a so-called "problem" and idiotic suggestion for "solution".

The article suggests that, though self-driving cars don't crash into other cars, they "cause" crashes (mostly fender-benders) by driving in a different manner than humans. No evidence that they cause more fender-benders than humans, who drive all sorts of different ways. Apparently, the author thinks this is so obvious, no data is required.

Then, the article seems to propose that self-driving cars should be like humans, who allegedly violate laws in a "safe and principled" way. This ridiculous statement ignores the tens of thousands of people killed in crashes caused by human-driven cars every year, and the many tens of thousands severely injured, by these "safe and principled" violation of driving laws. Most accidents do not involve complying with traffic laws, actually. That's why we have traffic laws -- to prevent this carnage. Individually, however, we still tend to believe that even if we engage in risky behavior like speeding or running lights, we're not the one personally who will crash.

As to some people who think self-driving cars should speed because so many people speed, please check the mortality rates for accidents at various speeds (they're widely published) -- survival rates go down lots as speed goes up, especially if a pedestrian is involved. On the other hand, if you do the math, on most trips the amount of time actually saved is much smaller than the exhilarating sense of going faster than the next guy you get from even moving a couple of mph faster. This is why many major cities are reducing speed limits and taking other steps to reduce traffic speeds. Speeding, the most common rule violation in driving, is neither safe nor reasonable, and the author, supposedly an expert on driving, cannot provide any evidence to indicate that it is. Well, except that he seems to assume that tens of thousands of traffic deaths are acceptable and unavoidable.

Perceptive readers will notice that I haven't cited stats to support my assertions in this comment. That's because it's a comment and I'm not holding myself out as a journalist who's done sufficient research to report on issues of motor vehicle safety. I'm a mere commenter, but be sure, if you do the work to find out what the real numbers are (regarding both driving safety and actual driving times) it bears out what I'm saying.

</comment><comment><USER36> Same deal as [https://www.theverge.com/2016/4/8/11391840/us-navy- autonomou...](https://www.theverge.com/2016/4/8/11391840/us-navy-autonomous- ship-sea-hunter-christened)

"One consideration in implementing the ship's autonomous functions was making its movements seem human-like. Any maneuvers it makes to avoid collisions have to be detectable by crew on other boats, so changes in direction (which are more easily spotted) are preferable to changes in speed that might be just as effective but are less obvious signals."

Obeying rules is nice but you need to account for behaviour of human actors as well.

</comment><comment><USER37> Basically there are the 'rules' and there is 'how people drive'. As I recall Flocking behavior is largely group consensus driven, where members that disrupt the flock are penalized, ones that conform move at the flock rate, and small optimizations propagate by example.

I would expect lines of self driving cars along the right lane of the freeway driving at the speed limit while the non-autonomous drivers speed by them on the left. Merging into that would look scary but would be fairly straight forward as the robot cars would always yield rather than collide.

Going to be interesting to see how this evolves out in practice.

</comment><comment><USER38> One of the many ways that drivers can be more predictable to other drivers is to disobey the laws regarding pedestrian rights of way and safety. Drivers not only disobey these laws all the time, but they _expect you to do so too_ , lest they honk and use their car as a weapon to show you how angry they are that you let someone cross the street at an unmarked crosswalk.

Unfortunately for all those with fantastical fantasies about our autonomous car future, when they finally get here they're going to be slow. And that's a good thing, even if it means the utopia is still slow and congested.

<comment><USER28> A crosswalk by definition is marked.

Drivers expect other drivers to follow the rules of the road, not to be nice.

Did you hear about the woman in Canada [1] who tried to "be nice" and stopped in the middle of a highway to let some ducks cross? She killed a motorcyclist and his passenger.

Don't be nice -- be predictable.

Same is the reason why the bots get rear-ended -- everyone expects them to roll through a stop, who in the world does a complete, 3 second stop?

[1] [https://www.google.ca/search?q=Quebec+woman+stopped+for+duck...](https://www.google.ca/search?q=Quebec+woman+stopped+for+ducks+fatal+crash+-who)

<comment><USER39> Anytime a vehicle gets rear-ended, fault belongs with the rear-ending vehicle's driver for either failing to maintain safe following distance or failing to pay adequate attention to conditions in front.

And rolling a stop is not following the rules of the road, it is a dangerous violation.

<comment><USER40> > Anytime a vehicle gets rear-ended, fault belongs with the rear-ending > vehicle's driver for either failing to maintain safe following distance or > failing to pay adequate attention to conditions in front.

I don't think that's true on a highway or similar road. Stopping in the middle of the highway is very dangerous. You cannot blame the 150km/h+ cars to be able to stop safely in all situations.

<comment><USER34> Absolutely you can always blame the car that does the rear-ending, it is your responsibility to maintain distance and speed such that you can stop if the car in front of you slams on the brakes. Which can happen for a multitude of valid reasons, like something dropping of a truck in front, or an accident.

You will absolutely be at fault and stuck with the bill in every single rear- ending case, good luck arguing otherwise.

</comment></comment></comment></comment></comment><comment><USER41> I love the statement "Humans violate the rules in a safe and principled way". Really sums up the problem.

So when you break the rules, what principles (i.e. rules) are you following?

<comment><USER42> You assess the road conditions and conclude that the speed limit is set too low for a road that is in broad daylight and has no other cars. Are you implying that the speed limit is binarily safe, no matter the road conditions (night, rain, snow, congestion, etc)?

<comment><USER43> I doubt many drivers know their car and tyres well enough to assess the safe speed given current conditions. People either adapt to others or choose a speed they feel comfortable with. Speed limits are not perfect for every condition but humans are certainly not good at choosing a better one while driving.

</comment></comment></comment><comment><USER44> Shocked and saddened to see such blatant, disgusting victim-blaming…

</comment><comment><USER45> So, in other words, the law is wrong. And the is kept as such for purposes of revenue enhancement (illegal taxation)?

I can see a few interesting govt things coming out of "Autos":

1\. Revenue from bad laws drops to 0. These vehicles follow the letter of the law. And they have the logs to prove any sort of claim against the former.

2\. A false claim is filed (BLM makes about a point about this..) and says driver did X. Is this the person's responsibility, or the company who wrote the AI?

</comment><comment><USER46> This seems at least lazy, and at worst click-mongering, in light of the recent article on Waymo's testing regime.

[https://www.theatlantic.com/technology/archive/2017/08/insid...](https://www.theatlantic.com/technology/archive/2017/08/inside- waymos-secret-testing-and-simulation-facilities/537648/)

It has several discussions on making self-driving cars act more human-like:

> It turns out that the hard part is not really the what-if-a-zombie-is- > eating-a-person-in-the-road scenarios people dream up, but proceeding > confidently and reliably like a human driver within the endless variation of > normal traffic.

> Waymo seems like it has driving as a technical skill—the speed and direction > parts of it—down. It is driving as a human social activity that they're > working on now. What is it to drive "normally," not just "legally"? And how > does one teach an artificial intelligence what that means?

</comment><comment><USER47> When I was in university we made a project for the Statistics class: Measure the velocity of cars from bridges for cars going outside and inside a big city in Europe.

We controlled all big highways.

The result: Over 95% of the cars were going way faster than what the rules were and nothing wrong happens. That is, rules are wrong because politicians decide them and they are always extra cautious, so they are not responsible for accidents, and they make money out of fines.

I see a big problem if everybody follows the law every time, like robots do, because rules are so wrong in the first place.

One of the big things with robots is that you could have real feedback with real data measuring in the real world. You don't need to guess, just test in the real world and measure the consequences for example, of increasing the velocity.

You could also change the parameters on real time when you know there is ice or snow in the road... you don't need to have the same parameters when it is sunny in summer and in winter.

<comment><USER48> > rules are wrong because politicians decide them

I would have thought speed limits are decided by technicians, based on statistics. I don't think it's elected politicians who decide them.

<comment><USER49> They are decided with a political idea in mind, consider that the design speed for interstate highways in the US is 75 MPH

<comment><USER48> I'm not sure what you're trying to say. How is 75 mph some political goal?

</comment></comment></comment></comment><comment><USER50> Perhaps we need an "autonomous vehicle" sign prominently displayed on the car, similar to how we display "student driver" signs. When I see a student driver, I automatically assume their driving behavior will be significantly different than the other cars on the road and I adjust my driving accordingly.

</comment><comment><USER51> Perhaps there should be a visual indication on self-driving cars. Not something ridiculous on the roof, maybe something glowing in the license plate area, or upper window area.

I imagine most people are more considerate around learner drivers because of the signs, without which you could (quite rationally) get frustrated.

</comment><comment><USER52> How much is this exposing humans who are not paying attention (ie: on their phone) while driving?

I would like to know to what extent are accidents caused by robot drivers being "odd" versus humans not paying attention and then blaming the robot for being odd.

(ED: grammar)

</comment><comment><USER53> I think most people discount the effect that connected cars will have on safety even when you have mixed levels of human operated and level 1-5 AVs. If a car operated by a human has even a basic connected control system in it then a AV can simply communicate that the driver is about to hit the AV and the human operated car will take some basic corrective action.

The interesting tech is not only AV but the infrastructure where cars communicate automatically about which lanes there in, what their intentions are etc.

The current use case I think is cool is a car comes up to a slow truck and the truck communicates to the car that the passing lane is clear.

<comment><USER43> > The interesting tech is not only AV but the infrastructure where cars > communicate automatically about which lanes there in, what their intentions > are etc.

I don't think that this will really work. Considering how interaction between tech of different manufacturers works in other areas, I doubt that cars will be able to safely communicate within milliseconds in high risk situations. But they won't need to, they can just use their own sensors to detect what happens around them.

</comment></comment><comment><USER54> I have just also read an article that talks about this matter at [https://www.lemberglaw.com/self-driving-autonomous-car- accid...](https://www.lemberglaw.com/self-driving-autonomous-car-accident- injury-lawyers-attorneys/). I actually haven't been able to imagine how if we all use this kind of car. I personally will always choose manual cars if possible.

</comment><comment><USER55> In Australia, stop means stop. If it's safe for you to roll through, there will be a GIVEWAY sign. But if you roll through a STOP you're an absolute fool who's risking the lives of yourself and others. We don't have four-way stop signs. We have roundabouts, or give one street priority and the other STOP signs in cross-streets.

I recently passed my California driving test, and I've observed that the placement of STOP signs here does not correlate with safety in the same way as Australia and lots of people roll through them.

I think self-driving cars would do a lot better in Australia.

<comment><USER56> You've hit on what I see as the big problem with stop signs in the US - <USER2> are inconsistent. Sometimes they are used at intersections where failing to stop is very dangerous, but much more often they are used when a yield sign would be sufficient. It conditions people in their normal driving to think of stop signs as recommendations, not requirements. This would seem to increase the danger of intersections where stopping fully is really necessary since people are more inclined to roll pass the stop sign.

</comment></comment><comment><USER57> I think I was in a low speed collision of this nature before autonomous cars even existed, and I was in the role of the autonomous car. I was inching forward at a stop sign because I couldn't see on coming traffic from the left. The driver behind didn't understand what I was doing, lost patience, and deliberately bumped me. (I'm not going to commit to merging into traffic without being able to see what's coming towards me, naturally.)

</comment><comment><USER13> People mention "when there are no more human drivers" like it's the inevitable endgame (probably people who work for autonomous driving companies I'm guessing) I hope I don't live long enough to see the day the law prevents me from riding a bike down the street, or walk down it for that matter. The implication of the above assumption is there is no freedom. (Analogous to gun ownership controversy, btw)

</comment><comment><USER25> Lol. I love how they say humans need to drive more like robots when it comes to traffic cameras, insurance, and making big money for insurance and gov't.

However, when it comes to something that threatens these industries...it's suddenly the humans that need to lighten up?

I'm ready to get rid of the entire auto industry once and for all, along with all of the insane amount of income they generate off the backs of regular people.

</comment><comment><USER58> I'm sure that when you're trying to engineer a participant in a complex system, factoring in your own impact on that system and how it might come back to affect you is as simple as it sounds. I mean, it's not like self-reference is the generator of intractable complexity in every situation it is found, right?

</comment><comment><USER59> Instead of making their cars more human like self driving companies could start a campaign similar to the one against jaywalking 90 years ago. This time against human driven cars.

[http://www.bbc.com/news/magazine-26073797](http://www.bbc.com/news/magazine-26073797)

<comment><USER60> Yes, I think this is the solution. Do not conform to the pre-existing culture. Force a new one. Through marketing/consumerism, sheer numbers of self driving cars on the road, I don't care. The current culture needs to die. It's cool that it got us here, but it has so many drawbacks that it's not worth using as a starting point for a new generation of autonomous vehicles.

</comment></comment><comment><USER61> There is an interesting tangent to this story that I think would answer some of the written rules of the road versus custom. By and large, do the people designing robot cars like to drive? Do they like getting out on the road and driving around?

</comment><comment><USER62> This might be a problem with the ways roads are "signed". I believe that stop signs are much more common in the US than in Europe where there are signs that are more relaxed. I.e that you have to stop only in case of another car.

</comment><comment><USER63> Tangential to the article, but I'm still waiting to see how these self-driving cars fare in European villages (& elsewhere), which are, shall we say, more _challenging_ to navigate than Californian roads.

</comment><comment><USER64> In other words, bad drivers tend to run into things. It isn't really the case that no one ever conservatively follows the rules of the road while driving manually.

</comment><comment><USER65> Rationalization hamstering at full speed.</comment>


Foxconn Worker Says iPhone 5 Arrives This June - <AUTHOR> http://www.tomsguide.com/us/Foxconn-iPhone-5-quad-core-WWDC-Samsung,news-13993.html

<comment><USER2> WOW. I haven't even gotten my hands on 4s. And unannounced iPad3 tablet. I wonder what they'll produce next.</comment>


Lykdat: Image Based Fashion Search Engine - <AUTHOR> https://lykdat.com <comment><AUTHOR> Hi guys! We've implemented this product with minimal features in order to get some feedback. Please be nice! :)</comment>


Two new vulnerabilities found in Oracle's latest Java patch - <AUTHOR> http://www.informationweek.com/security/application-security/java-hacker-uncovers-two-flaws-in-latest/240146717

<comment><USER2> Christ, as someone who wrote some Java software long, long ago: Does Oracle not care how damaging this stuff is to the already battered Java "brand"?

When Firefox brings up a "Java is a potentially malicious plugin" dialog by default, you should be trying to turn that ship around.

<comment><USER3> Perhaps this is the excuse to generate more critical updates, increasing the number of accidental Ask toolbar installs.

Oracle doesn't believe in "free".

<comment><USER4> Java in the browser has been battered for a while. It's been supplanted by Flash for the most part which will be replaced by Javascript in the browser. Oracle is expecting Java VM's to disappear from the browser altogether and is glad to wring out as much cash as possible in the meantime.

</comment></comment></comment><comment><USER5> To be clear -- neither of these vulnerabilities is likely to cause much damage in the wild for anyone who has installed the new version.

Applets don't run anymore unless you explicitly click through to authorize them.

If you aren't expecting your game to run, etc., you click "no".

I'm disappointed about all this (particularly since it's on its way to destroying my side business, which relies on applets), but I'm also frustrated by the reporting -- Java applets are still more secure than ActiveX used to be, right? There's a sandbox, and now applets won't even run at all without explicit permission from the user.

That's pretty close to "don't go to shady websites and install software they offer you" at this point.

<comment><USER6> If my mom sees a pop up while browsing, she will always click yes.

<comment><USER5> If she clicks yes to all popups, then Java is a risk to her even with all security bugs patched, because I can request permission to _get out of the sandbox_ with a signed applet, and if she approves I can do whatever I like with her computer.

Of course, if she's opening odd-looking links in her email anyway (which is how she'd _get_ to a site that might include a dangerous applet) there are likely all kinds of attack vectors that she's vulnerable to.

</comment></comment></comment><comment><USER7> I was a Java developer, and when Sun was acquired by Oracle, I knew it's time to move on. Now I'm coding Ruby, and whenever I look back, I see Oracle raping Java - suing the good guys, adding malware to Java installers, increasingly introducing new security holes. It's such a sad sight...

<comment><USER8> To be honest a lot of the major security bugs were actually inherited by Oracle from Sun when they bought Java. In 2011 we had two major Denial of Service working on any Java webapp server that were present since more than ten years in Java (one of them was a known-but-never-fixed bug and the other was unknown-but-already-existing).

The Java applet SNAFU is totally Sun's fault and the wasted time and energy spent making these applets work (and hence making Java plugins for the various browsers) should have been spent by everyone for most interesting purposes.

Regarding the "time to move on", I hardly think so: Java is still increasingly popular and it's very hard to find a big company not using Java anywhere in its stack.

And you mentioning Ruby in response to security holes is particularly ironic seen that lately Ruby hasn't exactly been proved rock-solid from a security standpoint ; )

<comment><USER9> The big "ruby" vulnerabilities that came up recently were issues in rails. I don't think that there's much irony here since the response from the rails core team was fast and professional, as was action taken by the community to patch existing web apps. Oracle sat on known vulnerabilities and didn't scramble out a fix until the department of homeland security got involved. Obviously we're comparing applets and oranges here, but Oracle deserves a heap of criticism over how it's handling these issues, and it really brings the future of their Java codebase into question.

</comment></comment></comment><comment><USER10> More vulnerabilities - more toolbars! What's not to like.

</comment><comment><USER11> Most of these vulnerabilities are break outs of the security manager. A lot of other VMs do not have security managers ("think of eval").

</comment><comment><USER12> Oracle is becoming a parody of itself. Can they just hand off the entire Java platform to a capable 3rd party already?

<comment><USER13> Did Oracle introduce these bugs?

<comment><USER14> Have they been permitting anyone who isn't oracle affiliated to work on the sandbox? I was under the impression that the core development and compiler work was all in house.

<comment><USER13> Are you sure these bugs are new? The Java Applet Sandbox doesn't exactly have a spotless security history.

<comment><USER15> One of the bugs is fairly old, the other (which is required for the overal exploit) is new-ish (introduced in Java 7), but probably not as new as saosebastiao was implying (as the title of this HN post can be parsed as "the bugs were introduced by the patch attempting to fix the other bugs", which is definitely not the case, AFAICT).

> Issue 51 affects both Java SE 6 and 7. Issue 52 is for Java SE 7 only. Since > both issues are required for the attack to succeed, we treat it as Java 7 > specific only.

\-- <http://seclists.org/fulldisclosure/2013/Jan/195>

</comment></comment></comment></comment></comment><comment> jy-p maybe oracle would fix my javas if i paid them for a support contract.

it's only USD 10 mln :P</comment>


Bing Overtakes Yahoo as the #2 U.S. Search Engine - <AUTHOR> http://blog.nielsen.com/nielsenwire/online_mobile/bing-overtakes-yahoo-as-the-2-search-engine/

<comment><USER2> I'm having a hard time understanding the significance of this news given the Bing / Yahoo.com partnership (Bing started powering Yahoo.com search in late August). Going forward Bing's success will be measured in terms of its performance vis-a-vis Google, so what's the relevance that it overtook Yahoo in market share?

<comment><USER3> Most users aren't aware that Yahoo is powered by Bing, so the fact that Bing overtook Yahoo in search shows that Bing has gained (or Yahoo has lost) significant ground. This isn't searches powered by Bing, but searches actually on Bing.com.

<comment><USER2> But still, why is it relevant or meaningful to compare the market share of Bing.com vs Yahoo.com since the two are now in a formal partnership going forward? Isn't the central issue: Bing + Yahoo vs Google?

<comment><USER4> You're conflating brand with technology. Yes, the back end is the same, but the point is that the Bing-branded site is now ahead of the Yahoo!-branded site.

<comment><USER2> Bing gained market share at the expense of Yahoo. Google's market share remained flat for the year. The net effect is that Bing + Yahoo has not gained ground on Google. So back to my original question, what is the strategic significance of Bing overtaking Yahoo in market share?

<comment><USER5> searches through Yahoo.com don't generate any revenue for Microsoft do they? Ie they show Yahoo ads, not ones that give Microsoft $$? I could be wrong about the deal specifics though.

Also, Microsoft doesn't really want people searching through Yahoo.com, in a few years time they could power their results through Google and Microsoft wouldn't be better off. They want brand recognition for Bing, so gaining market share for Bing itself is better for them.

<comment><USER6> i think the yahoo bing deal is for 10 years. so yahoo isn't going anywhere for a while.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> That's good for BING, only 52% to go. (well, actually more like 26% to achieve parity).

I don't see how google can go up 1% / month _and_ go up 1% / year at the same time.

Bing growing 30% per year and two percent per month means that they're already flattening out though.

In the article they note that since BING now powers Yahoo! search since August that BING actually has a marketshare that is roughly 26% instead of the 14% it has on its own domain.

<comment><USER8> > I don't see how google can go up 1% / month and go up 1% / year at the same > time.

That would work if they hadn't grown in the previous 11 months. Unless I'm reading it wrong, which is always a possibility.

<comment><USER7> On a table listed in 1/10th of a percent I find that unlikely.

</comment></comment></comment><comment><USER9> These numbers seem off to me. Does anyone here actually run a site where Google is only 65% of your incoming search traffic?

Looking at traffic for a few of my own sites (mostly tech related, admittedly), Google is consistently in the 92-96% range.

<comment><USER7> 83% for google, 5% for bing, 5% for yahoo, 7% small fry. 100 K uniques on that site per day

84% for google, 6% yahoo, 3% bing, 7% small fry, 1.8 M uniques / day on that site.

That's according to analytics ;)

<comment><USER10> I'm curious to know who "small fry" is. DuckDuckGo? ISPs? That's significant traffic share even if it's split between several second tier search engines.

How many of them are powered by Google/Yahoo?

<comment><USER7> As much as I like duckduckgo it's not even on the map.

Even Altavista is larger than duckduckgo and they're at 0.14% or so.

[http://siteanalytics.compete.com/altavista.com+duckduckgo.co...](http://siteanalytics.compete.com/altavista.com+duckduckgo.com/)

So if that holds true on the percentage then duckduckgo is at about 0.035%. Which is really not bad at all.

Small fry: search.com 2.7%, ask.com 1%, < 1%: naver.com , aol , baidu , yandex , altavista

<comment><USER10> Heh, I thought I could find a niche search engine I could advertise on that isn't saturated with competitors but it looks like I'll have to wait for ddg to start accepting ads. Search.com: google Ask.com: google Aol: google altavista: yahoo

naiver, baidu, yandex are local search engines.

It's amazing how much the search market in the US has consolidated. You would think with the declining cost of computing power someone out there would be building their own index.

It's also interesting that cuil doesn't appear in your stats at all.

Free startup idea: Build a niche search engine covering a curated list of sites(like google custom search but with value adds like ddg). Sort of like what blog search engines are doing, but in another area.

<comment><USER7> For ddg to be of any use to you though, you'd have to have sufficient searches in your keywords of interest that it would be worth their while to take your money.

Or you'd have to go overbroad.

Cuil is dead, they've tried to re-invent themselves in april as an encyclopedia, I think they must have missed the memo about WikiPedia's continued success.

Their search results suck too...

Duckduckgo.com is larger than cuil!

<comment><USER10> Nope...as long as 1. There is little competition, no quality score, and low click prices and 2. Traffic remains high quality and there is solid fraud detection I could probably monetize a good percentage of searches on ddg with affiliate offers, I wouldn't even need to arbitrage to higher paying ads like AdSense.

If the price is right, almost any search can be monetized.

This is how 2nd tier engines like 7search make money, except they have too much low-quality international and bot traffic to give steady conversions.

ddg could easily monetize and attract lots of advertisers if they published their exact search data, keywords and counts. Wordtracker is making a mint, millions and millions of dollars simply publishing dogpile.com search data, which has a tiny (1%) share of the search market. SEMRush is scraping Google for search data and has over 70,000 customers.

Nobody else currently does this. Privacy concerns aside, if there were a search engine that had a good keyword tool designed for advertisers, it would attract ad money in droves.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Hat's off to Microsoft on this one - they've earned it.

I don't use Bing for my day to day search but I've used their travel search and it's not too bad. It's definitely no Hipmunk, but it's clean, minimal and pretty snappy.

They've made some effort to take a dull product, make it useful, improve its design and differentiate it from the competition. Yeah, the logo is hideous and embarrassing. Yeah, they've also spent a lot of cash on the advertising.

In the end, though, they've expended more effort in making their search product worth using than Yahoo has recently. So bravo.

Meanwhile: Boy, has Yahoo just lost its fighting spirit or what? What are they doing over there? There's never any interesting news from their corner. Stuck in the mud. They don't even own their search results or PPC product anymore. It's a shame, they've got a good and trusted brand.

<comment><USER12> Yahoo, within the last five years especially, seemed to fall victim to the economics of the search engine space. That is, they failed to properly differentiate their product in any meaningful way and never once had a very strong focus on the experience of search. Web search just became too important and they were relegated to continually play catch-up while Microsoft crafted their strategy which, from this bit of news, seemed to have been fairly effective.

</comment></comment><comment><USER13> Bing has a tough battle especially because most people (including me) equate the notion of a comprehensive search result for a query to what Google produces for that query. That is expected considering we have used it for so long.

Bing is my default search engine because I'm paranoid about Google's tracking practices. In my experience, I still see cases where I do not find (all results, enough results, related results, etc) what I want on Bing and then I try Google and find it.

They've done a decent job nevertheless.

</comment><comment><USER10> They certainly built a great product, but it's easier to gain market share when you have a $300 million marketing budget.

Aside from heavy branding, they also built an absolutely brilliant, perfectly executed long-tail SEM campaign.

According to my internal data, Bing is one of the largest advertisers on both Yahoo and Google, approaching eBay and Amazon in volume.

SEMRush shows 50,000 paid keywords for Bing- but that's a tiny fraction of their actual ad spend.

</comment><comment><USER14> So, does Bing finally allow restricting your search results to specific period? The lack of this crucial feature was why I wouldn't even bother using it, and it still doesn't seem to be available (I just had a quick look out of curiosity).

</comment><comment><USER15> Another data sample (5 billion pageviews per month) that doesn't exactly confirm the Nielson data [http://gs.statcounter.com/#search_engine-US- weekly-200931-20...](http://gs.statcounter.com/#search_engine-US- weekly-200931-201037)

</comment><comment><USER16> All that aggressive advertising looks like it has paid off. And competition is always good for any market.

</comment><comment><USER17> Is it that big of a deal considering Bing powers Yahoo search anyway...? The two companies have a partnership.</comment>


GPU "supercomputers" provoke call to improve password security - <AUTHOR> http://www.bbc.co.uk/news/technology-10963967

<comment><USER2> Alternatively, we could all use scrypt.

The nice thing about proving limits on what can be done with custom silicon is that you automatically have limits on any future CPUs/GPUs/Physics offload engines/etc.</comment>


Benefits of responsive E-mail templates for any startup business - <AUTHOR> http://www.cgcolors.com/blog/importance-of-responsive-email-templates/ <comment><USER2> Your comments captcha box is broken so I can't leave a comment on this article so here's my feedback on the article

Wow, what an utter waste of time this was. How about sharing some templates, frameworks that can be used to create some, websites used to test responsive email templates. Hell, share anything other than a statistic and say "this is important."

Here's some that you could have shared: [https://github.com/sendwithus/templates](https://github.com/sendwithus/templates) or [https://github.com/zurb/foundation-emails- template](https://github.com/zurb/foundation-emails-template) and lastly [https://maildeveloper.com/](https://maildeveloper.com/)</comment>


How to prepare for the coming IT skills revolution - <AUTHOR> http://www.computerworld.com/s/article/9227617/IT_Skills_Jumping_the_Chasm?taxonomyId=14&pageNumber=1

<comment><USER2> This article mostly related to the hardware aspect and primarily from the business (or well-to-do, informed manager) perspective.

I was hoping it would concentrate on the lack of programming skills and possible solutions but it primarily seemed to very mutely classify "that computer/tech stuff" in general as they mention both hardware changes and offshoring software with a passive non-specific brush.

A decent read, even though it holds no value to someone in the industry looking to produce things (such as software or solutions to hardware problems).</comment>


China's consumers hate Airbnb's new Chinese name - <AUTHOR> https://qz.com/939253/chinas-consumers-hate-airbnbs-new-chinese-name-so-much-that-they-are-brainstorming-a-new-one/ <comment><USER2> It's not _that_ bad.</comment>


Structorizer: Nassi-Shneiderman diagrams - <AUTHOR> http://structorizer.fisch.lu/ <comment><USER2> I had to make these as part of an introductory programming class in college, using this specific software.

I'm not sure if it's a shortcoming of the software or the overall idea of an NS chart/diagram, but boy, these suck. We were using Java in the class I had to write them for, and a lot of ideas weren't smoothly represented with these charts. They were a pain in the ass more than anything, and I have no idea why I would painstakingly rewrite the program in an overly verbose chart when I could just be writing the program and properly commenting it.</comment>


Can you compete with big companies? - <AUTHOR> What is the value in spending time/money/energy on a project/idea than can probably be copied by big players? Unless it can be patented, or unless it's too hard to copy, is it worth it? <comment><USER2> Big companies don't necessarily want to compete.

\- they buy companies to augment their portfolio

\- Google Cloud Partner Program is seeking companies to support first/last mile for software and products on their platform.</comment>


Build Your Own Lisp: Learn C and build your own language in 1000 lines of code - <AUTHOR> https://leanpub.com/buildyourownlisp/ <comment><USER2> This book is available for reading online at [http://buildyourownlisp.com/](http://buildyourownlisp.com/)

I'm not sure how long it will be available now that it's being published by Leanpub.</comment>


A Few Easy Ones from Raymond Smullyan - <AUTHOR> http://weblog.raganwald.com/2008/05/few-easy-ones-from-raymond-smullyan.html

<comment><USER2> One of Raymond Smullyan's best contriubtions is his allegory "Planet Without Laughter"

<http://www-cs-faculty.stanford.edu/~knuth/smullyan.html>

I like things that encourage people to expand and/or examine their world views.

</comment><comment><USER3> If my boss saw me on Hacker News for 3 hours trying to solve this puzzle and said, "I forgot to take my Xanax this morning, I never lie, and all the other programmers are working hard, therefore you're fired," would that make him insane?

<comment><USER4> You need a new boss ;-)</comment></comment>


RISC instruction sets I have known and disliked - <AUTHOR> http://blog.jwhitham.org/2016/02/risc-instruction-sets-i-have-known-and.html <comment><USER2> Historical nit: I always considered the CDC 6600 to be the first commercial RISC machine, although given its strange architecture, I can see that others might disagree. It had multiple floating point and integer processors. An assembly programmer had to be aware of them all. I would not write two FP divides in a row because the second would stall waiting for the first to finish. I could write two consecutive FP multiplies, because there were two FP multipliers. Instruction timings were always a consideration in selecting registers, because you wouldnt want to try using a register that was the target of another instruction until that instruction had completed. Fortunately there were interlocks so that you would get the register contents expected rather than some undefined intermediate state. You always had two or three parallel instruction flows going to take ad vantage of as many of the 10 or so processors available.

Other aspects of the architecture were truly strange. There were no load or store instructions. They were a side effect of setting an address register. I was the lead developer for two of the PL/I compilers for the 6600. Much fun. For those interested in strange architectures, I recommend the Wikipedia article [https://en.wikipedia.org/wiki/CDC_6600](https://en.wikipedia.org/wiki/CDC_6600).

<comment><USER3> That was Seymour Cray, and his Cray machines were even more RISC-like. The Cray I was a very simple machine; it just had 64 of everything.

</comment></comment><comment><USER4> > RISC instruction sets like PowerPC are usually expected to be highly regular > [..] whereas the CISC style of instruction set is expected to be highly > irregular and full of oddities

No. Not true at all. Not even close. CISC instructions are expected to be _complex_ , hence the name. MC68K was pretty regular, NS32032 highly regular, both CISC.

RISC are _reduced_ , not _regular_ , so for example you'd expect memory access to only occur with specific memory access instructions, whereas all arithmetic and other computation only deals with registers.

So CISC was usually _more_ regular, not less. x86 is the exception, because it was just extensions heaped on top of extensions: 8080 8 bit -> 8086 segmented 16 bit + 20 bit addresses -> 80286 protected 16 bit segmented with 24 bit addresses -> 80386 semi-segmented/mostly flat 32/32 bit, etc.

<comment><USER5> That's a point I haven't seen before. Yes, many x86 haters who tend to like RISC architectures typically praise M68K's for their ISA. Clearly there's something else outside of RISC and CISC. You might have figured it out. Maybe not. Worth thinking on.

</comment></comment><comment><USER6> CISC has always been much nicer to hard write assembly code in than RISC is. The only reason RISC was able to take off was that most code started to be generated by compilers rather than through assemblers.

Given the advance of modern computer architecture that the author talks about many of the old advantages of RISC no longer apply. If you're going to be doing out of order execution the the extra effort in implementing some extra instructions really isn't important for application processors.

The big advantage that RISC has these days is that fixed width instructions are easy on the decoder. You can also have variable width instruction that use UTF8esque byte marking to make things easier on the decoder but x86 doesn't have anything like that. But then again separating them entirely in the ISA makes thing easier on the designers.

Oh, and it's a bad idea to touch memory multiple times in a single instruction on a modern machine but Intel's optimization manuals warn you not to do that and compilers abide by those warnings. If you want an ISA feature that's really hard to design into a high performance uArch then there's indirect addressing but unlike most CISC ISAs x86 managed to avoid that one.

The advantages of RISC might be overblown in some sense, but there have been a lot of new instruction set architectures developed over the last 20 years when the RISC/CISC debates were raging. Many of those have been weird in various ways but almost all look a lot more like RISC instruction sets than CISC instruction sets and it's not just because people are following the herd.

And I've got the sense that my inside view of the issue is underestimating now advantageous RISCishness is. When ARM had the opportunity to redesign their ISA when the transitioned to 64 bits they simplified their ISA quite a bit and increased the number of registers from 16 to 32, basically making their ISA much more similar to a classical RISC design. I don't really understand why they thought that going that way was an advantage but it seems like people actually involved with designing these things instead of just thinking about them in their armchairs still think that RISC has a lot of advantages.

<comment><USER7> > The big advantage that RISC has these days is that fixed width instructions > are easy on the decoder.

One thing that I've wondered is how much more efforts are needed to decode variable-width instructions. Decoding itself sounds fairly easy (but frankly I don't know any details), to the point that the amount of time needed for loading/storing/calculating overwhelms that of decoding. But decoding should happen extremely fast to fill the pipeline, so the speed might still matter. Can decoding instructions be an actual bottleneck?

<comment><USER8> OH, my, yes, it can become a bottleneck. Disclaimer: It has been a good many years since I was privy to the innards of an X86.

In the X86, it is possible for an instruction to be from 1 to 15 bytes long. (Maybe more today? It was 15 when I cared.) All you can tell from looking at the first byte is that it is either one byte longer than one byte. All you can tell from the 2nd byte is that it is either 2 bytes or longer than 2 bytes, and so on. When you walk all the way out to the 15th byte, you might find a MOD/RM field, which may contain invalid combinations. _Finally_ you have enough information to raise (or not) the illegal instruction exception. That is one very nasty equation.

Just one example of how variable instructions can become annoying to a logic designer. OTOH, some machines are very regular in how instruction length is specified -- in IBM 370 code, for instance, you can look at the first 2 bits and know the instruction width. X86 is an example of organic accumulation of features over time leading to a large collection of special cases.

<comment><USER9> The majority are below 4 bytes though, and ModRMs are either the 2nd or 3rd (in case of 0F escape or other prefix) byte. The 15-byte limit still applies, and is very rarely approached. As I understand it, modern x86 decoders can handle (multiple of) the smaller instructions in one cycle, while longer ones take a cycle or two more.

<comment><USER3> Intel and AMD approach this differently. Intel decodes a few instructions ahead of execution, and sometimes decodes speculatively. AMD at one time was expanding an entire cache line to fixed length instructions and executing the decoded form.

X86 allows you to store into code, even immediately ahead of execution. This made sense in the 1970s when Harry Pyle designed the instruction set and CPUs were slower than memory. Superscaler CPUs have to support this. But, since almost nobody does that any more, they don't do so efficiently. Storing into code near execution causes an exception event, flushing all the superscalar lookahead and backing up to just before the instruction doing the store into code. Then the code gets modified, and the pipeline reloads, having lost tens to hundreds of cycles.

</comment></comment></comment></comment></comment><comment><USER10> The IA64 (Itanium) series on Old New Thing seems to highlight a very crazy instruction set and architecture:

[https://blogs.msdn.microsoft.com/oldnewthing/20040119-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20040119-00/?p=41003)

[https://blogs.msdn.microsoft.com/oldnewthing/20150805-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20150805-00/?p=91171)

</comment><comment><USER11> It's unfortunate he didn't touch more on the DEC Alpha AXP. It was designed from the start to be a 64-bit chip, unlike most 64-bit ISAs in use today.

Sure, it took them a bit to be convinced that single-byte loads and stores were worthy of dedicated instructions.

It was designed so that most of your kernel code wasn't actually running in a privileged CPU mode, but instead make upcalls to PAL code, a sort of super lightweight hypervisor that emulated how ever many of rings of protection the kernel needed. (Ultrix and Linux needed 2 rings. VMS ran on another set of firmware that emulated more rings.)

It was a nice clean design that was running at 500 MHz back when Intel could manage 200 MHz. Its memory model was more friendly to parallel execution (and less friendly to compiler and JIT writers) than the x86 memory model, forcing weaker consistency guarantees out of the JVM memory model as a result.

It seems a shame to me that the architecture was never revived. I'd like to hear more about its quirks and flaws.

</comment><comment><USER12> Kinda seems like the compiler just shouldn't allocate r0 for inline assembly on PPC, since it's only valid in special circumstances. Hard to fault the ISA a lot since this is basically the compiler backend author(s) missing a corner case, which is quite easy to do considering the breadth of a compiler backend.

<comment><USER13> Yeah, that's not about the ISA, that's just Evidence That GCC's Inline ASM Functionality is a Mess #938292721

See also: [http://free-electrons.com/blog/how-we-found-that-the- linux-n...](http://free-electrons.com/blog/how-we-found-that-the-linux- nios2-memset-implementation-had-a-bug/)

See also: [http://robertoconcerto.blogspot.ca/2013/03/my-hardest- bug.ht...](http://robertoconcerto.blogspot.ca/2013/03/my-hardest-bug.html)

<comment><USER14> Alternately it could be seen as evidence that PowerPC assembly _syntax_ is a mess. For anyone who doesn't know, the way it works with typical PowerPC assemblers is that instructions take unadorned numbers for all arguments, and determine whether they refer to registers or immediates based on the instruction: "li 1, 2" sets R1 to the immediate 2 ("load immediate"), while "mr 1, 2" sets R1 to the value of R2 ("move register"). And then because people find bare numbers confusing, you have includes that do "#define r1 1" or equivalent for each register, so when writing assembly manually you can write "mr r1, r2". But because these are just dumb macros, nothing stops you from writing "li r1, r2" \- the assembler will just macro expand r2 to 2 and treat it as an immediate!

Other architectures have the R prefix as an intrinsic part of the syntax, so if you write R2 in a slot where the instruction requires an immediate, you'll just get an error. If PowerPC did that, you'd still need to remember the right inline assembly constraint letter for GCC, but getting it wrong would 'just' result in an unpredictable compile error when the compiler decided to use r0, not silent misbehavior.

<comment><USER15> At least with GNU as you can use %r1, %r2 etc. as an "intrinsic part of the syntax". Which means you can't use a register name where an immediate is expected.

However that doesn't fix the gotcha with r0 being special, that is specified in the ISA. In fact it's that way precisely so you can load an immediate without needing a separate opcode.

<comment><USER14> Huh, never knew that... but I just tried it and GAS (the version Debian installed as powerpc-linux-gnu-as, at any rate) accepted "lwz %r0, %r5(%r0)". Snatching defeat from the jaws of victory...

It would still be a gotcha, but a pretty minor one if messing it up just resulted in an error. I suppose the approach taken by AArch64 and others is preferable, where one register is just completely reserved as constant 0 rather than only in some encodings.

</comment></comment></comment></comment></comment><comment><USER16> IMO the the success of CPU lines in recent years had almost nothing to do the intrinsic properties of the instructions set.

I don't blame MIPs from doing delayed branching etc because _if_ most machine code is compiled from something else, and _if_ most compilers use decent abstractions, one should be changing ISAs all the time to adapt and bolster the latest and greatest implementation techniques. (e.g. for out-of-order super scalar, its probably best to give the CPU some sort of dependency graph.)

The focus on hand-coding as a way to get to know the architecture, on the other hand, borderline insinuates that instructions sets should optimize for hand-coding, which is just plainly ridiculous.

<comment><USER9> On the other hand, no one wants to have to recompile everything all the time, which gives much force to the argument that CPUs should be more CISC, so that the same (complex) instructions will simply run faster due to hardware improvements. REP MOVS on x86 is a great example of this; it was originally the fastest way to do a block copy until around the Pentium when it lost (only slightly) to very large custom unrolled loops, but since ~P6 it has been internally optimised to copy whole cache lines at once and in the very latest microarchitectures it is once again the fastest.

<comment><USER16> Well, as a NixOS User (which granted way post-dates RISC), I get the all the benefits of constant recompilation without burning any of my own CPU cycles.

Very good point on the `REP MOVS` front (and cool story!). Indeed if the Mill pans out it would instantly usher the renaissance for branch delay.

So yeah, I rather recompile than try to predict future architecture trends, but either way, the grossness should be there for performance not hand-coding ease.

</comment></comment></comment><comment><USER17> A few comments:

Yes, MIPS assembly is terrible, though I hear that the newer ISA revisions are better (the one I worked with most heavily was the 5k, and systems programming on it was very unpleasant).

Power and MIPS also both now have thumb-2 alike instruction encodings, POWER VLE and MIPS16e, respectively. It turns out that code size matters.

Lastly, RISC no longer means what it used to. It basically is used today to just mean a load-store architecture, as you now have variable-length instructions, multi-cycle arithmetic instructions, out-of-order superscalar chips labled "RISC"

When IBM came out with the POWER ISA, I seem to recall that one of the authors of the abacus book claimed it wasn't simple enough to be RISC, which is a quaint thought these days.

<comment><USER6> It's sort of funny that ARM, which is really the CISCiest of the old RISC instruction sets, has ended up being the most successful one.

[http://userpages.umbc.edu/~vijay/mashey.on.risc.html](http://userpages.umbc.edu/~vijay/mashey.on.risc.html)

<comment><USER18> ARM, which is really the CISCiest of the old RISC instruction sets, you can replace 'is' by 'was' since ARMv8.

</comment></comment></comment><comment><USER19> _However, many of the later RISC architectures do share one annoying flaw. [...] the mechanism for storing 32-bit immediates can only encode a 32-bit value by splitting it across two instructions: a "load high" followed by an "add". [...] This design pattern turns up on almost all RISC architectures, though ARM does it differently (large immediates are accessed by PC-relative loads)._

He neglects to mention the ARM's clever approach to this:

[https://alisdair.mcdiarmid.org/arm-immediate-value- encoding/](https://alisdair.mcdiarmid.org/arm-immediate-value-encoding/)

<comment><USER20> The ARM approach is clever, but you only load 8 bits. Suppose you need a 32-bit constant - it's going to take 4 instructions. Compared to the halfword instructions, you do win with certain awkward constants such as 3<<15\. That's why neither approach is as good as having variable-length instructions ;)

This made me wonder how common such constants are. So I grabbed some code I've been working on recently, for which I happened to have assembly language output, and searched for every immediate constant. (This must be the first time I've found a good use for gcc's nasty AT&T x64 syntax.)

My code targets x64, so take the "analysis" with a pinch of salt. Out of the 8982 instructions that had immediate operands, there were 819 unique 32-bit constants. 762 (93%) were high-halfword or low-halfword only, so they could have been loaded with one halfword instruction. By comparison, only 392 (48%) could been loaded with one instruction on ARM.

Ten constants were better for ARM, in that they would take two halfword instructions to form, but only one MOV or MVN: ['0x00ffffff', '0x03ffffff', '0x0fffffff', '0x3fffffff', '0x7fffffe8', '0x7ffffffe', '0x7fffffff', '0x80000003', '0xfffffffe', '0xffffffff']. These ten constants were used by 84 instructions out of the 8982.

<comment><USER21> Modern ARM has load halfword insns too, so you can use those or the 8-bit imm encoding depending on the constant.

For a full 32 bit value prior to movw/movt you'd most likely load it from a constant pool rather than do a 4 insn sequence. (Some 32 bit values can be done with clever choice of 8imm sequences -- there's an algorithm you can use as a compiler to say "given this value can I create it in 3 or less insns?", which is worth the effort if you're targeting a pre-movw ARM cpu.)

</comment></comment></comment><comment><USER22> > x86 is not particularly nasty

x86's terrible reputation is well deserved. x86-64 fixes a number of problems, but for most of x86's lifetime we've had to live with 8 registers and the lack of IP-relative addressing...

Let's not forget how awful x87 floating point was, either!

<comment><USER23> I'm confused why would IP-relative addressing be useful. Have you got some interesting examples?

<comment><USER24> It's the basis of efficient relocations in position independent code, which is now very common.

PIC can be emitted on older x86 machines without RIP-relative addressing, but the code is larger and slower. As an example, consider -m32 gcc output for the C program

        int x;

        int getx() {
            return x;
        }

With no PIC:

        getx:
    	movl	x, %eax
    	ret

With PIC:

        getx:
    	call    __x86.get_pc_thunk.cx
    	addl    $_GLOBAL_OFFSET_TABLE_, %ecx
    	movl    x@GOT(%ecx), %eax
    	movl    (%eax), %eax
    	ret

And with -m64, which emits PIC and uses x86-64s RIP-relative addressing:

        getx:
     	movl	x(%rip), %eax
    	ret

Hopefully that makes the motivation clear.

<comment><USER23> Thanks, I've seen it so many times it seems I developed (%rip) blindness :) Of course it's useful this way.

</comment></comment></comment></comment><comment><USER25> > At this point, it's probably better to have an efficient instruction > encoding, save on memory bandwidth and instruction cache space, and have a > comprehensible instruction set. Hence x86.

x86 is full of legacy single-byte instructions and complicated prefixes, hurting space efficiency and making it a huge pain to have high-throughput decoding. You could do a lot better if you took the x86 instruction list and reassigned all the encodings.

</comment><comment><USER26> > However, many of the later RISC architectures do share one annoying flaw. > Immediate values are constants embedded within the instructions. Sometimes > these are used for small values within expressions, but often they're used > for addresses, which are 32-bit or 64-bit values. On PowerPC, as on SPARC > and MIPS, the mechanism for storing 32-bit immediates can only encode a > 32-bit value by splitting it across two instructions: a "load high" followed > by an "add". This is a pain. Sometimes the two instructions containing the > value are some distance apart. Often you have to decode the address by hand, > because the disassembler can't automatically recognise that it is an > address. This design pattern turns up on almost all RISC architectures, > though ARM does it differently (large immediates are accessed by PC-relative > loads). When I worked on an object code analyser for another sort of RISC > machine, I gave up on the idea of statically resolving the target of a call > instructions, because the target address was split across two instructions, > one of which could appear anywhere in the surrounding code.

> The x86 system for storing 32-bit/64-bit immediates is much nicer. They just > follow the instruction, which is possible because the instruction length is > variable. Variable-length instructions are not usually seen in RISC, the > Thumb-2 instruction set being the only exception that I know of.

Hybrid way, that could be the best of both worlds : [https://github.com/trillek-team/trillek- computer/blob/master...](https://github.com/trillek-team/trillek- computer/blob/master/cpu/TR3200.md#instructions-format)

On a few words, it uses a bit to know if the literal would be bigger that could normally stored on a instructions of 4 bytes. If it's true, the next 4 bytes is the literal value.

</comment><comment><USER10> Shouldn't gcc (or a similar helper tool) be able to understand the side effects of the asm instructions and automatically fill in all the clobber flags, instead of manually having to fill in all those crazy =r style markers? Is it not possible to code something that determines all affected registers for a given set of assembly opcodes?

<comment><USER13> It's certainly possible to do a lot better than GCC's inline assembly setup, which has proven time and again to be a usability disaster that positively encourages writing subtly buggy code.

Microsoft's C compilers do a much better job with inline asm by being more conservative in how they allocate registers around the asm ([https://msdn.microsoft.com/en- us/library/k1a8ss06.aspx](https://msdn.microsoft.com/en- us/library/k1a8ss06.aspx)).

CodeWarrior's PPC compilers remain the ne plus ultra of inline assembly ergonomics, and it's a goddamn shame that LLVM has chosen (for pragmatic reasons) to follow GCC's mediocre lead rather than pursue something akin to it.

<comment><USER27> Clang provides both GCC and MSVC style inline assembly.

<comment><USER13> Holy crap, I was not aware of that.

edit: this doesn't seem well-documented, if true. The Clang site mostly just talks about GCC compatibility, eg) [http://clang.llvm.org/compatibility.html#inline- asm](http://clang.llvm.org/compatibility.html#inline-asm)

</comment></comment></comment></comment><comment><USER28> Can anyone clarify his claim on MIPS data hazards? I didn't follow that one. To my knowledge MIPS has no special hazards, like a VLIW ISA would have. Is that not correct?

<comment><USER29> MIPS, the Microprocessor without Interlocked Pipeline Stages, doesn't make sure the result of one instruction is available before executing an instruction "later" in the stream that refers to that result. Something like (pseudo-asm with C-notation comments)

         ld r1, @r2   ; r1 = *r2
         add r3,r1,r4 ; r3 = r1+r4

wouldn't set r3=*r2+r4 because the memory access hasn't finished by the time the add runs.

<comment><USER17> And this got really fun when superscalar MIPS processors with instruction prefetching came out. They had to introduce a different NOP called SSNOP that stalled all ALUs. Obviously they couldn't just declare "NOP stalls all ALUs" as that would have serious performance affects for places where NOPs are necessary (e.g. branch delay slots).

<comment><USER30> I'm curious why they still had NOP as part of the name since it actually did something.

<comment><USER17> Well NOP does nothing on one ALU, SSNOP does nothing on all ALUs.

And to give you an example of how you had to calculate things:

There were, if my memory serves me correctly 6 pipeline stages on the 5k numbered 0-5, plus instruction prefetch which was numbered -1. You subtracted the stage in which the instruction took effect from the stage in which a subsequent instruction needed to see that effect, and the result was the number of intermediate stages that all ALUs would need to go through.

Worst case scenario would be if you were modifying RAM that would be read as an instruction; it wouldn't take effect until stage 5, and instruction prefetch was stage -1 so you needed to make sure all ALUs were busy for 6 clock cycles. In theory you could do the math to figure out the scheduling for each ALU, but I just dropped 6 SSNOPs in there, since it was a code path that was only hit during loading of a new process, 6 wasted clock cycles was not a concern.

Note that this is unrelated to interlocks, as any Modified Harvard Architecture will require some sort off synchronization when changing the instruction stream. However, most ISAs have a single instruction that stalls the pipeline and discards any prefetched instructions (e.g. isync on Power). They added one in later revisions of the MIPS ISA as well.

Another fun thing was that there was no interrupt-safe way to disable interrupts, as the interrupt-enabled bit was in a word-sized register along with other values that could legitimately be changed by an ISR. This was also fixed by later revisions of the ISA.

</comment></comment></comment></comment></comment><comment><USER31> "If you do have the misfortune to have to work with SPARC"

So true... I work with the LEON (GPL implementation of SPARC) and have the occasional very bad day of SPARC asm code.

</comment><comment><USER32> Sad that there was no mention / evaluation of RISC-V in this post, which attempts to resolve exactly the problems he identifies...

<comment><USER33> I don't think RISC-V really addresses the encoding inefficiency problem, except for the "C" extension, sorta. Though I don't think that for OoO superscalar architectures, icache pressure is as much of a problem as it is on a fancy vliw.

But yeah, would be nice to get a take on RISC-V in context of this rant.

<comment><USER34> Huh?

RISC-V with the compressed extension is incredibly efficient in its encoding. Better than x86 or ARM in both static and dynamic bytes per program.

Also, Icache pressure is a _huge_ problem in modern warehouse-scale computers.

Any processor that cares about performance will almost certainly be implementing the C extension to RISC-V. It also enables more efficient macro- op fusion, turning common two instruction 4-byte idioms into a single, more powerful instruction.

<comment><USER33> Thanks for going into more detail. I was basing my assumption that it wasn't a huge problem on the fact that the only people who complain about it _first_ seem to the folks designing the Mill. They have a ridiculous/insane/cool solution to it.

Everyone else seems to first mention their cool branch predictor, or vector processor.

</comment></comment></comment></comment><comment><USER35> I wonder what the author would think of the Mill.

</comment><comment><USER36> That's "codesign" as in "co-design" not "code-sign".</comment>


Amethyst – a tiling window manager for Mac OS X - <AUTHOR> https://github.com/ianyh/Amethyst <comment><USER2> I took a look at it and .. decided to pass. I know this is lame, but its too much fuss to set it up and learn to use it before I'll get any immediate benefit out of it. At first, I found the idea appealing - get some sensible window management occurring in OSX, where it seriously needs it. But then it just seemed like too much of a bolt-on to an OS that already feels pretty kludged up by things like duet and tunnelblick : things which should really be part of the OS, but are instead maintained by third parties.

As much as I feel Amethyst has a place, I think its also a real nuisance that such things are being ignored by Apple in their effort to refine their OS. Finder is still a piece of junk, 15 years after everyone started noticing just how much junk it is!

On the other hand - if Amethyst gets a feature that will make any opened Finder window auto-layout itself for optimal-fit of its content, I'll pay you a donation right away. Don't know what I mean - try this, open a Finder window, hit ⌘-2 (so you're in List view), and see what I mean - did the Finder window auto-size to accommodate the content? Do the columns in list view auto- size to fit just the column info needed? Nope. Make Amethyst handle this, like I said, and I'll make an instant donation - it has irked me for decades that this simple feature doesn't get any attention .. yet it would do a lot to forward the aesthetics of Finder in my case.

</comment><comment><USER3> I use this and I like it. Some "modern" apps don't seem to obey their tiles (Apple Mail.app and Spotify) but everything else plays nicely. I primarily use it to switch back in forth to my IDE taking up my whole monitor to my IDE taking up 3/4 with my browser taking up 1/4.

</comment><comment><USER4> I'm greatful for the effort but that mac ui does not make it look natural for a twm.</comment>


Volkswagen Admits to Testing Diesel Fumes on Monkeys - <AUTHOR> https://www.cnet.com/roadshow/news/volkswagen-admits-to-testing-diesel-fumes-on-monkeys-which-is-messed-up/#ftag=CAD590a51e <comment> castle-bravo In Canada right now there is a lot of buzz around cannabis startups. I think there's definitely a synergy there that could be exploited by the diesel industry: cannabis diesel additives that offset the harmful health effects of diesel fumes, automobiles that double as drug delivery vehicles, aromatherapy and so on.

</comment><comment> King-Aaron God damn.

I would have more to say, but that's actually quite shocking.

I think the journalist could have done without the low-brow comment about the type of cartoon being watched at the end there. I personally didn't see the humour as being particularly fitting here.

</comment><comment><USER2> The joke at the end of the article was really inappropriate. Shame on CNET.

</comment><comment><USER3> I would suggest folks to watch netflix tv series "Dirty Money".

</comment><comment><USER4> Talk about blowing smoke up a monkey's a..</comment>