...and the kernel is full of such tables already, so it's not like it's a new idea.
So, for example, there's ide_acpi_blacklist in drivers/ide/ide-acpi.c; there's traps throughout the FireWire stack to disable features (like isochronous) on known-flawed chipsets (almost all of them), and so on.
Sometimes this is driven by vendor errata sheets; like when there's a flaw in a TI 1394 chip, if it can be identified, the errata workaround can be applied to all cards with it.
Most of the time, it seems to be driven by user bug reports.
I know that was supposed to be funny.......but I've got discs that get worse and worse each time I re-scan the collection. (I'm on the 3rd rip now; 1st to 192k MP3, then to 256k/320k MP3, and now lossless.)
First pass, everything was good. No clicks and pops--except for the ones done on Mac OS 8 where I might have moved the mouse while SoundJam MP was grinding away.
Second pass, a few discs needed the (then-new) "Error correction" feature in iTunes.
Third pass, for some of those discs, I had to use cdparanoia to rip the disc, then burn a new copy so iTunes could rip it. (I wanted a backup of the failing disc anyway, so that was easier than converting the cdparanoia rips directly.)
(And I do have a good selection of drives from an assortment of vendors; some of these would no longer play in an audio-only deck.)
One I actually had to give up and buy a new copy--I couldn't find an uncompressed one to download.
That's basically what I did; I've got the storage now, so I wanted to re-rip everything into lossless. After doing that, I built a list of "suspicious" files: less than 256k MP3, VBR MP3, and 128k AAC. (The latter needed some manual inspection, to find iTMS stuff that I'd de-DRMed but no iTunes+ version was ever made.)
(Unlike another poster, I'd previously re-coded my MP2 files into 256k MP3s.)
Oh, and I had to be careful around the VBR MP3s to identify stuff I'd gotten from my brief use of emusic.com. Maybe some people like subscriptions, but I tend to buy a whole mess of music at once and then nothing for months at a time.
Then I fixed all the missing album artwork. And scanned for bad ripping, thanks for the really crappy BD-combo drive, Lite-On.
I got a noise floor of about -35dB on my turntable. Which, granted, isn't an "audiophile" unit; it's just a Dual from the '60s. (With a modern Ortofon cartridge; with the OEM Shure cartridge the noise floor was closer to -25dB.) Which means the effective dynamic range was 35dB.
16 bit linear on CDs has a dynamic range of, what was it... clickyclicky... 96dB.
What people seem to ignore--and they do it with tubes vs. transistors too--is that CDs enabled a level of crappy mastering that wasn't possible before. (Just like cheap BJTs enabled crappy amps which weren't possible before.)
If you did the "loudness war" thing with an LP, the stylus wouldn't track. And I've owned LPs which were a pain to play; you'd have to fiddle the anti-skate and tracking force because they'd packed the grooves too close together (to get more music on a side), or made the excursions too big (to get louder music) and they'd just skip if you didn't adjust things for that particular album.
We just don't remember the crap.
Oh: LPs also only had a channel separation of about 20dB; so CDs made from the original tapes with hard separation (all vocals in left, all instruments in right say) that didn't take that into account sound ridiculous. That's, again, not a CD problem, but a mastering problem.
There's been tracks from the iTMS that have skips in them....
(I mainly buy CDs and rip them myself, but I do have about 80 tracks from the iTMS. Two had skips, but the album they were on was removed from the store. Maybe it had other problems....)
Oh, and Lite-On BD-ROM/DVD+-RW combo drives are terrible for ripping audio; they don't report uncorrected errors, so unless you've got a full cdparanoia session going, you get junk if you even breathe near the drive. I had to re-do 50 rips. (cdparanoia crashed the drive.)
Given that MissingSync for PalmOS could do syncs over Wi-Fi and Bluetooth to a Mac OS X host, I'd say it's a pretty obvious idea.
What real evidence says they stole the app itself, anyway? I'm pretty sure you submit the binaries to Apple for approval, not the source code. The agreement says only that you submit "Your Application."
Not reliably; you'd need to issue a flush to the disk itself, then as soon as you get the "completed" response you'd have to drop power to the drive. You could build a test rig with a relay under control of the test program, I suppose, to interrupt the power to the disk.
Then, after powering the drive back up, you'd check for your known value. Repeat a whole bunch of times, because this is obviously a race condition; it would probably help to have an active "read" load at the same time.
I run a couple of mail servers co-located in TORIX precisely because of the USA PATRIOT Act and related "all your DB are belong to us" rules south of the border.
And some people are happy to pay me 10x what they'd pay Google or some other mail provider, just to keep their data in their own country. (And with off-site backups somewhere they can actually drive to and ring the doorbell.)
In some cases, this is more about paranoia around industrial espionage abetted by the US Government. But it's still money I can spend, so I'm happy to manage a server that satisfies their needs.
Commodore made you hold down the STOP key when striking RESET to have an effect. (RESET always triggered a non-maskable interrupt, but if STOP wasn't also depressed, the default handler would do nothing.) Striking RESET could mess up things if interrupts were disabled for a reason (high-speed sector copies, say). But generally, those situations were times when you would NOT be typing at the same time.
They also had made the RESET key with slightly different properties, so it needed a fairly firm, deliberate strike to be detected.
(Most people, including my younger self, called STOP the "RUN/STOP" key, as the shifted behaviour was to load and run the next file on tape.)
Anyway. Most of the complaints about "stuff we've lost" seems to be stuff people who gave up the things they liked and started using things they don't like lost. Such as, I can still split my text editor window as many times as I like; but then, it's (X)Emacs... I don't build my life around commercial software for exactly that reason: it goes away.
So, uh, how long does a shortened URL remain valid at one of those services?
I couldn't find anything on TinyURL.com that says what their retention policy is. Is it really a good idea to use URLs you don't control in signage? Or even more so, documentation?
Alternately, clients could properly re-assemble a URL by dropping whitespace between < and >. That does mean you'd have to use <http://www.google.com> in plain text, but that's actually (one way) recommended in appendix C of RFC 3986. (RFC 1738 recommended <URL: and > as delimiters, that never caught on.)
And hey, look at that, RFC 1738 and 3986 already includes information on re-assembling a URL that has had whitespace (including newline) injected by formatting.
Which means the fact that this doesn't work in general is just sad.
(Though that thing Exchange does to "text/plain" e-mail to create a "text/html" version is just obscene. It completely re-writes the plain-text part, in addition to synthesizing HTML.)
This is exactly why the best thing to do is: include the source with the binaries. Then you've trivially achieved your GPL source obligation, you don't have to run download servers for an unknowable future time (3 years after the last person gets a binary... but the offer is transitive if the work isn't modified), you don't even have to worry about keeping that particular version of source around.
So that's what we do at my company: I set up the tarballs (and patches I add locally) so that our distribution system grabs the corresponding source for the binaries it ships. After that, if someone chucks a source file, it's not on us to replace it. (Though our retention period is in excess of 7 years for shipped code, so we certainly _would_.)
Well... What he's describe has been done, somewhat; others have mentioned AppleScript and other more-human-language environments. I'll go down a different path....
The AmigaDOS CLI had named parameters for its commands, completely different from the UNIX positional-and-switch model. So the MOVE syntax was:
Rename From/A/M To=As/A QUIET/S
What that means is:
- From is an argument (/a), that can be used multiple times (/m). - To is an argument (/a) with an alias (As). - Quiet is a switch.
If parameters can be inferred from position, the names may be omitted. (So, "to" is mandatory and single, so after QUIET is pulled out of the list, the last item is "to", and everything before it is "from".)
So, you could do a simple:
rename myfile yourfile
Or
rename myfile TO yourfile
Or
rename FROM myfile TO yourfile
Or even
rename TO yourfile FROM myfile
If you had a parameter that was the same name as an argument name, then you HAD to use the named form.
rename FROM from TO to
(Obviously, he'd want an alias setting move=rename, too.)
Most "Check Engine" indications are for emissions controls, not engine operations issues. That's why (as another reply notes) you get Check Engine for a loose gas cap.
So, there are many "Check Engine" indications that will happen, yet the vehicle is still perfectly safe to drive. Even if there's an emission control problem, you can still be well within your emissions limits, it just might be higher than the automaker promised the U.S. EPA it would be. (And, not being in the U.S., I don't care about that.)
Subaru got clever, though; when Check Engine comes on in the newer models (2008 and up at least), it also disables cruise control. What's really bad is, it can take several off-on cycles of the engine before the "loose gas cap" condition clears, so if you're on an 800 mile road trip... you can be going a long way without cruise.
They turn them down at night; to something like half the flow required at peak daytime viewing hours.
Then they shine lights on them; the tour guide at Sir Adam Beck smugly called them "weapons of mass distraction". (He also asked me more questions about my DSLR then he could answer about their power station... but I am an electrical engineer, so already knew way more than the "tourist" stuff. And the guide was in the market for a new camera.)
They change the colours periodically, and if we hadn't been short of time, I'd have gotten some shots of the gels part-way across the projector lenses. It turns out of you spend enough time taking pictures at night, they DO turn the lights off... 5 minutes to midnight, at least on Mother's Day.
(Since power demand is low at this time of year, and it's spring runoff, I doubt the water level was reduced by much that particular night. In the summer, they'll be storing everything they can in the pump-generating reservoirs on both sides for that 4PM demand peak... the one Ohio mucked up a few years back.)
I've already had a newer version of Firefox crash an older X11 display driver. Absolutely rock solid on Firefox 3.6 and down, and every other program I want to run. But the new GPU acceleration in Firefox? Could cause all of X11 to go away.
And Flash inside Firefox would pretty much guarantee a visit from the Coredump Gods. Fixed with a newer driver, but man is updating annoying.
Kinda sad that "web browsing" is the most intense job run on my work machine. I would have thought the massively parallel builds, or data simulation code, or something that actually pegs all the CPUs would be it. But no, it's the web.
Sure, in the U.S. with a lot of coal power, electric can be pretty dirty.
But in Quebec, with 95% hydroelectric, advertising that "you'll reduce CO2 emissions by switching to these CFLs" is an outright lie. Diesel is guaranteed "dirtier" than electricity.
Similarly, Ontario has typically no more than 1/3 of its generating capacity from combustible fuels (fossil and bio). It's usually closer to 1/4; so even if the diesel train and the station-to-rails efficiencies were equivalent (which leaves out the energy in getting the fuel to the train or power station), using electricity would be 1/3 as dirty as diesel directly. You could actually have the electric train 2x less efficient (net) and still be cleaner.
(On an generating capacity of ~23,000 MW, Ontario has 1900 MW of coal generation remaining; of which it is rare to see more than 4 MW operating. Though that's still more than 1.21 GW of coal capacity.)
My GPS has a hands-free speakerphone gizmo in it. So it may be on and at the "Where do you want to go?" menu if I'm anticipating needing the phone. But when it's on, the trip logger is running.
With the exception of the Performa [56][23]00 series, all Macs with an MMU can run Linux pretty well. (So that's 68020 with a 68851, 68030 or later, and all PowerPCs.)
I used a 68k version of Debian on an old Quadra as a serial terminal for a bit. In text mode, it was plenty fast enough.
So, OK, I've only been looking at the iThings. But to get a real GPS receiver, you need the 3G model.
So I'm thinking, 3G tablet, but no SIM card. I can do 3G data tethering through WiFi on my phone; the tablet will still have proper GPS. So it's more expensive to buy, but not more expensive per month.
(If I could just get an add-on SIM card and share the data allowance I've already got, that would be different. But this is Canada, you can't do that.)
Good digital circuits--the guts on the IC anyway--aren't easy, either. It's one thing to build a flip-flop, say, from basic logic gates and just paste in the relevant FETs. It's another to go back to first principles and build a bistable multivibrator taking advantage of the unique properties of the FETs you're using and the features you want the flip-flop to have.
In the data sheets, those equivalent logic circuits are often simply operationally equivalent; they don't represent the actual integrated circuit. (Better data sheets show you that, too. Though most of mine are old enough that 74LS is still a pretty neat idea.... I've moved on to 74HC.)
Even if no-one replaced CPUs, this would still let OEMs make a single base system board and offer a variety of CPUs for it.
So you get your base system board, with the AM3+ socket. You can then sell it with a $50 dual-core Athlon-II or a $300 6-core Phenom Black and everything in between. (Mine's a $120 3-core Phenom... from a year and a bit ago.)
All without having to even re-program the pick-and-place equipment. Same form-factor parts, just have the robot pick a different CPU. Wouldn't even need to slow down the line for semi-custom configs.
Works the other way, too: if you think your stuff is mostly CPU bound, go with the simpler board with the AM3 socket, slower RAM, fewer PCIe channels, whatever. Then give it a big number cruncher that will mostly munch stuff in L3 cache or higher.
I wrote something similar as a summer student at a Canadian telecom research company. Well, it wasn't spaghetti, but it was my first-ever OO program, and my first-ever C++ program, back when the reference on the language was just the Annotated Reference Manual and GCC still had that "new compiler" smell.
It was a stop-gap kludge project, with a UI modelled on the HP-48SX calculator. It was supposed to last up to a year while the real project got going.
You know where this is going. The real project was canned and they just kept using the kludge. Which meant I had to do phone support for it the next summer. Arrrgh.
With a large enough team, you can complete one child every week.
But it still takes about 9 months for each child.
This is why we have pipelining superscalar processors. You'll probably want out-of-order completion, too, sometimes kids are done early.
The easier example is: One man can dig a hole in 60 seconds. 60 men cannot dig one hole in 60 seconds. But 60 men can dig 60 holes in 60 seconds. That's SIMD, actually: one "dig hole" instruction, 60 execution units running it.
Slashdot Mirror
...and the kernel is full of such tables already, so it's not like it's a new idea.
So, for example, there's ide_acpi_blacklist in drivers/ide/ide-acpi.c; there's traps throughout the FireWire stack to disable features (like isochronous) on known-flawed chipsets (almost all of them), and so on.
Sometimes this is driven by vendor errata sheets; like when there's a flaw in a TI 1394 chip, if it can be identified, the errata workaround can be applied to all cards with it.
Most of the time, it seems to be driven by user bug reports.
I know that was supposed to be funny.... ...but I've got discs that get worse and worse each time I re-scan the collection. (I'm on the 3rd rip now; 1st to 192k MP3, then to 256k/320k MP3, and now lossless.)
First pass, everything was good. No clicks and pops--except for the ones done on Mac OS 8 where I might have moved the mouse while SoundJam MP was grinding away.
Second pass, a few discs needed the (then-new) "Error correction" feature in iTunes.
Third pass, for some of those discs, I had to use cdparanoia to rip the disc, then burn a new copy so iTunes could rip it. (I wanted a backup of the failing disc anyway, so that was easier than converting the cdparanoia rips directly.)
(And I do have a good selection of drives from an assortment of vendors; some of these would no longer play in an audio-only deck.)
One I actually had to give up and buy a new copy--I couldn't find an uncompressed one to download.
That's basically what I did; I've got the storage now, so I wanted to re-rip everything into lossless. After doing that, I built a list of "suspicious" files: less than 256k MP3, VBR MP3, and 128k AAC. (The latter needed some manual inspection, to find iTMS stuff that I'd de-DRMed but no iTunes+ version was ever made.)
(Unlike another poster, I'd previously re-coded my MP2 files into 256k MP3s.)
Oh, and I had to be careful around the VBR MP3s to identify stuff I'd gotten from my brief use of emusic.com. Maybe some people like subscriptions, but I tend to buy a whole mess of music at once and then nothing for months at a time.
Then I fixed all the missing album artwork. And scanned for bad ripping, thanks for the really crappy BD-combo drive, Lite-On.
I got a noise floor of about -35dB on my turntable. Which, granted, isn't an "audiophile" unit; it's just a Dual from the '60s. (With a modern Ortofon cartridge; with the OEM Shure cartridge the noise floor was closer to -25dB.) Which means the effective dynamic range was 35dB.
16 bit linear on CDs has a dynamic range of, what was it... clickyclicky... 96dB.
What people seem to ignore--and they do it with tubes vs. transistors too--is that CDs enabled a level of crappy mastering that wasn't possible before. (Just like cheap BJTs enabled crappy amps which weren't possible before.)
If you did the "loudness war" thing with an LP, the stylus wouldn't track. And I've owned LPs which were a pain to play; you'd have to fiddle the anti-skate and tracking force because they'd packed the grooves too close together (to get more music on a side), or made the excursions too big (to get louder music) and they'd just skip if you didn't adjust things for that particular album.
We just don't remember the crap.
Oh: LPs also only had a channel separation of about 20dB; so CDs made from the original tapes with hard separation (all vocals in left, all instruments in right say) that didn't take that into account sound ridiculous. That's, again, not a CD problem, but a mastering problem.
There's been tracks from the iTMS that have skips in them....
(I mainly buy CDs and rip them myself, but I do have about 80 tracks from the iTMS. Two had skips, but the album they were on was removed from the store. Maybe it had other problems....)
Oh, and Lite-On BD-ROM/DVD+-RW combo drives are terrible for ripping audio; they don't report uncorrected errors, so unless you've got a full cdparanoia session going, you get junk if you even breathe near the drive. I had to re-do 50 rips. (cdparanoia crashed the drive.)
Given that MissingSync for PalmOS could do syncs over Wi-Fi and Bluetooth to a Mac OS X host, I'd say it's a pretty obvious idea.
What real evidence says they stole the app itself, anyway? I'm pretty sure you submit the binaries to Apple for approval, not the source code. The agreement says only that you submit "Your Application."
Not reliably; you'd need to issue a flush to the disk itself, then as soon as you get the "completed" response you'd have to drop power to the drive. You could build a test rig with a relay under control of the test program, I suppose, to interrupt the power to the disk.
Then, after powering the drive back up, you'd check for your known value. Repeat a whole bunch of times, because this is obviously a race condition; it would probably help to have an active "read" load at the same time.
I run a couple of mail servers co-located in TORIX precisely because of the USA PATRIOT Act and related "all your DB are belong to us" rules south of the border.
And some people are happy to pay me 10x what they'd pay Google or some other mail provider, just to keep their data in their own country. (And with off-site backups somewhere they can actually drive to and ring the doorbell.)
In some cases, this is more about paranoia around industrial espionage abetted by the US Government. But it's still money I can spend, so I'm happy to manage a server that satisfies their needs.
Commodore made you hold down the STOP key when striking RESET to have an effect. (RESET always triggered a non-maskable interrupt, but if STOP wasn't also depressed, the default handler would do nothing.) Striking RESET could mess up things if interrupts were disabled for a reason (high-speed sector copies, say). But generally, those situations were times when you would NOT be typing at the same time.
They also had made the RESET key with slightly different properties, so it needed a fairly firm, deliberate strike to be detected.
(Most people, including my younger self, called STOP the "RUN/STOP" key, as the shifted behaviour was to load and run the next file on tape.)
Anyway. Most of the complaints about "stuff we've lost" seems to be stuff people who gave up the things they liked and started using things they don't like lost. Such as, I can still split my text editor window as many times as I like; but then, it's (X)Emacs... I don't build my life around commercial software for exactly that reason: it goes away.
So, uh, how long does a shortened URL remain valid at one of those services?
I couldn't find anything on TinyURL.com that says what their retention policy is. Is it really a good idea to use URLs you don't control in signage? Or even more so, documentation?
Alternately, clients could properly re-assemble a URL by dropping whitespace between < and >. That does mean you'd have to use <http://www.google.com> in plain text, but that's actually (one way) recommended in appendix C of RFC 3986. (RFC 1738 recommended <URL: and > as delimiters, that never caught on.)
And hey, look at that, RFC 1738 and 3986 already includes information on re-assembling a URL that has had whitespace (including newline) injected by formatting.
Which means the fact that this doesn't work in general is just sad.
(Though that thing Exchange does to "text/plain" e-mail to create a "text/html" version is just obscene. It completely re-writes the plain-text part, in addition to synthesizing HTML.)
This is exactly why the best thing to do is: include the source with the binaries. Then you've trivially achieved your GPL source obligation, you don't have to run download servers for an unknowable future time (3 years after the last person gets a binary... but the offer is transitive if the work isn't modified), you don't even have to worry about keeping that particular version of source around.
So that's what we do at my company: I set up the tarballs (and patches I add locally) so that our distribution system grabs the corresponding source for the binaries it ships. After that, if someone chucks a source file, it's not on us to replace it. (Though our retention period is in excess of 7 years for shipped code, so we certainly _would_.)
Well... What he's describe has been done, somewhat; others have mentioned AppleScript and other more-human-language environments. I'll go down a different path....
The AmigaDOS CLI had named parameters for its commands, completely different from the UNIX positional-and-switch model. So the MOVE syntax was:
Rename From/A/M To=As/A QUIET/S
What that means is:
- From is an argument (/a), that can be used multiple times (/m).
- To is an argument (/a) with an alias (As).
- Quiet is a switch.
If parameters can be inferred from position, the names may be omitted. (So, "to" is mandatory and single, so after QUIET is pulled out of the list, the last item is "to", and everything before it is "from".)
So, you could do a simple:
rename myfile yourfile
Or
rename myfile TO yourfile
Or
rename FROM myfile TO yourfile
Or even
rename TO yourfile FROM myfile
If you had a parameter that was the same name as an argument name, then you HAD to use the named form.
rename FROM from TO to
(Obviously, he'd want an alias setting move=rename, too.)
Most "Check Engine" indications are for emissions controls, not engine operations issues. That's why (as another reply notes) you get Check Engine for a loose gas cap.
So, there are many "Check Engine" indications that will happen, yet the vehicle is still perfectly safe to drive. Even if there's an emission control problem, you can still be well within your emissions limits, it just might be higher than the automaker promised the U.S. EPA it would be. (And, not being in the U.S., I don't care about that.)
Subaru got clever, though; when Check Engine comes on in the newer models (2008 and up at least), it also disables cruise control. What's really bad is, it can take several off-on cycles of the engine before the "loose gas cap" condition clears, so if you're on an 800 mile road trip... you can be going a long way without cruise.
They turn them down at night; to something like half the flow required at peak daytime viewing hours.
Then they shine lights on them; the tour guide at Sir Adam Beck smugly called them "weapons of mass distraction". (He also asked me more questions about my DSLR then he could answer about their power station... but I am an electrical engineer, so already knew way more than the "tourist" stuff. And the guide was in the market for a new camera.)
They change the colours periodically, and if we hadn't been short of time, I'd have gotten some shots of the gels part-way across the projector lenses. It turns out of you spend enough time taking pictures at night, they DO turn the lights off... 5 minutes to midnight, at least on Mother's Day.
(Since power demand is low at this time of year, and it's spring runoff, I doubt the water level was reduced by much that particular night. In the summer, they'll be storing everything they can in the pump-generating reservoirs on both sides for that 4PM demand peak... the one Ohio mucked up a few years back.)
I've already had a newer version of Firefox crash an older X11 display driver. Absolutely rock solid on Firefox 3.6 and down, and every other program I want to run. But the new GPU acceleration in Firefox? Could cause all of X11 to go away.
And Flash inside Firefox would pretty much guarantee a visit from the Coredump Gods. Fixed with a newer driver, but man is updating annoying.
Kinda sad that "web browsing" is the most intense job run on my work machine. I would have thought the massively parallel builds, or data simulation code, or something that actually pegs all the CPUs would be it. But no, it's the web.
It depends a lot on your electricity supply.
Sure, in the U.S. with a lot of coal power, electric can be pretty dirty.
But in Quebec, with 95% hydroelectric, advertising that "you'll reduce CO2 emissions by switching to these CFLs" is an outright lie. Diesel is guaranteed "dirtier" than electricity.
Similarly, Ontario has typically no more than 1/3 of its generating capacity from combustible fuels (fossil and bio). It's usually closer to 1/4; so even if the diesel train and the station-to-rails efficiencies were equivalent (which leaves out the energy in getting the fuel to the train or power station), using electricity would be 1/3 as dirty as diesel directly. You could actually have the electric train 2x less efficient (net) and still be cleaner.
(On an generating capacity of ~23,000 MW, Ontario has 1900 MW of coal generation remaining; of which it is rare to see more than 4 MW operating. Though that's still more than 1.21 GW of coal capacity.)
You know you've really overdone it when you've got custom package specs in /sw/fink/dists/local....
(Last night's mini-project: Get fink to build 'sox' with AAC support so it can mess around with ALAC files.)
My GPS has a hands-free speakerphone gizmo in it. So it may be on and at the "Where do you want to go?" menu if I'm anticipating needing the phone. But when it's on, the trip logger is running.
With the exception of the Performa [56][23]00 series, all Macs with an MMU can run Linux pretty well. (So that's 68020 with a 68851, 68030 or later, and all PowerPCs.)
I used a 68k version of Debian on an old Quadra as a serial terminal for a bit. In text mode, it was plenty fast enough.
So, OK, I've only been looking at the iThings. But to get a real GPS receiver, you need the 3G model.
So I'm thinking, 3G tablet, but no SIM card. I can do 3G data tethering through WiFi on my phone; the tablet will still have proper GPS. So it's more expensive to buy, but not more expensive per month.
(If I could just get an add-on SIM card and share the data allowance I've already got, that would be different. But this is Canada, you can't do that.)
Good digital circuits--the guts on the IC anyway--aren't easy, either. It's one thing to build a flip-flop, say, from basic logic gates and just paste in the relevant FETs. It's another to go back to first principles and build a bistable multivibrator taking advantage of the unique properties of the FETs you're using and the features you want the flip-flop to have.
In the data sheets, those equivalent logic circuits are often simply operationally equivalent; they don't represent the actual integrated circuit. (Better data sheets show you that, too. Though most of mine are old enough that 74LS is still a pretty neat idea.... I've moved on to 74HC.)
Even if no-one replaced CPUs, this would still let OEMs make a single base system board and offer a variety of CPUs for it.
So you get your base system board, with the AM3+ socket. You can then sell it with a $50 dual-core Athlon-II or a $300 6-core Phenom Black and everything in between. (Mine's a $120 3-core Phenom... from a year and a bit ago.)
All without having to even re-program the pick-and-place equipment. Same form-factor parts, just have the robot pick a different CPU. Wouldn't even need to slow down the line for semi-custom configs.
Works the other way, too: if you think your stuff is mostly CPU bound, go with the simpler board with the AM3 socket, slower RAM, fewer PCIe channels, whatever. Then give it a big number cruncher that will mostly munch stuff in L3 cache or higher.
I wrote something similar as a summer student at a Canadian telecom research company. Well, it wasn't spaghetti, but it was my first-ever OO program, and my first-ever C++ program, back when the reference on the language was just the Annotated Reference Manual and GCC still had that "new compiler" smell.
It was a stop-gap kludge project, with a UI modelled on the HP-48SX calculator. It was supposed to last up to a year while the real project got going.
You know where this is going. The real project was canned and they just kept using the kludge. Which meant I had to do phone support for it the next summer. Arrrgh.
With a large enough team, you can complete one child every week.
But it still takes about 9 months for each child.
This is why we have pipelining superscalar processors. You'll probably want out-of-order completion, too, sometimes kids are done early.
The easier example is: One man can dig a hole in 60 seconds. 60 men cannot dig one hole in 60 seconds. But 60 men can dig 60 holes in 60 seconds. That's SIMD, actually: one "dig hole" instruction, 60 execution units running it.