As far as I know, the major "feature" of UEFI over the original EFI is signed modules, ultimately allowing for control over what may be booted. The original EFI, while still bloated and overly complex (though considerably less so), would have been a clear improvement over the BIOS. However, the current incarnation of UEFI may be downright dangerous to our freedoms.
As bad as the BIOS is, at least we can run the OS of our choice. With UEFI, we still may--for now. Unfortunately, that "feature" may be removed in the future, just as Sony did with Linux on the PS3.
Or at least that is how I understand it. There was a lot of concern over this in the past, but strangely, I haven't seen much recently. I would love to be rid of the BIOS, but something like coreboot would be much better, as it would allow for a completely open platform, and is focused on actually booting the machine.
In my experience, it is hard to even imagine 10/2 Mbit/s average performance anywhere in the US; those numbers look way inflated. As the speed tests are short duration bursts, they are not indicative of actual sustained performance.
mDNSResponder--which Apple now uses for all DNS resolution--is broken with IPv6. If a cached nonexistent record for IPv4 exists, it won't even try to look up the IPv6 address. More than a few places running IPv6 set those records to expire more quickly, and thus IPv6-only hosts effectively become a black hole to OSX most of the time.
In any case, I had a look at the source, and it is one seriously ugly mess. I can't believe that Apple would replace a critical system component with such a flakey piece of code. (Or rather, I would like to not believe it. As long as it sort of works for most people though, Apple simply won't care.)
Anyway, the IPv6 code is just for show, so they claim it as a "feature." It is clearly obvious that no one at Apple actually uses it though.
Unfortunately, the fundamental nature of Flash will remain a bottleneck. The value of PCM is not in fixing the terrible performance of Flash based SSDs, but in their replacement all together. PCM is faster, 10-100 thousand times more durable, will scale smaller, and isn't crippled by Flash's block-erase semantics.
What Flash based SSDs really need is non-volatile RAM for the controller, not cache. In this role, a capacitor would work just as well, and yet manufacturers are still too cheap to include those.
I use and recommend OpenWRT myself, but the truth is, this is a problem which discourages potential users. One's first experience with OpenWRT shouldn't be frustration over digging for the proper documentation.
The primary problem isn't with the wiki, and can't be fixed in the wiki. The main links on the home page should point somewhere more useful, hence I recommended starting with the wiki.
The complaint about documentation is spot on. Following the documentation link for the latest release on the main page leads you to a page with an empty "Installation" section. The download link leads to a directory containing the various architecture specific image files, with no information on how to choose the correct one. At that point, most prospective users probably probably throw up their hands and go elsewhere, which is a shame.
However, OpenWRT itself is a nice system, and if the developers want to concentrate on the system, I can't blame them. For interested users, start with the Wiki. Some digging for various documentation may be required, but most of the important stuff is there somewhere. If you have given the search an honest effort, the forums will likely be a lot more receptive to your questions.
for SD/HD video, photos, side-by-side pages, single-page portrait, and it is fine for development and browsing if the display is large enough. For smaller displays though, there isn't enough vertical resolution. Making things worse, 16:9 is bad enough on the desktop, but especially obnoxious in notebooks. At approximately phi, it is also a nice all around pleasant ratio.
It is unfortunate that some marketing jerk recognized that higher aspects give you less space for the diagonal Inch. 16:9 displays are only good for one thing--16:9 video. They have too little vertical resolution for side-by-side pages, are too narrow in portrait, and are extremely wasteful while viewing SD video or photos. You also need an enormous display to have enough vertical resolution for simple web browsing.
If widescreen video is not important, another aspect ratio worth considering would be 14:10, as sqrt(2) is optimal for pages / columns / portrait. See paper size.
Sadly, 16:9 will probably win out in the end just like the awful TN displays did.
That may seem fine now, but core and memory density will continue to grow. It just doesn't scale, and in a few years, the efficiency advantages will be lost with increasingly integration. For example, a single 32-core/32GB machine vs. eight 4-core/4GB machines, 8 network connections, etc. Also, 32-bits of address space is already insufficient to properly utilize 4GB of physical RAM.
The fact is, it is a dead end, and I don't think Google is short-sighted or arrogant enough to employ some of the most talented people in the industry to glue together some custom ARM design. If they were happy doing that, they would still be at Apple.
A 32-bit architecture like ARM really has no place in Google's servers, and it is hard to imagine that those who jumped ship from PASemi/Apple would want to do the same sort of ARM integration monkey work at Google.
It is a shame that Google didn't pick up PASemi before Apple wasted their processor and years of effort; the PA6T would have served Google very well. I expect that Google is thinking long-term here, and we may even see a brand new 64-bit ISA, something that scales well from phones to low-power servers. (Okay, that may be a little hopeful, but I expect something new and interesting in any case.)
Some of the key talent, yes. However, that talent would have been wasted at Apple, just as their fine processor was. I'd be surprised if any of top people stayed long, after Apple tossed out their years of effort, only to have them doing ASIC monkey work.
It disgusts me to see how Apple chews up brilliant companies only to scavenge a few bits and pieces.
...and the STEC drives have the performance to match. If what you need are IOPS and not mere space, they are more than competitive, and you don't have to worry about them tossing transactions on power loss or performance degradation as they fill.
Re:This just in!
on
The Apple Two
·
· Score: 2, Insightful
A personal computer is a computer that _does what you want it to do._ For a shockingly large number of people, Apple's present product line does exactly that,
Agreed about your definition of a personal computer. However, just because there is a large intersection between what Apple makes and what people want, does not make it a personal computer!
Make no mistake, it does what Apple wants, and when (not if) they so decide, it will cease to do those things. That is the nature of DRM, and it rears its ugly head often enough that you should know the difference by now. (Assuming that you a/. reader, and not just an Apple shill.)
Back in Woz's day, it was important to have a BASIC interpreter on your personal computer, but not because it made the computer more "open" in some vague ideological terms. It was important because that was how a lot of useful computer software was transmitted.
Even today, "a lot of useful computer software" is transmitted in much the same way, and you can run it on a personal computer. Unfortunately for Apple, it competes with their existing products, so they now exclude it. Even if you a paying App developer, you may receive the same treatment, as has happened time and again.
Sizes were consistent, and this actually makes it more difficult, by applying base 10 units to quantities which are fundamentally base 2. Now you have to undo that conversion to compare sizes with those on standard systems. (i.e. with Windows and all other Unix/Linux/BSD systems.)
I'm not saying that the correct SI units shouldn't be applied; by all means, use KiB/KB as appropriate, but base 2 units should be used for fundamentally base 2 quantities.
As for rates, they are almost always a measured quantity, or defined in terms of a specified frequency, so base 10 units are appropriate in most cases. It really isn't critical either way though, as long as the appropriate units are used.
Things which are measured should use base 10 units. (Bandwidth, Hz, mass, etc.)
Things which are addressed in binary should use base 2 units. (Memory, cache, disk, etc.)
Ubuntu should not follow Apple's bad example here. Maybe things were different 30 years ago, but more recently, every platform had settled on base 2 units for storage, save the dishonest drive manufacturers, and now Apple.
Perpetuating this stupidity makes the display of file sizes across platforms inconsistent, which is a lot worse than the "problem" it is attempting to solve.
NUT is another alternative, which is open, simple, and well designed. Along with Matroska, it is also capable of containing Ogg Theora and Vorbis streams, so there is really is no good reason to use the Ogg container anymore. The author of the article is correct--the Ogg container is an awful format.
The main complaints about Matroska are two-fold. One, the EMBL encoding is overly complicated. It requires a considerable amount of code to parse, and also imposes an unnecessary degree of overhead. The second is a much more serious problem: a Matroska file can only contain one timebase. Thus, in order to mux streams with different timebases, approximation is required. To accurately represent the converted timebases, it is necessary to use a much finer granularity, and then you also lose the exact timestamps.
The NUT specification and code is available from svn://svn.mplayerhq.hu/nut, and the (de)muxers are included in MPlayer/FFmpeg, VLC, and probably elsewhere.
DNSCurve is an elegant and efficient idea, and most importantly, it would be easily deployable--requiring minimal changes to infrastructure, and no cooperation from end users or support in end devices. The only obstacle that I am aware of, is that no implementation exists. (Which is a problem...)
It does not provide end-end trust, but it is close enough in most cases, and you can always run your own local DNSCurve forwarder if you need the extra guarantee.
Even so, DNSCurve and DNSSEC are complimentary solutions, and both may be desirable. DNSCurve would provide vast benefits though, with exceedingly little cost and effort.
3. With a few exceptions, modern, supported OSes (Windows [2003, 2008, Vista, 7], GNU/Linux, all of the BSDs, OS X) support IPv6 perfectly.
Sadly, OSX does not. There is no support for NFS or SMB over IPv6. More importantly though, DNS is completely broken for hosts which have both v4 and v6 addresses, so you won't get far if you turn off v4.
Another critically missing piece is home routers. Also,/. regrettably, but you could use http://slashdot.org.sixxs.org/ in the mean time.
120hz displays make a lot of sense in the near term, but even that frame rate may be woefully inadequate for providing a true, indistinguishable from reality VR experience. (Of course, it will be a while before the resolution and color reproduction also catch up, but it is an interesting topic.)
In any case, no one really knows what will be enough, but 24fps is certainly not. 120hz displays will be a great improvement, both for gaming and video. The latter, because both 24fps movies, and 30fps video (or perhaps 60 fields/s interlaced) divide into it nicely. (If you want to be pedantic, it isn't exactly 30fps, but it is close enough, and even PAL would look better.)
The argument for safety is very simple, and it doesn't require a physicist to make it. Sadly, it does require common sense, which is likely to be absent in this case.
Anyway, here it is: the Earth has been--and continues to be--bombarded by cosmic rays of immensely greater energies than found in the LHC. After billions of years without incident, one can only conclude that any problems must not be very significant, as we are here after all.
We aren't off the hook though; even if the LHC may not be capable of destroying the Earth, the lawyers are certainly doing a fine job.
The fundamental problem lies in USB bridge chips which do not properly implement the cache management commands. Others have replied that you need to disable the write cache, and while that would be a solution, it is often impossible. Even with bridge chips that do support the cache disable command, some hard drives will not honor it anyway.
Most USB bridges simply lie about when data has been written, which makes it very difficult for a filesystem on top of it to make any guarantees. While it may not happen often, this can have disastrous results, as you have seen.
The copy on write nature of ZFS left it especially vulnerable to broken USB storage, and could easily leave you with a corrupted pool requiring manual intervention and a bit of luck to recover. Thankfully, the recent bits address this, and ZFS is now the only filesystem that I would trust on top of USB storage. Most other filesystems will survive without incident, but at the cost of some silent data corruption.
Just because you have control over your phone, does not mean you are not obligated to customize or hack it in any way. You are concerned about compatibility, but Apple's lock-in model is actually the antithesis of compatibility.
To put it in car terms, you want an Apple-controlled car, that can only drive on Apple-approved roads. Since Apple knows best, and obviously has your interests in mind, you would willingly subject yourself to such control.
Well, if you really want to be a tool, that is your choice, but I think you should give it more thought. Your freedom of choice need not be mutually exclusive with a good user experience. If google offers you both, you would be a fool not to jump on it.
Exactly. There is no use in fining corporations, as it only hurts their customers. The fines are nothing but a cash grab by the government, and the settlements benefit no one but the lawyers.
There need to be serious consequences for this type of thing. They should tear the responsible people limb from limb, literally.
While you may have a point, it is similar to complaining about Ampere's Law, before Maxwell's correction. Sure, it wasn't exactly right, but it more or less had the same properties.
This may not be the simplest function, but it retains the most fundamentally interesting properties of 2D fractals: infinite detail generated by a simple mathematical function. It is fascinating just the same, and is only a (very) minor modification of the original 2D function.
The Mandelbulb is awe-inspiring, and it is disappointing to see that story nitpicking outclasses your interest in this wonderful piece of work. If it were merely pretty pictures generated by iterative functions, I think you would be justified. It isn't though--this is an amazing structure generated by a pure and simple piece of math.
Company health? Either way, Sun is dead if this deal goes through--Oracle merely wants dibs on the corpse. They will scavenge what they can, and sell off the rest or simply let it rot.
Sun has some very cool hardware and software, not to mention an open source friendly attitude--probably none of which will survive the acquisition. I would rather see Sun struggling to survive than on the chopping block for a company like Oracle. I can't imagine that OpenSolaris, ZFS, Sparc, VirtualBox, Java, MySQL, or anything else really, will meet with a good fate. Things look quite grim in fact, as many of these directly compete with or threaten Oracle's products, or simply don't fit at all.
So, I can't say I'm disappointed with this decision.
I don't know, how much does an anycast address cost? So much that Google or Akamai can't afford it? (Also, RR load balancing is a separate thing entirely.)
Regarding the CDNs, you didn't read the article did you; it is fundamentally flawed. The CDN does not choose a server based upon proximity to the endpoint, but rather to the recursive resolver through which the DNS request passed.
Slashdot Mirror
As far as I know, the major "feature" of UEFI over the original EFI is signed modules, ultimately allowing for control over what may be booted. The original EFI, while still bloated and overly complex (though considerably less so), would have been a clear improvement over the BIOS. However, the current incarnation of UEFI may be downright dangerous to our freedoms.
As bad as the BIOS is, at least we can run the OS of our choice. With UEFI, we still may--for now. Unfortunately, that "feature" may be removed in the future, just as Sony did with Linux on the PS3.
Or at least that is how I understand it. There was a lot of concern over this in the past, but strangely, I haven't seen much recently. I would love to be rid of the BIOS, but something like coreboot would be much better, as it would allow for a completely open platform, and is focused on actually booting the machine.
In my experience, it is hard to even imagine 10/2 Mbit/s average performance anywhere in the US; those numbers look way inflated. As the speed tests are short duration bursts, they are not indicative of actual sustained performance.
mDNSResponder--which Apple now uses for all DNS resolution--is broken with IPv6. If a cached nonexistent record for IPv4 exists, it won't even try to look up the IPv6 address. More than a few places running IPv6 set those records to expire more quickly, and thus IPv6-only hosts effectively become a black hole to OSX most of the time.
In any case, I had a look at the source, and it is one seriously ugly mess. I can't believe that Apple would replace a critical system component with such a flakey piece of code. (Or rather, I would like to not believe it. As long as it sort of works for most people though, Apple simply won't care.)
Anyway, the IPv6 code is just for show, so they claim it as a "feature." It is clearly obvious that no one at Apple actually uses it though.
Unfortunately, the fundamental nature of Flash will remain a bottleneck. The value of PCM is not in fixing the terrible performance of Flash based SSDs, but in their replacement all together. PCM is faster, 10-100 thousand times more durable, will scale smaller, and isn't crippled by Flash's block-erase semantics.
What Flash based SSDs really need is non-volatile RAM for the controller, not cache. In this role, a capacitor would work just as well, and yet manufacturers are still too cheap to include those.
I use and recommend OpenWRT myself, but the truth is, this is a problem which discourages potential users. One's first experience with OpenWRT shouldn't be frustration over digging for the proper documentation.
The primary problem isn't with the wiki, and can't be fixed in the wiki. The main links on the home page should point somewhere more useful, hence I recommended starting with the wiki.
The complaint about documentation is spot on. Following the documentation link for the latest release on the main page leads you to a page with an empty "Installation" section. The download link leads to a directory containing the various architecture specific image files, with no information on how to choose the correct one. At that point, most prospective users probably probably throw up their hands and go elsewhere, which is a shame.
However, OpenWRT itself is a nice system, and if the developers want to concentrate on the system, I can't blame them. For interested users, start with the Wiki. Some digging for various documentation may be required, but most of the important stuff is there somewhere. If you have given the search an honest effort, the forums will likely be a lot more receptive to your questions.
for SD/HD video, photos, side-by-side pages, single-page portrait, and it is fine for development and browsing if the display is large enough. For smaller displays though, there isn't enough vertical resolution. Making things worse, 16:9 is bad enough on the desktop, but especially obnoxious in notebooks. At approximately phi, it is also a nice all around pleasant ratio.
It is unfortunate that some marketing jerk recognized that higher aspects give you less space for the diagonal Inch. 16:9 displays are only good for one thing--16:9 video. They have too little vertical resolution for side-by-side pages, are too narrow in portrait, and are extremely wasteful while viewing SD video or photos. You also need an enormous display to have enough vertical resolution for simple web browsing.
If widescreen video is not important, another aspect ratio worth considering would be 14:10, as sqrt(2) is optimal for pages / columns / portrait. See paper size.
Sadly, 16:9 will probably win out in the end just like the awful TN displays did.
That may seem fine now, but core and memory density will continue to grow. It just doesn't scale, and in a few years, the efficiency advantages will be lost with increasingly integration. For example, a single 32-core/32GB machine vs. eight 4-core/4GB machines, 8 network connections, etc. Also, 32-bits of address space is already insufficient to properly utilize 4GB of physical RAM.
The fact is, it is a dead end, and I don't think Google is short-sighted or arrogant enough to employ some of the most talented people in the industry to glue together some custom ARM design. If they were happy doing that, they would still be at Apple.
A 32-bit architecture like ARM really has no place in Google's servers, and it is hard to imagine that those who jumped ship from PASemi/Apple would want to do the same sort of ARM integration monkey work at Google.
It is a shame that Google didn't pick up PASemi before Apple wasted their processor and years of effort; the PA6T would have served Google very well. I expect that Google is thinking long-term here, and we may even see a brand new 64-bit ISA, something that scales well from phones to low-power servers. (Okay, that may be a little hopeful, but I expect something new and interesting in any case.)
Some of the key talent, yes. However, that talent would have been wasted at Apple, just as their fine processor was. I'd be surprised if any of top people stayed long, after Apple tossed out their years of effort, only to have them doing ASIC monkey work.
It disgusts me to see how Apple chews up brilliant companies only to scavenge a few bits and pieces.
...and the STEC drives have the performance to match. If what you need are IOPS and not mere space, they are more than competitive, and you don't have to worry about them tossing transactions on power loss or performance degradation as they fill.
A personal computer is a computer that _does what you want it to do._ For a shockingly large number of people, Apple's present product line does exactly that,
Agreed about your definition of a personal computer. However, just because there is a large intersection between what Apple makes and what people want, does not make it a personal computer!
Make no mistake, it does what Apple wants, and when (not if) they so decide, it will cease to do those things. That is the nature of DRM, and it rears its ugly head often enough that you should know the difference by now. (Assuming that you a /. reader, and not just an Apple shill.)
Back in Woz's day, it was important to have a BASIC interpreter on your personal computer, but not because it made the computer more "open" in some vague ideological terms. It was important because that was how a lot of useful computer software was transmitted.
Even today, "a lot of useful computer software" is transmitted in much the same way, and you can run it on a personal computer. Unfortunately for Apple, it competes with their existing products, so they now exclude it. Even if you a paying App developer, you may receive the same treatment, as has happened time and again.
Sizes were consistent, and this actually makes it more difficult, by applying base 10 units to quantities which are fundamentally base 2. Now you have to undo that conversion to compare sizes with those on standard systems. (i.e. with Windows and all other Unix/Linux/BSD systems.)
I'm not saying that the correct SI units shouldn't be applied; by all means, use KiB/KB as appropriate, but base 2 units should be used for fundamentally base 2 quantities.
As for rates, they are almost always a measured quantity, or defined in terms of a specified frequency, so base 10 units are appropriate in most cases. It really isn't critical either way though, as long as the appropriate units are used.
Things which are measured should use base 10 units. (Bandwidth, Hz, mass, etc.)
Things which are addressed in binary should use base 2 units. (Memory, cache, disk, etc.)
Ubuntu should not follow Apple's bad example here. Maybe things were different 30 years ago, but more recently, every platform had settled on base 2 units for storage, save the dishonest drive manufacturers, and now Apple.
Perpetuating this stupidity makes the display of file sizes across platforms inconsistent, which is a lot worse than the "problem" it is attempting to solve.
NUT is another alternative, which is open, simple, and well designed. Along with Matroska, it is also capable of containing Ogg Theora and Vorbis streams, so there is really is no good reason to use the Ogg container anymore. The author of the article is correct--the Ogg container is an awful format.
The main complaints about Matroska are two-fold. One, the EMBL encoding is overly complicated. It requires a considerable amount of code to parse, and also imposes an unnecessary degree of overhead. The second is a much more serious problem: a Matroska file can only contain one timebase. Thus, in order to mux streams with different timebases, approximation is required. To accurately represent the converted timebases, it is necessary to use a much finer granularity, and then you also lose the exact timestamps.
The NUT specification and code is available from svn://svn.mplayerhq.hu/nut, and the (de)muxers are included in MPlayer/FFmpeg, VLC, and probably elsewhere.
DNSCurve is an elegant and efficient idea, and most importantly, it would be easily deployable--requiring minimal changes to infrastructure, and no cooperation from end users or support in end devices. The only obstacle that I am aware of, is that no implementation exists. (Which is a problem...)
It does not provide end-end trust, but it is close enough in most cases, and you can always run your own local DNSCurve forwarder if you need the extra guarantee.
Even so, DNSCurve and DNSSEC are complimentary solutions, and both may be desirable. DNSCurve would provide vast benefits though, with exceedingly little cost and effort.
3. With a few exceptions, modern, supported OSes (Windows [2003, 2008, Vista, 7], GNU/Linux, all of the BSDs, OS X) support IPv6 perfectly.
Sadly, OSX does not. There is no support for NFS or SMB over IPv6. More importantly though, DNS is completely broken for hosts which have both v4 and v6 addresses, so you won't get far if you turn off v4.
Another critically missing piece is home routers. Also, /. regrettably, but you could use http://slashdot.org.sixxs.org/ in the mean time.
They have an interesting page about the question of "How many frames per second can the human eye see?"
120hz displays make a lot of sense in the near term, but even that frame rate may be woefully inadequate for providing a true, indistinguishable from reality VR experience. (Of course, it will be a while before the resolution and color reproduction also catch up, but it is an interesting topic.)
In any case, no one really knows what will be enough, but 24fps is certainly not. 120hz displays will be a great improvement, both for gaming and video. The latter, because both 24fps movies, and 30fps video (or perhaps 60 fields/s interlaced) divide into it nicely. (If you want to be pedantic, it isn't exactly 30fps, but it is close enough, and even PAL would look better.)
The argument for safety is very simple, and it doesn't require a physicist to make it. Sadly, it does require common sense, which is likely to be absent in this case.
Anyway, here it is: the Earth has been--and continues to be--bombarded by cosmic rays of immensely greater energies than found in the LHC. After billions of years without incident, one can only conclude that any problems must not be very significant, as we are here after all.
We aren't off the hook though; even if the LHC may not be capable of destroying the Earth, the lawyers are certainly doing a fine job.
The fundamental problem lies in USB bridge chips which do not properly implement the cache management commands. Others have replied that you need to disable the write cache, and while that would be a solution, it is often impossible. Even with bridge chips that do support the cache disable command, some hard drives will not honor it anyway.
Most USB bridges simply lie about when data has been written, which makes it very difficult for a filesystem on top of it to make any guarantees. While it may not happen often, this can have disastrous results, as you have seen.
The copy on write nature of ZFS left it especially vulnerable to broken USB storage, and could easily leave you with a corrupted pool requiring manual intervention and a bit of luck to recover. Thankfully, the recent bits address this, and ZFS is now the only filesystem that I would trust on top of USB storage. Most other filesystems will survive without incident, but at the cost of some silent data corruption.
Just because you have control over your phone, does not mean you are not obligated to customize or hack it in any way. You are concerned about compatibility, but Apple's lock-in model is actually the antithesis of compatibility.
To put it in car terms, you want an Apple-controlled car, that can only drive on Apple-approved roads. Since Apple knows best, and obviously has your interests in mind, you would willingly subject yourself to such control.
Well, if you really want to be a tool, that is your choice, but I think you should give it more thought. Your freedom of choice need not be mutually exclusive with a good user experience. If google offers you both, you would be a fool not to jump on it.
Exactly. There is no use in fining corporations, as it only hurts their customers. The fines are nothing but a cash grab by the government, and the settlements benefit no one but the lawyers.
There need to be serious consequences for this type of thing. They should tear the responsible people limb from limb, literally.
While you may have a point, it is similar to complaining about Ampere's Law, before Maxwell's correction. Sure, it wasn't exactly right, but it more or less had the same properties.
This may not be the simplest function, but it retains the most fundamentally interesting properties of 2D fractals: infinite detail generated by a simple mathematical function. It is fascinating just the same, and is only a (very) minor modification of the original 2D function.
The Mandelbulb is awe-inspiring, and it is disappointing to see that story nitpicking outclasses your interest in this wonderful piece of work. If it were merely pretty pictures generated by iterative functions, I think you would be justified. It isn't though--this is an amazing structure generated by a pure and simple piece of math.
Company health? Either way, Sun is dead if this deal goes through--Oracle merely wants dibs on the corpse. They will scavenge what they can, and sell off the rest or simply let it rot.
Sun has some very cool hardware and software, not to mention an open source friendly attitude--probably none of which will survive the acquisition. I would rather see Sun struggling to survive than on the chopping block for a company like Oracle. I can't imagine that OpenSolaris, ZFS, Sparc, VirtualBox, Java, MySQL, or anything else really, will meet with a good fate. Things look quite grim in fact, as many of these directly compete with or threaten Oracle's products, or simply don't fit at all.
So, I can't say I'm disappointed with this decision.
I don't know, how much does an anycast address cost? So much that Google or Akamai can't afford it? (Also, RR load balancing is a separate thing entirely.)
Regarding the CDNs, you didn't read the article did you; it is fundamentally flawed. The CDN does not choose a server based upon proximity to the endpoint, but rather to the recursive resolver through which the DNS request passed.
Anycast does exactly what you want.