The vserver will be upgraded the first of June. There will be some downtime while copying the FS to a larger partition.
Update: The server has been upgraded. A little bit later though than expected.
The vserver will be upgraded the first of June. There will be some downtime while copying the FS to a larger partition.
Update: The server has been upgraded. A little bit later though than expected.
Haochi has plotted the inbox size of gmail over time, interesting.
[tex]\displaystyle e=\lim_{n\to\infty} \left(1+\frac{1}{n}\right)^n[/tex]
Yay, it seems the wordpress [tex]\TeX[/tex] plugin works.
sudo
is evilsudo
, the *nix tool with which you can easily execute commands as a super user is harmful.
The idea behind sudo
is good. You are able to execute super user commands — offcourse when the super user has allowed you — without having to log into the super user.
The problem though is that the default configuration of sudo only asks for the password of the current user, when he first uses it. That means that if the security is breached of the user, which could happen, it can simply use sudo
to gain access to root, for it is very likely that users who have enabled sudo
, use it a lot.
My recommendation: don’t use sudo
, if you haven’t explicitly configured it to require your password every single time you use it — use su
instead.
update: If you want to force sudo
to ask your password every time you use it, add this in your /etc/sudoers
:
Defaults timestamp_timeout=0
They could’ve used a more sensible name for that in my opinion. I had to read the manual carefully before I found out it was this entry.
The best way to keep your e-mail address secure from evil spam bots is some kind of javascript and obfuscation, which unfortunately isn’t always available. There are enough alternatives though.
Usually people tend to replace the ‘@’ with some short replacement like ‘{at}’ or ‘bij’. This just doesn’t help.
Any programmer with a bit of knowledge of regex can create a program that scans for domain names and interprets every small bit of text in front of it as an @ sign.
Some smarter people also replace the dot. This works, unless your email-host uses a easily recognizable TLD (.com) or domainname (gmail.com).
Also putting ‘SPAM’ in your email-adress some.personREMOVETHISFORSPAM@foo.bar is easily filtered.
Best thing is to use something out of the box.
For instance, my email address is X@Y, where:
X = bas.westerbaan
Y = gmail.com
Also I’ve got an email-address on w-nz.com, namely bas.westerbaan.
Or even maybe w-nz.com@bas.
I’ve disabled anonymous comments for my blog, because my blog is spammed with ~100 spam-comments a day — it seems they’ve worked around Hashcash 3.0. I’ll look into this a bit more when I’ve got time. Sorry for the inconvenience.
Update Seems it were nasty trackbacks instead of comments. So I just disabled trackbacks. You can comment again.
SINP is a set of protocols to transfer a profile/identity; to authenticate owners of identities and negotiate for restricted information in protocols. It’s designed to be simple, being based on HTTPS and XML.
You can find the first draft here.
Subversion repository: https://cvs.codeyard.net/svn/webid
Acknoledgements: it’s loosely based on other stuff that has been floating around the web, like Zef’s SPTP.
Comments would be appreciated.
Update: Photo’s are in of the presentation we’ve given about SINP last wednesday:
http://www.codeyard.net/fotos/capaward-1.php
Our presentation has got several penguin mascottes.
I’ve just downloaded my whole GMail account via POP3. Each message is stored as-is, including headers and attachments in base64, in a seperate file.
du -ms on the folder with all emails tells me:
2117
While GMail tells me:
You are currently using 2079 MB
Why this difference, I asked myself. Was there a difference in the way e-mail was stored? Actually I stored my e-mail very inefficiently. E-Mail is 7bits encoded — every character is 7 bits — where my FS (like virtually every other) stores each character in a 8bits. Lets calculate the actual size of email on my disk:
>>> 2117 / 8 * 7
1848
It gets even more absurd considering that the most part of that space is used by attachments in emails, which are encoded in Base64, which uses 6bits per character. At least 50% of these 2GB are attachments, thus:
>>> 2117 / 8 * 6.5
1716
Why am I using 2079MB according to GMail?
GMail wouldn’t require 2079MB for my emails, they probably compress all attachments and old mails, they won’t even come near that 2079MB. It would therefore seem logical that they would use the real size of all emails — which should at least match the 1848MB or 2117MB, but it doesn’t.
Anyone got a good guess?
Disclaimer: This isn’t in any way meant to be anti-gmail — I love gmail, everyone loves gmail! I’m just curious.