I'm a happy Rackspace Cloud customer. I use it for a few small VMs that I treat like normal, uniquely-configured servers, but I don't have to mess with all the details of running a data center, and that makes my life easier. I looked at EC2, and it became very obvious that it was not intended to be used that way. If you want to do the whole dynamic cloud thing where your log scraper uses an API to request more CPU for this VM, more RAM for that VM, and duplicate a few more web front-end hosts, EC2 definitely covers the bases, but I just wanted a couple servers with redundant power and storage, pre-built backup/restore system, in a data center that's professionally managed by people who are not me, and I wanted to do it without spending tens or hundreds of thousands of dollars up front.
In terms of business growth, EC2-style cloud computing is great for large organizations with their own developers who can afford semi-custom solutions that offload 80% of their server infrastructure to Amazon's data centers, but that's a market that will saturate quickly. The larger opportunity is customers like me, who are trying to help a small organization grow into a large organization without investing huge amounts of time and money up front (because they don't have either to spare yet), and need servers that aren't just run from someone's desk. If Amazon invests the short term returns from EC2 into something that competes directly with Rackspace Cloud, I'm sure they'll be competitive, but right now the two offerings aren't directly comparable.
Anyone remember when Slashdot hit 16,777,215 comments, and overflowed MEDIUMINT? The ALTER TABLE statement that fixed it took hours to run. I shudder to think how long it'll take to fix this, even with the problem diagnosed.
If you're too disorganized for barcode scanners...
on
Finding Lost IT With RFID
·
· Score: 2, Insightful
...then how is knowing that the server you're looking for is (or more likely is not) somewhere within X meters going to help?
While the data within the encrypted volume should be indistinguishable from randomness, the metadata headers are quite distinguishable. It's pretty obvious if something is a LUKS volume, but within that you shouldn't be able to tell.
...is that most users of low-end CPUs won't notice the difference going from 2 threads to 4, or turning on extra cache. They'll just notice their Windows 7 system getting slow, as Windows systems are wont to do, and then pay $50 only to find out that it's still just as slow, because it did nothing for their memory-starved, I/O-bound, single-threaded workload.
Pi has the property that all binary strings of a given length occur with equal frequency, making it an excellent source of fair pseudorandom bits. There are plenty of applications in which 2 quadrillion pseudorandom bits is grossly insufficient.
It would get you nowhere near that. A substantial fraction of any mainframe architecture's instruction set is emulated in software. The actual MIPS ratings are way below the MHz ratings, whereas on most superscalar architectures, MIPS exceeds MHz.
Once you've paid that penalty as well as the qemu penalty, you're getting down to somewhere in the Doom/Quake I range, with no hardware acceleration.
While T-Mobile's towers may be capable of 21 Mbps HSPA+, the G2 itself can only do 14.4 Mbps, according to the fine print on T-Mobile's teaser site. Of course, you'll get nowhere near this in real life, but if you have a 7.2 Mbps HSPA device, and you're expecting it to be 3x as fast as whatever you get in real life on that, you'll be disappointed to only get 2x that, at best.
There's a first time for everything. When I was at Red Hat, a customer (maybe you?) experienced a SAN-wide outage due to an error, caused by a rare hardware failure mode, that the vendor's engineers told me in private they had never seen before. It was one of the more reputable SAN vendors, and they worked with us on a kernel patch to recover from that error more intelligently. There's now a patch in the Linux kernel to gracefully recover from an error that has only been seen once outside of a hardware lab.
I've also talked to plenty of engineers and support people who had simply never heard of a particular problem before, because their companies lacked sufficiently well-organized support and bug tracking systems, and couldn't hold on to their experienced employees long enough to have someone around who knew what was going on the next time the problem came up.
In the world of enterprise computing, the law of large numbers is working against you. Some vendors understand this, and treat each novel failure as an opportunity to harden the product further. You usually pay a premium for this, but it's worth it. Others just swap the bad board and update their resumes. It sounds like NG went with the lowest bidder.
Given that Blizzard monitors local weather in places where they have data centers, to be aware of potential power supply and cooling issues before the alarms go off, I'm going to take a shot in the dark and guess their SANs use redundant controllers.
I'm not kidding. For a filesystem that's only going to hold a handful of very large data files, transported by sneakernet, there's not much benefit to journalling, directory structure optimizations, POSIX permissions, etc. You just want something that's marginally more structured than writing data directly to the raw block device, and FAT32 is the lowest common denominator.
In all seriousness, given that it's being presented at a TeX conference, I highly doubt it's something so fundamental as P vs. NP. Since we're all flailing wildly at possible answers, I'm going to put my money on an average-case polynomial solution to an NP-complete problem. These already exist, but the average case is very fragile and rarely survives reduction to another NP-complete problem. Perhaps he's found one for one of the more popular and useful NP-complete problems.
There's no mention in TFA of distinguishing electrical from magnetic fields, the latter of which grows much faster as distance decreases. One group had an EM emitter, and the other did not.
I've got another one: inverse cube law. If the problem is somehow related to magnetic fields, putting a cell phone in the hive will really be measuring that more than any non-dipole phenomenon.
...but my current ISP redirects all NXDOMAIN results to their ad page, and the only "opt-out" is a browser cookie that turns that page into an error page. At least Verizon offered an alternative DNS server with that misfeature disabled. I can't wait until my one-year contract is up.
Yes, I have an axe to grind. I worked in support for Red Hat back when RHEL 5 was released, before the switch to KVM. There were rumors going around engineering about switching to KVM as early as RHEL 5.1, because as unready as KVM was at the time, Xen was a disaster. We shed enough blood to get Xen usable until KVM had good paravirt I/O, so that got deferred for a few updats. Prior to leaving Red Hat Support, I'd get bug reports from customers, and track down patches in xen-unstable that were summarized with "Linux does this a different way, so we probably should too." That kind of insight-free crap doesn't fly on LKML, and it further goes to demonstrate the sort of wheel-reinvention, endemic in Xen, that belongs in a research labs and not enterprise products.
The first two comments you quoted were my own opinions, and yes, they're a bit jaded from my experience. The last comes from the customers I dealt with. Xen was popular among the customers in industries that were doing cost-cutting. For the financial services customers, who simply wanted to squeeze as many logical servers as possible into their data centers next door to the exchanges, money was no object, so they stuck with VMware, because it was cheaper to have consultants tweak the hell out of their setups than switch to a faster paravirtualization product that just wasn't absolutely rock solid.
I no longer work there, but last I heard those financial services customers were much more interested in KVM than they ever were in Xen. The trading systems still run on bare metal, with realtime kernels where possible, but for all their other systems they want to virtualize everything they can, and KVM's technical advantages over VMware are quite compelling. Xen enjoys the same higher CPU and memory counts, but the stability problems were a deal-breaker.
For one generation of CPUs, you're right, hardware virtualization was slower. Since then we've gotten hardware nested paging that eliminates the TLB penalty and virtio device drivers that give us paravirtualization in confined I/O devices without having to coordinate the entire memory space between guest and host.
KVM decided to be stable first, THEN fast, and it succeeded. Xen decided to be fast first, THEN stable. The results are a clear lesson in the ills of premature optimization.
I don't mean to belittle the significance of Xen's paravirtualization approach, but rather to point out that it's much more suitable for environments like the ones that tend to use Fedora than the ones that tend to use RHEL. Xen tried to be a commercial product way before it was technically ready for it, simply because there was so much market demand for commodity virtualization. Maybe it's ready now, but I wouldn't know, because I gave up on it as soon as KVM reached feature parity, because it didn't require understanding a totally separate technology and keeping up with a totally separate development community. If Xen really has come a long way since then, they've still got a lot of catching up to do, because KVM hasn't stood still.
In fairness to Citrix, I think the situation has improved somewhat since the acquisition, as evidenced by the fact that it's even possible for Fedora to be considering this move now. That said, I think it's a day late and a dollar short. Xensource alienated the Linux community prior to that acquisition and Citrix has done little to repair that damage. In my opinion as someone who was forced to support Xen for Red Hat prior to their acquisition of Qumranet, the Xen community has grown primarily because existing users have increased their use of virtualization, not because of significant new deployments of Xen.
I'm glad to hear that you have significant university participation in the community, because I absolutely mean what I said about Xen being in a good position for research, but unless there are some drastic changes soon, I suspect Xen will rapidly lose the enthusiasm of the industry partners it needs to remain a credible enterprise product as customers migrate to KVM and other virtualization technologies.
Fedora, not RHEL, is really where Xen belongs anyway. It's exactly the sort of mix of neat ideas, dirty hacks, and blatant wheel re-invention that could only have come from academia, and it was only ever made enterprise-grade by throwing heaps of money at it, and even then only for carefully tested configurations. Yes, it's pretty much single-handedly responsible for commoditizing virtualization, but the combination of the design and the lack of cooperation with the kernel community made it a nightmare to support. Xen is responsible for the existence of KVM because it showed such immense promise, and then delivered extreme frustration and pain.
Since Xen decided long ago it was going to be the center of its own universe, it's really in a great position to do cool experimental things that the kernel community would be more cautious about and the enterprise market wouldn't touch with a 10' pole without seeing a strong proof of concept first. That kind of innovation is a stated goal of the Fedora project.
The only technical advantage Xen enjoys right now is a lack of dependency on hardware virtualization features. Since it's impossible to buy a new machine that you can call a server with a straight face that lacks hardware virtualization, this is meaningless in the enterprise world, but Fedora (like other community distros) has a much broader scope, so there's still a real chance there for necessity to give birth to more invention, much like it did in the early days of Xen when x86 hardware virtualization was still a whisper in the halls at Intel and AMD.
Of course, Xensource/Citrix has already driven away most of the community that would have done this kind of pre-product development, so I'm not holding my breath, but it would be nice to see something more to come of all that work (and years of my own life) beyond simply supporting existing users.
I bought a spindle of 25 CD-RW discs back in 2005 for about the retail price of a 1 GB flash stick today. I still have at least 20 of them, and less than half of those have ever been written to. I have 3 USB sticks and one SD card that are big enough for a liveCD image, and I use them fairly regularly (certainly more than once every six months) for other things. I would objectively be an idiot to use a flash stick on a machine with a CD drive. CDs may be to this decade what floppies were to last decade, but they will remain useful for a rather long time because they're big enough for all but a handful of things we do with data, and everyone who ever invested a cent in the technology currently has more reusable media than they will ever be able to consume.
Even if I were burning onto non-reusable media, at 2 releases per year, I would run out of CD-Rs and DVD-Rs (each of which I bought exactly one spindle of) around the time I buy my first car powered by a Mr. Fusion.
Slashdot Mirror
I'm a happy Rackspace Cloud customer. I use it for a few small VMs that I treat like normal, uniquely-configured servers, but I don't have to mess with all the details of running a data center, and that makes my life easier. I looked at EC2, and it became very obvious that it was not intended to be used that way. If you want to do the whole dynamic cloud thing where your log scraper uses an API to request more CPU for this VM, more RAM for that VM, and duplicate a few more web front-end hosts, EC2 definitely covers the bases, but I just wanted a couple servers with redundant power and storage, pre-built backup/restore system, in a data center that's professionally managed by people who are not me, and I wanted to do it without spending tens or hundreds of thousands of dollars up front.
In terms of business growth, EC2-style cloud computing is great for large organizations with their own developers who can afford semi-custom solutions that offload 80% of their server infrastructure to Amazon's data centers, but that's a market that will saturate quickly. The larger opportunity is customers like me, who are trying to help a small organization grow into a large organization without investing huge amounts of time and money up front (because they don't have either to spare yet), and need servers that aren't just run from someone's desk. If Amazon invests the short term returns from EC2 into something that competes directly with Rackspace Cloud, I'm sure they'll be competitive, but right now the two offerings aren't directly comparable.
Anyone remember when Slashdot hit 16,777,215 comments, and overflowed MEDIUMINT? The ALTER TABLE statement that fixed it took hours to run. I shudder to think how long it'll take to fix this, even with the problem diagnosed.
...then how is knowing that the server you're looking for is (or more likely is not) somewhere within X meters going to help?
No superpower is useless for picking up chicks.
While the data within the encrypted volume should be indistinguishable from randomness, the metadata headers are quite distinguishable. It's pretty obvious if something is a LUKS volume, but within that you shouldn't be able to tell.
...is that most users of low-end CPUs won't notice the difference going from 2 threads to 4, or turning on extra cache. They'll just notice their Windows 7 system getting slow, as Windows systems are wont to do, and then pay $50 only to find out that it's still just as slow, because it did nothing for their memory-starved, I/O-bound, single-threaded workload.
Pi has the property that all binary strings of a given length occur with equal frequency, making it an excellent source of fair pseudorandom bits. There are plenty of applications in which 2 quadrillion pseudorandom bits is grossly insufficient.
It would get you nowhere near that. A substantial fraction of any mainframe architecture's instruction set is emulated in software. The actual MIPS ratings are way below the MHz ratings, whereas on most superscalar architectures, MIPS exceeds MHz.
Once you've paid that penalty as well as the qemu penalty, you're getting down to somewhere in the Doom/Quake I range, with no hardware acceleration.
While T-Mobile's towers may be capable of 21 Mbps HSPA+, the G2 itself can only do 14.4 Mbps, according to the fine print on T-Mobile's teaser site. Of course, you'll get nowhere near this in real life, but if you have a 7.2 Mbps HSPA device, and you're expecting it to be 3x as fast as whatever you get in real life on that, you'll be disappointed to only get 2x that, at best.
http://g2.t-mobile.com/
Given that the Z architecture doesn't even have PCI, that would be a no.
There's a first time for everything. When I was at Red Hat, a customer (maybe you?) experienced a SAN-wide outage due to an error, caused by a rare hardware failure mode, that the vendor's engineers told me in private they had never seen before. It was one of the more reputable SAN vendors, and they worked with us on a kernel patch to recover from that error more intelligently. There's now a patch in the Linux kernel to gracefully recover from an error that has only been seen once outside of a hardware lab.
I've also talked to plenty of engineers and support people who had simply never heard of a particular problem before, because their companies lacked sufficiently well-organized support and bug tracking systems, and couldn't hold on to their experienced employees long enough to have someone around who knew what was going on the next time the problem came up.
In the world of enterprise computing, the law of large numbers is working against you. Some vendors understand this, and treat each novel failure as an opportunity to harden the product further. You usually pay a premium for this, but it's worth it. Others just swap the bad board and update their resumes. It sounds like NG went with the lowest bidder.
Given that Blizzard monitors local weather in places where they have data centers, to be aware of potential power supply and cooling issues before the alarms go off, I'm going to take a shot in the dark and guess their SANs use redundant controllers.
http://www.crunchgear.com/2009/09/18/blizzard-reveals-some-technical-data-about-world-of-warcraft/
According to TV, NCIS can hack into your motherboard and reprogram the hard drive to act as a GPS receiver, in under two hours.
I'm not kidding. For a filesystem that's only going to hold a handful of very large data files, transported by sneakernet, there's not much benefit to journalling, directory structure optimizations, POSIX permissions, etc. You just want something that's marginally more structured than writing data directly to the raw block device, and FAT32 is the lowest common denominator.
I'm pretty sure I remember reading a previous /. article about IBM patenting that.
In all seriousness, given that it's being presented at a TeX conference, I highly doubt it's something so fundamental as P vs. NP. Since we're all flailing wildly at possible answers, I'm going to put my money on an average-case polynomial solution to an NP-complete problem. These already exist, but the average case is very fragile and rarely survives reduction to another NP-complete problem. Perhaps he's found one for one of the more popular and useful NP-complete problems.
Who's running the pool?
There's no mention in TFA of distinguishing electrical from magnetic fields, the latter of which grows much faster as distance decreases. One group had an EM emitter, and the other did not.
I've got another one: inverse cube law. If the problem is somehow related to magnetic fields, putting a cell phone in the hive will really be measuring that more than any non-dipole phenomenon.
...but my current ISP redirects all NXDOMAIN results to their ad page, and the only "opt-out" is a browser cookie that turns that page into an error page. At least Verizon offered an alternative DNS server with that misfeature disabled. I can't wait until my one-year contract is up.
Yes, I have an axe to grind. I worked in support for Red Hat back when RHEL 5 was released, before the switch to KVM. There were rumors going around engineering about switching to KVM as early as RHEL 5.1, because as unready as KVM was at the time, Xen was a disaster. We shed enough blood to get Xen usable until KVM had good paravirt I/O, so that got deferred for a few updats. Prior to leaving Red Hat Support, I'd get bug reports from customers, and track down patches in xen-unstable that were summarized with "Linux does this a different way, so we probably should too." That kind of insight-free crap doesn't fly on LKML, and it further goes to demonstrate the sort of wheel-reinvention, endemic in Xen, that belongs in a research labs and not enterprise products.
The first two comments you quoted were my own opinions, and yes, they're a bit jaded from my experience. The last comes from the customers I dealt with. Xen was popular among the customers in industries that were doing cost-cutting. For the financial services customers, who simply wanted to squeeze as many logical servers as possible into their data centers next door to the exchanges, money was no object, so they stuck with VMware, because it was cheaper to have consultants tweak the hell out of their setups than switch to a faster paravirtualization product that just wasn't absolutely rock solid.
I no longer work there, but last I heard those financial services customers were much more interested in KVM than they ever were in Xen. The trading systems still run on bare metal, with realtime kernels where possible, but for all their other systems they want to virtualize everything they can, and KVM's technical advantages over VMware are quite compelling. Xen enjoys the same higher CPU and memory counts, but the stability problems were a deal-breaker.
For one generation of CPUs, you're right, hardware virtualization was slower. Since then we've gotten hardware nested paging that eliminates the TLB penalty and virtio device drivers that give us paravirtualization in confined I/O devices without having to coordinate the entire memory space between guest and host.
KVM decided to be stable first, THEN fast, and it succeeded. Xen decided to be fast first, THEN stable. The results are a clear lesson in the ills of premature optimization.
I don't mean to belittle the significance of Xen's paravirtualization approach, but rather to point out that it's much more suitable for environments like the ones that tend to use Fedora than the ones that tend to use RHEL. Xen tried to be a commercial product way before it was technically ready for it, simply because there was so much market demand for commodity virtualization. Maybe it's ready now, but I wouldn't know, because I gave up on it as soon as KVM reached feature parity, because it didn't require understanding a totally separate technology and keeping up with a totally separate development community. If Xen really has come a long way since then, they've still got a lot of catching up to do, because KVM hasn't stood still.
In fairness to Citrix, I think the situation has improved somewhat since the acquisition, as evidenced by the fact that it's even possible for Fedora to be considering this move now. That said, I think it's a day late and a dollar short. Xensource alienated the Linux community prior to that acquisition and Citrix has done little to repair that damage. In my opinion as someone who was forced to support Xen for Red Hat prior to their acquisition of Qumranet, the Xen community has grown primarily because existing users have increased their use of virtualization, not because of significant new deployments of Xen.
I'm glad to hear that you have significant university participation in the community, because I absolutely mean what I said about Xen being in a good position for research, but unless there are some drastic changes soon, I suspect Xen will rapidly lose the enthusiasm of the industry partners it needs to remain a credible enterprise product as customers migrate to KVM and other virtualization technologies.
Fedora, not RHEL, is really where Xen belongs anyway. It's exactly the sort of mix of neat ideas, dirty hacks, and blatant wheel re-invention that could only have come from academia, and it was only ever made enterprise-grade by throwing heaps of money at it, and even then only for carefully tested configurations. Yes, it's pretty much single-handedly responsible for commoditizing virtualization, but the combination of the design and the lack of cooperation with the kernel community made it a nightmare to support. Xen is responsible for the existence of KVM because it showed such immense promise, and then delivered extreme frustration and pain.
Since Xen decided long ago it was going to be the center of its own universe, it's really in a great position to do cool experimental things that the kernel community would be more cautious about and the enterprise market wouldn't touch with a 10' pole without seeing a strong proof of concept first. That kind of innovation is a stated goal of the Fedora project.
The only technical advantage Xen enjoys right now is a lack of dependency on hardware virtualization features. Since it's impossible to buy a new machine that you can call a server with a straight face that lacks hardware virtualization, this is meaningless in the enterprise world, but Fedora (like other community distros) has a much broader scope, so there's still a real chance there for necessity to give birth to more invention, much like it did in the early days of Xen when x86 hardware virtualization was still a whisper in the halls at Intel and AMD.
Of course, Xensource/Citrix has already driven away most of the community that would have done this kind of pre-product development, so I'm not holding my breath, but it would be nice to see something more to come of all that work (and years of my own life) beyond simply supporting existing users.
I bought a spindle of 25 CD-RW discs back in 2005 for about the retail price of a 1 GB flash stick today. I still have at least 20 of them, and less than half of those have ever been written to. I have 3 USB sticks and one SD card that are big enough for a liveCD image, and I use them fairly regularly (certainly more than once every six months) for other things. I would objectively be an idiot to use a flash stick on a machine with a CD drive. CDs may be to this decade what floppies were to last decade, but they will remain useful for a rather long time because they're big enough for all but a handful of things we do with data, and everyone who ever invested a cent in the technology currently has more reusable media than they will ever be able to consume.
Even if I were burning onto non-reusable media, at 2 releases per year, I would run out of CD-Rs and DVD-Rs (each of which I bought exactly one spindle of) around the time I buy my first car powered by a Mr. Fusion.