You're not wrong, in the sense that there are plenty of people who suffer from that "Just World" problem. But using it as a method to attack anyone who judges another at fault for failing to apply even the most basic thought to a a significant action does not require that you subscribe to the Just World hypothesis.
People who subscribe to that will blame another for what essentially constitute random accidents - a car hits yours when you had right of way - why didn't you do a defensive driving course? people are idiots you know!
However it's not the same thing to find fault with someone who, due to their own failure to apply common sense to a significant action, suffers loss (not the same as requiring common sense for an everyday action, attention is not always available).
It is also not the same to find fault with someone in the abstract, vs a particular person. Ie, to say that in general, those scammed by 911 mails should have known better, that the entire thing is both too dodgy and too good to be true, is not the same as berating your grandmother because it happened to her.
People are always more willing to deliver an objective assessment in the abstract, when it actually happens to your lovely old grandmother who spent years in Nigeria in her youth helping their education system the cause-and-effect of judgement suspension is easier to follow and natural sympathy for a member of your tribe comes into play.
The tragedy is that people with a strong belief that you are correct result in a less resilient population. Believers who end up in politics attempt to create a legal environment based on the idea that people cannot be trusted to think, a self-perpetuating cycle once it gets bad enough - if you don't normally have to think while going about your day to day activities, it becomes harder and harder to blame you for not thinking when anything unusual happens, so more and more things have to be regulated to the point where it is impossible to come to harm no matter how stupid the action.
Not only is such an environment unsustainable (at least given our current technology level), it is severely counter-productive. Safety is easiest to apply to a narrow range of possibilities, and thus laws are made which subsequently restrict peoples ability to act in an intelligent, but uncommon manner, resulting in heavy efficiency losses overall.
So jidar, why are you mis-representing the views of people in order to make yourself feel superior, and why are you screwing up my society?
Actually, they're right. Not saying they're any more realistic about what they're doing, but the Internet2 research that has been going on has run into plenty of problems with the basic IP protocols, from packet overhead to issues with TCP backoff algorithms. These things just weren't designed with gigabit+ speeds in mind, even though they work there, their efficiency is poor and in some cases really quite pathological.
Of particular concern above and beyond the basic failings when confronted with very high speeds, the balance between bandwidth ad latency starts to warp significantly as the bandwidth of the link increases. The speed of light, and thus the latency from A to B will never change, although response times improve due to better switching, but the amount that can be sent in any given moment constantly increases as we improve our ability to transmit more data per second. As a consequence, the idea of, for example, the standard TCP handshake SYN *wait* ACK will never improve despite greater speeds, it'll always be constrained by the need to wait for light to get to the end and back. At the moment, this is efficient, in the near future you would be better off sending a whole HTTP request off in a single packet and if the other end doesn't want to talk it'll send back a RST instead, reducing the connection times significantly.
There's a considerable number of related issues to do with high bandwidth that need serious investigation, from security implications (brute force of TCP session numbers occasionally rears its ugly head again until someone manages to squeeze better security into the protocol) to better protocols to support routing mechanisms (ipv6 being a good case in point, ipv4 is computationally expensive to route in comparison, causing your megafast link to choke because the hardware can't handle it).
We want to set foot on the moon again, because the moon is the ultimate high ground.
It's much harder to track a chunk of rock on a ballistic course than it is to track a missile, and no power supply is required, a simple mass driver on the moon and some decent "rock" design and any country could find itself the victim of a "meteor" strike.
The problem with this concept is deceptively simple:
1. The most difficult part of programming is developing software that does a good job of unanticipated uses 2. Most programmers are fine with something that just does the job they need it to do, and no more 3. Relatively few useful software components can operate in isolation, the rest place requirements on the environment
The consequence of this is that contrary to the theory that writing something once should be sufficient, the truth of the matter is that in the vast majority of practical cases, it is simpler to write the code once again, bespoke for your particular needs and environment, than it is to pick up the best available pre-written component to do it.
The essence of the problem is one of assumptions. Any component has an environment, this is the sum of state and information it requires in order to be able to operate. The component also (probably), has an API. This is the formal environment, the sum o state and information that it makes explicitly available to the programmer.
The problem that you have is that there is no "right" place for the percentage of the environment to be formalised into an API. For all those of you who are thinking "Well, the answer is obvious, everything!", imagine a component that manipulates dates.
Think about this for a moment, I use it because it's an example which almost every language I have encountered has done "poorly" (where poorly is the situation in which I find myself implementing something I felt should have been there by default, like adding or subtracting a month).
The environment for a date component, the true environment, is larger than any date component I have ever seen has exposed. For a start, which calendar are you working in? what timezone? what are the DST considerations for that timezone? is there some mechanism for updating these DST settings for those crazy timezones that change DST times all the time? is the begining of the week Sunday or Monday?, what is the current locale? If I add a month to the 31st of October, is it now the 30th of November, or the 1st of December? what if I subtract a month? is month addition associative?
Keep in mind that every question there has been solved at some point or another, and the majority of it is solved by the few really good date libraries out there (perl has a particularly fantastic one the name of which escapes me), but I've never seen one that did a good job of updating its daylight savings information, the majority of the *nix style ones simply assume that the operating system has good information, normally the catalog that came with your most recently install of glibc.
Anyway, back to the point, the issue is simply one of appropriateness. There are some components that make a lot of assumptions, but their interface is simple. There are others that make very few assumptions, but working with them is mind bogglingly complicated. Anyone who has ever had to work with mapserver or equivalent mapping problems will understand the gradient. But it is not at all uncommon to find yourself in a situation, even with something as well covered as dates, where the conventional components don't cover the part of the environment you need covered. Interfaces are either too big and complex, too small and simple, or just focused in a different area (how many components have been dropped because they were perfect, except that they didn't handle multithreading?).
In the end, rewriting this stuff is going to be a fact of life for a long time yet (unless we get really smart AIs or a revolution in programming I can't foresee), although hopefully better coverage of more common problems will continue to be a feature (it's much easier to do things today than it was 10 years ago basically because of this, regardless of what the lisp guys say:)
The simple problem with the fight against botnets is that it's asymmetric, and not in our favor. The bots are in a place that is particularly difficult for someone attempting to dismantle the network to reach, the property of someone else. It's not the technical problems that make a botnet so difficult to dismantle, but the legal ones.
The botnet creators don't give a damn, their objective involves breaking the law (where there is one) in order to hijack someones computer. Someone attempting to destroy the botnet is likely to be atempting to operate within the law, which requires notifying and enlisting the support of the owners of the compromise machines, many of which:
a) are difficult or impossible to contact b) don't speak your language c) don't understand anything about the problem d) don't care
Any single instance of a botnet may have weaknesses that permit its demise without running into potential legal problems (such as a poorly-secured disable command), however botnets as a concept have no real theoretical weakness given the appropriate cryptography and care of construction. Decentralised, failure resistant networks of cooperating nodes is a well researched area and at the level botnets operate, barely constitute a challenge to anyone with the necessary knowledge of protocols, cryptography and programming.
They're here to stay, there is no practical non-desperate legal changes or technical tricks which will kill the concept entirely. Even if the general level of internet security increased 10-fold, there'd still be more than enough vulnerable computers to support botnet operators, and lets face it, that level of security change is not going to happen. Even if the general OS level improves, old and embedded (non-patchable) devices are still plentiful, and there will be more no-patch applicance like systems in the future which will continue to be exploited.
As a systems administrator or someone otherwise concerned with the impact, the rules are simple. Stay patched, Stay vigilant. If a large botnet decides to get you, hope your ISP subscribes to something like tipping-point that will give them a head start on deflecting the inbound traffic. That's about it.
Given enough ammunition and fuel, it's likely that a single helicopter gunship would be sufficient to crush whole armies:) short of getting a lucky shot in with a cannon, there's just not a lot of hope. The technology difference would likely be equivalent, at best we'd have to get a lucky shot in with a nuke.
But more importantly, despite what the rest of the nutters around here are saying about how we should keep our heads down, the simple fact is that nobody is likely to bother coming to visit us because intellectual curiosity aside, it's a long way to go for absolutely no benefit.
There is nothing Earth or humanity has to offer which can't be found easier closer to 'home'. There's no point trying to wipe us out, or enslave us etc. Not on a civilisation scale anyway.
Thus far, we have come up with 4 possible scenarios for the attack of the earth:
1. Bizarre alien sex fetishes 2. The destruction of humanity due to its insistence in polluting the EM spectrum with talkshows. 3. Plausibly, we could end up falling victim to the equivalent of a pirate attack, a bunch of freebooters with a couple of interstellar ships who feel like setting up their own little feifdom where interstellar "law". 4. Religion. Of course.
Quite frankly, it's all incredibly far fetched. Personally, I don't think they're ever going to come all the way out here, it's a lot of effort for no real gain.
What's wrong with "I'd just assume not" ? I agree it's inelegant, but it doesn't seem to be the same class of error as "For all intensive purposes". I'd actually genuinely interested.
You fool! Don't you reaise that nobody does *anything* unless they're making money from it? artists wouldn't paint, musicians wouldn't record, nobody would do anything. Without the all-powerful profit motive we would all be vacant-eyed lumps of nothing being eaten alive by our own shoelaces!! all hail the RIAA, bless their little cotton socks, lest we be faced with a world bereft of art!
Self-contained, graphical environment with instant feedback, lots of code available, decent language with room to grow, runs anywhere, decent error messages (those who recommended javascript, what are you smoking? it barely gives error messages at the best of times).
No scientific value per se. But the moon has wonderul military potential. The fun thing about the earth is that it's sitting at the bottom of its own gravity well. The moon is, in some respects, the ultimate high-ground. You don't even have to try hard to be threatening from the moon, the same kind of explosive charges that can demolish a building on earth can launch a large chunk of rock at the capital city of your favorite enemy. Return fire is much harder work.
IMHO, this is one of the reasons why we don't have a base on the moon already. Even starting to build one would be the equivalent of stockpiling nukes again, suddenly every major arms country would need some means to balance the firepower.
Actually the issue isn't so much bandwidth, I put the block in place years ago when hundreds of gigabytes would have been a problem, it's not a problem anymore. The issue is one of processing power. Most sites hosted on Exorsus are PHP based and utilise a database to some degree or another. Apache is more than capable of delivering the number of hits required but on a general basis, it is more than likely that the system would overload and interrupt other users sites, email etc.
In the end, on a free system like Exorsus, it comes down to most utility. It does not serve a good purpose to interrupt all the rest of the system users' functions in order to cater to an occasional spike, especially since there are plenty of mechanisms for helping out servers, such as coralize, which will both avoid the slashdot restriction on the site and avoid placing unnecessary load on my system.
No, a salt can be public knowledge, a salt is there to prevent the use of a pre-hashed dictionary, it does not help in the event of a matcher.
Way back when the hash was unix crypt(), everyone got a little nervous about the idea that someone with a lot of computing power to burn might just fill up a large hard-drive with a map of plaintext->hash for the entire oxford dictionary for example. If they did that, then all they'd need to do subsequently to figure out the plaintext for any of the values they did the crypt()'ing for would be to look through the rive for the crypt value that matched the crypt value in the password file.
The idea of a salt is simple, it changes the hashed result in a computably repeatable fashion, but one that requires that the entire hash has to be performed with the salt in mind in order to get the correct end result.
So using a completely public bit of knowledge is fine. What is preferable is that the salt be random yet repeatable. That's why you see unix passwd files have the salt prepended to the hash (in crypt, it use to be the first 2 characters for example), you generate it randomly once, then whenever you want to see if the plaintext you've been given is the same, you grab the salt, hash the plaintext with it, and then check to see if the result matches the original hash.
In summary, a salt protects you from the problem of a pre-computed hash dictionary, nothing else.
?unfortunately? defeating your watermark is trivially done by obtaining three leaked copies rather than one, and simply doing a per-frame transformation picking the pixel colour of the majority. At best you will have a invalid watermark, at worst (depending on the scheme you encode with and the particular copies obtained) no watermark at all.
Three copies are not necessary, two will do to identify the location of the watermark however three makes it entirely automatic.
As pointed out by an earlier post, if you are releasing N copies, the complexity of the watermark increases dramatically as the size of the subset of N that you wish to protect yourself from increases, in the simple case (ie, to detect 2 people collaborating) you need both a tag per user, and a tag per possible pair, if you want to protect against three, a tag per possible triple, etc.
This is why the "industry" has such a hard time with this stuff, watermarking is *not* simple to make bulletproof and indeed the technique above ha an amusing end point, where subset of N compromised == N, at which point someone has merged copie of *every* leak you put out, and therefore in theory..they're all responsible. Beware of this if you have a nice predictable pattern in your watermark id:) you may find someone simply switches the code instead of removing it...
I really like inkscape. I've worked with it a fair bit now, and with the exception of a standard icon library for creating network etc diagrams, it's really good.
Another huge benefit of the middleware layer which you didn't outline is the ability to significantly boost the performance of your database layer by storing transient information and cached information in a memcached or equivalent mechanism.
Without the presence of a middleware layer, maintaining a consistent (and therefore more valuable) cache is more difficult, especially if you have reporting software accessing the database outside the regular web systems.
A middleware layer that is the exclusive access point to the data is able to ensure its own consistency for transient data and therefore pull it out of faster cached access when practical.
It is important of course not to store transaction-important data in such a thing, but session information, caches of processed information and regular queries are all relatively easy to transfer to memcached or other distributed shared memory environments for easy multiple-machine consistent caching.
This reduces the load on your database server signficantly, meaning less iron needed for transaction support (which doesn't distribute nearly as easily).
Acutally, 1) is not a valid case against open sourcing. Opening the source to something nobody could care about still helps in the instance of historical examination of the data the code work with.
Otherwise we tend to find a whole pile of data we no longer know how to access, sometimes even to the point of knowing whether it was important or not.
Re:Gun rights primer
on
Internet Hunting
·
· Score: 4, Insightful
Yeah, because an armed populace would prevent a major world power from invading your land today.
They've had enormous issues with SkypeOut, related to people being able to pay. Check the forums, there's no end of bitching about their CC clearing company. I never even managed to get so much as $10 worth of credit, despite correct CCV and everything, it just decided to decline to serve me.
The support leaves a great deal to be desired as well, they seem badly informed about this issue in particular and utterly unable to provide any kind of solution to the problem short of hoping your get bored and go away. I suspect that until they put some serious pressure on the people validating the credit cards for them, it will be more of the same.
I can use my CC to purchase stuff all over the 'net, but not 10 measly dollars of SkypeOut credit.
You are correct, the weaknesses of OTP are all out of band, one of which is the randomness of the keys. Perfectly random keys are of cours eunbreakable, but if I use a psuedo-random function, it is no longer a one-time pad, it's a stream cipher with the psuedo-random generator as the source and the initial state as the key.
However "english" is simply not enough of a qualifier, even given the trivial length message I presented first, there is no real way of knowing what I said, or even close. You would need many many qualifiers in order to reduce the search space, and at that point of course, you wouldn't need the ciphertext at all. That's why OTP is "unbreakable", in order to break it, you need so much information you already know the answer.
Slashdot Mirror
Man. What complete crap.
You're not wrong, in the sense that there are plenty of people who suffer from that "Just World" problem. But using it as a method to attack anyone who judges another at fault for failing to apply even the most basic thought to a a significant action does not require that you subscribe to the Just World hypothesis.
People who subscribe to that will blame another for what essentially constitute random accidents - a car hits yours when you had right of way - why didn't you do a defensive driving course? people are idiots you know!
However it's not the same thing to find fault with someone who, due to their own failure to apply common sense to a significant action, suffers loss (not the same as requiring common sense for an everyday action, attention is not always available).
It is also not the same to find fault with someone in the abstract, vs a particular person. Ie, to say that in general, those scammed by 911 mails should have known better, that the entire thing is both too dodgy and too good to be true, is not the same as berating your grandmother because it happened to her.
People are always more willing to deliver an objective assessment in the abstract, when it actually happens to your lovely old grandmother who spent years in Nigeria in her youth helping their education system the cause-and-effect of judgement suspension is easier to follow and natural sympathy for a member of your tribe comes into play.
The tragedy is that people with a strong belief that you are correct result in a less resilient population. Believers who end up in politics attempt to create a legal environment based on the idea that people cannot be trusted to think, a self-perpetuating cycle once it gets bad enough - if you don't normally have to think while going about your day to day activities, it becomes harder and harder to blame you for not thinking when anything unusual happens, so more and more things have to be regulated to the point where it is impossible to come to harm no matter how stupid the action.
Not only is such an environment unsustainable (at least given our current technology level), it is severely counter-productive. Safety is easiest to apply to a narrow range of possibilities, and thus laws are made which subsequently restrict peoples ability to act in an intelligent, but uncommon manner, resulting in heavy efficiency losses overall.
So jidar, why are you mis-representing the views of people in order to make yourself feel superior, and why are you screwing up my society?
Actually, they're right. Not saying they're any more realistic about what they're doing, but the Internet2 research that has been going on has run into plenty of problems with the basic IP protocols, from packet overhead to issues with TCP backoff algorithms. These things just weren't designed with gigabit+ speeds in mind, even though they work there, their efficiency is poor and in some cases really quite pathological.
Of particular concern above and beyond the basic failings when confronted with very high speeds, the balance between bandwidth ad latency starts to warp significantly as the bandwidth of the link increases. The speed of light, and thus the latency from A to B will never change, although response times improve due to better switching, but the amount that can be sent in any given moment constantly increases as we improve our ability to transmit more data per second. As a consequence, the idea of, for example, the standard TCP handshake SYN *wait* ACK will never improve despite greater speeds, it'll always be constrained by the need to wait for light to get to the end and back. At the moment, this is efficient, in the near future you would be better off sending a whole HTTP request off in a single packet and if the other end doesn't want to talk it'll send back a RST instead, reducing the connection times significantly.
There's a considerable number of related issues to do with high bandwidth that need serious investigation, from security implications (brute force of TCP session numbers occasionally rears its ugly head again until someone manages to squeeze better security into the protocol) to better protocols to support routing mechanisms (ipv6 being a good case in point, ipv4 is computationally expensive to route in comparison, causing your megafast link to choke because the hardware can't handle it).
"WE VOTED OUT THE PARTY IN POWER"
No you didn't, you just voted in the understudy.
We want to set foot on the moon again, because the moon is the ultimate high ground.
It's much harder to track a chunk of rock on a ballistic course than it is to track a missile, and no power supply is required, a simple mass driver on the moon and some decent "rock" design and any country could find itself the victim of a "meteor" strike.
Yay for living at the bottom of a gravity well.
The problem with this concept is deceptively simple:
:)
1. The most difficult part of programming is developing software that does a good job of unanticipated uses
2. Most programmers are fine with something that just does the job they need it to do, and no more
3. Relatively few useful software components can operate in isolation, the rest place requirements on the environment
The consequence of this is that contrary to the theory that writing something once should be sufficient, the truth of the matter is that in the vast majority of practical cases, it is simpler to write the code once again, bespoke for your particular needs and environment, than it is to pick up the best available pre-written component to do it.
The essence of the problem is one of assumptions. Any component has an environment, this is the sum of state and information it requires in order to be able to operate. The component also (probably), has an API. This is the formal environment, the sum o state and information that it makes explicitly available to the programmer.
The problem that you have is that there is no "right" place for the percentage of the environment to be formalised into an API. For all those of you who are thinking "Well, the answer is obvious, everything!", imagine a component that manipulates dates.
Think about this for a moment, I use it because it's an example which almost every language I have encountered has done "poorly" (where poorly is the situation in which I find myself implementing something I felt should have been there by default, like adding or subtracting a month).
The environment for a date component, the true environment, is larger than any date component I have ever seen has exposed. For a start, which calendar are you working in? what timezone? what are the DST considerations for that timezone? is there some mechanism for updating these DST settings for those crazy timezones that change DST times all the time? is the begining of the week Sunday or Monday?, what is the current locale? If I add a month to the 31st of October, is it now the 30th of November, or the 1st of December? what if I subtract a month? is month addition associative?
Keep in mind that every question there has been solved at some point or another, and the majority of it is solved by the few really good date libraries out there (perl has a particularly fantastic one the name of which escapes me), but I've never seen one that did a good job of updating its daylight savings information, the majority of the *nix style ones simply assume that the operating system has good information, normally the catalog that came with your most recently install of glibc.
Anyway, back to the point, the issue is simply one of appropriateness. There are some components that make a lot of assumptions, but their interface is simple. There are others that make very few assumptions, but working with them is mind bogglingly complicated. Anyone who has ever had to work with mapserver or equivalent mapping problems will understand the gradient. But it is not at all uncommon to find yourself in a situation, even with something as well covered as dates, where the conventional components don't cover the part of the environment you need covered. Interfaces are either too big and complex, too small and simple, or just focused in a different area (how many components have been dropped because they were perfect, except that they didn't handle multithreading?).
In the end, rewriting this stuff is going to be a fact of life for a long time yet (unless we get really smart AIs or a revolution in programming I can't foresee), although hopefully better coverage of more common problems will continue to be a feature (it's much easier to do things today than it was 10 years ago basically because of this, regardless of what the lisp guys say
The simple problem with the fight against botnets is that it's asymmetric, and not in our favor. The bots are in a place that is particularly difficult for someone attempting to dismantle the network to reach, the property of someone else. It's not the technical problems that make a botnet so difficult to dismantle, but the legal ones.
The botnet creators don't give a damn, their objective involves breaking the law (where there is one) in order to hijack someones computer. Someone attempting to destroy the botnet is likely to be atempting to operate within the law, which requires notifying and enlisting the support of the owners of the compromise machines, many of which:
a) are difficult or impossible to contact
b) don't speak your language
c) don't understand anything about the problem
d) don't care
Any single instance of a botnet may have weaknesses that permit its demise without running into potential legal problems (such as a poorly-secured disable command), however botnets as a concept have no real theoretical weakness given the appropriate cryptography and care of construction. Decentralised, failure resistant networks of cooperating nodes is a well researched area and at the level botnets operate, barely constitute a challenge to anyone with the necessary knowledge of protocols, cryptography and programming.
They're here to stay, there is no practical non-desperate legal changes or technical tricks which will kill the concept entirely. Even if the general level of internet security increased 10-fold, there'd still be more than enough vulnerable computers to support botnet operators, and lets face it, that level of security change is not going to happen. Even if the general OS level improves, old and embedded (non-patchable) devices are still plentiful, and there will be more no-patch applicance like systems in the future which will continue to be exploited.
As a systems administrator or someone otherwise concerned with the impact, the rules are simple. Stay patched, Stay vigilant. If a large botnet decides to get you, hope your ISP subscribes to something like tipping-point that will give them a head start on deflecting the inbound traffic. That's about it.
Given enough ammunition and fuel, it's likely that a single helicopter gunship would be sufficient to crush whole armies :) short of getting a lucky shot in with a cannon, there's just not a lot of hope. The technology difference would likely be equivalent, at best we'd have to get a lucky shot in with a nuke.
But more importantly, despite what the rest of the nutters around here are saying about how we should keep our heads down, the simple fact is that nobody is likely to bother coming to visit us because intellectual curiosity aside, it's a long way to go for absolutely no benefit.
There is nothing Earth or humanity has to offer which can't be found easier closer to 'home'. There's no point trying to wipe us out, or enslave us etc. Not on a civilisation scale anyway.
Thus far, we have come up with 4 possible scenarios for the attack of the earth:
1. Bizarre alien sex fetishes
2. The destruction of humanity due to its insistence in polluting the EM spectrum with talkshows.
3. Plausibly, we could end up falling victim to the equivalent of a pirate attack, a bunch of freebooters with a couple of interstellar ships who feel like setting up their own little feifdom where interstellar "law".
4. Religion. Of course.
Quite frankly, it's all incredibly far fetched. Personally, I don't think they're ever going to come all the way out here, it's a lot of effort for no real gain.
Ah! I understand now. Thanks. No, I'd never use it in place of "I'd just as soon not". Sorr, I imagined it being used in the following scentence:
"Does debian always come with a 2.6 kernel?"
"I'd just assume not"
As in, in general, I would make a negative assumption on the general condition that had been queried.
But I see what you mean! crazy!
What's wrong with "I'd just assume not" ? I agree it's inelegant, but it doesn't seem to be the same class of error as "For all intensive purposes". I'd actually genuinely interested.
You fool! Don't you reaise that nobody does *anything* unless they're making money from it? artists wouldn't paint, musicians wouldn't record, nobody would do anything. Without the all-powerful profit motive we would all be vacant-eyed lumps of nothing being eaten alive by our own shoelaces!! all hail the RIAA, bless their little cotton socks, lest we be faced with a world bereft of art!
http://www.squeak.org/
Self-contained, graphical environment with instant feedback, lots of code available, decent language with room to grow, runs anywhere, decent error messages (those who recommended javascript, what are you smoking? it barely gives error messages at the best of times).
No, you don't understand. What you do is mine it, then turn it into a big smooth object. Then you get people to pay you *not* to drop it on them.
No scientific value per se. But the moon has wonderul military potential. The fun thing about the earth is that it's sitting at the bottom of its own gravity well. The moon is, in some respects, the ultimate high-ground. You don't even have to try hard to be threatening from the moon, the same kind of explosive charges that can demolish a building on earth can launch a large chunk of rock at the capital city of your favorite enemy. Return fire is much harder work.
IMHO, this is one of the reasons why we don't have a base on the moon already. Even starting to build one would be the equivalent of stockpiling nukes again, suddenly every major arms country would need some means to balance the firepower.
Is it called Catch-22 by any chance?
Actually the issue isn't so much bandwidth, I put the block in place years ago when hundreds of gigabytes would have been a problem, it's not a problem anymore. The issue is one of processing power. Most sites hosted on Exorsus are PHP based and utilise a database to some degree or another. Apache is more than capable of delivering the number of hits required but on a general basis, it is more than likely that the system would overload and interrupt other users sites, email etc.
In the end, on a free system like Exorsus, it comes down to most utility. It does not serve a good purpose to interrupt all the rest of the system users' functions in order to cater to an occasional spike, especially since there are plenty of mechanisms for helping out servers, such as coralize, which will both avoid the slashdot restriction on the site and avoid placing unnecessary load on my system.
No, a salt can be public knowledge, a salt is there to prevent the use of a pre-hashed dictionary, it does not help in the event of a matcher.
Way back when the hash was unix crypt(), everyone got a little nervous about the idea that someone with a lot of computing power to burn might just fill up a large hard-drive with a map of plaintext->hash for the entire oxford dictionary for example. If they did that, then all they'd need to do subsequently to figure out the plaintext for any of the values they did the crypt()'ing for would be to look through the rive for the crypt value that matched the crypt value in the password file.
The idea of a salt is simple, it changes the hashed result in a computably repeatable fashion, but one that requires that the entire hash has to be performed with the salt in mind in order to get the correct end result.
So using a completely public bit of knowledge is fine. What is preferable is that the salt be random yet repeatable. That's why you see unix passwd files have the salt prepended to the hash (in crypt, it use to be the first 2 characters for example), you generate it randomly once, then whenever you want to see if the plaintext you've been given is the same, you grab the salt, hash the plaintext with it, and then check to see if the result matches the original hash.
In summary, a salt protects you from the problem of a pre-computed hash dictionary, nothing else.
I recommend lime. Put the lime in the coconut, take two asprin and call me in the morning.
?unfortunately? defeating your watermark is trivially done by obtaining three leaked copies rather than one, and simply doing a per-frame transformation picking the pixel colour of the majority. At best you will have a invalid watermark, at worst (depending on the scheme you encode with and the particular copies obtained) no watermark at all.
:) you may find someone simply switches the code instead of removing it...
Three copies are not necessary, two will do to identify the location of the watermark however three makes it entirely automatic.
As pointed out by an earlier post, if you are releasing N copies, the complexity of the watermark increases dramatically as the size of the subset of N that you wish to protect yourself from increases, in the simple case (ie, to detect 2 people collaborating) you need both a tag per user, and a tag per possible pair, if you want to protect against three, a tag per possible triple, etc.
This is why the "industry" has such a hard time with this stuff, watermarking is *not* simple to make bulletproof and indeed the technique above ha an amusing end point, where subset of N compromised == N, at which point someone has merged copie of *every* leak you put out, and therefore in theory..they're all responsible. Beware of this if you have a nice predictable pattern in your watermark id
I really like inkscape. I've worked with it a fair bit now, and with the exception of a standard icon library for creating network etc diagrams, it's really good.
Another huge benefit of the middleware layer which you didn't outline is the ability to significantly boost the performance of your database layer by storing transient information and cached information in a memcached or equivalent mechanism.
Without the presence of a middleware layer, maintaining a consistent (and therefore more valuable) cache is more difficult, especially if you have reporting software accessing the database outside the regular web systems.
A middleware layer that is the exclusive access point to the data is able to ensure its own consistency for transient data and therefore pull it out of faster cached access when practical.
It is important of course not to store transaction-important data in such a thing, but session information, caches of processed information and regular queries are all relatively easy to transfer to memcached or other distributed shared memory environments for easy multiple-machine consistent caching.
This reduces the load on your database server signficantly, meaning less iron needed for transaction support (which doesn't distribute nearly as easily).
Acutally, 1) is not a valid case against open sourcing. Opening the source to something nobody could care about still helps in the instance of historical examination of the data the code work with.
Otherwise we tend to find a whole pile of data we no longer know how to access, sometimes even to the point of knowing whether it was important or not.
Yeah, because an armed populace would prevent a major world power from invading your land today.
Like Iraq for example.
They've had enormous issues with SkypeOut, related to people being able to pay. Check the forums, there's no end of bitching about their CC clearing company. I never even managed to get so much as $10 worth of credit, despite correct CCV and everything, it just decided to decline to serve me.
The support leaves a great deal to be desired as well, they seem badly informed about this issue in particular and utterly unable to provide any kind of solution to the problem short of hoping your get bored and go away. I suspect that until they put some serious pressure on the people validating the credit cards for them, it will be more of the same.
I can use my CC to purchase stuff all over the 'net, but not 10 measly dollars of SkypeOut credit.
negativland.com :)
You are correct, the weaknesses of OTP are all out of band, one of which is the randomness of the keys. Perfectly random keys are of cours eunbreakable, but if I use a psuedo-random function, it is no longer a one-time pad, it's a stream cipher with the psuedo-random generator as the source and the initial state as the key.
However "english" is simply not enough of a qualifier, even given the trivial length message I presented first, there is no real way of knowing what I said, or even close. You would need many many qualifiers in order to reduce the search space, and at that point of course, you wouldn't need the ciphertext at all. That's why OTP is "unbreakable", in order to break it, you need so much information you already know the answer.