The SecureBoot model is, frankly, a joke. As soon as you leave the realm of vendor provided OS content, it provides nearly zero protection. Hibernation can't fit into the SecureBoot model, the memory image cannot possibly be signed by the OS vendor private key. kexec could be hypothetically modified to require a signature be passed, but userspace could *look* just like something kexec would produce. Fullscreening qemu-kvm comes to mind...
What distinguishes hibernated memory image from, say, an initrd? Practically speaking, a distro has to allow for initrds to boot that aren't signed by the distribution. In fact, what about booting *any* filesystem? Some may suggest that the goal would be to have every binary signed, but what about end-user maintained scripts and config files? SecureBoot as currently defined only about the OS provider signing what they provide and that leaves a whole lot of area for malicious content outside that scope. It's of little comfort that you have assurance that you are running the correct sshd if, for example, you have malicious ssh_config and malicious authorized_keys.
I think dark matter theory is a bit more presumptive than 'any theory to explain discrepancies between established theory and observed reality with respect to gravity' it specifically hypothesizes some sort of matter as the mechanism. For example there are theories suggesting our accepted model to describe gravity is incomplete and more complex models might explain the discrepancies.
Of course the post saying dark matter is 'invented' does unduly trivialize the experimentation that is going on to attempt explanation and the strength of the evidence supporting the theory that it is a sort of matter versus incomplete models of gravity as an explanation for what we observe.
Assuming they skipped asking permission, I'm not sure that would be "bad faith". Glee can't pretend that 'their' work was completely unrelated and coincidentally sounds like Coulton, no one would believe it. It's a simple fact that they used Coulton's work and they don't deny that. Acknowledging him even without asking permission would be consistent with that stance. It doesn't contradict the concept that they, in good faith, thought use of his work was legal based on the relationships in terms of perception of CC or how copyright works relative to covers/arrangements.
I suppose asking permission, being denied, and proceeding anyway would suggest "bad faith" and thus maybe they are better off not asking permission, but decency would still suggest attribution. I would argue though that for these artists, asking permission is low risk (they will very likely say yes to any friendly, reasonable request) and even if they simply hate your show and want their work to have no relation to it, nothing of critical value was lost, you can find tons of artists out there with novel and interesting arrangements to play ball with.
There's also non-legal and indirect ramifications from this sort of behavior. Glee's fanbase is probably very much sympathetic to the plight of these small artists and thus news of being asses like this will alienate the young, liberal audience that a show like this appeals to. I suspect such a reputation may make other more established artists work against Glee's goals. This may make it more difficult to license popular songs or at least do things like diminish their ability to get the star/guest star they want. With information spreading as much as it does, a show like this has to manage their off-screen image more carefully than in the past.
You are, of course correct. My mindset was more toward "stealing the credit" which I think is the critical sore point from the victims of Fox' actions in this show. In the more common case of copyright infringement, at least there is no mistake regarding attribution of the work.
A show with a reported 3.5 million dollar an episode budget can't even be arsed to let artists know their stuff is going to be used....
All of these people being stolen from would be content with so little as an off-screen credit through some blog post or something. If they wanted to be decent human beings, they would have thrown in an on-screen one liner mentioning the names of the people that are actually responsible for the arrangements, rather than trying to perpetuate the lie that the people behind that show have even an ounce of original musical talent.
All this stuff they could have done without spending so much as a dime...
We aren't talking about someone doing a 'similar' cover, we are talking about Fox, by all appearances, using his Karaoke track verbatim against his license and singing over it. Hell, even the lyrics kept "Johnny C's in trouble" instead of the original lyrics. Analysis suggests they even had to work a bit to try to edit out a duck quack from his track, but still left some sign of that quack behind.
In fact, reports are that the show lifts a *lot* of differently done arrangements of well known songs done by obscure people without permission without a shred of apologetic tone or credit given.
But at least it is equal opportunity, a fair number of more well known musicians whose songs have been featured aren't exactly pleased to hear their works crop up in that show either.
on an Amazon server and have as much storage as you want
Well, one, hosting is not cheap, particularly if you are storage intensive. Having owncloud from the home is a solution around this... but fundamentally it represents a centralized model where you have a likely single point of failure. Your owncloud instance could be killed and all associated devices would be in a pickle.
My assumption with this is that it is more decentralized. Meaning that it's more natural to reach a state where no particular instance is considered more important than others.
This happens both in private and publicly developed projects. All too often the developers do not grasp the fundamentals of security. If lucky, they grasp 'enable encryption' but it's exceptionally rare for them to understand things like mutual authentication and appropriate key management or even why a backdoor or fixed credential is very very bad news. The 'answer' in many companies is to tack on a 'security expert' to audit the code and do some penetration testing. While this is certainly not a bad idea, the security expert who is not a developer can only do so much. Additionally, that security specialist frequently ends up with an antagonistic relationship to the other developers because the developers will want to do things the ludicrously insecure easy way and the security specialist, conversely, will impose security but without much perspective for making the security as easy as it could be. As a common example, take SSL. Many developers will say 'enable SSL because it is secure, but disable all cert checking because it's beyond us'. SSL is nearly useless in that scenario. Security person comes in and rightly notices this is a dumb idea. Security person then forces develoers to turn their project into nagware so that user is well warned about the threat and maybe the user will do something like carefully curate their certificate management to avoid the nag, when in practice the user just trains to always click 'ok'. Meanwhile, a third option of secure, automated PKI chaining off some other solid trust relationship is missed because the required understanding and perspective are not shared among enough of the developer base.
The only way software can be entrusted to do things moderately secure is if solid principles of security are pervasive in the minds of all the developers. Then good security practices are done and frequently in a manner that is extremely unobtrusive to the user.
IBM has gotten better at telling when they know best versus customer. They'll still very happily sell you an IBM-knows-best solution (and honestly, they frequently do), but they no longer are so full of hubris that they'll screw up an opporunity where they do not know best (or at least the customer will never believe IBM knows best).
In the contexxt of this discussion, they take Windows very seriously and, IIRC, they still see more revenue from MS related sales than Linux.
It can be that the private equity situation is a matter of scavenging vultures that raid the company as they grind it into the ground.
However, if MS and Michael Dell were the principle private stake holders, I'd imagine it is at least trying to be what you describe: a way to run the damn business with some risk without day traders killing you. MS would undoubtedly be looking to 'be more Apple', and Dell's position in the market is better than MS's current circumstance of starting from scratch...
This is unfortunately the natural consequence of arbitrarily declaring certain releases 'LTS' without a distinc development cycle.
By the time Debian or Red Hat release something as stable, enthusiasts are generally underwhelmed because the content is ancient from the second it is 'released'. An Ubuntu LTS release enjoys a brief period of appearing fresher, but that comes at a price, quality wise.
Canonical is in an unfortunate position where, as a business, they can't figure out a way 'in'. They are a very popular server distro, but only in the free context where Canonical sees little to no benefit. They had a pretty strong hold over the Linux desktop (IMO largely due to better following upstream whilst the others crammed more and more distro-specific junk in, also due to the change in philosophy the Fedora name represented for RH users), but they haven't been able to derive a business plan. Then they went for embedded TV with a shameless rip off of a third party samsung tv firmware, but that went no where. Now they are making the same noise about phone and will meet the same end as the TV.
I will say that both Ubuntu and Fedora are going along those lines.
Once upon a time the prevaliing community mocked MS for their over-complicated underpinnings with complex inter-component APIs, binary registry, etc etc. We reveled in our straightforward, plain-text configuration that was trivial to examine, if not a tad incovenient for developers to parse and human error could produce confusing errors for the 'uninitiated', but experts had the easiest time writing one-off scripts to do whatever they wanted.
Now, we have things like dbus, network manager, dconf, and systemd effectively mimicking the behavior the community once marked. Now ludicrous 'dbus-send' commands are the only recourse for scripted workflows, the once simple task of writing an init script is now somewhat complicated because they really want a correct dependency graph to speed up boot (a noble goal, but the approach makes administration more difficult). The software stack strongly suggests *not* manipulating resolv.conf at all, instead manipulating some local instance of dnsmasq.
If you want it to be, server hardware is already commoditized. All the priciest components are interchangeable (you *can* buy DIMMs from wherever and cram them in your server from a technology standpoint). Apart from Intel and AMD playing this game where the IOH is generally affine to some particular CPU generation, things are already there (and the IOH is a pretty inexpensive part however you slice it, and could already be subbed out for a PCI-e constructed device if they saw fit). Now the catch is that for *most* traditional IT shops, there continues to be value in well-integrated systems. This will not change that picture.
I see this as another step toward two goals: -Getting ARM into the datacenter in some reputable fashion (which may or may not make sense, depending on whether a compelling performance per watt case can be made that offsets the energy/manufacturing gap that might be incurred from requiring more packages to get to performance desired). -Rebranding 'whitebox'. White box vendors are viewed as the low cost alternative to HP/Dell/IBM, but image wise they are viewed anywhere between 'unacceptably bad' to, at best, 'just as good' from a select portion of the market. Putting cost aside, no one thinks of white box as 'better' than the expensive names. A lot of open compute at the system level is the same thing that has been the reality for the last decade with a shiny new name. The same standards that everyone already followed are getting highlighted more explicitly. This is the opportunity, through marketing, to change minds to say 'better' in some cases or at least make the 'unacceptable' segment of the market take another look.
It can play all the games I care about. Better yet, 10 years from now it is very likely I'll be able to buy a brand new system and continue to play my current games should my existing system fail.
I don't want my gaming library dependent upon a locked down hardware device that, in 10 years, will be a rare 'museum' piece, impractical to replace should I have the need.
Emulators once upon a time could be relied upon to deliver the gaming library from a console to the PC, but it seems to be an ever increasing gap to overcome. More commonality in game engines makes HLE more viable, but even that isn't really doing enough to make up for the slowing pace of PC performance improvement.
Of course, the commercial game market is looking vulnerable as of late. If Steam went offline for good in 5 years time, then many legitimately acquired game licenses would be rendered unusable.
That's awfully optimistic. NAT made the best buy routers make *some* effort to configure the stateful rules correctly or else the customer sees 'broken internet'.
On the other hand, being too open with firewall rules will not look 'broken' to the market. Network security at that point isn't a differentiator and suddenly the manufacturers don't see the dire need to lock down devices enough. In fact, in pursuit of not risking 'breaking' the user, they'd trend toward more open by default.
There is a ray of hope. Increasingly, the ISP is the vendor of the gateway device and not person going out to best buy. ISP is going to, on average, make decisions more securely than a consumer. Hopefully this doesn't supercede consumer ability to buy advanced devices when they *do* know what they are doing...
Even an embarassingly parallel workload like you'd find in world community grid won't fit in cpu cache. Short of that, this architecture would bone you horribly *if* memory were on the long side of the pcie transaction, which there's no way that it would be...
The GbE controller may or may not be part of an IO hub which would provide USB and SATA. Also there is likely to be a video device (though ARM has video as SoC as a matter of course, Intel and AMD server chips do not have Video on package... yet....).
In a server, there is usually some service processor so that software bugs don't require a physical visit to regain capacity. In terms of manageability, I'd expect some I2C connectivity (the relation betwen fan and processor can get very interesting actually). Intel processor speaks PECI exclusively nowadays, wouldn't be surprised if standard basically forces a thermal control mechanism to terminate PECI on daughter card to speak i2c to the fan management subsystem. This is probably the greatest lost opportunity for energy savings; a wholistic system can do some pretty interesting things knowing what the fans are capable of and what sort of baffling is in place.
Also, the daughtercard undoubtedly brings the firmware with it.
All in all, the daughtercard is going to be the motherboard and not much changes. Maybe you get to reuse SATA chips, gigabit, usb and 'on-board' video chips for some cost savings on a mass upgrade, but those parts are pretty cheap and even they get dated. video, USB and gigabit might not matter for the internet datacenter of today and several tomorrows to come, but the SATA throughput is actually significant for data mining.
They can't *possibly* mean that memory would go over that. They have to mean a CPU+Memory daughtercard. As limited already as the concept is without that assumption, the system would be unusably bad if memory transactions went over such a connection.
In terms of server design, none of those names are particularly reputable. One might have *assumed* Intel would do decent system design, but anyone who has touched an Intel designed server knows they aren't particularly good at whole server design.
When they say '8x' PCIe, if that is accurate and the entiriety of the connectivity, what it really means is a standardized IO board for video, ethernet, maybe storage. The CPU daughtercard becomes the new 'motherboard' in terms of cost. You might marginally improve service time for the relatively rare board replace case (CPU replace case is already easy for repair action), but having that board segregated will drive up cost a bit.
They could mean that 8x is the data path and some amount of I2C and Power is allowed through as well to make it more like a 'daughter' board, but the high cost board will still be the daughter board (CPU is pricy and the layers required for a beefy memory subsystem drive up the actual board cost). Meanwhile you have a mess for management, thermal, and power management, likely resulting in having to be wasteful with fans.
Unless they make the daughtercard a behemoth, the design is a non starter for GPGPU and Infiniband applications (unless daughtercard has own PCIE slot allowed, 8x isn't enough for even one of those applications). The daughtercard must hold the memory, either meaning it will be large and expensive, or mandate soldered memory significantly restricting the customization potential in building out a system.
IPSec does approximately zero to change this conversation. One could, however, make the argument that most Windows and Linux deployments are far more conservative in the number and type of listening sockets they open up, and that would aid the case. On the other hand, we are innundated with wildly varying embedded devices with networking with frequently exceedingly poor networking security, which counters the argument.
What NAT established was the standard behavior of buying a network gateway for even residences. Hopefully, with that standard model of a home network firmly pressed into the minds of consumers, even if you don't need to NAT you'd still be forced to get a gateway device (e.g. delegated subnet would still mandate it, and the router companies can implement firewall rules that provide the same benefit as NAT).
Ultimately, the 'security' case for NAT is that it was mandatory security that left the common user with very little recourse and forced them to think very carefully about their network service. Without NAT, then firewalling when done correctly is better, but the possibility of incorrect firewalling is pretty high.
Slashdot Mirror
The SecureBoot model is, frankly, a joke. As soon as you leave the realm of vendor provided OS content, it provides nearly zero protection. Hibernation can't fit into the SecureBoot model, the memory image cannot possibly be signed by the OS vendor private key. kexec could be hypothetically modified to require a signature be passed, but userspace could *look* just like something kexec would produce. Fullscreening qemu-kvm comes to mind...
What distinguishes hibernated memory image from, say, an initrd? Practically speaking, a distro has to allow for initrds to boot that aren't signed by the distribution. In fact, what about booting *any* filesystem? Some may suggest that the goal would be to have every binary signed, but what about end-user maintained scripts and config files? SecureBoot as currently defined only about the OS provider signing what they provide and that leaves a whole lot of area for malicious content outside that scope. It's of little comfort that you have assurance that you are running the correct sshd if, for example, you have malicious ssh_config and malicious authorized_keys.
I think dark matter theory is a bit more presumptive than 'any theory to explain discrepancies between established theory and observed reality with respect to gravity' it specifically hypothesizes some sort of matter as the mechanism. For example there are theories suggesting our accepted model to describe gravity is incomplete and more complex models might explain the discrepancies. Of course the post saying dark matter is 'invented' does unduly trivialize the experimentation that is going on to attempt explanation and the strength of the evidence supporting the theory that it is a sort of matter versus incomplete models of gravity as an explanation for what we observe.
It might be reasonable to map most system binaries to an nfs share where root is mapped to nobody...
Assuming they skipped asking permission, I'm not sure that would be "bad faith". Glee can't pretend that 'their' work was completely unrelated and coincidentally sounds like Coulton, no one would believe it. It's a simple fact that they used Coulton's work and they don't deny that. Acknowledging him even without asking permission would be consistent with that stance. It doesn't contradict the concept that they, in good faith, thought use of his work was legal based on the relationships in terms of perception of CC or how copyright works relative to covers/arrangements.
I suppose asking permission, being denied, and proceeding anyway would suggest "bad faith" and thus maybe they are better off not asking permission, but decency would still suggest attribution. I would argue though that for these artists, asking permission is low risk (they will very likely say yes to any friendly, reasonable request) and even if they simply hate your show and want their work to have no relation to it, nothing of critical value was lost, you can find tons of artists out there with novel and interesting arrangements to play ball with.
There's also non-legal and indirect ramifications from this sort of behavior. Glee's fanbase is probably very much sympathetic to the plight of these small artists and thus news of being asses like this will alienate the young, liberal audience that a show like this appeals to. I suspect such a reputation may make other more established artists work against Glee's goals. This may make it more difficult to license popular songs or at least do things like diminish their ability to get the star/guest star they want. With information spreading as much as it does, a show like this has to manage their off-screen image more carefully than in the past.
You are, of course correct. My mindset was more toward "stealing the credit" which I think is the critical sore point from the victims of Fox' actions in this show. In the more common case of copyright infringement, at least there is no mistake regarding attribution of the work.
A show with a reported 3.5 million dollar an episode budget can't even be arsed to let artists know their stuff is going to be used....
All of these people being stolen from would be content with so little as an off-screen credit through some blog post or something. If they wanted to be decent human beings, they would have thrown in an on-screen one liner mentioning the names of the people that are actually responsible for the arrangements, rather than trying to perpetuate the lie that the people behind that show have even an ounce of original musical talent.
All this stuff they could have done without spending so much as a dime...
We aren't talking about someone doing a 'similar' cover, we are talking about Fox, by all appearances, using his Karaoke track verbatim against his license and singing over it. Hell, even the lyrics kept "Johnny C's in trouble" instead of the original lyrics. Analysis suggests they even had to work a bit to try to edit out a duck quack from his track, but still left some sign of that quack behind.
In fact, reports are that the show lifts a *lot* of differently done arrangements of well known songs done by obscure people without permission without a shred of apologetic tone or credit given.
But at least it is equal opportunity, a fair number of more well known musicians whose songs have been featured aren't exactly pleased to hear their works crop up in that show either.
on an Amazon server and have as much storage as you want
Well, one, hosting is not cheap, particularly if you are storage intensive. Having owncloud from the home is a solution around this... but fundamentally it represents a centralized model where you have a likely single point of failure. Your owncloud instance could be killed and all associated devices would be in a pickle.
My assumption with this is that it is more decentralized. Meaning that it's more natural to reach a state where no particular instance is considered more important than others.
This happens both in private and publicly developed projects. All too often the developers do not grasp the fundamentals of security. If lucky, they grasp 'enable encryption' but it's exceptionally rare for them to understand things like mutual authentication and appropriate key management or even why a backdoor or fixed credential is very very bad news. The 'answer' in many companies is to tack on a 'security expert' to audit the code and do some penetration testing. While this is certainly not a bad idea, the security expert who is not a developer can only do so much. Additionally, that security specialist frequently ends up with an antagonistic relationship to the other developers because the developers will want to do things the ludicrously insecure easy way and the security specialist, conversely, will impose security but without much perspective for making the security as easy as it could be. As a common example, take SSL. Many developers will say 'enable SSL because it is secure, but disable all cert checking because it's beyond us'. SSL is nearly useless in that scenario. Security person comes in and rightly notices this is a dumb idea. Security person then forces develoers to turn their project into nagware so that user is well warned about the threat and maybe the user will do something like carefully curate their certificate management to avoid the nag, when in practice the user just trains to always click 'ok'. Meanwhile, a third option of secure, automated PKI chaining off some other solid trust relationship is missed because the required understanding and perspective are not shared among enough of the developer base.
The only way software can be entrusted to do things moderately secure is if solid principles of security are pervasive in the minds of all the developers. Then good security practices are done and frequently in a manner that is extremely unobtrusive to the user.
and it's the Second Korean war
Well, *technically* the first one isn't 'ended' by some measures, so it would just be resuming the first one.
IBM has gotten better at telling when they know best versus customer. They'll still very happily sell you an IBM-knows-best solution (and honestly, they frequently do), but they no longer are so full of hubris that they'll screw up an opporunity where they do not know best (or at least the customer will never believe IBM knows best).
In the contexxt of this discussion, they take Windows very seriously and, IIRC, they still see more revenue from MS related sales than Linux.
It can be that the private equity situation is a matter of scavenging vultures that raid the company as they grind it into the ground.
However, if MS and Michael Dell were the principle private stake holders, I'd imagine it is at least trying to be what you describe: a way to run the damn business with some risk without day traders killing you. MS would undoubtedly be looking to 'be more Apple', and Dell's position in the market is better than MS's current circumstance of starting from scratch...
This is unfortunately the natural consequence of arbitrarily declaring certain releases 'LTS' without a distinc development cycle.
By the time Debian or Red Hat release something as stable, enthusiasts are generally underwhelmed because the content is ancient from the second it is 'released'. An Ubuntu LTS release enjoys a brief period of appearing fresher, but that comes at a price, quality wise.
Canonical is in an unfortunate position where, as a business, they can't figure out a way 'in'. They are a very popular server distro, but only in the free context where Canonical sees little to no benefit. They had a pretty strong hold over the Linux desktop (IMO largely due to better following upstream whilst the others crammed more and more distro-specific junk in, also due to the change in philosophy the Fedora name represented for RH users), but they haven't been able to derive a business plan. Then they went for embedded TV with a shameless rip off of a third party samsung tv firmware, but that went no where. Now they are making the same noise about phone and will meet the same end as the TV.
I will say that both Ubuntu and Fedora are going along those lines.
Once upon a time the prevaliing community mocked MS for their over-complicated underpinnings with complex inter-component APIs, binary registry, etc etc. We reveled in our straightforward, plain-text configuration that was trivial to examine, if not a tad incovenient for developers to parse and human error could produce confusing errors for the 'uninitiated', but experts had the easiest time writing one-off scripts to do whatever they wanted.
Now, we have things like dbus, network manager, dconf, and systemd effectively mimicking the behavior the community once marked. Now ludicrous 'dbus-send' commands are the only recourse for scripted workflows, the once simple task of writing an init script is now somewhat complicated because they really want a correct dependency graph to speed up boot (a noble goal, but the approach makes administration more difficult). The software stack strongly suggests *not* manipulating resolv.conf at all, instead manipulating some local instance of dnsmasq.
Yes, as I alluded to, that is the bane of the gaming industry. The bad news for consoles is that they too have such schemes.
So in PC land, screwed by DRM but the platform will continue to be availoble.
In Console land, screwed by DRM *and* the whims/fortunes of the platform provider hardware wise.
If you want it to be, server hardware is already commoditized. All the priciest components are interchangeable (you *can* buy DIMMs from wherever and cram them in your server from a technology standpoint). Apart from Intel and AMD playing this game where the IOH is generally affine to some particular CPU generation, things are already there (and the IOH is a pretty inexpensive part however you slice it, and could already be subbed out for a PCI-e constructed device if they saw fit). Now the catch is that for *most* traditional IT shops, there continues to be value in well-integrated systems. This will not change that picture.
I see this as another step toward two goals:
-Getting ARM into the datacenter in some reputable fashion (which may or may not make sense, depending on whether a compelling performance per watt case can be made that offsets the energy/manufacturing gap that might be incurred from requiring more packages to get to performance desired).
-Rebranding 'whitebox'. White box vendors are viewed as the low cost alternative to HP/Dell/IBM, but image wise they are viewed anywhere between 'unacceptably bad' to, at best, 'just as good' from a select portion of the market. Putting cost aside, no one thinks of white box as 'better' than the expensive names. A lot of open compute at the system level is the same thing that has been the reality for the last decade with a shiny new name. The same standards that everyone already followed are getting highlighted more explicitly. This is the opportunity, through marketing, to change minds to say 'better' in some cases or at least make the 'unacceptable' segment of the market take another look.
I payed 300 dollars for my most recent PC.
It can play all the games I care about. Better yet, 10 years from now it is very likely I'll be able to buy a brand new system and continue to play my current games should my existing system fail.
I don't want my gaming library dependent upon a locked down hardware device that, in 10 years, will be a rare 'museum' piece, impractical to replace should I have the need.
Emulators once upon a time could be relied upon to deliver the gaming library from a console to the PC, but it seems to be an ever increasing gap to overcome. More commonality in game engines makes HLE more viable, but even that isn't really doing enough to make up for the slowing pace of PC performance improvement.
Of course, the commercial game market is looking vulnerable as of late. If Steam went offline for good in 5 years time, then many legitimately acquired game licenses would be rendered unusable.
That's awfully optimistic. NAT made the best buy routers make *some* effort to configure the stateful rules correctly or else the customer sees 'broken internet'.
On the other hand, being too open with firewall rules will not look 'broken' to the market. Network security at that point isn't a differentiator and suddenly the manufacturers don't see the dire need to lock down devices enough. In fact, in pursuit of not risking 'breaking' the user, they'd trend toward more open by default.
There is a ray of hope. Increasingly, the ISP is the vendor of the gateway device and not person going out to best buy. ISP is going to, on average, make decisions more securely than a consumer. Hopefully this doesn't supercede consumer ability to buy advanced devices when they *do* know what they are doing...
Even an embarassingly parallel workload like you'd find in world community grid won't fit in cpu cache. Short of that, this architecture would bone you horribly *if* memory were on the long side of the pcie transaction, which there's no way that it would be...
The GbE controller may or may not be part of an IO hub which would provide USB and SATA. Also there is likely to be a video device (though ARM has video as SoC as a matter of course, Intel and AMD server chips do not have Video on package... yet....).
In a server, there is usually some service processor so that software bugs don't require a physical visit to regain capacity. In terms of manageability, I'd expect some I2C connectivity (the relation betwen fan and processor can get very interesting actually). Intel processor speaks PECI exclusively nowadays, wouldn't be surprised if standard basically forces a thermal control mechanism to terminate PECI on daughter card to speak i2c to the fan management subsystem. This is probably the greatest lost opportunity for energy savings; a wholistic system can do some pretty interesting things knowing what the fans are capable of and what sort of baffling is in place.
Also, the daughtercard undoubtedly brings the firmware with it.
All in all, the daughtercard is going to be the motherboard and not much changes. Maybe you get to reuse SATA chips, gigabit, usb and 'on-board' video chips for some cost savings on a mass upgrade, but those parts are pretty cheap and even they get dated. video, USB and gigabit might not matter for the internet datacenter of today and several tomorrows to come, but the SATA throughput is actually significant for data mining.
They can't *possibly* mean that memory would go over that. They have to mean a CPU+Memory daughtercard. As limited already as the concept is without that assumption, the system would be unusably bad if memory transactions went over such a connection.
In terms of server design, none of those names are particularly reputable. One might have *assumed* Intel would do decent system design, but anyone who has touched an Intel designed server knows they aren't particularly good at whole server design.
Maybe this would be useful in some HPC environments where applications can be written to maximize the use of CPU cache,,
Actually, it would be murder on HPC applications, which generally rely on quality inter-node communication to acheive high scale.
When they say '8x' PCIe, if that is accurate and the entiriety of the connectivity, what it really means is a standardized IO board for video, ethernet, maybe storage. The CPU daughtercard becomes the new 'motherboard' in terms of cost. You might marginally improve service time for the relatively rare board replace case (CPU replace case is already easy for repair action), but having that board segregated will drive up cost a bit.
They could mean that 8x is the data path and some amount of I2C and Power is allowed through as well to make it more like a 'daughter' board, but the high cost board will still be the daughter board (CPU is pricy and the layers required for a beefy memory subsystem drive up the actual board cost). Meanwhile you have a mess for management, thermal, and power management, likely resulting in having to be wasteful with fans.
Unless they make the daughtercard a behemoth, the design is a non starter for GPGPU and Infiniband applications (unless daughtercard has own PCIE slot allowed, 8x isn't enough for even one of those applications). The daughtercard must hold the memory, either meaning it will be large and expensive, or mandate soldered memory significantly restricting the customization potential in building out a system.
IPSec does approximately zero to change this conversation. One could, however, make the argument that most Windows and Linux deployments are far more conservative in the number and type of listening sockets they open up, and that would aid the case. On the other hand, we are innundated with wildly varying embedded devices with networking with frequently exceedingly poor networking security, which counters the argument.
What NAT established was the standard behavior of buying a network gateway for even residences. Hopefully, with that standard model of a home network firmly pressed into the minds of consumers, even if you don't need to NAT you'd still be forced to get a gateway device (e.g. delegated subnet would still mandate it, and the router companies can implement firewall rules that provide the same benefit as NAT).
Ultimately, the 'security' case for NAT is that it was mandatory security that left the common user with very little recourse and forced them to think very carefully about their network service. Without NAT, then firewalling when done correctly is better, but the possibility of incorrect firewalling is pretty high.