Software patents literally make these open source projects illegal
The context you skipped was speaking directly to OSS H264 implementations. A patent does not *force* the patent holder to be anti-OSS, but if the patent holder doesn't explicitly grant that liberty, then the OSS project distribution in geographies where the patents apply are illegal and are liable. You may argue that this should be the right of the patent holder to make these restrictions, but don't pretend that all software patent holders are just fine with OSS and that it has no impact.
Let me ask you, how many people has the MPEG-LA sued over h264... there are OSS implementations... how many of them have been sued? I can count to one higher on my dick, so just stop with the retarded bullshit you're pulling out of your ass.
That argument could have been made about GIF and VFAT for *years* before the respective companies started going after their royalties with force. One of the devious things about patents is that they can be 'submarined' while the industry standardizes on it and then the holders can raise their hands and make demands upon the whole industry. In cases like Novell and RedHat where they explicitly license their patents, its ok. For closed/open projects that explicitly get signoff from a patent holder, they are ok. In the case of H264, there are clear demands as to how to legally license that are ignored by many who are *currently* ignored in turn as the holders think it the best current business course of action. Because of the overall soft stance in the community on h264 licensing, they reap the benefits of open source implementations as validating it as a standard while not incurring the risk of losing their right to sue by explicitly granting rights.
The thing is, syslinux/grub/etc all make PXE calls to retrieve files, which is TFTP. gPXE as a firmware (or as an undi driver delivered via PXE) gives syslinux http protocol support.
Since you mentioned IPv6, the DHCPv6 RFC is just about to come out, and specifies a url syntax for protocol flexibility, as well as recommending http as the protocol of choice (FTP kinda gets the shaft...).
As I mentioned above, most tftp clients go above and beyond the spec and for unicast transfers can outdo the spec (multicast a no-go).
half-duplex is not perfectly fine when there is a relatively accessible better technology.
http (or perhaps more appropriately ftp) are perfectly suitable protocols. The technology has progressed sufficiently far that a TCP stack is feasible in firmware, and there's no point in not doing it.
The DHCPv6 netboot standard about to come out recommends http as the protocol of choice where tftp would have been used, but uses URLs so the protocol is selectable.
The iSCSI portion of this is a wider standard, implemented by many firmware configurations out of the box.
Finally, I'm going to plug xCAT as a tool to wrap dhcp, dns, ntp, active directory, gPXE, iSCSI, PXE, bootp/tftp, ipmi, blades, vmware, kvm, xen, LPARs, and more to deploy vmware, windows, linux, and aix systems and do hardware management. It mostly pays off at larger scale, but it is a project that aims to understand how to best utilize those various technologies.
xCAT at its core focuses on network boot (and for x86 portions, includes gPXE). It does Windows, Redhat, SuSE, VMware. It takes a lot of the tedium out at scale of network install, statless boot, and iscsi boot.
Issues: -tftp multicast is inherently limited to smaller than 98MB images with sane MTU. The same block number wrapping in unicast can't work in multicast. When you want speedup the most, tftp multicast can't even work -multicast only buys you something if a large number of clients are acquiring the same payload at the same time. In a large scale 'cloud 'configuration, things are generally heterogenous enough to negate any such hypothetical benefit. -Most ethernet fabrics are either incapable or not configured for IGMP/MLDv2 snooping required to properly scope multicast resulting in all multicast traffic degrading to broadcast. This has very adverse results unless every entity on the network only cares about the transfer.
Well, one issue is boot payload is getting bigger and bigger. One distro has about 20MB of download that would be tftped in the default case. Windows uses tftp for a *lot* more.
tftp has the following issues: -16-bit block indexes. Most firmware won't go above 1400 or so blocksize (with good reason, if they go higher and the network is set for jumbo frames, transfers will fail in many scenarios). This means a cap of about 98MB before you overflow the counter. Most tftp servers nowadays can deal with it in a unicast case, but it's not technically fixed in the spec.
-tftp exhibits a sort of half-duplex character with regards to transmits and block acknowledgement. Server sends 1.5 kilobytes, then does nothing, client receives the block, and only then does it request the other one. Compare to TCP windows in ftp and http and the differences are massive.
IPv6 has some immature aspects to it. IPv4 has had decades of hardening in the practical space. As the only viable protocol, all the issues encountered had to be solved and people couldn't bail on IPv4 if it were not fixed. Much of the experience has been translated over, but owners of IPv6 have been keen to try to rethink every aspect of how things are done, frequently missing corner cases or demanding a workflow change for net admins accustomed to IPv4. With no hard requirement driving these admins to adopt IPv6, rejected admins just report back to their organization that IPv6 is infeasible, and walk away from the table since IPv4 works today.
ISC's DHCP server still doesn't have full function in IPv6 compared to IPv4, and resorts to violating RFC 3315 to try to hack in a feature from IPv4.
There are also many standards that are still IPv6-incapable. Examples include IPMI (net configuration directives have 4 bytes for addresses and such) and PXE.
Of course, this is all part of the chicken and the egg, standards improving requires demand in the industry that lacks in an IPv4 dominated world, and IPv6 won't displace IPv4 so long as the standards aren't improved. There are enough people chipping away at it to make some progress, but the rate is significantly slower than it would be if people didn't just go back to IPv4 and take a wait and see position.
Adobe will fix any touch issues eventually, they have a very strong incentive to make it work well, so that's really only a "for now" issue.
While I agree that capability not provided via standards is provided, my confidence that Adobe will fix all the issues is low. The entire lifetime of flash has been pretty much about the bare-minimum they had to do, staying fairly flaky and bloated throughout its life.
Way to presuppose something about my stance that conveniently demonizes me.
I really didn't have much to say on the matter. When it released, I tried it out, thought it was a harbinger of good things to come, but it lacked some features that made me wait until a less button-averse set of manufacturers really got into the game. I actually had to wait longer than I thought before I got a WebOS device that pretty much fit my requirements, which is a testament of how far ahead of the game Apple was in technology. iPhone was a disruptive (in a good way) technology in a cell-phone industry focused on milking the status quo.
However, my complaint is not that they 'allow' native apps, it's that they game the industry to give developers little choice in the matter in a fairly anti-competitive way. Not only do they force third parties to use native apis by shooting down and forbidding cross-platform toolkits, they also restrict feature-set and approval processes to protect first-party software efforts from third-party efforts on their platform (i.e. no IM background capability in their new 'multitasking', which seems to be reserved for upcoming iChat enhancements). I have no idea why they would give such a crippled multitasking experience after so long a delay, but it seems clear they still don't want third parties to have capability they use themselves.
all standards pertaining to the web should be open
Note that qualification in Steve's message. There has been noise about flash as an 'app' platform beyond 'just' web, and that is something Apple has a *lot* to lose on. Longer term, perhaps HTML5/WebGL/CSS/Javascript poses a long-term threat to their 'apps', but Flash represents a more clear and imminent threat.
Apple is in some ways worse than Microsoft (perhaps because Apple is allowed to get away with it) when it comes to standards. It would be wise to keep in mind the motivations of the players as they present their rhetoric to the world.
While I dislike Apple's my-way-or-the-highway approach, I'll give them credit for sticking to their guns about open standards for the web.
The problem I have is while they dress it up as sticking to their guns on open standards, their true motive is they want people to write to the proprietary technology of iPhone apps instead of flash apps. They make legitimate criticisms of Adobe as tying up the web in a proprietary technology while at the same time clearly moving to punish any developers that would want to target iPhone+others using cross-platform tools rather than limited and proprietary iPhone only apps.
I can't get excited over the concept of rooting for either Adobe or Apple in their little pissing contest. I dislike what both want the industry to look like.
In a corporate environment, what you say comes close to flying (practically speaking, it's horribly expensive to have enough IT to cover all the edge cases to get enough productive work), but even then the user is able to spawn executables of some sort. I guess if/tmp,/var/tmp, and/home in a *nix env are mounted noexec, you're pretty much where you describe, and I suppose Windows is disadvantaged from that perspective.
That, however, ignores the home market where most everyone is their own administrator.
a) Windows has serious flaws that exacerbate the problem (only recently did they get something roughly sudo like that is still laughably trivial to bypass, and even then poor third-party implementations that haven't grown out of the Win9x days further torture things), nothing short of disciplined users can do anything to get rid of anti-virus market. So long as a user is actually allowed to execute what they want on a system, some stupid thing will convince them to execute it, and damage/manipulate any data that user has access to. b) ok, that seems fair enough c) I concur, but back to point a, most users have all the stuff they care about under their account and aren't mollified that the system files are ok when all their personal documents have been corrupted.
I will say the ability to, in the worst case scenario, boot a system single or log into an existing alternate account to 'clean' the afflicted user account is perfect. I've spent a lot of time trying to rescue a windows system that was malware infected because I couldn't clean it from within the afflicted system (the malware already had control, and did an effective job blocking attempts).
A lot of system management utilities had to treat execution under dom0 quite differently than on linux normally. A lot of the industry would rather have a hypervisor platform with a 'normal' OS behavior to it.
The phrasing at least makes it sound like you have some lack of discipline in how it has grown and possibly how it will continue to grow. For some topologies (SAN, network), there are technologies (the best 'generally' scoped ones aren't free) that can mitigate even without sticking to one vendor, but for bulk power topology, you have nothing but discipline to do it. At the end of the day, no matter how fancy, the basic principle will be akin to a relational database that is manually maintained for that. The danger here is that panic situations and carelessness without discipline will cause the physical reality to drift from your logical view.
So if you know the network topology to anchor to and enforce discipline in wiring, you can derive specific location from the network (i.e. this is the way xCAT correlates physical location to a logical entity). If you use near-rack edge switches, even if you are weak in your discipline, it at least narrows it down to the rack.
xCAT's approach is straightforward, it tracks either what is attached to an ethernet port or a physical blade bay.
It is by no means a complete 'answer' to the whole problem (it will correlate servers to a location, and even track asset tags, model, and serial number and do some other things), but it is a philosophy to apply for physical information derived from a pure 'logical' view of a datacenter.
Fine 'emerging' might have paid a disservice to the rest of embedded, but you have to admit embedded sensibilities are meeting more front-and-center consumer interaction with more general purpose set-top boxes and cell phones going around. Sure, special purpose embedded well behind the scenes has been larger volumes, but the more general purpose in a single device aspect is changing the landscape of embedded.
If you didn't want to run them on the same machine for performance reasons before, virtualization will only exacerbate the problem. Virtualization does not speed up anything, it does not magically make multitasking better (in fact, worse). Virtualization can be used for some security separation without having to think at all about it (I would prefer people do the thinking to make it ok to coexist in the same OS instance, the VM thinking just leads to effectively static linked binaries for everything, but practically speaking, people are lazy) or for running disparate OS apps (i.e. Windows and Linux) concurrently with reduced hardware.
You don't just plop down a bunch of ARM processors on a board and magically get suitable performance without scaling out memory architecture and such. The only way in the x86 space that very many core systems get acceptable results is by increasingly sophisticated memory architectures that demand more memory modules in aggregate to allow direct, lightly loaded paths between compute and memory. Those memory modules draw more energy, as does various strategies that put more memory controllers down to lighten the load and more. Scaling general-purpose computing tasks to many small cores simply has some significant challenges that drive up the incremental power requirements as it goes up.
The most performance per watt in pure compute power is currently PowerXCell 8i, which doesn't exist outside of an IBM blade as far as I know. If a datacenter wanted to *really* be serious about performance per watt, I think I'd see more QS22s lying around. Intel is admittedly not the leader in performance-per-watt, but the crown still lies in systems optimized for high resource utilization in a small number of CPU packages.
One issue discussed then was the Atom microprocessor lacked performance compared with other Intel processors
Atom and ARM are great platforms when you don't need much processor in one spot. I.e. many embedded applications and a lot of consumer electronics. They need some processor, but not a lot. 'desktop/server' processors are optimized for a higher load and just don't scale down. Note that ARM isn't inherently low power, it's just the instruction set everyone in the world has rights to implement, and Intel pretty well dominated everything but an emerging low power market. You have a lot of innovation and skill at implementing 'just-enough' processors that simply picks ARM out of convenience.
In the data center context, things change. The notorious energy consumption of the low-power processors come to nothing when you can arbitrarily consolidate workload onto as few processors as possible. The economies of scale of the mainstream desktop/server platforms deliver are far greater than tiny low power devices.
In terms of MS experimenting with it, expect nothing to come of it. It will fail like Atom did in their experiment before. Assuming a long shot, expect nothing to change externally, even if MS discovers ARM is great for their data centers, they cannot readily win a market that centers around lower cost, lower energy, lower performance non-x86 compatible parts. They have a golden example of a company thinking their technology intrinsically drives the industry making a drastic change to discover they were wrong. Intel thought they dictated the terms of the industry, but Itanium simply failed to transform the market without quality x86 compatibility. This was the golden opportunity for AMD to swoop in with an alternative and make huge gains. MS is in the exact same situation, 99.9% of their clout is the environment of existing Windows apps. Microsoft has tried time after time various platforms to reach the same endgame of no success. If the new architecture in *theory* provided more performance, sufficient to emulate x86 instructions, then it would stand a remote chance, but going to lower performance platform renders this impossible. In a really long shot, MS gets a lot of really nice ARM hardware on the market, and then has to compete with Linux on its own merits rather than ecosystem of applications. It's nearly suicide to risk your largest leverage point unless the industry is imminently making you irrelevant even if you stick to your guns.
One of the side effects of open source development is that you get a slightly different driver for every device, instead of generic drivers.
This is the case for every OS. Some things are done generically (i.e. AHCI driver can support a number of SATA chips without a lot of drawback), others that could be done generically are generally crappy when accessed via generic interfaces (i.e. VBE graphics vs. specific GPU drivers), and others are simply impossible to write generic drivers for once firmware services stop (i.e. most SAS controllers, sound cards, etc). WHQL does *not* limit the number of drivers, and simply formalizes the 'write once, debug everywhere' reality that any platform of that variety endures at the driver level. Apple's approach alleviates them of a lot of that, but their drivers are no less specialized than anyone else, just fewer of them.
All the action is on mobile devices, and Linux on a mobile device is like pounding a screw
While I could see QNX and the like as appropriate for the embedded space, Linux is very popular and viable in the embedded space. The vast majority of non-iPhone smartphones are Linux based. That's not to say they all do it well or in a manner that would fit with many people's view of embedded systems, but it's not Linux that causes that parting from the sensibilities of embedded, it's attracting app developers that are too bad/lazy to write good code in an embedded context.
The Linux GUI is still ugly.
*The* Linux GUI is an interesting statement. GUIs on Linux range from Android, to Xorg, to Luna in WebUI, to Tivos. If you want to be strict about it,*Linux* isn't about GUI development, it's about the foundation an entire system including a GUI needs. This isn't anti-GUI, this is simply a matter of platform prerequisites. FYI, I'm under 30 and I very very very much appreciate the CLI and not having to carry the burden of GUIs on thousands of headless systems I manage day to day.
Linux failed on the desktop.
It didn't fail on *my* desktop. It didn't fail on the mobile device market (it has an order of magnitude larger share than Windows Mobile). In terms of who wants to work on server architecture, the answer would be obviously some people, as a lot of critical effort and money is invested in that space software-wise.
I'm not a kernel developer, but I've poked around specific parts of the kernel for various reasons. You do not have to even think about the existence of most of the code to work an a particular segment. Hell, I've created small kernel modules that compiled against a kernel without even having kernel source on my system.
It might be strictly monolithic in overall architecture, but from a development standpoint much of it isn't meaningfully that different from a modular implementation. Most of the differences manifest at runtime, not at development time.
Slashdot Mirror
Software patents literally make these open source projects illegal
The context you skipped was speaking directly to OSS H264 implementations. A patent does not *force* the patent holder to be anti-OSS, but if the patent holder doesn't explicitly grant that liberty, then the OSS project distribution in geographies where the patents apply are illegal and are liable. You may argue that this should be the right of the patent holder to make these restrictions, but don't pretend that all software patent holders are just fine with OSS and that it has no impact.
Let me ask you, how many people has the MPEG-LA sued over h264 ... there are OSS implementations ... how many of them have been sued? I can count to one higher on my dick, so just stop with the retarded bullshit you're pulling out of your ass.
That argument could have been made about GIF and VFAT for *years* before the respective companies started going after their royalties with force. One of the devious things about patents is that they can be 'submarined' while the industry standardizes on it and then the holders can raise their hands and make demands upon the whole industry. In cases like Novell and RedHat where they explicitly license their patents, its ok. For closed/open projects that explicitly get signoff from a patent holder, they are ok. In the case of H264, there are clear demands as to how to legally license that are ignored by many who are *currently* ignored in turn as the holders think it the best current business course of action. Because of the overall soft stance in the community on h264 licensing, they reap the benefits of open source implementations as validating it as a standard while not incurring the risk of losing their right to sue by explicitly granting rights.
The thing is, syslinux/grub/etc all make PXE calls to retrieve files, which is TFTP. gPXE as a firmware (or as an undi driver delivered via PXE) gives syslinux http protocol support.
Since you mentioned IPv6, the DHCPv6 RFC is just about to come out, and specifies a url syntax for protocol flexibility, as well as recommending http as the protocol of choice (FTP kinda gets the shaft...).
As I mentioned above, most tftp clients go above and beyond the spec and for unicast transfers can outdo the spec (multicast a no-go).
half-duplex is not perfectly fine when there is a relatively accessible better technology.
http (or perhaps more appropriately ftp) are perfectly suitable protocols. The technology has progressed sufficiently far that a TCP stack is feasible in firmware, and there's no point in not doing it.
The DHCPv6 netboot standard about to come out recommends http as the protocol of choice where tftp would have been used, but uses URLs so the protocol is selectable.
The iSCSI portion of this is a wider standard, implemented by many firmware configurations out of the box.
Finally, I'm going to plug xCAT as a tool to wrap dhcp, dns, ntp, active directory, gPXE, iSCSI, PXE, bootp/tftp, ipmi, blades, vmware, kvm, xen, LPARs, and more to deploy vmware, windows, linux, and aix systems and do hardware management. It mostly pays off at larger scale, but it is a project that aims to understand how to best utilize those various technologies.
xCAT at its core focuses on network boot (and for x86 portions, includes gPXE). It does Windows, Redhat, SuSE, VMware. It takes a lot of the tedium out at scale of network install, statless boot, and iscsi boot.
Issues:
-tftp multicast is inherently limited to smaller than 98MB images with sane MTU. The same block number wrapping in unicast can't work in multicast. When you want speedup the most, tftp multicast can't even work
-multicast only buys you something if a large number of clients are acquiring the same payload at the same time. In a large scale 'cloud 'configuration, things are generally heterogenous enough to negate any such hypothetical benefit.
-Most ethernet fabrics are either incapable or not configured for IGMP/MLDv2 snooping required to properly scope multicast resulting in all multicast traffic degrading to broadcast. This has very adverse results unless every entity on the network only cares about the transfer.
Well, one issue is boot payload is getting bigger and bigger. One distro has about 20MB of download that would be tftped in the default case. Windows uses tftp for a *lot* more.
tftp has the following issues:
-16-bit block indexes. Most firmware won't go above 1400 or so blocksize (with good reason, if they go higher and the network is set for jumbo frames, transfers will fail in many scenarios). This means a cap of about 98MB before you overflow the counter. Most tftp servers nowadays can deal with it in a unicast case, but it's not technically fixed in the spec.
-tftp exhibits a sort of half-duplex character with regards to transmits and block acknowledgement. Server sends 1.5 kilobytes, then does nothing, client receives the block, and only then does it request the other one. Compare to TCP windows in ftp and http and the differences are massive.
IPv6 has some immature aspects to it. IPv4 has had decades of hardening in the practical space. As the only viable protocol, all the issues encountered had to be solved and people couldn't bail on IPv4 if it were not fixed. Much of the experience has been translated over, but owners of IPv6 have been keen to try to rethink every aspect of how things are done, frequently missing corner cases or demanding a workflow change for net admins accustomed to IPv4. With no hard requirement driving these admins to adopt IPv6, rejected admins just report back to their organization that IPv6 is infeasible, and walk away from the table since IPv4 works today.
ISC's DHCP server still doesn't have full function in IPv6 compared to IPv4, and resorts to violating RFC 3315 to try to hack in a feature from IPv4.
There are also many standards that are still IPv6-incapable. Examples include IPMI (net configuration directives have 4 bytes for addresses and such) and PXE.
Of course, this is all part of the chicken and the egg, standards improving requires demand in the industry that lacks in an IPv4 dominated world, and IPv6 won't displace IPv4 so long as the standards aren't improved. There are enough people chipping away at it to make some progress, but the rate is significantly slower than it would be if people didn't just go back to IPv4 and take a wait and see position.
I've had the exact same situation.
More commonly, I see people use 192.x where x is not 168 thinking 192 is a class A private network (except they have no idea what those words mean).
Adobe will fix any touch issues eventually, they have a very strong incentive to make it work well, so that's really only a "for now" issue.
While I agree that capability not provided via standards is provided, my confidence that Adobe will fix all the issues is low. The entire lifetime of flash has been pretty much about the bare-minimum they had to do, staying fairly flaky and bloated throughout its life.
You probably complained about that.
Way to presuppose something about my stance that conveniently demonizes me.
I really didn't have much to say on the matter. When it released, I tried it out, thought it was a harbinger of good things to come, but it lacked some features that made me wait until a less button-averse set of manufacturers really got into the game. I actually had to wait longer than I thought before I got a WebOS device that pretty much fit my requirements, which is a testament of how far ahead of the game Apple was in technology. iPhone was a disruptive (in a good way) technology in a cell-phone industry focused on milking the status quo.
However, my complaint is not that they 'allow' native apps, it's that they game the industry to give developers little choice in the matter in a fairly anti-competitive way. Not only do they force third parties to use native apis by shooting down and forbidding cross-platform toolkits, they also restrict feature-set and approval processes to protect first-party software efforts from third-party efforts on their platform (i.e. no IM background capability in their new 'multitasking', which seems to be reserved for upcoming iChat enhancements). I have no idea why they would give such a crippled multitasking experience after so long a delay, but it seems clear they still don't want third parties to have capability they use themselves.
all standards pertaining to the web should be open
Note that qualification in Steve's message. There has been noise about flash as an 'app' platform beyond 'just' web, and that is something Apple has a *lot* to lose on. Longer term, perhaps HTML5/WebGL/CSS/Javascript poses a long-term threat to their 'apps', but Flash represents a more clear and imminent threat.
Apple is in some ways worse than Microsoft (perhaps because Apple is allowed to get away with it) when it comes to standards. It would be wise to keep in mind the motivations of the players as they present their rhetoric to the world.
While I dislike Apple's my-way-or-the-highway approach, I'll give them credit for sticking to their guns about open standards for the web.
The problem I have is while they dress it up as sticking to their guns on open standards, their true motive is they want people to write to the proprietary technology of iPhone apps instead of flash apps. They make legitimate criticisms of Adobe as tying up the web in a proprietary technology while at the same time clearly moving to punish any developers that would want to target iPhone+others using cross-platform tools rather than limited and proprietary iPhone only apps.
I can't get excited over the concept of rooting for either Adobe or Apple in their little pissing contest. I dislike what both want the industry to look like.
In a corporate environment, what you say comes close to flying (practically speaking, it's horribly expensive to have enough IT to cover all the edge cases to get enough productive work), but even then the user is able to spawn executables of some sort. I guess if /tmp, /var/tmp, and /home in a *nix env are mounted noexec, you're pretty much where you describe, and I suppose Windows is disadvantaged from that perspective.
That, however, ignores the home market where most everyone is their own administrator.
a) Windows has serious flaws that exacerbate the problem (only recently did they get something roughly sudo like that is still laughably trivial to bypass, and even then poor third-party implementations that haven't grown out of the Win9x days further torture things), nothing short of disciplined users can do anything to get rid of anti-virus market. So long as a user is actually allowed to execute what they want on a system, some stupid thing will convince them to execute it, and damage/manipulate any data that user has access to.
b) ok, that seems fair enough
c) I concur, but back to point a, most users have all the stuff they care about under their account and aren't mollified that the system files are ok when all their personal documents have been corrupted.
I will say the ability to, in the worst case scenario, boot a system single or log into an existing alternate account to 'clean' the afflicted user account is perfect. I've spent a lot of time trying to rescue a windows system that was malware infected because I couldn't clean it from within the afflicted system (the malware already had control, and did an effective job blocking attempts).
A lot of system management utilities had to treat execution under dom0 quite differently than on linux normally. A lot of the industry would rather have a hypervisor platform with a 'normal' OS behavior to it.
The phrasing at least makes it sound like you have some lack of discipline in how it has grown and possibly how it will continue to grow. For some topologies (SAN, network), there are technologies (the best 'generally' scoped ones aren't free) that can mitigate even without sticking to one vendor, but for bulk power topology, you have nothing but discipline to do it. At the end of the day, no matter how fancy, the basic principle will be akin to a relational database that is manually maintained for that. The danger here is that panic situations and carelessness without discipline will cause the physical reality to drift from your logical view.
So if you know the network topology to anchor to and enforce discipline in wiring, you can derive specific location from the network (i.e. this is the way xCAT correlates physical location to a logical entity). If you use near-rack edge switches, even if you are weak in your discipline, it at least narrows it down to the rack.
xCAT's approach is straightforward, it tracks either what is attached to an ethernet port or a physical blade bay.
It is by no means a complete 'answer' to the whole problem (it will correlate servers to a location, and even track asset tags, model, and serial number and do some other things), but it is a philosophy to apply for physical information derived from a pure 'logical' view of a datacenter.
Fine 'emerging' might have paid a disservice to the rest of embedded, but you have to admit embedded sensibilities are meeting more front-and-center consumer interaction with more general purpose set-top boxes and cell phones going around. Sure, special purpose embedded well behind the scenes has been larger volumes, but the more general purpose in a single device aspect is changing the landscape of embedded.
If you didn't want to run them on the same machine for performance reasons before, virtualization will only exacerbate the problem. Virtualization does not speed up anything, it does not magically make multitasking better (in fact, worse). Virtualization can be used for some security separation without having to think at all about it (I would prefer people do the thinking to make it ok to coexist in the same OS instance, the VM thinking just leads to effectively static linked binaries for everything, but practically speaking, people are lazy) or for running disparate OS apps (i.e. Windows and Linux) concurrently with reduced hardware.
You don't just plop down a bunch of ARM processors on a board and magically get suitable performance without scaling out memory architecture and such. The only way in the x86 space that very many core systems get acceptable results is by increasingly sophisticated memory architectures that demand more memory modules in aggregate to allow direct, lightly loaded paths between compute and memory. Those memory modules draw more energy, as does various strategies that put more memory controllers down to lighten the load and more. Scaling general-purpose computing tasks to many small cores simply has some significant challenges that drive up the incremental power requirements as it goes up.
The most performance per watt in pure compute power is currently PowerXCell 8i, which doesn't exist outside of an IBM blade as far as I know. If a datacenter wanted to *really* be serious about performance per watt, I think I'd see more QS22s lying around. Intel is admittedly not the leader in performance-per-watt, but the crown still lies in systems optimized for high resource utilization in a small number of CPU packages.
As I said everything *but* an emerging low power market. ARM is the place where they don't have a hold.
One issue discussed then was the Atom microprocessor lacked performance compared with other Intel processors
Atom and ARM are great platforms when you don't need much processor in one spot. I.e. many embedded applications and a lot of consumer electronics. They need some processor, but not a lot. 'desktop/server' processors are optimized for a higher load and just don't scale down. Note that ARM isn't inherently low power, it's just the instruction set everyone in the world has rights to implement, and Intel pretty well dominated everything but an emerging low power market. You have a lot of innovation and skill at implementing 'just-enough' processors that simply picks ARM out of convenience.
In the data center context, things change. The notorious energy consumption of the low-power processors come to nothing when you can arbitrarily consolidate workload onto as few processors as possible. The economies of scale of the mainstream desktop/server platforms deliver are far greater than tiny low power devices.
In terms of MS experimenting with it, expect nothing to come of it. It will fail like Atom did in their experiment before. Assuming a long shot, expect nothing to change externally, even if MS discovers ARM is great for their data centers, they cannot readily win a market that centers around lower cost, lower energy, lower performance non-x86 compatible parts. They have a golden example of a company thinking their technology intrinsically drives the industry making a drastic change to discover they were wrong. Intel thought they dictated the terms of the industry, but Itanium simply failed to transform the market without quality x86 compatibility. This was the golden opportunity for AMD to swoop in with an alternative and make huge gains. MS is in the exact same situation, 99.9% of their clout is the environment of existing Windows apps. Microsoft has tried time after time various platforms to reach the same endgame of no success. If the new architecture in *theory* provided more performance, sufficient to emulate x86 instructions, then it would stand a remote chance, but going to lower performance platform renders this impossible. In a really long shot, MS gets a lot of really nice ARM hardware on the market, and then has to compete with Linux on its own merits rather than ecosystem of applications. It's nearly suicide to risk your largest leverage point unless the industry is imminently making you irrelevant even if you stick to your guns.
One of the side effects of open source development is that you get a slightly different driver for every device, instead of generic drivers.
This is the case for every OS. Some things are done generically (i.e. AHCI driver can support a number of SATA chips without a lot of drawback), others that could be done generically are generally crappy when accessed via generic interfaces (i.e. VBE graphics vs. specific GPU drivers), and others are simply impossible to write generic drivers for once firmware services stop (i.e. most SAS controllers, sound cards, etc). WHQL does *not* limit the number of drivers, and simply formalizes the 'write once, debug everywhere' reality that any platform of that variety endures at the driver level. Apple's approach alleviates them of a lot of that, but their drivers are no less specialized than anyone else, just fewer of them.
All the action is on mobile devices, and Linux on a mobile device is like pounding a screw
While I could see QNX and the like as appropriate for the embedded space, Linux is very popular and viable in the embedded space. The vast majority of non-iPhone smartphones are Linux based. That's not to say they all do it well or in a manner that would fit with many people's view of embedded systems, but it's not Linux that causes that parting from the sensibilities of embedded, it's attracting app developers that are too bad/lazy to write good code in an embedded context.
The Linux GUI is still ugly.
*The* Linux GUI is an interesting statement. GUIs on Linux range from Android, to Xorg, to Luna in WebUI, to Tivos. If you want to be strict about it,*Linux* isn't about GUI development, it's about the foundation an entire system including a GUI needs. This isn't anti-GUI, this is simply a matter of platform prerequisites. FYI, I'm under 30 and I very very very much appreciate the CLI and not having to carry the burden of GUIs on thousands of headless systems I manage day to day.
Linux failed on the desktop.
It didn't fail on *my* desktop. It didn't fail on the mobile device market (it has an order of magnitude larger share than Windows Mobile). In terms of who wants to work on server architecture, the answer would be obviously some people, as a lot of critical effort and money is invested in that space software-wise.
I'm not a kernel developer, but I've poked around specific parts of the kernel for various reasons. You do not have to even think about the existence of most of the code to work an a particular segment. Hell, I've created small kernel modules that compiled against a kernel without even having kernel source on my system.
It might be strictly monolithic in overall architecture, but from a development standpoint much of it isn't meaningfully that different from a modular implementation. Most of the differences manifest at runtime, not at development time.