There ARE, interestingly enough, network protocols (such as BACNet) specified and approved for use in HVAC and other heavy-duty systems for intelligent controlling of devices by computer. Open Source implementations exist for these protocols. There are other embedded systems and remote devices control protocols: Supervisory Control and Data Acquisition (SCADA, widely used by power generator companies), Controller Area Network (CAN, maybe in Linux, either now or soon) and Fieldbus are the two I know with open Source implementations. You could probably even use SCTP (already in Linux), SS7 or Active Messaging. Such systems aren't fast, so ACE's CORBA could do the trick. Grid Resoures for Industrial Applications also looks interesting. There's also the Open Robot Control Systems project. Domestic and street-level devices to control may not be widely available (or perhaps exist), but the low-level infrastructure certainly does.
My question is not, then, why it is not in wide use, but rather why it took me a long time to dig up the project information on these protocols, why information tends to be very sparse from the hobyist/garage community, why there are no Woznik Mk. II's providing homebrewed household systems, or Prof. Heinz Wolff II's running an X-Prize for such systems. All the foundation work has been done, the protocols are all available, the proofs of those systems exist in many of the more sophisticated facilities, everything that preceeded the hardware revolution in microcomputers has for many years also existed in the domestic appliance level and even the local substation level. What we have not seen is much of a garage revolution, the way we have for many other technologies. X10's aility to turn lights on and off seems to have been about the closest attempt.
Don't expect the Big Guys to do it. If there are trains that don't support regenerative braking yet, given the state of the rail network, then it is reasonable to assume nobody else in the upper echelons is going to care. This stage has invariably, for virtually all technologies out there today - including television and radio, been carried out by hobbyists, enthusiasts and homebrewers. My guess would be that if those hobbyists don't hobby along soon, this concept will simply never enter any market ouside of the real high-end. Mainframes will rule forever and the micro of the appliance world will never exist.
I'm fairly certain that authoritarian, despotic organizations would ALSO advocate beating children. Are we to assume from the lack of a contemporary reference that Jack Thompson feels safer using historical references most people never experienced - and those that did would barely remember? That references to, oh, any of the truly major world-horrifying cases of true, ultra-pure evil in Austria or Belgium would be too risky owing to the similarity between advocated mindset and the truly monsterous? That anything people could meaningfully comprehend would be more likely to be seen as condemning of the Jack Thompsons of the world?
Don't get me wrong - I regard Take Two as an excellent representation of Dante's Inferno, given the way they treated David Braben and others, and shock/gore games strike me as very childish, but amoral "moralists" (Mary Whitehouse was another) who use cultist techniques to "program" the more easily-swayed segments of the population to believe their propoganda are far far worse than those they seek to suppress. It seems to me that of the Four Horsemen of the Apocolypse, Famine has retired in favour of FUD. There really are some fates worse than death, and perverted mind-control games would be one of them.
How to define useful. That's actually a very good question and critical in the understanding of environmental impact. Is a game useful? Depends on perspective. Is MSN useful? Well, ok, I'll skip that one. I guess I consider a computer as an electronic enzyme, something that converts an input into an output without consuming itself in the process. One step is not necesarily enough to produce the type of output desired, so there may be quite an extensive chain of conversions. Eventually, though, you produce an output. This may be a spreadsheet, this may be a database record view, this may be the next frame in a video game.
Going by this description, the useful work is the conversion itself. That fraction of the entropy is an inevitable consequence of what you are trying to do. The "non-useful" work is any overhead required by this electronic enzyme that is not a part of the conversion but is required in order for that computer to perform it. This is a function of the technology, not the problem, and is infinitely variable and controllable, but will never be zero and cannot be better than the ability to steer it.
Are computers bad for the environment? By this definition, no more (and no less) than any other enzyme, in the abstract. Specific solutions, specific computers, may be worse. The original Itanium was notoriously inefficient, for example. There was a lot of overhead within the CPU itself. Also, some CPUs, in an effort to reduce the power requirements, have too small a cache and do a lot of non-useful work in the form of spinning round in small circles waiting for something to do. Systems with shared resources are also prone to stalling, as are systems with excessively dedicated resources. It's a difficult balancing act. It has taken nature four billion years to produce systems with gigantic chains that frequently stall or malfunction.
Well, I agree that the statistics are useless in and of themselves, but to be fair, how many data centres are actually doing useful work? Point-to-point streaming of broadcasts, for example, is a horrible waste of CPU power and bandwidth, but it is the dominant method used by webcam services. OS overheads are often unnecessarily high, due to the running of excess services or inefficient code. Server rooms are often run far too hot and cooling methods are often inefficent.
If we measure greenhouse gas production, not as an absolute but as a percentage relative to what is actually required to do the useful component of the work, my guess would be that data centres do not work out to be that green.
Firstly, I really can't see Microsoft being able to do much towards improving its OS if it was unable to provide the internal API in the US anti-trust case (no such documentation apparently existed). It's hard to fix something safely if you don't know why or how it works in the first place. Bugs may be depended upon, for example, and you'd never know until that specific arc through the code was hit in testing.
Secondly, a cynic (such as myself) might suspect Microsoft pulled out of what most speculators considered a done deal in order to massively deflate Yahoo's value so it could be bought later at a fraction of the price. Not that Yahoo has done itself any favours in this process by effectively stoking up the speculation and failing to add much value to its service. I use Yahoo's email service because its cheap, not because its any good, and the "new, improved" web mail service is infinitely heavier, slower and less reliable.
Alternatively, a cynic might argue that no deal was ever really intended, that there was some intent by Microsoft to damage rivals rather than improve their own services. It wouldn't be the first time, if that was the case, but I'm not seeing any real damage beyond perhaps shareholder confidence.
Since the Japanese has 1Gb/s links to the home and the RIAA/MPAA knows Americans are the more advanced culture, they obviously need to work on the assumption that everyone would have 10Gb/s links at least. It stands to reason, after all. Especially if they can get a larger fine out of the deal, and it's not like a judge would know what network speeds are meaningful. (If they did, the RIAA/MPAA would be being dangled over a crocodile pit by now.)
must concern lawful activity: A lot of the "products" advertised don't exist. I would consider this unlawful, but then I see everything else advertised on TV, radio, billboards, McDonald's windows...
and not be misleading: See above, and add in any movie trailer that uses the words "exciting", "dramatic" or "thrilling".
By this standard, virtually all commercial speech should be prohibited. Admittedly, this might lead to a gigantic leap in the quality of products and services, a massive reclamation of land, bandwidth and other resources, and the undoing of years of brainwashing. The inprisonment of the entire advertising sector would also slash pollution levels, accelerate web speeds by three orders of magnitude, and be directly responsible for bringing civilization to whole new heights of wisdom and enlightenment.
In the UK, if a person file and loses an appeal in which the State counter-claims that the original sentance was unduly lenient, the appeal court judges can increase the sentance. This is one of the very, very, very few cases in which such a law could be considered justified. Unfortunately, printing out a representative sample of his spam e-mails and making a paper mache coffin out of it to decorate his prison cell might run counter to the cruel and unusual punishment clause.
The life question is easy. James Lovelock demonstrated that planets devoid of life will have a composition totally distinct from any planet bearing life. You do not need to know what the life is, the chemistry, the complexity, etc. You need only look at the stability of the system. Stable systems have no life. Unstable systems do. Indeed, he demonstrated by means of the Daisyworld hypothesis that in order for a system containing life to remain containing life, the life on it must alter the system so as to provide negative feedback on desirable attributes, and the reduction in that organism increases its viability. This must take place with a chemistry that is unstable in the environment, or it'll overrun the environment and wipe itself out. Any other dynamic is self-destructive.
What you want to look for is not a planet with X, Y or Z in terms of chemical components in the atmosphere, but evidence of a dynamic equilibrium actively maintained by a minimum of two opposing negative feedback loops that involve highly unstable components in the atmosphere. Since there will be day and night, and seasons, different points on the planet will register different prevailing feedback loops. These conditions cannot arise in a wholly inorganic environment. An inorganic environment may be chaotic (the atmospheres of Saturn and Jupiter, for example) or very basic (as in the case of the surface of Pluto) but the systems are relatively basic. They are simple chemical systems, passively reacting to the occasional direct strike by a comet, but there is nothing metastable or unstable about any of those examples. If anything, they are remarkable in their stability.
It is planets whose chemistry should be violently unstable but are actively held in dynamic equilibrium that are interesting. Those have processes that are in the realms of what we would consider living matter, and outside the realms of the non-living.
What about intelligent life? First define intelligence, and then secondly prove there's any on Earth. If we don't know what we're looking for, or how to recognize it if we find it, then such a search is futile. I regard SETI as more of a research lab for advanced theories into digital signal processing. It won't be useful until the one kilometer array is active, and the planned closures in Britain inclclude key parts of that array. We also need very very powerful signals processing - a million channels, or even half a billion, isn't much. We don't even know if we want the radio or optical spectrums. So, two arrays - one radio, one optical - at a kilometer diameter and, oh, say a trillion channels being monitored and analyzed with rather better signals theory than SETI@Home use. When will this happen? Never. That, then, is the earliest alien intelligence can be passively detected by us.
Your letter was lost in the mail. We searched and searched, but didn't find it. As a result, we're going to bill you for half a billion dollars. If we find the letter and discover any money in it, we'll keep that that as well. And if there's anything blackmailable in it...
They have set up an 8x8 grid of processors, not unlike a chessboard. Each square on this grid can talk only to adjacent squares (up, down, left, right), with the edge squares connecting to I/O devices. They refer to their network as a mesh, but the correct term for this design is a Manhattan Network. This is not significantly different from a processor I dearly loved in the late 80s, the Transputer. That, too, had 4 connections from each processor, but you were not restricted in how you connected the Transputers together. A grid, it transpired, was not efficient, you needed to arrange the connections to form a hypercube. (Yes, it's 2D, so it's actually a 2D representation of a hypercube. Now stop fussing or I won't get you that Beowulf cluster for Christmas.)
I like the idea, I like the idea a lot, but the fact that they opted for a simple but slow topology doesn't fill me with hope. Especially as they suggest running SMP over it. Processors close to the centre of the "mesh" will be resource-starved. There needs to be strong affinity of a given thread to a given core, where the weighting is by the operations expected and where that weighting can (and will) shift as code blocks change or new threads start. In other words, you want something that is semi-static, semi-dynamic according to need. Only the OS is capable of obtaining that kind of information, so it is the OS that needs to do the dividing, NOT the architecture underneath OR a system administrator.
Actually you might want to imagine a Beowulf cluster of them. You'd more likely run MOSIX or OpenMOSIX on the chip to handle the migration from logical machine to logical machine on the same chip, but you can't then use that to build a cluster as you'd get a conflict between the cluster and cluster-of-clusters. SMP and virtualization might work, but there's minimal messaging between nodes and SMP technology doesn't scale well beyond 16 nodes, so a clustering technology seems a more logical way to go.
Not always. Some companies abuse the term to mean a closed source driver for an open source OS. This isn't open source at all, as we're all perfectly well aware, but marketroids are less interested in reality as they are in exploitable buzzwords.
Certain aspects of a driver depend on the hardware alone and are platform-agnostic. (Let's say some company had an ethernet chipset and chips for PCI and Hypertransport, and made two versions of their card, one PCI-whatever, the other Hypertransport. Oh, the chipset uses an abstract signalling and abstract messaging mechanism. Their bus chips convert these into the form appropriate for the bus and vice versa. The messages you pass to the chipset will be the same for both versions. The transport doesn't change anything. Of course, this scenario is so rare that it's not really considered in driver development, but it actually is a legitimate point of abstraction and would give hardware vendors a good many more platforms they could sell to.)
Other aspects of a driver depend on the bus being used. (This could be abstracted out entirely into a virtual transport layer, however you'd get the performance hit from hell unless it's done in hardware and the only companies capable of getting a big enough slice of market for this to be worth considering are the companies selling busses - exactly not the people who would want abstraction systems that could help competitors.)
Yet other aspects depend on the OS. (Ignoring for now the bus abstraction, the OS dictates how the driver can be communicated with, how data is passed in/out - and in what form, whether or not the driver can be internally threaded, whether or not the driver can be multiply called, what IPC mechanisms exist and what locking mechanisms exist. A lot of that information could be masked by a suitable OS abstraction layer.)
Where speed is critical, there may even be aspects that depend on the CPU instruction set.
The reality is that you can't make drivers efficient and OS-agnostic, although you can do one or the other. That's a pity, because if you could, then it wouldn't matter if the manufacturers thought of themselves as making Linux drivers. There would be no significant penalty running them under any *BSD. The manufacturers might be happier, too, as it would cut down on how many OS' they needed to write for. There again, they might not, as it would expose more supposed secrets and would eliminate OS favouritism.
As things stand, drivers are very tightly written and OS-specific. An abstraction layer to run Linux drivers under a *BSD would still be possible, but largely pointless except for researching the driver's characteristics. Even highly specialized closed-source drivers with oodles of protection against analysis would be better reverse-engineered than wrappered.
Server hardware does NOT have 100% support, or anything like. I won't list all examples, but here's a few you can think about:
Broadcom BCM91250
Non-Mellanox Infiniband
Some Compaq RAID controller modules
PCI Express 2.x (full specification)
Infiniband 3 (full specification)
VME and VXI busses
Fieldbus support is minimal to non-existant
SCADA support is negligible to non-existant
BACnet support is negligible to non-existant
VAX architecture (it's still used, so it's still part of that 100%)
ARM-based AMULET CPUs
Most TCP Offload Engines
LEON support is abandonware
Some of these you may argue are not "server". They're not webserver or database server, perhaps, but a data acquisition device that stores and later delivers specified data on request is damn well a server. The fact that it's stored, specified and on demand, rather than digested and passed on, distinguishes a true server from any other type of (usually) headless device. If you specify a category narrow enough, there will always be 100% support for it. If you want to guarantee that, start with the 100% and change the definition to fit. If you prefer something a little more useful, then take the definition and explore how things in the Linux world work within that definition. Traditional servers are almost entirely passive when it comes to external connections. Something else has to initiate a connection. Modern servers sometimes do a little bit of active networking - broadcasts and multicasts to identify services, for example, and in clusters, servers will routinely push activities and data to other servers. However, they are fundamentally passive on networking and highly active on processing and data crunching. Streaming servers and VOD servers are generally transmitting on-demand, so are still passive recipients of the request. They don't do anything on their own. Sites streaming webcams by multicast or whatever are blindly sending in a way that's not much different than an announcement. In both cases, it's intended for processing by clients but not replying to. It's not part of an exchange, it's just a blind send. Thus, such systems are also servers.
Clients may passively receive broadcasts and multicasts, but actively initiate all conversations (with the special case of PUSH technology, but there the client really becomes a temporary server, and the server a temporary client, so the definitions still hold true - besides which, when was the last time you saw anyone use PUSH?!)
The technologies I listed are not client technologies, they are server technologies, although there's no reason a client couldn't have those hardware components. It'd just be a very heavy client.
You have your music on a central server at a fixed location, and you want to have files copied opportunistically onto your laptop via a wireless connection, regardless of where you happen to be in the world. You've set up bittorrent to handle the transfers. You can't use tcpwrappers or something similar, as your laptop's IP address will frequently change, since it's opportunistic, you won't be watching to enter in any passwords, so you leave the bittorrent system on the server open but unadvertised and rely on obscurity.
You have your music on a disk shared via a wide-area networked filesystem and again have a mobile laptop and want to do opportunistic copying. Much the same situation as above.
You have the most secure setup in the world between the server and laptop, but you forgot to set your laptop's bittorrent client to not also act as a server.
You are running an MP3 verification service. Your server has the original raw files, from which it generates MP3s at different compression levels, which it then generates cryptographic hashes and statistics for. Users can obtain, via bittorrent or some other P2P software, the data files and use them to examine any MP3 they get from their CD to see if the rip was successful and at the quality they want. However, your music is in the same directory as the data, so users can obtain the music as well. An easy thing to miss, but you've made all you music available via P2P, without any intent for anyone to copy it.
These aren't great examples, they're only intended to be good enough to give an idea that there could be cases where availability and intent are not the least bit the same.
What will make a difference is that the managers who make decision in data centers are more likely to regard Linux as supported by the hardware vendors, even though nothing has really changed. This will lead to Dell, and the others calling for more open source drivers, being in a position to make more sales. Now, as soon as that starts happening, as soon as serious money starts changing hands, drivers will be written for Linux. Not necessarily open source, in fact probably not open source, but drivers nonetheless. Hardware vendors are like sharks and lawyers - they can smell blood from incredible distances.
XFS is stable, SGI may be in questionable shape and actual releases may be far and few between, but I've seen plenty of bugfixes in the kernel changelogs.
NILFS (Developed by the Nippon Telephone and Telegraph CyberSpace Laboratories)
Btrfs (Developed by Oracle, GPLed and intended to compete with ZFS)
In short, what's the problem with these worrywarts? Three competing filesystems at various levels of development, four if you include JFS, that could replace ReiserFS and Reiser4 and could give ZFS a serious run for its money. Some are journalling, some are full log. They're either in the kernel or are already license-compatible and likely to be there. And that's just filesystems developed by major vendors AND announced AND have a Wikipedia page. Other vendors may have Linux filesystems under development which will be announced when ready to be included, on the basis that a certain PR hit will be better than a possible PR flub. And, as you say, smaller project filesystems exist everywhere. Some have become abandonware, others have remained around, others have a good chance of ending up in the remaining around category.
Choice isn't the problem. It never has been. Choices offered by distribution installers has been a far bigger complaint (at least of mine) than choices within the kernel itself.
Slashdot Mirror
For the last generation but one, it would be: 0r10n !pwned by you. ur !1337 like me, s0 stop.
My question is not, then, why it is not in wide use, but rather why it took me a long time to dig up the project information on these protocols, why information tends to be very sparse from the hobyist/garage community, why there are no Woznik Mk. II's providing homebrewed household systems, or Prof. Heinz Wolff II's running an X-Prize for such systems. All the foundation work has been done, the protocols are all available, the proofs of those systems exist in many of the more sophisticated facilities, everything that preceeded the hardware revolution in microcomputers has for many years also existed in the domestic appliance level and even the local substation level. What we have not seen is much of a garage revolution, the way we have for many other technologies. X10's aility to turn lights on and off seems to have been about the closest attempt.
Don't expect the Big Guys to do it. If there are trains that don't support regenerative braking yet, given the state of the rail network, then it is reasonable to assume nobody else in the upper echelons is going to care. This stage has invariably, for virtually all technologies out there today - including television and radio, been carried out by hobbyists, enthusiasts and homebrewers. My guess would be that if those hobbyists don't hobby along soon, this concept will simply never enter any market ouside of the real high-end. Mainframes will rule forever and the micro of the appliance world will never exist.
Don't get me wrong - I regard Take Two as an excellent representation of Dante's Inferno, given the way they treated David Braben and others, and shock/gore games strike me as very childish, but amoral "moralists" (Mary Whitehouse was another) who use cultist techniques to "program" the more easily-swayed segments of the population to believe their propoganda are far far worse than those they seek to suppress. It seems to me that of the Four Horsemen of the Apocolypse, Famine has retired in favour of FUD. There really are some fates worse than death, and perverted mind-control games would be one of them.
Going by this description, the useful work is the conversion itself. That fraction of the entropy is an inevitable consequence of what you are trying to do. The "non-useful" work is any overhead required by this electronic enzyme that is not a part of the conversion but is required in order for that computer to perform it. This is a function of the technology, not the problem, and is infinitely variable and controllable, but will never be zero and cannot be better than the ability to steer it.
Are computers bad for the environment? By this definition, no more (and no less) than any other enzyme, in the abstract. Specific solutions, specific computers, may be worse. The original Itanium was notoriously inefficient, for example. There was a lot of overhead within the CPU itself. Also, some CPUs, in an effort to reduce the power requirements, have too small a cache and do a lot of non-useful work in the form of spinning round in small circles waiting for something to do. Systems with shared resources are also prone to stalling, as are systems with excessively dedicated resources. It's a difficult balancing act. It has taken nature four billion years to produce systems with gigantic chains that frequently stall or malfunction.
If we measure greenhouse gas production, not as an absolute but as a percentage relative to what is actually required to do the useful component of the work, my guess would be that data centres do not work out to be that green.
Secondly, a cynic (such as myself) might suspect Microsoft pulled out of what most speculators considered a done deal in order to massively deflate Yahoo's value so it could be bought later at a fraction of the price. Not that Yahoo has done itself any favours in this process by effectively stoking up the speculation and failing to add much value to its service. I use Yahoo's email service because its cheap, not because its any good, and the "new, improved" web mail service is infinitely heavier, slower and less reliable.
Alternatively, a cynic might argue that no deal was ever really intended, that there was some intent by Microsoft to damage rivals rather than improve their own services. It wouldn't be the first time, if that was the case, but I'm not seeing any real damage beyond perhaps shareholder confidence.
Since the Japanese has 1Gb/s links to the home and the RIAA/MPAA knows Americans are the more advanced culture, they obviously need to work on the assumption that everyone would have 10Gb/s links at least. It stands to reason, after all. Especially if they can get a larger fine out of the deal, and it's not like a judge would know what network speeds are meaningful. (If they did, the RIAA/MPAA would be being dangled over a crocodile pit by now.)
By this standard, virtually all commercial speech should be prohibited. Admittedly, this might lead to a gigantic leap in the quality of products and services, a massive reclamation of land, bandwidth and other resources, and the undoing of years of brainwashing. The inprisonment of the entire advertising sector would also slash pollution levels, accelerate web speeds by three orders of magnitude, and be directly responsible for bringing civilization to whole new heights of wisdom and enlightenment.
In the UK, if a person file and loses an appeal in which the State counter-claims that the original sentance was unduly lenient, the appeal court judges can increase the sentance. This is one of the very, very, very few cases in which such a law could be considered justified. Unfortunately, printing out a representative sample of his spam e-mails and making a paper mache coffin out of it to decorate his prison cell might run counter to the cruel and unusual punishment clause.
What you want to look for is not a planet with X, Y or Z in terms of chemical components in the atmosphere, but evidence of a dynamic equilibrium actively maintained by a minimum of two opposing negative feedback loops that involve highly unstable components in the atmosphere. Since there will be day and night, and seasons, different points on the planet will register different prevailing feedback loops. These conditions cannot arise in a wholly inorganic environment. An inorganic environment may be chaotic (the atmospheres of Saturn and Jupiter, for example) or very basic (as in the case of the surface of Pluto) but the systems are relatively basic. They are simple chemical systems, passively reacting to the occasional direct strike by a comet, but there is nothing metastable or unstable about any of those examples. If anything, they are remarkable in their stability.
It is planets whose chemistry should be violently unstable but are actively held in dynamic equilibrium that are interesting. Those have processes that are in the realms of what we would consider living matter, and outside the realms of the non-living.
What about intelligent life? First define intelligence, and then secondly prove there's any on Earth. If we don't know what we're looking for, or how to recognize it if we find it, then such a search is futile. I regard SETI as more of a research lab for advanced theories into digital signal processing. It won't be useful until the one kilometer array is active, and the planned closures in Britain inclclude key parts of that array. We also need very very powerful signals processing - a million channels, or even half a billion, isn't much. We don't even know if we want the radio or optical spectrums. So, two arrays - one radio, one optical - at a kilometer diameter and, oh, say a trillion channels being monitored and analyzed with rather better signals theory than SETI@Home use. When will this happen? Never. That, then, is the earliest alien intelligence can be passively detected by us.
Sorry, but unless there are three of you and you have photographs proving you can get drunk on water, I cannot accept your claim.
Your letter was lost in the mail. We searched and searched, but didn't find it. As a result, we're going to bill you for half a billion dollars. If we find the letter and discover any money in it, we'll keep that that as well. And if there's anything blackmailable in it...
I like the idea, I like the idea a lot, but the fact that they opted for a simple but slow topology doesn't fill me with hope. Especially as they suggest running SMP over it. Processors close to the centre of the "mesh" will be resource-starved. There needs to be strong affinity of a given thread to a given core, where the weighting is by the operations expected and where that weighting can (and will) shift as code blocks change or new threads start. In other words, you want something that is semi-static, semi-dynamic according to need. Only the OS is capable of obtaining that kind of information, so it is the OS that needs to do the dividing, NOT the architecture underneath OR a system administrator.
It's like an antimatter containment field - circular and serves the purpose of being dramatic on television.
Actually you might want to imagine a Beowulf cluster of them. You'd more likely run MOSIX or OpenMOSIX on the chip to handle the migration from logical machine to logical machine on the same chip, but you can't then use that to build a cluster as you'd get a conflict between the cluster and cluster-of-clusters. SMP and virtualization might work, but there's minimal messaging between nodes and SMP technology doesn't scale well beyond 16 nodes, so a clustering technology seems a more logical way to go.
Not always. Some companies abuse the term to mean a closed source driver for an open source OS. This isn't open source at all, as we're all perfectly well aware, but marketroids are less interested in reality as they are in exploitable buzzwords.
Other aspects of a driver depend on the bus being used. (This could be abstracted out entirely into a virtual transport layer, however you'd get the performance hit from hell unless it's done in hardware and the only companies capable of getting a big enough slice of market for this to be worth considering are the companies selling busses - exactly not the people who would want abstraction systems that could help competitors.)
Yet other aspects depend on the OS. (Ignoring for now the bus abstraction, the OS dictates how the driver can be communicated with, how data is passed in/out - and in what form, whether or not the driver can be internally threaded, whether or not the driver can be multiply called, what IPC mechanisms exist and what locking mechanisms exist. A lot of that information could be masked by a suitable OS abstraction layer.)
Where speed is critical, there may even be aspects that depend on the CPU instruction set.
The reality is that you can't make drivers efficient and OS-agnostic, although you can do one or the other. That's a pity, because if you could, then it wouldn't matter if the manufacturers thought of themselves as making Linux drivers. There would be no significant penalty running them under any *BSD. The manufacturers might be happier, too, as it would cut down on how many OS' they needed to write for. There again, they might not, as it would expose more supposed secrets and would eliminate OS favouritism.
As things stand, drivers are very tightly written and OS-specific. An abstraction layer to run Linux drivers under a *BSD would still be possible, but largely pointless except for researching the driver's characteristics. Even highly specialized closed-source drivers with oodles of protection against analysis would be better reverse-engineered than wrappered.
Some of these you may argue are not "server". They're not webserver or database server, perhaps, but a data acquisition device that stores and later delivers specified data on request is damn well a server. The fact that it's stored, specified and on demand, rather than digested and passed on, distinguishes a true server from any other type of (usually) headless device. If you specify a category narrow enough, there will always be 100% support for it. If you want to guarantee that, start with the 100% and change the definition to fit. If you prefer something a little more useful, then take the definition and explore how things in the Linux world work within that definition. Traditional servers are almost entirely passive when it comes to external connections. Something else has to initiate a connection. Modern servers sometimes do a little bit of active networking - broadcasts and multicasts to identify services, for example, and in clusters, servers will routinely push activities and data to other servers. However, they are fundamentally passive on networking and highly active on processing and data crunching. Streaming servers and VOD servers are generally transmitting on-demand, so are still passive recipients of the request. They don't do anything on their own. Sites streaming webcams by multicast or whatever are blindly sending in a way that's not much different than an announcement. In both cases, it's intended for processing by clients but not replying to. It's not part of an exchange, it's just a blind send. Thus, such systems are also servers.
Clients may passively receive broadcasts and multicasts, but actively initiate all conversations (with the special case of PUSH technology, but there the client really becomes a temporary server, and the server a temporary client, so the definitions still hold true - besides which, when was the last time you saw anyone use PUSH?!)
The technologies I listed are not client technologies, they are server technologies, although there's no reason a client couldn't have those hardware components. It'd just be a very heavy client.
These aren't great examples, they're only intended to be good enough to give an idea that there could be cases where availability and intent are not the least bit the same.
Needs to be lock'n'key, or there are too many syllables in the last line.
What will make a difference is that the managers who make decision in data centers are more likely to regard Linux as supported by the hardware vendors, even though nothing has really changed. This will lead to Dell, and the others calling for more open source drivers, being in a position to make more sales. Now, as soon as that starts happening, as soon as serious money starts changing hands, drivers will be written for Linux. Not necessarily open source, in fact probably not open source, but drivers nonetheless. Hardware vendors are like sharks and lawyers - they can smell blood from incredible distances.
Hey, don't knock it. The machines aren't only disabled for the blind, they're disabled for everyone else too! That's equality for you.
It's The Eric Conspiricy All Over Again!
NILFS (Developed by the Nippon Telephone and Telegraph CyberSpace Laboratories)
Btrfs (Developed by Oracle, GPLed and intended to compete with ZFS)
In short, what's the problem with these worrywarts? Three competing filesystems at various levels of development, four if you include JFS, that could replace ReiserFS and Reiser4 and could give ZFS a serious run for its money. Some are journalling, some are full log. They're either in the kernel or are already license-compatible and likely to be there. And that's just filesystems developed by major vendors AND announced AND have a Wikipedia page. Other vendors may have Linux filesystems under development which will be announced when ready to be included, on the basis that a certain PR hit will be better than a possible PR flub. And, as you say, smaller project filesystems exist everywhere. Some have become abandonware, others have remained around, others have a good chance of ending up in the remaining around category.
Choice isn't the problem. It never has been. Choices offered by distribution installers has been a far bigger complaint (at least of mine) than choices within the kernel itself.