A stereo headset can't be used to communicate with one's phone when driving. At least in my state, it's illegal to wear an audio device covering both ears while operating a motor vehicle; and I can't see it being good practice anywhere.
They don't have to open source it. They need to stop requiring that it be downloaded directly from their servers and that the user view and affirmatively accept the license for every installation.
I haven't heard Fox News repeat any claim that they're accurate. They just claim that they're "fair and balanced" -- which has nothing at all to do with accuracy.
There's a very distinct difference between changing the respect given to the value of some peoples' lives, and changing the value assigned to all peoples' lives. The latter is considerably more equitable.
Hey -- how was I supposed to get the editors' attention without some offtopic comment? When in Rome, and all that.
(More seriously, though... how big of an advantage being an ISO standard is to OpenDocument in terms of adoption is likely to vary with whether OpenXML ends up being ratified as well).
Not everyone who's religious (or who studies religion) is a raving lunatic intent on making the rest of the world do things their way Because God Said So; it's just that set which makes the press, generates the noise, and results in bad laws and worse politicians being foisted off on everyone else.
Characterizing a scholarly society revolving around the study, analysis, archival and dissemination of historical documents as a group of "nutters", without any evidence other than the area of study those documents correspond to... well, it's certainly inappropriate. Religion is an entirely legitimate field of study, even should you consider it bogus in every other way.
If you'd had enough opportunities to work with binary formats built for custom, one-off, non-source available parsers and XML-based formats and tools for manipulating them, I think you'd have changed that opinion by now. XML makes interoperability work much, much easier -- and is vastly more readable than the bit-packing one-off formats people come up with otherwise.
Having a structure which can be used to build unambiguously parsable data data formats is a Good Thing. Having some level of self-documentation properties on top of that is icing on the cake.
I work for a company making software for the healthcare industry -- a startup which for a long time didn't offer insurance but started doing so recently.
The cash prices might be high -- but they're negotiable, if you know how. Our CEO is an emergency room surgeon; before the company offered medical insurance, he'd call up places his employees owed money to and talk them down substantially. My single emergency room stay during this time period (after a motorcycle accident) cost me $700 post-negotiation -- less than what I pay for two months of insurance before taking copays into account.
I'm still glad to have the insurance, as it avoids some truly nasty worst-case scenarios -- but cash customers don't actually need to pay the full cash customer pricing.
And most Americans would come down on the side of the value of human life.
It's a shame this isn't an item that varies on a state-by-state basis, such that those who disagree with the prevailing position can move somewhere where the consequences of that decision (economic and otherwise) aren't forced on them.
Yes, the kernel developers don't like binary modules. Yes, they require that such drivers only link to a limited set of symbols. Yes, Intel's(?) proposal to create a standard ABI has been turned down. Nonetheless, so long as those rules are followed, they're explictly allowed.
(None of this is news -- I used to work at an embedded development house with an engineering team composed primarily of kernel developers)
When I first started programming, I came into a company as a full-time "apprentice" programmer. I made *barely* 20k per year, but I was learning under incredible people. It was invaluable.
Similar situation here. I was an "intern" -- but did the work of a full engineer and was employed year-round (though only half-time during the school year). The people I worked with, though, were top of their art, and included folks who maintained major ports of the Linux kernel; core toolchain (gcc+glibc) people and the like. Without any question, that job (and the people there who took me under their wings) shaped the rest of my career.
As for humility: I'd grown somewhat cocky at college. Working with the people I did brought me down to size -- not because of any belittling on their parts, but simply because working with them, it became obvious how much I didn't know. I'd argue that exposure, more than pre-existing humility, is the key ingrediant.
Heh. That's... interesting. You seriously suggest that if I were to cut my hair, this would somehow stop me from working late? Experience suggests otherwise: Back when I had short hair and shaved regularly, I worked longer hours than I do now (13-hour days with the occasional all-nighter rather than 9-hour ones).
I'm a geek. I'm scruffy. I'm also one of the top three members of technical staff at the company where I work, and am well respected for such -- when I tried to resign, the CEO himself scheduled a meeting to talk me out of it. I do in fact feel good about myself. I work out in the early morning 6 days a week (a fairly recent lifestyle change), and will be hiking to Guadalupe Peak with my wife this fall. I don't drink soda, and have barely touched coffee for years. I avoid even pharmaceutical drugs when I can help it.
Instead of feeling good about myself because of how I look, I feel good about myself on account of the respect others give me -- respect I've earned without such empty, shallow measures as changing what I wear, but instead by being consistently competent, helpful, resourceful and personally involved. Now, where in your stereotypes do I fit in?
For purposes of the Linux kernel, it doesn't matter what the FSF says; it matters what the copyright holder says. Linus says binary kernel modules are allowed. Linus is the relevant copyright holder (kind of -- but the other folks who contribute do so knowing of the exception, and thus consent). If you have explicit permission from the copyright holder, that's your license to create binary-only kernel modules. There; done; non-issue.
I don't see any of your other arguments, clearly portrayed, which really hold water for common-case scenarios. Remember that there are very big companies with very well-paid lawyers who build software for Linux; the analysis has been done by people more competant than you or I.
Well, yes, for some value of sufficiency. A collection of high-level knowledge may well work in most cases -- but strictly most, and certainly not all; and it's certainly not right to try to foster only that limited level of understanding.
Some of my motivation here is personal: I have the most fun when I'm working with a team of people almost universally better than me. My first job for a Real Software Company (MontaVista Software, an embedded Linux shop, back when they still had Paul Mundt, Mike Taht and some of their other really-damn-good staff members who've since moved on... which is not to say they don't still have good people, since they do) was like that. Since then, I've worked with a lot of programmers best described as mediocre, a few specialists who know their single subfield better than 99% of others who practice it -- and a number of skilled top-to-bottom generalists I can count on one hand, despite being in a location with a tech economy second (within the US) only to the Bay Area. (By way of being fair: There are a lot of things within my repertoire which I'm only mediocre at myself. I only mean to be harsh towards people who are mediocre at the one or two things that they do and don't do anything else).
Every company has a certain amount of need for folks with a broad-range skillset -- and working at a place with a need for more, I have a bird's-eye view of just how hard it is to find such people. Consequently, to the extent that the educational system or the guidance offered by folks already in the field can be used to encourage those who are learning to understand the nuts and bolts, such should absolutely be done! Our level of competitiveness on a national level is at least in some way weighted on how good our average developer or sysadmin is; if we can bring up that average, everyone benefits.
Without an easy-to-learn language like BASIC where do you begin to teach the fundamentals of programming? The syntax, class structure, includes, etc of modern object-oriented programming languages are a huge barrier to picking up the basics.
I taught an after-school class on programming with Python to a set of middle-school students for a while, and the biggest issue we ran into was that (not having taken algebra yet) most of them didn't have a mindset for thinking about algorithms. If I try teaching again, I'm going to be prepared to focus more closely on that point.
Syntax? Python's syntax stays out of the way, and you don't need to use classes or other OO features until you're ready to start using them -- and when you do start using them, they're consistent with the rest of the language's syntax.
Python is a Very Good Thing in this context: An extremely powerful language which can be taught (and learned) incrementally; which can be experimented with at the interpreter (making for lab sessions where everyone can follow along on a line-by-line basis through the simple things); and which was designed with simplicity and readability in mind.
Here's the problem with only learning to program on top of tools other people made: When the abstractions leak, you don't know enough about what's going on under-the-hood to resolve it.
Understanding how dynamic linking works; understanding what syscalls are, which ones there are and how they operate; understanding how virtual memory is implemented at a hardware level; understanding the processor as something other than a black box -- all of these are necessary if you're going to be the dude who comes in when the high-level-only programmers have a problem they can't solve because their tools have a subtle bug or a conflict with some aspect of their environment. If you're going to be making architectural-level decisions, it also helps to know how various high-level things work -- which mechanisms different revision control systems use for representing and manipulating history; how video codecs handle seeking; and so forth. This kind of knowledge is useful so that ideas which are used in one area (say, video codecs) can be reapplied to another (say, maintaining support for fast seeking in large, mutable text buffers).
Having the versatility implicit in knowing how the low-level stuff works as well as the high-level bits makes for more variety, prestige and job security than one would otherwise have.
I thought it had been shown pretty clearly that all it is is a way of moving more of the tax burden onto the middle class.
References? It's fine and well for you to allege such a thing, but I'm interested to see if you can come up with a demonstration of such which hasn't in fact been refuted.
I'm very much middle class, and it would certainly reduce my tax burden -- and my headaches. Even if it increased my tax burden by $1000/yr, though, I'd be willing to pay that to be rid of the IRS and all the reporting requirements associated with the taxes presently levied on individuals.
Remember your post when Dell rolls out $150 desktops.
If it's far enough in the future that the relevant economics have changed -- or if Dell is using providers other than Microsoft and Intel for the relevant parts -- I'll be able to remember my post smugly.
The Dell system includes support, a monitor, faster chip, bigger hard drive and windows. Strip all that stuff down to the China spec and you are near $150.
Sure, Dell could make a system at the Chinese spec for not too much more than the Chinese company does... but the Chinese company can build a system at the Chinese spec and actually expect to turn enough of a profit off it to sustain their business with that system as their key product. That's a pretty big difference. Also, Dell's fixed costs (as they'd be paying for a custom chip developed with R&D at American rates rather than Chinese ones) would be huge.
Also, the 6% margin doesn't apply to every product, just to the company overall.
That's true -- but the lowest end of the market is already going to have the smallest margins. If a product makes back its marginal cost (buying the components and paying any additional payroll costs which can be attributed to assembly, QA and sale of the individual machine) but not its share of fixed costs (paying for product development and testing, accounting, advertising, and all the other stuff that the company has to do if it wants to roll out another product without regard to exactly how many units of that product they sell), it's a money-losing proposition even though each individual machine may turn a profit.
Now, what would you contend that Dell's marginal profit on a per-machine basis is? A lot more than 6.5%, right? That means that the fixed costs are sufficient to bring Dell's overall profit down from the much higher marginal value to only 6.5% after paying said costs -- so they're too high to trivialize away.
A company based in China has not only lower marginal costs but also much lower fixed costs, as what they're paying for land and labor (including the accountants, the advertisers, the marketers, etc) is far, far lower; consequently, they have much less by way of fixed costs that any profitable product needs to make up for. Dell may have economies of scale on their side -- but the differences between costs when even the fixed-cost component of one's expenses are paid at a Chinese scale is almost certainly sufficient to put them at a disadvantage in this market. (That is: If Dell dumped Windows and started selling something at a similar spec in China, expect the Municator's selling price to drop below what they could match).
The driver's license has to be shown to correspond with the individual holding it. That is to say: To perform its essential function (proving that the individual who holds it has met the legal requirements to be able to drive), it doesn't need to demonstrate who the individual is; rather, it needs to demonstrate that the individual is the same as the individual to whom it was issued, and that it was legitimately issued. Using biometrics and digital signatures, one can easily create a driver's license which proves those things without proving the identity of its holder.
Same thing goes for age requirements. There's no need to show who someone is; rather, there's a need to show their age, and that the card is legitimately issued and theirs. No need for a global identifier here either.
Credit checks are a somewhat different issue -- but there's no reason that an individual's credit history has to be linked to an identifier used for anything other than financial purposes, or that said identifier needs to be issued by the government. Using a set of separate identifiers, further, is already done by the responsible companies: Try retrieving your own credit report with/just/ your SSN via channels intended for consumers to use for said purposes.
The income tax is a bad idea anyhow. The FairTax would make them unnecessary, prevent folks from cheating on their taxes (because individuals don't file taxes!), still allow for a sliding effective tax rate, and otherwise be a Good Thing.
I'm not necessarily arguing for an identifier-free society -- but your arguments against one don't hold water. Given appropriate application of technology, the minimum necessary amounts of information can be provided when appropriate without reference to massive central databases.
If Dell can market a PC for $300 retail to the US with all that crap, I'm sure they can market a similar system for $150 to China that doesn't suck so hard. Order a couple thousand and Dell starts knocking down the price, especially if you take out the support contracts and the windows price.
The $300 retail PC already doesn't have much of a margin on it. The substantial per-unit profits are on the high end of the market, not the low. Remember, the goal isn't to make something that can be manufactured for $150; rather, it's to make something which can be sold for $150, making back both fixed and marginal costs. From that perspective, using Microsoft and Intel is a losing proposition.
Dell's overall net profit margin is 6.4% -- and that's for their entire business, including the higher end of the market. Expecting them to be able to cut the cost of their bottom-end systems by 50% (or even 20%) and still turn a profit on those systems is ludicrous.
You're forgetting the target audience. To compensate, let's do a thought experiment: Scale the prices up.
Let's say that right now the cheapest PC you could get were $3000 (akin to the Dell $300 box), and a really good one cost $30,000 (think your $3K gaming box). Making a crappy machine for $1500 means that there are a whole bunch of folks would couldn't possibly afford a new computer who now can.
Remember, these things aren't targeted at the US market, and aren't targeted at people who can afford current prices.
You simply will not get the same type of experience if it's interactive all the time, and being interactive constantly should not always be the highest goal for a game to have.
Well, wait a moment.
One can have the player's character scripted to talk with someone else on the radio, speaking a precanned conversation, without removing the player's control of his character for the duration of that conversation. Keeping the player in control doesn't mean requiring the player to control everything down to the PC's speech in discussion with NPCs (though allowing the conversation to be directed is nice -- and movement through the plot can be dependent on following the conversation tree until it hits one of a few particular paths). (Supporting multiple paths is a Good Thing, though: One of the best things about Deus Ex was how the player had a number of places where there were several substantially different approaches which could be taken to achieve goals, which would have effects for the rest of the game -- for instance, one could go the obvious path and let a friendly NPC die, or a less obvious route and have that NPC around later in the game; or one could engage in a direct assault and gain a reputation for being bloodthirsty which followed the player around later on, or take a covert approach and gain a reputation to the contrary. Supporting this is hard enough without having to have multiple versions of big, long, prerendered cutscenes, though). Having a short cutscene while the other party in a user-directed conversation talks is a reasonable approach. Requiring big long cutscenes before the plot is compelling... not so good.
And until games start having sophisticated linguistic and other communication involved, constant interactivity will always be second rate.
Techniques for allowing the player to direct complex conversations are well-established. Largely they consist of letting the user pick key responses at some point in the conversation (and then providing precanned conversation from there until the next decision large enough to ask for user interaction comes up), but other approaches have been used. Avoiding large cutscenes and leaving the user in control of the PC during discussions (either by directing the flow of conversation or, when appropriate [ie. radio conversations], leaving the player in control of the PC's movement and actions) doesn't imply that it's necessary to remove all precanned communications from the game.
Slashdot Mirror
A stereo headset can't be used to communicate with one's phone when driving. At least in my state, it's illegal to wear an audio device covering both ears while operating a motor vehicle; and I can't see it being good practice anywhere.
At 2.5x less than the market rate for such services, I'll subscribe and then tunnel my traffic via OpenVPN.
I've downloaded GPL software for Windows, and I had to agree to the GPL before installation.
The GPL doesn't require that; the developer of that installer did.
They don't have to open source it. They need to stop requiring that it be downloaded directly from their servers and that the user view and affirmatively accept the license for every installation.
I haven't heard Fox News repeat any claim that they're accurate. They just claim that they're "fair and balanced" -- which has nothing at all to do with accuracy.
There's a very distinct difference between changing the respect given to the value of some peoples' lives, and changing the value assigned to all peoples' lives. The latter is considerably more equitable.
Hey -- how was I supposed to get the editors' attention without some offtopic comment? When in Rome, and all that.
(More seriously, though... how big of an advantage being an ISO standard is to OpenDocument in terms of adoption is likely to vary with whether OpenXML ends up being ratified as well).
Not everyone who's religious (or who studies religion) is a raving lunatic intent on making the rest of the world do things their way Because God Said So; it's just that set which makes the press, generates the noise, and results in bad laws and worse politicians being foisted off on everyone else.
Characterizing a scholarly society revolving around the study, analysis, archival and dissemination of historical documents as a group of "nutters", without any evidence other than the area of study those documents correspond to... well, it's certainly inappropriate. Religion is an entirely legitimate field of study, even should you consider it bogus in every other way.
If you'd had enough opportunities to work with binary formats built for custom, one-off, non-source available parsers and XML-based formats and tools for manipulating them, I think you'd have changed that opinion by now. XML makes interoperability work much, much easier -- and is vastly more readable than the bit-packing one-off formats people come up with otherwise.
Having a structure which can be used to build unambiguously parsable data data formats is a Good Thing. Having some level of self-documentation properties on top of that is icing on the cake.
I work for a company making software for the healthcare industry -- a startup which for a long time didn't offer insurance but started doing so recently.
The cash prices might be high -- but they're negotiable, if you know how. Our CEO is an emergency room surgeon; before the company offered medical insurance, he'd call up places his employees owed money to and talk them down substantially. My single emergency room stay during this time period (after a motorcycle accident) cost me $700 post-negotiation -- less than what I pay for two months of insurance before taking copays into account.
I'm still glad to have the insurance, as it avoids some truly nasty worst-case scenarios -- but cash customers don't actually need to pay the full cash customer pricing.
It's a shame this isn't an item that varies on a state-by-state basis, such that those who disagree with the prevailing position can move somewhere where the consequences of that decision (economic and otherwise) aren't forced on them.
Yes, the kernel developers don't like binary modules. Yes, they require that such drivers only link to a limited set of symbols. Yes, Intel's(?) proposal to create a standard ABI has been turned down. Nonetheless, so long as those rules are followed, they're explictly allowed.
(None of this is news -- I used to work at an embedded development house with an engineering team composed primarily of kernel developers)
When I first started programming, I came into a company as a full-time "apprentice" programmer. I made *barely* 20k per year, but I was learning under incredible people. It was invaluable.
Similar situation here. I was an "intern" -- but did the work of a full engineer and was employed year-round (though only half-time during the school year). The people I worked with, though, were top of their art, and included folks who maintained major ports of the Linux kernel; core toolchain (gcc+glibc) people and the like. Without any question, that job (and the people there who took me under their wings) shaped the rest of my career.
As for humility: I'd grown somewhat cocky at college. Working with the people I did brought me down to size -- not because of any belittling on their parts, but simply because working with them, it became obvious how much I didn't know. I'd argue that exposure, more than pre-existing humility, is the key ingrediant.
Heh. That's... interesting. You seriously suggest that if I were to cut my hair, this would somehow stop me from working late? Experience suggests otherwise: Back when I had short hair and shaved regularly, I worked longer hours than I do now (13-hour days with the occasional all-nighter rather than 9-hour ones).
I'm a geek. I'm scruffy. I'm also one of the top three members of technical staff at the company where I work, and am well respected for such -- when I tried to resign, the CEO himself scheduled a meeting to talk me out of it. I do in fact feel good about myself. I work out in the early morning 6 days a week (a fairly recent lifestyle change), and will be hiking to Guadalupe Peak with my wife this fall. I don't drink soda, and have barely touched coffee for years. I avoid even pharmaceutical drugs when I can help it.
Instead of feeling good about myself because of how I look, I feel good about myself on account of the respect others give me -- respect I've earned without such empty, shallow measures as changing what I wear, but instead by being consistently competent, helpful, resourceful and personally involved. Now, where in your stereotypes do I fit in?
For purposes of the Linux kernel, it doesn't matter what the FSF says; it matters what the copyright holder says. Linus says binary kernel modules are allowed. Linus is the relevant copyright holder (kind of -- but the other folks who contribute do so knowing of the exception, and thus consent). If you have explicit permission from the copyright holder, that's your license to create binary-only kernel modules. There; done; non-issue.
I don't see any of your other arguments, clearly portrayed, which really hold water for common-case scenarios. Remember that there are very big companies with very well-paid lawyers who build software for Linux; the analysis has been done by people more competant than you or I.
Well, yes, for some value of sufficiency. A collection of high-level knowledge may well work in most cases -- but strictly most, and certainly not all; and it's certainly not right to try to foster only that limited level of understanding.
Some of my motivation here is personal: I have the most fun when I'm working with a team of people almost universally better than me. My first job for a Real Software Company (MontaVista Software, an embedded Linux shop, back when they still had Paul Mundt, Mike Taht and some of their other really-damn-good staff members who've since moved on... which is not to say they don't still have good people, since they do) was like that. Since then, I've worked with a lot of programmers best described as mediocre, a few specialists who know their single subfield better than 99% of others who practice it -- and a number of skilled top-to-bottom generalists I can count on one hand, despite being in a location with a tech economy second (within the US) only to the Bay Area. (By way of being fair: There are a lot of things within my repertoire which I'm only mediocre at myself. I only mean to be harsh towards people who are mediocre at the one or two things that they do and don't do anything else).
Every company has a certain amount of need for folks with a broad-range skillset -- and working at a place with a need for more, I have a bird's-eye view of just how hard it is to find such people. Consequently, to the extent that the educational system or the guidance offered by folks already in the field can be used to encourage those who are learning to understand the nuts and bolts, such should absolutely be done! Our level of competitiveness on a national level is at least in some way weighted on how good our average developer or sysadmin is; if we can bring up that average, everyone benefits.
Bad! We need people who understand how wheels work!
I wrote another post on the topic, so I won't repeat myself.
Without an easy-to-learn language like BASIC where do you begin to teach the fundamentals of programming? The syntax, class structure, includes, etc of modern object-oriented programming languages are a huge barrier to picking up the basics.
I taught an after-school class on programming with Python to a set of middle-school students for a while, and the biggest issue we ran into was that (not having taken algebra yet) most of them didn't have a mindset for thinking about algorithms. If I try teaching again, I'm going to be prepared to focus more closely on that point.
Syntax? Python's syntax stays out of the way, and you don't need to use classes or other OO features until you're ready to start using them -- and when you do start using them, they're consistent with the rest of the language's syntax.
Python is a Very Good Thing in this context: An extremely powerful language which can be taught (and learned) incrementally; which can be experimented with at the interpreter (making for lab sessions where everyone can follow along on a line-by-line basis through the simple things); and which was designed with simplicity and readability in mind.
Here's the problem with only learning to program on top of tools other people made: When the abstractions leak, you don't know enough about what's going on under-the-hood to resolve it.
Understanding how dynamic linking works; understanding what syscalls are, which ones there are and how they operate; understanding how virtual memory is implemented at a hardware level; understanding the processor as something other than a black box -- all of these are necessary if you're going to be the dude who comes in when the high-level-only programmers have a problem they can't solve because their tools have a subtle bug or a conflict with some aspect of their environment. If you're going to be making architectural-level decisions, it also helps to know how various high-level things work -- which mechanisms different revision control systems use for representing and manipulating history; how video codecs handle seeking; and so forth. This kind of knowledge is useful so that ideas which are used in one area (say, video codecs) can be reapplied to another (say, maintaining support for fast seeking in large, mutable text buffers).
Having the versatility implicit in knowing how the low-level stuff works as well as the high-level bits makes for more variety, prestige and job security than one would otherwise have.
References? It's fine and well for you to allege such a thing, but I'm interested to see if you can come up with a demonstration of such which hasn't in fact been refuted.
I'm very much middle class, and it would certainly reduce my tax burden -- and my headaches. Even if it increased my tax burden by $1000/yr, though, I'd be willing to pay that to be rid of the IRS and all the reporting requirements associated with the taxes presently levied on individuals.
If it's far enough in the future that the relevant economics have changed -- or if Dell is using providers other than Microsoft and Intel for the relevant parts -- I'll be able to remember my post smugly.
Sure, Dell could make a system at the Chinese spec for not too much more than the Chinese company does... but the Chinese company can build a system at the Chinese spec and actually expect to turn enough of a profit off it to sustain their business with that system as their key product. That's a pretty big difference. Also, Dell's fixed costs (as they'd be paying for a custom chip developed with R&D at American rates rather than Chinese ones) would be huge.
That's true -- but the lowest end of the market is already going to have the smallest margins. If a product makes back its marginal cost (buying the components and paying any additional payroll costs which can be attributed to assembly, QA and sale of the individual machine) but not its share of fixed costs (paying for product development and testing, accounting, advertising, and all the other stuff that the company has to do if it wants to roll out another product without regard to exactly how many units of that product they sell), it's a money-losing proposition even though each individual machine may turn a profit.
Now, what would you contend that Dell's marginal profit on a per-machine basis is? A lot more than 6.5%, right? That means that the fixed costs are sufficient to bring Dell's overall profit down from the much higher marginal value to only 6.5% after paying said costs -- so they're too high to trivialize away.
A company based in China has not only lower marginal costs but also much lower fixed costs, as what they're paying for land and labor (including the accountants, the advertisers, the marketers, etc) is far, far lower; consequently, they have much less by way of fixed costs that any profitable product needs to make up for. Dell may have economies of scale on their side -- but the differences between costs when even the fixed-cost component of one's expenses are paid at a Chinese scale is almost certainly sufficient to put them at a disadvantage in this market. (That is: If Dell dumped Windows and started selling something at a similar spec in China, expect the Municator's selling price to drop below what they could match).
Same thing goes for age requirements. There's no need to show who someone is; rather, there's a need to show their age, and that the card is legitimately issued and theirs. No need for a global identifier here either.
Credit checks are a somewhat different issue -- but there's no reason that an individual's credit history has to be linked to an identifier used for anything other than financial purposes, or that said identifier needs to be issued by the government. Using a set of separate identifiers, further, is already done by the responsible companies: Try retrieving your own credit report with
The income tax is a bad idea anyhow. The FairTax would make them unnecessary, prevent folks from cheating on their taxes (because individuals don't file taxes!), still allow for a sliding effective tax rate, and otherwise be a Good Thing.
I'm not necessarily arguing for an identifier-free society -- but your arguments against one don't hold water. Given appropriate application of technology, the minimum necessary amounts of information can be provided when appropriate without reference to massive central databases.
The $300 retail PC already doesn't have much of a margin on it. The substantial per-unit profits are on the high end of the market, not the low. Remember, the goal isn't to make something that can be manufactured for $150; rather, it's to make something which can be sold for $150, making back both fixed and marginal costs. From that perspective, using Microsoft and Intel is a losing proposition.
Dell's overall net profit margin is 6.4% -- and that's for their entire business, including the higher end of the market. Expecting them to be able to cut the cost of their bottom-end systems by 50% (or even 20%) and still turn a profit on those systems is ludicrous.
You're forgetting the target audience. To compensate, let's do a thought experiment: Scale the prices up.
Let's say that right now the cheapest PC you could get were $3000 (akin to the Dell $300 box), and a really good one cost $30,000 (think your $3K gaming box). Making a crappy machine for $1500 means that there are a whole bunch of folks would couldn't possibly afford a new computer who now can.
Remember, these things aren't targeted at the US market, and aren't targeted at people who can afford current prices.
You simply will not get the same type of experience if it's interactive all the time, and being interactive constantly should not always be the highest goal for a game to have.
Well, wait a moment.
One can have the player's character scripted to talk with someone else on the radio, speaking a precanned conversation, without removing the player's control of his character for the duration of that conversation. Keeping the player in control doesn't mean requiring the player to control everything down to the PC's speech in discussion with NPCs (though allowing the conversation to be directed is nice -- and movement through the plot can be dependent on following the conversation tree until it hits one of a few particular paths). (Supporting multiple paths is a Good Thing, though: One of the best things about Deus Ex was how the player had a number of places where there were several substantially different approaches which could be taken to achieve goals, which would have effects for the rest of the game -- for instance, one could go the obvious path and let a friendly NPC die, or a less obvious route and have that NPC around later in the game; or one could engage in a direct assault and gain a reputation for being bloodthirsty which followed the player around later on, or take a covert approach and gain a reputation to the contrary. Supporting this is hard enough without having to have multiple versions of big, long, prerendered cutscenes, though). Having a short cutscene while the other party in a user-directed conversation talks is a reasonable approach. Requiring big long cutscenes before the plot is compelling... not so good.
And until games start having sophisticated linguistic and other communication involved, constant interactivity will always be second rate.
Techniques for allowing the player to direct complex conversations are well-established. Largely they consist of letting the user pick key responses at some point in the conversation (and then providing precanned conversation from there until the next decision large enough to ask for user interaction comes up), but other approaches have been used. Avoiding large cutscenes and leaving the user in control of the PC during discussions (either by directing the flow of conversation or, when appropriate [ie. radio conversations], leaving the player in control of the PC's movement and actions) doesn't imply that it's necessary to remove all precanned communications from the game.