"Oh, your credentials are excellent; but I'm afraid your mortality profile is not what we are looking for. The best alumni donors live long successful lives, then die relatively swiftly, leaving plenty for a generous bequest. The ones that die young and tragically we admit strategically, for their potential artistic value; but the ones that are likely to linger for years under ever costlier treatments just aren't worth it."
"Though, on the other hand... I like you kid, you seem like the right sort, not really your fault that you'll probably die slowly of something from 90 to 97. Re-apply, with an essay that has a bit more stoicism and enthusiasm for the sort of motorcycles that you'll be able to afford just as your reflexes are starting to deteriorate, and I'll talk to some people I know..."
It isn't really sexy tech(though visualization of its results might be), which may well be why Google isn't too interested; but there has actually been a lot of social science research on genocide, the conditions under which it occurs, whether it can be predicted based on demographic and economic data, and so forth.
The "hey, let's draw some pretty pictures of what is already happening" concept is largely vacuous; but there is actually reasonably good reason to suspect that genocides should be substantially predictable, on an epidemiological level...
Be fair. Once I announced that I would be leveraging the social graph and web2.0 crowdsourced collaboration to enable grassroots Ethnic Cleansing Beta, Google acquired me for a juicy pile of stock almost immediately.
Microsoft responded by announcing the imminent release of an enterprise-grade PurityPoint Ethnicity rights management server, complete with robust AD integration, and a bookburning management console snap-in to allow administrators to easily purge documents from SharePoint, or delegate purging rights to their most depraved henchmen. Unfortunately, their truth_and_reconcilation_ml, an ostensibly open-standard XML-based atrocity documentation markup language turned out to be a ghastly quasi-proprietary mess, rammed through ECMA...
Because leap seconds are not added predictably(the International Earth Rotation and Reference Systems Service does try to announce them with some notice; but the earth is pretty wobbly), that would be an issue for any system that has to spit out UTC for years or decades without any updates aside from GPS; but for pretty much any other system(and basically any internet or large internal network connected PC would qualify), who cares?
The GPS gives you a highly stable timebase for peanuts, and then you can correct to UTC in software; based on the current number of leap seconds in play.
What I don't really understand(though what might be part of why they don't seem to offer anything all that compelling to the customer) is how the economics of their operation stack up.
With something like storage, or web hosting, there are fairly large and obvious gains to centralization and specialization. In the case of storage, the economics of not having a local copy are stupid, when a 1TB drive is $99; but unless your data are super extra secret, especially enormous, or you are atypically skilled, getting backup by buying 1 1 millionth of some professional data warehouse's capacity and sending incrementals over the internet is clearly sensible. Web hosting even more so. A tiny slice of some gigantic datacenter with multiple redundant enormous pipes is way cheaper than replicating that at home.
Video games, though, don't seem to offer the same arguments. Unlike, say, making good backups, which is a comparatively rare skill, console gaming is pretty seriously accessible. Worst case, you bribe some local 16 year old with a six pack to make it work. So there is no argument from skill specialization. Consoles have already carved out a "gaming appliance" market, and(particularly for casual games, flash games, and the like) using the PC that already needs to be working for internet access and word processing for a bit of gaming on the side isn't much harder.
There is also no efficiency of scale argument: In something like storage, a fancy data-deduplicating, zippy-special-compression, etc. storage setup, as available to the pros, can handle rather more customers than a simple comparison of its total capacity to the sum of all the customer's data would suggest. Most home-user data are either in the form of unique; but fairly tiny and compressible, stuff like text documents, or fairly large; but far from unique, things like downloaded movies and songs. With games, though, that effect is much smaller, if present at all. Console games are generally designed to be at the limits of their hardware, since those limits are fixed. You might, if buying in gigantic bulk, convince the console maker to provide you with their console in "processor card" format, allowing you to aggregate things like PSUs and mass storage; but, even in that ideal world, you are still buying as much silicon as joe gamer.
Games are also relatively "bursty" which is bad. Because of latency/speed of light issues, you cannot aggregate demand across the globe, or even across more than a handful of time zones. So, everyone your datacenter serves will be on almost the same schedule. During peak hours, like shortly after kids get out of school, you'll need to be able to support almost as many instances as you have customers. During off-hours, you'll just have a few inverted odd-shift workers and the like. Unlike batch number crunching, an hour starting at 4am is nearly worthless to most of your customers.
Then, of course, you come to the fact that "cloud gaming" inevitably incurs certain additional costs: bandwidth and video compression hardware. You'll see some bandwidth savings, since none of your customers will be downloading game or demo binaries from you, and because you will be able to keep multiplayer games, in some cases, occuring between multiple users within your datacenter; but the fact that you are sending 720p video constantly, to each one of them, will erode that pretty quickly. You also have to pay for, and power, whatever silicon is pumping out that video.
This, I'm assuming, is why OnLive is charging a subscription fee just for the right to show up and buy stuff, and why the games they are selling access to are not, generally, forecast to be much of a discount over their retail counterparts.
Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps.
Damn it, kids, Latency and bandwidth are not the same thing and anybody who makes that mistake should be forced to use a "1Gb/s" connection via fedex.
Yes, in the case of something like OnLive, which is basically streaming mouse/keyboard events one way and video the other, things will look substantially worse if frame N hasn't finished downloading by the time frame N+1 is ready for transfer(and then either has to be dropped, or delays frame N+1 even more than your connection's latency would); but having a fat pipe does not "reduce your latency". It is correct to say that 25mb/s FIOS is probably about the most generous test that is also remotely realistic for more than a tiny number of their potential customers; but the bandwidth thereof does not "reduce latency"...
Depends on the battery chemistry. Most batteries do not perform as well when cold as they do at room temperature, though exactly how severe "not as well" is for various values of "cold" can vary sharply by chemistry and design.
This is actually part of why conventional engines are hard to start in cold(in addition to increased lubricant viscosity and any other effects on the fuel and fluids). Your car battery needs to deliver a nontrivial amount of current to the starter motor to get the engine started. A cold battery, especially if it was borderline before, is going to have lower peak current output. If your battery's peak current drops below what you need to start, you have a problem. If the starting requirements are higher because lubricants are more viscous than designed, you have two problems flanking you.
An electric vehicle would, presumably, be at lower risk of simply "not starting", since most electric motors will at least turn feebly at well under their preferred voltage or current; but it would be more vulnerable to the fact that cold generally reduces usable battery capacity and available current, at least until the battery is allowed to warm again.
Golf carts, shockingly enough, are not especially heavy-duty vehicles. Amazing what being designed to operate cheaply on gently rolling and well-manicured landscapes will do to you.
Electric motors, though, can put out some seriously mean torque at low speed. In fact, dealing with the amount of current they draw as they approach stall is one of the important design considerations in using them.
In terms of energy output, I have no doubt that such a system would work just fine. Even quite primitive combustion technologies will get you net-positive energy out of all but the most combustion resistant plastics.
Assuming their claims are roughly accurate, they may also avoid some of the nasty side effects of crude incineration: many plastics, and organic combustibles generally, will put out a grab-bag of nasties (polycyclic aromatic hydrocarbons and other carcinogenic deliciousness) if their combustion occurs at too low a temperature, or is incomplete. A properly designed and operated pyrolytic system would, presumably, avoid that, assuming it actually spends its life running to spec, not necessarily to lowest operating cost.
Where my skepticism and concern kick in, though, are with plastics that have high odds of being nasty no matter how you burn them. PVC, for instance, is ~50% chlorine by weight. Chlorine has some really vicious combustion products(dioxins being the most famous). Those guys explicitly claim support for "highly chlorinated plastics". Where does the chlorine go?
Even plastics that sound like they should be pretty harmless when burned properly(like ABS) virtually always have a number of processing aids, additives, fillers, pigments, flame retardants, and stabilizers in them by the time they hit the real world. Depending on the precise application, manufacturer, date of manufacture, and other variables pretty much impossible to economically determine at disposal time, that can mean all kinds of curious chemicals. With electronics, chlorine or bromine based flame retardants in the plastic parts are practically a given. Neither has combustion products that I would want to breath. Heavy-metal based inorganic pigments(good old cadmium yellow and friends) cannot be ruled out. Organonickel UV stabilizers are a possibility. Lead based heat stabilizers may show up as well.
It could be, I am not a toxicologist, that all this stuff is less nasty than what you would get by generating the same amount of energy with coal, which would make it a net win compared to current practice; but some plastics are not to be incinerated lightly, including some that show up almost across the board in consumer products.
Some probably can(many plastics are, after all, recycleable); but polymerization is one of those things that can be harder to undo than to do(consider cellulose: produced by virtually all plants, something like the most common organic compound on the earth's surface, a long chain of delicious, energy-rich glucose, and yet only a relative handful of specialized organisms can crack the stuff...).
The other problem is the additives. The properties that, say, make an ABS dye a good dye are its ability to integrate itself with ABS in an even, stable, lightfast, resistant-to-common-chemicals way. These same properties will probably make it a nuisance to get back out. Thus, unless you are recycling for an application where it doesn't matter, or are sorting by color for future applications consisting of present colors or mixes, you have a problem.
Certain additives are also an issue because they are rather unpleasant in themselves. Hydrocarbon derivatives would make a dandy fuel(especially in large facilities that can burn them hot enough to keep the levels of carcinogenic incomplete combustion products down. Power plants, yes. Bubba's burn pit, not so much); but, if they had halogen compounds added for combustion resistance, your smoke will be somewhere in the PPM range of assorted nasty halogen compounds. That really brings out the NIMBY in people.
Given that "smart meters" will inevitably end up being connected to billing, I wouldn't be too optimistic about there being any fully open standard for how they do their reporting. They will probably use some sort of mostly-standard transport(ie. bluetooth, wifi, TCP/IP over whatever is handy) for economic reasons and, for similar economic reasons, we might end up with some sort of "industry consensus" type standard, where the equipment is more or less interoperable; but the details are rather hush-hush/professionals only(if, probably, more transparent than they would like to anybody with hardware hacking chops and some guts).
If one is lucky, they would probably make mostly-standard use of the bluetooth serial profile, the way that bluetooth GPSes do, with some additional commands tacked on to allow for configuration, and (ideally) to make the device spit out a nicely formatted description of exactly what information it is providing.
It isn't clear that PC recycling can be done cheaper than just letting expendable kids do it over open fires; but that isn't the same as saying it can't be done.
Compare your average PC, in terms of metals content, to the sorts of ores that are considered economically viable to extract. Particularly once you consider that somebody with a selection of common screwdrivers, and maybe a prybar, can do substantial material separation mechanically(or, if labor costs bite, shredder + magnets). With either screwdriver work or shredding + electromagnets, most of the steel that went in can be recovered fairly easily. The remaining scrap is, in percentage by weight, substantially richer in things like copper, gold, lead, and tin than many ores that are considered commercially viable.
The real nuisance is a lot of the plastics. ABS+dyes+possibly plasticisers and other application specific additives isn't worth all that much, Ground fiberglass composites are probably worth even less.. However, with a lot of electronics, both of those will have enough halogenated flame retardants baked in that you can't really safely burn the stuff, and burying it is just an invitation to the local groundwater for any lead you didn't manage to extract.
Please, sir, cease your slander. The invisible hand is colour blind. It would be just as happy for white and asian children to wallow in toxic waste, assuming it is profitable enough. Only a racist, and one with insufficient trust in the market, would apply affirmative action policies to the booming "informal disposal" market...
Shhh. Those are just a commie conspiracy to discredit the Free Market. Any failure by the real world to precisely replicate the predictions of an Econ 101 student with a B or better average is caused by government meddling and could be solved by cutting taxes.
Do these words of wisdom also apply to people who work outside?
Now, it isn't like I have to sully the purity of my untanned pastiness by facing sunlight on the clock; but I've heard persistent rumors of people who make vocational use of computers, among other tools, in the merciless company of our nearest star...
Unfortunately, the solution you have identified does not solve the problem that the army as it now exists(for better or for worse) is attempting to solve:
Insurgencies are, particularly if they have the advantage of good suppliers, hostile terrain, culturally clueless enemies, etc. pretty good at holding ground, or at least exacting a nontrivial price for every month the occupying force wishes to "control" the area.
For projecting force into new areas, though, they are nearly useless. Some might argue that this is an advantage; because it keeps foreign military adventurism to a minimum; but it represents a massive change from the capability set of a professional standing army with technology and supply lines and whatnot.
It also doesn't help that a lot of small companies, particularly tech ones, really don't need much of what MS is good at providing.
If you are business or institution, whose focus and skillset isn't primarily technical, that needs to roll out a whole bunch of desktops for word processing and assorted off-the-shelf applications, along with email and central logins and stuff, Microsoft can make you a relatively compelling offer. There will be some annoying issues of various sorts; but the off-the-shelf software will run on Windows clients(and the boxes will be cheap because HP and dell are always cutting each other's throats), Windows admins are fairly common and comparatively inexpensive, and things like Exchange and AD make it(comparatively) trivial to get a bunch of people running more or less homogenous desktop setttings, logging in on different machines, and scheduling boring meetings with each other.
If, on the other hand, you are some tiny techy startup, none of that is nearly as relevant or interesting, or worth the money.
I think that there is a distinction to be drawn between mature and developing markets, there.
Most of Microsoft's biggest customers basically just want XP and legacy stability. Sure, it'd be nice if it were incrementally more secure and stuff; but it is hard for Microsoft to make major changes without their customers feeling churned rather than improved.
With something like Android, though, it's still a wild-west just-like-computers-back-before-the-wintel/apple-duopoly/cold war-stabilized. There are still enormous areas for improvement and relatively few ossified-but-critical people or applications. Changes still feel like improvements. It won't last that way forever; but they should have another couple of years.
I totally agree with your second point. The class of "electrical mistake A that will be totally harmless unless somebody makes mistake B, at which point the combination will, as the kids say, 'kill yo ass dead'" is far too large for comfort. Luckily, in a smallish dwelling, and with the history and material culture of RVs to work with, the amount of mains wiring you actually need to run is fairly limited.
The first part, though, I'm inclined to disagree. While a n00b certainly isn't a drop in replacement for a mechanical engineer, I'd be much more confident of the ability of a bunch of tinkerer-level people, with basic woodworking and maybe some light welding skills, along with online CAD fab services, to come up with all sorts of clever little pieces than I would in their ability to come up with an overall coherent architectural design that really pops. Plus, even were good, overall design isn't all that re-usable, while modules can be slotted in elsewhere.
And u-boot is arguably the best case scenario. I just Love the guys who decide that they are too cool for u-boot and decide to roll their own obscure custom bootloaders. That makes life a lot easier...
Drown "that kid who kicks the back of your chair every 1.2 seconds for the entire duration of the flight" in the bathroom sink shortly after takeoff, and you'll have a much better flight.
Plus, altitude causes alcohol to hit harder. Between that and the duty-free, it's like happy hour!
Perhaps being a little more... Diplomatic would be a good idea when dealing with the(sometimes rather ego-driven) people who know how to hack your box...
You are going to have to comply with things like building and fire codes, unless you want to exist in legal limbo. On the plus side, because rail cars presumably had to follow DOT regulations of various sorts(and are only one story tall) code compliance isn't going to be the biggest hurdle in the world; but you'll still have to do it.
http://bulk.resource.org/codes.gov/ is, by a fair margin, your best bet for free access to building, fire, and similar codes(run by one Carl Malamud, something of a hero in the "open public access to government documents" business). It might be less useful to someone of the Limey persuasion, which you seem to be; but many US municipal and state codes simply incorporate wholesale various industry-standard codes, many of which are of international reach. Depending on your location, you may still need one or more licenced people to sign off, for it to all be legal, and you might be able to get a copy of any local codes from some local authority.
More generally, If you want this project to be "open source" in a useful sense, you'll likely want to focus on two things: One is obvious: documentation. You want documentation anyway, just to save your sanity; but that is what you will be sharing with others. Second, slightly less obvious but more important, is modularity. An "Open Source" project that beings "Obtain 1 model XYZ-FOO-123 underground train car. Follow the following steps precisely to convert it into a house." That's a build log, which is fine; but it is of rather limited re-usability. Train cars(and probably other things you will end up incorporating during the course of the project) are the sort of item that is cheap to free(depending on the scrap/collectors market at the time) if you get lucky, uneconomically pricey otherwise. Some people will have them, some won't. Those who do have them will pretty much be stuck with the model they have.
What you will want to do, if you wish to make this a useful "OSS" project, is build it out of a bunch of documented modular components that fit in your environment; but could, possibly with some adaptation; be used in all sorts of other contexts. "Design for platform with sliding wall-mounted pivots that can be unfolded as either a sleeping surface or a table" is useful for anybody who has a flat wall and not much space. Various things of that nature will add up to the solution to your specific problem; but will also be generally applicable.
Coming back to code, and general applicability, and legality, you might also wish to explore minimizing your dependence on things like gas lines and mains electricity in your design. These are the most dangerous if a n00b fucks them up, the most likely to be code/legal-requirement encumbered, and the most likely to differ between nations. 12/24 volt electrical systems, for instance, will allow you to tap the experience of the camper/RV enthusiasts, and may well subject you to far fewer regulatory headaches. Trivial integration with solar is fun also.
Slashdot Mirror
"Oh, your credentials are excellent; but I'm afraid your mortality profile is not what we are looking for. The best alumni donors live long successful lives, then die relatively swiftly, leaving plenty for a generous bequest. The ones that die young and tragically we admit strategically, for their potential artistic value; but the ones that are likely to linger for years under ever costlier treatments just aren't worth it."
"Though, on the other hand... I like you kid, you seem like the right sort, not really your fault that you'll probably die slowly of something from 90 to 97. Re-apply, with an essay that has a bit more stoicism and enthusiasm for the sort of motorcycles that you'll be able to afford just as your reflexes are starting to deteriorate, and I'll talk to some people I know..."
It isn't really sexy tech(though visualization of its results might be), which may well be why Google isn't too interested; but there has actually been a lot of social science research on genocide, the conditions under which it occurs, whether it can be predicted based on demographic and economic data, and so forth.
The "hey, let's draw some pretty pictures of what is already happening" concept is largely vacuous; but there is actually reasonably good reason to suspect that genocides should be substantially predictable, on an epidemiological level...
Be fair. Once I announced that I would be leveraging the social graph and web2.0 crowdsourced collaboration to enable grassroots Ethnic Cleansing Beta, Google acquired me for a juicy pile of stock almost immediately.
Microsoft responded by announcing the imminent release of an enterprise-grade PurityPoint Ethnicity rights management server, complete with robust AD integration, and a bookburning management console snap-in to allow administrators to easily purge documents from SharePoint, or delegate purging rights to their most depraved henchmen. Unfortunately, their truth_and_reconcilation_ml, an ostensibly open-standard XML-based atrocity documentation markup language turned out to be a ghastly quasi-proprietary mess, rammed through ECMA...
Because leap seconds are not added predictably(the International Earth Rotation and Reference Systems Service does try to announce them with some notice; but the earth is pretty wobbly), that would be an issue for any system that has to spit out UTC for years or decades without any updates aside from GPS; but for pretty much any other system(and basically any internet or large internal network connected PC would qualify), who cares?
The GPS gives you a highly stable timebase for peanuts, and then you can correct to UTC in software; based on the current number of leap seconds in play.
If people would just stop using large font sizes in emails, their compressor definitely would have done the trick...
What I don't really understand(though what might be part of why they don't seem to offer anything all that compelling to the customer) is how the economics of their operation stack up.
With something like storage, or web hosting, there are fairly large and obvious gains to centralization and specialization. In the case of storage, the economics of not having a local copy are stupid, when a 1TB drive is $99; but unless your data are super extra secret, especially enormous, or you are atypically skilled, getting backup by buying 1 1 millionth of some professional data warehouse's capacity and sending incrementals over the internet is clearly sensible. Web hosting even more so. A tiny slice of some gigantic datacenter with multiple redundant enormous pipes is way cheaper than replicating that at home.
Video games, though, don't seem to offer the same arguments. Unlike, say, making good backups, which is a comparatively rare skill, console gaming is pretty seriously accessible. Worst case, you bribe some local 16 year old with a six pack to make it work. So there is no argument from skill specialization. Consoles have already carved out a "gaming appliance" market, and(particularly for casual games, flash games, and the like) using the PC that already needs to be working for internet access and word processing for a bit of gaming on the side isn't much harder.
There is also no efficiency of scale argument: In something like storage, a fancy data-deduplicating, zippy-special-compression, etc. storage setup, as available to the pros, can handle rather more customers than a simple comparison of its total capacity to the sum of all the customer's data would suggest. Most home-user data are either in the form of unique; but fairly tiny and compressible, stuff like text documents, or fairly large; but far from unique, things like downloaded movies and songs. With games, though, that effect is much smaller, if present at all. Console games are generally designed to be at the limits of their hardware, since those limits are fixed. You might, if buying in gigantic bulk, convince the console maker to provide you with their console in "processor card" format, allowing you to aggregate things like PSUs and mass storage; but, even in that ideal world, you are still buying as much silicon as joe gamer.
Games are also relatively "bursty" which is bad. Because of latency/speed of light issues, you cannot aggregate demand across the globe, or even across more than a handful of time zones. So, everyone your datacenter serves will be on almost the same schedule. During peak hours, like shortly after kids get out of school, you'll need to be able to support almost as many instances as you have customers. During off-hours, you'll just have a few inverted odd-shift workers and the like. Unlike batch number crunching, an hour starting at 4am is nearly worthless to most of your customers.
Then, of course, you come to the fact that "cloud gaming" inevitably incurs certain additional costs: bandwidth and video compression hardware. You'll see some bandwidth savings, since none of your customers will be downloading game or demo binaries from you, and because you will be able to keep multiplayer games, in some cases, occuring between multiple users within your datacenter; but the fact that you are sending 720p video constantly, to each one of them, will erode that pretty quickly. You also have to pay for, and power, whatever silicon is pumping out that video.
This, I'm assuming, is why OnLive is charging a subscription fee just for the right to show up and buy stuff, and why the games they are selling access to are not, generally, forecast to be much of a discount over their retail counterparts.
Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps.
Damn it, kids, Latency and bandwidth are not the same thing and anybody who makes that mistake should be forced to use a "1Gb/s" connection via fedex.
Yes, in the case of something like OnLive, which is basically streaming mouse/keyboard events one way and video the other, things will look substantially worse if frame N hasn't finished downloading by the time frame N+1 is ready for transfer(and then either has to be dropped, or delays frame N+1 even more than your connection's latency would); but having a fat pipe does not "reduce your latency". It is correct to say that 25mb/s FIOS is probably about the most generous test that is also remotely realistic for more than a tiny number of their potential customers; but the bandwidth thereof does not "reduce latency"...
Depends on the battery chemistry. Most batteries do not perform as well when cold as they do at room temperature, though exactly how severe "not as well" is for various values of "cold" can vary sharply by chemistry and design.
This is actually part of why conventional engines are hard to start in cold(in addition to increased lubricant viscosity and any other effects on the fuel and fluids). Your car battery needs to deliver a nontrivial amount of current to the starter motor to get the engine started. A cold battery, especially if it was borderline before, is going to have lower peak current output. If your battery's peak current drops below what you need to start, you have a problem. If the starting requirements are higher because lubricants are more viscous than designed, you have two problems flanking you.
An electric vehicle would, presumably, be at lower risk of simply "not starting", since most electric motors will at least turn feebly at well under their preferred voltage or current; but it would be more vulnerable to the fact that cold generally reduces usable battery capacity and available current, at least until the battery is allowed to warm again.
Golf carts, shockingly enough, are not especially heavy-duty vehicles. Amazing what being designed to operate cheaply on gently rolling and well-manicured landscapes will do to you.
Electric motors, though, can put out some seriously mean torque at low speed. In fact, dealing with the amount of current they draw as they approach stall is one of the important design considerations in using them.
In terms of energy output, I have no doubt that such a system would work just fine. Even quite primitive combustion technologies will get you net-positive energy out of all but the most combustion resistant plastics.
Assuming their claims are roughly accurate, they may also avoid some of the nasty side effects of crude incineration: many plastics, and organic combustibles generally, will put out a grab-bag of nasties (polycyclic aromatic hydrocarbons and other carcinogenic deliciousness) if their combustion occurs at too low a temperature, or is incomplete. A properly designed and operated pyrolytic system would, presumably, avoid that, assuming it actually spends its life running to spec, not necessarily to lowest operating cost.
Where my skepticism and concern kick in, though, are with plastics that have high odds of being nasty no matter how you burn them. PVC, for instance, is ~50% chlorine by weight. Chlorine has some really vicious combustion products(dioxins being the most famous). Those guys explicitly claim support for "highly chlorinated plastics". Where does the chlorine go?
Even plastics that sound like they should be pretty harmless when burned properly(like ABS) virtually always have a number of processing aids, additives, fillers, pigments, flame retardants, and stabilizers in them by the time they hit the real world. Depending on the precise application, manufacturer, date of manufacture, and other variables pretty much impossible to economically determine at disposal time, that can mean all kinds of curious chemicals. With electronics, chlorine or bromine based flame retardants in the plastic parts are practically a given. Neither has combustion products that I would want to breath. Heavy-metal based inorganic pigments(good old cadmium yellow and friends) cannot be ruled out. Organonickel UV stabilizers are a possibility. Lead based heat stabilizers may show up as well.
It could be, I am not a toxicologist, that all this stuff is less nasty than what you would get by generating the same amount of energy with coal, which would make it a net win compared to current practice; but some plastics are not to be incinerated lightly, including some that show up almost across the board in consumer products.
Some probably can(many plastics are, after all, recycleable); but polymerization is one of those things that can be harder to undo than to do(consider cellulose: produced by virtually all plants, something like the most common organic compound on the earth's surface, a long chain of delicious, energy-rich glucose, and yet only a relative handful of specialized organisms can crack the stuff...).
The other problem is the additives. The properties that, say, make an ABS dye a good dye are its ability to integrate itself with ABS in an even, stable, lightfast, resistant-to-common-chemicals way. These same properties will probably make it a nuisance to get back out. Thus, unless you are recycling for an application where it doesn't matter, or are sorting by color for future applications consisting of present colors or mixes, you have a problem.
Certain additives are also an issue because they are rather unpleasant in themselves. Hydrocarbon derivatives would make a dandy fuel(especially in large facilities that can burn them hot enough to keep the levels of carcinogenic incomplete combustion products down. Power plants, yes. Bubba's burn pit, not so much); but, if they had halogen compounds added for combustion resistance, your smoke will be somewhere in the PPM range of assorted nasty halogen compounds. That really brings out the NIMBY in people.
Given that "smart meters" will inevitably end up being connected to billing, I wouldn't be too optimistic about there being any fully open standard for how they do their reporting. They will probably use some sort of mostly-standard transport(ie. bluetooth, wifi, TCP/IP over whatever is handy) for economic reasons and, for similar economic reasons, we might end up with some sort of "industry consensus" type standard, where the equipment is more or less interoperable; but the details are rather hush-hush/professionals only(if, probably, more transparent than they would like to anybody with hardware hacking chops and some guts).
If one is lucky, they would probably make mostly-standard use of the bluetooth serial profile, the way that bluetooth GPSes do, with some additional commands tacked on to allow for configuration, and (ideally) to make the device spit out a nicely formatted description of exactly what information it is providing.
It isn't clear that PC recycling can be done cheaper than just letting expendable kids do it over open fires; but that isn't the same as saying it can't be done.
Compare your average PC, in terms of metals content, to the sorts of ores that are considered economically viable to extract. Particularly once you consider that somebody with a selection of common screwdrivers, and maybe a prybar, can do substantial material separation mechanically(or, if labor costs bite, shredder + magnets). With either screwdriver work or shredding + electromagnets, most of the steel that went in can be recovered fairly easily. The remaining scrap is, in percentage by weight, substantially richer in things like copper, gold, lead, and tin than many ores that are considered commercially viable.
The real nuisance is a lot of the plastics. ABS+dyes+possibly plasticisers and other application specific additives isn't worth all that much, Ground fiberglass composites are probably worth even less.. However, with a lot of electronics, both of those will have enough halogenated flame retardants baked in that you can't really safely burn the stuff, and burying it is just an invitation to the local groundwater for any lead you didn't manage to extract.
Please, sir, cease your slander. The invisible hand is colour blind. It would be just as happy for white and asian children to wallow in toxic waste, assuming it is profitable enough. Only a racist, and one with insufficient trust in the market, would apply affirmative action policies to the booming "informal disposal" market...
Was he also shocked! shocked! that gambling was occuring in his establishment?
Shhh. Those are just a commie conspiracy to discredit the Free Market. Any failure by the real world to precisely replicate the predictions of an Econ 101 student with a B or better average is caused by government meddling and could be solved by cutting taxes.
Do these words of wisdom also apply to people who work outside?
Now, it isn't like I have to sully the purity of my untanned pastiness by facing sunlight on the clock; but I've heard persistent rumors of people who make vocational use of computers, among other tools, in the merciless company of our nearest star...
Unfortunately, the solution you have identified does not solve the problem that the army as it now exists(for better or for worse) is attempting to solve:
Insurgencies are, particularly if they have the advantage of good suppliers, hostile terrain, culturally clueless enemies, etc. pretty good at holding ground, or at least exacting a nontrivial price for every month the occupying force wishes to "control" the area.
For projecting force into new areas, though, they are nearly useless. Some might argue that this is an advantage; because it keeps foreign military adventurism to a minimum; but it represents a massive change from the capability set of a professional standing army with technology and supply lines and whatnot.
It also doesn't help that a lot of small companies, particularly tech ones, really don't need much of what MS is good at providing.
If you are business or institution, whose focus and skillset isn't primarily technical, that needs to roll out a whole bunch of desktops for word processing and assorted off-the-shelf applications, along with email and central logins and stuff, Microsoft can make you a relatively compelling offer. There will be some annoying issues of various sorts; but the off-the-shelf software will run on Windows clients(and the boxes will be cheap because HP and dell are always cutting each other's throats), Windows admins are fairly common and comparatively inexpensive, and things like Exchange and AD make it(comparatively) trivial to get a bunch of people running more or less homogenous desktop setttings, logging in on different machines, and scheduling boring meetings with each other.
If, on the other hand, you are some tiny techy startup, none of that is nearly as relevant or interesting, or worth the money.
I think that there is a distinction to be drawn between mature and developing markets, there.
Most of Microsoft's biggest customers basically just want XP and legacy stability. Sure, it'd be nice if it were incrementally more secure and stuff; but it is hard for Microsoft to make major changes without their customers feeling churned rather than improved.
With something like Android, though, it's still a wild-west just-like-computers-back-before-the-wintel/apple-duopoly/cold war-stabilized. There are still enormous areas for improvement and relatively few ossified-but-critical people or applications. Changes still feel like improvements. It won't last that way forever; but they should have another couple of years.
I totally agree with your second point. The class of "electrical mistake A that will be totally harmless unless somebody makes mistake B, at which point the combination will, as the kids say, 'kill yo ass dead'" is far too large for comfort. Luckily, in a smallish dwelling, and with the history and material culture of RVs to work with, the amount of mains wiring you actually need to run is fairly limited.
The first part, though, I'm inclined to disagree. While a n00b certainly isn't a drop in replacement for a mechanical engineer, I'd be much more confident of the ability of a bunch of tinkerer-level people, with basic woodworking and maybe some light welding skills, along with online CAD fab services, to come up with all sorts of clever little pieces than I would in their ability to come up with an overall coherent architectural design that really pops. Plus, even were good, overall design isn't all that re-usable, while modules can be slotted in elsewhere.
And u-boot is arguably the best case scenario. I just Love the guys who decide that they are too cool for u-boot and decide to roll their own obscure custom bootloaders. That makes life a lot easier...
Drown "that kid who kicks the back of your chair every 1.2 seconds for the entire duration of the flight" in the bathroom sink shortly after takeoff, and you'll have a much better flight.
Plus, altitude causes alcohol to hit harder. Between that and the duty-free, it's like happy hour!
Perhaps being a little more... Diplomatic would be a good idea when dealing with the(sometimes rather ego-driven) people who know how to hack your box...
You are going to have to comply with things like building and fire codes, unless you want to exist in legal limbo. On the plus side, because rail cars presumably had to follow DOT regulations of various sorts(and are only one story tall) code compliance isn't going to be the biggest hurdle in the world; but you'll still have to do it.
http://bulk.resource.org/codes.gov/ is, by a fair margin, your best bet for free access to building, fire, and similar codes(run by one Carl Malamud, something of a hero in the "open public access to government documents" business). It might be less useful to someone of the Limey persuasion, which you seem to be; but many US municipal and state codes simply incorporate wholesale various industry-standard codes, many of which are of international reach. Depending on your location, you may still need one or more licenced people to sign off, for it to all be legal, and you might be able to get a copy of any local codes from some local authority.
More generally, If you want this project to be "open source" in a useful sense, you'll likely want to focus on two things: One is obvious: documentation. You want documentation anyway, just to save your sanity; but that is what you will be sharing with others. Second, slightly less obvious but more important, is modularity. An "Open Source" project that beings "Obtain 1 model XYZ-FOO-123 underground train car. Follow the following steps precisely to convert it into a house." That's a build log, which is fine; but it is of rather limited re-usability. Train cars(and probably other things you will end up incorporating during the course of the project) are the sort of item that is cheap to free(depending on the scrap/collectors market at the time) if you get lucky, uneconomically pricey otherwise. Some people will have them, some won't. Those who do have them will pretty much be stuck with the model they have.
What you will want to do, if you wish to make this a useful "OSS" project, is build it out of a bunch of documented modular components that fit in your environment; but could, possibly with some adaptation; be used in all sorts of other contexts. "Design for platform with sliding wall-mounted pivots that can be unfolded as either a sleeping surface or a table" is useful for anybody who has a flat wall and not much space. Various things of that nature will add up to the solution to your specific problem; but will also be generally applicable.
Coming back to code, and general applicability, and legality, you might also wish to explore minimizing your dependence on things like gas lines and mains electricity in your design. These are the most dangerous if a n00b fucks them up, the most likely to be code/legal-requirement encumbered, and the most likely to differ between nations. 12/24 volt electrical systems, for instance, will allow you to tap the experience of the camper/RV enthusiasts, and may well subject you to far fewer regulatory headaches. Trivial integration with solar is fun also.