The flexible cable race would be a hellish thing to service. It would also add ungodly lengths to your cables. Also, your cabling becomes complex since you have multiple cable races in the same column to wrangle...
A tape library makes it work because it's relatively small. The design does not scale up to a 65 story building.
Though typically office buildings will not design to high degrees of live load, because it's expensive. So yes, you can make tall buildings that can support massive loads, but the cost to do so makes many facilities just stick things in the basement if they do have a high rise, or build at a little more convenient location so they can sprawl out.
Precisely. People saying 'it's tall so it can *be* a chimney or alternatively some have said 'oh, you can suck in air from the top (which isn't right, but for the sake of argument...). Whichever way you believe, if you want a chimney so bad, build a chimney.
It won't cut the cooling cost at all compared to alternative, practical designs. If you are fixated on free air cooling there are a lot of alternative strategies to do that without resorting to a crazy complicated tower (or even a pretty mundane high-rise).
If you care about cooling, water cooling would be a lot more bang for the buck. You can do chiller-free designs, and waste heat recovery. Sure there are going to be impellers in play, but the draw is not as significant. The general blocking point is the upfront cost, but if you are considering going to crazy combine-citadel architecture, this would be much cheaper. Contrary to the imagination of architects and readers, 'free air cooling' still needs fans to move the air (the tendency of hot air to rise is not adequate, and even if it were, you'd be fighting the geometric realities of the electronic components in play),
Each column has an elevator. Said elevator means only one pod may be serviced in a column at a time. If said elevator breaks, you have no alternative access to that column. The electrical infrastructure needed to make that work for the massive volume of electricity to a pod is unreasonable (and therefore at high risk of knocking out an entire pod on servicing a component). This all adds up to a great deal of expense and limited serviceability for..... no benefit really except looking exotic and having low footprint (and a more traditional high rise would be more practical for low foot print, though most people underestimate just how much weight we are talking and how relatively little weight high rises typically build to support due to the complexity and cost.
Thermodynamics are simply not on the side of this being a particularly better cooling design. The only remotely true claim is that equipment is close to external air (which is rarely reliably cold enough, but that aside...), but there are much easier ways to get to fresh air if that's the goal.
Typically for these contest winning architect concepts, they are render-op first and... well stay that way because no one will ever build it because the architect is limited only by his imagination and artistic sensibilities, and is only interested in throwing practical sounding buzzwords vaguely at it.
Just FYI, I think these are cool things to get rendered up, just find it odd when people take it seriously. E.g. http://www.discovery.com/dscov....
There's no way that solar could drive this. To even get close, you'd need a sea of reflectors. At which point, you might as build a sprawling datacenter because that would be cheaper anyway.
Because if a general purpose freight elevator is too expensive, hard to maintain, etc, a highly customized application specific freight elevator dedicated to a column of racks would surely be the cure.
This is a rather stylish looking concept that might be at home in some sci-fi media, but it is a horribly impractical concept to actually implement in real life.
Same reason you don't see skyscrapers except in the middle of very urban centers. It's much, much more money to build up than out. Many facets of maintenance are much more complicated with a tall facility. Having to deal with elevators and having to have a large volume of freight elevators is very tricky. So on and so forth.
And for a large chunk of applications, a cheaper approach would be to build it 15-30 miles away from the expensive area.
However, architects regularly post pie in the sky, not fleshed out ideas to catch the eyes of companies that will build real, more down to earth projects inspired by the wacky concept art of an exotic thing.
I'd probably say something a little less severe. A browser environment should be able to do more, but it should be presumed *not* to be able to do any particular new thing until carefully considered and planned.
For example, I'm all fine with a browser being able to access a camera, with browser requiring a very clear and specific prompt for allowing that site to use a camera. It's something handy and specific enough that a user can make an informed decision based on pretty simply wording.
Basically, specific use cases should be evaluated and given a mechanism for use with clear capability to have specific security controls if it has widely perceived value.
However, nothing should be enabling the browser to be an open-ended execution environment, as it makes it pretty much impossible for a standard user to understand the possibilities they just granted a remote site.
When the vendors are doing such lazy crappy things, trying to enable them is not the answer.
Those vendors doing sloppy things lead to very unstable and insecure things. These vendors are actually largely to blame for the poor security/reliability of Windows ecosystem in practice, despite MS actually having done an adequate job of making a decently sound security infrastructure. If you avoid the shovelware, Windows tends to run OK. This would enable OS destabilizing/security problems from a browser.
But how much do you put within reach of the sandbox? Given the open ended nature of the beast, what are the hopes that a browser can competently present a user with a specific enough warning about what's about to happen to allow them to make an informed decision?
I'd rather not bind USB devices to only work under a web browser.
It's the job of the OS to manage the hardware. To codify a bypass to let a particular application do whatever it wants seems unreasonable.
Note for USB devices, this is relatively more rare, as the USB forum codifies standards so that different vendors of common devices all look the same. A usb mass storage device has the same abstraction regardless of underlying technology. A usb network device is implementing one of a handful of network protocols (there have been some revisions on that setup). A usb camera looks the same regardless of vendor.
So if you have some wacky precious snowflake of a device that is so cutting edge that no driver model has been established for it, this lets a hypothetical web app skip a few months of hand wringing waiting for a standard. In exchange for this modest benefit, you are discouraging pursuit of standards, empowering javascript to do more insidious things, and discouraging device support for non-browser access (there are more applications on a system than a web browser, and encouraging device vendors to target the browser *instead* of the OS driver model is just nasty).
It seems the goal is to empower developers to skip the pesky wait for actually standardizing around 'novel' device types by giving the browser pretty open ended access to USB devices...
As a rule, I do not believe OSes themselves allow open ended access to any device by an unprivileged user process (e.g. a browser process), USB or otherwise. So it would seem the OS model for hardware would be in the way. Incidentally, this problem should be taken as a huge red flag as why this may be an ill-conceived idea.
I would worry that should this strategy be encouraged, we would see devices that *only* are usable within a web browser. This is the first time I can recall any managed runtime environment trying to implement an independent driver model of the underlying OS. This strikes me as particularly bad form.
In general, Javascript can't even access arbitrary files owned by the user. This is a good thing. This is flying pretty firmly in the face of Javascript in browser being a domain specific language that has *some* security by virtue of explicitly not being allowed to do everything to a system.
What you describe sounds reasonable. I don't think I've heard anyone proclaim DevOps to be that rather than starting to apply particularly hyped tools to a process indiscriminately. I suppose unsurprisingly a recommendation about something like modifying your philosophy about planning would not get any attention, since there's no profit to be had in that sort of interpretation.
So.... like every other big technology buzzword since the history of the industry?
It's really a tiresome industry in that respect. Lot's of real stuff happening, but far more weird marketing bullshit for utterly inane stuff.
It'd be like if a new socket wrench came out and made headlines for it's new approach to manipulating bolts. People would rightfully wonder why the hell a bunch of articles are being written about something so banal. In IT, somehow it's exciting...
requires a complete change from how business is used to doing things
The question being for a lot of organizations is what the upside will *really* be. Yes, if you redo a lot of your work, many things can work in that architecture. Not all things really work that well. But at the end, how do you end up better than before? Is it faster deployment of workload, lower staff cost to service requests? Could an alternative strategy have delivered the benefit in a way more compatible with the way your business works today? Will the imagined benefit really materialize given the wider context of your particular organization? It's a complicated set of questions that I worry is not considered carefully enough by most adopters.
Things like docker are easy enough to add on to infrastructure non-disruptively, a sort of technology that can be deployed without being too demanding about urgent changes to how the business works. If it gets ignored, oh well, no harm done. If it gets sunset, again no big deal for those who weren't using it. Openstack is a bit more disruptive and demanding and so warrants a bit more careful approach, and looks much uglier if the transition does not work out and requires a fair effort to backtrack..
This is of course true, but a lot of the OpenStack community were pretty content to let misrepresentation in their favor run rampant, until folks started screwing themselves by listening to the hype.
As I said, it's a dilemma for a commercial effort (BeOS was). BeOS without revenue could not continue, and they did not elect to release it to the world.
Now turn to say something like say AROS, utterly obscure, but a healthy community. As a company, sure they'd never survive, but as a hobbyist effort, they do good by their users.
large sunk investment it takes to be able to use the feature
Actually, my experience is that there isn't that much of a sunk investment difference. Sure it takes work to get server workloads going right, but Windows isn't really better on that front. This may be hard for a Windows desktop user to believe, but Windows Server for typical server use can be a major pain (well, file and print sharing is easy enough, but beyond that...)
The users shouldn't be rooting for 'winning' the desktop away. They should be rooting for the best experience *they* want.
In terms of the rest of your anti-Linux desktop rant: -People rarely have to even think about compiling a driver these days (and in fact I find most linux desktop installs don't even have a C compiler, which was an unheard of approach in late 90s. -Multiple DEs does not mean a user actually has to ever deviate from the default environment. I see plenty of folks using Unity or Gnome shell without really thinking about it (though I personally I'm not a fan, my opinion does not detract from their experience unless I make it so) -Of all the distros, there's only a couple of options that people even know about at any given time, and this has pretty much been the case since near the beginning. Slackware, Debian, Redhat, SuSE, and Mandrake were the only 4 people knew in the wild west 90s. Now, people generally know about Ubuntu, Mint, and/or RedHat/Fedora.
Note by the way, the monoculture of the PC market is an anomaly for society rather than the norm. Cars are not 'tuned out' because you have dozens of manufacturers, each churning out dozens of models. People stick with what they know and generally ignore what they don't care about.
That sensibility is fine I suppose, but the problem is that the project has not been so restrained when it comes to how it is evangelized.
Years ago I saw a virtualization management software team pretty much get disbanded, because some high level engineer told executives that Openstack was utterly share nothing, resilient, stable, easy to use, and equipped to do everything an enterprise virtualization user would possibly want, so developing software geared toward enterprise virtualization management was a lost game.
Around the same time, an organization doing *nothing* cloud related or even virtualization related was directed to rebase all their efforts on Openstack, because leadership was told that OpenStack was already the way *everybody* did everything with Linux. That group lost about 6 months of time to first figuring out it wouldn't be so easy, that it really wouldn't work at all, and finally convincing their leadership that Openstack was, in fact, *not* covering everything.
I don't know how it turned out, but I also was in the early stages of a very large customer datacenter revamp. They had thousands of systems largely running vmware. Their executive said 'we will move to 100% openstack within the year'. Turned out they had made this decision based solely on write ups and never actually used the software. This was about the time I moved on to another company, so I didn't see how that turned out. Keep in mind that was about 3 years ago.
I'll also say that not providing those functions when the lower level software does provide it isn't exactly a virtue. I understand how an implementation may make certain storage and networking decisions that would make it a bad idea to provide the features, but for the higher layer software to not even give a choice... it's dubious. Also early on the word 'share nothing' was flung along a lot, with 'oh, except for the MySQL database, but someone will probably rearchitect that'.
The way OpenStack evangelizes itself has caused unfortunate side effects in a lot of areas, sucking up all the attention for something that is much narrower in scope than people will talk about it. I will say that fortunately, the buzz around Openstack has seemingly settled down a great deal, but I do not like the damage it caused on the way.
I would expect it to be more about a single utility frontending the same apis.
My bigger concern would be whether this meaningfully simplifies things, or, as is more common, is just a prefix word making commands more verbose without much benefit.
Perhaps in this context 'success' is best defined by how satisfied your users are, not by how numerous your users are.
Any ambition to expand the quantity runs the risk of making decisions to appease hypothetical users that compromise the satisfaction of your loyal users. This is of course a dilemma for a commercial endeavor that thrives on revenue, but for a community effort the urge is less pronounced (financially the ecosystem is sustained by mobile and server space, so the desktop should be free to be an unapologetic power user environment).
Sorry, it's when all the OEMs jump out of bed with microsoft. Nothing short of that will pave the way. 99.5% of people don't care about the desktop. Any of them are good enough. They take what comes in the box, no muss, no fuss. There isn't a desktop platform design possible that would make today's computer consumer base a purchasing decision or go to the trouble of reloading the OS.
In the meantime, chasing the hopeless, non-technical goal of 'displacing windows' leads to all sorts of mischief and degradation of the desktop experience.
Slashdot Mirror
The flexible cable race would be a hellish thing to service. It would also add ungodly lengths to your cables. Also, your cabling becomes complex since you have multiple cable races in the same column to wrangle...
A tape library makes it work because it's relatively small. The design does not scale up to a 65 story building.
Though typically office buildings will not design to high degrees of live load, because it's expensive. So yes, you can make tall buildings that can support massive loads, but the cost to do so makes many facilities just stick things in the basement if they do have a high rise, or build at a little more convenient location so they can sprawl out.
Precisely. People saying 'it's tall so it can *be* a chimney or alternatively some have said 'oh, you can suck in air from the top (which isn't right, but for the sake of argument...). Whichever way you believe, if you want a chimney so bad, build a chimney.
It won't cut the cooling cost at all compared to alternative, practical designs. If you are fixated on free air cooling there are a lot of alternative strategies to do that without resorting to a crazy complicated tower (or even a pretty mundane high-rise).
If you care about cooling, water cooling would be a lot more bang for the buck. You can do chiller-free designs, and waste heat recovery. Sure there are going to be impellers in play, but the draw is not as significant. The general blocking point is the upfront cost, but if you are considering going to crazy combine-citadel architecture, this would be much cheaper. Contrary to the imagination of architects and readers, 'free air cooling' still needs fans to move the air (the tendency of hot air to rise is not adequate, and even if it were, you'd be fighting the geometric realities of the electronic components in play),
Each column has an elevator. Said elevator means only one pod may be serviced in a column at a time. If said elevator breaks, you have no alternative access to that column. The electrical infrastructure needed to make that work for the massive volume of electricity to a pod is unreasonable (and therefore at high risk of knocking out an entire pod on servicing a component). This all adds up to a great deal of expense and limited serviceability for..... no benefit really except looking exotic and having low footprint (and a more traditional high rise would be more practical for low foot print, though most people underestimate just how much weight we are talking and how relatively little weight high rises typically build to support due to the complexity and cost.
Thermodynamics are simply not on the side of this being a particularly better cooling design. The only remotely true claim is that equipment is close to external air (which is rarely reliably cold enough, but that aside...), but there are much easier ways to get to fresh air if that's the goal.
Typically for these contest winning architect concepts, they are render-op first and... well stay that way because no one will ever build it because the architect is limited only by his imagination and artistic sensibilities, and is only interested in throwing practical sounding buzzwords vaguely at it.
Just FYI, I think these are cool things to get rendered up, just find it odd when people take it seriously. E.g. http://www.discovery.com/dscov....
There's no way that solar could drive this. To even get close, you'd need a sea of reflectors. At which point, you might as build a sprawling datacenter because that would be cheaper anyway.
Because if a general purpose freight elevator is too expensive, hard to maintain, etc, a highly customized application specific freight elevator dedicated to a column of racks would surely be the cure.
This is a rather stylish looking concept that might be at home in some sci-fi media, but it is a horribly impractical concept to actually implement in real life.
It doesn't remind me of Star Trek, it more reminds me of stuff built by the combine in half life 2.
Same reason you don't see skyscrapers except in the middle of very urban centers. It's much, much more money to build up than out. Many facets of maintenance are much more complicated with a tall facility. Having to deal with elevators and having to have a large volume of freight elevators is very tricky. So on and so forth.
And for a large chunk of applications, a cheaper approach would be to build it 15-30 miles away from the expensive area.
However, architects regularly post pie in the sky, not fleshed out ideas to catch the eyes of companies that will build real, more down to earth projects inspired by the wacky concept art of an exotic thing.
I'd probably say something a little less severe. A browser environment should be able to do more, but it should be presumed *not* to be able to do any particular new thing until carefully considered and planned.
For example, I'm all fine with a browser being able to access a camera, with browser requiring a very clear and specific prompt for allowing that site to use a camera. It's something handy and specific enough that a user can make an informed decision based on pretty simply wording.
Basically, specific use cases should be evaluated and given a mechanism for use with clear capability to have specific security controls if it has widely perceived value.
However, nothing should be enabling the browser to be an open-ended execution environment, as it makes it pretty much impossible for a standard user to understand the possibilities they just granted a remote site.
When the vendors are doing such lazy crappy things, trying to enable them is not the answer.
Those vendors doing sloppy things lead to very unstable and insecure things. These vendors are actually largely to blame for the poor security/reliability of Windows ecosystem in practice, despite MS actually having done an adequate job of making a decently sound security infrastructure. If you avoid the shovelware, Windows tends to run OK. This would enable OS destabilizing/security problems from a browser.
But how much do you put within reach of the sandbox? Given the open ended nature of the beast, what are the hopes that a browser can competently present a user with a specific enough warning about what's about to happen to allow them to make an informed decision?
I'd rather not bind USB devices to only work under a web browser.
It's the job of the OS to manage the hardware. To codify a bypass to let a particular application do whatever it wants seems unreasonable.
Note for USB devices, this is relatively more rare, as the USB forum codifies standards so that different vendors of common devices all look the same. A usb mass storage device has the same abstraction regardless of underlying technology. A usb network device is implementing one of a handful of network protocols (there have been some revisions on that setup). A usb camera looks the same regardless of vendor.
So if you have some wacky precious snowflake of a device that is so cutting edge that no driver model has been established for it, this lets a hypothetical web app skip a few months of hand wringing waiting for a standard. In exchange for this modest benefit, you are discouraging pursuit of standards, empowering javascript to do more insidious things, and discouraging device support for non-browser access (there are more applications on a system than a web browser, and encouraging device vendors to target the browser *instead* of the OS driver model is just nasty).
It seems the goal is to empower developers to skip the pesky wait for actually standardizing around 'novel' device types by giving the browser pretty open ended access to USB devices...
As a rule, I do not believe OSes themselves allow open ended access to any device by an unprivileged user process (e.g. a browser process), USB or otherwise. So it would seem the OS model for hardware would be in the way. Incidentally, this problem should be taken as a huge red flag as why this may be an ill-conceived idea.
I would worry that should this strategy be encouraged, we would see devices that *only* are usable within a web browser. This is the first time I can recall any managed runtime environment trying to implement an independent driver model of the underlying OS. This strikes me as particularly bad form.
In general, Javascript can't even access arbitrary files owned by the user. This is a good thing. This is flying pretty firmly in the face of Javascript in browser being a domain specific language that has *some* security by virtue of explicitly not being allowed to do everything to a system.
What you describe sounds reasonable. I don't think I've heard anyone proclaim DevOps to be that rather than starting to apply particularly hyped tools to a process indiscriminately. I suppose unsurprisingly a recommendation about something like modifying your philosophy about planning would not get any attention, since there's no profit to be had in that sort of interpretation.
So.... like every other big technology buzzword since the history of the industry?
It's really a tiresome industry in that respect. Lot's of real stuff happening, but far more weird marketing bullshit for utterly inane stuff.
It'd be like if a new socket wrench came out and made headlines for it's new approach to manipulating bolts. People would rightfully wonder why the hell a bunch of articles are being written about something so banal. In IT, somehow it's exciting...
requires a complete change from how business is used to doing things
The question being for a lot of organizations is what the upside will *really* be. Yes, if you redo a lot of your work, many things can work in that architecture. Not all things really work that well. But at the end, how do you end up better than before? Is it faster deployment of workload, lower staff cost to service requests? Could an alternative strategy have delivered the benefit in a way more compatible with the way your business works today? Will the imagined benefit really materialize given the wider context of your particular organization? It's a complicated set of questions that I worry is not considered carefully enough by most adopters.
Things like docker are easy enough to add on to infrastructure non-disruptively, a sort of technology that can be deployed without being too demanding about urgent changes to how the business works. If it gets ignored, oh well, no harm done. If it gets sunset, again no big deal for those who weren't using it. Openstack is a bit more disruptive and demanding and so warrants a bit more careful approach, and looks much uglier if the transition does not work out and requires a fair effort to backtrack..
This is of course true, but a lot of the OpenStack community were pretty content to let misrepresentation in their favor run rampant, until folks started screwing themselves by listening to the hype.
As I said, it's a dilemma for a commercial effort (BeOS was). BeOS without revenue could not continue, and they did not elect to release it to the world.
Now turn to say something like say AROS, utterly obscure, but a healthy community. As a company, sure they'd never survive, but as a hobbyist effort, they do good by their users.
large sunk investment it takes to be able to use the feature
Actually, my experience is that there isn't that much of a sunk investment difference. Sure it takes work to get server workloads going right, but Windows isn't really better on that front. This may be hard for a Windows desktop user to believe, but Windows Server for typical server use can be a major pain (well, file and print sharing is easy enough, but beyond that...)
The users shouldn't be rooting for 'winning' the desktop away. They should be rooting for the best experience *they* want.
In terms of the rest of your anti-Linux desktop rant:
-People rarely have to even think about compiling a driver these days (and in fact I find most linux desktop installs don't even have a C compiler, which was an unheard of approach in late 90s.
-Multiple DEs does not mean a user actually has to ever deviate from the default environment. I see plenty of folks using Unity or Gnome shell without really thinking about it (though I personally I'm not a fan, my opinion does not detract from their experience unless I make it so)
-Of all the distros, there's only a couple of options that people even know about at any given time, and this has pretty much been the case since near the beginning. Slackware, Debian, Redhat, SuSE, and Mandrake were the only 4 people knew in the wild west 90s. Now, people generally know about Ubuntu, Mint, and/or RedHat/Fedora.
Note by the way, the monoculture of the PC market is an anomaly for society rather than the norm. Cars are not 'tuned out' because you have dozens of manufacturers, each churning out dozens of models. People stick with what they know and generally ignore what they don't care about.
That sensibility is fine I suppose, but the problem is that the project has not been so restrained when it comes to how it is evangelized.
Years ago I saw a virtualization management software team pretty much get disbanded, because some high level engineer told executives that Openstack was utterly share nothing, resilient, stable, easy to use, and equipped to do everything an enterprise virtualization user would possibly want, so developing software geared toward enterprise virtualization management was a lost game.
Around the same time, an organization doing *nothing* cloud related or even virtualization related was directed to rebase all their efforts on Openstack, because leadership was told that OpenStack was already the way *everybody* did everything with Linux. That group lost about 6 months of time to first figuring out it wouldn't be so easy, that it really wouldn't work at all, and finally convincing their leadership that Openstack was, in fact, *not* covering everything.
I don't know how it turned out, but I also was in the early stages of a very large customer datacenter revamp. They had thousands of systems largely running vmware. Their executive said 'we will move to 100% openstack within the year'. Turned out they had made this decision based solely on write ups and never actually used the software. This was about the time I moved on to another company, so I didn't see how that turned out. Keep in mind that was about 3 years ago.
I'll also say that not providing those functions when the lower level software does provide it isn't exactly a virtue. I understand how an implementation may make certain storage and networking decisions that would make it a bad idea to provide the features, but for the higher layer software to not even give a choice... it's dubious. Also early on the word 'share nothing' was flung along a lot, with 'oh, except for the MySQL database, but someone will probably rearchitect that'.
The way OpenStack evangelizes itself has caused unfortunate side effects in a lot of areas, sucking up all the attention for something that is much narrower in scope than people will talk about it. I will say that fortunately, the buzz around Openstack has seemingly settled down a great deal, but I do not like the damage it caused on the way.
I would expect it to be more about a single utility frontending the same apis.
My bigger concern would be whether this meaningfully simplifies things, or, as is more common, is just a prefix word making commands more verbose without much benefit.
Perhaps in this context 'success' is best defined by how satisfied your users are, not by how numerous your users are.
Any ambition to expand the quantity runs the risk of making decisions to appease hypothetical users that compromise the satisfaction of your loyal users. This is of course a dilemma for a commercial endeavor that thrives on revenue, but for a community effort the urge is less pronounced (financially the ecosystem is sustained by mobile and server space, so the desktop should be free to be an unapologetic power user environment).
Sorry, it's when all the OEMs jump out of bed with microsoft. Nothing short of that will pave the way. 99.5% of people don't care about the desktop. Any of them are good enough. They take what comes in the box, no muss, no fuss. There isn't a desktop platform design possible that would make today's computer consumer base a purchasing decision or go to the trouble of reloading the OS.
In the meantime, chasing the hopeless, non-technical goal of 'displacing windows' leads to all sorts of mischief and degradation of the desktop experience.