I am a Linux user since the times you had to get a wagon load of disks from somwhere to install. So I am pretty familliar with partitioning disks.
That said, I find that the Debian installer is the worst partitioning interface I have ever seen. I don't know why, but it confuses be a lot. I find using plain fdisk easier. When I use it, I alsways have the feeling that I may have selected the worng options. Somehow the partitioning tool isn't able to clearly show me the state of the partitionings.
Well, I am used to do this stuff, but I can imagine that even non-stupid users will have some big problems with the installer.
>I think the biggest win is the ease of finding
>files. Theoretically this would allow file
>information to propagate, and I tihnk the most
>interesting problem that will be faced is
>stability. How do you make effective searches
>that do not loop around the network?
The CS research has concentrated on different types of DHTs (distributed hash tables).
The idea is that you don't search for a filename, but for a hash of the file or the filename.
Hashing allowes a good way of distributing the load. Each node in the network is assigned to an approximately equal share of the search space and stored the hashes in this part.
A search can usually be completed in O(log N) steps, where N is the number of nodes in the network.
Hit Google with these keyowords: DHT, Chors, Tapestry, Pastry, p-Grid, CAN.
And you will find the research papers.
Problem of DHTs: You can query only for hash equality or a hash-prefix-equality.
One has to implement some meta structure to be able to search for names with some kind of pattern matching.
I am myself designing networks for storing geometrical keys that allow search by testing for intersection with an (geometrical) query key.
Slashdot Mirror
I am a Linux user since the times you had to get a wagon load of disks from somwhere to install. So I am pretty familliar with partitioning disks.
That said, I find that the Debian installer is the worst partitioning interface I have ever seen. I don't know why, but it confuses be a lot. I find using plain fdisk easier. When I use it, I alsways have the feeling that I may have selected the worng options. Somehow the partitioning tool isn't able to clearly show me the state of the partitionings.
Well, I am used to do this stuff, but I can imagine that even non-stupid users will have some big problems with the installer.
>I think the biggest win is the ease of finding >files. Theoretically this would allow file >information to propagate, and I tihnk the most >interesting problem that will be faced is >stability. How do you make effective searches >that do not loop around the network? The CS research has concentrated on different types of DHTs (distributed hash tables). The idea is that you don't search for a filename, but for a hash of the file or the filename. Hashing allowes a good way of distributing the load. Each node in the network is assigned to an approximately equal share of the search space and stored the hashes in this part. A search can usually be completed in O(log N) steps, where N is the number of nodes in the network. Hit Google with these keyowords: DHT, Chors, Tapestry, Pastry, p-Grid, CAN. And you will find the research papers. Problem of DHTs: You can query only for hash equality or a hash-prefix-equality. One has to implement some meta structure to be able to search for names with some kind of pattern matching. I am myself designing networks for storing geometrical keys that allow search by testing for intersection with an (geometrical) query key.