Well, if it's a form with a GET request then it should be safe to request it, and it's used merely to display some information. Forms using the POST method, which performs an action, are less safe and I'd hope Google is not trying to spider those.
If people want their sites to be indexed, they shouldn't use forms for navigation.
So the alternative is automatically generating pages and pages of links to every possible item in the database just so that search engines can follow them? If a form is the most natural and convenient interface for a human there's no reason the spider can't use it too.
The thing is, when people are faced with more than two choices, they tend to panic and dither and get put off. It's surely a bug in the way the human mind is designed, but given that the original maintainer seems to have gone quiet for a while, I don't think a patch will be forthcoming. So we have to work around the bug. One way to do that is to reduce the number of choices that have to be made, or at least, as the Python folk say, 'There should be one obvious way to do it'. Even if what you end up with is technically inferior to one of the options that could have been chosen (and let's face it, the C language, X11, Qwerty keyboards, SMTP, and pretty much everything else is less than perfect), there is massive value in simply eliminating the number of decisions a developer has to make.
I realize this isn't quite a direct reply to what you wrote, but I felt like a bit of a rant anyway:-p.
Think of a dollar as "100" cents. 0x100 cents = 256 (decimal) cents.
Yes, finally someone is taking a stand against the crappy metric-system-obsessed definition of a dollar. Everyone knows a dollar is 256 cents, this whole decimal crap is just a conspiracy by big business in cahoots with the Federal Reserve to rip us off, just like they did with hard disk sizes. I'm voting for Ron Paul.
I think the most serious criticism of TWiki is its poor security track record. I used to run a site, until it was compromised by a widespread exploit uploading a PHP file as an attachment, which TWiki then saves in a directory served directly by Apache - so an attacker can upload any program he wants and it runs with privileges of the web server. In my case, it was a rather handy remote administration tool that lets you alter any file on the system (that's writable by Apache) and download the contents of/etc/passwd.
OK, anyone could get caught out by such a mistake, but the response of the TWiki developers does not inspire confidence. They added a blacklist of 'bad file extensions' so that filenames ending.php cannot be uploaded. Of course, this falls into the mistake of 'enumerating badness' and leaves you open to the next magic file extension that the developers hadn't thought of. At least in TWiki 2 the problem has been dealt with properly by using a CGI script to serve attachments, rather than leaving them to the vagaries of Apache's configuration (which is great for a website you maintain yourself, not so good for directories where anyone can upload any file with any name).
It appeared that the TWiki developers' security process was purely reactive - kludging in fixes to exploits as they were discovered - and nobody was auditing the code to discover holes before the bad guys do, or just to clean up bad smells that might or might not lead to an exploit later.
Looking at the TWiki code, it's rather a mess and doesn't seem to take the paranoid precautions you need in Perl when running system() and other interaction with the outside world - precautions particularly needed in a CGI program that's meant to be publicly accessible. I am a keen Perl programmer but TWiki is the kind of code that gives Perl a bad reputation.
That said, in an environment where you trust everybody (like a company webserver accessible only on your network) TWiki is a very handy application. I rather like the grungy way it keeps page content in RCS archives; you can hack up scripts to automatically import your existing static HTML pages into the wiki. But if I were installing a new wiki now I would use something else: preferably the kind of wiki that works by generating a set of static HTML pages and updating them on edits. That seems to have the smallest attack surface and the best performance.
Nope, it's because DOS (following VMS convention) used slash for options. For example DIR/OD to sort by date. AFAIK, all versions of DOS (since 2.0) and Windows have accepted both \ and / as directory separator, although many userland applications may insist on \.
The tragic thing is that this function doesn't even do what it says. If a and b are large enough, it won't return a + b, nor even give an error, but instead return some wrapped-around crazy value, which is almost never what you want.
Do you have any performance/power figures for IBM's chips versus Intel's? I am thinking of general purpose computing, so ATI and Nvidia are out, at least until you can run Postgres, gzip, Apache, perl, Java and C# directly on a GPU core. Agreed that for number crunching and floating-point heavy applications you'd be wise not to rely on Intel's general purpose x86 chips.
Does the cost of Microsoft Windows included with a server include a support subscription comparable to Red Hat's? If not, you are not comparing like with like.
The fair comparison is: Windows licence plus support contract versus RHEL subscription,
or: Windows licence with no support versus CentOS with no support.
OK so if you have a PUE of 1.2 then five-sixths of the input energy is used to power the computer equipment. But that doesn't say how energy efficient the machines themselves are. You could be running 150W Pentium 4 Extreme Edition processors, or whatever, and still get a higher 'efficiency' than someone using Atom processors giving the same computational speed with lower power usage.
In the old days I would have suggested that Microsoft was limited to x86 processors and so they would necessarily have higher power usage than Google, who would be free to use more power-efficient architectures like ARM or PowerPC. But I get the feeling this isn't true nowadays. In servers and high-end desktops, do Intel x86 chips now offer the best bang per watt?
try sleeping only when you're tired and eating only when you're hungry
That's what everyone does anyway!
Is anyone able to sleep when they are not tired? Who ever heard of stuffing food into yourself even when you don't feel hungry?
Is there some parallel universe where people don't feel the natural bodily impulses of hunger and tiredness, and have to rely on Slashdot advice to tell them to drink when thirsty and scratch their own itch?
Whenever you read these overclocking and gaming sites it gets really tedious that they always have to call a computer a 'rig'. But finally, we have an instance where the name is entirely appropriate.
You can do basic functional programming in Perl but more advanced stuff becomes a real pain because of the lack of static type checking. Once you start having multiple layers of map or foldr or monads or whatever, you really need a type system like Haskell's to catch mistakes for you. With Perl you end up with undefined value warnings at run time and spend ages putting in debugging print statements to figure out what's going on. On the other hand, of course, many programming styles are much easier in Perl than in Haskell.
No problem, if Apple hasn't included Firewire then just buy your next Mac from any one of the wide range of competing hardware vendors... right... right?
Using a Mac means you have to bend over for Steve Jobs. It's pointless complaining about it.
Nowadays making sure your site is valid HTML is easy. Just install the excellent HTML validator plugin for Firefox. It gives you a tick or cross icon on each page; double-click the cross to view the page source with a list of errors. It does the validation locally on your machine, not sending the content off to some server, so it's fast.
If you're writing dynamically generated pages it is a great way to find bugs in your code, and it's unobtrusive enough to leave it turned on all the time.
Yeah, dammit, why are all the cast so frickin' *young*? And too good-looking IMHO. Science fiction shouldn't be spoiled by hunky young beefcake any more than by pneumatic Borg-enhanced female lifeforms. One or two green aliens is okay, but the bridge of the Enterprise is not a shaving foam commercial.
Actually it has 8 * 500 trillion offsets since a 500Gbyte drive is 4000 gigabits. So 47 bits of randomness. I take your point though, it's not much.
Conceivably you could hide each bit of your 256 bit key at a different place on the disk... but I doubt a court would buy that argument even if the earlier one had some hope of working.
I just downloaded truecrypt-6.0a-opensuse-x64.tar.gz without problems to my PC sitting within 500 metres of St Paul's cathedral. A file failing to download is hardly unknown. A conspiracy theory should be the explanation of last resort, not the first.
Suppose some incriminating evidence exists but it is hidden in a secret location. Can you be forced to disclose that location?
If not, then why not store your encrypted data on a huge partition of random data. To get it you need both the key and the location of the data. The latter you can simply refuse to disclose.
So you've given up on the relatively open PC platform and gone to a console which is far more locked down and DRM'd than anything from Microsoft or Apple. This doesn't show that DRM or anti-piracy measures (note: the two are not the same thing) are bad for business: it shows that they are good for business provided they are done well (which in practice means locking down the rest of the system under a single company's control).
This is really great news. We already have IRC bots that can fool the casual observer into thinking they are human, but this takes things to a higher level. If the source for one of these bots is available, within a few months you can expect instant messaging networks to be full of bots which are programmed to make friends with you and then after a few weeks start making subtle references to Viagra and online pharmacies. Indeed, if one of them is able to chat up the ladies, then the lonely nerd could easily automate much of the tedious work of setting up dates: get your robot to talk to thousands of potential matches at once and alert you when it gets hold of a phone number, together with a brief summary of what you talked about, and any pictures. (Or indeed, just program it to harvest pictures.) That is, if online dating works at all, which is doubtful.
Slashdot Mirror
Well, if it's a form with a GET request then it should be safe to request it, and it's used merely to display some information. Forms using the POST method, which performs an action, are less safe and I'd hope Google is not trying to spider those.
So the alternative is automatically generating pages and pages of links to every possible item in the database just so that search engines can follow them? If a form is the most natural and convenient interface for a human there's no reason the spider can't use it too.
The thing is, when people are faced with more than two choices, they tend to panic and dither and get put off. It's surely a bug in the way the human mind is designed, but given that the original maintainer seems to have gone quiet for a while, I don't think a patch will be forthcoming. So we have to work around the bug. One way to do that is to reduce the number of choices that have to be made, or at least, as the Python folk say, 'There should be one obvious way to do it'. Even if what you end up with is technically inferior to one of the options that could have been chosen (and let's face it, the C language, X11, Qwerty keyboards, SMTP, and pretty much everything else is less than perfect), there is massive value in simply eliminating the number of decisions a developer has to make.
I realize this isn't quite a direct reply to what you wrote, but I felt like a bit of a rant anyway :-p.
Yes, finally someone is taking a stand against the crappy metric-system-obsessed definition of a dollar. Everyone knows a dollar is 256 cents, this whole decimal crap is just a conspiracy by big business in cahoots with the Federal Reserve to rip us off, just like they did with hard disk sizes. I'm voting for Ron Paul.
I think the most serious criticism of TWiki is its poor security track record. I used to run a site, until it was compromised by a widespread exploit uploading a PHP file as an attachment, which TWiki then saves in a directory served directly by Apache - so an attacker can upload any program he wants and it runs with privileges of the web server. In my case, it was a rather handy remote administration tool that lets you alter any file on the system (that's writable by Apache) and download the contents of /etc/passwd.
OK, anyone could get caught out by such a mistake, but the response of the TWiki developers does not inspire confidence. They added a blacklist of 'bad file extensions' so that filenames ending .php cannot be uploaded. Of course, this falls into the mistake of 'enumerating badness' and leaves you open to the next magic file extension that the developers hadn't thought of. At least in TWiki 2 the problem has been dealt with properly by using a CGI script to serve attachments, rather than leaving them to the vagaries of Apache's configuration (which is great for a website you maintain yourself, not so good for directories where anyone can upload any file with any name).
It appeared that the TWiki developers' security process was purely reactive - kludging in fixes to exploits as they were discovered - and nobody was auditing the code to discover holes before the bad guys do, or just to clean up bad smells that might or might not lead to an exploit later.
Looking at the TWiki code, it's rather a mess and doesn't seem to take the paranoid precautions you need in Perl when running system() and other interaction with the outside world - precautions particularly needed in a CGI program that's meant to be publicly accessible. I am a keen Perl programmer but TWiki is the kind of code that gives Perl a bad reputation.
That said, in an environment where you trust everybody (like a company webserver accessible only on your network) TWiki is a very handy application. I rather like the grungy way it keeps page content in RCS archives; you can hack up scripts to automatically import your existing static HTML pages into the wiki. But if I were installing a new wiki now I would use something else: preferably the kind of wiki that works by generating a set of static HTML pages and updating them on edits. That seems to have the smallest attack surface and the best performance.
Nope, it's because DOS (following VMS convention) used slash for options. For example DIR/OD to sort by date. AFAIK, all versions of DOS (since 2.0) and Windows have accepted both \ and / as directory separator, although many userland applications may insist on \.
If printing paper notes is theft, then mining new gold out of the ground must also be theft, since it dilutes the value of the gold already out there?
Remember too that most of the money in circulation has never existed as notes or coins. It is created by banks making loans.
Printing money indiscriminately is a bad idea, but the picture is more complex than you suggest.
The tragic thing is that this function doesn't even do what it says. If a and b are large enough, it won't return a + b, nor even give an error, but instead return some wrapped-around crazy value, which is almost never what you want.
Do you have any performance/power figures for IBM's chips versus Intel's? I am thinking of general purpose computing, so ATI and Nvidia are out, at least until you can run Postgres, gzip, Apache, perl, Java and C# directly on a GPU core. Agreed that for number crunching and floating-point heavy applications you'd be wise not to rely on Intel's general purpose x86 chips.
Does the cost of Microsoft Windows included with a server include a support subscription comparable to Red Hat's? If not, you are not comparing like with like.
The fair comparison is: Windows licence plus support contract versus RHEL subscription,
or: Windows licence with no support versus CentOS with no support.
OK so if you have a PUE of 1.2 then five-sixths of the input energy is used to power the computer equipment. But that doesn't say how energy efficient the machines themselves are. You could be running 150W Pentium 4 Extreme Edition processors, or whatever, and still get a higher 'efficiency' than someone using Atom processors giving the same computational speed with lower power usage.
In the old days I would have suggested that Microsoft was limited to x86 processors and so they would necessarily have higher power usage than Google, who would be free to use more power-efficient architectures like ARM or PowerPC. But I get the feeling this isn't true nowadays. In servers and high-end desktops, do Intel x86 chips now offer the best bang per watt?
That's what everyone does anyway!
Is anyone able to sleep when they are not tired? Who ever heard of stuffing food into yourself even when you don't feel hungry?
Is there some parallel universe where people don't feel the natural bodily impulses of hunger and tiredness, and have to rely on Slashdot advice to tell them to drink when thirsty and scratch their own itch?
Whenever you read these overclocking and gaming sites it gets really tedious that they always have to call a computer a 'rig'. But finally, we have an instance where the name is entirely appropriate.
I gave up reading the article when the author starts talking about 'java benchmarks' when he means Javascript...
On a two's complement 16-bit machine it would be -32768 surely?
You can do basic functional programming in Perl but more advanced stuff becomes a real pain because of the lack of static type checking. Once you start having multiple layers of map or foldr or monads or whatever, you really need a type system like Haskell's to catch mistakes for you. With Perl you end up with undefined value warnings at run time and spend ages putting in debugging print statements to figure out what's going on. On the other hand, of course, many programming styles are much easier in Perl than in Haskell.
If you think that anybody can change the source code, then just try it. Get a line or two of your code into Linux, Firefox and Openoffice.
Don't you mean a 64 bit ARM? (called Leg?)
No problem, if Apple hasn't included Firewire then just buy your next Mac from any one of the wide range of competing hardware vendors... right... right?
Using a Mac means you have to bend over for Steve Jobs. It's pointless complaining about it.
Nowadays making sure your site is valid HTML is easy. Just install the excellent HTML validator plugin for Firefox. It gives you a tick or cross icon on each page; double-click the cross to view the page source with a list of errors. It does the validation locally on your machine, not sending the content off to some server, so it's fast.
If you're writing dynamically generated pages it is a great way to find bugs in your code, and it's unobtrusive enough to leave it turned on all the time.
Yeah, dammit, why are all the cast so frickin' *young*? And too good-looking IMHO. Science fiction shouldn't be spoiled by hunky young beefcake any more than by pneumatic Borg-enhanced female lifeforms. One or two green aliens is okay, but the bridge of the Enterprise is not a shaving foam commercial.
Actually it has 8 * 500 trillion offsets since a 500Gbyte drive is 4000 gigabits. So 47 bits of randomness. I take your point though, it's not much.
Conceivably you could hide each bit of your 256 bit key at a different place on the disk... but I doubt a court would buy that argument even if the earlier one had some hope of working.
I just downloaded truecrypt-6.0a-opensuse-x64.tar.gz without problems to my PC sitting within 500 metres of St Paul's cathedral. A file failing to download is hardly unknown. A conspiracy theory should be the explanation of last resort, not the first.
Suppose some incriminating evidence exists but it is hidden in a secret location. Can you be forced to disclose that location?
If not, then why not store your encrypted data on a huge partition of random data. To get it you need both the key and the location of the data. The latter you can simply refuse to disclose.
So you've given up on the relatively open PC platform and gone to a console which is far more locked down and DRM'd than anything from Microsoft or Apple. This doesn't show that DRM or anti-piracy measures (note: the two are not the same thing) are bad for business: it shows that they are good for business provided they are done well (which in practice means locking down the rest of the system under a single company's control).
This is really great news. We already have IRC bots that can fool the casual observer into thinking they are human, but this takes things to a higher level. If the source for one of these bots is available, within a few months you can expect instant messaging networks to be full of bots which are programmed to make friends with you and then after a few weeks start making subtle references to Viagra and online pharmacies. Indeed, if one of them is able to chat up the ladies, then the lonely nerd could easily automate much of the tedious work of setting up dates: get your robot to talk to thousands of potential matches at once and alert you when it gets hold of a phone number, together with a brief summary of what you talked about, and any pictures. (Or indeed, just program it to harvest pictures.) That is, if online dating works at all, which is doubtful.