Never happen. A previous poster alluded to parallel construction - what will happen is the suspect's calls will be listened to, then another agency will be given a time, location, and a car to look for. The suspect's car will get pulled over for failure to use a turn signal or some such, at which time a dog will be brought in, "alert" on the car, and the suspect will be arrested. These guys *know* that Stingray-gathered evidence won't hold up since the device itself can't be examined, and that operating them is contrary to FCC regulations to begin with. They can't allow any information gathered from them to be introduced into court, so parallel construction neatly solves all of their problems.

Yes, they are quite light. We have six-car trains with a capacity of 60 passengers per car, so the capacity is comparable, but they've got composite bodies over a steel subframe, which saves a lot of weight. They don't have to be really heavy since it's an elevated system with no chance of interaction with roadway traffic, and owing to their configuration, they deal with high winds quite well without needing the extra weight just to keep them on the track. Additionally, there are some grades on the system (around 9%) that would bring any traditional rail prime mover to a screeching halt, plus the trains have to be able to take those grades at speed (and sometimes accelerate) with only half the motors if needed. Top speed on our trains is electronically limited to 40mph, but to my knowledge they're physically capable of running well in excess of 60mph.

Don't we have machine learning and adaptive control for that? These things should still be easier for a computer than for a human.

I'm not disagreeing with you. I didn't design the train control system. :-) There was so much on our trains that the drivers really shouldn't have had to deal with, and I found it kind of ironic that the Orlando International Airport terminal shuttles had more smarts than our trains. As of 2012, Disney had concrete plans in place to finally put automation on the trains, which I personally think is going to be a losing proposition on a fleet of 25 year old monorails with 1970's-era control systems (the vehicle on-board controller is run by a pair of Z-80s) and millions of miles on them, and at their age are already *very* maintenance intensive. They get tons of PM, but nowadays it's unusual for a day to go by without at least one train having to go back to the shop, and not a week goes by where one doesn't get towed.

but often gets the calculation wrong because even though the system "knows" how much each car weighs, people sway back and forth as the vehicles slow down and we undershoot the platform.

That's good that it's conservative like that, but does it actually bring it to a complete stop short of the mark? There have been times when I've been driving a full train that it slowed a bit more aggressively than I would have expected, but it was easy to just modulate the brakes to hit the mark without stopping short. Then again, our trains were substantially lighter (about 50 tons empty, 80 tons crush load), so I'm sure it was easier for us to deal with the varying inertia.

I would hope that any company developing systems to automate control of any vehicles, most of all those tasked with mass transit automation, are fully aware of the need for redundant feedback systems which provide inegrated positioning and acceleration sensors built into every smart phone today.

Our trains had a pair of tachometers that measured speed, along with fixed transponders every thousand feet or so along the beamway. Between the tachs and the transponders, the train could figure out where it was and how fast it was going to quite a good degree of accuracy. When the tachs disagreed with one another or if a transponder was missed we'd get an indication, even though the train still knew exactly where it was. I'm sure integrating the tach inputs over time to get an acceleration value would be relatively trivial.

Disney's trains were retrofitted in the mid/late 00's with a similar system. There are three optical switches that all have to be aligned with corresponding places at the station, otherwise the driver is unable to open the doors. It was fairly easy to only get one or two of the sensors in place, requiring the driver to move the train a couple of inches forward or back to get his doors open. It's gotten to be a real headache for today's drivers, since the new rules Disney instituted after the accident in 2009 require that *any* reverse motion of the train be set up by the central coordinator and visually cleared by an independent spotter beforehand, even if it's only to back up an inch.

Hence, the acceleration and braking systems were optimized for automatic operation (as opposed to manual operation) and it is difficult for a human driver to control the train's movements precisely and smoothly.

I have a perspective on this that most probably don't, as I was a monorail driver at Disney World for a number of years. Contrary to what some might imagine, the current Bombardier Mark VI trains there are not attractions but are in fact full-up transit vehicles, and Bombardier continues to sell them as such (although with different bodies and newer electronics). If D.C.'s trains handle anything like ours did, I can understand why some of the drivers short-stop or otherwise have problems.

Our Mark VI trains were originally designed to accommodate automation as well, but I don't think this in itself really is a factor. More importantly, each train had its own "personality" and handled differently, and all of them would take between one and two seconds to respond after an input was commanded except for E-stops, which instantly opened the relay contactors and applied air to the friction brakes. One train might be ultra-responsive (relatively) to the throttle and have really tight brakes, which made it easy to drive and predict stopping distances with great accuracy. Others would act like your control inputs were more of a suggestion than a command, necessitating that you be looking a little ahead of where you actually wanted to be in order to stop where you were supposed to. We had some drivers that had difficulty dealing with that, and would often blow their stops by a couple of feet or so on a train with loose brakes, or would stop short if they were in a tighter train that didn't require so much anticipation of its behavior. I don't think I ever had a short stop, but did have trains "slide" on me a few times and missed the stop by just enough to have to back up a couple of inches to get lined up with the gates.

I would imagine transit trains everywhere exhibit similar unique peculiarities, and the only consistent way to deal with it is for the driver to be ultra-conservative, which can lead to the occasional short stop. It's not so much a problem for an automation system that can directly respond in milliseconds and isn't being moved between trains with wildly varying performance characteristics.

That's what they did when IE6 won the browser war!

Oracle has this problem, too.

I am sure that, if you have a talk about Linux security with Samsung/HTC/LG... you will hear some unprintable commentary on Linux security.

To a great extent, it's correct. While a lot of phones have been broken wide open, the same flaw can be used by a hostile app to own your phone (to say nothing of what could be done to a vulnerable enterprise system).

• - UNIX admins have been able to ply their trade for the last 40-odd years with a stable set of userland utilities, which systemd consigns to the trash heap.
• - systemd has removed the old userland (init, inetd) without providing good documentation and examples for doing the old things with the new tools (seriously, the top systemd-inetd example uses ssh, which nobody does - how about ftp or pop3?).

It seems that there are lots of new capabilities with systemd, but it has come to market with lousy documentation. The purveyors are receiving a thorough flogging at the hands of the greybeards, which they richly deserve.

We are in a War on Faith, because Faith justifies anything and ISIS takes it to extremes. But in the end they are just a bigger version of Christian-dominated school boards that mess with the teaching of Evolution, or Mormon sponsors of anti-gay-marriage measures, or my Hebrew school teacher, an adult who slapped me as a 12-year-old for some unremembered offense against his faith.

Hm. The covenant of Noah is about two paragraphs before this part (King James Version) which is used for various justifications of slavery and discrimination against all sorts of people because they are said to bear the Curse of Ham. If folks wanted to use the Bible to justify anything ISIS says is justified by God's words in the Koran, they could easily do so.

18 And the sons of Noah, that went forth of the ark, were Shem, and Ham, and Japheth: and Ham is the father of Canaan.
19 These are the three sons of Noah: and of them was the whole earth overspread.
20 And Noah began to be an husbandman, and he planted a vineyard:
21 And he drank of the wine, and was drunken; and he was uncovered within his tent.
22 And Ham, the father of Canaan, saw the nakedness of his father, and told his two brethren without.
23 And Shem and Japheth took a garment, and laid it upon both their shoulders, and went backward, and covered the nakedness of their father; and their faces were backward, and they saw not their father's nakedness.
24 And Noah awoke from his wine, and knew what his younger son had done unto him.
25 And he said, Cursed be Canaan; a servant of servants shall he be unto his brethren.
26 And he said, Blessed be the Lord God of Shem; and Canaan shall be his servant.
27 God shall enlarge Japheth, and he shall dwell in the tents of Shem; and Canaan shall be his servant.

Untrue. I've had the X server hang up and I've logged in via the network and killed it and restarted it. I can't restart systemd without restarting the whole system. Furthermore, I don't run the X server on our mission critical machines.

I understand what you're saying (I think) but I've always wondered (and this is from a hardware-guy's perspective) wouldn't you rather have one big monitor [flickr.com], than two small monitors [wired.com]?

I actually prefer multiple displays along with virtual desktops, as the bezel doesn't bother me, and it's easier for me to have a dev environment on one screen with documentation/tools on the other sans taskbar, with the virtual desktops being used for stuff like IMs, email, etc.. Maximizing something on the second display fills that display, but leaves the primary untouched. Additionally, there are some folks that prefer to use multiple displays in different orientations, although I'm not one of those. Finally, it's cheaper. :-) Having said that, it's not something I'm dogmatic about. People should use whatever works best for them.