Daniel0

The carriage return is incredibly annoying when working in vim. I hate that character.

Just found out they made an official announcement on their blog: http://googleblog.blogspot.com/2008/09/fresh-take-on-browser.html Beta release tomorrow... I just hope it will not be an infinite beta like Gmail is. Here is a quote from Slashdot: I think those a good arguments.

http://www.ietf.org/rfc/rfc2616.txt

Hehe... did you read the comic? Google lives on the internet so they have an interest in making it a better place

A three strikes out method works fine. We do it on the PHP Freaks servers for SSH logins using denyhosts. If you have three failed login attempts within an amount of time (can't remember how much) then you get your IP in /etc/hosts.deny and that file is huge. Agreed on the prepared statements. I haven't been using anything else for a long time.

http://blogoscoped.com/archive/2008-09-01-n47.html If this turns out well and I can get something like Firebug and Adblock Plus then I'm sold. Nonetheless, it sounds interesting.

Heh... I'm sure you're going to get some biased opinions when asking here. This is a website for PHP developers after all. Nevertheless, I think that Ruby is a good language, but I hear it has some performance problems. I haven't confirmed that in any way at all though, so it might not be true.

You could make a community of dermatologists where you can discuss various deceases, new techniques/treatments, etc. Kind of like PHP Freaks, only about dermatology instead of PHP.

First of all, congrats on your graduation Regarding those websites, I think their layouts are horrible. The last one, DermNet, doesn't look so bad, but just pretty plain (the web developer on that site must've had one of them "actinic keratosis horns" inside his brain when he wrote the HTML markup though). If you're good at designing then that's something you could take a look at. Nevertheless, I don't know anything about dermatology, but a directory over the various deceases you can have sounds like a good idea. Of course, it has been done so you need to make sure that yours is better and it has at least as much information as the other ones do.

I use CheapVPS and I pay £9/month (ex VAT). I've had no problems with them except that they interpret having irssi running as "using IRC" whereas I interpreted it as running an IRCd. That resulted in my account getting shut down temporarily without notice.

That is in fact white listing, you allow a very particular thing while everything else gets rejected. There is nothing that prevents a whitelist to use wildcards. The opposite is a black list where you disallow something very particular and allow everything else. A whitelist will in almost every case be better.

I wouldn't call Wikipedia an extensive resource to the entire subject of DNS.

64 MB RAM is unlikely to be sufficient. You have to consider that the various daemons and the OS itself will use some of the memory. On a shared server there is dedicated an amount of memory for that purpose and the rest will be used for the individual applications that runs on the server. On my VPS I have 256 MB guaranteed RAM and double the amount burst. That means if it's available then I can have an additional 256 MB, but only if it's available.

They're not shut off per se, the layout is just messed up. Hell, you can browse with IE v1 if you like, chances are just that you will have an incredibly poor experience (as you would with any other version of IE).

Though i've not read anything about this in relation to sha1(), it has been suggested that applying the md5() algorithm twice increases the chances of collisions - e.g. the chances of two inputs having the same output. I've not seen any concrete proof of this either way, but it seems rather pointless in any case. A salt is perfectly adequate. That's true, it will increase the chances of a hash collision because the sample size will be minimized twice. There is another problem with solely relying on double hashing - you can still crack it! If the algorithm is known then it's just a matter of computation power and time before it's brute-forced. It's also still as vulnerable to dictionary attacks as just a single run through a hashing algorithm. The great thing about salts is that first of all it adds random data to the string so that renders dictionary attacks completely useless. Moreover, if you add something like a 30-char long salt then brute-forcing it will take considerably longer time (long enough time that it wont even happen within a billion years with the computational power that's available today). It's imperative that you keep the salt absolutely secret, otherwise it's completely useless. You might also consider to add the salt into different parts of the original string before hashing it so that even if people get the salt then they won't know where it belongs in the string. Another issue you (waynewex) address is the visibility of files that lie within document root. The fix is simple: move it to a directory above document root. If people are not supposed to request the file directly (e.g. an image, stylesheet, javascript file or index.php) then it doesn't belong within document root. I've written an article about PHP security here on PHP Freaks: http://www.phpfreaks.com/tutorial/php-security It does obviously not address everything under the sun, but I feel it's a good primer for security related issues.

Well, it is of course up to you to decide whether you think that you can live without those users. Here I decided that IE6 will not be supported on the main site for instance. That's a significantly larger portion of the potential users than those who browse without Javascript. Well, they can still view it but it doesn't look very good.

Security, freedom of choice, technical limitations. links for instance does not support Javascript. People might want to disable it to prevent things like XSS entirely and some people might just think that Javascript is annoying. Doing unobtrusive Javascript isn't that difficult. You could even make a secondary HTML-only version like Gmail does.

If they told you to shut down 21 and 80 then just change the port number...

"Never" is the keyword here. You cannot possibly know if you at a later time would want a group between admins and regular users, say a moderator for instance.

Why would that be bad, ober? If you need to periodically check if there is new mail on a mail box then I see no better solution than doing so unless you've got direct access to the mail server itself.

Exactly. It'll occur for about a minute every hour. The only solution I see is to setup a MySQL replication server and do the backups there. We'll need another server to do that and I doubt Eric, the owner, will like that seeing as he already pays a lot of money for keeping this site running (way, way more than the donations give).

We have the same problem here (I think). We do an hourly backup of the database and during that time the CPU usage jumps to 100% which results in unresponsiveness on the webserver. Unfortunately, we've yet to find a working solution to that problem.

If it occurs when there is a spike in mail activity on that box then I would say, yes, the problem lies within that box.

I just have my laptop, it's creatively named daniel-laptop. Then I have a vps, it's named after the main domain of the vps...

No spaces