No - distinguish between syntactic sugar, which gives you a new syntax to express what you could have said anyway, and real language features.
For example array access with [] in C is syntactic sugar, since you could do the same with pointer arithmetic - a[b] is exactly equivalent to *(a+b). However a declaration of an array variable:
int a[1000];
is _not_ syntactic sugar, since there is no other way to reserve space for a thousand contiguous integers on the stack. You could use malloc() from the standard library, but as you know that allocates on the heap and you have to free the memory afterwards.
(OK you could have a thousand 'int' declarations but I don't think it's guaranteed they will be a contiguous block in memory.)
As an example of a language with no syntactic sugar, look at Unlambda (although you wouldn't want to program in it). The language syntax is minimal but semantically it is a long way off from raw machine code.
Using shorter notation does not lead to increased maintenance. Of course using shorthands stupidly is a maintenance headache, but so is doing anything stupid.
Far more of a problem in maintenance, I have found, is wading through pages of boilerplate code when a couple of function definitions and maybe macros or code generation would have let the same ideas be expressed much more concisely and with less repetition.
I think the cylinders are too small and the heads too bulky to do this. There have been drives with two or more heads, which seems like an obvious way to improve performance, I don't know why they haven't taken off.
(I don't mean several heads stacked underneath each other, one per platter, I mean two independently-movable heads for the same platter.)
At some stage the density may be high enough that you can store everything on a single cylinder and not need to move the head at all. That would also make the drives a bit cheaper to manufacture.
Of course I expect moving-head drives to still dominate because people would rather have a larger capacity, even if accessing most of that capacity requires a few milliseconds of seek time.
The cipher 'none' does exist but normally it is specially disabled in the source code. I have a patch to OpenSSH to enable cipher 'none' but I haven't updated it in a while.
Re:What OSS needs from wall street....
on
Wall Street Meat
·
· Score: 1
GeniusTrader could be a starting point for building such a system.
I don't think that the IBM and Sun JREs can fairly be described as 'competing' because IBM licenses code from Sun. They aren't independent implementations as far as I know.
But types are not 'nonsense that has nothing to do with how the program works'. If you have a function to return the largest element in a list, then its type signature will state that it expects a list of things and there should be some comparison function defined on those things. For example in Haskell the type might be 'Cmp a => [a] -> a' stating that for a type 'a' which has a less-than operator ('Cmp'), the function expects a list of 'a' elements and returns one. You can see from the type quite a lot of what the program does.
Of course things which are more implementation details like 'should this integer take 32 bits or 64 bits of storage' or 'should this (read-only) parameter be copied onto the stack or passed by reference' can get in the way. That's why it's often good to use a high-level language which decides these things for you. And also to use a language with type inference so you don't have to specify every fiddly little type, you can just add type declarations where you want to and the compiler will work out the rest.
Don't let the limitations of Pascal or C turn you off static typing altogether. A type system like that in ML or Haskell really helps productivity rather than impeding it.
Perhaps the problem is write caching. With many embedded devices you have to allow that the power can fail at any time (due to batteries running out, being unplugged, or just the user turning the device off). Ext2 can take a long time to fsck after an unclean shutdown and it's possible (though unlikely) that the filesystem will be beyond repair. Hence the need for a journalling filesystem.
The DOS filesystem is relatively robust against half-written data, I think. Or at least the disk recovery tools are very mature. Older DOS versions, of course, didn't have any write-behind disk caching. I don't know what Vxworks does, whether by default it commits all writes to disk immediately or not.
It's not really a filesystem issue, you could easily run ext2 mounted in synchronous mode if you wanted. Although the performance would not be as good as a filesystem designed to commit writes immediately, such as ext3 with data=journal.
No, I picked up the phrase 'AI-complete' from some online forum, probably Slashdot. It's defined at Foldoc, although it might be better to use the definition 'a program that answers an AI-complete problem could pass a Turing Test without too much extra effort'.
I think people would have used 'Turing-complete' but that was taken:-). It's more than most ordinary folk can dream of to be associated with enough important concepts that they start being unable to name them all after you.
OK I will take your word for it since I am no OCR expert. Anyway, even if someone did manage to OCR the current Yahoo login pictures, the job could be made a lot harder by allowing nonalphabetic symbols such as dingbats (then give a hint to human readers 'please write A for the telephone symbol and B for the knife-and-fork symbol').
What you say may be right but until I see an example of a question which can be worked out backwards but not forwards by a machine, yet can be easily worked out forwards by most humans, I'd prefer to assume it's not possible.
If a computer can generate a question from a solution, then it could also go the other way albeit slowly, by thinking of solutions at random and generating possible questions for them until it finds one that matches.
Maybe no software exists to OCR this stuff now, but if such systems are adopted for challenges you can be pretty sure the software will be written. (It would be useful to have already, for Yahoo registrations and similar things.)
Hmm I was going to respond saying 'shouldn't there be a grave accent, as voil?' but apparently this isn't used in English.
About OCR: I don't think it is computationally expensive, or at least even if it is now it will not be in five years' time. If you want to inflict computing expense on spammers you need a system which can be easily stepped up from year to year.
However, challenge/response does require that the sending address exist in order to reply to the challenge. You can't set up an account, send millions of messages and then scram. You have to wait around for the challenges to arrive and then try to answer them. The longer the delay between original message and getting a challenge, the harder life becomes for spammers, but also a long delay spoils the point of email.
What I'd expect spammers to do is spoof the headers so that mail appears to be from random addresses. If there's one resource spammers can be guaranteed to have at their disposal it's a list of random addresses:-(. Then the challenges will be sent to random users. If those users are accustomed to responding to challenges they may fill them out so the spam is delivered. Of course if spammers adopt this tactic then people will have to wade through a mass of challenges in their inbox, sorting the few genuine ones from the mass of spam.
There is a small possibility for improvement in that the mail client could discard challenges that don't correspond to any message in the sent-mail folder, but doing that automatically would require a machine-readable format for challenge messages. (The puzzle itself can require human intelligence, but the stuff about 'you tried to send a message to x@y.com and its content had MD5 sum 43243242' could be in a standard format.)
Bandwidth is also a good point. The trouble is that any bandwidth costs you inflict on the spammer you also inflict on yourself and other ISPs.
They could have a dual system: send challenges normally, but if a message has enough Hash Cash postage paid then no challenge is needed. This would let automated mailings get through if the sender was prepared to spend some amount of CPU time. Presumably the company with whom you have a business relationship would be willing to spend ten seconds of their server's CPU time to send you a message, but a spammer would not.
Spammers seem to be sending a whole bunch of crap from my address (ed@membled.com) even now. At least, I keep seeing what appear to be genuine delivery failure notifications of Russian spam sent from my address. Any system which trusts individual email addresses, without relying on some real authentication such as PGP signatures, is broken.
A simple rule is: Headers can be forged. Don't trust anything in the headers for antispam purposes. This includes the sender and recipient.
Of course it is no good if the spammers can set up automated systems to respond to the challenge. There are only two ways around this:
- Make the challenge 'AI-complete', that is, to give a correct answer you must be a thinking human being and not a computer. But then how can the other end check that the answer is correct? Having humans generate a fixed number of questions and provide sample answers also isn't going to work, since spammers will learn the correct answers. You need a way to generate an unlimited number of questions and to mark the answers automatically, and clearly this can't be done if the questions are intended to be too hard for a computer.
- Make the response computationally burdensome, so a computer can do it but only at the cost of some CPU power (so large bulk mailings would be impractical). This is what Hash Cash and similar systems suggest.
It looks like Earthlink's system will rely on sending pictures you have to look at. Apart from the practical problems of clogging the wires with image files, I worry about OCR potential. The examples of this stuff I've seen on Yahoo, where you have to type in a number shown in a partially 'obscured' image, wouldn't have been difficult to develop OCR software for if you were so minded.
There's also the question of the spammer taking the challenge and sending it out to some other user. That user, by now used to replying to challenges from Earthlink and other addresses, will respond to the question and send the correct answer back to the spammer. D'oh!
No repeating pattern does not mean no formula. Take the number.010110111011110111110... where you have groups of 1 digits getting one digit longer each time. This is an irrational number in that it can't be represented as M/N where M and N are integer. But clearly it's possible to write a formula to calculate the digit at a given position.
Although what matters is not finding *a formula* but an 'efficient' formula in some sense. The digits of pi are certainly computable and you can write a program to give any digit asked for. But can you do this without calculating the whole expansion of pi up to that point, or to put it in terms of time taken, can you write a program that does better than taking linear time in the 'depth' of the digit chosen?
About your second point - given two hex digits, how do you work out the corresponding decimal digit? Let's number the digits with zero for the digit immediately after the (hexa)decimal point. If I told you that the hex digits at positions 5 and 6 were 'A' and 'B', what decimal digit could you work out from that? Don't you need to know the preceding digits as well?
If they paid bounties for spotting suspicious activities, people would try to create such activity themselves in order to report it. Like how offering bounties for killing pest creatures can encourage people to farm them.
Quite. Rather than adding more features/kludges to X11's authorization to cope with IPv6 addresses, might it not be better to abolish it altogether?
All this xhost / xauth / MIT_MAGIC_COOKIE stuff really needs to die. I can see the point of keeping it around for compatibility, but nobody is requiring 'compatibility' with some mythical Sun3 or MicroVAX using IPv6. Why not have the X server accept connections only on a single Unix socket, and then if you want remote connections you can use a separate daemon (such as sshd) to handle the authorization?
Or in the worst case they could use Kerberos.
(And why yes, I did recently read the appropriate chapter of the UHH... but I knew this stuff was a crock even before then. Ssh tunnelling is great. Plaintext X traffic with half-baked 'authentication', xdm protocol and so on is not.)
Of course someone in the US could set up as an intermediary - you could probably argue it was legal, since sending the paid-for single copy of the song is not really any different from mailing a CD overseas.
Of course Apple would still block it, because they have agreed with the record companies not to sell overseas.
The biggest reason viruses aren't such a problem on Linux is that Linux users don't generally run binary-only programs downloaded from random places. They don't attach dancing_elephants.exe to their messages or run such a program when it arrives.
Yes - in theory it is possible to add a virus to source code so that when compiled the virus will spread, but this requires deliberate steps. I think most Windows viruses are spread accidentally.
Slashdot Mirror
No - distinguish between syntactic sugar, which gives you a new syntax to express what you could have said anyway, and real language features.
For example array access with [] in C is syntactic sugar, since you could do the same with pointer arithmetic - a[b] is exactly equivalent to *(a+b). However a declaration of an array variable:
int a[1000];
is _not_ syntactic sugar, since there is no other way to reserve space for a thousand contiguous integers on the stack. You could use malloc() from the standard library, but as you know that allocates on the heap and you have to free the memory afterwards.
(OK you could have a thousand 'int' declarations but I don't think it's guaranteed they will be a contiguous block in memory.)
As an example of a language with no syntactic sugar, look at Unlambda (although you wouldn't want to program in it). The language syntax is minimal but semantically it is a long way off from raw machine code.
Using shorter notation does not lead to increased maintenance. Of course using shorthands stupidly is a maintenance headache, but so is doing anything stupid.
Far more of a problem in maintenance, I have found, is wading through pages of boilerplate code when a couple of function definitions and maybe macros or code generation would have let the same ideas be expressed much more concisely and with less repetition.
I think the cylinders are too small and the heads too bulky to do this. There have been drives with two or more heads, which seems like an obvious way to improve performance, I don't know why they haven't taken off.
(I don't mean several heads stacked underneath each other, one per platter, I mean two independently-movable heads for the same platter.)
At some stage the density may be high enough that you can store everything on a single cylinder and not need to move the head at all. That would also make the drives a bit cheaper to manufacture.
Of course I expect moving-head drives to still dominate because people would rather have a larger capacity, even if accessing most of that capacity requires a few milliseconds of seek time.
The cipher 'none' does exist but normally it is specially disabled in the source code. I have a patch to OpenSSH to enable cipher 'none' but I haven't updated it in a while.
GeniusTrader could be a starting point for building such a system.
I don't think that the IBM and Sun JREs can fairly be described as 'competing' because IBM licenses code from Sun. They aren't independent implementations as far as I know.
But types are not 'nonsense that has nothing to do with how the program works'. If you have a function to return the largest element in a list, then its type signature will state that it expects a list of things and there should be some comparison function defined on those things. For example in Haskell the type might be 'Cmp a => [a] -> a' stating that for a type 'a' which has a less-than operator ('Cmp'), the function expects a list of 'a' elements and returns one. You can see from the type quite a lot of what the program does.
Of course things which are more implementation details like 'should this integer take 32 bits or 64 bits of storage' or 'should this (read-only) parameter be copied onto the stack or passed by reference' can get in the way. That's why it's often good to use a high-level language which decides these things for you. And also to use a language with type inference so you don't have to specify every fiddly little type, you can just add type declarations where you want to and the compiler will work out the rest.
Don't let the limitations of Pascal or C turn you off static typing altogether. A type system like that in ML or Haskell really helps productivity rather than impeding it.
Perhaps the problem is write caching. With many embedded devices you have to allow that the power can fail at any time (due to batteries running out, being unplugged, or just the user turning the device off). Ext2 can take a long time to fsck after an unclean shutdown and it's possible (though unlikely) that the filesystem will be beyond repair. Hence the need for a journalling filesystem.
The DOS filesystem is relatively robust against half-written data, I think. Or at least the disk recovery tools are very mature. Older DOS versions, of course, didn't have any write-behind disk caching. I don't know what Vxworks does, whether by default it commits all writes to disk immediately or not.
It's not really a filesystem issue, you could easily run ext2 mounted in synchronous mode if you wanted. Although the performance would not be as good as a filesystem designed to commit writes immediately, such as ext3 with data=journal.
You don't need a special key to type an accented 'a', you just press the normal key slightly harder.
No, I picked up the phrase 'AI-complete' from some online forum, probably Slashdot. It's defined at Foldoc, although it might be better to use the definition 'a program that answers an AI-complete problem could pass a Turing Test without too much extra effort'.
:-). It's more than most ordinary folk can dream of to be associated with enough important concepts that they start being unable to name them all after you.
I think people would have used 'Turing-complete' but that was taken
OK I will take your word for it since I am no OCR expert. Anyway, even if someone did manage to OCR the current Yahoo login pictures, the job could be made a lot harder by allowing nonalphabetic symbols such as dingbats (then give a hint to human readers 'please write A for the telephone symbol and B for the knife-and-fork symbol').
What you say may be right but until I see an example of a question which can be worked out backwards but not forwards by a machine, yet can be easily worked out forwards by most humans, I'd prefer to assume it's not possible.
If a computer can generate a question from a solution, then it could also go the other way albeit slowly, by thinking of solutions at random and generating possible questions for them until it finds one that matches.
Maybe no software exists to OCR this stuff now, but if such systems are adopted for challenges you can be pretty sure the software will be written. (It would be useful to have already, for Yahoo registrations and similar things.)
Hmm I was going to respond saying 'shouldn't there be a grave accent, as voil?' but apparently this isn't used in English.
:-(. Then the challenges will be sent to random users. If those users are accustomed to responding to challenges they may fill them out so the spam is delivered. Of course if spammers adopt this tactic then people will have to wade through a mass of challenges in their inbox, sorting the few genuine ones from the mass of spam.
About OCR: I don't think it is computationally expensive, or at least even if it is now it will not be in five years' time. If you want to inflict computing expense on spammers you need a system which can be easily stepped up from year to year.
However, challenge/response does require that the sending address exist in order to reply to the challenge. You can't set up an account, send millions of messages and then scram. You have to wait around for the challenges to arrive and then try to answer them. The longer the delay between original message and getting a challenge, the harder life becomes for spammers, but also a long delay spoils the point of email.
What I'd expect spammers to do is spoof the headers so that mail appears to be from random addresses. If there's one resource spammers can be guaranteed to have at their disposal it's a list of random addresses
There is a small possibility for improvement in that the mail client could discard challenges that don't correspond to any message in the sent-mail folder, but doing that automatically would require a machine-readable format for challenge messages. (The puzzle itself can require human intelligence, but the stuff about 'you tried to send a message to x@y.com and its content had MD5 sum 43243242' could be in a standard format.)
Bandwidth is also a good point. The trouble is that any bandwidth costs you inflict on the spammer you also inflict on yourself and other ISPs.
They could have a dual system: send challenges normally, but if a message has enough Hash Cash postage paid then no challenge is needed. This would let automated mailings get through if the sender was prepared to spend some amount of CPU time. Presumably the company with whom you have a business relationship would be willing to spend ten seconds of their server's CPU time to send you a message, but a spammer would not.
I hope it's not obvious, if each me@challenge.earthlink.com has a corresponding me@earthlink.com then spammers could figure this out pretty quickly.
Spammers seem to be sending a whole bunch of crap from my address (ed@membled.com) even now. At least, I keep seeing what appear to be genuine delivery failure notifications of Russian spam sent from my address. Any system which trusts individual email addresses, without relying on some real authentication such as PGP signatures, is broken.
A simple rule is: Headers can be forged. Don't trust anything in the headers for antispam purposes. This includes the sender and recipient.
Of course it is no good if the spammers can set up automated systems to respond to the challenge. There are only two ways around this:
- Make the challenge 'AI-complete', that is, to give a correct answer you must be a thinking human being and not a computer. But then how can the other end check that the answer is correct? Having humans generate a fixed number of questions and provide sample answers also isn't going to work, since spammers will learn the correct answers. You need a way to generate an unlimited number of questions and to mark the answers automatically, and clearly this can't be done if the questions are intended to be too hard for a computer.
- Make the response computationally burdensome, so a computer can do it but only at the cost of some CPU power (so large bulk mailings would be impractical). This is what Hash Cash and similar systems suggest.
It looks like Earthlink's system will rely on sending pictures you have to look at. Apart from the practical problems of clogging the wires with image files, I worry about OCR potential. The examples of this stuff I've seen on Yahoo, where you have to type in a number shown in a partially 'obscured' image, wouldn't have been difficult to develop OCR software for if you were so minded.
There's also the question of the spammer taking the challenge and sending it out to some other user. That user, by now used to replying to challenges from Earthlink and other addresses, will respond to the question and send the correct answer back to the spammer. D'oh!
No repeating pattern does not mean no formula. Take the number .010110111011110111110... where you have groups of 1 digits getting one digit longer each time. This is an irrational number in that it can't be represented as M/N where M and N are integer. But clearly it's possible to write a formula to calculate the digit at a given position.
Although what matters is not finding *a formula* but an 'efficient' formula in some sense. The digits of pi are certainly computable and you can write a program to give any digit asked for. But can you do this without calculating the whole expansion of pi up to that point, or to put it in terms of time taken, can you write a program that does better than taking linear time in the 'depth' of the digit chosen?
About your second point - given two hex digits, how do you work out the corresponding decimal digit? Let's number the digits with zero for the digit immediately after the (hexa)decimal point. If I told you that the hex digits at positions 5 and 6 were 'A' and 'B', what decimal digit could you work out from that? Don't you need to know the preceding digits as well?
If they paid bounties for spotting suspicious activities, people would try to create such activity themselves in order to report it. Like how offering bounties for killing pest creatures can encourage people to farm them.
How can this be - how can there exist a formula to get a hexadecimal digit but not a decimal digit? What is so special about base 16?
(Unless the origianl formula is to get a binary digit, and you clump four of them together to get hex... but then why is binary special?)
Quite. Rather than adding more features/kludges to X11's authorization to cope with IPv6 addresses, might it not be better to abolish it altogether?
All this xhost / xauth / MIT_MAGIC_COOKIE stuff really needs to die. I can see the point of keeping it around for compatibility, but nobody is requiring 'compatibility' with some mythical Sun3 or MicroVAX using IPv6. Why not have the X server accept connections only on a single Unix socket, and then if you want remote connections you can use a separate daemon (such as sshd) to handle the authorization?
Or in the worst case they could use Kerberos.
(And why yes, I did recently read the appropriate chapter of the UHH... but I knew this stuff was a crock even before then. Ssh tunnelling is great. Plaintext X traffic with half-baked 'authentication', xdm protocol and so on is not.)
Of course someone in the US could set up as an intermediary - you could probably argue it was legal, since sending the paid-for single copy of the song is not really any different from mailing a CD overseas.
Of course Apple would still block it, because they have agreed with the record companies not to sell overseas.
The biggest reason viruses aren't such a problem on Linux is that Linux users don't generally run binary-only programs downloaded from random places. They don't attach dancing_elephants.exe to their messages or run such a program when it arrives.
Yes - in theory it is possible to add a virus to source code so that when compiled the virus will spread, but this requires deliberate steps. I think most Windows viruses are spread accidentally.