... I've lost 20 pounds, my acne has cleared up, my wife moved back in and doesn't want a divorce anymore, my dog somehow got un-hit by a car and is alive again, my son stopped using drugs, my daughter isn't pregnant anymore, my truck magically fixed itself and runs again, my boss called and gave me my job back, my dialup connection allows me to surf up to 5x faster than before, I'm not dumb enough to click on emails from banks anymore, I'm suddenly brilliant enough to realize that I've never had an EBay account, and I'm suddenly brilliant enough to realize that Paypal doesn't NEED to verify what my password is.
Yep, this IPS is amazing. It is only rivaled by the greatness of the Virus Scanner that runs on my PocketPC, which detects every known PktPC virus ever created. I'm still trying to figure out how they do that with a signiture database that is 0 bytes in length, but...
The concept is simple - the messages are processed by someone with the authority to do something about them. Assistants have no such authority - they merely filter, and act as "middle management" - they only possess the authority to say "No", never "Yes". Like middle management, they are worthless in that regard.
Delegation is a key role as you suggest, especially as the sender-base scales up - but the key is that the delegates must be *full* delegates. Anything less can be replaced by a 2-line pearl script.
>> Thus the question over DRM remains: should we be policed by our own property?"
This question begs that the property would prevent us from violating law. In truth, none of the DRM solutions do that - they simply make it extremely difficult to NOT purchase redundant licenses, licenses that ARE NOT DEMANDED by the law.
That is not policing, and is merely a tool to produce a new revenue stream. In the immortal words of Steve Wright... "I bought some batteries, but they weren't included... so I had to buy them again." Or more approprate, the anecdote about Disney, regarding the rejection of one-time-view VCR tapes - "How will we know how many people are sitting in front of the TV?"
>> I saw various hardware failures get artificially introduced with not so much as a hiccup from the client workstations
Yeah, but you missed the good version. The E4000... you'd PCAW to the desktop of the "server", introduce hardware failures (such as ripping the RAM out of one of the CEs, or pulling the active NIC, or whatever) and see not so much as a hiccup from the desktop of that server, itself.:)
Too bad they hosed the performance with the FT version, though... the FT product was supposedly going to allow a 100km split between the tuples. Dunno if they got it working. Ugh.
Proponants of clustering neglect one thing - it mostly works, but requires a painful coding practice to prevent any loss of state when a failure happens. For the bulk of productions out there, this state cannot be transferred from box to box - find me a solution that'll real-time "cluster" a file-region lock, for example, of... who cares, a 5 meg autocad file. It's not likely to happen... users will get collisions, and the file will get chewed. Make it easy - cluster your favorite spreadsheet file, such that 50 people can edit it at once without clobbering each other. It's not going to happen - and hopefully you see my point about "state". Clustering is best used when the server-side is stateless... which is useless in most productions. File locking, for example, is a server-side state.
Years ago, a company named "Marathon Technologies" went after the fault-proof market, and succeeded quite well. They cut the problem into points of failure, and duplicated each of them.
The first POF was the context. They addressed this by having two machines handle the software state - literally, two PCs loaded with RAM, CPU, and a custom FPGA controller. No I/O, no keyboard, no mouse. The FPGA would keep the two contexts in near-lock-step with each other, effectively making a Raid-1 software state.
The second POF was the hardware. They addressed this by... you guessed it, two boxes, again with a raid-1 type of resource mirror. The boxes each needed the same config - right down to the mac address of the NICs you threw in them. Resources where then virtualized and redirected into the software context - whatever the context does to the hardware, it does it to both, simultaneously. (The only exception being the NICs - one would be "hot", the other a warm spare). If any combination of resources went away, it didn't matter - so long as you had one of *something*, *somewhere*, the software context would not notice. We took a lightning hit in 2000 - and one of everything died. No problem, though - it used the drive array from this box, the Nic from that box, the CDRom from this box, the keyboard from that box, the mouse from this box... and unless I'd known about the failure, I'd never have noticed unless I was standing at the physical racks.
"Failover" was instant, as there was no "failover". If something died, it din't matter - you were already using the other one. The only "failover" that would take place is if a NIC died - and the time for the "warm" nic to fire up was under 10ms.
It had extra bonus points because you could separate the components by almost half a mile... and required ZERO rewrites of any software to use it. If the s/w would run on WinNT, then it'd run on this.
Of particular fun was using the system to manage (trial) patches. Literally split the brain - isolate each half of the context & hardware from the other, so that each would think the other had died. You'd leave one half such that the users could continue to use it uninterrupted, while you try the patch on the disconnected one. Once done testing the patch, no big deal - just rejoin it, and it'll be brainwiped by the production one during the sync.
It was also useful for actual application of patches. Come time to apply, you'd freeze production, split the brain and shut one half of it off. Then commit your updates and gain confidence. If the updates succeed, just fire up the half that's off and it'll be overwritten with the updated version. If the updates fail - kill the failed half, and fire up the half you shut down. Rollback could be achieved in about 25 seconds.
Clustering cannot compare to this as far as availability is concerned... with zero downtime, zero loss of state, it's open and shut. It didn't scale well, sadly, and their newer versions don't thrill me - but the E4000 product was killer, hands down.
The story mentions that the woman was handicapped. What they didn't mention is that she was actually KILLED in a car crash two years ago, and only her mind survives... a ghost in the machine, distributed across the 'net. (insert scary music)
Kahrytan, it appears that you've never fought a car fire. It also appears that you dunno wtf you're talking about, at all, and that you do not know how to use google, at all. We have a word for you in the fire service. We call you "NIOSH Food" (aka dead from arrogance, hopefully you don't take out your crew along with you).
a) Magnesium is hard to ignite. So are tires. Still, they burn. Hydrogen is quite easy to ignite by comparison. b) Both magnesium and tires, as well as the upholstry inside the vehical and the plastics in the body, trunk and engine compartments are each more than hot enough to ignite hydrogen. So are electric sparks from downed powerlines and shorted battery cables. c) True, you won't find many cars with magnesium any more, and hopefully it'll stay that way. You will continue to find tires and upholstry, however, along with a more and more other plastics. d) Hindinberg pretty much calls into question every statement you've made regarding expansion rates and ignitability. e) "Little Heat" - 2400 calories per gram per degree to convert from steam to liquid or vice-versa. That is an ASSLOAD of heat. And that's just a secondary reaction that happens to the byproduct later on, not the primary one that'll drive the car. f) No heat means no pressure to drive a reciprocating engine. Bullshit. To force a piston down, you need pressure. Pressure is heat as far as that's concerned, clearly it is present. Period.
In the future, I'd suggest you do a little study of firematics and hazmat prior to making such statements. Here is a good starting point.
Very Good concept point, but your specific illustrations are somewhat silly. Any questions, move to Syracuse, Rochester, Buffalo, or Oswego.
a) It rains every damned day b) If it isn't raining, it's snowing c) If it isn't snowing, existing snow is drifting d) Most places don't bother to plow unless there's a *good* chance that the town supervisor's wife's SUV will get stuck. And then he'll only order the plowing if he thinks her cellphone battery is charged. e) The major roads and intersections are salted or sanded, making ice irrelevent. Minor roads are not, making the surface a brittle snow-pack ice in the first place.
Like I said, your point of not considering impacts is well taken - but your specific examples are "normal" existence around here. Nobody's ever noticed, nobody's ever cared, and quite frankly it's never mattered. At all. Your ideas make for some interesting irrigation techniques in the more arid regions, though...:)
SBB writes "Green Universe News is reporting that scientists claim to have proof that 'supernovae are the direct catastrophic result of Global Warming on Earth' and not the result of giant stars undergoing gravitational collapse and subsequent explosion after having spent all of their nuclear fuel as previously thought."
Ya know, that's a damned good point - "One Time Use" in this case means that you are only allowed to use it until it's empty. So, refill it before it gets that low:)
If I haven't stopped using it yet, then my first use isn't over...
This Stinley(tm) hammer is licensed for use only with authorized Stinley(tm) Nails. Utilization of this hammer with unauthorized nails, or utilization of this hammer with any used nail, or utilization of this hammer in a fashion that does not directly result in the consumption of at least one authorized Stinley(tm) nail per five strikes of this hammer is prohibited by law.
Stinley(tm) nails are available separately, and are licensed per-user per-hammer. Stinley(tm) nail licenses are non-transferrable between users, and are non-transferrable between hammers.
This license to use your new Stinley(tm) hammer may not be transferred, rented, borrowed, or sold.
First, remote storage requires bandwidth to get the dataset up there.
Second, remote storage requires bandwidth to get the dataset back. Most people seem to have overlooked this small aspect... you must expect that "incremental" is irrelevent. If you're dealing with a T1 on the upload, then you'll probably be dealing with a T1 on the download.
We use a combination of tapes and "cold spare" colocation; nightly tapes are the primary method, and they are kept offsite. The colocation is maintained by a kludgeware called "doubletake", which effectively echoes cluster writes between us and the colo.
Total dataset is about 60gigs - 40 gigs for SQL, and another 20 gig for GIS & map stuff. Over a 1.5, you can do the math and figure out how long the initial mirror takes. It's great once done, though, because DblTake will keep them current. If our building goes away, we just tunnel in, mount the fileset into SQL and Mapguide, etc, and we're back up with the (now hot) spare. And therein lies the flaw in "online backups".
If I lose a box, I can restore it from tape in about 2 hours. Or, I can restore it from the colocation in about... uh, a week + some days. It isn't viable in that respect; where I can (and do) prove our tape backups by (literally) wiping production servers and restoring them (takes two hours on a slow night), we cannot even *try* the colocation idea because of the timespan involved - a timespan where we are *completely* dependant on the internet. And you know how dependable *that* is.
You, however, wouldn't even have that as an option. You'd simply be storing remotely; if your local dataset goes away, it stays gone until you copy it back. That goes directly towards downtime; unless you either have a trivial dataset, or you have an OC3 (*very* cost effective to have one of those lying around when it's average utilization is 0.00004%), the solution loses appeal very quickly. You can probably cheat and go with a cablemodem (or even bond several together), but be aware that there are no SLAs in that arena, and most people will shy away from it.
So, there's the problem with "online backups", or in non-hype english, "remote storage". All is not lost, however - you have options.
First, you can get a burstable pipe. We run a T1 that can burst, which cuts the initial transfer down to only a couple days. The cost may be prohibitive for you, however.
Second, you don't need no stupid "provider" to host your dataset. The issue is *not* the initial upload to the remote site; the issue is getting it *back* when you need it. You can literally create some connectivity between your shop and someone's house (or even setup a quid-pro-quo with another business across town), throw a box in their basement, and you're set. Come the day when you need the entire fileset, you can tirenet the entire thing back to your shop in about 20 minutes.
All of this is assuming you actually *need* this failed-buzzword-concept-du-jour. I'm trying to figure out why some tape rotation strategy wouldn't work; at two bucks for a DDS4, combined with the fact that you can practically ghost the drives into them these days, combined with the reality that your "online backup provider" has a security model of swiss cheese and is a *major* source of non-accountable, non-auditable vulnerability... I don't quite understand the problem that an "online backup" is going to solve; I only see them being obscured, while a large quantity of new ones are introduced.
There's only one challenge with this - and you can bet your butt it'll happen -
Spammer gets tired of being DOSed. Spammer then sends ten billion spams on behalf of a legitimate site - a site that did not contract with him, would not contract with him, and has no idea who he is. The spammer does this for the sole purpose of suckering you into attacking them. Your reactions are now wrong.
And to make it more fun, spammer later notifies victim company that if they don't pay him one zillion dollars, he's going to keep suckering you into doing it to them. Talk about a reflection attack... and you are the reflector.
So, consider this in whatever solution you advocate. It's not impossible, but the above scenario would not be acceptable. Like I said, it's a challenge.
Slashdot Mirror
... I've lost 20 pounds, my acne has cleared up, my wife moved back in and doesn't want a divorce anymore, my dog somehow got un-hit by a car and is alive again, my son stopped using drugs, my daughter isn't pregnant anymore, my truck magically fixed itself and runs again, my boss called and gave me my job back, my dialup connection allows me to surf up to 5x faster than before, I'm not dumb enough to click on emails from banks anymore, I'm suddenly brilliant enough to realize that I've never had an EBay account, and I'm suddenly brilliant enough to realize that Paypal doesn't NEED to verify what my password is.
Yep, this IPS is amazing. It is only rivaled by the greatness of the Virus Scanner that runs on my PocketPC, which detects every known PktPC virus ever created. I'm still trying to figure out how they do that with a signiture database that is 0 bytes in length, but...
Eh, not exactly.
The concept is simple - the messages are processed by someone with the authority to do something about them. Assistants have no such authority - they merely filter, and act as "middle management" - they only possess the authority to say "No", never "Yes". Like middle management, they are worthless in that regard.
Delegation is a key role as you suggest, especially as the sender-base scales up - but the key is that the delegates must be *full* delegates. Anything less can be replaced by a 2-line pearl script.
>> Thus the question over DRM remains: should we be policed by our own property?"
This question begs that the property would prevent us from violating law. In truth, none of the DRM solutions do that - they simply make it extremely difficult to NOT purchase redundant licenses, licenses that ARE NOT DEMANDED by the law.
That is not policing, and is merely a tool to produce a new revenue stream. In the immortal words of Steve Wright... "I bought some batteries, but they weren't included... so I had to buy them again." Or more approprate, the anecdote about Disney, regarding the rejection of one-time-view VCR tapes - "How will we know how many people are sitting in front of the TV?"
Policing has nothing to do with it.
>> I saw various hardware failures get artificially introduced with not so much as a hiccup from the client workstations
:)
Yeah, but you missed the good version. The E4000... you'd PCAW to the desktop of the "server", introduce hardware failures (such as ripping the RAM out of one of the CEs, or pulling the active NIC, or whatever) and see not so much as a hiccup from the desktop of that server, itself.
Too bad they hosed the performance with the FT version, though... the FT product was supposedly going to allow a 100km split between the tuples. Dunno if they got it working. Ugh.
Proponants of clustering neglect one thing - it mostly works, but requires a painful coding practice to prevent any loss of state when a failure happens. For the bulk of productions out there, this state cannot be transferred from box to box - find me a solution that'll real-time "cluster" a file-region lock, for example, of... who cares, a 5 meg autocad file. It's not likely to happen... users will get collisions, and the file will get chewed. Make it easy - cluster your favorite spreadsheet file, such that 50 people can edit it at once without clobbering each other. It's not going to happen - and hopefully you see my point about "state". Clustering is best used when the server-side is stateless... which is useless in most productions. File locking, for example, is a server-side state.
Years ago, a company named "Marathon Technologies" went after the fault-proof market, and succeeded quite well. They cut the problem into points of failure, and duplicated each of them.
The first POF was the context. They addressed this by having two machines handle the software state - literally, two PCs loaded with RAM, CPU, and a custom FPGA controller. No I/O, no keyboard, no mouse. The FPGA would keep the two contexts in near-lock-step with each other, effectively making a Raid-1 software state.
The second POF was the hardware. They addressed this by... you guessed it, two boxes, again with a raid-1 type of resource mirror. The boxes each needed the same config - right down to the mac address of the NICs you threw in them. Resources where then virtualized and redirected into the software context - whatever the context does to the hardware, it does it to both, simultaneously. (The only exception being the NICs - one would be "hot", the other a warm spare). If any combination of resources went away, it didn't matter - so long as you had one of *something*, *somewhere*, the software context would not notice. We took a lightning hit in 2000 - and one of everything died. No problem, though - it used the drive array from this box, the Nic from that box, the CDRom from this box, the keyboard from that box, the mouse from this box... and unless I'd known about the failure, I'd never have noticed unless I was standing at the physical racks.
"Failover" was instant, as there was no "failover". If something died, it din't matter - you were already using the other one. The only "failover" that would take place is if a NIC died - and the time for the "warm" nic to fire up was under 10ms.
It had extra bonus points because you could separate the components by almost half a mile... and required ZERO rewrites of any software to use it. If the s/w would run on WinNT, then it'd run on this.
Of particular fun was using the system to manage (trial) patches. Literally split the brain - isolate each half of the context & hardware from the other, so that each would think the other had died. You'd leave one half such that the users could continue to use it uninterrupted, while you try the patch on the disconnected one. Once done testing the patch, no big deal - just rejoin it, and it'll be brainwiped by the production one during the sync.
It was also useful for actual application of patches. Come time to apply, you'd freeze production, split the brain and shut one half of it off. Then commit your updates and gain confidence. If the updates succeed, just fire up the half that's off and it'll be overwritten with the updated version. If the updates fail - kill the failed half, and fire up the half you shut down. Rollback could be achieved in about 25 seconds.
Clustering cannot compare to this as far as availability is concerned... with zero downtime, zero loss of state, it's open and shut. It didn't scale well, sadly, and their newer versions don't thrill me - but the E4000 product was killer, hands down.
The story mentions that the woman was handicapped. What they didn't mention is that she was actually KILLED in a car crash two years ago, and only her mind survives... a ghost in the machine, distributed across the 'net. (insert scary music)
...the embarrassingly long development cycle of Vista, including a 'revamping of the engineering and the processes.'
Translation: Gate's "Security is Job 1" pledge just got yanked.
They wanted to, but couldn't. I'd already squatted that name for use with my Worldwide Hamster Tracking System.
I've followed that debate, and it's moot in this case. Either way the hydrogen burned, and it burned quite well.
Kahrytan, it appears that you've never fought a car fire. It also appears that you dunno wtf you're talking about, at all, and that you do not know how to use google, at all. We have a word for you in the fire service. We call you "NIOSH Food" (aka dead from arrogance, hopefully you don't take out your crew along with you).
a) Magnesium is hard to ignite. So are tires. Still, they burn. Hydrogen is quite easy to ignite by comparison.
b) Both magnesium and tires, as well as the upholstry inside the vehical and the plastics in the body, trunk and engine compartments are each more than hot enough to ignite hydrogen. So are electric sparks from downed powerlines and shorted battery cables.
c) True, you won't find many cars with magnesium any more, and hopefully it'll stay that way. You will continue to find tires and upholstry, however, along with a more and more other plastics.
d) Hindinberg pretty much calls into question every statement you've made regarding expansion rates and ignitability.
e) "Little Heat" - 2400 calories per gram per degree to convert from steam to liquid or vice-versa. That is an ASSLOAD of heat. And that's just a secondary reaction that happens to the byproduct later on, not the primary one that'll drive the car.
f) No heat means no pressure to drive a reciprocating engine. Bullshit. To force a piston down, you need pressure. Pressure is heat as far as that's concerned, clearly it is present. Period.
In the future, I'd suggest you do a little study of firematics and hazmat prior to making such statements. Here is a good starting point.
Very Good concept point, but your specific illustrations are somewhat silly. Any questions, move to Syracuse, Rochester, Buffalo, or Oswego.
:)
a) It rains every damned day
b) If it isn't raining, it's snowing
c) If it isn't snowing, existing snow is drifting
d) Most places don't bother to plow unless there's a *good* chance that the town supervisor's wife's SUV will get stuck. And then he'll only order the plowing if he thinks her cellphone battery is charged.
e) The major roads and intersections are salted or sanded, making ice irrelevent. Minor roads are not, making the surface a brittle snow-pack ice in the first place.
Like I said, your point of not considering impacts is well taken - but your specific examples are "normal" existence around here. Nobody's ever noticed, nobody's ever cared, and quite frankly it's never mattered. At all. Your ideas make for some interesting irrigation techniques in the more arid regions, though...
SBB writes "Green Universe News is reporting that scientists claim to have proof that 'supernovae are the direct catastrophic result of Global Warming on Earth' and not the result of giant stars undergoing gravitational collapse and subsequent explosion after having spent all of their nuclear fuel as previously thought."
Ya know, that's a damned good point - "One Time Use" in this case means that you are only allowed to use it until it's empty. So, refill it before it gets that low :)
If I haven't stopped using it yet, then my first use isn't over...
More like,
Thank you for buying a new Stinley(tm) Hammer!
This Stinley(tm) hammer is licensed for use only with authorized Stinley(tm) Nails. Utilization of this hammer with unauthorized nails, or utilization of this hammer with any used nail, or utilization of this hammer in a fashion that does not directly result in the consumption of at least one authorized Stinley(tm) nail per five strikes of this hammer is prohibited by law.
Stinley(tm) nails are available separately, and are licensed per-user per-hammer. Stinley(tm) nail licenses are non-transferrable between users, and are non-transferrable between hammers.
This license to use your new Stinley(tm) hammer may not be transferred, rented, borrowed, or sold.
Mac Users.
Well, the first sign is that her partner doesn't read /.
First, remote storage requires bandwidth to get the dataset up there.
Second, remote storage requires bandwidth to get the dataset back. Most people seem to have overlooked this small aspect... you must expect that "incremental" is irrelevent. If you're dealing with a T1 on the upload, then you'll probably be dealing with a T1 on the download.
We use a combination of tapes and "cold spare" colocation; nightly tapes are the primary method, and they are kept offsite. The colocation is maintained by a kludgeware called "doubletake", which effectively echoes cluster writes between us and the colo.
Total dataset is about 60gigs - 40 gigs for SQL, and another 20 gig for GIS & map stuff. Over a 1.5, you can do the math and figure out how long the initial mirror takes. It's great once done, though, because DblTake will keep them current. If our building goes away, we just tunnel in, mount the fileset into SQL and Mapguide, etc, and we're back up with the (now hot) spare. And therein lies the flaw in "online backups".
If I lose a box, I can restore it from tape in about 2 hours. Or, I can restore it from the colocation in about... uh, a week + some days. It isn't viable in that respect; where I can (and do) prove our tape backups by (literally) wiping production servers and restoring them (takes two hours on a slow night), we cannot even *try* the colocation idea because of the timespan involved - a timespan where we are *completely* dependant on the internet. And you know how dependable *that* is.
You, however, wouldn't even have that as an option. You'd simply be storing remotely; if your local dataset goes away, it stays gone until you copy it back. That goes directly towards downtime; unless you either have a trivial dataset, or you have an OC3 (*very* cost effective to have one of those lying around when it's average utilization is 0.00004%), the solution loses appeal very quickly. You can probably cheat and go with a cablemodem (or even bond several together), but be aware that there are no SLAs in that arena, and most people will shy away from it.
So, there's the problem with "online backups", or in non-hype english, "remote storage". All is not lost, however - you have options.
First, you can get a burstable pipe. We run a T1 that can burst, which cuts the initial transfer down to only a couple days. The cost may be prohibitive for you, however.
Second, you don't need no stupid "provider" to host your dataset. The issue is *not* the initial upload to the remote site; the issue is getting it *back* when you need it. You can literally create some connectivity between your shop and someone's house (or even setup a quid-pro-quo with another business across town), throw a box in their basement, and you're set. Come the day when you need the entire fileset, you can tirenet the entire thing back to your shop in about 20 minutes.
All of this is assuming you actually *need* this failed-buzzword-concept-du-jour. I'm trying to figure out why some tape rotation strategy wouldn't work; at two bucks for a DDS4, combined with the fact that you can practically ghost the drives into them these days, combined with the reality that your "online backup provider" has a security model of swiss cheese and is a *major* source of non-accountable, non-auditable vulnerability... I don't quite understand the problem that an "online backup" is going to solve; I only see them being obscured, while a large quantity of new ones are introduced.
There's only one challenge with this - and you can bet your butt it'll happen -
Spammer gets tired of being DOSed. Spammer then sends ten billion spams on behalf of a legitimate site - a site that did not contract with him, would not contract with him, and has no idea who he is. The spammer does this for the sole purpose of suckering you into attacking them. Your reactions are now wrong.
And to make it more fun, spammer later notifies victim company that if they don't pay him one zillion dollars, he's going to keep suckering you into doing it to them. Talk about a reflection attack... and you are the reflector.
So, consider this in whatever solution you advocate. It's not impossible, but the above scenario would not be acceptable. Like I said, it's a challenge.
My friend is one of the NASA team on that mission. His horoscope the other day?
"Today, you will help smash a small probe into a comet."
If this russian chick's horoscope was accurate, it would have accounted for this...
Heh.
Eh, big deal. I calculated 1/3 to over 280,000 digits (*still* no end in sight!) and can recite them all... but after that, it gets too confusing.
14) Xenu!
Worse... it's a new species of NWO BLACK Helicopter. If we allow these things to reach maturity... it'll be very, very, ugly.
Whenever people argue for these snakeoil fixes, I usually drop a simple statement -
"Hell Hath No Fury like a Determined Idiot. I'm living proof."
While it might not convince them to approach the problem correctly, without fail it gives them pause...
Well DUH,
If ANY foreigner tries to attack a computer in the US, they know Dubya will freakin INVADE!
I said it back when mice became viable in the 80s, and I'll say it again:
Real men don't use Macs. Mice for for pussies.
(I'll be over here, hiding under this table if anyone needs me.)