Nonsense. You can find oil almost anywhere. It's a byproduct of biomass. You probably have at least a litre of it in your kitchen in one form or another. So the argument that "peak" is a term to be reserved for non-renewable resources means that it should not be applied to oil either.
In fact, the notion of peak production has to do with sustainability: that is, the relative rates of production and consumption. Resource exhaustion is another topic entirely.
There was no option for the natives of Easter Island to plant new forests, once the last tree had been felled. There was no potential renewability for them. They couldn't even build seaworthy craft to go in search of seedlings. In a word, they were FUCKED. And they did it to themselves.
So every historical and archaeological record that bears on how we handle the extremes of resource management is instructive, insofar as it tells us about our patterns of past successes and mistakes.
We live with a finite set of resources at the bottom of a massive gravity well isolated by millions of miles of hard vacuum from anything else at all. We are consuming many of those resources at an unsustainable rate. If we don't want to end up like the people of Easter Island, we'd better not take any of it for granted.
Roland Wright speaks eloquently of another tragedy of the commons involving timber. This one took place on Easter Island, and it is a stark reminder to us all of what may come from presuming that our resources are infinite or necessarily renewable.
Easter Island is barren now. It was once heavily forested. But, as Wright recounts, "The people who felled the last tree could see it was the last, could know with complete certainty that there would never be another. And they felled it anyway."
So what you save in cooling you spend on dedicated long-haul fiber?
Well, actually, I'm not telling you what will work for you. I'm telling you about what other people have done because it worked for them.
And even if you switch to a major POP, you still have dozens of miliseconds of latency at best.
Let's see, the switches we were using had about 10us latency, of which about 1us was optical transceiver latency. That was typical a few years ago, but has since improved by an order of magnitude. I don't know where you get your "dozens of milliseconds" estimate. That certainly has not been our experience.
You still can't support low latency operations like trading or synchronous data replication, making you customer pool thar much smaller.
Gee, that would be too bad. But since your arguments so far are unsound, I suppose we shouldn't rush to that conclusion.
Also, though I don't usually recommend this to people, your writing will be more credible if you turn on your spelling checker.
We have to choose between the glass being half full or half empty. But it's not the symmetrical choice which it might seem to be. Specifically,
it's not a matter of providing cold air. That's just a means to an end. Fundamentally, it's a matter of removing thermal pollution.
The ideal environment for the equipment is one which is uniformly, ambiently cold. Not only are there fewer thermal stresses, the entire design problem is simplified if you can assume uniformity. Departures from this ideal are therefore to be minimized. You don't want to contain the cold, you want it to prevail. Instead you want to contain the heat, remove it, and minimize points of contamination along the way. This has the additional benefit that you're minimizing leakage from the relatively small heat regions rather than trying to protect the entire environment.
An analogous situation arises in a marine engine room. You want to supply clean air and also exhaust the combustion gases. Supposing you only had the following two choices, should you (a) exhaust directly into the engine room and pipe fresh air from outside to the engine, or (b) pipe the exhaust outside and let air be drawn directly into the engine?
Generally (b) is regarded as better, because exhaust gas is hot, toxic, and corrosive. It's much more trouble to design every surface in the environment to tolerate it that it would be just to contain and get rid of it.
You can build a switched network to connect the remote data center to the point of presence where you want it to join the backbone.
Though this does nothing to mitigate time-of-flight latency, it nicely eliminates the latency and jitter issues due to routing. It's what we did at Westgrid to connect our computing clusters to storage facilities many hundreds of kilometers away.
Well, item (5) makes especially good sense. It's almost a weekly news event on the SANS mailing list that someone has lost a laptop containing a plaintext copy of the entire customer database. I know, it's bizarre. What idiot would do that? And what idiot would make it possible to do that? But it happens regularly just the same: proof that there's no shortage of idiots, I guess.
So yeah, the guy with the laptop might need to process items of data , and that data will be in plaintext at the point of use. But it shouldn't be transmitted or stored in plaintext.
You know, all of the use cases you describe can be supported by ticking the 'encrypt' checkbox
Not really, no.
Think about it. All you've done is ensure that the data on the storage media is encrypted. But as soon as it moves off the media and onto the server it's in plaintext.
Now what are you going to do? Nobody hacks into your disk array. They hack into your servers.
It's scarier to contemplate that such information is so often exposed as a matter of routine carelessness.
On the other hand, it's not clear what to do about the classic perimeter problem. Sooner or later, somewhere, the encrypted data has to be processed or presented in plaintext. The key and the data have to be brought together. Now we've converted the problem of securing the data to the problem of securing the key - probably many keys in practice - and the systems on which those keys reside - probably many systems.
Not only is Tcl/Tk a superior scripting language due to syntactical regularity and minimalism, not only does it provide native access to Unix commands, but it also provides event handling and a simple means to build a GUI if you want to wrap one around your script functions.
In case anyone needs to understand what's wrong with the above script, ask yourself what happens if there's a typo in the setting of LOGDIR.
First, the cd command fails. That leaves the current directory unchanged. Probably it's the home directory of whatever user is running the script.
Second, the rm command runs successfully in that directory. Ahem.
Notice that this is a general problem with software behavior, not specific to scripts nor to GUI frontends to scripts. This problem is the reason why people advocate tools such as cfengine and puppet, on the theory that people should be writing as few scripts as possible to do scalable system administration.
Ultimately, it's got to be "default deny". Nothing else will do.
And then we will have our Brave New World. Anything that isn't signed by a Certificate Authority which the software recognizes will be deemed to be a thought crime.
The reason this whole thing has any force at all behind it is because corporations are not people and don't have human interests at heart. A corporation can look at the value equation of the most draconian possible DRM and go, "Hey, cool. Summary execution for attempting to circumvent? That's sure to add a couple of percent to our user base."
The real reason that Apple is censoring applications by Mark Fiore is that he led the way in doing animated cartoons in Flash.
Regardless of whether you agree with his views (and I think it's entirely possible for you to make your own choice whether to install an app whose function is to deliver political satire) his work is widely regarded as technically innovative and artistically stylish. And the Apple principals can't stand to be seen in conflict with anyone more innovative and stylish than they are.
So rather than have him outclass them at the party, they'll just escort him out of the house, so to speak. There you go Apple, problem solved!
They were badly formed questions for a literacy test.
Not everyone agrees with your analysis. In fact the very person who should agree does not. John Bruer, who is credited for having removed the text in question, was asked whether scientifically literate academics would have answered "false" to the statement about humans having evolved from earlier species, Bruer said: "On that particular point, no."
Or,for that matter, the number of in-house development or integration projects that fall short of delivering on requirements.
But this illustrates the point made above. It's characteristic that most projects, regardless of whether they're open source or not, don't succeed. We just can't know about all of them as readily as we can the open source ones.
The BBC article seems to characterize these test subjects as unable to correctly assess risk.
That's cognitively quite different from assessing risk but not caring. On the basis of what's been presented here, I don't see any data which support the claim that moral reasoning is diminished in these subjects.
It turns out that the problem is not in the research, but in oversimplification by the news media. If you want a more accurate idea of what's going on, take a look at the original papers by Young et al. For example:
Participants even judged attempted harms
(e.g., attempting, but failing to poison someone) as more permissible than accidental harms (e.g.,
accidentally poisoning someone).
Not really. Your situation of working offline is a particular case of working online. It just happens to have high latency. So the easiest solution, for the user, is one which generalizes to encompass high latency.
The converse is not true. Of course you can retain the capabilities of an offline environment even after you add a wire to it, but those capabilities do not generalize to managing the resources on the other end of the wire.
The easiest solution to implement is a pencil and a piece of paper. Oh, you want capabilities too? Well, that's different.
It happens, rarely but it does, that I have to retract my articles at last minute and rewrite them because what I wrote simply is not true anymore.
Then you're approaching security as if it were a technology. It's not; it's a science. If you write instead about the application of security principles, you won't find yourself having to retract anything.
Sure, a particular use case might become less relevant over time, but it can't become wrong unless you misunderstood the underlying principle to begin with. The principle remains, and talking about it constitutes the real teaching opportunity.
I'd consider someone to be extremist who, whether as a matter of doctrine or personal conviction, actively goes around try to persuade others to believe in the existence of imaginary beings.
Another word might be "lunatic", but that would unkind to lunatics. Lunatics don't necessarily go around trying to persuade others to get on board with their insanity. Extremists do. The rest is just a question of degree, isn't it?
Slashdot Mirror
Nonsense. You can find oil almost anywhere. It's a byproduct of biomass. You probably have at least a litre of it in your kitchen in one form or another. So the argument that "peak" is a term to be reserved for non-renewable resources means that it should not be applied to oil either.
In fact, the notion of peak production has to do with sustainability: that is, the relative rates of production and consumption. Resource exhaustion is another topic entirely.
Yes, exactly.
There was no option for the natives of Easter Island to plant new forests, once the last tree had been felled. There was no potential renewability for them. They couldn't even build seaworthy craft to go in search of seedlings. In a word, they were FUCKED. And they did it to themselves.
So every historical and archaeological record that bears on how we handle the extremes of resource management is instructive, insofar as it tells us about our patterns of past successes and mistakes.
We live with a finite set of resources at the bottom of a massive gravity well isolated by millions of miles of hard vacuum from anything else at all. We are consuming many of those resources at an unsustainable rate. If we don't want to end up like the people of Easter Island, we'd better not take any of it for granted.
Roland Wright speaks eloquently of another tragedy of the commons involving timber. This one took place on Easter Island, and it is a stark reminder to us all of what may come from presuming that our resources are infinite or necessarily renewable.
Easter Island is barren now. It was once heavily forested. But, as Wright recounts, "The people who felled the last tree could see it was the last, could know with complete certainty that there would never be another. And they felled it anyway."
http://freerepublic.com/focus/f-news/1285440/posts
So what you save in cooling you spend on dedicated long-haul fiber?
Well, actually, I'm not telling you what will work for you. I'm telling you about what other people have done because it worked for them.
And even if you switch to a major POP, you still have dozens of miliseconds of latency at best.
Let's see, the switches we were using had about 10us latency, of which about 1us was optical transceiver latency. That was typical a few years ago, but has since improved by an order of magnitude. I don't know where you get your "dozens of milliseconds" estimate. That certainly has not been our experience.
You still can't support low latency operations like trading or synchronous data replication, making you customer pool thar much smaller.
Gee, that would be too bad. But since your arguments so far are unsound, I suppose we shouldn't rush to that conclusion.
Also, though I don't usually recommend this to people, your writing will be more credible if you turn on your spelling checker.
On the contrary. Just sit.
Zen is not about study. It's about practice.
We have to choose between the glass being half full or half empty. But it's not the symmetrical choice which it might seem to be. Specifically, it's not a matter of providing cold air. That's just a means to an end. Fundamentally, it's a matter of removing thermal pollution.
The ideal environment for the equipment is one which is uniformly, ambiently cold. Not only are there fewer thermal stresses, the entire design problem is simplified if you can assume uniformity. Departures from this ideal are therefore to be minimized. You don't want to contain the cold, you want it to prevail. Instead you want to contain the heat, remove it, and minimize points of contamination along the way. This has the additional benefit that you're minimizing leakage from the relatively small heat regions rather than trying to protect the entire environment.
An analogous situation arises in a marine engine room. You want to supply clean air and also exhaust the combustion gases. Supposing you only had the following two choices, should you (a) exhaust directly into the engine room and pipe fresh air from outside to the engine, or (b) pipe the exhaust outside and let air be drawn directly into the engine? Generally (b) is regarded as better, because exhaust gas is hot, toxic, and corrosive. It's much more trouble to design every surface in the environment to tolerate it that it would be just to contain and get rid of it.
You can build a switched network to connect the remote data center to the point of presence where you want it to join the backbone.
Though this does nothing to mitigate time-of-flight latency, it nicely eliminates the latency and jitter issues due to routing. It's what we did at Westgrid to connect our computing clusters to storage facilities many hundreds of kilometers away.
Well, item (5) makes especially good sense. It's almost a weekly news event on the SANS mailing list that someone has lost a laptop containing a plaintext copy of the entire customer database. I know, it's bizarre. What idiot would do that? And what idiot would make it possible to do that? But it happens regularly just the same: proof that there's no shortage of idiots, I guess.
So yeah, the guy with the laptop might need to process items of data , and that data will be in plaintext at the point of use. But it shouldn't be transmitted or stored in plaintext.
You know, all of the use cases you describe can be supported by ticking the 'encrypt' checkbox
Not really, no.
Think about it. All you've done is ensure that the data on the storage media is encrypted. But as soon as it moves off the media and onto the server it's in plaintext.
Now what are you going to do? Nobody hacks into your disk array. They hack into your servers.
It's scarier to contemplate that such information is so often exposed as a matter of routine carelessness.
On the other hand, it's not clear what to do about the classic perimeter problem. Sooner or later, somewhere, the encrypted data has to be processed or presented in plaintext. The key and the data have to be brought together. Now we've converted the problem of securing the data to the problem of securing the key - probably many keys in practice - and the systems on which those keys reside - probably many systems.
Don't forget to mention Tcl/Tk.
Not only is Tcl/Tk a superior scripting language due to syntactical regularity and minimalism, not only does it provide native access to Unix commands, but it also provides event handling and a simple means to build a GUI if you want to wrap one around your script functions.
In case anyone needs to understand what's wrong with the above script, ask yourself what happens if there's a typo in the setting of LOGDIR.
First, the cd command fails. That leaves the current directory unchanged. Probably it's the home directory of whatever user is running the script.
Second, the rm command runs successfully in that directory. Ahem.
Notice that this is a general problem with software behavior, not specific to scripts nor to GUI frontends to scripts. This problem is the reason why people advocate tools such as cfengine and puppet, on the theory that people should be writing as few scripts as possible to do scalable system administration.
If you think that a graphical equivalent of nmap will somehow make up for this situation, you're deeply misinformed about how nmap works.
Ultimately, it's got to be "default deny". Nothing else will do.
And then we will have our Brave New World. Anything that isn't signed by a Certificate Authority which the software recognizes will be deemed to be a thought crime.
The reason this whole thing has any force at all behind it is because corporations are not people and don't have human interests at heart. A corporation can look at the value equation of the most draconian possible DRM and go, "Hey, cool. Summary execution for attempting to circumvent? That's sure to add a couple of percent to our user base."
Wow! Épouvantable.
Did Christine Albanel take special courses in stupidity, or is it just a natural talent?
The real reason that Apple is censoring applications by Mark Fiore is that he led the way in doing animated cartoons in Flash.
Regardless of whether you agree with his views (and I think it's entirely possible for you to make your own choice whether to install an app whose function is to deliver political satire) his work is widely regarded as technically innovative and artistically stylish. And the Apple principals can't stand to be seen in conflict with anyone more innovative and stylish than they are.
So rather than have him outclass them at the party, they'll just escort him out of the house, so to speak. There you go Apple, problem solved!
Formal meetings are where formal decisions are made. Not everything can be done by a casual wave of the hand, you know.
They were badly formed questions for a literacy test.
Not everyone agrees with your analysis. In fact the very person who should agree does not. John Bruer, who is credited for having removed the text in question, was asked whether scientifically literate academics would have answered "false" to the statement about humans having evolved from earlier species, Bruer said: "On that particular point, no."
What JavaScript? This has to do with dynamic content.
You've heard of PostScript, right?
Or,for that matter, the number of in-house development or integration projects that fall short of delivering on requirements.
But this illustrates the point made above. It's characteristic that most projects, regardless of whether they're open source or not, don't succeed. We just can't know about all of them as readily as we can the open source ones.
That's cognitively quite different from assessing risk but not caring. On the basis of what's been presented here, I don't see any data which support the claim that moral reasoning is diminished in these subjects.
It turns out that the problem is not in the research, but in oversimplification by the news media. If you want a more accurate idea of what's going on, take a look at the original papers by Young et al. For example:
Not really. Your situation of working offline is a particular case of working online. It just happens to have high latency. So the easiest solution, for the user, is one which generalizes to encompass high latency.
The converse is not true. Of course you can retain the capabilities of an offline environment even after you add a wire to it, but those capabilities do not generalize to managing the resources on the other end of the wire.
The easiest solution to implement is a pencil and a piece of paper. Oh, you want capabilities too? Well, that's different.
It happens, rarely but it does, that I have to retract my articles at last minute and rewrite them because what I wrote simply is not true anymore.
Then you're approaching security as if it were a technology. It's not; it's a science. If you write instead about the application of security principles, you won't find yourself having to retract anything.
Sure, a particular use case might become less relevant over time, but it can't become wrong unless you misunderstood the underlying principle to begin with. The principle remains, and talking about it constitutes the real teaching opportunity.
Hey, there's this tree in my backyard that's green. Do you believe me?
Of course I don't believe you! I have no independent basis for verifying your claim.
That doesn't mean that I believe the converse. It means that I consider your claim to be empty.
Lunacy implies something wrong with their brain and intelligence.
Yes, exactly.
Please define "extremist."
I'd consider someone to be extremist who, whether as a matter of doctrine or personal conviction, actively goes around try to persuade others to believe in the existence of imaginary beings.
Another word might be "lunatic", but that would unkind to lunatics. Lunatics don't necessarily go around trying to persuade others to get on board with their insanity. Extremists do. The rest is just a question of degree, isn't it?