So what if it's an attempt by the BBC to justify its own existence and the licence fee? If they are trying to do something useful (and something that commercial broadcasters would find difficult), good luck to them.
I'm going to wait and see what really happens, however. A complete archive of all TV and radio output since 1922 (or at least what is left) would be great, but it might not turn out like that. The BBC gets a small proportion of its income from the bloodsucking BBC Worldwide whose job is to overcharge American stations for Dr Who episodes and sell tacky merchandise; they might be frightened of doing anything to jeopardize that, even though the income is tiny compared to the licence fee paid by the public. Let's hope the BBC puts the public's interests first.
Yes of course, foot-shooting-possibility is not in itself a reason to exclude 'advanced' features. But if you intend to ignore one of the main purposes of a package manager - to track dependencies and make sure that no installation or uninstallation breaks other packages - then perhaps it would be better to do without one altogether - it's simple to run rpm2cpio and then install that.
The feature you suggest would be quite an extension to RPM (if it has to know about shared objects, Perl modules, header files, etc etc) and only vaguely related to its existing purpose, which is to install files and track them using a database. So I think it might better go into a separate program. One approach would be to look at the filesystem, see that libfred.so.1 exists, and create a 'package' from that, marking the files in RPM's database. Then RPM would be able to take the package into account when calculating dependencies and perhaps even remove or upgrade it.
But this is all a big kludge compared to just installing an RPM package in the first place. I think the best improvement would be to make it easier for intermediate users (those who build packages from source, but aren't RPM gurus or sysadmins for large networks) to create their own packages and share them.
As far as I know an RPM can either list a whole package, or an individual file. It's up to the package builder. Often library dependencies are stated as files, since they're found automatically.
However the problem you mention could easily be resolved by keeping a mapping of which files are available in which package, so the computer knows that libfoo.so.1 comes from foolib-1.3.i386.rpm. I think that many tools like apt and urpmi do this already.
What you suggest is quite a big change to the way RPM (or pretty much any package manager) works. Never mind the special case of Perl modules, you're saying that files installed outside the package manager's control should be usable to satisfy dependencies.
This might be possible, but one obvious problem is what happens when those files are later removed or replaced. For example, you have fred-1.0 installed by hand and install an RPM package of jim-0.1, which depends on fred = 1.0. Well, perhaps RPM could look at the files already on the system and figure out that something looking rather like fred-1.0 is already there. But then if you upgrade fred to version 2.0, which is not quite compatible, you'll break the installed jim package with no warning. OTOH if you use RPM as it is currently intended to be used, you'd get warned when trying to upgrade fred that the jim package depends on a particular version - and if you use a tool like urpmi or apt, a new version of jim could be installed at the same time so that everything keeps working.
I agree that having to use --nodeps is annoying and dangerous. But the best answer, IMHO, is to work with the package manager rather than against it, and make your Perl modules etc. into RPM packages as well. Now this is sometimes easier said than done; we need more automatic tools like cpanflute to package things (or better awareness of the existing ones). Similarly it would be useful if Red Hat could bring back the 'contrib' area, or if the various third party RPM sites could get together and make some mega-site which indexes practically every package you could ever want.
My dad got a Nigerian scam which did not appear to be crooked, which is to say it didn't appeal to the victim as an opportunity to get on the inside of some crooked scheme. It said that a rich clergyman had died and left some money in his will - and some of it was to go to the author of a book he had read. I dunno, maybe they try the same scam with all authors. Anyway the response was 'please deal with my solicitor' and the scammers weren't heard from again.
At the time I have to admit I thought it was probably genuine, since it was so different from the normal 419 scam material. But I did advise against sending any headed notepaper or bank account details.
Strange - I've met nobody who doesn't pronounce the G. Apart from one guy who spelled out 'G-N-U' every time; it was embarassing watching him try to ask RMS a question at some public speaking event.
Seems like bloody slow progress to me, given that Linux has been around in a usable form since 1993 or so and that in 2008 it will be about 17 years old. Linux had a usable desktop in 1994, or at least a lot more usable than Windows back then. Still I suppose this process is social rather than technical.
Sorry, what I meant to say was that there is only one instance of any particular electricity grid. Of course there are many different grids across the world.
The reason why security through obscurity may be appropriate for elecricity grids but not for computer programs is simple: there is only one electricity grid, but a program can have millions of copies, all alike. Find the flaw in one of the copies and you can crack all of them. With the ease of making copies and the possibility to fully inspect them (using a debugger or just reading through the program code), you cannot realistically hope to stop bad guys finding out the flaws. So you just have to fix them.
However it's impossible to take a copy of the electricity grid, and presumably very difficult for a bad guy to examine the whole system at once and search for flaws. Also, physical systems don't suffer from 'security holes' in quite the same way as software: a buffer overflow may compromise the whole application but is easy to fix when found, whereas a power cable connecting two substations might be very expensive to 'fix' and make sabotage-proof by posting armed guards along it or burying it or whatever.
In short, it's another instance of the general rule that is often ignored on Slashdot: software is different from hardware. What makes sense for information doesn't always make sense for physical objects, and vice versa.
Yes, but you are assuming a particular language used for the descriptions. I can also show that 61070941271139577504711647465813663675921309 412553 1498031084978534953383702400017179 is not random by giving a shorter description of it: 'the number mentioned in kasperd's Slashdot post'.
Besides, it's not clear what correspondence your definition has with the randomness of the source. A random source uniformly distributed in [0, 1000000) is just as likely to produce 418261 as to produce 999999. So any criterion you applied to an individual number would tell you nothing about the randomness of the source. Unless you assume that possible non-random sources have a particular tendency to produce 999999 more or less often than other numbers.
When working with K. complexity in general the universal computer doesn't matter much, but if you try to pick a particular number or message out of the air and work out the complexity of that it does matter. You could define a Turing machine with one extra instruction that prints out the complete works of Shakespeare, and then the complexity of that particular string would be very low. But such a special machine would not help you at all if trying to reduce the complexity of strings in general. The point is that you have to be very careful when picking a single number and trying to talk about complexity or randomness after the fact. Normally you'd worry about these things for numbers to be drawn from a particular distribution, not just one number you picked out of a hat (with also the liberty of picking a particular computational model out of a hat).
A number is not 'random'. There is no test you can apply to determine that 25 is random, while 44 is not. Randomness is not a property of individual numbers, it is a property of the number generator or source.
So when people say 'a random number' they really mean 'a number drawn from a random source'.
You're talking about Kolmogorov complexity, I think - the complexity of some data is the length of its shortest description. But even there you have to agree what language the description will be in. You could define a language where 18282822 is represented by the symbol 'A' and any other number is represented by itself.
Huh? Pseudo-random numbers are those that follow a sequence you can predict, if you know how the generator works and what its internal state is.
Random numbers are those you cannot predict. I'm no physicist, but I think quantum theory says that many natural events occur randomly - that is, there's no way of knowing which slit a photon will 'choose' to go through, and it isn't particularly 'based on' anything except a 50/50 probability.
All numbers generated are based on something, so they'll never be truly random.
So then if all current sources of numbers are not random, what _would_ meet your definition of the word 'random'?
But you are clearly not Abraham Lincoln anyway; a picture of your face doesn't change anything. OK, it would deal with the wrong sex or an obviously wrong age, but wouldn't help that much. Also, face matching doesn't give any easy way to stop a person creating several different accounts (of which all but one are false, or maybe all) - unless computer face recognition becomes very reliable, and by that time it will probably be possible to fake a video stream of a human face.
Personally I don't have a problem with being able to do something if I choose to. If rental stores require identity, and I don't like it, I will choose not to do business with them. I don't know what you mean by saying that a rental store is 'not supposed to' require SSN and phone number; as far as I know it's entirely between you and them what terms you want to agree for renting a video.
If there were only one rental store, and you were forced to use it, you might have a point. Otherwise, it's just market decisionmaking (if providing id really were unpopular with most people then rental stores requiring it would not stay in business). This is just the same argument as saying that it should be forbidden by law to pay more than $10 to rent a movie, since if there were a way to do it, some businesses might start requiring it.
Once you start taking into account crackers breaking into systems and copying files or changing them, pretty much any computer security system breaks down. So this is no fault of digital signatures. I agree that widespread use, for important (read: money) applications, would probably have to wait until the day when the average PC is secure enough to be trusted. That day is probably a long way off.
I think that passports are a reasonably good way of proving identity; 99% good enough and certainly better than anything else. If it's good enough proof of identity (together with your ATM card) to withdraw large sums of cash over the counter at a bank, then it's good enough for most online applications.
Actually Outlook Express isn't too bad, it seems to have much fewer holes and less cruft than Outlook does. It's just a fairly boring Windows mail client that connects to a POP3 or IMAP server.
Slashdot readers take note: this is Outlook Express that's being discontinued, not Outlook. The two are about as related as Javascript and Java.
It's 2003. Is there really no reliable way to electronically identify oneself, so that you can prove you are a person with the name and age given?
It would make sense for passports (as in the funny booklet thing you have to take with you when travelling, for some obscure reason) to include your PGP public key. Then the passport itself (or at least the machine-readable section at the back) can be PGP signed by the government. That way you are able to prove who you are. Messages sent from Friendster or other sites would be encrypted using your public key.
Slashdot Mirror
So what if it's an attempt by the BBC to justify its own existence and the licence fee? If they are trying to do something useful (and something that commercial broadcasters would find difficult), good luck to them.
I'm going to wait and see what really happens, however. A complete archive of all TV and radio output since 1922 (or at least what is left) would be great, but it might not turn out like that. The BBC gets a small proportion of its income from the bloodsucking BBC Worldwide whose job is to overcharge American stations for Dr Who episodes and sell tacky merchandise; they might be frightened of doing anything to jeopardize that, even though the income is tiny compared to the licence fee paid by the public. Let's hope the BBC puts the public's interests first.
Yes of course, foot-shooting-possibility is not in itself a reason to exclude 'advanced' features. But if you intend to ignore one of the main purposes of a package manager - to track dependencies and make sure that no installation or uninstallation breaks other packages - then perhaps it would be better to do without one altogether - it's simple to run rpm2cpio and then install that.
The feature you suggest would be quite an extension to RPM (if it has to know about shared objects, Perl modules, header files, etc etc) and only vaguely related to its existing purpose, which is to install files and track them using a database. So I think it might better go into a separate program. One approach would be to look at the filesystem, see that libfred.so.1 exists, and create a 'package' from that, marking the files in RPM's database. Then RPM would be able to take the package into account when calculating dependencies and perhaps even remove or upgrade it.
But this is all a big kludge compared to just installing an RPM package in the first place. I think the best improvement would be to make it easier for intermediate users (those who build packages from source, but aren't RPM gurus or sysadmins for large networks) to create their own packages and share them.
Bah. Elite had that in 1984. Two books, in fact!
As far as I know an RPM can either list a whole package, or an individual file. It's up to the package builder. Often library dependencies are stated as files, since they're found automatically.
However the problem you mention could easily be resolved by keeping a mapping of which files are available in which package, so the computer knows that libfoo.so.1 comes from foolib-1.3.i386.rpm. I think that many tools like apt and urpmi do this already.
What you suggest is quite a big change to the way RPM (or pretty much any package manager) works. Never mind the special case of Perl modules, you're saying that files installed outside the package manager's control should be usable to satisfy dependencies.
This might be possible, but one obvious problem is what happens when those files are later removed or replaced. For example, you have fred-1.0 installed by hand and install an RPM package of jim-0.1, which depends on fred = 1.0. Well, perhaps RPM could look at the files already on the system and figure out that something looking rather like fred-1.0 is already there. But then if you upgrade fred to version 2.0, which is not quite compatible, you'll break the installed jim package with no warning. OTOH if you use RPM as it is currently intended to be used, you'd get warned when trying to upgrade fred that the jim package depends on a particular version - and if you use a tool like urpmi or apt, a new version of jim could be installed at the same time so that everything keeps working.
I agree that having to use --nodeps is annoying and dangerous. But the best answer, IMHO, is to work with the package manager rather than against it, and make your Perl modules etc. into RPM packages as well. Now this is sometimes easier said than done; we need more automatic tools like cpanflute to package things (or better awareness of the existing ones). Similarly it would be useful if Red Hat could bring back the 'contrib' area, or if the various third party RPM sites could get together and make some mega-site which indexes practically every package you could ever want.
PLMO wants to play with you!
My dad got a Nigerian scam which did not appear to be crooked, which is to say it didn't appeal to the victim as an opportunity to get on the inside of some crooked scheme. It said that a rich clergyman had died and left some money in his will - and some of it was to go to the author of a book he had read. I dunno, maybe they try the same scam with all authors. Anyway the response was 'please deal with my solicitor' and the scammers weren't heard from again.
At the time I have to admit I thought it was probably genuine, since it was so different from the normal 419 scam material. But I did advise against sending any headed notepaper or bank account details.
Strange - I've met nobody who doesn't pronounce the G. Apart from one guy who spelled out 'G-N-U' every time; it was embarassing watching him try to ask RMS a question at some public speaking event.
Seems like bloody slow progress to me, given that Linux has been around in a usable form since 1993 or so and that in 2008 it will be about 17 years old. Linux had a usable desktop in 1994, or at least a lot more usable than Windows back then. Still I suppose this process is social rather than technical.
Sorry, what I meant to say was that there is only one instance of any particular electricity grid. Of course there are many different grids across the world.
The reason why security through obscurity may be appropriate for elecricity grids but not for computer programs is simple: there is only one electricity grid, but a program can have millions of copies, all alike. Find the flaw in one of the copies and you can crack all of them. With the ease of making copies and the possibility to fully inspect them (using a debugger or just reading through the program code), you cannot realistically hope to stop bad guys finding out the flaws. So you just have to fix them.
However it's impossible to take a copy of the electricity grid, and presumably very difficult for a bad guy to examine the whole system at once and search for flaws. Also, physical systems don't suffer from 'security holes' in quite the same way as software: a buffer overflow may compromise the whole application but is easy to fix when found, whereas a power cable connecting two substations might be very expensive to 'fix' and make sabotage-proof by posting armed guards along it or burying it or whatever.
In short, it's another instance of the general rule that is often ignored on Slashdot: software is different from hardware. What makes sense for information doesn't always make sense for physical objects, and vice versa.
Since the code seems to be mostly direct memory access, CALL, and USR, wouldn't it have made more sense simply to write it in assembly language?
You can use a BASIC dialect that has a built-in assembler and so still get suitably old-school source code.
Who's to say that USB keys will not be made containing a small hard disk?
Yes, but you are assuming a particular language used for the descriptions. I can also show that9 412553 1498031084978534953383702400017179
6107094127113957750471164746581366367592130
is not random by giving a shorter description of it: 'the number mentioned in kasperd's Slashdot post'.
Besides, it's not clear what correspondence your definition has with the randomness of the source. A random source uniformly distributed in [0, 1000000) is just as likely to produce 418261 as to produce 999999. So any criterion you applied to an individual number would tell you nothing about the randomness of the source. Unless you assume that possible non-random sources have a particular tendency to produce 999999 more or less often than other numbers.
When working with K. complexity in general the universal computer doesn't matter much, but if you try to pick a particular number or message out of the air and work out the complexity of that it does matter. You could define a Turing machine with one extra instruction that prints out the complete works of Shakespeare, and then the complexity of that particular string would be very low. But such a special machine would not help you at all if trying to reduce the complexity of strings in general. The point is that you have to be very careful when picking a single number and trying to talk about complexity or randomness after the fact. Normally you'd worry about these things for numbers to be drawn from a particular distribution, not just one number you picked out of a hat (with also the liberty of picking a particular computational model out of a hat).
A number is not 'random'. There is no test you can apply to determine that 25 is random, while 44 is not. Randomness is not a property of individual numbers, it is a property of the number generator or source.
So when people say 'a random number' they really mean 'a number drawn from a random source'.
You're talking about Kolmogorov complexity, I think - the complexity of some data is the length of its shortest description. But even there you have to agree what language the description will be in. You could define a language where 18282822 is represented by the symbol 'A' and any other number is represented by itself.
Random numbers are those you cannot predict. I'm no physicist, but I think quantum theory says that many natural events occur randomly - that is, there's no way of knowing which slit a photon will 'choose' to go through, and it isn't particularly 'based on' anything except a 50/50 probability.
So then if all current sources of numbers are not random, what _would_ meet your definition of the word 'random'?
But you are clearly not Abraham Lincoln anyway; a picture of your face doesn't change anything. OK, it would deal with the wrong sex or an obviously wrong age, but wouldn't help that much. Also, face matching doesn't give any easy way to stop a person creating several different accounts (of which all but one are false, or maybe all) - unless computer face recognition becomes very reliable, and by that time it will probably be possible to fake a video stream of a human face.
Personally I don't have a problem with being able to do something if I choose to. If rental stores require identity, and I don't like it, I will choose not to do business with them. I don't know what you mean by saying that a rental store is 'not supposed to' require SSN and phone number; as far as I know it's entirely between you and them what terms you want to agree for renting a video.
If there were only one rental store, and you were forced to use it, you might have a point. Otherwise, it's just market decisionmaking (if providing id really were unpopular with most people then rental stores requiring it would not stay in business). This is just the same argument as saying that it should be forbidden by law to pay more than $10 to rent a movie, since if there were a way to do it, some businesses might start requiring it.
Once you start taking into account crackers breaking into systems and copying files or changing them, pretty much any computer security system breaks down. So this is no fault of digital signatures. I agree that widespread use, for important (read: money) applications, would probably have to wait until the day when the average PC is secure enough to be trusted. That day is probably a long way off.
I think that passports are a reasonably good way of proving identity; 99% good enough and certainly better than anything else. If it's good enough proof of identity (together with your ATM card) to withdraw large sums of cash over the counter at a bank, then it's good enough for most online applications.
But how do you match a face to a person's name and age? Your system wouldn't stop people registering as 'Abraham Lincoln'.
Actually Outlook Express isn't too bad, it seems to have much fewer holes and less cruft than Outlook does. It's just a fairly boring Windows mail client that connects to a POP3 or IMAP server.
Slashdot readers take note: this is Outlook Express that's being discontinued, not Outlook. The two are about as related as Javascript and Java.
An XML format for images? Why not SVG?
It's 2003. Is there really no reliable way to electronically identify oneself, so that you can prove you are a person with the name and age given?
It would make sense for passports (as in the funny booklet thing you have to take with you when travelling, for some obscure reason) to include your PGP public key. Then the passport itself (or at least the machine-readable section at the back) can be PGP signed by the government. That way you are able to prove who you are. Messages sent from Friendster or other sites would be encrypted using your public key.