The question of whether the machine runs FreeBSD and the question of giving direct unproxied Internet access are completely orthogonal.
Any bad things you can do with FreeBSD can also be done with Windows. It has a TCP/IP stack too, you know. Downloading bad source or trojaned binaries is no less likely just because you run a different OS. Any attacks that could be launched from a Unix box could equally well be done from Windows. Perhaps on Windows you would need administrator rights to send certain packets; the same applies on Unix with root access.
A Windows OS with a few network tools installed, gcc, and some skills can lead to a lot of problems for the company. The operating system is not the important thing.
So maybe an analogous question to ask would be: if you have a copy of Microsoft Word on your hard disk, and someone wipes it, what is the value of the damage caused? I'd say the time taken to reinstall Word, not the cost of buying another original Word CD at full retail price. Similarly the damage caused by deleting a virtual item is just the time taken for the sysadmin to recreate that item.
The trouble is that the input can be 'as expected' yet still cause hash collisions (which are not corruption - just a slowdown). You can check that every value looks sane, but if you are allowing more than very short strings, it won't help you.
You're right that the only absolutely certain way to avoid hash collisions is not to use hashes; however you can make a probabilistic argument that the chance of really bad collisions happening is close to zero, and less than the computer being struck by lightning. But that is only true if an attacker doesn't know your hashing function and so isn't able to purposely generate strings with the same hash value.
Software patents of seven years (or shorter) duration would not be a good idea. Given the incredibly low standard most patent offices (in America and Europe) apply, a company can simply apply for twice as many patents to cover the fact that they last half as long. If you are currently infringing 4000 (trivial) software patents held by Lucent, then with a seven year duration you'd probably be infringing about 2000. They can still shake you down for money.
It would be interesting to see an economic study assessing the likely impart of different patent lifetimes. However as far as I am aware no economic study has shown a case for software patents, with any lifetime.
On 'continuous use' - all this would do is create jobs for a few extra lawyers whose job it would be to 'release' new works using a character every few years (perhaps a badly drawn comic strip? anything at all in fact) to stay within the letter of the law.
Your farming analogy doesn't fit because you are not 'taking away the farm' when copyright expires. A work that is in the public domain can be used by all, and one person's use of it does not exclude another's. Whereas land and most physical goods are exclusionary.
I'm quite happy that Disney should be able to continue using the Mickey Mouse character in new works. What's not so good is that the law prevents anyone else from doing so (even though Disney itself has often benefited from characters and stories in the public domain).
Might be worth looking at this tutorial about robots.txt if you think you might be at risk.
Er, no. If you have passwords being exposed on the web then you need to make sure they stop being exposed - not just to well-behaved robots but to anybody!.htaccess (if you use Apache) is the file for this.
However, if the web server can read the file then most likely any other user on the same system can read it, since httpd normally runs as an unpriveleged user. So the fix is simple: 'chmod go-rwx file'.
Going a stage further you could say that plaintext passwords should not be stored in files on disk anyway...
I am not slagging off C++ syntax, I am explaining the rationale for C's declarator syntax. But the original rationale doesn't work so well once you add C++'s reference to the mix, or 'const' as you point out. K&R C did not have either (AFAIK) so the declarator syntax back then still had some logic to it.
The question of where to put spaces is not really an issue of language syntax.
Surely it is possible to make a modchip which allows the system to boot Linux or other free OSes, but will reject copies of proprietary games? The Linux CD might have a special marker (not a digital signature, just a marker) to say that it can be loaded. Of course no game maker would put this marker on its CDs.
In the current legal climate, wouldn't that be the best way to sell modchips legally and widely?
PC builders have a choice whether to include a particular brand of hard disk (for example). If any hard disk manufacturer tried to set up a contract where the PC builder had to pay for every PC sold, whether or not it came with the manufacturer's hard disk, they would be laughed at. This is because there is competition in the hard disk market. Competition means choice for PC builders in what to include and what not to include, and makes sure they are not subjected to lock-in contracts by a single hardware supplier (with the possible exception of Intel).
In the case of Windows, Microsoft has the monopoly power to set up contracts where the PC maker has to make Windows non-optional. They can effectively force the PC maker to include Windows (and pay for it) on all PCs sold - with the sanction being withdrawal of OEM licences, and the PC maker being forced to pay the hugely expensive retail price. (This was an explicit threat made by Microsoft to IBM.)
So it is a purely commercial consideration, but not necessarily one that gives the best outcome for consumers. The market is not working as well as it should. The reason is lack of competition.
The ultimate point of the exercise is to get computers to be available without paying for Windows, if you don't want Windows. That will save significant amounts of money.
I don't think that asking a vendor to abide by the contract that came with the computer is 'penalizing'.
Nobody is saying that vendors should be forced not to include OEM software. Only that you should be able to get (and pay for) Windows if you want it, and do without it if you prefer to use another operating system. Of course if you do want Windows it would probably be preinstalled on the machine, as now.
I don't see how wanting to buy a laptop without paying for a bundled OS is 'stomping'. You should have the choice of whether to pay for Windows, or not pay for it - and the same for any other OS. Surely that's not unreasonable?
FWIW I disagree about 'ultimately no price impact' - the cost of Windows as a proportion of total system cost has risen a great deal over the past few years and is still rising (although I do not know what kind of sweetheart deals the major OEMs are able to get with Microsoft). The PC market is not so uncompetitive that a supplier would be able to keep all of the cost savings to itself and pass none on to customers.
Oh come on - you don't do it directly to cost Microsoft money, but to encourage OEMs and Microsoft to let PCs be available for purchase without the Microsoft tax. It's a matter of principle surely - if you don't want Windows, why pay for it?
Anyone who does an analysis of monetary value (or cost) against time spent will not be reading Slashdot anyway...
This guy is not trolling. He makes several valid points.
The two are not mutually exclusive, you know...
FWIW I strongly disagree with your assertion that Perl should not be used for anything longer than a few hundred lines. For longer programs you do need more discipline and a more structured approach. That is as true in Perl as in any language. Writing clear and well-separated code does not have to mean UML diagrams. (Though you can have those with Perl, if you really insist.)
Your terminology, using 'variable' to refer to a whole typeglob slot, is nonstandard in the Perl world. Most programmers (and Larry himself AFAIK) would say that $x is a scalar variable and @x is an array variable. They are both variables and both different.
Referring to the whole typeglob with *var is rather esoteric (not saying it's never used, just it is used far far less often than accessing variables normally), and when you do use it, you talk about typeglobs not variables. *var is a typeglob, which brings together several different variables of the same name.
At least, that is the terminology almost everyone uses.
Lisp has the minimum possible syntax? You sure about that? I'm no Lisp hacker, but it seems that the language has at least two ways of defining functions, at least three different kinds of quoting (plus anti-quoting), and a reasonable number of syntactic shortcuts like ; for constructing pairs. In terms of total punctuation per line of code, Lisp and Perl probably come out about equal.
I don't think it is any more different from Perl 5 than Perl 5 is from Perl 4. Huge amounts of extra stuff (most importantly objects and nested data structures) were added from 4 to 5, together with quite a few syntax changes.
However, backwards compatibility will be more of a gap, because perl 5 is pretty much source-compatible with perl 4, but it doesn't seem that 5 -> 6 will be the same. (No, having a separate interpreter specially built to run older scripts doesn't mean source-compatible in this sense - I'm talking about the language itself.)
Fppt. C has * for multiplication, pointer dereference, and as part of the comment syntax, but it doesn't seem to be confusing. It all depends on the context in which the operator appears. There's nothing wrong with context-dependency in a language, provided it doesn't get counterintuitive.
Seriously, though, the 'someone else' surely ought to take care to express things in the simplest way possible so that other people can read it easily. The choice of whether to use
f() if $cond;
$cond && f();
if ($cond) { f() }
is a matter of style and what part you want to emphasize as important. Just as in English you have a choice of how to arrange a sentence and normally put the more important things last.
Plenty of minimal languages make it just as easy to write unreadable code... I've seen plenty of obfuscated Java. A richer language like Perl lets you write code in the style that is clearest for the task at hand, and that can only be a good thing.
The C++ people have some justification for putting the * next to the type name, because of C++'s references.
string &x;
&x is a string? Huh? How can the address of x be a string? Of course & does not really mean address-of in the above line, it means a reference to the type.
string& x;
string* x;
Not great, and pretty bad when you have multiple declarations on the same line, but probably better. Stroustrup gives his reasons for preferring this second style.
*bar is an int. Therefore, bar must be a pointer to int.
You have to kind of work backwards from the type of *bar to the type of bar. This was considered a feature because the type declaration mirrors the use, however it gets really unwieldy once you start having more complex types like function pointers.
Bjarne Stroustrup has said he considers the C++ declarator syntax an experiment that failed. Of course, in C++ it's even worse since you have the extra & modifier to indicate a reference, which doesn't really fit (since 'char &c' might be read by a C programmer as 'the address of c is a char' - WTF?).
BTW, a nondeterministic finite automaton is much less flexible than ordinary code; there are many things (checking for palindromes being the classic example) which code in a programming language can do but an NFA (and hence a regular expression) cannot. What you mean is that regexps provide a more concise syntax, and perhaps a more efficient implementation (since the regexp engine is in C).
Perl's so-called regular expressions are not true NFAs however, because they have wacky things like backreferences. In fact they are NP-complete.
I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
I think you should reserve judgement until there is an implementation. Otherwise sweeping statements like 'perl6 won't make development any faster' are pretty hard to justify or to disprove.
By all means attack perl5, or dismiss perl6 as vapourware.
FWIW, the huge ugly monster that is Mozilla seems to have turned out rather well in the end - it just took far too long to get there. It's not perfect, but it has succeeded in its own aims (be a portable web browser suited for everyday use).
I'm not 100% sure that uour sanity checks protect the program from excessive hash collisions. Well, maybe restricting to five characters or fewer would do it - but even in the space of five-char-or-shorter strings there must be an awful lot which hash to the same value. Maybe five alphanumeric characters would be a small enough space.
Still, there are cases where you need to allow fairly long and diverse inputs, but still worry about DoS hashing attacks.
Slashdot Mirror
The question of whether the machine runs FreeBSD and the question of giving direct unproxied Internet access are completely orthogonal.
Any bad things you can do with FreeBSD can also be done with Windows. It has a TCP/IP stack too, you know. Downloading bad source or trojaned binaries is no less likely just because you run a different OS. Any attacks that could be launched from a Unix box could equally well be done from Windows. Perhaps on Windows you would need administrator rights to send certain packets; the same applies on Unix with root access.
A Windows OS with a few network tools installed, gcc, and some skills can lead to a lot of problems for the company. The operating system is not the important thing.
I predict that this thermal paste will be useful for putting down one's pants. In order to conduct heat away from any hot grits present.
So maybe an analogous question to ask would be: if you have a copy of Microsoft Word on your hard disk, and someone wipes it, what is the value of the damage caused? I'd say the time taken to reinstall Word, not the cost of buying another original Word CD at full retail price. Similarly the damage caused by deleting a virtual item is just the time taken for the sysadmin to recreate that item.
The trouble is that the input can be 'as expected' yet still cause hash collisions (which are not corruption - just a slowdown). You can check that every value looks sane, but if you are allowing more than very short strings, it won't help you.
You're right that the only absolutely certain way to avoid hash collisions is not to use hashes; however you can make a probabilistic argument that the chance of really bad collisions happening is close to zero, and less than the computer being struck by lightning. But that is only true if an attacker doesn't know your hashing function and so isn't able to purposely generate strings with the same hash value.
Software patents of seven years (or shorter) duration would not be a good idea. Given the incredibly low standard most patent offices (in America and Europe) apply, a company can simply apply for twice as many patents to cover the fact that they last half as long. If you are currently infringing 4000 (trivial) software patents held by Lucent, then with a seven year duration you'd probably be infringing about 2000. They can still shake you down for money.
It would be interesting to see an economic study assessing the likely impart of different patent lifetimes. However as far as I am aware no economic study has shown a case for software patents, with any lifetime.
On 'continuous use' - all this would do is create jobs for a few extra lawyers whose job it would be to 'release' new works using a character every few years (perhaps a badly drawn comic strip? anything at all in fact) to stay within the letter of the law.
Your farming analogy doesn't fit because you are not 'taking away the farm' when copyright expires. A work that is in the public domain can be used by all, and one person's use of it does not exclude another's. Whereas land and most physical goods are exclusionary.
I'm quite happy that Disney should be able to continue using the Mickey Mouse character in new works. What's not so good is that the law prevents anyone else from doing so (even though Disney itself has often benefited from characters and stories in the public domain).
Er, no. If you have passwords being exposed on the web then you need to make sure they stop being exposed - not just to well-behaved robots but to anybody! .htaccess (if you use Apache) is the file for this.
However, if the web server can read the file then most likely any other user on the same system can read it, since httpd normally runs as an unpriveleged user. So the fix is simple: 'chmod go-rwx file'.
Going a stage further you could say that plaintext passwords should not be stored in files on disk anyway...
I am not slagging off C++ syntax, I am explaining the rationale for C's declarator syntax. But the original rationale doesn't work so well once you add C++'s reference to the mix, or 'const' as you point out. K&R C did not have either (AFAIK) so the declarator syntax back then still had some logic to it.
The question of where to put spaces is not really an issue of language syntax.
Sorry, what I meant was that the type of the expression *bar is int.
Surely it is possible to make a modchip which allows the system to boot Linux or other free OSes, but will reject copies of proprietary games? The Linux CD might have a special marker (not a digital signature, just a marker) to say that it can be loaded. Of course no game maker would put this marker on its CDs.
In the current legal climate, wouldn't that be the best way to sell modchips legally and widely?
PC builders have a choice whether to include a particular brand of hard disk (for example). If any hard disk manufacturer tried to set up a contract where the PC builder had to pay for every PC sold, whether or not it came with the manufacturer's hard disk, they would be laughed at. This is because there is competition in the hard disk market. Competition means choice for PC builders in what to include and what not to include, and makes sure they are not subjected to lock-in contracts by a single hardware supplier (with the possible exception of Intel).
In the case of Windows, Microsoft has the monopoly power to set up contracts where the PC maker has to make Windows non-optional. They can effectively force the PC maker to include Windows (and pay for it) on all PCs sold - with the sanction being withdrawal of OEM licences, and the PC maker being forced to pay the hugely expensive retail price. (This was an explicit threat made by Microsoft to IBM.)
So it is a purely commercial consideration, but not necessarily one that gives the best outcome for consumers. The market is not working as well as it should. The reason is lack of competition.
The ultimate point of the exercise is to get computers to be available without paying for Windows, if you don't want Windows. That will save significant amounts of money.
I don't think that asking a vendor to abide by the contract that came with the computer is 'penalizing'.
Nobody is saying that vendors should be forced not to include OEM software. Only that you should be able to get (and pay for) Windows if you want it, and do without it if you prefer to use another operating system. Of course if you do want Windows it would probably be preinstalled on the machine, as now.
I don't see how wanting to buy a laptop without paying for a bundled OS is 'stomping'. You should have the choice of whether to pay for Windows, or not pay for it - and the same for any other OS. Surely that's not unreasonable?
FWIW I disagree about 'ultimately no price impact' - the cost of Windows as a proportion of total system cost has risen a great deal over the past few years and is still rising (although I do not know what kind of sweetheart deals the major OEMs are able to get with Microsoft). The PC market is not so uncompetitive that a supplier would be able to keep all of the cost savings to itself and pass none on to customers.
Oh come on - you don't do it directly to cost Microsoft money, but to encourage OEMs and Microsoft to let PCs be available for purchase without the Microsoft tax. It's a matter of principle surely - if you don't want Windows, why pay for it?
Anyone who does an analysis of monetary value (or cost) against time spent will not be reading Slashdot anyway...
The two are not mutually exclusive, you know...
FWIW I strongly disagree with your assertion that Perl should not be used for anything longer than a few hundred lines. For longer programs you do need more discipline and a more structured approach. That is as true in Perl as in any language. Writing clear and well-separated code does not have to mean UML diagrams. (Though you can have those with Perl, if you really insist.)
Your terminology, using 'variable' to refer to a whole typeglob slot, is nonstandard in the Perl world. Most programmers (and Larry himself AFAIK) would say that $x is a scalar variable and @x is an array variable. They are both variables and both different.
Referring to the whole typeglob with *var is rather esoteric (not saying it's never used, just it is used far far less often than accessing variables normally), and when you do use it, you talk about typeglobs not variables. *var is a typeglob, which brings together several different variables of the same name.
At least, that is the terminology almost everyone uses.
Lisp has the minimum possible syntax? You sure about that? I'm no Lisp hacker, but it seems that the language has at least two ways of defining functions, at least three different kinds of quoting (plus anti-quoting), and a reasonable number of syntactic shortcuts like ; for constructing pairs. In terms of total punctuation per line of code, Lisp and Perl probably come out about equal.
I don't think it is any more different from Perl 5 than Perl 5 is from Perl 4. Huge amounts of extra stuff (most importantly objects and nested data structures) were added from 4 to 5, together with quite a few syntax changes.
However, backwards compatibility will be more of a gap, because perl 5 is pretty much source-compatible with perl 4, but it doesn't seem that 5 -> 6 will be the same. (No, having a separate interpreter specially built to run older scripts doesn't mean source-compatible in this sense - I'm talking about the language itself.)
So what you're saying is that Dummies == Linux users?
Fppt. C has * for multiplication, pointer dereference, and as part of the comment syntax, but it doesn't seem to be confusing. It all depends on the context in which the operator appears. There's nothing wrong with context-dependency in a language, provided it doesn't get counterintuitive.
(5) Profit!!!
Seriously, though, the 'someone else' surely ought to take care to express things in the simplest way possible so that other people can read it easily. The choice of whether to use
f() if $cond;
$cond && f();
if ($cond) { f() }
is a matter of style and what part you want to emphasize as important. Just as in English you have a choice of how to arrange a sentence and normally put the more important things last.
Plenty of minimal languages make it just as easy to write unreadable code... I've seen plenty of obfuscated Java. A richer language like Perl lets you write code in the style that is clearest for the task at hand, and that can only be a good thing.
The C++ people have some justification for putting the * next to the type name, because of C++'s references.
string &x;
&x is a string? Huh? How can the address of x be a string? Of course & does not really mean address-of in the above line, it means a reference to the type.
string& x;
string* x;
Not great, and pretty bad when you have multiple declarations on the same line, but probably better. Stroustrup gives his reasons for preferring this second style.
It does make some sense, in a warped kind of way.
foo is an int.
*bar is an int. Therefore, bar must be a pointer to int.
You have to kind of work backwards from the type of *bar to the type of bar. This was considered a feature because the type declaration mirrors the use, however it gets really unwieldy once you start having more complex types like function pointers.
Bjarne Stroustrup has said he considers the C++ declarator syntax an experiment that failed. Of course, in C++ it's even worse since you have the extra & modifier to indicate a reference, which doesn't really fit (since 'char &c' might be read by a C programmer as 'the address of c is a char' - WTF?).
BTW, a nondeterministic finite automaton is much less flexible than ordinary code; there are many things (checking for palindromes being the classic example) which code in a programming language can do but an NFA (and hence a regular expression) cannot. What you mean is that regexps provide a more concise syntax, and perhaps a more efficient implementation (since the regexp engine is in C).
Perl's so-called regular expressions are not true NFAs however, because they have wacky things like backreferences. In fact they are NP-complete.
I think you should reserve judgement until there is an implementation. Otherwise sweeping statements like 'perl6 won't make development any faster' are pretty hard to justify or to disprove.
By all means attack perl5, or dismiss perl6 as vapourware.
FWIW, the huge ugly monster that is Mozilla seems to have turned out rather well in the end - it just took far too long to get there. It's not perfect, but it has succeeded in its own aims (be a portable web browser suited for everyday use).
I'm not 100% sure that uour sanity checks protect the program from excessive hash collisions. Well, maybe restricting to five characters or fewer would do it - but even in the space of five-char-or-shorter strings there must be an awful lot which hash to the same value. Maybe five alphanumeric characters would be a small enough space.
Still, there are cases where you need to allow fairly long and diverse inputs, but still worry about DoS hashing attacks.