Well, what you desribed would allow me to instantaneously communicate over very long distances without the pesky latency induced by the speed of light limitation, which is back to the point a few posts up. The other guy said you can't "change" the state of particle A to 'bar', you can only observe that it is bar, and then observe that B is also 'bar', and therefore can't use it for insta-communication.
Just like the last article slashdot linked from this source. For one, it's a straw-man argument. He gets to set up the 10 greivances that he'll knock down. How about he ask Paul for a list of 10 greivances to knock down? Secondly, the greivances he picks and his arguments against them clearly show that he's incapable of thinking in the way that people who despise java think, which makes him a poor arbiter of such things. Would a great hacker really say "Java sucks because it doesn't have a cool IDE like MS Visual Studio?"
Sounds like the whole thing is a lot of BS to me then. So like... if you replace "quantum entanglement" with "randomly-colored can of spraypaint", and "photon" with "tennis ball"... wouldn't you get the same effect? Blast two tennis balls with a single random color of spraypaint, shoot them in two direction, and when you observe one of them being puke-green [drum roll].. the other one is instantly determined to be puke-green!
Ok, I found the book, it was a Waite Group Press book called "Ray Tracing Creations", copyright is 1993, and it did include povray on CD. I also just hit povray.org to see if they said something about the date they're claiming is the 10th anniversary - it's the povray.org *website*'s 10th anniversary, not the 10th anniversary of povray itself. Fix the damn article:)
I remember buying a povray book at the bookstore, which came with a version of povray on CD, when I was in high school, and I graduated in '94. I suppose it's remotely possible I'm not remembering clearly, or that I got the book just before I graduated and what was on the CD was the first release or something.... Still, I would have guessed at least 12 years, if not much longer. I seem to remember povray having origins in compuserve back before I was using it (I had no compuserve at the time, just FidoNet).
I'm under the impression (and IANAP), that you can somehow entangle two photons and then send them down seperate paths at light speed away from each other (say to two endpoints millions of km apart), at which point you can instantaneously transmit information from one photon to the other, by messing with the state of one and seeing a related change in the other. My understanding of this was you could have an entangled-photon generator at the centerpoint of a fiber link between two cities halfway around the world and by sending a constant stream of entangled photons in both directions, you could have instantaneous, zero-lag communication between the endpoints.
I know this isn't what's being done here, but does anyone know about what I'm (probably incorrectly) talking about, and where I can find some source on that, or what it's called?
The big problem with this is the physical medium, the fiber. Right now, I can do a reasonably secure openssl session with any of god knows how many millions of hosts on the internet. You can't replace my current cryptography technology with your quantum otp system unless you give me direct fiber links from my PC to all of those millions of others. And another set of millions of fibers to my cellphone and laptop too while you're at it. I'm sure certain government organizations, banks, and large corps will use quantum otp styled solutions for certain important point-to-point links, bu tit's just not practical for general deployment.
The user way is apparently the way of the future, which sucks for a lot of us. Gone are the days of the vanilla stable kernel branch actually being stable.:(
Yes, nonvolatile ram technologies in general have limited write cycles, and this applies to the various forms of nvram used by the various solid-state disk manufacturers (who as the grandparent post pointed out, have been around for ages, this is not news). Most of the modern nvram hdds solve this in the controller logic by evening the write load over the whole drive. The idea is that on a typical hard drive, a relatively small percentage of the sectors get overwritten a lot, while most of them are written very infrequently (well, infrequently enough that the nvram write cycle lifetime is nowhere near an issue). This creates write-cycle-lifetime hotspots. So the controller logic relocates the logical blocks all over the physical drive as they are written in order to evenly spread the write-cycle load over the entire drive.
It's a bad analogy. An equally bad version of the analogy that's closer to explaining the realities of software piracy would be:
If your house doesn't have a front door, it's easier for you and your family to walk in and out every day, which you spend a lot of time doing. If you put a door in place, it makes things a pain in the ass. If any criminal decided to steal things from your house, they're either gonna walk in through the big front door hole, or if you installed a rather inconvenient door they'll just kick it open on their way in.
As long as people like you keep thinking that way, we aren't going to make any progress. You write code for computers, not for people. It's kinda inherent in the definition. If you're working on a team and most programms can't understand the code you write, then either you suck, or they all suck. However, I didn't say "can't understand the code you write", I said "will look like unmaintainable trash", which is markedly different. I can understand the output of another good programmer, but if I were asked to take over his code and maintain it, 9/10 times I would refactor and re-write large parts of it to suit me, because his code looks like unmaintainable trash to my brain. Same would be true if our roles were reversed.
This isn't that big of an issue. Gentoo can set their md5 to be from a version of the file with bytes 0x10-0x23 set to 0x00, and instruct users to blank those bytes out after downloading. They could even supply the user with a commandline to run to do so using split, join, and echo.
I think we're on the same page here, I just suck at communication myself. When I say 'well-documented interface delineations', I'm not referring to heavily structured object models and crap like that. To give an example (a small one, but the concept scales), suppose the application in question is a web-based app with a persistent datastore in an rdbms.
The developers might gather around and discuss things and decide that Perl will be the only language they need to use, Then, they split the tasks such that one guy writes the database schema and a library of perl functions and/or objects for interfacing with the database, a second guy will be responsible for the actual application logic code which forms the heart of the CGIs, and a third guy is responsible for the HTML output code that's being templated into the CGIs, along with the requisite embedded javascript and what-have-you. The developers obviously have to co-ordinate and communicate, but they do so at an interface level. They don't neccesarily have to understand or be able to maintain each others' code all that well, they just have to communicate the interfaces they are presenting to each other. You can imagine conversations like:
CGI Guy: I'm not really happy with the interface you're currently putting on db_object_x, it doesn't fit well with my coding model
DB Guy: Ok, I'll re-work that to work better for your purposes.
HTML/JS Guy: CGI Guy, I need you to give me $value_x in a template variable on page_3....
(Well, that sounded really contrived and fake, but you get the idea:)
Where we differ is really in whether code should be maintainable by others very easily at all. In my (obivously minority) opinion, code should stick with who wrote it. Trying to pass off code from one guy to the next is a mistake. Of course, this implies radically different hiring practices than the way most of the industry operates.
Also, when I called my very good programmers' code 'unmaintainable trash' I merely meant that in the sense that it would be unlikely fo ra nother programmer to come along and be able to 'maintain' it (chances are if you do that, the new programmer just ends up gutting and refactoring the whole thing to fit his brain) - I did not mean that what I call a good programmer would introduce 'unneccesary complications' either - but invariably hard programming tasks do involve neccesary complications, and the solutions to these complications vary wildly between brains.
Almost invariably, unless the really good programmer puts an uncommonly high amount of effort into such things, the output of a single really good programmer will look like unmaintainable trash to most other programmers, especially mediocre ones, which are the norm in the industry.
This isn't because he writes bad code, it's because he naturally programs in a way that suits his brain, no tin a way that suits other peoples' brains. When code is written by a team collectively, they have three essential options:
1) They can make very hard, well-documented interface delineations between single-programmer-sized peices of the project and essentially have a bunch of subprojects run by individuals that again look like unmaintainable trash, and nobody can work on each others' code.
2) They can communicate effectively and code to a common standard of thinking and style. Essentially you're finding common ground between all the brains involved. This tends to need to be a lowest common denominator, and the code doesn't come out nearly as fast and isn't nearly as clever, but at least it is maintainable.
3) They can utterly fail to produce a quality product (I think this is the option usually chosen by default).
Personally, I vote for option 1, although option 2 is clearly what the industry shoots for, which usually ends up option 3 because option 2 is pretty hard to do right.
The problem is that jpegs can't be grepped like text. People don't just want to scan a stack of images, they want the data to have meaning. In some cases they even want to parse typed hospital forms into an xml format for example.
There's a balance somewhere inbetween these two statements. It will always be illegal to unleash a virus, just as it will always be illegal to murder. However, just as civil suits can and do win against negligent manufacturers of equipment for failing to include adequate and reasonable safety measures, so should civil class-action suits win against makers of software who haven't done their due diligence on the security side of things. I'm not a fan of punitive damages against the manufacturer, but I think cost-of-purchase would be in order, covering the product bought (or the whole cost of any bundle containing the product). IOW, consumers should be able to sue Eudora for the cost of their mail client if they get penetrated and virused through it, and should be able to sue M$ for the entire cost of Windows since Outlook Express was a bundled component. (And again, not just because there was a bug - those are inevitable - but as a class action suit alleging that they were completely negligent in the area of security as evidence by the pattern of recurrent successful attacks on their software).
I know it doesn't have the coolness factor of WiFi, and it doesn't help you contribute to the criminal deliquency of your neighbors' little wannabe hacker kids, but you could try regular old CAT5, just tack it down along the edges of the walls somewhere and cover it up with some moulding.
Correct. Once you initiate migration, it basically takes a snapshot of the state of the virtual system (memory copy, basically) and pushes it to the new host. While copying they keep a bitmap on the old host of what's been changed while they were busy copying (much like snapshotting a filesystem). When the copy is complete, they go back and copy over again just the stuff that changed while they were copying the first time. When that's done, repeat, repeat, until the changeset gets so small that it repeats the cycle in some small amount of time under a second. At that point it freezes the image on the old host, transfers the final small set of state changes, and fires up on the new host.
And yes, shared disk of some sort is a requirement too.
Some of the large old systems cost huge $$$ just in run and maintain costs on a monthly basis though, which can provide sufficient impetus for finding a better solution when you show management how much it's costing you per year to stay on that hardware versus cheaper run and maintain costs elsewhere.
Yeah they have that already for x86 on x86, VMWare's high-end enterprise product allows you to run VMWare on several machines and transparently move system images between physical hosts without taking any (perceivable) downtime. So hardware maintenance can be done without interrupting your "servers". Of course if the hardware crashes, any system images running on that particular hardware go down hard, but they can fail over to another peice of hardware and come up and fsck (or the equivalent in your OS of choice) themselves and go online immediately on one of the remaining hardwares.
Gigabit ethernet is fast, and it's very easy for your processor, your tcp stack, your driver, your card, your pci bus, etc... to bottleneck at less than gigabit speeds. It's pretty hard to tell you which without seeing the whole setup and analyzing it in place. It's also possible for the tcp protocol itself to bottleneck at a lower-than-gigabit speed if you don't tune various parameters to help it out. You can tell if it's a tcp bottleneck by trying multiple parallel transfers between the same pair of machines and checking to see if the aggregate bandwidth is significantly higher than a single transfer. If this turns out to be the case, you can look at various network tunable like buffer sizes and window sizes. Another related tunable is the MTU of your ethernet network. If ALL your cards (and your switches if you had any) support it, you can turn on Jumbo Frames and push 9000 bytes per ethernet frame instead of 1500, which can make a big difference in transfer speeds over a gigabit network.
Technically, any software sold in sufficient volume has a $0 cost, and is all profit, as you're amortizing the development cost over so many copies that it drops to under a penny. And microsoft definitely sells in those kidns of volumes. $375/license is $375 profit. The only issue that cuts into this is Tech Support, which might have been included in the deal, and has real recurring human wage costs.
Slashdot Mirror
Well, what you desribed would allow me to instantaneously communicate over very long distances without the pesky latency induced by the speed of light limitation, which is back to the point a few posts up. The other guy said you can't "change" the state of particle A to 'bar', you can only observe that it is bar, and then observe that B is also 'bar', and therefore can't use it for insta-communication.
Which of the two is correct?
Just like the last article slashdot linked from this source. For one, it's a straw-man argument. He gets to set up the 10 greivances that he'll knock down. How about he ask Paul for a list of 10 greivances to knock down? Secondly, the greivances he picks and his arguments against them clearly show that he's incapable of thinking in the way that people who despise java think, which makes him a poor arbiter of such things. Would a great hacker really say "Java sucks because it doesn't have a cool IDE like MS Visual Studio?"
Sounds like the whole thing is a lot of BS to me then. So like... if you replace "quantum entanglement" with "randomly-colored can of spraypaint", and "photon" with "tennis ball"... wouldn't you get the same effect? Blast two tennis balls with a single random color of spraypaint, shoot them in two direction, and when you observe one of them being puke-green [drum roll].. the other one is instantly determined to be puke-green!
Where's the magic?
Ok, I found the book, it was a Waite Group Press book called "Ray Tracing Creations", copyright is 1993, and it did include povray on CD. I also just hit povray.org to see if they said something about the date they're claiming is the 10th anniversary - it's the povray.org *website*'s 10th anniversary, not the 10th anniversary of povray itself. Fix the damn article
I remember buying a povray book at the bookstore, which came with a version of povray on CD, when I was in high school, and I graduated in '94. I suppose it's remotely possible I'm not remembering clearly, or that I got the book just before I graduated and what was on the CD was the first release or something.... Still, I would have guessed at least 12 years, if not much longer. I seem to remember povray having origins in compuserve back before I was using it (I had no compuserve at the time, just FidoNet).
I'm under the impression (and IANAP), that you can somehow entangle two photons and then send them down seperate paths at light speed away from each other (say to two endpoints millions of km apart), at which point you can instantaneously transmit information from one photon to the other, by messing with the state of one and seeing a related change in the other. My understanding of this was you could have an entangled-photon generator at the centerpoint of a fiber link between two cities halfway around the world and by sending a constant stream of entangled photons in both directions, you could have instantaneous, zero-lag communication between the endpoints.
I know this isn't what's being done here, but does anyone know about what I'm (probably incorrectly) talking about, and where I can find some source on that, or what it's called?
The big problem with this is the physical medium, the fiber. Right now, I can do a reasonably secure openssl session with any of god knows how many millions of hosts on the internet. You can't replace my current cryptography technology with your quantum otp system unless you give me direct fiber links from my PC to all of those millions of others. And another set of millions of fibers to my cellphone and laptop too while you're at it. I'm sure certain government organizations, banks, and large corps will use quantum otp styled solutions for certain important point-to-point links, bu tit's just not practical for general deployment.
The user way is apparently the way of the future, which sucks for a lot of us. Gone are the days of the vanilla stable kernel branch actually being stable.
Yes, nonvolatile ram technologies in general have limited write cycles, and this applies to the various forms of nvram used by the various solid-state disk manufacturers (who as the grandparent post pointed out, have been around for ages, this is not news). Most of the modern nvram hdds solve this in the controller logic by evening the write load over the whole drive. The idea is that on a typical hard drive, a relatively small percentage of the sectors get overwritten a lot, while most of them are written very infrequently (well, infrequently enough that the nvram write cycle lifetime is nowhere near an issue). This creates write-cycle-lifetime hotspots. So the controller logic relocates the logical blocks all over the physical drive as they are written in order to evenly spread the write-cycle load over the entire drive.
It's a bad analogy. An equally bad version of the analogy that's closer to explaining the realities of software piracy would be:
If your house doesn't have a front door, it's easier for you and your family to walk in and out every day, which you spend a lot of time doing. If you put a door in place, it makes things a pain in the ass. If any criminal decided to steal things from your house, they're either gonna walk in through the big front door hole, or if you installed a rather inconvenient door they'll just kick it open on their way in.
As long as people like you keep thinking that way, we aren't going to make any progress. You write code for computers, not for people. It's kinda inherent in the definition. If you're working on a team and most programms can't understand the code you write, then either you suck, or they all suck. However, I didn't say "can't understand the code you write", I said "will look like unmaintainable trash", which is markedly different. I can understand the output of another good programmer, but if I were asked to take over his code and maintain it, 9/10 times I would refactor and re-write large parts of it to suit me, because his code looks like unmaintainable trash to my brain. Same would be true if our roles were reversed.
This isn't that big of an issue. Gentoo can set their md5 to be from a version of the file with bytes 0x10-0x23 set to 0x00, and instruct users to blank those bytes out after downloading. They could even supply the user with a commandline to run to do so using split, join, and echo.
I think we're on the same page here, I just suck at communication myself. When I say 'well-documented interface delineations', I'm not referring to heavily structured object models and crap like that. To give an example (a small one, but the concept scales), suppose the application in question is a web-based app with a persistent datastore in an rdbms.
The developers might gather around and discuss things and decide that Perl will be the only language they need to use, Then, they split the tasks such that one guy writes the database schema and a library of perl functions and/or objects for interfacing with the database, a second guy will be responsible for the actual application logic code which forms the heart of the CGIs, and a third guy is responsible for the HTML output code that's being templated into the CGIs, along with the requisite embedded javascript and what-have-you. The developers obviously have to co-ordinate and communicate, but they do so at an interface level. They don't neccesarily have to understand or be able to maintain each others' code all that well, they just have to communicate the interfaces they are presenting to each other. You can imagine conversations like:
CGI Guy: I'm not really happy with the interface you're currently putting on db_object_x, it doesn't fit well with my coding model
DB Guy: Ok, I'll re-work that to work better for your purposes.
HTML/JS Guy: CGI Guy, I need you to give me $value_x in a template variable on page_3.
(Well, that sounded really contrived and fake, but you get the idea
Where we differ is really in whether code should be maintainable by others very easily at all. In my (obivously minority) opinion, code should stick with who wrote it. Trying to pass off code from one guy to the next is a mistake. Of course, this implies radically different hiring practices than the way most of the industry operates.
Also, when I called my very good programmers' code 'unmaintainable trash' I merely meant that in the sense that it would be unlikely fo ra nother programmer to come along and be able to 'maintain' it (chances are if you do that, the new programmer just ends up gutting and refactoring the whole thing to fit his brain) - I did not mean that what I call a good programmer would introduce 'unneccesary complications' either - but invariably hard programming tasks do involve neccesary complications, and the solutions to these complications vary wildly between brains.
Almost invariably, unless the really good programmer puts an uncommonly high amount of effort into such things, the output of a single really good programmer will look like unmaintainable trash to most other programmers, especially mediocre ones, which are the norm in the industry.
This isn't because he writes bad code, it's because he naturally programs in a way that suits his brain, no tin a way that suits other peoples' brains. When code is written by a team collectively, they have three essential options:
1) They can make very hard, well-documented interface delineations between single-programmer-sized peices of the project and essentially have a bunch of subprojects run by individuals that again look like unmaintainable trash, and nobody can work on each others' code.
2) They can communicate effectively and code to a common standard of thinking and style. Essentially you're finding common ground between all the brains involved. This tends to need to be a lowest common denominator, and the code doesn't come out nearly as fast and isn't nearly as clever, but at least it is maintainable.
3) They can utterly fail to produce a quality product (I think this is the option usually chosen by default).
Personally, I vote for option 1, although option 2 is clearly what the industry shoots for, which usually ends up option 3 because option 2 is pretty hard to do right.
Stop trying to pick up the 0.3 unpaid chicks at quakecon and get back to work you lazy bums.
The problem is that jpegs can't be grepped like text. People don't just want to scan a stack of images, they want the data to have meaning. In some cases they even want to parse typed hospital forms into an xml format for example.
There's a balance somewhere inbetween these two statements. It will always be illegal to unleash a virus, just as it will always be illegal to murder. However, just as civil suits can and do win against negligent manufacturers of equipment for failing to include adequate and reasonable safety measures, so should civil class-action suits win against makers of software who haven't done their due diligence on the security side of things. I'm not a fan of punitive damages against the manufacturer, but I think cost-of-purchase would be in order, covering the product bought (or the whole cost of any bundle containing the product). IOW, consumers should be able to sue Eudora for the cost of their mail client if they get penetrated and virused through it, and should be able to sue M$ for the entire cost of Windows since Outlook Express was a bundled component. (And again, not just because there was a bug - those are inevitable - but as a class action suit alleging that they were completely negligent in the area of security as evidence by the pattern of recurrent successful attacks on their software).
I know it doesn't have the coolness factor of WiFi, and it doesn't help you contribute to the criminal deliquency of your neighbors' little wannabe hacker kids, but you could try regular old CAT5, just tack it down along the edges of the walls somewhere and cover it up with some moulding.
Correct. Once you initiate migration, it basically takes a snapshot of the state of the virtual system (memory copy, basically) and pushes it to the new host. While copying they keep a bitmap on the old host of what's been changed while they were busy copying (much like snapshotting a filesystem). When the copy is complete, they go back and copy over again just the stuff that changed while they were copying the first time. When that's done, repeat, repeat, until the changeset gets so small that it repeats the cycle in some small amount of time under a second. At that point it freezes the image on the old host, transfers the final small set of state changes, and fires up on the new host.
And yes, shared disk of some sort is a requirement too.
Some of the large old systems cost huge $$$ just in run and maintain costs on a monthly basis though, which can provide sufficient impetus for finding a better solution when you show management how much it's costing you per year to stay on that hardware versus cheaper run and maintain costs elsewhere.
Yeah they have that already for x86 on x86, VMWare's high-end enterprise product allows you to run VMWare on several machines and transparently move system images between physical hosts without taking any (perceivable) downtime. So hardware maintenance can be done without interrupting your "servers". Of course if the hardware crashes, any system images running on that particular hardware go down hard, but they can fail over to another peice of hardware and come up and fsck (or the equivalent in your OS of choice) themselves and go online immediately on one of the remaining hardwares.
Not on windows it isn't :)
Gigabit ethernet is fast, and it's very easy for your processor, your tcp stack, your driver, your card, your pci bus, etc... to bottleneck at less than gigabit speeds. It's pretty hard to tell you which without seeing the whole setup and analyzing it in place. It's also possible for the tcp protocol itself to bottleneck at a lower-than-gigabit speed if you don't tune various parameters to help it out. You can tell if it's a tcp bottleneck by trying multiple parallel transfers between the same pair of machines and checking to see if the aggregate bandwidth is significantly higher than a single transfer. If this turns out to be the case, you can look at various network tunable like buffer sizes and window sizes. Another related tunable is the MTU of your ethernet network. If ALL your cards (and your switches if you had any) support it, you can turn on Jumbo Frames and push 9000 bytes per ethernet frame instead of 1500, which can make a big difference in transfer speeds over a gigabit network.
Technically, any software sold in sufficient volume has a $0 cost, and is all profit, as you're amortizing the development cost over so many copies that it drops to under a penny. And microsoft definitely sells in those kidns of volumes. $375/license is $375 profit. The only issue that cuts into this is Tech Support, which might have been included in the deal, and has real recurring human wage costs.