Consumer devices are fine. It's consumer-grade services that are the problem. If corporate users have devices that are slaves to a consumer-grade service like Apple's or Google's, they can be attacked or disabled through that service. Typically, there's no contractual recourse available.
Microsoft is more careful about this. They offer corporate control over Windows Update. If your corporate apps stop working because Apple pushed an iPhone update, you have no recourse.
The problem with C isn't strings. It's arrays. Strings are just a special case of arrays.
Understand that when C came out, it barely had types. "structs" were not typed; field names were just offsets. All fields in all structs, program-wide, had to have unique names. There was no "typedef". There was no parameter type checking on function calls. There were no function pointers. All parameters were passed as "int" or "float", including pointers and chars. Strong typing and function prototypes came years later, with ANSI C.
This was rather lame, even for the late 1970s. Pascal was much more advanced at the time. Pascal powered much of the personal computer revolution, including the Macintosh. But you couldn't write an OS in Pascal at the time; it made too many assumptions about object formats. In particular, arrays had descriptors which contained length information, and this was incompatible with assembly-language code with other conventions. By design, C has no data layout conventions built into the language.
Why was C so lame? Because it had to run on PDP-11 machines, which were weaker than PCs. On a PC, at least you had 640Kb. On a PDP-11, you had 64Kb of data space and (on the later PDP-11 models) 64Kb of code space, for each program. The C compiler had to be crammed into that. That's why the original C is so dumb.
The price of this was a language with a built in lie - arrays are described as pointers. The language has no idea how big an array is, and there's not even a way to usefully talk about array size in C. This is the fundamental cause of buffer overflows. Millions of programs crash every day because of that problem.
That's how we got into this mess.
As I point out occasionally, the right answer would have been array syntax like
int read(int fd, char[n]& buf, size_t n);
That says buf is an array of length n, passed by reference. There's no array descriptor and no extra overhead, but the language now says what's actually going on. The classic syntax,
int read(int fd, char* buf, size_t n);
is a lie - you're not passing a pointer by value, you're passing an array by reference.
C++ tries to wallpaper over the problem by hiding it under a layer of templates, but the mold always seeps through the wallpaper when a C pointer is needed to call some API.
The people I read whining about this aren't the ones coming up with original ideas. They seem to be people who want to clone someone else's successful idea. Or are just whining.
Look who's getting hit with patent problems - Spotify, which is yet another streaming music service. Hulu, which is yet another streaming video service. Rovio, whose Angry Birds is a clone of an old "attack the castle" game. These are not innovative companies.
Even Linux isn't very original. It's basically a UNIX clone. It's not an original OS, like PenPoint or QNX or BeOS. OpenOffice is as much like Microsoft Office as it can be made to be. Apache started as a clone of the NCSA web server.
Come up with something new, and you have far fewer patent problems. I have four issued software patents myself, all in areas where the existing technology didn't work but mine did.
IP supports a large number of protocols other than TCP, UDP, and ICMP. But how many ISPs still pass them? Can you still send Xerox Network System (XNS) packets (protocol 22)? AX-25 frames (protocol 93)? QNX messaging (protocol 106)? Fibre Channel (protocol 133)? Can you change the version number on TCP (which is what the people doing the original paper should be doing when they change the protocol)?
All of these are IP, so the Internet should pass them. I've tried QNX packets, and they at least went through Linksys boxes without being lost or modified.
The government of Saudi Arabia acquired a 100% interest in Saudi Aramco in 1980. That's when the US Big Oil firms ceased to control production. Since 1993, Saudi Aramco has controlled its own refining and marketing.
The author of the original article is way out of touch.
Browsers have now reached the maturity of 1950s American cars. They more or less work, still break too much, use too much fuel, and have lots of chrome and tailfins.
Out here in Silicon Valley, most of us have been to Maker Faire, which has been around for years, and many of us have shown there. It's now full of people selling flea-market level craft junk. I don't go any more.
They've re-invented an older model Checkpoint anti-theft tag, the square "sticker" model 410 with an antenna printed in conductive ink and an IC at the center. The Checkpoint tag IC is rather dumb, but then the whole tag costs about $0.05.
Progress with programmable logic controllers has made them much more vulnerable. They used to be really dumb devices, often programmed by physically plugging in an EPROM. Their communications protocol tended to be some ancient multi-drop serial protocol like RS-485, or a vendor-specific proprietary network. The "host machine" tended to be some CPU on a card, connected to a dumb terminal or a control panel. This was dumb and static, but being totally isolated, secure from external intrusion.
Now, PLCs tend to be reprogrammable over their communications link. Some support Ethernet directly. The proprietary networks were all overpriced, and although Ethernet is overkill for most low-level controllers, the interface parts are cheaper, the cables are cheaper, the connectors are cheaper, and more interface devices are available. Also, 10baseT, which has differential signalling and error control, has better noise immunity than some of the lower-speed proprietary networks.
I've used devices that have a built in web server just for configuration purposes. With no security.
Even if the low-level network is nonstandard, there's a tendency today to put in a gateway to an Ethernet. This allows connection to, inevitably, a PC running Windows, usually with some custom DLL from the controls vendor. (See page 9 of this Siemens brochure.)
This often allows reprogramming the low level controllers from a PC. This is exactly the configuration that was used in the Iranian centrifuge facility.
Of course, once you have something that's IP over Ethernet with Windows machines on it, it tends to become accessible from the outside world. This is a recognized problem. Here's a Siemens paper on it. They talk about "firewalls" a lot, but don't go into much detail over what they really do. Note that they mention an engineering terminal use for system programming (a PC), physically outside the firewall, coming in through an encrypted VPN. That's a classic point of attack.
The trouble is that it's too convenient to have connections to external systems. The PLC system for lock control in a prison wouldn't seem to have to be connected to other systems. But there's going to be an inmate inventory system that tracks who is supposed to be in which cell. It's convenient if the interface to the locking system shows who is supposed to be where, and has important info like which prisoners are violent, which need extra medical attention, and such. Then you can have screens which show both door status and prisoner info.
But others need to talk to the prisoner inventory system.
The system for food ordering needs info about how many inmates are in which parts of the prison and maybe their dietary needs. And the system for food ordering needs to talk to external suppliers to place orders. That means a link to outside the prison. This is the sort of thing which leads to a data path from non-critical to critical systems.
... about where hybrids with power storage have gone, if anywhere?
General Electric is coming out with a diesel-electric with battery storage to recover some of the energy used in braking. Dynamic braking on diesel-electrics normally dumps the energy into (huge) resistors, and that can be put into batteries, if you want to carry all those batteries around. Whether this is a win depends on the way the loco is used. It's probably a win for switch engines,which stop and start frequently, and a lose for road locos on long runs, which don't.
Almost all high speed trains are pure electrics, drawing their power from centenaries. Newer ones put braking power back into the power line if possible. This involves a frequency conversion and some very large semiconductors.
According to the Logitech web site, the thing needs both an Ethernet connection to the outside world, and "Cable or Satellite set top box with HDMI out". What does it need a video input for? Over the air digital TV plus streaming over the Internet for anything else should suffice. None of the other video-over-the-Internet boxes seem to need that.
As I pointed out when this first happened,
Hollysys claims to have designed and built the signalling system. They issued a denial that the system failed.
Now we have a unit of "China Railway Signal & Communication Co" taking responsibility. They're affiliated with what used to be General Railway Signal in the US, which is now part of Alstom. It's not clear who built what here. "China Railway Signal & Communication Co" may be the installation contractor.
A little of what happened is clear. There are two separate systems involved. One is classic railroad signaling, with track circuits, wayside equipment, and cab signals. The classical designs are simple and robust. That's the safety-related system. The other is the train control system which uses a unit at the head and tail of each train, communicating to a central headquarters. Those systems are elaborate and computerized, but not considered life-safety systems.
Either system is normally sufficient to prevent collisions.
In normal operation, the train control system does most of the work. It knows about train identity, schedules, and speeds. If the train control system is working right, the safety-related system never intervenes.
In a power failure, though, the train control system can lose contact with a train, since it uses active equipment on each train. That probably happened here. With a total power loss, the dead train isn't reporting to central control.
The safety system, on the other hand, detects trains because the wheels connect the rails together, normally has battery backup, is supposed to be very robust, and is intended to fail to STOP. Even after lightning strikes and a total power failure, it should still work. (Such systems have been taking lightning hits for a century without problems. Lightning hits railroad tracks and pole lines frequently; in flat country, they're the lowest resistance path to ground.)
But the safety system is high-maintenance. There are bits of it all along the lines; track circuits, wayside equipment, signal enclosures, and various other little and big boxes, all of which need attention. Keeping railroad signalling working right requires a large staff of dedicated, well-supervised signal maintainers. Since the systems are designed to fail to STOP, maintenance failures tend to result in red signals.
If the train control system shows the line as clear, and the safety system shows STOP, this normally triggers an emergency brake application. For a high speed train, that takes several kilometers and can cause wheel flattening. (Train wheels have steel "tires", which have to be replaced periodically. An emergency stop takes a lot of life off a tire.)
The question here is what happened to the safety system. Was there over-reliance on the train control system? Was the safety system bypassed to avoid unwanted emergency stops. That's speculation at this point.
Few sources, even Blu-Ray, consistently deliver 1080p now. Get close enough to a display to see the pixels, and notice the compression blur that stabilizes once motion stops.
The next logical step is a higher frame rate. 24FPS for movies is way too slow. Cameron ("Titanic", "Avatar", etc.) has been bitching about this for years. He likes pans over highly detailed backgrounds, which produce strobing effects at 24FPS. Movies should be at least 48FPS, and maybe 72FPS. (The Showscan tests indicate that viewers notice improved quality up to about 72FPS, but not above that, so that's the limit of human perception.)
Personally, I'd like to see framefree compression. This is a concept out of Kerner Optical (a Lucasfilm spinoff). Instead of merely switching from one frame to the next, the player computes a morph between frames. This allows running at any display rate, allows arbitrarily slow motion, allows much higher compression ratios than MPEG-4, and requires substantial computation in the decoder. They never did much with the technology, though; it was sold to Monolith in Japan, which hasn't done much with it. It's worth looking at again, now that putting a GPU in a TV isn't a radical concept.
Google+ isn't the problem. Google's use of "crowdsourcing" in search results is the problem.
Google values links, reviews, and now "likes". All can be, and are, be spammed using anonymous accounts on social networks and blogs. This is why there are so many spam posts on blogs, phony reviews, and phony accounts on social networks. Those aren't there for humans - they're there to feed Google's ranking system.
This was a nagging problem for years, but didn't get much attention outside the "search engine optimization" community.
It went over the top in Q4 2010, when Google Places was merged into Google web search, and the payoff for social spam increased. Now there are articles in the New York Times about it. 40% of the jobs on Amazon's Mechanical Turk are for spamming.
Now the trend is toward requiring a login from some non-anonymous social network to post on blogs and forums. That reduces spam targeted at Google. None of this has anything to do with human readers.
For several decades, amplifier advertising had to use a power rating defined by FTC rules. The power rating was RMS power, per channel, continuous sine wave input, and maintained for half an hour without overheating. No "peak power" or "music power" ratings.
The industry hated this, because they had to put in power supplies sized for the worst case. But they complied, and amplifiers from that era have solid power supplies.
Post-deregulation, power supplies became undersized again.
In the last 15 years or so, CGI became good enough to do just about anything the writers can imagine. There was a backlog of stuff to do - not just SF and comics,but historical epics, like Rome in "Gladiator". At last, the viewer could walk through a large alien city or a an alien planet. Scale was no longer a problem. Nonhuman characters could interact with human ones. (This gave us Jar Jar Binks, but we'll pass over that.) Magic worked just fine.
All those things have now been done, and well. "Avatar" nailed "alien planet". "Harry Potter" nailed "magic". "Titanic" nailed "big disaster". "Lord of the Rings" nailed "fantasy epic war". "Batman" nailed "comic book hero". The backlog has been worked down. Audiances can no longer be impressed by doing any of those things.
It wasn't cheap. Movies once boasted "a cast of thousands". Now, major films do have a cast of thousands - of artists and animators. "Captain America"'s credits have about 850 people on the effects side alone. Anything can be put on screen, but it costs about $100 million.
That's the problem. The technology didn't make movies cheaper to make. Even if the whole thing is done in front of a green screen, it doesn't save much money. ("Sky Captain" was supposed to cost $20 million, but ended up costing $80 million.) We're not seeing good $20 million movies with high production values. Those economics lock Hollywood into what are considered sure wins.
Automation helps, but tweaking it adds the cost back in. SpeedTree, the program that automatically generates realistic trees, each different, in quantity for video games, has a version for films. Cameron used it on one of his films, and demanded manual tweaks, wanting branches moved so as to obscure or not obscure the action. (This sort of thing, by the way, is why dealing with Hollywood is a pain. Either they're in development and have trouble coming up with a valid credit card number, or they're in production and want a new feature yesterday.)
Notwithstanding, the claims set forth in the Class Action Complaints filed against
SCEA and the other Sony Defendants, as well as the miscellaneous claims, arising out of the
cyber attacks on the PSN and SOE Network and the unauthorized access to and theft of the
named plaintiffs and putative class members' personal identification and financial information,
do not assert claims for "bodily injury," "property damage" or "personal and advertising injury"
so as to entitle SCEA to defense and/or indemnity under the ZAIC Primary Policy.
In other words, Sony didn't buy coverage against a liability of this type. They were covered if the product actually injured someone or damaged their property (shocked someone or caught on fire, for example) but not for an indirect financial loss.
What they needed was an "errors and omissions policy". This covers financial screwups. Banks, accountants, tax advisors, and brokers usually carry such policies, because they handle other people's money. What Sony's people didn't realize is that, by handling so many credit card numbers (and, apparently, improperly holding more credit card info than they should have), they had the exposure of a financial institution.
Any merchant who holds onto credit card info for recurring transactions needs that coverage. Merchants who just pass credit card data to the bank for a single transaction, but don't keep it on file, are less at risk.
The people who produce false reviews will develop a tool that not only fakes the reviews, but then applies this exact software (in the article) to analyze it, and then provides logical adjustments until this exact software cannot discern the difference between the adjusted outcome or real reviews.
That's a very real problem. A few years ago, phishing sites could be distinguished from real sites by observing bad grammar, poor layout, and other indicators of low quality. Today, phishing sites look very much like real ones to humans.
For a few years, until 2008, there was the Web Spam Challenge. A large number of web pages had been classified by humans as "spam" or "not spam", and people ran classifiers against them to try to match the human judgement. That used to have some effectiveness, but the quality of junk web sites has improved, now that big companies like AOL and Demand Media generate them.
A superficial examination by humans isn't good enough any more. You need to dig deeper. For web spam, look at the business behind the web site. For recommendation spam, look at the person behind the recommendation. Social networks have enough information to do this for individuals. eBay and Amazon, which actually see the customer's transactions, can and do use that information.
Upverter has some of the right ideas, but not enough user base for their concept of a "crowdsourced parts library" to be useful. They're still way ahead of CircuitBee.
With the better electrical CAD packages, you get a good parts library, including the PC board layout and maybe a SPICE model for the part. The major commercial library has 2 million parts in it.
There are open source parts libraries, but the contents tends to be somewhat random, since it's just what people happened to upload.
Parts libraries also need to be consistent. You want all the pads designed with uniform design rules, or you have problems in board fab. So a Q/A operation and standards are needed. (Open Circuits says "Please also note that we guarantee that there are some messed up footprints in this library.")
Digi-Key manages to collect the data sheets for almost everything they sell. Maybe someone will do that for PC board footprints and simulation models and make them freely available. It probably won't be CircuitBee, but some vendor of parts or boards.
Bing's market share isn't all that bad, for only two years into the market. Microsoft has lost money entering a market before; the original XBox was a money drain from start to finish. A decade later, Sega is out of consoles, Sony is in trouble, and Microsoft is finally #1 in console sales, having passed Nintendo this year. Microsoft is finally profitable in games, although it's not clear if they've made up all the early losses yet.
Microsoft's online services division is losing about US$2bn a year, but that group includes more than Bing. Microsoft has a whole range of online services, many part of "Windows Live", mimicking many of the services Google gives away to annoy Microsoft. The search engine itself probably generates enough ad revenue to support itself.
Microsoft went at online from the opposite direction as Google. They did the money-losers, like free email, first, then the search engine with ads, which makes all the money. Microsoft, like Google, has recently been dumping some of the less successful freebie products. That can't hurt.
Bing has a brain drain. They've been losing key technical people and execs to Facebook, eBay, and even AOL. I'm not even sure who's running Bing right now. (Does anybody know who the top 3 people are at Bing right now? Let me know.) They're hiring, if you want to work in search.
Bing could potentially do a better job at search than Google. Google gets 30% of their ad revenue from AdSense sites, and has been hesitant to bring the hammer down on made-for Adsense junk sites. Bing could do better just by penalizing sites with ads, content farms, and related junk, like Blekko does. Google is vulnerable there.
Slashdot Mirror
Consumer devices are fine. It's consumer-grade services that are the problem. If corporate users have devices that are slaves to a consumer-grade service like Apple's or Google's, they can be attacked or disabled through that service. Typically, there's no contractual recourse available.
Microsoft is more careful about this. They offer corporate control over Windows Update. If your corporate apps stop working because Apple pushed an iPhone update, you have no recourse.
The problem with C isn't strings. It's arrays. Strings are just a special case of arrays.
Understand that when C came out, it barely had types. "structs" were not typed; field names were just offsets. All fields in all structs, program-wide, had to have unique names. There was no "typedef". There was no parameter type checking on function calls. There were no function pointers. All parameters were passed as "int" or "float", including pointers and chars. Strong typing and function prototypes came years later, with ANSI C.
This was rather lame, even for the late 1970s. Pascal was much more advanced at the time. Pascal powered much of the personal computer revolution, including the Macintosh. But you couldn't write an OS in Pascal at the time; it made too many assumptions about object formats. In particular, arrays had descriptors which contained length information, and this was incompatible with assembly-language code with other conventions. By design, C has no data layout conventions built into the language.
Why was C so lame? Because it had to run on PDP-11 machines, which were weaker than PCs. On a PC, at least you had 640Kb. On a PDP-11, you had 64Kb of data space and (on the later PDP-11 models) 64Kb of code space, for each program. The C compiler had to be crammed into that. That's why the original C is so dumb.
The price of this was a language with a built in lie - arrays are described as pointers. The language has no idea how big an array is, and there's not even a way to usefully talk about array size in C. This is the fundamental cause of buffer overflows. Millions of programs crash every day because of that problem.
That's how we got into this mess.
As I point out occasionally, the right answer would have been array syntax like
int read(int fd, char[n]& buf, size_t n);
That says buf is an array of length n, passed by reference. There's no array descriptor and no extra overhead, but the language now says what's actually going on. The classic syntax,
int read(int fd, char* buf, size_t n);
is a lie - you're not passing a pointer by value, you're passing an array by reference.
C++ tries to wallpaper over the problem by hiding it under a layer of templates, but the mold always seeps through the wallpaper when a C pointer is needed to call some API.
The people I read whining about this aren't the ones coming up with original ideas. They seem to be people who want to clone someone else's successful idea. Or are just whining.
Look who's getting hit with patent problems - Spotify, which is yet another streaming music service. Hulu, which is yet another streaming video service. Rovio, whose Angry Birds is a clone of an old "attack the castle" game. These are not innovative companies.
Even Linux isn't very original. It's basically a UNIX clone. It's not an original OS, like PenPoint or QNX or BeOS. OpenOffice is as much like Microsoft Office as it can be made to be. Apache started as a clone of the NCSA web server.
Come up with something new, and you have far fewer patent problems. I have four issued software patents myself, all in areas where the existing technology didn't work but mine did.
IP supports a large number of protocols other than TCP, UDP, and ICMP. But how many ISPs still pass them? Can you still send Xerox Network System (XNS) packets (protocol 22)? AX-25 frames (protocol 93)? QNX messaging (protocol 106)? Fibre Channel (protocol 133)? Can you change the version number on TCP (which is what the people doing the original paper should be doing when they change the protocol)?
All of these are IP, so the Internet should pass them. I've tried QNX packets, and they at least went through Linksys boxes without being lost or modified.
The government of Saudi Arabia acquired a 100% interest in Saudi Aramco in 1980. That's when the US Big Oil firms ceased to control production. Since 1993, Saudi Aramco has controlled its own refining and marketing.
The author of the original article is way out of touch.
Browsers have now reached the maturity of 1950s American cars. They more or less work, still break too much, use too much fuel, and have lots of chrome and tailfins.
This seems to be a feud between some cult and someone who doesn't like the cult. For once, it's not Scientology. It's some offshoot of Buddhism.
One side of the argument can be seen here. An old article about William Cassidy may provide some background.
As far as I can tell from a superficial reading, both sites are nutcases.
How did some clown's vacation blog get in?
Out here in Silicon Valley, most of us have been to Maker Faire, which has been around for years, and many of us have shown there. It's now full of people selling flea-market level craft junk. I don't go any more.
They've re-invented an older model Checkpoint anti-theft tag, the square "sticker" model 410 with an antenna printed in conductive ink and an IC at the center. The Checkpoint tag IC is rather dumb, but then the whole tag costs about $0.05.
Progress with programmable logic controllers has made them much more vulnerable. They used to be really dumb devices, often programmed by physically plugging in an EPROM. Their communications protocol tended to be some ancient multi-drop serial protocol like RS-485, or a vendor-specific proprietary network. The "host machine" tended to be some CPU on a card, connected to a dumb terminal or a control panel. This was dumb and static, but being totally isolated, secure from external intrusion.
Now, PLCs tend to be reprogrammable over their communications link. Some support Ethernet directly. The proprietary networks were all overpriced, and although Ethernet is overkill for most low-level controllers, the interface parts are cheaper, the cables are cheaper, the connectors are cheaper, and more interface devices are available. Also, 10baseT, which has differential signalling and error control, has better noise immunity than some of the lower-speed proprietary networks. I've used devices that have a built in web server just for configuration purposes. With no security.
Even if the low-level network is nonstandard, there's a tendency today to put in a gateway to an Ethernet. This allows connection to, inevitably, a PC running Windows, usually with some custom DLL from the controls vendor. (See page 9 of this Siemens brochure.) This often allows reprogramming the low level controllers from a PC. This is exactly the configuration that was used in the Iranian centrifuge facility.
Of course, once you have something that's IP over Ethernet with Windows machines on it, it tends to become accessible from the outside world. This is a recognized problem. Here's a Siemens paper on it. They talk about "firewalls" a lot, but don't go into much detail over what they really do. Note that they mention an engineering terminal use for system programming (a PC), physically outside the firewall, coming in through an encrypted VPN. That's a classic point of attack.
The trouble is that it's too convenient to have connections to external systems. The PLC system for lock control in a prison wouldn't seem to have to be connected to other systems. But there's going to be an inmate inventory system that tracks who is supposed to be in which cell. It's convenient if the interface to the locking system shows who is supposed to be where, and has important info like which prisoners are violent, which need extra medical attention, and such. Then you can have screens which show both door status and prisoner info.
But others need to talk to the prisoner inventory system. The system for food ordering needs info about how many inmates are in which parts of the prison and maybe their dietary needs. And the system for food ordering needs to talk to external suppliers to place orders. That means a link to outside the prison. This is the sort of thing which leads to a data path from non-critical to critical systems.
... about where hybrids with power storage have gone, if anywhere?
General Electric is coming out with a diesel-electric with battery storage to recover some of the energy used in braking. Dynamic braking on diesel-electrics normally dumps the energy into (huge) resistors, and that can be put into batteries, if you want to carry all those batteries around. Whether this is a win depends on the way the loco is used. It's probably a win for switch engines,which stop and start frequently, and a lose for road locos on long runs, which don't.
Almost all high speed trains are pure electrics, drawing their power from centenaries. Newer ones put braking power back into the power line if possible. This involves a frequency conversion and some very large semiconductors.
Foxconn HQ is in Taiwan, but most of the employees are on the mainland. Are they planning to move more production back to Taiwan?
According to the Logitech web site, the thing needs both an Ethernet connection to the outside world, and "Cable or Satellite set top box with HDMI out". What does it need a video input for? Over the air digital TV plus streaming over the Internet for anything else should suffice. None of the other video-over-the-Internet boxes seem to need that.
As I pointed out when this first happened, Hollysys claims to have designed and built the signalling system. They issued a denial that the system failed. Now we have a unit of "China Railway Signal & Communication Co" taking responsibility. They're affiliated with what used to be General Railway Signal in the US, which is now part of Alstom. It's not clear who built what here. "China Railway Signal & Communication Co" may be the installation contractor.
A little of what happened is clear. There are two separate systems involved. One is classic railroad signaling, with track circuits, wayside equipment, and cab signals. The classical designs are simple and robust. That's the safety-related system. The other is the train control system which uses a unit at the head and tail of each train, communicating to a central headquarters. Those systems are elaborate and computerized, but not considered life-safety systems. Either system is normally sufficient to prevent collisions.
In normal operation, the train control system does most of the work. It knows about train identity, schedules, and speeds. If the train control system is working right, the safety-related system never intervenes.
In a power failure, though, the train control system can lose contact with a train, since it uses active equipment on each train. That probably happened here. With a total power loss, the dead train isn't reporting to central control.
The safety system, on the other hand, detects trains because the wheels connect the rails together, normally has battery backup, is supposed to be very robust, and is intended to fail to STOP. Even after lightning strikes and a total power failure, it should still work. (Such systems have been taking lightning hits for a century without problems. Lightning hits railroad tracks and pole lines frequently; in flat country, they're the lowest resistance path to ground.)
But the safety system is high-maintenance. There are bits of it all along the lines; track circuits, wayside equipment, signal enclosures, and various other little and big boxes, all of which need attention. Keeping railroad signalling working right requires a large staff of dedicated, well-supervised signal maintainers. Since the systems are designed to fail to STOP, maintenance failures tend to result in red signals.
If the train control system shows the line as clear, and the safety system shows STOP, this normally triggers an emergency brake application. For a high speed train, that takes several kilometers and can cause wheel flattening. (Train wheels have steel "tires", which have to be replaced periodically. An emergency stop takes a lot of life off a tire.)
The question here is what happened to the safety system. Was there over-reliance on the train control system? Was the safety system bypassed to avoid unwanted emergency stops. That's speculation at this point.
Few sources, even Blu-Ray, consistently deliver 1080p now. Get close enough to a display to see the pixels, and notice the compression blur that stabilizes once motion stops.
The next logical step is a higher frame rate. 24FPS for movies is way too slow. Cameron ("Titanic", "Avatar", etc.) has been bitching about this for years. He likes pans over highly detailed backgrounds, which produce strobing effects at 24FPS. Movies should be at least 48FPS, and maybe 72FPS. (The Showscan tests indicate that viewers notice improved quality up to about 72FPS, but not above that, so that's the limit of human perception.)
Personally, I'd like to see framefree compression. This is a concept out of Kerner Optical (a Lucasfilm spinoff). Instead of merely switching from one frame to the next, the player computes a morph between frames. This allows running at any display rate, allows arbitrarily slow motion, allows much higher compression ratios than MPEG-4, and requires substantial computation in the decoder. They never did much with the technology, though; it was sold to Monolith in Japan, which hasn't done much with it. It's worth looking at again, now that putting a GPU in a TV isn't a radical concept.
Google+ isn't the problem. Google's use of "crowdsourcing" in search results is the problem.
Google values links, reviews, and now "likes". All can be, and are, be spammed using anonymous accounts on social networks and blogs. This is why there are so many spam posts on blogs, phony reviews, and phony accounts on social networks. Those aren't there for humans - they're there to feed Google's ranking system.
This was a nagging problem for years, but didn't get much attention outside the "search engine optimization" community. It went over the top in Q4 2010, when Google Places was merged into Google web search, and the payoff for social spam increased. Now there are articles in the New York Times about it. 40% of the jobs on Amazon's Mechanical Turk are for spamming.
Now the trend is toward requiring a login from some non-anonymous social network to post on blogs and forums. That reduces spam targeted at Google. None of this has anything to do with human readers.
Doesn't the build process need the grammar sources? Or is it that nobody actually builds EMACS from source any more?
program could correctly identify gender 65.9% of the time.
Vs. 50% for random?
FTC amplifier power rule history .
For several decades, amplifier advertising had to use a power rating defined by FTC rules. The power rating was RMS power, per channel, continuous sine wave input, and maintained for half an hour without overheating. No "peak power" or "music power" ratings. The industry hated this, because they had to put in power supplies sized for the worst case. But they complied, and amplifiers from that era have solid power supplies.
Post-deregulation, power supplies became undersized again.
In the last 15 years or so, CGI became good enough to do just about anything the writers can imagine. There was a backlog of stuff to do - not just SF and comics,but historical epics, like Rome in "Gladiator". At last, the viewer could walk through a large alien city or a an alien planet. Scale was no longer a problem. Nonhuman characters could interact with human ones. (This gave us Jar Jar Binks, but we'll pass over that.) Magic worked just fine.
All those things have now been done, and well. "Avatar" nailed "alien planet". "Harry Potter" nailed "magic". "Titanic" nailed "big disaster". "Lord of the Rings" nailed "fantasy epic war". "Batman" nailed "comic book hero". The backlog has been worked down. Audiances can no longer be impressed by doing any of those things.
It wasn't cheap. Movies once boasted "a cast of thousands". Now, major films do have a cast of thousands - of artists and animators. "Captain America"'s credits have about 850 people on the effects side alone. Anything can be put on screen, but it costs about $100 million.
That's the problem. The technology didn't make movies cheaper to make. Even if the whole thing is done in front of a green screen, it doesn't save much money. ("Sky Captain" was supposed to cost $20 million, but ended up costing $80 million.) We're not seeing good $20 million movies with high production values. Those economics lock Hollywood into what are considered sure wins.
Automation helps, but tweaking it adds the cost back in. SpeedTree, the program that automatically generates realistic trees, each different, in quantity for video games, has a version for films. Cameron used it on one of his films, and demanded manual tweaks, wanting branches moved so as to obscure or not obscure the action. (This sort of thing, by the way, is why dealing with Hollywood is a pain. Either they're in development and have trouble coming up with a valid credit card number, or they're in production and want a new feature yesterday.)
Ads, overlaid on the real world. Inevitable with this technology.
The actual court filing by the insurance companies says:
Notwithstanding, the claims set forth in the Class Action Complaints filed against SCEA and the other Sony Defendants, as well as the miscellaneous claims, arising out of the cyber attacks on the PSN and SOE Network and the unauthorized access to and theft of the named plaintiffs and putative class members' personal identification and financial information, do not assert claims for "bodily injury," "property damage" or "personal and advertising injury" so as to entitle SCEA to defense and/or indemnity under the ZAIC Primary Policy.
In other words, Sony didn't buy coverage against a liability of this type. They were covered if the product actually injured someone or damaged their property (shocked someone or caught on fire, for example) but not for an indirect financial loss.
What they needed was an "errors and omissions policy". This covers financial screwups. Banks, accountants, tax advisors, and brokers usually carry such policies, because they handle other people's money. What Sony's people didn't realize is that, by handling so many credit card numbers (and, apparently, improperly holding more credit card info than they should have), they had the exposure of a financial institution.
Any merchant who holds onto credit card info for recurring transactions needs that coverage. Merchants who just pass credit card data to the bank for a single transaction, but don't keep it on file, are less at risk.
The people who produce false reviews will develop a tool that not only fakes the reviews, but then applies this exact software (in the article) to analyze it, and then provides logical adjustments until this exact software cannot discern the difference between the adjusted outcome or real reviews.
That's a very real problem. A few years ago, phishing sites could be distinguished from real sites by observing bad grammar, poor layout, and other indicators of low quality. Today, phishing sites look very much like real ones to humans.
For a few years, until 2008, there was the Web Spam Challenge. A large number of web pages had been classified by humans as "spam" or "not spam", and people ran classifiers against them to try to match the human judgement. That used to have some effectiveness, but the quality of junk web sites has improved, now that big companies like AOL and Demand Media generate them.
A superficial examination by humans isn't good enough any more. You need to dig deeper. For web spam, look at the business behind the web site. For recommendation spam, look at the person behind the recommendation. Social networks have enough information to do this for individuals. eBay and Amazon, which actually see the customer's transactions, can and do use that information.
Upverter has some of the right ideas, but not enough user base for their concept of a "crowdsourced parts library" to be useful. They're still way ahead of CircuitBee.
With the better electrical CAD packages, you get a good parts library, including the PC board layout and maybe a SPICE model for the part. The major commercial library has 2 million parts in it. There are open source parts libraries, but the contents tends to be somewhat random, since it's just what people happened to upload.
Parts libraries also need to be consistent. You want all the pads designed with uniform design rules, or you have problems in board fab. So a Q/A operation and standards are needed. (Open Circuits says "Please also note that we guarantee that there are some messed up footprints in this library.")
Digi-Key manages to collect the data sheets for almost everything they sell. Maybe someone will do that for PC board footprints and simulation models and make them freely available. It probably won't be CircuitBee, but some vendor of parts or boards.
Bing's market share isn't all that bad, for only two years into the market. Microsoft has lost money entering a market before; the original XBox was a money drain from start to finish. A decade later, Sega is out of consoles, Sony is in trouble, and Microsoft is finally #1 in console sales, having passed Nintendo this year. Microsoft is finally profitable in games, although it's not clear if they've made up all the early losses yet.
Microsoft's online services division is losing about US$2bn a year, but that group includes more than Bing. Microsoft has a whole range of online services, many part of "Windows Live", mimicking many of the services Google gives away to annoy Microsoft. The search engine itself probably generates enough ad revenue to support itself.
Microsoft went at online from the opposite direction as Google. They did the money-losers, like free email, first, then the search engine with ads, which makes all the money. Microsoft, like Google, has recently been dumping some of the less successful freebie products. That can't hurt.
Bing has a brain drain. They've been losing key technical people and execs to Facebook, eBay, and even AOL. I'm not even sure who's running Bing right now. (Does anybody know who the top 3 people are at Bing right now? Let me know.) They're hiring, if you want to work in search.
Bing could potentially do a better job at search than Google. Google gets 30% of their ad revenue from AdSense sites, and has been hesitant to bring the hammer down on made-for Adsense junk sites. Bing could do better just by penalizing sites with ads, content farms, and related junk, like Blekko does. Google is vulnerable there.