The patent system works in mysterious ways, so there certainly could be a giant clusterfuck of submarine patents lurking out there; but the RFC was released in '98, and the list of vendors and OSS projects with source, sink, or both support is not a short one(and includes Apple's own proprietary OSX server media streaming package). Whatever video/audio codecs you are streaming on top of RTMP are almost certainly going to land you in a giant heap of trouble; but I would expect RTMP itself to either be harmless or driven into some sort of cross-licensing stalemate by now. Individual vendor extensions, of course, particularly DRM related ones, for which the DMCA can come to the field, are presumably a mess; but Apple's ability to say "The RTMP that is real RTMP is the RTMP that iOS recognizes as such, suck it down." would seem to be equal to its ability to say "HTTP live streaming is the new flavor of the month. RTMP is dead."
I'm certainly not up on the details of live media streaming; but I've never seen a clear breakdown of why RTMP is obviously fucked compared to the alternatives.
Given that(with the exception of licensing embedded clients, which(if the dire performance on Android is any indication), they'll have increasing trouble even giving away... Adobe's client side flash/AIR stuff is a pure cost center designed to drive sales of their content-creation suit and assorted server offerings, they don't really have anything to gain by attempting a fight to the last on the client side.
Back when they could actually claim adoption rates in 95+ percent range without the slightest doubt, I suspect that having client ubiquity certainly was helpful; but they would be insane to alienate the customers who actually buy stuff in some sort of fight to ensure that the customers who just download stuff and encounter ghastly security problems can continue to do so.
They will, presumably, walk away by half measures, in order to try to milk RTMPe and other benefits of flash client ubiquity as long as possible; but there is nothing inimical to their actual profit sources in building HTML5 related tools...
RTSP has the major disadvantage of not infrequently including assorted vendor's special secret sauces, meant to drive lock-ins between server software and client software(and/or satisfy somebody's demand for DRM); but does anybody have a technical explanation of why bog-standard RTSP, an RFC implemented by a bunch of vendors(including Apple), is worse than HTTP for media streaming? "More difficult to optimize" is pretty vague.
Depending on how local power is generated, the power consumption column may or may not be hiding a substantial amount of water use as well(the giant cooling towers, billowing clouds of steam that weren't successfully recovered, are not there for show, nor is the siting of many sorts of power plants next to bodies of water just because operators like paying more for picturesque real estate with flood risks.) Some flavors of mining are pretty nasty about using and/or filling with delightsome heavy metals and such, water resources as well.
I don't mean to detract from your, eminently valid, point that there are a lot of accounting shell games, in addition to actual engineering, going on when being "efficient"; but it is really necessary to decompose all the columns in order to figure out what is hiding under each of the shells(and how nasty each something is).
Swamp coolers are a great way(in non-humid areas) to reduce A/C costs and increase clean freshwater use. Whether or not that is a better choice than using more energy strongly depends on how your friendly local energy producer is producing. Odds are that they are consuming cooling water(or hydropower's consumption of water with potential energy); but it isn't always clear how much.
Regardless, though, what you Really, Really, Really want to avoid is situations where archaic, weak, nonsensical, and/or outright corrupt regulatory environments allow people to shove major costs under somebody else's rug. Why do they grow crops in the California desert? Because the 'market price', such as it is, of water sucked from surrounding states is virtually zero. Why are there 20-odd water-bottling operations in Florida, a state barely above sea-level and with minimal water resources? Because the cost of a license to pump alarming amounts(you guys weren't using those everglades for anything, right?) of water is basically zero(unless you are a resident, of course, they face water shortages. Trying incorporating next time, sucker). Similar arguments could be made that energy users in a number of locales are paying absurdly low rates for the Appalachian coal regions being turned into a lunar theme park, among other possibilities.
Playing around with 'efficiency' numbers is a silly game; but largely harmless PR puffery. Making resource tradeoffs that are sensible simply because they allow you to shove major costs onto other people at no cost to yourself is all kinds of serious.
It's pretty much a classic application of the major business case for "open source" anything(the second, typically less significant, one being to assure a customer or customers that you aren't locking them in, if they are large enough or the business competitive enough, to demand that): commodifying your complements.
When a hardware vendor gets all "open source", that is usually a sign that they want a cheap OS and/or some flavor of middleware that can sit between their hardware and their consulting services or genuinely competitively distinguished software(see IBM's use of Linux, or Oracle's, at least before they purchased Sun).
In this case, Facebook's competitive advantage is some combination of their software platform and the network effects of their existing userbase and giant pile-o'-user data. Any requirement that gets in the way of shoving ads and Zanga games down user's gullets is just a cost center, and thus a perfect area to try to share R&D costs on(and possibly put the screws to some of the weaker datacenter operators who are trying to go it alone on high efficiency designs).
Now(just to avoid misinterpretation), the fact that there is a perfectly pragmatic logic behind this doesn't make its value as 'open source' any lower(as long as it isn't some sort of tricky quasi-open thing, which is tried from time to time, though not obviously so here.), in fact, that pragmatic utility is one of 'open source's greatest allies in getting more stuff to be available under those terms; but it is a purely pragmatic thing.
While I suspect that this particular guy might be OK, but the bolded part of your argument would be as applicable to indentured servitude as it would to 'non-compete' clauses. Exactly how much can you sign away?
Oh, I'm sure that they'd be happy enough to sell you the update and skip the hassle of actually producing a new unit. Particularly with all the delightfully DRM-y advances in bootloader-level cryptographic verification and so forth, I could easily see a modern version of the old 'golden screwdriver' upgrade being employed.
(Even without reconfigurable hardware, it is hardly out of the ordinary among 'enterprise appliance' type hardware to pay nontrivial money for unlock codes that let you use parts of the system that the system shipped with. If that model can survive, hardware upgrades through software would look downright sensible by comparison.)
Of course(and this is the big, big 'remains to be see' part) is that 'Privacy Mode' concerns something happening on a box you physically and(unless rooted) logically control. Enforcing it is just a matter of writing the software(which, under different names, I believe pretty much all browser producers have now done).
'Do not track', however, is just a polite request(similar to a robots.txt). There is absolutely no way of technologically forcing compliance(other schemes, like assorted cookie-handling plugins, tor routing, and such attempt to solve the problem technologically, with varying degrees of success and tradeoffs. DNT is just a psuedo-standard way of asking). If major players actually buy in, it could end up being quite useful(given that outwitting data-mining professionals is a bit of a cat-and-mouse, particularly for Joe User). If major players ignore it, or farm out plausible-deniability subsidiaries to do it for them, DNT will be a dead letter.
In the case of robots.txt, ignoring that is considered rather tasteless, and most big players tend not to; but there is nothing stopping a wildcat player or a proxy entity from trampling all over it. DNT's cultural status has yet to be determined. Since that is still up in the air, supporting it is a nice gesture; but provides an unknown(and at present likely fairly minimal) degree of protection.
From a look at the exterior shot provided, no special effort appears to have been taken to ground the foil. It appears to just be there to keep moisture and/or rabid sheetrock mites from getting into the interior material. I'm a bit surprised that some plastic wasn't cheaper; but it seems otherwise sensible enough.
For those who know more than I about the dark arts of RF propagation, what would the effect be of ungrounded conductive sheets? Substantial signal attenuation? Not much effect? Completely unpredictable absorption and re-emmision that could vary wildly according to the exact geometry of the piece?
In a similar vein, if one had an AP/router that one didn't love to much(not so hard when they start at $20...), what would the effect be of attempting to use the metal foil as an antenna, by coupling it directly to the antenna output? Horribly non-optimized for the frequency, I'd imagine; but would it be expected to Not Work, to Not Work and kill the RF amp, to work somewhat, to work better than one might expect?
Incognito mode ('porn mode' to its friends) attacks an entirely different class of privacy problem.
The interpersonal privacy compromise problem is a legitimate one. Potentially embarrassing or worse. Incognito mode does a reasonably effective job of stopping that one(I haven't read up on whether or not the latest forensics packages can do anything against it; but the contents of a closed incognito session are safe enough from your roommate/spouse/kids/nosy sibling/etc.)
Against remote 3rd parties, though, incognito mode is highly limited. It does flush cookies when the session is terminated, which is better than nothing; but with most broadband IPs being close to static, it often isn't rocket surgery to correlate and reconstruct user activity even if you lose some cookies(indeed, being able to run an incognito session and a standard session at the same time and on the same host probably makes that easier, unlike the older, cruder methods where the user manually wiped all their sessions after a period of time).
They are really two entirely different classes of threat.
As much as I think space travel is cool, and the SR-71 was one of the more aesthetically pleasing aircraft ever, and similar sentiments, I can't really muster much pity for the disappointed astronauts and test-pilot types.
There's a saying from the murky world of the intersection between market actors and regulatory agents: "Nobody screams louder than the guy whose subsidy is being cut."
Astronauts, and their ilk, while they did the jobs we offered, fair and square, were (in terms of human speed) some of the most subsidized travellers in history. For a mixture of reasons, some more or less universal(scientific curiosity), some bound up in particular historical moments(Cold war dickwaving and spy games), we made comparatively massive investments in the velocity of a small number of pilots carrying out specific missions. I have nothing against the pilots, who largely executed their missions with skill and nerve; but that doesn't change the fact that those were some of the most expensive tickets in human history, made possible only by certain historical conditions. Those guys were playing with once-in-a-lifetime white elephants, not prerelease prototypes of consumer goods.
(Now, unfortunately, our extraordinary subsidies projects seem to be focused on our parasitic layer of financial services con-men, an entirely crasser class of people, with far fewer virtues and far greater dangers...)
Given the seriously cramped conditions imposed by the Concorde's airframe design(it was necessarily narrow-bodied to reduce drag), and the further crunching induced by trying to get enough paying passengers into the sardine tube to justify the expensive flight, the trade off isn't as straightforward as one might imagine.
From the perspective of comfort and productivity, if the same money can get you a cattle-class seat on a mach 2 bird or a cushy recliner, a power jack for your laptop, and an edible meal on a cost-optimized subsonic one, it isn't at all clear that you'd choose the former.
Given that running the big, cost-optimized subsonic allows the carrier to adjust the split(not quite per-flight; but reasonably quickly) between comfort seats and low cost seats as the market dictates, while the small, supersonic one only allows choosing between expensive discomfort and really expensive comfort, the economics behind running the subsonic craft seem pretty compelling.
While I expect that maximum achievable air speeds(and/or flight paths that incorporate very high speed excursions outside the atmosphere) will continue to advance for specialty applications, mostly military; such developments as "leg room", "laptops that aren't a pain to work on", and "sweet, sweet inflight internet" have likely sealed the commercial fate of very high speed air travel services.
Do you know if the ~150 employees just counts core developers, artists, etc. or does that include the receptionist and the guy who swaps drives on the steam servers and so on?
Unless large parts of the backend are outsourced(which wouldn't be a complete surprise, trying to beat one of the dedicated CDNs at delivering large files to customers all over the place isn't obviously a sensible move when they'd be happy to deliver them for you for a modest fee...) , I have to imagine that steam's physical infrastructure alone would consume a reasonable amount of time and attention, never mind the software development, or the work that goes into figuring out how to make the client hog more system resources.
At least on recent stuff, it typically goes both ways: The motherboard has thermal data from the CPU, and adjusts the output on the PWM line going to the fan, which adjusts its speed. At the same time, to detect fan faults, the motherboard monitors the Tach line coming from the fan. If it doesn't like what it sees, some sort of complaining(from an optional alert on the low end, to a compulsory alert that has to be manually cleared at boot, to just plain shutting down) is typically the result.
As somebody mentioned further up, it wouldn't be rocket surgery to emulate the expected fan signals if needed; but I would expect that a reasonable percentage of management firmwares would at least complain, if not worse, without correctly faked signals.
Microsoft doesn't have an advertising arm, nor is it aggressively moving into IPTV services. Their software platforms also have an excellent record of never being compromised, and the Kinect makes it trivially evident when its mics and/or camera are active.
Thus, there is no possible way in which this could be sinister. I was worried there for a minute...
In systems not designed for it, that could get kind of ugly(DIMMs, riser cards, expansion cards parallel to the motherboard, etc) and having to re-CAD the part because your vendor went to rev A01 from rev A00 or they are now shipping memory modules with slightly different sizes would be a huge pain.
I am told, though, that for very harsh environment embedded systems, that is pretty much what they do. Conformal heatsink plate firmly attached to the board so that the whole thing is a solid block.
All you need is very low ceilings, allowing multiple tiers of racks in what would ordinarily be a 1-story room. You can then hire malnourished Dickensian urchins to scuttle, bent over in a permanent half-crouch, among the dripping coolant tanks, swapping drives and cards... Just remember to flog them frequently, to remind them of their place, or you'll find one cooking his fish-and-chips in the hot-coolant line and clogging the heat exchanger with crumbs.
I imagine that some sort of pneumatic/hydraulic piston system(like the one used on many vertical-open car doors and the like) would be well within the realm of the possible, and offer a zero-apparent-weight slide-up ; but I can't see whether or not there is anything of the sort from the pictures provided.
The one picture showing "easy serviceability" shows the operator having completely unracked a relatively small server. That doesn't scream 'easy' to me. Pull server up, hold with one hand, unclip a bunch of fiddly cables with the other(don't lose them in the oil pit, or you'll have to give the temp a snorkel...) lay it flat, pop the top? Aw hell no. The whole point of slide rails is that you can get to the guts without having to disconnect any cables(unless connected to the particular bit you are swapping, of course) or unrack anything.
All blades would be OK, assuming you never need to get at the back of the blade chassis; but I pity the fool who has to disconnect and reconnect(and be sure to get them back in the right places... those 8 are on different VLANS!) a nasty mess of ethernet cables just to swap a PSU or something.
I suspect that the main advantage over waterblocks is that your server vendor of choice doesn't have to cooperate, and you don't have to run so many small hoses, and can get away with the big huge tank. Now, if some sort of critical mass were achieved in terms of industry acceptance of waterblocks as a factory option(along with some sort of standardized fluid connector), I suspect that that would swiftly become a superior option(though, quite possibly not displacing fans entirely. A fair number of ancillary systems, too small to justify their own waterblocks, get very unhappy if they aren't getting any airflow, even if the CPUs are taken care of...)
I've never tested to see if anything bad happens if you change this yourself; but hard drives are definitely not airtight. Pretty much all of them have one or more visible holes(usually on the top cover, often next to a "Do Not Cover" sticker). There is a fairly serious looking filter on the inside, covering the hole(some sort of fine carbonish powder sealed in what appears to be a teflon pouch); but that is to impede dust, rather than gases.
Nothing stopping you from PXE booting(or iSCSI or fiber channel HBAs on the high end); but I'd be leery of running a hard drive under fluid, except as an experiment.
The only other issue I can imagine might crop up would be discovering the hard way that some polymer used in one of the system's components doesn't handle oil exposure well in the long term. I suspect that most are fine; but if the plasticizer used to soften the insulator coating on some important bundle of wires leaches out over 18 months in a warm oil bath, and the embrittled insulator cracks and shorts the next time you mess with it, the joke would be on you...
Slashdot Mirror
Just fire up SPAN against whatever port the guy with the office's stickiest keyboard uses and you can watch all the porn you want...
The patent system works in mysterious ways, so there certainly could be a giant clusterfuck of submarine patents lurking out there; but the RFC was released in '98, and the list of vendors and OSS projects with source, sink, or both support is not a short one(and includes Apple's own proprietary OSX server media streaming package). Whatever video/audio codecs you are streaming on top of RTMP are almost certainly going to land you in a giant heap of trouble; but I would expect RTMP itself to either be harmless or driven into some sort of cross-licensing stalemate by now. Individual vendor extensions, of course, particularly DRM related ones, for which the DMCA can come to the field, are presumably a mess; but Apple's ability to say "The RTMP that is real RTMP is the RTMP that iOS recognizes as such, suck it down." would seem to be equal to its ability to say "HTTP live streaming is the new flavor of the month. RTMP is dead."
I'm certainly not up on the details of live media streaming; but I've never seen a clear breakdown of why RTMP is obviously fucked compared to the alternatives.
Given that(with the exception of licensing embedded clients, which(if the dire performance on Android is any indication), they'll have increasing trouble even giving away... Adobe's client side flash/AIR stuff is a pure cost center designed to drive sales of their content-creation suit and assorted server offerings, they don't really have anything to gain by attempting a fight to the last on the client side.
Back when they could actually claim adoption rates in 95+ percent range without the slightest doubt, I suspect that having client ubiquity certainly was helpful; but they would be insane to alienate the customers who actually buy stuff in some sort of fight to ensure that the customers who just download stuff and encounter ghastly security problems can continue to do so.
They will, presumably, walk away by half measures, in order to try to milk RTMPe and other benefits of flash client ubiquity as long as possible; but there is nothing inimical to their actual profit sources in building HTML5 related tools...
RTSP has the major disadvantage of not infrequently including assorted vendor's special secret sauces, meant to drive lock-ins between server software and client software(and/or satisfy somebody's demand for DRM); but does anybody have a technical explanation of why bog-standard RTSP, an RFC implemented by a bunch of vendors(including Apple), is worse than HTTP for media streaming? "More difficult to optimize" is pretty vague.
Depending on how local power is generated, the power consumption column may or may not be hiding a substantial amount of water use as well(the giant cooling towers, billowing clouds of steam that weren't successfully recovered, are not there for show, nor is the siting of many sorts of power plants next to bodies of water just because operators like paying more for picturesque real estate with flood risks.) Some flavors of mining are pretty nasty about using and/or filling with delightsome heavy metals and such, water resources as well.
I don't mean to detract from your, eminently valid, point that there are a lot of accounting shell games, in addition to actual engineering, going on when being "efficient"; but it is really necessary to decompose all the columns in order to figure out what is hiding under each of the shells(and how nasty each something is).
Swamp coolers are a great way(in non-humid areas) to reduce A/C costs and increase clean freshwater use. Whether or not that is a better choice than using more energy strongly depends on how your friendly local energy producer is producing. Odds are that they are consuming cooling water(or hydropower's consumption of water with potential energy); but it isn't always clear how much.
Regardless, though, what you Really, Really, Really want to avoid is situations where archaic, weak, nonsensical, and/or outright corrupt regulatory environments allow people to shove major costs under somebody else's rug. Why do they grow crops in the California desert? Because the 'market price', such as it is, of water sucked from surrounding states is virtually zero. Why are there 20-odd water-bottling operations in Florida, a state barely above sea-level and with minimal water resources? Because the cost of a license to pump alarming amounts(you guys weren't using those everglades for anything, right?) of water is basically zero(unless you are a resident, of course, they face water shortages. Trying incorporating next time, sucker). Similar arguments could be made that energy users in a number of locales are paying absurdly low rates for the Appalachian coal regions being turned into a lunar theme park, among other possibilities.
Playing around with 'efficiency' numbers is a silly game; but largely harmless PR puffery. Making resource tradeoffs that are sensible simply because they allow you to shove major costs onto other people at no cost to yourself is all kinds of serious.
It's pretty much a classic application of the major business case for "open source" anything(the second, typically less significant, one being to assure a customer or customers that you aren't locking them in, if they are large enough or the business competitive enough, to demand that): commodifying your complements.
When a hardware vendor gets all "open source", that is usually a sign that they want a cheap OS and/or some flavor of middleware that can sit between their hardware and their consulting services or genuinely competitively distinguished software(see IBM's use of Linux, or Oracle's, at least before they purchased Sun).
In this case, Facebook's competitive advantage is some combination of their software platform and the network effects of their existing userbase and giant pile-o'-user data. Any requirement that gets in the way of shoving ads and Zanga games down user's gullets is just a cost center, and thus a perfect area to try to share R&D costs on(and possibly put the screws to some of the weaker datacenter operators who are trying to go it alone on high efficiency designs).
Now(just to avoid misinterpretation), the fact that there is a perfectly pragmatic logic behind this doesn't make its value as 'open source' any lower(as long as it isn't some sort of tricky quasi-open thing, which is tried from time to time, though not obviously so here.), in fact, that pragmatic utility is one of 'open source's greatest allies in getting more stuff to be available under those terms; but it is a purely pragmatic thing.
Not to worry. Once we bring back indentured servitude and debt slavery, noncompetes will seem entirely reasonable by comparison.
While I suspect that this particular guy might be OK, but the bolded part of your argument would be as applicable to indentured servitude as it would to 'non-compete' clauses. Exactly how much can you sign away?
Oh, I'm sure that they'd be happy enough to sell you the update and skip the hassle of actually producing a new unit. Particularly with all the delightfully DRM-y advances in bootloader-level cryptographic verification and so forth, I could easily see a modern version of the old 'golden screwdriver' upgrade being employed.
(Even without reconfigurable hardware, it is hardly out of the ordinary among 'enterprise appliance' type hardware to pay nontrivial money for unlock codes that let you use parts of the system that the system shipped with. If that model can survive, hardware upgrades through software would look downright sensible by comparison.)
shampoo was invented by the Ancestral Ur Language.
I'm afraid that I have some very bad news about your ongoing use of unlicenced derivatives of my legally protected intellectual property...
XOXOXO,
The Ancestral Ur Language.
I was attempting a deadpan joke with the 'rabid sheetrock mites'. I'll try to be more overt.
Of course(and this is the big, big 'remains to be see' part) is that 'Privacy Mode' concerns something happening on a box you physically and(unless rooted) logically control. Enforcing it is just a matter of writing the software(which, under different names, I believe pretty much all browser producers have now done).
'Do not track', however, is just a polite request(similar to a robots.txt). There is absolutely no way of technologically forcing compliance(other schemes, like assorted cookie-handling plugins, tor routing, and such attempt to solve the problem technologically, with varying degrees of success and tradeoffs. DNT is just a psuedo-standard way of asking). If major players actually buy in, it could end up being quite useful(given that outwitting data-mining professionals is a bit of a cat-and-mouse, particularly for Joe User). If major players ignore it, or farm out plausible-deniability subsidiaries to do it for them, DNT will be a dead letter.
In the case of robots.txt, ignoring that is considered rather tasteless, and most big players tend not to; but there is nothing stopping a wildcat player or a proxy entity from trampling all over it. DNT's cultural status has yet to be determined. Since that is still up in the air, supporting it is a nice gesture; but provides an unknown(and at present likely fairly minimal) degree of protection.
From a look at the exterior shot provided, no special effort appears to have been taken to ground the foil. It appears to just be there to keep moisture and/or rabid sheetrock mites from getting into the interior material. I'm a bit surprised that some plastic wasn't cheaper; but it seems otherwise sensible enough.
For those who know more than I about the dark arts of RF propagation, what would the effect be of ungrounded conductive sheets? Substantial signal attenuation? Not much effect? Completely unpredictable absorption and re-emmision that could vary wildly according to the exact geometry of the piece?
In a similar vein, if one had an AP/router that one didn't love to much(not so hard when they start at $20...), what would the effect be of attempting to use the metal foil as an antenna, by coupling it directly to the antenna output? Horribly non-optimized for the frequency, I'd imagine; but would it be expected to Not Work, to Not Work and kill the RF amp, to work somewhat, to work better than one might expect?
Incognito mode ('porn mode' to its friends) attacks an entirely different class of privacy problem.
The interpersonal privacy compromise problem is a legitimate one. Potentially embarrassing or worse. Incognito mode does a reasonably effective job of stopping that one(I haven't read up on whether or not the latest forensics packages can do anything against it; but the contents of a closed incognito session are safe enough from your roommate/spouse/kids/nosy sibling/etc.)
Against remote 3rd parties, though, incognito mode is highly limited. It does flush cookies when the session is terminated, which is better than nothing; but with most broadband IPs being close to static, it often isn't rocket surgery to correlate and reconstruct user activity even if you lose some cookies(indeed, being able to run an incognito session and a standard session at the same time and on the same host probably makes that easier, unlike the older, cruder methods where the user manually wiped all their sessions after a period of time).
They are really two entirely different classes of threat.
As much as I think space travel is cool, and the SR-71 was one of the more aesthetically pleasing aircraft ever, and similar sentiments, I can't really muster much pity for the disappointed astronauts and test-pilot types.
There's a saying from the murky world of the intersection between market actors and regulatory agents: "Nobody screams louder than the guy whose subsidy is being cut."
Astronauts, and their ilk, while they did the jobs we offered, fair and square, were (in terms of human speed) some of the most subsidized travellers in history. For a mixture of reasons, some more or less universal(scientific curiosity), some bound up in particular historical moments(Cold war dickwaving and spy games), we made comparatively massive investments in the velocity of a small number of pilots carrying out specific missions. I have nothing against the pilots, who largely executed their missions with skill and nerve; but that doesn't change the fact that those were some of the most expensive tickets in human history, made possible only by certain historical conditions. Those guys were playing with once-in-a-lifetime white elephants, not prerelease prototypes of consumer goods.
(Now, unfortunately, our extraordinary subsidies projects seem to be focused on our parasitic layer of financial services con-men, an entirely crasser class of people, with far fewer virtues and far greater dangers...)
Given the seriously cramped conditions imposed by the Concorde's airframe design(it was necessarily narrow-bodied to reduce drag), and the further crunching induced by trying to get enough paying passengers into the sardine tube to justify the expensive flight, the trade off isn't as straightforward as one might imagine.
From the perspective of comfort and productivity, if the same money can get you a cattle-class seat on a mach 2 bird or a cushy recliner, a power jack for your laptop, and an edible meal on a cost-optimized subsonic one, it isn't at all clear that you'd choose the former.
Given that running the big, cost-optimized subsonic allows the carrier to adjust the split(not quite per-flight; but reasonably quickly) between comfort seats and low cost seats as the market dictates, while the small, supersonic one only allows choosing between expensive discomfort and really expensive comfort, the economics behind running the subsonic craft seem pretty compelling.
While I expect that maximum achievable air speeds(and/or flight paths that incorporate very high speed excursions outside the atmosphere) will continue to advance for specialty applications, mostly military; such developments as "leg room", "laptops that aren't a pain to work on", and "sweet, sweet inflight internet" have likely sealed the commercial fate of very high speed air travel services.
Do you know if the ~150 employees just counts core developers, artists, etc. or does that include the receptionist and the guy who swaps drives on the steam servers and so on?
Unless large parts of the backend are outsourced(which wouldn't be a complete surprise, trying to beat one of the dedicated CDNs at delivering large files to customers all over the place isn't obviously a sensible move when they'd be happy to deliver them for you for a modest fee...) , I have to imagine that steam's physical infrastructure alone would consume a reasonable amount of time and attention, never mind the software development, or the work that goes into figuring out how to make the client hog more system resources.
At least on recent stuff, it typically goes both ways: The motherboard has thermal data from the CPU, and adjusts the output on the PWM line going to the fan, which adjusts its speed. At the same time, to detect fan faults, the motherboard monitors the Tach line coming from the fan. If it doesn't like what it sees, some sort of complaining(from an optional alert on the low end, to a compulsory alert that has to be manually cleared at boot, to just plain shutting down) is typically the result.
As somebody mentioned further up, it wouldn't be rocket surgery to emulate the expected fan signals if needed; but I would expect that a reasonable percentage of management firmwares would at least complain, if not worse, without correctly faked signals.
Microsoft doesn't have an advertising arm, nor is it aggressively moving into IPTV services. Their software platforms also have an excellent record of never being compromised, and the Kinect makes it trivially evident when its mics and/or camera are active.
Thus, there is no possible way in which this could be sinister. I was worried there for a minute...
In systems not designed for it, that could get kind of ugly(DIMMs, riser cards, expansion cards parallel to the motherboard, etc) and having to re-CAD the part because your vendor went to rev A01 from rev A00 or they are now shipping memory modules with slightly different sizes would be a huge pain.
I am told, though, that for very harsh environment embedded systems, that is pretty much what they do. Conformal heatsink plate firmly attached to the board so that the whole thing is a solid block.
All you need is very low ceilings, allowing multiple tiers of racks in what would ordinarily be a 1-story room. You can then hire malnourished Dickensian urchins to scuttle, bent over in a permanent half-crouch, among the dripping coolant tanks, swapping drives and cards... Just remember to flog them frequently, to remind them of their place, or you'll find one cooking his fish-and-chips in the hot-coolant line and clogging the heat exchanger with crumbs.
I imagine that some sort of pneumatic/hydraulic piston system(like the one used on many vertical-open car doors and the like) would be well within the realm of the possible, and offer a zero-apparent-weight slide-up ; but I can't see whether or not there is anything of the sort from the pictures provided.
The one picture showing "easy serviceability" shows the operator having completely unracked a relatively small server. That doesn't scream 'easy' to me. Pull server up, hold with one hand, unclip a bunch of fiddly cables with the other(don't lose them in the oil pit, or you'll have to give the temp a snorkel...) lay it flat, pop the top? Aw hell no. The whole point of slide rails is that you can get to the guts without having to disconnect any cables(unless connected to the particular bit you are swapping, of course) or unrack anything.
All blades would be OK, assuming you never need to get at the back of the blade chassis; but I pity the fool who has to disconnect and reconnect(and be sure to get them back in the right places... those 8 are on different VLANS!) a nasty mess of ethernet cables just to swap a PSU or something.
I suspect that the main advantage over waterblocks is that your server vendor of choice doesn't have to cooperate, and you don't have to run so many small hoses, and can get away with the big huge tank. Now, if some sort of critical mass were achieved in terms of industry acceptance of waterblocks as a factory option(along with some sort of standardized fluid connector), I suspect that that would swiftly become a superior option(though, quite possibly not displacing fans entirely. A fair number of ancillary systems, too small to justify their own waterblocks, get very unhappy if they aren't getting any airflow, even if the CPUs are taken care of...)
I've never tested to see if anything bad happens if you change this yourself; but hard drives are definitely not airtight. Pretty much all of them have one or more visible holes(usually on the top cover, often next to a "Do Not Cover" sticker). There is a fairly serious looking filter on the inside, covering the hole(some sort of fine carbonish powder sealed in what appears to be a teflon pouch); but that is to impede dust, rather than gases.
Nothing stopping you from PXE booting(or iSCSI or fiber channel HBAs on the high end); but I'd be leery of running a hard drive under fluid, except as an experiment.
The only other issue I can imagine might crop up would be discovering the hard way that some polymer used in one of the system's components doesn't handle oil exposure well in the long term. I suspect that most are fine; but if the plasticizer used to soften the insulator coating on some important bundle of wires leaches out over 18 months in a warm oil bath, and the embrittled insulator cracks and shorts the next time you mess with it, the joke would be on you...