You might not always be able to find the right address, even if there is an address on the page it might not be the right person to ask about bandwidth.
People pay for bandwidth.
I'd avoid those ISPs where you have to pay for the amount of traffic. Signing a contract where you have to pay for something where the price is completely out of your control sounds like a bad idea to me.
For that matter, why not have one farm of computers sieving out all the primes
AFAIK Erathostenes is the fastest algorithm for that task, but we would just not have enough memory for the bitmask. Secondly there are factorization algorithms faster than finding all the prime candidates.
Quantum computing is about much more than how many cycles per second it can run
Yes indeed. I don't remember the complexity of factorization on a quantum computer, but I don't think we should worry about the speed being 1MHz or 1GHz. What we should worry about right now is the storage size. We just cannot fit a 2048 bit key into 7 bits of storage. If building such a "large" quantum computer eventually suceeds, we will have far worse worries than Microsoft, X-Box, and Palladium.
Ok so I havent passed the discrete matchs exam yet, but doesn't numbers that are divisible by 5 end in either 0 or 5 (thus beeing eliminated already)?
Yes, that was also what was said.
Why not numbers that end in 0,2,4,6,8 AND numbers where the total sum of the individual digits is divisible by 3?
You can do almost that. In fact you wouldn't be looking on a decimal representation, but rather a binary representation. So computing the last digit of a decimal representation would take som computation time. Unless you are smart and keep the last digit in a seperate variable. Just adding one to a byte and starting from zero every time you reach ten would be a lot faster than computing the last digit every time.
But in fact we can be even smarter than that. Why keep the last digit of a base 10 representation? It would be smarter to save the last digit of the number in a higher base, because there will be a larger fraction of digits that can be ruled out immediately. For example the case of divisibility by three would be trivial if we kept the last digit of a base 30 representation rather than base 10. I'd even go as far as base 210, which happens to be the product of the first four primes. Only 48 of the 210 possibilities would have to be tested. That has cut the number of cases down to 23%
But we can be even smarter. Why even add only one each time, given the last digit we already know how many times we will have to add one before reaching the next candidate. So rather just keep an array telling us how much to add each time, then we don't even have to remember the last digit, but just an index in an array with 48 bytes.
But why stop at base 210. Take another two primes and make the base 30030, only 5760 of those would have to be tested. So we would be down to 19% of the original search space. But here we notice that increasing the array by a factor 120 only saved us a few percent. And in fact each time we add another prime the size of the array grows faster and faster while the gain in reduction of search space gets smaller. So as soon as we hit the size of the L1 cache, we will probably gain no more. All in all we might have cut the search space by a factor four, maybe five or six, but no more.
But for a problem of exponential complexity cutting the time usage by a constant factor doesn't really help. All our efforts to avoid candidates that are obviously not prime can be defeated by just using a key five bits larger. Those five bits would be enough to make the problem harder than before we used those tricks. And the price for those five bits in normal use of the key is close to nothing. In fact they already did add another five bits and then again some more.
But we can be even smarter, first of all we obviously only have to verify divisors up to the square root of the number. Of course we'd already just do that, because we would be starting from zero and going upwards.
But we can be even smarter, because trial and error is absolutely not the fastest way to factorize products of large primes. Other techniques like quadratic sieve would be a lot faster. And then all our smart ways to avoid obviously nonprimes is not usefull at all. The way to actually factorize is completely different.
Because the purpose of doing it is to achieve interoperability between Linux and the X-Box. Had the purpose been to make pirate copies or something similar, it would have been an entirely different matter.
Like, is there anything to prevent Microsoft from just randomly calling up the project with a bunch of dummy clients that submit the REAL x-box key a couple times to the "i've checked this and it's not the key" list?
Hurry up, mod parent down before anybody from Microsoft see it.
The Neo Project recently updated its client so users can use free processor cycles to try and crack the private key that Microsoft uses to sign Xbox software.
Unfortunately the server apears to be slashdotted. Let's hope that just means a lot of people want to help with that task. This of course makes me want to ask about the legality of doing this. Does people risk getting sued by downloading the client?
The Oxygen in earths atmosphere came from the earliest living organisms.
It has always been my understanding that the first life used oxygen rather than producing it. Life forms capable of producing oxygen came shortly after.
That doesn't work well because I get too many hits like
That is not a problem with grep, it reports those because the word ant really is there. To avoid that use the grep command on a set of sources which has not yet been used for a compilation, or that has been compiled without that word in the path or machine name.
Re:Horse & Pig reference in Kernel 2.4.20
on
Linux Kernel Code Humor
·
· Score: 3, Informative
Does anyone know how to do grep for "ant" (exact word by itself)?:)
Lots of answers, but most of them not really good.
How about reading the man page. After doing that, I came up with this: grep -ir "\<ant\>" *
The use of -i is simpler than specifying every letter could be upper or lower case. And the use of spaces at each end of the word misses those cases where where other chars are used at the word boundaries. Then better use the grep builtin feature to indicate start and end of a word.
The most scary one I ever got was on a RH7.1 system. After upgrading a lot of RPM packages, I sudenly started getting the "Self-destruct in 5 seconds. Have a nice day..." message. That was one of the error messages I was hoping never to see.
I couldn't find exactly that comment. This is as close as I can get:
grep -ir 'wonder.*work' linux
linux/net/ipv4/arp.c: I wonder why people believe that they work.
linux/drivers/acorn/block/fd1772.c: * code - I wonder if it will still work... No:-)
linux/drivers/nubus/nubus.c: * I wonder how the CRC is meant to work -
"we can never create fractals with inifinite dimension"
Really!? Watch me!
You missed the point. You can define an infinitely dimensional fractal in an infinitely dimensional space. But it can never exist in our finite dimensional space. (Let's not start an argument about the actual number of dimensions of our space. We all know there are at least three, and I think nobody believes there are more than ten.)
Fractal implies a geometric pattern that is repeated at every scale and so cannot be represented by classical geometry.
And this is exactly where the snowflake breaks down. You might find the same patterns in a snowflake at many different scales, but when you go to smaller and smaller scales, eventually you will reach the molocular scale at which the pattern changes.
A snowflake is not a perfect fractal. If we could really create fractal physical objects, I have ideas for applications in computers. You wouldn't imagine the processing power of a fractal CPU.
Anything that can be represented as a (or a finite number of) point could be considered to have a dimension of zero.
That is true, but in fact you can even have an infinite number of points and still have a dimension of zero.
There are different kinds of infinity. The set of integers is what we call a countable infinity, while the set of real numbers is what we call an uncountable infinity. There are even uncountable infinites that are infinitely larger than the real numbers. In fact it is a suprprise once you realize how large infinities can become compared to the quite small infinity of the integers. In fact the inifinity of the integers is the smallest infinity you can find.
A set of countable infinity has dimension zero, anything with dimention larger than zero is an uncountable infinity same size as the real numbers. Wether the dimension is 0.1 or 3.0 the number of points will be exactly the same. And that is the case for any finite number of dimensions. And AFAIK no fractal can be of higher dimension than the space in which it exists, so we can never create fractals with inifinite dimension.
The parent post dares to speak the truth about the lack of quality about X Windows!
Most people criticizing X Windows don't know what they are talking about. Usually the talk is about the user interface which is in fact implemented by something like KDE or Gnome, or even simpler stuff like a plain window manager. Sure I don't think neither KDE nor Gnome is perfect yet. They are still too unstable. And in every revision the interface is improved in some way while it gets worse in other ways. Why can't I just configure the interface to get the best from every version? And finally they are way too much bloat, they gets slower and slower as I upgrade to newer versions.
But if we take the talk back to X Windows that is a really good design. Network transparancy works like a charm. It is portable, interoperable, and extensible. What more can you ask for? Surely XFree86 is not always perfectly stable, but it never caused me enough trouble to make me care enough about it to track down the problems. All I know is that once in a while it crashes on VC switching, but except from this minor glitch, it has been working just fine since I upgraded to RH7.2.
No matter what the layer above should look like, it is nice to have a filesystem below. You can do stuff like making backup copies. Take a copy of the files belonging to one particular application. Move files. Fix problems when something goes wrong.
Forking files can be accomplished without copying a file.
Versioning should not conceptually be built into a filesystem. I find it far too complicated. A filesystem should be conceptually as simple as possible (but no simpler).
However, I don't see why anybody would come up with a hierachical file system, unless they were accomidating for hardware limitations.
I don't get it. Back in DOS 1.x a flat filesystem was being used. In DOS 2.x this was extended into a hierarchical filesystem. That was not due to any kind of hardware limitations, in fact the growing media sizes was probably one of the reasons to want a way to organize data. In fact the hierarchical filesystem was one of the most important improvements in DOS 2.x, the fact that it was implemented in a clumsy way was certainly not due to a bad idea, but rather because that way it could be slightly more backward compatible. That this clumsy directory implementation was allowed to exist all the way until W95 just proves a certain companys incompetence, other systems has had far better hierarchical filesystems.
Placing files somewhere within a huge directory tree is just too darn complicated.
The hierarchical filesystems were introduced to make things simpler. And it certainly did. Some applications implement some complicated stuff on top of that, but that is certainly not due to the hierarchical filesystems.
Why should the same file not exist in multiple directories?
In most of the hierarchical filesystems I know a file can actually exist in multiple directories. In fact FAT happens to be the only filesystem I know without that feature.
Why should copies of a file exist?
For backups, or simply because you want to work on a copy rather than the original. Then again I'd like to see filesystems implementing efficient copying of files by the use of CoW, but that must be transparent to the overlying applications.
Everything, including advanced security policies (more advanced than what is currently possible)
Do we want more complicated security policies? They can be a threat to security because of implementation bugs or incorrect usage. There are few situations that cannot be covered with the user, group, other attribute concept. But in fact more complicated security policies are being built into hierarchical filesystems, so we don't need a keyword system for that.
Finally it must be noted that I don't dislike the idea of a keyword based approach to files, I just don't want to give up the hierarchical filesystem to achieve it. A keyword approach built on top of a hierarchical filesystem sounds like a great idea to me. Built as an extension to a hierarchical filesystem also is an option, though care must be taken not to break too many existing applications. You don't want to loose your metadata because your backup utility saves only the files without the keywords.
Also note that I don't say a filesystem must be simple, only that it should implement a simple concept. A simple interface between applications and filesystem is important to me. But the underlying filesystem implementation can be arbitrary complex, and sometimes that is a good idea. FAT is a perfect example of a too primitive implementation.
To be honest, 'dd' is not a Linux utility. Various *nixes used it before Linux was even started.
In fact dd is even overkill for this purpose. The same could be achieved by cat or something even simpler. This task is so simple that we shouldn't really care how they did it. I could have written a 42 line Turbo Pascal program under DOS that could do it.
On top of that, if an app is not made 64 bit ready, why would you need a CPU that is?
The most important piece of software to get upgraded to 64 bit code is not actually an application, but rather the OS kernel you are using. AFAIK the
x86-64 architecture is so nicely designed that a 64 bit OS can run both old 32 bit programs and 64 bit programs in a multitasking environment. And even 32 bit applications can get a little benefit from the change by getting the OS outside the 32 bit address range. Thus they can get access to 4GB of address space compared to the 2 or 3GB they would usually have.
A lot more applications will benefit from a recompilation, which might not even require a change of the source code. There are places where 64 bit calculations are already needed on the current 32 bit architectures. There might not be a lot of people knowing it, but in fact we have had the need for 64 bit architectures for many years. I'm looking forward for the new AMD chips.
Slashdot Mirror
We have this remarkable thing called e-mail.
You might not always be able to find the right address, even if there is an address on the page it might not be the right person to ask about bandwidth.
People pay for bandwidth.
I'd avoid those ISPs where you have to pay for the amount of traffic. Signing a contract where you have to pay for something where the price is completely out of your control sounds like a bad idea to me.
For that matter, why not have one farm of computers sieving out all the primes
AFAIK Erathostenes is the fastest algorithm for that task, but we would just not have enough memory for the bitmask. Secondly there are factorization algorithms faster than finding all the prime candidates.
Quantum computing is about much more than how many cycles per second it can run
Yes indeed. I don't remember the complexity of factorization on a quantum computer, but I don't think we should worry about the speed being 1MHz or 1GHz. What we should worry about right now is the storage size. We just cannot fit a 2048 bit key into 7 bits of storage. If building such a "large" quantum computer eventually suceeds, we will have far worse worries than Microsoft, X-Box, and Palladium.
Ok so I havent passed the discrete matchs exam yet, but doesn't numbers that are divisible by 5 end in either 0 or 5 (thus beeing eliminated already)?
Yes, that was also what was said.
Why not numbers that end in 0,2,4,6,8 AND numbers where the total sum of the individual digits is divisible by 3?
You can do almost that. In fact you wouldn't be looking on a decimal representation, but rather a binary representation. So computing the last digit of a decimal representation would take som computation time. Unless you are smart and keep the last digit in a seperate variable. Just adding one to a byte and starting from zero every time you reach ten would be a lot faster than computing the last digit every time.
But in fact we can be even smarter than that. Why keep the last digit of a base 10 representation? It would be smarter to save the last digit of the number in a higher base, because there will be a larger fraction of digits that can be ruled out immediately. For example the case of divisibility by three would be trivial if we kept the last digit of a base 30 representation rather than base 10. I'd even go as far as base 210, which happens to be the product of the first four primes. Only 48 of the 210 possibilities would have to be tested. That has cut the number of cases down to 23%
But we can be even smarter. Why even add only one each time, given the last digit we already know how many times we will have to add one before reaching the next candidate. So rather just keep an array telling us how much to add each time, then we don't even have to remember the last digit, but just an index in an array with 48 bytes.
But why stop at base 210. Take another two primes and make the base 30030, only 5760 of those would have to be tested. So we would be down to 19% of the original search space. But here we notice that increasing the array by a factor 120 only saved us a few percent. And in fact each time we add another prime the size of the array grows faster and faster while the gain in reduction of search space gets smaller. So as soon as we hit the size of the L1 cache, we will probably gain no more. All in all we might have cut the search space by a factor four, maybe five or six, but no more.
But for a problem of exponential complexity cutting the time usage by a constant factor doesn't really help. All our efforts to avoid candidates that are obviously not prime can be defeated by just using a key five bits larger. Those five bits would be enough to make the problem harder than before we used those tricks. And the price for those five bits in normal use of the key is close to nothing. In fact they already did add another five bits and then again some more.
But we can be even smarter, first of all we obviously only have to verify divisors up to the square root of the number. Of course we'd already just do that, because we would be starting from zero and going upwards.
But we can be even smarter, because trial and error is absolutely not the fastest way to factorize products of large primes. Other techniques like quadratic sieve would be a lot faster. And then all our smart ways to avoid obviously nonprimes is not usefull at all. The way to actually factorize is completely different.
So why do you think it's ok to do it to the XBox
Because the purpose of doing it is to achieve interoperability between Linux and the X-Box. Had the purpose been to make pirate copies or something similar, it would have been an entirely different matter.
Like, is there anything to prevent Microsoft from just randomly calling up the project with a bunch of dummy clients that submit the REAL x-box key a couple times to the "i've checked this and it's not the key" list?
Hurry up, mod parent down before anybody from Microsoft see it.
He could hire 4 engineers for a year to do that.
But that would not give him any guarantee of reaching the result. By putting up the reward he will only have to pay if he gets what he wants.
The Neo Project recently updated its client so users can use free processor cycles to try and crack the private key that Microsoft uses to sign Xbox software.
Unfortunately the server apears to be slashdotted. Let's hope that just means a lot of people want to help with that task. This of course makes me want to ask about the legality of doing this. Does people risk getting sued by downloading the client?
The Oxygen in earths atmosphere came from the earliest living organisms.
It has always been my understanding that the first life used oxygen rather than producing it. Life forms capable of producing oxygen came shortly after.
has been established for billions of years
Had you said millions I would have believed you.
my hamster generates enough power at night to keep the BIOS settings.
That sounds like an unreliable solution. What you need is a RAIH (Redundant Array of Inexpensive Hamsters).
die("Should never reach this far");
I would receive that error about once a month...
How?
That doesn't work well because I get too many hits like
That is not a problem with grep, it reports those because the word ant really is there. To avoid that use the grep command on a set of sources which has not yet been used for a compilation, or that has been compiled without that word in the path or machine name.
Does anyone know how to do grep for "ant" (exact word by itself)? :)
Lots of answers, but most of them not really good. How about reading the man page. After doing that, I came up with this:
grep -ir "\<ant\>" *
The use of -i is simpler than specifying every letter could be upper or lower case. And the use of spaces at each end of the word misses those cases where where other chars are used at the word boundaries. Then better use the grep builtin feature to indicate start and end of a word.
egrep -ir "windows should be destroyed" *
In fact you will find that in the Linux sources. But the context will give it a different meaning than you might expect:
scripts/tkgen.c: * We are checking which windows should be destroyed and which are
which probably means "scary".
The most scary one I ever got was on a RH7.1 system. After upgrading a lot of RPM packages, I sudenly started getting the "Self-destruct in 5 seconds. Have a nice day..." message. That was one of the error messages I was hoping never to see.
"//I wonder why this works"?
:-)
I couldn't find exactly that comment. This is as close as I can get:
grep -ir 'wonder.*work' linux
linux/net/ipv4/arp.c: I wonder why people believe that they work.
linux/drivers/acorn/block/fd1772.c: * code - I wonder if it will still work... No
linux/drivers/nubus/nubus.c: * I wonder how the CRC is meant to work -
"we can never create fractals with inifinite dimension" Really!? Watch me!
You missed the point. You can define an infinitely dimensional fractal in an infinitely dimensional space. But it can never exist in our finite dimensional space. (Let's not start an argument about the actual number of dimensions of our space. We all know there are at least three, and I think nobody believes there are more than ten.)
Fractal implies a geometric pattern that is repeated at every scale and so cannot be represented by classical geometry.
And this is exactly where the snowflake breaks down. You might find the same patterns in a snowflake at many different scales, but when you go to smaller and smaller scales, eventually you will reach the molocular scale at which the pattern changes.
A snowflake is not a perfect fractal. If we could really create fractal physical objects, I have ideas for applications in computers. You wouldn't imagine the processing power of a fractal CPU.
Anything that can be represented as a (or a finite number of) point could be considered to have a dimension of zero.
That is true, but in fact you can even have an infinite number of points and still have a dimension of zero.
There are different kinds of infinity. The set of integers is what we call a countable infinity, while the set of real numbers is what we call an uncountable infinity. There are even uncountable infinites that are infinitely larger than the real numbers. In fact it is a suprprise once you realize how large infinities can become compared to the quite small infinity of the integers. In fact the inifinity of the integers is the smallest infinity you can find.
A set of countable infinity has dimension zero, anything with dimention larger than zero is an uncountable infinity same size as the real numbers. Wether the dimension is 0.1 or 3.0 the number of points will be exactly the same. And that is the case for any finite number of dimensions. And AFAIK no fractal can be of higher dimension than the space in which it exists, so we can never create fractals with inifinite dimension.
The parent post dares to speak the truth about the lack of quality about X Windows!
Most people criticizing X Windows don't know what they are talking about. Usually the talk is about the user interface which is in fact implemented by something like KDE or Gnome, or even simpler stuff like a plain window manager. Sure I don't think neither KDE nor Gnome is perfect yet. They are still too unstable. And in every revision the interface is improved in some way while it gets worse in other ways. Why can't I just configure the interface to get the best from every version? And finally they are way too much bloat, they gets slower and slower as I upgrade to newer versions.
But if we take the talk back to X Windows that is a really good design. Network transparancy works like a charm. It is portable, interoperable, and extensible. What more can you ask for? Surely XFree86 is not always perfectly stable, but it never caused me enough trouble to make me care enough about it to track down the problems. All I know is that once in a while it crashes on VC switching, but except from this minor glitch, it has been working just fine since I upgraded to RH7.2.
"Filesystem? I don't need no stinkin filesystem!"
No matter what the layer above should look like, it is nice to have a filesystem below. You can do stuff like making backup copies. Take a copy of the files belonging to one particular application. Move files. Fix problems when something goes wrong.
Forking files can be accomplished without copying a file.
Versioning should not conceptually be built into a filesystem. I find it far too complicated. A filesystem should be conceptually as simple as possible (but no simpler).
However, I don't see why anybody would come up with a hierachical file system, unless they were accomidating for hardware limitations.
I don't get it. Back in DOS 1.x a flat filesystem was being used. In DOS 2.x this was extended into a hierarchical filesystem. That was not due to any kind of hardware limitations, in fact the growing media sizes was probably one of the reasons to want a way to organize data. In fact the hierarchical filesystem was one of the most important improvements in DOS 2.x, the fact that it was implemented in a clumsy way was certainly not due to a bad idea, but rather because that way it could be slightly more backward compatible. That this clumsy directory implementation was allowed to exist all the way until W95 just proves a certain companys incompetence, other systems has had far better hierarchical filesystems.
Placing files somewhere within a huge directory tree is just too darn complicated.
The hierarchical filesystems were introduced to make things simpler. And it certainly did. Some applications implement some complicated stuff on top of that, but that is certainly not due to the hierarchical filesystems.
Why should the same file not exist in multiple directories?
In most of the hierarchical filesystems I know a file can actually exist in multiple directories. In fact FAT happens to be the only filesystem I know without that feature.
Why should copies of a file exist?
For backups, or simply because you want to work on a copy rather than the original. Then again I'd like to see filesystems implementing efficient copying of files by the use of CoW, but that must be transparent to the overlying applications.
Everything, including advanced security policies (more advanced than what is currently possible)
Do we want more complicated security policies? They can be a threat to security because of implementation bugs or incorrect usage. There are few situations that cannot be covered with the user, group, other attribute concept. But in fact more complicated security policies are being built into hierarchical filesystems, so we don't need a keyword system for that.
Finally it must be noted that I don't dislike the idea of a keyword based approach to files, I just don't want to give up the hierarchical filesystem to achieve it. A keyword approach built on top of a hierarchical filesystem sounds like a great idea to me. Built as an extension to a hierarchical filesystem also is an option, though care must be taken not to break too many existing applications. You don't want to loose your metadata because your backup utility saves only the files without the keywords.
Also note that I don't say a filesystem must be simple, only that it should implement a simple concept. A simple interface between applications and filesystem is important to me. But the underlying filesystem implementation can be arbitrary complex, and sometimes that is a good idea. FAT is a perfect example of a too primitive implementation.
To be honest, 'dd' is not a Linux utility. Various *nixes used it before Linux was even started.
In fact dd is even overkill for this purpose. The same could be achieved by cat or something even simpler. This task is so simple that we shouldn't really care how they did it. I could have written a 42 line Turbo Pascal program under DOS that could do it.
On top of that, if an app is not made 64 bit ready, why would you need a CPU that is?
The most important piece of software to get upgraded to 64 bit code is not actually an application, but rather the OS kernel you are using. AFAIK the x86-64 architecture is so nicely designed that a 64 bit OS can run both old 32 bit programs and 64 bit programs in a multitasking environment. And even 32 bit applications can get a little benefit from the change by getting the OS outside the 32 bit address range. Thus they can get access to 4GB of address space compared to the 2 or 3GB they would usually have.
A lot more applications will benefit from a recompilation, which might not even require a change of the source code. There are places where 64 bit calculations are already needed on the current 32 bit architectures. There might not be a lot of people knowing it, but in fact we have had the need for 64 bit architectures for many years. I'm looking forward for the new AMD chips.
only surf Slashdot at +4 and above.
In fact +1 and above is good enough to avoid such rude comments.
Yup it's illegal, but only because of the DMCA.
I don't think the DMCA applies to me.
The illegal part is disabling the copy protection.
I didn't disable any copy protection. The protection just didn't work on all my drives.