>>Dont know about you guys but a 1 in 113 chance of a massive catastrophy sounds pretty high to me.
Yet you have a 1 in 100 chance of being killed in a car crash. Does that stop anyone from getting into their cars in the morning to get to work?
>>Is it really that hard not to have things fall of it. (?)
Well, yes. Take anything, and attach some controlled explosives, get it light and send it hurtling at the sky, while making it obtain 2,000 mph extra per minute of launch. You're going to get objects falling off of it. Foam is light, but at speed its the problem.
>>Time on this recording has been compressed, so that 73 seconds corresponds to 27 minutes. Since the frequencies of these emissions are well above the audio frequency range, we have shifted them downward by a factor of 44.
If you compressed the time of my voice down about 22 times and shifted its frequency down by a factor of 44, I think I would sound eerie as well!
Then again... you might not need to shift my voice to make it sound eerie...
>Do you have any stats to back up your claim that most servers don't support byte range requests, or are you just going on memories from years ago?
How about the huge number of half-downloads I've goten from HTTP served downloads on many computers, of which have downloaded many files from many diffrent servers over a few diffrent connections?
I've never had a download from an FTP server ever fail. I've had *many* fail from HTTP served downloads that I really do try avoid downloading anything over about 3MB on HTTP.
You keep skipping over torrents. Really, are you trying to attack one point by ignoring points you can't argue? Or will you acknowledge that torrents can be far better than HTTP for downloads of large files?
>Well, it would be nice if it didn't stop responding when your access log hits 2GB, too...
One should never let the logs get larger than a few hundred MB. Consider rotating the logs, either monthly or weekly (or even more often if your logs gain size quickly).
>HTTP doesn't really have much to do with hypertext.
Well, it does share its name in the first letter (i.e. HyperText Transfer Protocol). When it was first about, you didn't really have anything other than the text. Its only with our media enriched abilities do we add in images, flash, java (shudder), and other binary file formats.
For a webpage, sure, HTTP is good. For many tiny files that only are going to be viewed rather than saved, sure, HTTP is good. But for large downloads (the whole "problem" behind the 2G limit), HTTP really isn't that good of a choice.
>byte ranges allow a client to only request part of the file (great for file completions)
I beileve you can do that with FTP as well, seeing as you can request a start offset in FTP for the ability to resume downloads.
Well, first you skipped my other suggestion of torrents, of which they have an advantage over HTTP because you're not stressing the main server, and once you get going, the main server can go away and you can still download.
Now, FTP has the ability to resume from a set point in a file, so you can pause your download, or continue one after sudden connection loss (for any reason).
As for a FTP login, well, there's anonymous logins for that very reason.
My justification isn't its abbreviation, its the fact that when you're downloading files of larger than 2G, you don't want to risk anything going wrong with a HTTP download (the major risk of being unable to resume in most cases).
Sitting in #apache on freenode is actually fun sometimes. You'll actually see these common things bought up by many people every day. The PDF actually touches on only a few of the "problems" that the conf file has.
However, its the 2G file limit that makes me laugh. Sure, there's LFS (Configure 1.3 with CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", enabled by default in 2.0.53 (and higher) and in 2.1), but to be really honest, there are far better ways to send large files. HTTP isn't one of them. There's FTP and there's also torrents; Both of which have the advantage of being designed for files rather than 'hypertext', which by nature is normally text...
>Why not just put in 10 sensors and as long as 3 or 4 are working then go ahead launch.
They did. There's four fuel sensors, of which one was faulty. You can launch on two, you can use it on just one. Its not a critical system in most respects, but since this fault is a bit odd, they decided to scrub the launch and check it over.
I'm sure you've made a valid point. However, I can't quite read it. I've set my browser window to 100% translucent, and I can't for the love of anything actually see it. So I'm typing at keys randomly in the hope that I undo what I did....
Not quite. There's an option they have if something goes wrong when the solids are lit, its just never been done before. You seperate them from the external tank while they are still lit.
Unfortunatly the rest would be unkown. Some say that the stress on the airframe would break it up, some say that you might get away with it.
If they do, they then have three options. Limp into space and return on a planned re-entry, do a total abort (i.e also jettson the main external tank), and try land, or do a total abort, and abandon the space shuttle.
Getting into space doesn't take long. Its about 2 mins worth of trying, so its only those 2 mins in which something can go wrong (Challenger showed that it can happen though).
So its not all 'cross your fingers', there are other options, its just that no one has ever attempted a in-launch seperation of the solids. Everything else though has been tested (including the high altitude abandon).
Yes! There's an idea! Line the case with something thats known to cause cancer! (/sarcasim)
The best thing for localised destruction would probibally be a shaped charge. Getting it right, you could use just one charge for all your drives; the explosive force being focused down through the main part of the disks, thus destroying them.
The other advantage of the shaped charge is that you'll only leave a hefty hole in the carpet, not a burning smoldering mass inside a case..
Being dyslexic and dyspraxic (it has its perks once and a while), I can't write well on paper. Infact, my fine motor control is so bad that it looks like a spider has died, rather than my todo list.
So to organise anything, I use a whiteboard with pens. Why? Its better than any digital application as it works without power, doesn't require me to sit down to use it, and most importantly, it requires gross motor control, something that I still have.
When you're able to write your todo list in 10cm letters at any time, able to check it off in many ways, and even the ability to doddle when bored, you'll see that there isn't a single application that can ever come close to a whiteboard.
Dead pixels will relate to the ISO rating class that the pannel has combined with its native resolution.
ISO 13406-2 (Class II) states that you can roughtly have 2 dead pixels per million pixels. So for a native resolution of 2560*1024, you will get nothing more than 4 dead pixels.
You can get better, of course, if the pannels are rated to Class I, they must be perfect, i.e. no dead pixels.
> What a pathetic set of definitions. > GIF. Lossless, but limited to 8 bit colour pallette.
No, no, no, no, no! Lies! All lies!
A GIF is not limited to an 8bit color palette in any way shape or form. Its the applications that make GIF's that limit it to 8bit.
http://phil.ipal.org/tc.html is proof that GIF can support more than a 8 bit palette. Its just that the generated image can exceed the point of a small file sized image.
In short: GIF can support more than 256 colour palette.
Any that require 3D models to show what is required. CAD/CAM applications, any one doing 3D rendering, showcases for new homes, medical software (teaching that is), etc.
The "average" user won't, however, have any use for this until computer games start using it, but then again, thats the whole reason why we have faster computers now isn't it?
If you really need to get the proper 'Secuirty' tab for XP Home, look no further than: HP Home Secuirty tab
It works, but its not enabled by default because the average user can stuff alot up (you can set deny to all, and no one can access the file (although if you own the parent folder, you can take control))
In short? Well, this means that if someone gets hold of a database which has your password stored in md5, then they can crack it.
However, having a collision just makes bruteforcing it easier, it doesn't mean that you can take a hash and spit out the original word in seconds.
In short: you are safe for now...
In long?
For the sake of this post, I will simply define the two methods of attack which combine to form collision attacks - birthday attack and meet-in-the-middle attack - as we generically deem them.
Birthday Attack
As the name implies, this attack is based upon the birthday paradox, which goes a little something like this: If you have, let's say, 23 people in a room, the probability of duplicate birthdays is above 50%. In fact, 23 people are required for this paradox to hold a probability > 50%. This attack relies on the idea of producing duplicates, or collisions, at a rate that exceeds expectations. To satisfy our purpose, we can define it simply, as:
For N different values, one can expect the initial collision to occur, in the vicinity of the square root of N randomly chosen values. You are simply waiting for the second occurrence of a single value within the same value set.
To those who actually analyze the basis for this attack, it isn't a paradox in the sense that it contradicts itself, be it logically or such. It is more so a paradox in that it contains a veracity of mathematics in which there is a contradiction of how one's natural cognitive reaction may be, to the problem. In other words, one may be apprehensive of the problem's validity, in terms of how sound the conclusion is, therefore making this a "contrary to popular belief" case, rather than a "contradicting itself" case.
Meet-in-the-Middle Attack
Unlike its relative above, this attack relies on the overlapping of two value sets. Not only does this attack see more applicable benefit, it is much more flexible. Consider the following scenario:
Where N is all possible values, while P and Q are pairs of element sets, one can assume the expectation of a collision when PQ/N is close to 1, if the chance of matching is 1/N. P similar to Q similar to the square root of N, of course, is the birthday bound, which is most efficient.
This is where the flexibility of meet-in-the-middle attacks comes into play. Sometimes, the ease of finding elements is greater for one set than the other, which is valid, as long as PQ is similar to N.
The differences between these two attacks are very simple to outline. Birthday attacks are concerned with the duplicate occurrence of single values within one set, whereas meet-in-the-middle attacks exhibit the praxis of overlapping of two sets.
So, why are we concerned with this?
Smaller, 128-bit keys, or similar cryptographic values, will provide us with n/2 security, therefore, in the case of 128-bit, you render 2^64 complexity, which is far below our desired level of security. This is the primary basis for our concern with collision attacks and their effects on insufficient key lengths. Otherwise, using 128-bit keys might not be so risky. The complexity that this imposes makes it the most cumbersome issue to deal with, alongside the intricacies of what it takes to get entropy right, the first time around. So, here we have it. The second antagonist - collision attack. It's riding shotgun with entropy, so you'd better approach them with equal caution.
Even if we can ensure n bits of entropy to obtain n bits of security, we must still append extra key material, at the mode of operation level, to thwart the effectiveness of collision attacks. This, in itself, is a security risk, due to added complexity, which is exactly what we do not want to impose upon our decision-making process. It is much more trivial to achieve sufficient security via simplicity, in our case. Again, stay with larger keys. 256-bit, if you can help it.
NeoThermic
Re:download.com sucks...
on
P2P vs. The Clones
·
· Score: 2, Informative
Or, use the service which is free, and has been for a while:
Slashdot Mirror
You're quite right, I was getting confused with the statistics of people involved in a car accident.
NeoThermic
>>Dont know about you guys but a 1 in 113 chance of a massive catastrophy sounds pretty high to me.
4 e5002_high.jpg shows quite clearly that the foam came from further along the Ext. Tank. (See http://www.nasa.gov/images/content/123628main_hh_u mb_no_annotation1_5002.jpg if you're having trouble spotting it.)
Yet you have a 1 in 100 chance of being killed in a car crash. Does that stop anyone from getting into their cars in the morning to get to work?
>>Is it really that hard not to have things fall of it. (?)
Well, yes. Take anything, and attach some controlled explosives, get it light and send it hurtling at the sky, while making it obtain 2,000 mph extra per minute of launch. You're going to get objects falling off of it. Foam is light, but at speed its the problem.
As for those that say the foam came from the mounting section, you're actually wrong. http://www.nasa.gov/images/content/123612main_s11
NeoThermic
>>Time on this recording has been compressed, so that 73 seconds corresponds to 27 minutes. Since the frequencies of these emissions are well above the audio frequency range, we have shifted them downward by a factor of 44.
If you compressed the time of my voice down about 22 times and shifted its frequency down by a factor of 44, I think I would sound eerie as well!
Then again... you might not need to shift my voice to make it sound eerie...
NeoThermic
>Do you have any stats to back up your claim that most servers don't support byte range requests, or are you just going on memories from years ago?
How about the huge number of half-downloads I've goten from HTTP served downloads on many computers, of which have downloaded many files from many diffrent servers over a few diffrent connections?
I've never had a download from an FTP server ever fail. I've had *many* fail from HTTP served downloads that I really do try avoid downloading anything over about 3MB on HTTP.
You keep skipping over torrents. Really, are you trying to attack one point by ignoring points you can't argue? Or will you acknowledge that torrents can be far better than HTTP for downloads of large files?
NeoThermic
>Well, it would be nice if it didn't stop responding when your access log hits 2GB, too...
o gs.html or http://httpd.apache.org/docs/programs/rotatelogs.h tml
One should never let the logs get larger than a few hundred MB. Consider rotating the logs, either monthly or weekly (or even more often if your logs gain size quickly).
See:
http://httpd.apache.org/docs-2.0/programs/rotatel
NeoThermic
>HTTP doesn't really have much to do with hypertext.
Well, it does share its name in the first letter (i.e. HyperText Transfer Protocol). When it was first about, you didn't really have anything other than the text. Its only with our media enriched abilities do we add in images, flash, java (shudder), and other binary file formats.
For a webpage, sure, HTTP is good. For many tiny files that only are going to be viewed rather than saved, sure, HTTP is good. But for large downloads (the whole "problem" behind the 2G limit), HTTP really isn't that good of a choice.
>byte ranges allow a client to only request part of the file (great for file completions)
I beileve you can do that with FTP as well, seeing as you can request a start offset in FTP for the ability to resume downloads.
NeoThermic
Well, first you skipped my other suggestion of torrents, of which they have an advantage over HTTP because you're not stressing the main server, and once you get going, the main server can go away and you can still download.
Now, FTP has the ability to resume from a set point in a file, so you can pause your download, or continue one after sudden connection loss (for any reason).
As for a FTP login, well, there's anonymous logins for that very reason.
My justification isn't its abbreviation, its the fact that when you're downloading files of larger than 2G, you don't want to risk anything going wrong with a HTTP download (the major risk of being unable to resume in most cases).
NeoThermic
>And it's URI, not URL. No such thing as a URL.
There's a whole RFC here to prove you wrong:
http://www.ietf.org/rfc/rfc1738.txt
NeoThermic
Sitting in #apache on freenode is actually fun sometimes. You'll actually see these common things bought up by many people every day. The PDF actually touches on only a few of the "problems" that the conf file has.
However, its the 2G file limit that makes me laugh. Sure, there's LFS (Configure 1.3 with CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64", enabled by default in 2.0.53 (and higher) and in 2.1), but to be really honest, there are far better ways to send large files. HTTP isn't one of them. There's FTP and there's also torrents; Both of which have the advantage of being designed for files rather than 'hypertext', which by nature is normally text...
NeoThermic
>Why not just put in 10 sensors and as long as 3 or 4 are working then go ahead launch.
They did. There's four fuel sensors, of which one was faulty. You can launch on two, you can use it on just one. Its not a critical system in most respects, but since this fault is a bit odd, they decided to scrub the launch and check it over.
NeoThermic
As per Ravatar's reply above mine, XP SP2 is what I'm running, and both the options are there for netstat.
NeoThermic
And for windows:
netstat -v -o -n -b -a
(you can ommit -v for a quicker display)
NeoThermic
I'm sure you've made a valid point. However, I can't quite read it. I've set my browser window to 100% translucent, and I can't for the love of anything actually see it. So I'm typing at keys randomly in the hope that I undo what I did....
NeoThermic
Not quite. There's an option they have if something goes wrong when the solids are lit, its just never been done before. You seperate them from the external tank while they are still lit.
Unfortunatly the rest would be unkown. Some say that the stress on the airframe would break it up, some say that you might get away with it.
If they do, they then have three options. Limp into space and return on a planned re-entry, do a total abort (i.e also jettson the main external tank), and try land, or do a total abort, and abandon the space shuttle.
Getting into space doesn't take long. Its about 2 mins worth of trying, so its only those 2 mins in which something can go wrong (Challenger showed that it can happen though).
So its not all 'cross your fingers', there are other options, its just that no one has ever attempted a in-launch seperation of the solids. Everything else though has been tested (including the high altitude abandon).
NeoThermic
Yes! There's an idea! Line the case with something thats known to cause cancer! (/sarcasim)
The best thing for localised destruction would probibally be a shaped charge. Getting it right, you could use just one charge for all your drives; the explosive force being focused down through the main part of the disks, thus destroying them.
The other advantage of the shaped charge is that you'll only leave a hefty hole in the carpet, not a burning smoldering mass inside a case..
NeoThermic
Being dyslexic and dyspraxic (it has its perks once and a while), I can't write well on paper. Infact, my fine motor control is so bad that it looks like a spider has died, rather than my todo list.
So to organise anything, I use a whiteboard with pens. Why? Its better than any digital application as it works without power, doesn't require me to sit down to use it, and most importantly, it requires gross motor control, something that I still have.
When you're able to write your todo list in 10cm letters at any time, able to check it off in many ways, and even the ability to doddle when bored, you'll see that there isn't a single application that can ever come close to a whiteboard.
NeoThermic
Dead pixels will relate to the ISO rating class that the pannel has combined with its native resolution.
ISO 13406-2 (Class II) states that you can roughtly have 2 dead pixels per million pixels. So for a native resolution of 2560*1024, you will get nothing more than 4 dead pixels.
You can get better, of course, if the pannels are rated to Class I, they must be perfect, i.e. no dead pixels.
NeoThermic
> What a pathetic set of definitions.
> GIF. Lossless, but limited to 8 bit colour pallette.
No, no, no, no, no! Lies! All lies!
A GIF is not limited to an 8bit color palette in any way shape or form. Its the applications that make GIF's that limit it to 8bit.
http://phil.ipal.org/tc.html is proof that GIF can support more than a 8 bit palette. Its just that the generated image can exceed the point of a small file sized image.
In short: GIF can support more than 256 colour palette.
NeoThermic
Any that require 3D models to show what is required. CAD/CAM applications, any one doing 3D rendering, showcases for new homes, medical software (teaching that is), etc.
The "average" user won't, however, have any use for this until computer games start using it, but then again, thats the whole reason why we have faster computers now isn't it?
NeoThermic
If you really need to get the proper 'Secuirty' tab for XP Home, look no further than:
HP Home Secuirty tab
It works, but its not enabled by default because the average user can stuff alot up (you can set deny to all, and no one can access the file (although if you own the parent folder, you can take control))
NeoThermic
About the only thing i can say to you is N = R* × fp × ne × fl × fi × fc × L
NeoThermic
Not sure what you see, but when I go to the firefox page, I see a huge div on the right, saying:
`Download Now!`
Seriously, are you on the right page?
http://www.mozilla.org/products/firefox/
NeoThermic
No. Read again. 80,000 CPU hours. Its like man hours. If two men work for 1 hour, thats 2 man hours.
So in theory, you could assign 40,000 CPU's for 2 hours on the task and get a collision.
NeoThermic
In short? Well, this means that if someone gets hold of a database which has your password stored in md5, then they can crack it.
However, having a collision just makes bruteforcing it easier, it doesn't mean that you can take a hash and spit out the original word in seconds.
In short: you are safe for now...
In long?
For the sake of this post, I will simply define the two methods of
attack which combine to form collision attacks - birthday attack and
meet-in-the-middle attack - as we generically deem them.
Birthday Attack
As the name implies, this attack is based upon the birthday paradox,
which goes a little something like this: If you have, let's say, 23
people in a room, the probability of duplicate birthdays is above 50%.
In fact, 23 people are required for this paradox to hold a probability
> 50%. This attack relies on the idea of producing duplicates, or
collisions, at a rate that exceeds expectations. To satisfy our
purpose, we can define it simply, as:
For N different values, one can expect the initial collision to occur,
in the vicinity of the square root of N randomly chosen values. You
are simply waiting for the second occurrence of a single value within
the same value set.
To those who actually analyze the basis for this attack, it isn't a
paradox in the sense that it contradicts itself, be it logically or
such. It is more so a paradox in that it contains a veracity of
mathematics in which there is a contradiction of how one's natural
cognitive reaction may be, to the problem. In other words, one may be
apprehensive of the problem's validity, in terms of how sound the
conclusion is, therefore making this a "contrary to popular belief"
case, rather than a "contradicting itself" case.
Meet-in-the-Middle Attack
Unlike its relative above, this attack relies on the overlapping of
two value sets. Not only does this attack see more applicable benefit,
it is much more flexible. Consider the following scenario:
Where N is all possible values, while P and Q are pairs of element
sets, one can assume the expectation of a collision when PQ/N is close
to 1, if the chance of matching is 1/N. P similar to Q similar to the
square root of N, of course, is the birthday bound, which is most
efficient.
This is where the flexibility of meet-in-the-middle attacks comes into
play. Sometimes, the ease of finding elements is greater for one set
than the other, which is valid, as long as PQ is similar to N.
The differences between these two attacks are very simple to outline.
Birthday attacks are concerned with the duplicate occurrence of single
values within one set, whereas meet-in-the-middle attacks exhibit the
praxis of overlapping of two sets.
So, why are we concerned with this?
Smaller, 128-bit keys, or similar cryptographic values, will provide
us with n/2 security, therefore, in the case of 128-bit, you render
2^64 complexity, which is far below our desired level of security.
This is the primary basis for our concern with collision attacks and
their effects on insufficient key lengths. Otherwise, using 128-bit
keys might not be so risky. The complexity that this imposes makes it
the most cumbersome issue to deal with, alongside the intricacies of
what it takes to get entropy right, the first time around. So, here we
have it. The second antagonist - collision attack. It's riding shotgun
with entropy, so you'd better approach them with equal caution.
Even if we can ensure n bits of entropy to obtain n bits of security,
we must still append extra key material, at the mode of operation
level, to thwart the effectiveness of collision attacks. This, in
itself, is a security risk, due to added complexity, which is exactly
what we do not want to impose upon our decision-making process. It is
much more trivial to achieve sufficient security via simplicity, in
our case. Again, stay with larger keys. 256-bit, if you can help it.
NeoThermic
Or, use the service which is free, and has been for a while:
SnapFiles
NeoThermic