The fact that two people missed the sarcasm enough to feel that it was worth commenting gives me the unpleasant suspicion that people who aren't being sarcastic apply this theory of hiring with some frequency...
Unless the contrary is specifically mentioned, it's probably a safe assumption. I suspect that the question will be 'is the proprietary firmware stored on the device, or loaded by the driver, and if it is loaded by the driver, are Qualcomm going to be total dicks about redistribution of the firmware blob?'
While, in an ideal world, having the firmware also be OSS would be nice (and, in the case of something like motherboard firmware, which is something approaching the complexity and power of a full OS, running silently underneath the OS that you can see, all the time, increasingly likely to be necessary for the product to be 'free' in any operationally useful sense, rather than being a proprietary blackbox that is kind enough to permit you to exist inside a hypervised sandbox, like the PS3 used to), the thing that is really annoying is companies who hassle you about mere redistribution of unaltered firmware images purely for the purposes of using their products. There isn't really a 'freedom' difference between the parts that store all their firmware in flash, and the parts that have just enough brain to wake up and receive their firmware blob from their driver on startup(if anything, parts that store the blob offsite are probably easier targets for reverse engineering, and harder to brick); but unless you can redistribute the blob, there sure is a convenience difference...
Back in the NSLU2 days (233MHz StrongARM for only $99... how far we've come), that was the case with the NIC firmware for some inscrutable reason. If you wanted to use the built-in NIC, you needed to go through a clickwrap license agreement with Intel, despite the fact that the firmware you were 'licensing' was totally useless for any purpose except to use part of the silicon purchased from Intel. Just pure, pointless, hassle.
I mean, yeah, it'll have gameplay that would make calling it "Battlefield: Sneaking of Honor" more honest, and actually-useful arrows will be consumable DLC items you purchase with real money, and you'll have to install Origin for it to work, and the game will demand the right to post promotional messages on any and all social media accounts you have access to; but it'll be AAA, man!
Ah, the plan will not be complete until we can pay the workers in scrip. I'm pretty sure that ZyngaCash isn't an option, since Facebook is having togetherness issues with them. Does Facebook have a pseudo-currency they could use?
Why do you think that Silicon valley has an entire population of wealthy and petulant.com zillionaires with schemes to build their own nominally-libertarian company towns outside of national jurisdiction?
Of course not. Our HR department's compliance specialists would love to assure you that no such violations are taking place. Now, as an unfortunate matter of fact, old, uncool, balding sickies with 'families' and 'lives outside work' happen to be a poor fit for our company culture, and our hiring process takes ensuring the continuation of the company's innovative culture very seriously; but all applications are given the consideration that the law requires.
You see illegals picketing all the time in D.C.....why no crackdown/arrests/deportations?
Well, you see, America has what's called a "Two party system". One of the parties operates under the bleeding-heart assumption that illegal immigrants might actually be humans, and might actually vote for them. The other party isn't that optimistic; but likes its laborers cheap, expendable, and powerless.
(Also, when it comes to playing law-enforcement whack-a-mole, fighting the 'war on drugs' and getting some of that sweet, sweet, civil forfeiture action pays so much better than rounding up illegal mexicans.)
...because they think it's too big and not good enough
Maybe they think Linus is a jerk who treats linux like his personal playground. Wouldn't want 50,000 units depending on that.
I'm sure that this is irrelevant to you; but somebody else might read it: the big trick RE: Linus vs. Linux is that (unless you like it fast, dangerous, and straight from kernel.org), a given Linux user only depends on, or suffers, Linus' decisions indirectly. If they are doing device development or something, the vendor BSP is between them and 'linux' proper. If they are running Linux on desktops, servers, thin-clients, whatever, their distro is between them and 'linux' proper.
You are still fucked, albeit slowly, if mainline Linux goes in a direction fundamentally unsuitable to you, and you end up having to maintain an ever-larger collection of out-of-tree patches, or remain forever on version 2.6.X or something; but the day-to-day drama on LKML means basically nothing if you just want to use the stuff.
That's the aspect that I was curious about (and about which TFA gave me no useful insights whatsoever):
Unless things have changed radically since the last time I ripped the top off a switch (purely for diagnostic purposes, boss, really), you've got your weedy little application processor that runs some unpleasant, approximately UNIXlike, proprietary embedded OS, whose sole purpose in life is to handle interactions on any config interfaces (local serial, SSH, SNMP, maybe a web page or vendor-proprietary 'unified management' product client) and to chew on the configuration file and spit the result to the actual switching hardware, which is more or less an entirely opaque black box; but switches packets like a bat out of hell with a jetpack. As far as the application processor is concerned, it can't really 'see' the NICs it is switching. It has a network interface itself(sometimes physically available as an actual port, sometimes just a logical interface that you can see if you are connected to the switch); but its OS doesn't "own" or even have particularly direct access to, the switched ports. It just sends down configuration commands, and sometimes receives diagnostic or other replies back.
I certainly wouldn't object to having the application processor running Linux, since it would make a variety of switch-wrangling tasks that are conceptually similar to server management tasks also practically similar, which would simplify my life; but is 'Linux on the network' going to interact with the actual switching hardware in the same way that the prior management OS did, or is this proposal to more closely integrate things (so that, for instance, a 48 port switch 'looks' like a linux box with 48 NICs, possibly another couple for management, and all the usual software you would use if you were doing switching in software on whitebox with a few NICs crammed in would be used; but the switching ASICs would work silently in the background to make those operations actually fast enough to be useful?
It seems (in my admittedly only-slightly-above-a-layman's opinion) that switching to a less impoverished and weird OS for the application processor would be nice; but not particularly world-changing. If, however, the switching hardware interacted more closely with the OS, and you could treat the switch as though it were an ordinary machine with a lot of NICs, only with some operations being hardware accelerated, that would be pretty neat.
Oh, I don't suspect that they were backstabbed; but that they knowingly purchased marginal-quality goods at discounted prices in order to meet their own aggressive pricing schemes.
Especially for potentially-sensitive firmware upgrades or diagnostics, it is perfectly sensible to maintain your own, controlled, environment; but only if you provide your customers with it.
As you say, HP does that (and for other products aside from servers); but they provide whatever you would need to prepare a boot CD/USB of their pet environment, with their utilities ready to go, so that's all just fine.
For most purposes, a relatively tiny utility program can handle any messy details of turning a CD image into a bootable flash drive (whether said tiny utility program is provided for the CD image you care about...) so the two approaches aren't really mutually exclusive. Though I'd certainly treat a vendor who expected 'burn a CD' to be an acceptable mandatory step, without treating usb-stick users as a serious consideration, about as seriously as the same idiots who kept assuming that everybody had floppy drives well after CDRs and small flash drives had mostly taken over, and even conservative PC OEMs were dropping the things.
At one point in the past few years, one of OCZ's popular SSD lines had a 20% failure rate. Most of their other products have consistently been about double to triple the failure rate of everyone else's.
Given that cheap-ass SSDs and cheap-ass RAM were two of their big lines (with PSUs and various other gamer-jockey bits and pieces floating around at the edges from time to time), and given that they didn't own any fabs, it will be very interesting to see what, if any, effect their demise would have on the market for flash and ram silicon...
With something like a DIMM or an SSD, there isn't a huge amount to go wrong mechanically (unless your manufacturing process is unbelievably dire), nor are there a whole lot of components, aside from relatively pricey silicon, to shave pennies on. This is somewhat less like PSUs or cases, or most mechanical gear, where costs are more evenly distributed across the assembly, and you can be sneakier about shaving a nickle here and a penny there, which leaves room for companies that are good at doing so (and produce products that feel pretty cheesy; but work), and companies that aren't (who produce products that just fail a lot).
This leaves one inclined to wonder if OCZ was getting good prices on the expensive silicon by serving as a 'sink' for the actual silicon manufacturer's dubious-grade flash and DRAM. Unless yields are absolutely beautiful across the industry, there are going to be some B-list dice rolling off the line, and almost any discount that doesn't involve writing them off as scrap and grinding them up will be more profitable than the alternative. If that is in fact the case, OCZ may die; but the strong incentives for somebody to find a use for marginal-grade material will remain. Will some other off-brand(s) spring up? Will one or more controller design outfits attempt to turn the situation to their advantage by producing a controller specially suited to taking a larger quantity of lousy flash or DRAM and hiding that behind an abstraction of a smaller quantity of actually-reliable stuff(all controllers do some degree of that, but apparently not enough to save OCZ products)?
Everyones SSD stuttered back then, save for Intels. Search for Marvel SSD controller stuttering and you'll find almost every brand! The early controllers were garbage..
On the plus side, if you were stuck with a Marvel controller, that did mean that you didn't have a JMicron controller. Those are shit.
Oh, I don't think that we are in disagreement here. My intended point is that, while railing against the (often genuinely ghastly) shambling horrors that people cobble together out of spreadsheets, duct tape, and optimism is entertaining, There Is No programming tool(barring strong AI-level expert systems, at which point humanity can pretty much pack up and call it a day) that will stop that from happening unless people who are both programmers and understand and care about/are allocated to the problem are available.
As much as it might offend the purists, almost everyone would rather have an imperfect, or even lousy, implementation of what they want, now, rather than a technically correct implementation of what IT thinks they ought to have 6 months from now. In fairness to IT, of course, when they can be properly integrated, things are somewhat less likely to turn into an unmaintainable and horribly brittle clusterfuck. (I once had the... pleasure... of observing the period where a small group of economic consultants, experts in that area, ran very hard indeed into the memory-space and compute-speed limitations of macro-laden spreadsheets. Luckily, they still had most of the human capital in-house, so the task of breaking out the algorithms and logical structures for implementation by the dedicated software developers they eventually had to hire was an expensive inconvenience rather than futile archaeology. Even so, if executing a spreadsheet in a 64 bit memory space across a modest sized compute cluster had been a supported option, they'd probably be using MS Excel for HPC to this day...)
And before long, the whole company descends into chaos. Can we please keep non-programmers AWAY from trying to cobble together automated systems?
While we're at it, can management please be made to bother to consult the development department BEFORE making technical decisions on things such as data structures, key formats etc?
The ugly trick is that if you want to keep non-programmers away from something, some programmer has to take one for the team and gingerly approach whatever horrible little ad-hoc business logic problem or whatever the non-programmer was trying to solve. If dual-class programmers were in ready supply, it's not like the non-techies would be clamoring for more chances to get their hands dirty.
Arguably, 'Flow Based Programming' (at least back when it was called 'Functional Programming'), arises out of an elegant impulse, just look at what the concept of a 'Function' can do for you in so very many fields of mathematics; but seems painfully likely to fall over in a screaming heap in the face of a real-world programming team, under real-world pressure.
Actually, sounds more like LabView.
Fishing through that programming environment's icon set for the correct function is very close to what I imagine hell must be like.
I suspect that it's pretty strongly dependent on implementation, with two main drivers:
On the one hand, you have the needs of essentially-not-programmers-at-all, who have some input that needs to travel through a series of tubes and get transmogrified. The results aren't going to be pretty; but it's a legitimate need. (there are also those who argue that it's a good pedagogical approach for young children, as in classic Klick 'n Play(published by Maxis in the US, international publishing and titles are strangely all over the map, or the more recent Scratch.
On the other hand, "Flow-based programming" is essentially another flavor of Functional Programming, which seems likely to never truly die, no matter how obscure in real-world use, because of how central the concept of 'functions' in some reasonably generalized sense is to mathematics, ensuring a ready supply of people ready to charge into the breach and try to bring the elegance of pure mathematics to programming. Again.
It fails the 'without making you sweat' test, and it will continue to work up to (and past) the point of lethal hyperthermia, which is why nobody officially uses it any more; but a href="http://en.wikipedia.org/wiki/2,4-Dinitrophenol">2,4-Dinitrophenol does the trick.
The stuff craters the ATP synthesis efficiency of your mitochondria by allowing protons to pass through the membrane that is supposed to be maintaining the proton gradient for Oxidative phosphorylation. The energy that should have gone into producing ATP is then dissipated as waste heat. Obviously this isn't something you want to overdo (since either lack of ATP or excessive body temperature will do you a world of bad) and there are some concerns about the toxicity of the chemical outside of this particular effect; but sure burns off those excess calories.
I assume that 'waveforms' is a poorly-written-up allusion to the fact that a peltier element (while most usually driven in one direction for its entire life, or, as with those cheapie 'car fridge' units that plug into the DC jack and keep your no-it-isn't-beer-officer-it's-refreshing-soda cool; but can also warm things, flicked between running in one direction and running in the other quite infrequently) is a device that you would treat as demanding specially crafted AC current for a project like this.
Because user temperature and ambient temperature can both vary, sometimes fairly quickly(metabolic exertion, user enters a sunlit office from an interior corridor, whatever), the system would need to be able to drive the peltier in either direction at short notice: to warm the user, drive so that the hot side is coupled to the major blood vessels in the wrist, to cool them, drive in reverse with the hot side dumping to a heat sink(which, given the miserable efficiency of peltiers, will be a little tricky to mount comfortably on the wrist. Liquid coolant circulating through a tube in the sleeve would be convenient; but start to get into 'uncomfortable cyborg' territory pretty quickly.
At any given moment, the Peltier would be an essentially DC device (unlike capacitors or inductors/magnetics in general, they don't depend on either DC ripple or AC current to do anything special); but the driver would have to be able to switch V+ and ground(as well as either the magnitude of V+ or the amount of current allowed to flow) swiftly and automatically in response to sensor inputs.
Any AC/Climate Control people know how the energy costs of modifying humidity compare to those of modifying temperature?
For weedy little freestanding units, dehumidifiers appear to be pretty close to air conditioners that blow warm exhaust air in your face rather than outside; but there may be greater economies to be had in some mechanisms that only work on a larger scale, or when built into the building from day one, or so forth.
XP will obviously be the more important one in real terms (given that people actually use it); but it would be interesting to know whether XP or Vista will be more screwed by malicious actors either hunting exploits in 7 and 8 or studying patches issued for 7 and 8 for clues to use against unpatched systems.
Both will be largely unsupported by MS in the near future; but while XP has the fundamentally more broken security model, Vista is much closer to 7 and 8 architecturally, and so probably has (inferior) versions of anything that was changed when they jumped from XP to 7.
Slashdot Mirror
The fact that two people missed the sarcasm enough to feel that it was worth commenting gives me the unpleasant suspicion that people who aren't being sarcastic apply this theory of hiring with some frequency...
Unless the contrary is specifically mentioned, it's probably a safe assumption. I suspect that the question will be 'is the proprietary firmware stored on the device, or loaded by the driver, and if it is loaded by the driver, are Qualcomm going to be total dicks about redistribution of the firmware blob?'
While, in an ideal world, having the firmware also be OSS would be nice (and, in the case of something like motherboard firmware, which is something approaching the complexity and power of a full OS, running silently underneath the OS that you can see, all the time, increasingly likely to be necessary for the product to be 'free' in any operationally useful sense, rather than being a proprietary blackbox that is kind enough to permit you to exist inside a hypervised sandbox, like the PS3 used to), the thing that is really annoying is companies who hassle you about mere redistribution of unaltered firmware images purely for the purposes of using their products. There isn't really a 'freedom' difference between the parts that store all their firmware in flash, and the parts that have just enough brain to wake up and receive their firmware blob from their driver on startup(if anything, parts that store the blob offsite are probably easier targets for reverse engineering, and harder to brick); but unless you can redistribute the blob, there sure is a convenience difference...
Back in the NSLU2 days (233MHz StrongARM for only $99... how far we've come), that was the case with the NIC firmware for some inscrutable reason. If you wanted to use the built-in NIC, you needed to go through a clickwrap license agreement with Intel, despite the fact that the firmware you were 'licensing' was totally useless for any purpose except to use part of the silicon purchased from Intel. Just pure, pointless, hassle.
Obviously the EA version is going to be better!
I mean, yeah, it'll have gameplay that would make calling it "Battlefield: Sneaking of Honor" more honest, and actually-useful arrows will be consumable DLC items you purchase with real money, and you'll have to install Origin for it to work, and the game will demand the right to post promotional messages on any and all social media accounts you have access to; but it'll be AAA, man!
Ah, the plan will not be complete until we can pay the workers in scrip. I'm pretty sure that ZyngaCash isn't an option, since Facebook is having togetherness issues with them. Does Facebook have a pseudo-currency they could use?
Why do you think that Silicon valley has an entire population of wealthy and petulant .com zillionaires with schemes to build their own nominally-libertarian company towns outside of national jurisdiction?
Admitting to age discrimination are we?
Of course not. Our HR department's compliance specialists would love to assure you that no such violations are taking place. Now, as an unfortunate matter of fact, old, uncool, balding sickies with 'families' and 'lives outside work' happen to be a poor fit for our company culture, and our hiring process takes ensuring the continuation of the company's innovative culture very seriously; but all applications are given the consideration that the law requires.
if only it WAS.
You see illegals picketing all the time in D.C.....why no crackdown/arrests/deportations?
Well, you see, America has what's called a "Two party system". One of the parties operates under the bleeding-heart assumption that illegal immigrants might actually be humans, and might actually vote for them. The other party isn't that optimistic; but likes its laborers cheap, expendable, and powerless.
(Also, when it comes to playing law-enforcement whack-a-mole, fighting the 'war on drugs' and getting some of that sweet, sweet, civil forfeiture action pays so much better than rounding up illegal mexicans.)
...because they think it's too big and not good enough
Maybe they think Linus is a jerk who treats linux like his personal playground. Wouldn't want 50,000 units depending on that.
I'm sure that this is irrelevant to you; but somebody else might read it: the big trick RE: Linus vs. Linux is that (unless you like it fast, dangerous, and straight from kernel.org), a given Linux user only depends on, or suffers, Linus' decisions indirectly. If they are doing device development or something, the vendor BSP is between them and 'linux' proper. If they are running Linux on desktops, servers, thin-clients, whatever, their distro is between them and 'linux' proper.
You are still fucked, albeit slowly, if mainline Linux goes in a direction fundamentally unsuitable to you, and you end up having to maintain an ever-larger collection of out-of-tree patches, or remain forever on version 2.6.X or something; but the day-to-day drama on LKML means basically nothing if you just want to use the stuff.
Hey, I heard customers like kernels...
That's the aspect that I was curious about (and about which TFA gave me no useful insights whatsoever):
Unless things have changed radically since the last time I ripped the top off a switch (purely for diagnostic purposes, boss, really), you've got your weedy little application processor that runs some unpleasant, approximately UNIXlike, proprietary embedded OS, whose sole purpose in life is to handle interactions on any config interfaces (local serial, SSH, SNMP, maybe a web page or vendor-proprietary 'unified management' product client) and to chew on the configuration file and spit the result to the actual switching hardware, which is more or less an entirely opaque black box; but switches packets like a bat out of hell with a jetpack. As far as the application processor is concerned, it can't really 'see' the NICs it is switching. It has a network interface itself(sometimes physically available as an actual port, sometimes just a logical interface that you can see if you are connected to the switch); but its OS doesn't "own" or even have particularly direct access to, the switched ports. It just sends down configuration commands, and sometimes receives diagnostic or other replies back.
I certainly wouldn't object to having the application processor running Linux, since it would make a variety of switch-wrangling tasks that are conceptually similar to server management tasks also practically similar, which would simplify my life; but is 'Linux on the network' going to interact with the actual switching hardware in the same way that the prior management OS did, or is this proposal to more closely integrate things (so that, for instance, a 48 port switch 'looks' like a linux box with 48 NICs, possibly another couple for management, and all the usual software you would use if you were doing switching in software on whitebox with a few NICs crammed in would be used; but the switching ASICs would work silently in the background to make those operations actually fast enough to be useful?
It seems (in my admittedly only-slightly-above-a-layman's opinion) that switching to a less impoverished and weird OS for the application processor would be nice; but not particularly world-changing. If, however, the switching hardware interacted more closely with the OS, and you could treat the switch as though it were an ordinary machine with a lot of NICs, only with some operations being hardware accelerated, that would be pretty neat.
Oh, I don't suspect that they were backstabbed; but that they knowingly purchased marginal-quality goods at discounted prices in order to meet their own aggressive pricing schemes.
Especially for potentially-sensitive firmware upgrades or diagnostics, it is perfectly sensible to maintain your own, controlled, environment; but only if you provide your customers with it.
As you say, HP does that (and for other products aside from servers); but they provide whatever you would need to prepare a boot CD/USB of their pet environment, with their utilities ready to go, so that's all just fine.
For most purposes, a relatively tiny utility program can handle any messy details of turning a CD image into a bootable flash drive (whether said tiny utility program is provided for the CD image you care about...) so the two approaches aren't really mutually exclusive. Though I'd certainly treat a vendor who expected 'burn a CD' to be an acceptable mandatory step, without treating usb-stick users as a serious consideration, about as seriously as the same idiots who kept assuming that everybody had floppy drives well after CDRs and small flash drives had mostly taken over, and even conservative PC OEMs were dropping the things.
At one point in the past few years, one of OCZ's popular SSD lines had a 20% failure rate. Most of their other products have consistently been about double to triple the failure rate of everyone else's.
Given that cheap-ass SSDs and cheap-ass RAM were two of their big lines (with PSUs and various other gamer-jockey bits and pieces floating around at the edges from time to time), and given that they didn't own any fabs, it will be very interesting to see what, if any, effect their demise would have on the market for flash and ram silicon...
With something like a DIMM or an SSD, there isn't a huge amount to go wrong mechanically (unless your manufacturing process is unbelievably dire), nor are there a whole lot of components, aside from relatively pricey silicon, to shave pennies on. This is somewhat less like PSUs or cases, or most mechanical gear, where costs are more evenly distributed across the assembly, and you can be sneakier about shaving a nickle here and a penny there, which leaves room for companies that are good at doing so (and produce products that feel pretty cheesy; but work), and companies that aren't (who produce products that just fail a lot).
This leaves one inclined to wonder if OCZ was getting good prices on the expensive silicon by serving as a 'sink' for the actual silicon manufacturer's dubious-grade flash and DRAM. Unless yields are absolutely beautiful across the industry, there are going to be some B-list dice rolling off the line, and almost any discount that doesn't involve writing them off as scrap and grinding them up will be more profitable than the alternative. If that is in fact the case, OCZ may die; but the strong incentives for somebody to find a use for marginal-grade material will remain. Will some other off-brand(s) spring up? Will one or more controller design outfits attempt to turn the situation to their advantage by producing a controller specially suited to taking a larger quantity of lousy flash or DRAM and hiding that behind an abstraction of a smaller quantity of actually-reliable stuff(all controllers do some degree of that, but apparently not enough to save OCZ products)?
Everyones SSD stuttered back then, save for Intels. Search for Marvel SSD controller stuttering and you'll find almost every brand! The early controllers were garbage..
On the plus side, if you were stuck with a Marvel controller, that did mean that you didn't have a JMicron controller. Those are shit.
Oh, I don't think that we are in disagreement here. My intended point is that, while railing against the (often genuinely ghastly) shambling horrors that people cobble together out of spreadsheets, duct tape, and optimism is entertaining, There Is No programming tool(barring strong AI-level expert systems, at which point humanity can pretty much pack up and call it a day) that will stop that from happening unless people who are both programmers and understand and care about/are allocated to the problem are available.
As much as it might offend the purists, almost everyone would rather have an imperfect, or even lousy, implementation of what they want, now, rather than a technically correct implementation of what IT thinks they ought to have 6 months from now. In fairness to IT, of course, when they can be properly integrated, things are somewhat less likely to turn into an unmaintainable and horribly brittle clusterfuck. (I once had the... pleasure... of observing the period where a small group of economic consultants, experts in that area, ran very hard indeed into the memory-space and compute-speed limitations of macro-laden spreadsheets. Luckily, they still had most of the human capital in-house, so the task of breaking out the algorithms and logical structures for implementation by the dedicated software developers they eventually had to hire was an expensive inconvenience rather than futile archaeology. Even so, if executing a spreadsheet in a 64 bit memory space across a modest sized compute cluster had been a supported option, they'd probably be using MS Excel for HPC to this day...)
And before long, the whole company descends into chaos. Can we please keep non-programmers AWAY from trying to cobble together automated systems? While we're at it, can management please be made to bother to consult the development department BEFORE making technical decisions on things such as data structures, key formats etc?
The ugly trick is that if you want to keep non-programmers away from something, some programmer has to take one for the team and gingerly approach whatever horrible little ad-hoc business logic problem or whatever the non-programmer was trying to solve. If dual-class programmers were in ready supply, it's not like the non-techies would be clamoring for more chances to get their hands dirty.
Arguably, 'Flow Based Programming' (at least back when it was called 'Functional Programming'), arises out of an elegant impulse, just look at what the concept of a 'Function' can do for you in so very many fields of mathematics; but seems painfully likely to fall over in a screaming heap in the face of a real-world programming team, under real-world pressure.
Actually, sounds more like LabView. Fishing through that programming environment's icon set for the correct function is very close to what I imagine hell must be like.
I suspect that it's pretty strongly dependent on implementation, with two main drivers: On the one hand, you have the needs of essentially-not-programmers-at-all, who have some input that needs to travel through a series of tubes and get transmogrified. The results aren't going to be pretty; but it's a legitimate need. (there are also those who argue that it's a good pedagogical approach for young children, as in classic Klick 'n Play(published by Maxis in the US, international publishing and titles are strangely all over the map, or the more recent Scratch.
On the other hand, "Flow-based programming" is essentially another flavor of Functional Programming, which seems likely to never truly die, no matter how obscure in real-world use, because of how central the concept of 'functions' in some reasonably generalized sense is to mathematics, ensuring a ready supply of people ready to charge into the breach and try to bring the elegance of pure mathematics to programming. Again.
It fails the 'without making you sweat' test, and it will continue to work up to (and past) the point of lethal hyperthermia, which is why nobody officially uses it any more; but a href="http://en.wikipedia.org/wiki/2,4-Dinitrophenol">2,4-Dinitrophenol does the trick.
The stuff craters the ATP synthesis efficiency of your mitochondria by allowing protons to pass through the membrane that is supposed to be maintaining the proton gradient for Oxidative phosphorylation. The energy that should have gone into producing ATP is then dissipated as waste heat. Obviously this isn't something you want to overdo (since either lack of ATP or excessive body temperature will do you a world of bad) and there are some concerns about the toxicity of the chemical outside of this particular effect; but sure burns off those excess calories.
A man's body is his own. His water belongs to the corporation.
I assume that 'waveforms' is a poorly-written-up allusion to the fact that a peltier element (while most usually driven in one direction for its entire life, or, as with those cheapie 'car fridge' units that plug into the DC jack and keep your no-it-isn't-beer-officer-it's-refreshing-soda cool; but can also warm things, flicked between running in one direction and running in the other quite infrequently) is a device that you would treat as demanding specially crafted AC current for a project like this.
Because user temperature and ambient temperature can both vary, sometimes fairly quickly(metabolic exertion, user enters a sunlit office from an interior corridor, whatever), the system would need to be able to drive the peltier in either direction at short notice: to warm the user, drive so that the hot side is coupled to the major blood vessels in the wrist, to cool them, drive in reverse with the hot side dumping to a heat sink(which, given the miserable efficiency of peltiers, will be a little tricky to mount comfortably on the wrist. Liquid coolant circulating through a tube in the sleeve would be convenient; but start to get into 'uncomfortable cyborg' territory pretty quickly. At any given moment, the Peltier would be an essentially DC device (unlike capacitors or inductors/magnetics in general, they don't depend on either DC ripple or AC current to do anything special); but the driver would have to be able to switch V+ and ground(as well as either the magnitude of V+ or the amount of current allowed to flow) swiftly and automatically in response to sensor inputs.
Any AC/Climate Control people know how the energy costs of modifying humidity compare to those of modifying temperature?
For weedy little freestanding units, dehumidifiers appear to be pretty close to air conditioners that blow warm exhaust air in your face rather than outside; but there may be greater economies to be had in some mechanisms that only work on a larger scale, or when built into the building from day one, or so forth.
XP will obviously be the more important one in real terms (given that people actually use it); but it would be interesting to know whether XP or Vista will be more screwed by malicious actors either hunting exploits in 7 and 8 or studying patches issued for 7 and 8 for clues to use against unpatched systems.
Both will be largely unsupported by MS in the near future; but while XP has the fundamentally more broken security model, Vista is much closer to 7 and 8 architecturally, and so probably has (inferior) versions of anything that was changed when they jumped from XP to 7.
If I hadn't already commented, I'd give you +1 Funny for using the future tense when describe when the system is going to get owned.