Actually I have had a look at the architecture of Gnutella and Freenet. One point I remember is that both systems go to some trouble to obscure the original origin of a file - so if you request a file , you don't usually know which node it originated from and neither do the nodes between you and the source. This lack of knowledge means that the route taken by a file can be longer and more roundabout than it needs to be, using several times as much bandwidth in total. There is no technical reason for this subterfuge, it is only there to make it more difficult for the RIAA and other bad guys to trace who is providing files.
You could add a special 'legitimate' mode for Freenet or other file sharing systems, where the source and destination are known to each other and can calculate the optimum route. But I think that an explicit design goal was to make it difficult for observers to see what is going on.
The entire clue-stick is that you're taking a bunch of *peers*, each hosting their own share, and it'll appear as one big "server" you can search.
But the problems you describe apply just as much to files other than music. What's the difficulty with using web pages, search engines and hyperlinks? Why is it that for family photos or blogs or non-warez software people can put up web sites and get them indexed - but suddenly when they start distributing other kinds of files they need to have P2P with the justification that it makes things easier to find? I'm sure it is just a coincidence that these 'hard-to-find' file types happen to be the same ones associated with copyright infringement.
I wasn't suggesting some big central server with all users' files on it, any more than I'd suggest moving the World Wide Web onto a single server. I asked why can't these students put the files up on web pages? Their universities provide personal web space surely?
It's not a question of whether Google is 'good' or 'evil'. It's a question of whether the patent office was right to grant this patent, and whether a patent system that includes software is of greater economic benefit to society than one that does not.
You can ask: if patents on computer programs were not available, would Google have developed their idea anyway?
Because if the files you were exchanging were legitimate, you wouldn't need to use peer-to-peer systems like Gnutella, Freenet etc etc, which add a lot of inefficiency just to make it harder to find the source of a file. If what you are sending weren't in some way illegal, you would just stick it on a web page.
There is the possibility that peer-to-peer can prevent Slashdotting by using bandwidth in different places rather than all at a central server, but I find it hard to imagine that students using P2P are doing so out of the goodness of their hearts to cut their university's bandwidth bill.
NewsForge:The problem -- to some -- with GPL-licensed software is the fact that anyone can use it. How would you feel seeing some of your code used by Saddam Hussein's people. Or Osama bin Laden's? Or by the Chinese government to help prevent full Internet access?
Oh, sure, if you put a clause in your licence saying 'not for use by terrorists', that'll fix it.
Please Do: Always put the trademark SPAM in all capital letters. Follow SPAM with "Luncheon Meat" or other descriptor. Remember, a trademark is a formal adjective and as such, should always be followed by a noun.
So in this case, it would seem that Google have a claim to 'Google(tm) Web Searches' or 'the Google(tm) search engine', but not the verb 'to google'.
I never used the verb 'to google' before now, but after this heavy-handed lawyering I just might start.
Aren't there programs which fetch web pages from Outlook's web interface and act as an IMAP server? I don't know of any, it just seems that they ought to exist.
BTW - it could be worse - they could be using Notes.
I think you need to distinguish between things that interest OS programmers (memory management, interrupts, etc) and stuff that the compiler has to worry about, which is the instruction set itself.
Average instruction length isn't the whole picture, the number of instructions you need to perform a given task also has an impact.
Now the idea of CISC processors was that many complex operations could be coded with a single instruction, making the code more compact. And this may have been the case for architectures like VAX. But on x86, which has not so much been designed as grown by a series of extensions from the 8086, I don't believe that the instructions available are a particularly good fit for the programs you want to run. In particular, with only four registers visible to the programmer there will be a lot of code moving stuff into and out of memory. Even if this is magically translated inside the processor to use more than four registers, it still doesn't make for good code density.
I am really just speculating here, I have only very rudimentary knowledge of i386 assembler and of ARM assembler, and a vague feeling that ARM is more concise (even if every instruction takes a whole word). The larger number of registers helps, as does the fact that every instruction can be made conditional (predication).
If you say that x86 is famously compact you may be right. Still, if you set out from scratch to design a compact bytecode for CPUs to interpret, I am sure it would look nothing like x86.
To find the answer you'd need to compile a large C program for various architectures and see which binary was smallest. (Try this with both optimize-for-speed and optimize-for-size I think.)
It would need some payment system so you pay the other devices a tiny amount for successfully delivered packets, and they agree to compensate you for any that are dropped.
(Well it wouldn't _need_ that, a simple trust-everyone system will be good enough to start with, but it would be kewl. And promote commercial-yet-decentralized growth of wireless networks.)
'x86 is a nice, compact, widely supported bytecode.'
What are you smoking? It's widely supported, yes, and it might or might not be compact (myself, I would guess not, even RISC chips like the ARM/XScale have more compact code), but 'nice'?
Well, many people already have 4Gb (four gigabits), it's 4 *Gbyte* which is the interesting barrier. I don't mean to be pedantic but when you are talking about memory sizes it's important to get these things right.
(Some people advocate using 'b' to mean byte or octet but IMHO they are Wrong. I think I am with the majority in saying that 'b' abbreviates 'bit', the smallest whole unit of information.)
I'm familiar with VNC but I would prefer to use plain X if possible - VNC seems like the low-budget option somehow (only full screen display is possible, no cut and paste, and other things). But in the end it might come down to speed. Which is more usable over a modem link: X with some extension like lbx, or VNC with some form of compression?
WTF? How do you propose measuring the damage caused by, say, a hurricane, other than in monetary terms?
We're not talking about saving whales here, or preserving Antarctic wildlife, or even saving a site of natural beauty. All of those are things that can't be expressed just as an amount of money. But natural disasters, in Europe, tend not to kill anybody; rather, their cost is the damage they do to property and the economy. You say that the damage caused by the floods will cost X amount to put right, and the loss of production is Y.
It's totally legitimate to measure these things in monetary terms because economic damage is the only real kind of damage these disasters cause (at least in Europe, which is what the figure refers to). They don't damage wildlife (in the long term) or destroy an unspoilt landscape or do many of the other things for which you would have to resort to value judgements.
It's an odd day when Slashdot messages criticize quantitative statements which have a clear meaning and are independently verifiable, asking instead for generalizations and handwaving. If a government instead issued a report saying 'we are switching to renewable energy because it's obviously better and, like, will someone please think of the children', would that meet with your approval?
Well, I'd only want to run a window manager and xterm locally anyway... maybe not even xterm. I am looking for a thin X client on a floppy. I chose XF86_VGA16 as an example, you could equally pick a server for your particular graphics card and it probably wouldn't be much bigger (assuming you don't want hardware 3d).
Slackware used to install off floppies, but by the time of recent releases only the 'a' (base system) and 'n1' (basic networking) disk sets can still do it.
Debian's base system can be installed from floppies, but I don't know if there is a convenient way to install further packages from there.
But since trying Knoppix I've become obsessed with the idea of having nothing important on the local disk. Since I do most of my work over ssh anyway, this is certainly possible. The question is can it be done in a machine with no CD player?
Twenty megabytes for X seems excessive. XF86_VGA16 is about two megs big, libX11.so.6.1 is 800Kbyte. A lightweight window manager would presumably be another 100Kbyte or so. After piping through bzip2 the X server and libX11 come to about 1100Kbyte. Allowing for the window manager and some extra stuff I've forgotten (pixmaps, two or three bitmap fonts in small sizes) it should fit on a floppy formatted to 1920 kilobytes. You would need another floppy for Linux itself of course, and enough RAM to decompress and run from ramdisk.
I have yet to see a distro that is as easy to install as Corel Linux.
Maybe this is cheating, but could I suggest Knoppix? It really _is_ 'Debian for the average Joe', probably more so than Corel, since it requires no installation at all.
(On a slightly related note - can anyone recommend a tiny Linux distribution that runs off floppies? I am hoping to run an X server, icewm, PPP and ssh.)
Well, it looks like a DAS4020 board has 12-bit resolution and so does the BBC Micro (although it might be only 10 bits in practice). The difference comes in sample rates: 20MHz versus 100Hz! So people are not going to be recording any UHF broadcasts through the analogue port. Unless they manage some serious overclocking.
So, can I go out and buy off the shelf suitable hardware to use with GNU Radio? Assuming I have a box with a reasonably fast CPU and a spare PCI slot. The web site seems strangely coy about covering this, unlike most driver sites where they say 'we successfully got working the card XXX from manufacturer YYY, available for $44.50 from ZZZ'.
Do I need an A/D converter, or what? Knowing nothing about electronics, where do I get such a thing? I just threw away my BBC Micro with its built-in 12-bit A/D... was that a mistake?;-)
ELKS might one day be suitable for really tiny devices with 8-bit or 16-bit CPUs, provided the application doesn't need hard real-time. (I presume a kitchen appliance falls into this category.) But nothing much seems to have happened on the project for a while.
Slashdot Mirror
Actually I have had a look at the architecture of Gnutella and Freenet. One point I remember is that both systems go to some trouble to obscure the original origin of a file - so if you request a file , you don't usually know which node it originated from and neither do the nodes between you and the source. This lack of knowledge means that the route taken by a file can be longer and more roundabout than it needs to be, using several times as much bandwidth in total. There is no technical reason for this subterfuge, it is only there to make it more difficult for the RIAA and other bad guys to trace who is providing files.
You could add a special 'legitimate' mode for Freenet or other file sharing systems, where the source and destination are known to each other and can calculate the optimum route. But I think that an explicit design goal was to make it difficult for observers to see what is going on.
But the problems you describe apply just as much to files other than music. What's the difficulty with using web pages, search engines and hyperlinks? Why is it that for family photos or blogs or non-warez software people can put up web sites and get them indexed - but suddenly when they start distributing other kinds of files they need to have P2P with the justification that it makes things easier to find? I'm sure it is just a coincidence that these 'hard-to-find' file types happen to be the same ones associated with copyright infringement.
I wasn't suggesting some big central server with all users' files on it, any more than I'd suggest moving the World Wide Web onto a single server. I asked why can't these students put the files up on web pages? Their universities provide personal web space surely?
It's not a question of whether Google is 'good' or 'evil'. It's a question of whether the patent office was right to grant this patent, and whether a patent system that includes software is of greater economic benefit to society than one that does not.
You can ask: if patents on computer programs were not available, would Google have developed their idea anyway?
Because if the files you were exchanging were legitimate, you wouldn't need to use peer-to-peer systems like Gnutella, Freenet etc etc, which add a lot of inefficiency just to make it harder to find the source of a file. If what you are sending weren't in some way illegal, you would just stick it on a web page.
There is the possibility that peer-to-peer can prevent Slashdotting by using bandwidth in different places rather than all at a central server, but I find it hard to imagine that students using P2P are doing so out of the goodness of their hearts to cut their university's bandwidth bill.
Oh, sure, if you put a clause in your licence saying 'not for use by terrorists', that'll fix it.
I can't wait for the anticipatory scheduler to be used in a stable kernel release... I'm really looking forward to it.
So in this case, it would seem that Google have a claim to 'Google(tm) Web Searches' or 'the Google(tm) search engine', but not the verb 'to google'.
I never used the verb 'to google' before now, but after this heavy-handed lawyering I just might start.
Aren't there programs which fetch web pages from Outlook's web interface and act as an IMAP server? I don't know of any, it just seems that they ought to exist.
BTW - it could be worse - they could be using Notes.
Perhaps this will be the first really good reason to port Wine to Windows.
I think you need to distinguish between things that interest OS programmers (memory management, interrupts, etc) and stuff that the compiler has to worry about, which is the instruction set itself.
Average instruction length isn't the whole picture, the number of instructions you need to perform a given task also has an impact.
Now the idea of CISC processors was that many complex operations could be coded with a single instruction, making the code more compact. And this may have been the case for architectures like VAX. But on x86, which has not so much been designed as grown by a series of extensions from the 8086, I don't believe that the instructions available are a particularly good fit for the programs you want to run. In particular, with only four registers visible to the programmer there will be a lot of code moving stuff into and out of memory. Even if this is magically translated inside the processor to use more than four registers, it still doesn't make for good code density.
I am really just speculating here, I have only very rudimentary knowledge of i386 assembler and of ARM assembler, and a vague feeling that ARM is more concise (even if every instruction takes a whole word). The larger number of registers helps, as does the fact that every instruction can be made conditional (predication).
If you say that x86 is famously compact you may be right. Still, if you set out from scratch to design a compact bytecode for CPUs to interpret, I am sure it would look nothing like x86.
To find the answer you'd need to compile a large C program for various architectures and see which binary was smallest. (Try this with both optimize-for-speed and optimize-for-size I think.)
It would need some payment system so you pay the other devices a tiny amount for successfully delivered packets, and they agree to compensate you for any that are dropped.
(Well it wouldn't _need_ that, a simple trust-everyone system will be good enough to start with, but it would be kewl. And promote commercial-yet-decentralized growth of wireless networks.)
You can do a *network install* of pretty much anything using one or two floppy disks. The question is, what can you install from floppies?
'x86 is a nice, compact, widely supported bytecode.'
What are you smoking? It's widely supported, yes, and it might or might not be compact (myself, I would guess not, even RISC chips like the ARM/XScale have more compact code), but 'nice'?
Well, many people already have 4Gb (four gigabits), it's 4 *Gbyte* which is the interesting barrier. I don't mean to be pedantic but when you are talking about memory sizes it's important to get these things right.
(Some people advocate using 'b' to mean byte or octet but IMHO they are Wrong. I think I am with the majority in saying that 'b' abbreviates 'bit', the smallest whole unit of information.)
I'm familiar with VNC but I would prefer to use plain X if possible - VNC seems like the low-budget option somehow (only full screen display is possible, no cut and paste, and other things). But in the end it might come down to speed. Which is more usable over a modem link: X with some extension like lbx, or VNC with some form of compression?
WTF? How do you propose measuring the damage caused by, say, a hurricane, other than in monetary terms?
We're not talking about saving whales here, or preserving Antarctic wildlife, or even saving a site of natural beauty. All of those are things that can't be expressed just as an amount of money. But natural disasters, in Europe, tend not to kill anybody; rather, their cost is the damage they do to property and the economy. You say that the damage caused by the floods will cost X amount to put right, and the loss of production is Y.
It's totally legitimate to measure these things in monetary terms because economic damage is the only real kind of damage these disasters cause (at least in Europe, which is what the figure refers to). They don't damage wildlife (in the long term) or destroy an unspoilt landscape or do many of the other things for which you would have to resort to value judgements.
It's an odd day when Slashdot messages criticize quantitative statements which have a clear meaning and are independently verifiable, asking instead for generalizations and handwaving. If a government instead issued a report saying 'we are switching to renewable energy because it's obviously better and, like, will someone please think of the children', would that meet with your approval?
Well, I'd only want to run a window manager and xterm locally anyway... maybe not even xterm. I am looking for a thin X client on a floppy. I chose XF86_VGA16 as an example, you could equally pick a server for your particular graphics card and it probably wouldn't be much bigger (assuming you don't want hardware 3d).
Slackware used to install off floppies, but by the time of recent releases only the 'a' (base system) and 'n1' (basic networking) disk sets can still do it.
Debian's base system can be installed from floppies, but I don't know if there is a convenient way to install further packages from there.
But since trying Knoppix I've become obsessed with the idea of having nothing important on the local disk. Since I do most of my work over ssh anyway, this is certainly possible. The question is can it be done in a machine with no CD player?
Twenty megabytes for X seems excessive. XF86_VGA16 is about two megs big, libX11.so.6.1 is 800Kbyte. A lightweight window manager would presumably be another 100Kbyte or so. After piping through bzip2 the X server and libX11 come to about 1100Kbyte. Allowing for the window manager and some extra stuff I've forgotten (pixmaps, two or three bitmap fonts in small sizes) it should fit on a floppy formatted to 1920 kilobytes. You would need another floppy for Linux itself of course, and enough RAM to decompress and run from ramdisk.
Maybe this is cheating, but could I suggest Knoppix? It really _is_ 'Debian for the average Joe', probably more so than Corel, since it requires no installation at all.
(On a slightly related note - can anyone recommend a tiny Linux distribution that runs off floppies? I am hoping to run an X server, icewm, PPP and ssh.)
Well, it looks like a DAS4020 board has 12-bit resolution and so does the BBC Micro (although it might be only 10 bits in practice). The difference comes in sample rates: 20MHz versus 100Hz! So people are not going to be recording any UHF broadcasts through the analogue port. Unless they manage some serious overclocking.
So, can I go out and buy off the shelf suitable hardware to use with GNU Radio? Assuming I have a box with a reasonably fast CPU and a spare PCI slot. The web site seems strangely coy about covering this, unlike most driver sites where they say 'we successfully got working the card XXX from manufacturer YYY, available for $44.50 from ZZZ'.
;-)
Do I need an A/D converter, or what? Knowing nothing about electronics, where do I get such a thing? I just threw away my BBC Micro with its built-in 12-bit A/D... was that a mistake?
ELKS might one day be suitable for really tiny devices with 8-bit or 16-bit CPUs, provided the application doesn't need hard real-time. (I presume a kitchen appliance falls into this category.) But nothing much seems to have happened on the project for a while.