I've seen numbers like this for many countries, and I wonder if it's a side effect of giving an English-language test such as WISC to a non-native speaker? I suspect this because at 80 a personal qualifies for special ed in my (US) state, so this seems doubly suspect. Finally, the standard deviation is, by definition, 15.
The real answer is Baumol's Cost Disease, and it's why all services get expensive faster than overall average inflation. It's also why products get expensive slower than overall inflation. $6 T-Shirts at Sears are cheaper, inflation adjusted, than they were when I was a kid in the 70s (6 bucks today was 2 bucks in 1981 and pennies before 1974). Meanwhile, have you hired a couple of musicians for a wedding lately? Freaking expensive. Education is a service, not a product, and there have only been the slightest productivity improvements. The National Science Foundation and the National Institutes for Health set the overhead rates, and they've barely changed since the early 90s. Incidentally, the number one driver of university costs has been faculty and staff health insurance - like every other labor-intensive business.
The big business doing this now is Wal-Mart and their "Woodforest Bank" branches inside the store - deposit in one town, withdraw in another. Fuel is still mostly bought, and loads are usually still paid for with cash, especially among independents, but most towns have a Wal-mart and drivers are rarely going down the road with $3-4K in the cab anymore.
It will be cool if they can produce (provably) optimal "tours" for arbitrarily complicated sets of stops. It will be even cooler if they can do it in polynomial time.
I actually took a few minutes and skimmed some of the online training modules that USDOT put out for developers. There are problems, and they "sort of" admit to them. If I read this correctly, there are only ~105K possible keys, though I'd love to be wrong - otherwise this should fall to a brute-force attack in seconds. Just slam on your brakes, record the outgoing packets, and try every key until one decodes as "putting on my brakes, dude!" And now you have enough information to force any car to let you merge in, whether the driver wants to or not. Which, heck, might actually improve safety. I don't know. Could go either way.
As far as privacy, it's still pretty weak (=totally cracked). They aren't recording the MAC addresses of the cars per se, or so they say, but you could from first principles tell what factory a car came from and its approximate date of manufacture. That's useful - narrows it down to a manageable number of vehicles. Or just passively monitor an intersection with a license plate reader and record every "putting on my brakes, dude!" message. Now you have a table of license plates and MAC addresses. I can't see, frankly, that licence plate reader vendors won't sell this as an optional feature for a modest additional charge.
A big problem, and one discussed elsewhere, is that re-keying this thing is going to be a pain. It doesn't support over-the-air keying, and the intent is that a dealer will periodically re-flash new certificates/keys. That's a tall order. For this to work, cars will have to accept some pretty old keys (insert stars wars joke about older codes but they check out, above), increasing the odds they'll have to accept previously compromised keys. Which will probably be had by dumping the flash.
Anyway, the layer 1 and 2 protocols over the air are 802.11p, and what looks like a quasi-layer-3 is IEEE 1609. So get started.
Another commenter has asked about GPS errors. Looks like the standards explicitly support a very-short-range form of differential GPS and I wouldn't be surprised to see some sort of localizer used to reinitialize a Kalmann filter at some point. Pretty easy these days.
Same thoughts here - just take a moment and enjoy it at home, but... I used to work for a company that made apparel. There is a plant in the deep south with washing machines the size of dumpsters - they wash 288 jeans at a time. Over 10,000 pieces are washed, dried, pressed, and folded a day. People stand there and manually turn them wrong-side-out and then, after laundry, turn them back again. They have to check the pockets to make sure there isn't any pumice left in them from "Stone Washing" - the rocks will mess up an iron. Extremely low-tech, labor intensive. Most of it is done in Mexico, except during droughts when it's hard to get enough water there (I'm not making this up), so they keep the operation in Alabama running all the time and they just add a couple of shifts during dry weather. A jeans-folding robot would need to come in pretty cheap so its Net Present Value would be less than minimum wage. Wild guess, maybe around $10K would be the breakeven point.
Come to think of it, with Alabama in record drought right now, I wonder if that laundry is running?:-)
I've stuck pin stock over those screws with superglue and then dissolved them back off with acetone. Before you glue it, bend a right angle crook to get some leverage for turning. Not, perhaps, as good as a real pentalobe driver, but then again I guess it couldn't strip the head if it had to.
The cool thing about CDMA is that it won't work without precision time standards in each of the base stations - i.e., GPS receivers with antennas fed through known lengths of feedline (or, alternatively, GPS receivers with known lengths of wire providing a 1 pulse per second reference). Net result is that CDMA can give sub-ppb time reference, and it works great indoors, too. Probably overkill for getting the kids up in the morning.:-)
Bobby? Bobby Tables? Is that you? Haven't heard from you in ages, dude. What have you been up to? Things went to pieces here right about the time you left...
41% of those actions occurred in Puerto Rico, with the number two favorite being Colorado. Looks like two field offices care enough to investigate, most of the time.
The FCC has, over the last couple of decades, gone a long way toward outsourcing radio regulation. Now, they're predominantly a finance agency conducting spectrum auctions and counting on competitors to police each other. Often, this actually works. Sometimes it doesn't. To be sure, they do have some field-based, rapidly-responding capability to identify interference, especially for (and between!) public safety users, and they occasionally use this to levy big fines to scare everyone else into compliance - I wouldn't want to absorb the typically $11K fine, personally. But their enforcement division is nothing like it used to be.
As far as what used to be called "type approval" (the pre-marketing certification that a device is compliant), it is now 100% outsourced. The fees for this run between $100K and $500K, depending on the complexity of the device and the section of the FCC regs you have to be compliant with (47CFR). 47CFR95 devices are cheap, 47CFR90 devices aren't. 47CFR5 devices can (usually) be self-certified, but they can't be sold.
So, unless Open Source drivers can be sold and operated under Part 5, and it's totally not evident to me that they can, then certification cost is going to mean that someone if going to have to pick a tiny handful of reference devices, certify some binary blobs, and call it done. My guess is that those someones would be Red Hat and quite possibly Lenovo - the one and only marketable Linux Laptop would perhaps be enough of a niche to pursue. In principle, someone like, say, Intel could certify a blob for a mezzanine card and sell the card to vendors, but bear in mind this means the antenna must be fixed onto the card and certified as a package.
Hmmm. If I degenerate enough, and if I just happen to be in Walking Dead country, then yeah... I might visit the place. But that's two unlikely things that have to happen at the same time.:-)
If you're reading this article, you may also be interested in the E. H. Danner Museum of Telephony located on the grounds of Fort Concho National Historic Landmark in San Angelo, TX. While there, you might as well see the Robert Wood Johnson Museum of Frontier Medicine, also on the grounds. Don't go on a full stomach. And that's about all there is to do in San Angelo.
------ "The 600 series had rubber skin. We spotted them easy, but these are new. They look human... sweat, bad breath, everything. Very hard to spot." -Kyle Reese
I'm starting to suspect we're in violent agreement here.:-)
I've physically, with my eyeballs, seen Linux running on some sort of z series a couple years ago. I saw AIX/370 running on some sort of box around 1990-92-ish, so I know it can be done (parenthetically, I was told it shared no code at all with AIX/6000). My entire point with virtualization is not to suggest there's a problem with the mainframe. Whether it makes sense to or not is completely beside the point.
Z series and power definitely do not share an instruction set, and they have really substantial differences, but that isn't keeping the engineering teams all that separated, if indeed they are at all.
Quoting Timothy Prickett Morgan from http://www.itjungle.com/tfh/tf... , "And as has been the case in the past, the Power and z processors are designed by a single processing team and are borrowing technologies from each other. This does not, however, mean that IBM is creating a converged processor that can support either Power or z instruction sets." My hazy memory makes me think they're sharing FPU blocks, possibly one of the bus interfaces, and it seems like one of the cache blocks (L3?). Z has plenty of custom hardware - I think it's fair to say it's predominantly custom - the branch predictor would have to be pretty different, and of course power doesn't have a BCD arithmetic unit.
Point being, if you're going down the Z Series road to run a Unix-like OS, why not just (conceptually) stop early, end up with something like Power, and call it good? Anyway, I'll argue that they're spiritually and economically related, and there's more than a passing family resemblance. Kind of like power and modern ("advanced server") iSeries, though that's getting more into Deliverance territory.
Meanwhile, channel controllers aren't as dumb as they look. A little wikipedia action here (I know, citing wikipedia, but it's monday and I'm still tired): https://en.wikipedia.org/wiki/... . Turns out the little dickens can do a decent amount of work on its own. I think the wikipedia entry is showing its age... seems like IBM's done a lot more work since this.
I remember when SASI came out. I looked at the spec and thought "Hey, this is a lot like a channel controller." Then I read some more and decided "No, a channel controller is much smarter. But this isn't bad." SASI became SCSI and everything else flowed downhill from that. At a very real level, Linux is forcing a million dollar fibre channel array to look more or less like an ST506 connected a board from 1984. Wild.
Yup - first thought that ran through my mind: "Oh, they're selling Z Series with crippled Firmware."
I'm kind of stumped. Linux on a Mainframe is a neat party trick, but it doesn't really make a lot of sense. Modern Z Series hardware is heavily derived from Power. Why not just run Power Linux? Mainframe I/O design is intentionally about as un-PDP-like as possible, so it's a bad match for Unix, Linux, or even Windows for that matter (NT ran on MIPS, so it theoretically could be ported to S/390). Mainframes get their performance by pushing computation into the channel controllers, and while you could do something like that in Linux, are any of your applications ready to treat your database like a device driver? Because that's what you'll have to do. And, incidentally, it's why every attempt from AIX/370 to Linux on Z Series has required virtualization and a ton of independent kernels to get anything resembling decent performance. And that's where Dell will come in and put thousands of cores in a 42U rack for you... No, IBM's own P Series is a better idea, and their former x86 division (now Lenovo) looks even better.
I've seen numbers like this for many countries, and I wonder if it's a side effect of giving an English-language test such as WISC to a non-native speaker? I suspect this because at 80 a personal qualifies for special ed in my (US) state, so this seems doubly suspect. Finally, the standard deviation is, by definition, 15.
...netcraft confirms it!
Sorry. Flashbacks.
The real answer is Baumol's Cost Disease, and it's why all services get expensive faster than overall average inflation. It's also why products get expensive slower than overall inflation. $6 T-Shirts at Sears are cheaper, inflation adjusted, than they were when I was a kid in the 70s (6 bucks today was 2 bucks in 1981 and pennies before 1974). Meanwhile, have you hired a couple of musicians for a wedding lately? Freaking expensive. Education is a service, not a product, and there have only been the slightest productivity improvements. The National Science Foundation and the National Institutes for Health set the overhead rates, and they've barely changed since the early 90s. Incidentally, the number one driver of university costs has been faculty and staff health insurance - like every other labor-intensive business.
The big business doing this now is Wal-Mart and their "Woodforest Bank" branches inside the store - deposit in one town, withdraw in another. Fuel is still mostly bought, and loads are usually still paid for with cash, especially among independents, but most towns have a Wal-mart and drivers are rarely going down the road with $3-4K in the cab anymore.
It will be cool if they can produce (provably) optimal "tours" for arbitrarily complicated sets of stops. It will be even cooler if they can do it in polynomial time.
I actually took a few minutes and skimmed some of the online training modules that USDOT put out for developers. There are problems, and they "sort of" admit to them. If I read this correctly, there are only ~105K possible keys, though I'd love to be wrong - otherwise this should fall to a brute-force attack in seconds. Just slam on your brakes, record the outgoing packets, and try every key until one decodes as "putting on my brakes, dude!" And now you have enough information to force any car to let you merge in, whether the driver wants to or not. Which, heck, might actually improve safety. I don't know. Could go either way.
As far as privacy, it's still pretty weak (=totally cracked). They aren't recording the MAC addresses of the cars per se, or so they say, but you could from first principles tell what factory a car came from and its approximate date of manufacture. That's useful - narrows it down to a manageable number of vehicles. Or just passively monitor an intersection with a license plate reader and record every "putting on my brakes, dude!" message. Now you have a table of license plates and MAC addresses. I can't see, frankly, that licence plate reader vendors won't sell this as an optional feature for a modest additional charge.
A big problem, and one discussed elsewhere, is that re-keying this thing is going to be a pain. It doesn't support over-the-air keying, and the intent is that a dealer will periodically re-flash new certificates/keys. That's a tall order. For this to work, cars will have to accept some pretty old keys (insert stars wars joke about older codes but they check out, above), increasing the odds they'll have to accept previously compromised keys. Which will probably be had by dumping the flash.
Anyway, the layer 1 and 2 protocols over the air are 802.11p, and what looks like a quasi-layer-3 is IEEE 1609. So get started.
Another commenter has asked about GPS errors. Looks like the standards explicitly support a very-short-range form of differential GPS and I wouldn't be surprised to see some sort of localizer used to reinitialize a Kalmann filter at some point. Pretty easy these days.
Same thoughts here - just take a moment and enjoy it at home, but... I used to work for a company that made apparel. There is a plant in the deep south with washing machines the size of dumpsters - they wash 288 jeans at a time. Over 10,000 pieces are washed, dried, pressed, and folded a day. People stand there and manually turn them wrong-side-out and then, after laundry, turn them back again. They have to check the pockets to make sure there isn't any pumice left in them from "Stone Washing" - the rocks will mess up an iron. Extremely low-tech, labor intensive. Most of it is done in Mexico, except during droughts when it's hard to get enough water there (I'm not making this up), so they keep the operation in Alabama running all the time and they just add a couple of shifts during dry weather. A jeans-folding robot would need to come in pretty cheap so its Net Present Value would be less than minimum wage. Wild guess, maybe around $10K would be the breakeven point.
Come to think of it, with Alabama in record drought right now, I wonder if that laundry is running? :-)
I've stuck pin stock over those screws with superglue and then dissolved them back off with acetone. Before you glue it, bend a right angle crook to get some leverage for turning. Not, perhaps, as good as a real pentalobe driver, but then again I guess it couldn't strip the head if it had to.
ISPF: Whatever my 3270 emulator is, which is green on black.
It inherited that from its NeXTstep origins. God I feel old.
Do you still sell forestry equipment? Because that was some badass stuff.
The cool thing about CDMA is that it won't work without precision time standards in each of the base stations - i.e., GPS receivers with antennas fed through known lengths of feedline (or, alternatively, GPS receivers with known lengths of wire providing a 1 pulse per second reference). Net result is that CDMA can give sub-ppb time reference, and it works great indoors, too. Probably overkill for getting the kids up in the morning. :-)
...or maybe it's just required that people named Jean-Luc go into astro/planetary/aerospace lines of work. :-)
Bobby? Bobby Tables? Is that you? Haven't heard from you in ages, dude. What have you been up to? Things went to pieces here right about the time you left...
41% of those actions occurred in Puerto Rico, with the number two favorite being Colorado. Looks like two field offices care enough to investigate, most of the time.
The FCC has, over the last couple of decades, gone a long way toward outsourcing radio regulation. Now, they're predominantly a finance agency conducting spectrum auctions and counting on competitors to police each other. Often, this actually works. Sometimes it doesn't. To be sure, they do have some field-based, rapidly-responding capability to identify interference, especially for (and between!) public safety users, and they occasionally use this to levy big fines to scare everyone else into compliance - I wouldn't want to absorb the typically $11K fine, personally. But their enforcement division is nothing like it used to be.
As far as what used to be called "type approval" (the pre-marketing certification that a device is compliant), it is now 100% outsourced. The fees for this run between $100K and $500K, depending on the complexity of the device and the section of the FCC regs you have to be compliant with (47CFR). 47CFR95 devices are cheap, 47CFR90 devices aren't. 47CFR5 devices can (usually) be self-certified, but they can't be sold.
So, unless Open Source drivers can be sold and operated under Part 5, and it's totally not evident to me that they can, then certification cost is going to mean that someone if going to have to pick a tiny handful of reference devices, certify some binary blobs, and call it done. My guess is that those someones would be Red Hat and quite possibly Lenovo - the one and only marketable Linux Laptop would perhaps be enough of a niche to pursue. In principle, someone like, say, Intel could certify a blob for a mezzanine card and sell the card to vendors, but bear in mind this means the antenna must be fixed onto the card and certified as a package.
Sorry to be such a downer...
Hmmm. If I degenerate enough, and if I just happen to be in Walking Dead country, then yeah... I might visit the place. But that's two unlikely things that have to happen at the same time. :-)
If you're reading this article, you may also be interested in the E. H. Danner Museum of Telephony located on the grounds of Fort Concho National Historic Landmark in San Angelo, TX. While there, you might as well see the Robert Wood Johnson Museum of Frontier Medicine, also on the grounds. Don't go on a full stomach. And that's about all there is to do in San Angelo.
Word doesn't even completely interoperate with Word for Mac, as far as that goes.
Still, you could have a lot of fun with someone... this is the sort of thing that happens when you google "dental robot vomit":
http://www.nissin-dental.net/p...
http://techcrunch.com/2011/06/...
------
"The 600 series had rubber skin. We spotted them easy, but these are new. They look human... sweat, bad breath, everything. Very hard to spot." -Kyle Reese
Yeah, I'll take $20 on the 'hog.
I'm starting to suspect we're in violent agreement here. :-)
I've physically, with my eyeballs, seen Linux running on some sort of z series a couple years ago. I saw AIX/370 running on some sort of box around 1990-92-ish, so I know it can be done (parenthetically, I was told it shared no code at all with AIX/6000). My entire point with virtualization is not to suggest there's a problem with the mainframe. Whether it makes sense to or not is completely beside the point.
Z series and power definitely do not share an instruction set, and they have really substantial differences, but that isn't keeping the engineering teams all that separated, if indeed they are at all.
Quoting Timothy Prickett Morgan from http://www.itjungle.com/tfh/tf... , "And as has been the case in the past, the Power and z processors are designed by a single processing team and are borrowing technologies from each other. This does not, however, mean that IBM is creating a converged processor that can support either Power or z instruction sets." My hazy memory makes me think they're sharing FPU blocks, possibly one of the bus interfaces, and it seems like one of the cache blocks (L3?). Z has plenty of custom hardware - I think it's fair to say it's predominantly custom - the branch predictor would have to be pretty different, and of course power doesn't have a BCD arithmetic unit.
Point being, if you're going down the Z Series road to run a Unix-like OS, why not just (conceptually) stop early, end up with something like Power, and call it good? Anyway, I'll argue that they're spiritually and economically related, and there's more than a passing family resemblance. Kind of like power and modern ("advanced server") iSeries, though that's getting more into Deliverance territory.
Meanwhile, channel controllers aren't as dumb as they look. A little wikipedia action here (I know, citing wikipedia, but it's monday and I'm still tired): https://en.wikipedia.org/wiki/... . Turns out the little dickens can do a decent amount of work on its own. I think the wikipedia entry is showing its age... seems like IBM's done a lot more work since this.
I remember when SASI came out. I looked at the spec and thought "Hey, this is a lot like a channel controller." Then I read some more and decided "No, a channel controller is much smarter. But this isn't bad." SASI became SCSI and everything else flowed downhill from that. At a very real level, Linux is forcing a million dollar fibre channel array to look more or less like an ST506 connected a board from 1984. Wild.
It's not the mainframe that's so bulletproof. It's MVS. And, as you noted, an extremely risk-avoidant culture.
Yup - first thought that ran through my mind: "Oh, they're selling Z Series with crippled Firmware."
I'm kind of stumped. Linux on a Mainframe is a neat party trick, but it doesn't really make a lot of sense. Modern Z Series hardware is heavily derived from Power. Why not just run Power Linux? Mainframe I/O design is intentionally about as un-PDP-like as possible, so it's a bad match for Unix, Linux, or even Windows for that matter (NT ran on MIPS, so it theoretically could be ported to S/390). Mainframes get their performance by pushing computation into the channel controllers, and while you could do something like that in Linux, are any of your applications ready to treat your database like a device driver? Because that's what you'll have to do. And, incidentally, it's why every attempt from AIX/370 to Linux on Z Series has required virtualization and a ton of independent kernels to get anything resembling decent performance. And that's where Dell will come in and put thousands of cores in a 42U rack for you... No, IBM's own P Series is a better idea, and their former x86 division (now Lenovo) looks even better.
Erik