If we had the same crazy patent environment when cars were being developed, every car would have a different way to control it.
Early cars did have all sorts of control schemes. Some had steering tillers instead of wheels. There were throttle levers on the steering column on many vehicles. A Model T Ford has three pedals, two of which control the transmission. By the 1940s, things had settled down into something close to the current arrangement, but automatic transmission quadrants were not standardized until Congress stepped in. (GM had P-N-D-S-L-R, Ford and Chrysler had P-R-N-D-S-L). Standardization occured long after any relevant patents would have run out.
There are fewer places to hang out. Record stores and video rental stores are gone. Indoor malls are on the way out. Fast food places discourage hanging out. Starbucks are popular places to hang out, but just can't handle many people. Few nightclubs allow teens. Where to go?
I'm in Silicon Valley, and I get to see a few views of this. Downtown Redwood City (a mostly lower middle class town), sort of by accident, ended up being a teen hangout zone. Years of attempts to "revitalize downtown" actually worked. A 20-screen theater, a lot of cheap restaurants (pizza, yogurt, burgers, etc.) and a refurbished live theater, often used by cover bands, finally brought people downtown. There's also a big plaza in front of the former courthouse, where free movies or bands are shown on warm nights. It took years to get going, there were empty storefronts for years, and it seemed to be a boondoggle project, but now it's happening. But it was never intended to enrich the lives of teenagers. It was intended to enrich retailers and property owners.
There's another side to this. Being a teenager in a high-achieving area like Silicon Valley means being run ragged with school, homework, and semi-mandatory activities needed to build up the resume to get into a good college. As a horse owner, I see a lot of kids like that, and many are just overworked. I once asked a group of girls at the Stanford barn who were discussing grades what they considered an acceptable GPA. One answered, in a bleak voice, "4.5." These are kids who will be considered a failure if they don't get into a school at the Stanford/Harvard/Yale level. Those kids are on a treadmill from their first day of preschool.
As an amusing note, one thing horse kids have going for them is good situational awareness. They're used to being aware of what's going on around them, because that's required on or around horses. (Riding in a busy ring with different people and horses doing different things without getting in each others way is a basic skill.) They all have smartphones, but aren't glued to them.
The original MacOS had it right - there was no command line at all, at any level. The mechanism for manipulating the system at a low level was ResEdit, a tool for editing the resource fork of files. It was a GUI tool, not a command line. If you wanted to set the color of something, you used a color picker; you didn't write RGB in hex.
This was an effective way to do the job.
Unfortunately, the original MacOS sucked as an OS - no processes, no threads, no memory protection. The designers had to do that to cram it into 128K of RAM, but it didn't scale. On top of that, the Mac's "Resource Manager", which was really a little database system, was an unstable database. A crash while the resource fork was open for writing usually resulted in a corrupted resource fork. This gave the resource fork approach a bad reputation. In reality, the problem was that it was designed for floppies, where writes were so slow that keeping the resource fork in sync was too expensive.
Then, when Apple needed Steve Jobs back, they had to buy his NeXt failure for $400M, so they ended up using NeXt's warmed-over BSD/Mach kludge. So they got all the obsolete UNIX command line crap back. They also lost the Mac file system with its resource forks.
In the Linux world, the legacy command line crap is stacked so deep that nothing can be fixed. Many things that should be databases are text files. So there are stil lock files, sending signals to processes to tell them to reread their text file, and similar legacies of the bell-bottom-trousers 1970s.
There's also a pernicious tradition in Linux that GUI tools need not be comprehensive. It's OK to have a GUI tool that doesn't let you do everything you can from the command line. Linux GUI tools tend to be dumbed down, and often don't know what they did - they just display text messages from a lower level in a text box. On the original Mac, that was an absolute no-no. Programs couldn't even use print statements.
There are good arguments for a tax on advertising. Most Americans are "spent out"; they're spending almost everything they earn. The US personal savings rate is near an all-time low of 2%. In that situation, advertising can't create new demand. It's just a war between advertisers. So that's a good place to tax.
Both Fox News and The Washington Post are reporting favorably on Snowden. Congress and the courts are acting on his revelations. He's changed the world a little, probably for the better.
Projection onto streams of water is well known. Here are some examples. It's used to create big-screen effects outdoors, usually for PR purposes. You usually get big, but fuzzy, images, because the water screen isn't flat enough. Huge light levels are required, so it takes expensive projectors.
Indoors, I've seen it done in a doorway, and you could walk through the image, getting slightly wet.
Until somebody figures out how to make a curtain of mist/water/some gas or liquid stay very flat, this isn't going to be more than an advertising gimmick.
There's been an anti-gentrification movement in the Mission for years. In the first dot-com boom, they were putting signs on SUVs found in the area. The photos of the Google bus are on 24th between Mission and Valencia. The building with all the bars at street level is a Christian church. (It was buiit as a synagogue, but they went bust and another brand picked up the space.)
I'm surprised Google employees want to live there. It's not that fun an area. It's a working-class neighborhood with crap schools. The Mission was never that cool. There are some good restaurants; I've eaten at many of them. But that's about it. There are bars, but not much of a club scene.
SOMA used to be cool, because there were lots of big art things and clubs going on in former industrial spaces. SOMA did get gentrified; all the empty industrial spaces have been repurposed or torn down. Tall buildings have replaced many of them. The artists moved out to Emeryville or Oakland or South San Francisco, or even the Richmond shipyard, where space is cheaper.
The comment was modded up, and then, after about two hours, modded down. This happens so consistently with criticism of Apple products that it's probably orchestrated. Is there a crawler somewhere looking for criticism of Apple?
Re:But Node.JS IS WEBSCALE
on
Is Ruby Dying?
·
· Score: 3, Interesting
But it's web scale.
The event/callback/state machine model is a pain to program in, but at least you don't have race conditions on shared data. Also, now that most Javascript programmers are aware that the language supports closures, callbacks aren't so hard to code properly.
The classic problem with threads is that the usual locking primitives (which are almost always variants on the POSIX primitives) are treated as an OS object, rather than part of the language. For most languages, the language has no idea of which locks lock what data. Ada gets this right, but the Ada rendezvous is clunky. Even Go gets this wrong. (See the endless discussions of "is this a race condition?" in the Go newsgroup.) So race conditions are common in threaded software, and a cause of random failures.
Practical problems with threads include crappy implementations of lock primitives that make a system call even in the non-blocking case, the cost of fencing on superscalar CPUs, and poor scheduler coordination between context switching and message passing.
Most of those issues are way too theoretical for the average web programmer. It's better that they not have to think about them. There's a lot of web code to be written and we don't want to waste the good people on it.
I was given $3000 to spend on a desktop Mac, I'd be hard-pressed to pick the entry-level Mac Pro instead of a 27-inch iMac with 3.5GHz quad-core Intel Core i7 processor, 32GB of RAM, a 3TB Fusion Drive, and an Nvidia GeForce GTX 780M GPU.
Unimpressive specs for the price.
I'm writing this on a 3.2GHz 4-core Intel i5-4570 CPU, with an Nvidia GeForce GT 640. Running Linux. Cost under $1000. I could have ordered a machine with the components Apple is installing for a few hundred more. The CPU upgrade would cost $116 and the GPU upgrade about $225. The GTX 780M isn't even NVidia's top-of-the-line GPU; that's a mobile (for laptops) part, three or four steps down from the top of the line.
Tube computers seldom had tubes fail in operation. Part of daily maintenance was to run the machine on "high margins", with voltages raised about 10%. Half an hour on in that mode would blow out all the tubes near failure. Those were then replaced, and the machine would then operate for the rest of the day without problems. A tech who had worked on UNIVAC I computers once told me they'd never had a tube failure during regular operation.
Some of the the AN/FSQ-7 consoles keep showing up in movies because they're available for rental at Woody's Props in LA.
Those aren't even the control panels for the computer. Those are just the modems and serial ports. Here are the much larger AN/FSQ-7 maintenance control panels.
Those are just the control panels. Here's the CPU, with all the racks of tubes. Full-sized 12AX7 tubes (still used in some guitar amps), not even minature tubes.
During periods of heavy trading, Mt. Gox trade data has repeatedly been observed to be unrealistic. Sometimes it gets very strange. During heavy trading periods, trades are often done out of order. Delays up to 46 minutes have been reported.
Whether this is incompetence or market manipulation has never been entirely clear.
(Despite all the hype, Bitcoin transaction volume is not large. Most exchanges do a few transactions per minute.)
Most of the discussion so far has been rather lame. But there's detailed video of everything. Not that silly feed for the general public, but the detail videos. For each event, there's video from four cameras - three watching the robot, and one watching the operators, presented as a four-quadrant image. That's all on line, unedited, 9 hours a day from each camera, no audio. In there, you can see what's really happening.
Most of the time, the robots are being teleoperated. DARPA introduced substantial lag (100ms during "good comms" periods, 1 second during "bad comms" periods, alternating once a minute) and bandwidth limits (1,000,000 bps each direction during "good comms" periods, 100,000 bps during "bad comms" periods.) This was to prevent excessive teleoperation and encourage autonomy. What they mostly got was really slow teleoperation. Event time limits were very generous and scoring wasn't time based. Many of the events were dumbed down from the original specs. DARPA wanted some successes.
Watch the debris removal task by Team Schaft starting at 02:33:00. That's one of the better runs. It's really slow, but the operator isn't constantly teleoperating. Once in a while the operator pushes a button. Some other teams used game controllers.
A wheelbarrow is a specialized tool, for moving loose material a short distance and then pouring it out. For most other applications, a wagon, hand truck, or dolly is more useful. There's also the Gardenway cart, which has two large wheels on an axle slightly forward of the center. It's dumpable, but less work to move. Horse barns usually have a few of those around.
Modern wheelbarrows have the single wheel much closer to the CG, so you're only lifting a fraction of the weight. You want some weight on the handles, because you're providing roll stability.
But will it be cheaper or more expensive than using a credit card?
Accepting Bitcoins is surprisingly expensive. There's a volatility risk, and for a currency that can change by 10% in minutes, that's a real problem. Coinbase (which is a dealer, rather than an exchange) has a posted buying price, good for one minute, and some shopping cart systems use that. But that price is usually lower than the prices on the major exchanges; there's a conversion cost. So, as with retail money-changers, you pay a conversion fee. Also, like most money-changers, Coinbase will briefly stop buying during periods of high volatility or if they have trouble unloading their Bitcoins.
Then, of course, there's prying the money out of the Bitcoin broker or exchange. Overstock is probably in a strong enough position to demand a daily sweep into a real bank account, with serious penalties for failure to deliver.
If you look at the few Bitcoin-accepting businesses that sell real products with typical mail order retail markups, the Bitcoin price is usually significantly higher than the US$ price. Most of the stores that currently accept Bitcoin are selling T-shirts, posters, remaindered goods, and similar crap. Of course, that's what Overstock does, so it may be a good fit.
This is an earth-pressure-balance type TBM built for soft sand and dirt, below water level. Compressed air is used to keep water out at the working face. That's what's needed for a tunnel under the Seattle waterfront. It can cope with rocks and boulders, but not a solid rock face. It's not a hard-rock TBM. Those have very different cutters, but can't handle waterlogged soil.
Tunneling is like that. Stuff like this happens. It will be handled.
What this seems to do is take control away from the user, who could swap SIM cards, and give it to some carrier.
When you say "seems to," do you really mean "could possibly some day"?
No, I mean that's what the documentation seems to say. The user can't swap SIM cards when there is no removable SIM card. It has to be done remotely. From the documentation, it seems that the carrier has the keys to do that, but the user does not. Some devices start out in "provisioning mode", from which point (I think) the first carrier to talk to the device downloads a profiile and has control of the device until they release it. Or the device might come pre-locked to a carrier. Whether the user can force the device back to provisioning mode seems to be under the control of the profile downloaded by the carrier.
it's a lot like the way domain transfer works between registrars, with the "domain locked" status being under the control of the "losing registrar". That's led to disputes.
To fix this issue, the GSMA has developed a non-removable SIM that can be embedded in a device for the duration of its life, and remotely assigned to a network. This information can be subsequently modified over-the-air, as many times as necessary.
What this seems to do is take control away from the user, who could swap SIM cards, and give it to some carrier. This looks like something where you beg and plead with your old carrier to let you switch your device to a new carrier. There's a lot of elaborate key management in this system, and compromise of certain keys could break the whole system.
Heard this one before. On Slashdot, even. Yes, you can do it. No, you don't want to. Remember when LCDs came with a few dead pixels? There used to be a market for DRAM with bad bits for phone answering machines and buffers in low-end CD players. That's essentially over.
Working around bad bits in storage devices is common; just about everything has error correction now. For applications where error correction is feasible, this works. Outside that area, there's some gain in cost and power consumption in exchange for a big gain in headaches.
Slashdot Mirror
If we had the same crazy patent environment when cars were being developed, every car would have a different way to control it.
Early cars did have all sorts of control schemes. Some had steering tillers instead of wheels. There were throttle levers on the steering column on many vehicles. A Model T Ford has three pedals, two of which control the transmission. By the 1940s, things had settled down into something close to the current arrangement, but automatic transmission quadrants were not standardized until Congress stepped in. (GM had P-N-D-S-L-R, Ford and Chrysler had P-R-N-D-S-L). Standardization occured long after any relevant patents would have run out.
There are fewer places to hang out. Record stores and video rental stores are gone. Indoor malls are on the way out. Fast food places discourage hanging out. Starbucks are popular places to hang out, but just can't handle many people. Few nightclubs allow teens. Where to go?
I'm in Silicon Valley, and I get to see a few views of this. Downtown Redwood City (a mostly lower middle class town), sort of by accident, ended up being a teen hangout zone. Years of attempts to "revitalize downtown" actually worked. A 20-screen theater, a lot of cheap restaurants (pizza, yogurt, burgers, etc.) and a refurbished live theater, often used by cover bands, finally brought people downtown. There's also a big plaza in front of the former courthouse, where free movies or bands are shown on warm nights. It took years to get going, there were empty storefronts for years, and it seemed to be a boondoggle project, but now it's happening. But it was never intended to enrich the lives of teenagers. It was intended to enrich retailers and property owners.
There's another side to this. Being a teenager in a high-achieving area like Silicon Valley means being run ragged with school, homework, and semi-mandatory activities needed to build up the resume to get into a good college. As a horse owner, I see a lot of kids like that, and many are just overworked. I once asked a group of girls at the Stanford barn who were discussing grades what they considered an acceptable GPA. One answered, in a bleak voice, "4.5." These are kids who will be considered a failure if they don't get into a school at the Stanford/Harvard/Yale level. Those kids are on a treadmill from their first day of preschool.
As an amusing note, one thing horse kids have going for them is good situational awareness. They're used to being aware of what's going on around them, because that's required on or around horses. (Riding in a busy ring with different people and horses doing different things without getting in each others way is a basic skill.) They all have smartphones, but aren't glued to them.
The original MacOS had it right - there was no command line at all, at any level. The mechanism for manipulating the system at a low level was ResEdit, a tool for editing the resource fork of files. It was a GUI tool, not a command line. If you wanted to set the color of something, you used a color picker; you didn't write RGB in hex. This was an effective way to do the job.
Unfortunately, the original MacOS sucked as an OS - no processes, no threads, no memory protection. The designers had to do that to cram it into 128K of RAM, but it didn't scale. On top of that, the Mac's "Resource Manager", which was really a little database system, was an unstable database. A crash while the resource fork was open for writing usually resulted in a corrupted resource fork. This gave the resource fork approach a bad reputation. In reality, the problem was that it was designed for floppies, where writes were so slow that keeping the resource fork in sync was too expensive.
Then, when Apple needed Steve Jobs back, they had to buy his NeXt failure for $400M, so they ended up using NeXt's warmed-over BSD/Mach kludge. So they got all the obsolete UNIX command line crap back. They also lost the Mac file system with its resource forks.
In the Linux world, the legacy command line crap is stacked so deep that nothing can be fixed. Many things that should be databases are text files. So there are stil lock files, sending signals to processes to tell them to reread their text file, and similar legacies of the bell-bottom-trousers 1970s.
There's also a pernicious tradition in Linux that GUI tools need not be comprehensive. It's OK to have a GUI tool that doesn't let you do everything you can from the command line. Linux GUI tools tend to be dumbed down, and often don't know what they did - they just display text messages from a lower level in a text box. On the original Mac, that was an absolute no-no. Programs couldn't even use print statements.
The House Ways and Means Committee is considering making advertising non-deductable as a business expense. That would take a bite out of Google.
There are good arguments for a tax on advertising. Most Americans are "spent out"; they're spending almost everything they earn. The US personal savings rate is near an all-time low of 2%. In that situation, advertising can't create new demand. It's just a war between advertisers. So that's a good place to tax.
What fraction of the increase was ads?
In Capitalist America, book reads you!
Both Fox News and The Washington Post are reporting favorably on Snowden. Congress and the courts are acting on his revelations. He's changed the world a little, probably for the better.
Projection onto streams of water is well known. Here are some examples. It's used to create big-screen effects outdoors, usually for PR purposes. You usually get big, but fuzzy, images, because the water screen isn't flat enough. Huge light levels are required, so it takes expensive projectors. Indoors, I've seen it done in a doorway, and you could walk through the image, getting slightly wet.
Until somebody figures out how to make a curtain of mist/water/some gas or liquid stay very flat, this isn't going to be more than an advertising gimmick.
There's been an anti-gentrification movement in the Mission for years. In the first dot-com boom, they were putting signs on SUVs found in the area. The photos of the Google bus are on 24th between Mission and Valencia. The building with all the bars at street level is a Christian church. (It was buiit as a synagogue, but they went bust and another brand picked up the space.)
I'm surprised Google employees want to live there. It's not that fun an area. It's a working-class neighborhood with crap schools. The Mission was never that cool. There are some good restaurants; I've eaten at many of them. But that's about it. There are bars, but not much of a club scene.
SOMA used to be cool, because there were lots of big art things and clubs going on in former industrial spaces. SOMA did get gentrified; all the empty industrial spaces have been repurposed or torn down. Tall buildings have replaced many of them. The artists moved out to Emeryville or Oakland or South San Francisco, or even the Richmond shipyard, where space is cheaper.
The comment was modded up, and then, after about two hours, modded down. This happens so consistently with criticism of Apple products that it's probably orchestrated. Is there a crawler somewhere looking for criticism of Apple?
But it's web scale.
The event/callback/state machine model is a pain to program in, but at least you don't have race conditions on shared data. Also, now that most Javascript programmers are aware that the language supports closures, callbacks aren't so hard to code properly.
The classic problem with threads is that the usual locking primitives (which are almost always variants on the POSIX primitives) are treated as an OS object, rather than part of the language. For most languages, the language has no idea of which locks lock what data. Ada gets this right, but the Ada rendezvous is clunky. Even Go gets this wrong. (See the endless discussions of "is this a race condition?" in the Go newsgroup.) So race conditions are common in threaded software, and a cause of random failures.
Practical problems with threads include crappy implementations of lock primitives that make a system call even in the non-blocking case, the cost of fencing on superscalar CPUs, and poor scheduler coordination between context switching and message passing.
Most of those issues are way too theoretical for the average web programmer. It's better that they not have to think about them. There's a lot of web code to be written and we don't want to waste the good people on it.
I was given $3000 to spend on a desktop Mac, I'd be hard-pressed to pick the entry-level Mac Pro instead of a 27-inch iMac with 3.5GHz quad-core Intel Core i7 processor, 32GB of RAM, a 3TB Fusion Drive, and an Nvidia GeForce GTX 780M GPU.
Unimpressive specs for the price. I'm writing this on a 3.2GHz 4-core Intel i5-4570 CPU, with an Nvidia GeForce GT 640. Running Linux. Cost under $1000. I could have ordered a machine with the components Apple is installing for a few hundred more. The CPU upgrade would cost $116 and the GPU upgrade about $225. The GTX 780M isn't even NVidia's top-of-the-line GPU; that's a mobile (for laptops) part, three or four steps down from the top of the line.
Tube computers seldom had tubes fail in operation. Part of daily maintenance was to run the machine on "high margins", with voltages raised about 10%. Half an hour on in that mode would blow out all the tubes near failure. Those were then replaced, and the machine would then operate for the rest of the day without problems. A tech who had worked on UNIVAC I computers once told me they'd never had a tube failure during regular operation.
Some of the the AN/FSQ-7 consoles keep showing up in movies because they're available for rental at Woody's Props in LA.
Those aren't even the control panels for the computer. Those are just the modems and serial ports. Here are the much larger AN/FSQ-7 maintenance control panels.
Those are just the control panels. Here's the CPU, with all the racks of tubes. Full-sized 12AX7 tubes (still used in some guitar amps), not even minature tubes.
During periods of heavy trading, Mt. Gox trade data has repeatedly been observed to be unrealistic. Sometimes it gets very strange. During heavy trading periods, trades are often done out of order. Delays up to 46 minutes have been reported. Whether this is incompetence or market manipulation has never been entirely clear.
(Despite all the hype, Bitcoin transaction volume is not large. Most exchanges do a few transactions per minute.)
Most of the discussion so far has been rather lame. But there's detailed video of everything. Not that silly feed for the general public, but the detail videos. For each event, there's video from four cameras - three watching the robot, and one watching the operators, presented as a four-quadrant image. That's all on line, unedited, 9 hours a day from each camera, no audio. In there, you can see what's really happening.
Most of the time, the robots are being teleoperated. DARPA introduced substantial lag (100ms during "good comms" periods, 1 second during "bad comms" periods, alternating once a minute) and bandwidth limits (1,000,000 bps each direction during "good comms" periods, 100,000 bps during "bad comms" periods.) This was to prevent excessive teleoperation and encourage autonomy. What they mostly got was really slow teleoperation. Event time limits were very generous and scoring wasn't time based. Many of the events were dumbed down from the original specs. DARPA wanted some successes.
Watch the debris removal task by Team Schaft starting at 02:33:00. That's one of the better runs. It's really slow, but the operator isn't constantly teleoperating. Once in a while the operator pushes a button. Some other teams used game controllers.
A wheelbarrow is a specialized tool, for moving loose material a short distance and then pouring it out. For most other applications, a wagon, hand truck, or dolly is more useful. There's also the Gardenway cart, which has two large wheels on an axle slightly forward of the center. It's dumpable, but less work to move. Horse barns usually have a few of those around.
Modern wheelbarrows have the single wheel much closer to the CG, so you're only lifting a fraction of the weight. You want some weight on the handles, because you're providing roll stability.
But will it be cheaper or more expensive than using a credit card?
Accepting Bitcoins is surprisingly expensive. There's a volatility risk, and for a currency that can change by 10% in minutes, that's a real problem. Coinbase (which is a dealer, rather than an exchange) has a posted buying price, good for one minute, and some shopping cart systems use that. But that price is usually lower than the prices on the major exchanges; there's a conversion cost. So, as with retail money-changers, you pay a conversion fee. Also, like most money-changers, Coinbase will briefly stop buying during periods of high volatility or if they have trouble unloading their Bitcoins.
Then, of course, there's prying the money out of the Bitcoin broker or exchange. Overstock is probably in a strong enough position to demand a daily sweep into a real bank account, with serious penalties for failure to deliver.
If you look at the few Bitcoin-accepting businesses that sell real products with typical mail order retail markups, the Bitcoin price is usually significantly higher than the US$ price. Most of the stores that currently accept Bitcoin are selling T-shirts, posters, remaindered goods, and similar crap. Of course, that's what Overstock does, so it may be a good fit.
See above. But here's the link again: GSM Association Official Document 12FAST.13 - Embedded SIM Remote Provisioning Architecture.
This is an earth-pressure-balance type TBM built for soft sand and dirt, below water level. Compressed air is used to keep water out at the working face. That's what's needed for a tunnel under the Seattle waterfront. It can cope with rocks and boulders, but not a solid rock face. It's not a hard-rock TBM. Those have very different cutters, but can't handle waterlogged soil.
Tunneling is like that. Stuff like this happens. It will be handled.
What this seems to do is take control away from the user, who could swap SIM cards, and give it to some carrier.
When you say "seems to," do you really mean "could possibly some day"?
No, I mean that's what the documentation seems to say. The user can't swap SIM cards when there is no removable SIM card. It has to be done remotely. From the documentation, it seems that the carrier has the keys to do that, but the user does not. Some devices start out in "provisioning mode", from which point (I think) the first carrier to talk to the device downloads a profiile and has control of the device until they release it. Or the device might come pre-locked to a carrier. Whether the user can force the device back to provisioning mode seems to be under the control of the profile downloaded by the carrier.
it's a lot like the way domain transfer works between registrars, with the "domain locked" status being under the control of the "losing registrar". That's led to disputes.
Who tells whom what to do? - V. Lenin
To fix this issue, the GSMA has developed a non-removable SIM that can be embedded in a device for the duration of its life, and remotely assigned to a network. This information can be subsequently modified over-the-air, as many times as necessary.
What this seems to do is take control away from the user, who could swap SIM cards, and give it to some carrier. This looks like something where you beg and plead with your old carrier to let you switch your device to a new carrier. There's a lot of elaborate key management in this system, and compromise of certain keys could break the whole system.
Spec for the system architecture.
People who use an OpenMoko will love this.
There's something to be said for what the FSF is trying to do. The problem is that they're too slow in doing it.
Heard this one before. On Slashdot, even. Yes, you can do it. No, you don't want to. Remember when LCDs came with a few dead pixels? There used to be a market for DRAM with bad bits for phone answering machines and buffers in low-end CD players. That's essentially over.
Working around bad bits in storage devices is common; just about everything has error correction now. For applications where error correction is feasible, this works. Outside that area, there's some gain in cost and power consumption in exchange for a big gain in headaches.
Bitcoin has a legitimate purpose; a truly portable store of value
As a store of value, Bitcoin has trouble holding its value for a week. Some days, hours. This limits its usefulness for transactions.