Tilda is a drop-down terminal for linux. Press the assigned hotkey and the terminal will dropdown and gains focus, press it once again and it’ll dropout. And even better, the terminal isn’t closed, just hidden.
This is great for development. I write some code, press Ctrl+S to save, Alt+Q for the terminal and make. If there is a bug I can Alt+Q and return to my code, and if I didn’t look closely enough I can press Alt+Q again to see the output again in the terminal.
Tuesday the 11th, we (Noud, Bram and I) had a meeting with some guys of the Security of Systems Group at the Radboud University. We discussed the security of the current SINP protocol. There hasn’t been a hard verdict on whether SINP is secure, because the SINP specification leaves a lot of details to implementations and SINP doesn’t make hard claims on its security yet (which can be either proved or disproved).
The meeting has yielded two new additions to SINP: document certificates1 and redirects.
First of, SINP document certificates. At the moment you can’t trust the information in a SINP document. I can forge my SINP document and claim that I’m Belgium, which I am not. To allow some trust which some people and services care about, we’ll allow certificates in your identity document. Basically you let someone sign a part of your SINP document and include that certificate.
Your goverment could sign your name in your SINP document for instance and you’d add that certificate into your document, which could be required by some services. These certificates are a bit tricky though to design, because they do need to be secure and they need to be a bit more dynamic than your usual certificate because of the way SINP documents are queried.
A second problem we encountered during the meeting was how to be able to trust your SINP server. I (and other tech savvy people) can set up their own SINP server, which we can fully trust because we set it up ourselves. Not so tech savvy people can’t — they need to rely on existing SINP servers. The problem is whether we can trust those servers with our secrets.
Cees (if I recall correctly) coined the idea that some of your secrets are already on the internet. If you’ve got a VISA creditcard number, then VISA obviously has that creditcard number, and you trust them with it. What if VISA would store the part of your SINP identity document with your creditcardnumber on its own SINP Server?
Basically I go to a big SINP provider (which I don’t trust), I create a SINP identity and put in my SINP document that you can find my creditcard number under the SINP identity bas@visa.com. This act of redirecting clients to other SINP identities is called a SINP Redirect. SINP Redirects could also proof very usefull when you change your SINP server. The only thing you’d have to do is to set up a SINP redirect in your old identity document to your new identitiy document.
Both SINP Certificates and SINP Redirects will require a lot of though to implement cleanly and simple, which is tricky.
Any thoughts would be welcome.
1: Actually, this certificates aren’t new, Bram came up with the idea quite a while ago.
Wouldn’t it be nice to have:
begin {
&nsbr;LoadTheDatabase("foo.bar");
} rescue (Exception e) {
print "Fatal exception happened: ", e
} on (Warning w) {
print "Database Warning: ", w
} on (Message m) {
print "Database Message: ", m
}
The rescue (Exception e) should be familiar with everyone — something failed, maybe the database file was corrupted very bad, and raised an exception and the rescue block will be executed.
But what if the database has a small error, or something is only a little bit out of place. You wouldn’t want to just ignore it, but warn about it. Usually one would implement a ‘Logger’ class to which a function can log certain events, but that is ugly and inconvenient.
Enter non fatal exceptions. Basically there would be two ways to raise an exception, fatal like we all know it, and non fatal. When the on block for a non fatal exception has been executed, control will be returned to the function in which the raise was called.
This is done in about the same ways as a lot of languages implement yield. But this time the handling code depends on the type of the yielded object.
As far as Kaja and I concern this will be a feature of Paradox.
Thanks go to Bram for the idea.
irb> require 'sinp'
irb> c = SINP::Client.new nil, nil, [:http]
irb> c.getPublicDocument('Kristy@w-nz.com').write
<requested version='2'>
<sinp-id>
<name><nick>kristy</nick></name>
<address type='email'>kbuiter@hotmail.com</address>
<uri>hotmail.com</uri>
</sinp-id>
</requested>
As you can see, I’ve almost finished the implementation of a Ruby SINP client — I only got to finish SINP Negotiation.
SINP is a protocol based on HTTP(S) and XML that provides you with an identity on the web. You register a so called SINP Identity on a SINP Server of your choice. To address a certain identity, we use an email like notation: bas@w-nz.com is the SINP Identity of the user bas on the SINP Server w-nz.com.
The first big feature of SINP is authentication. If someone claims to be bram@w-nz.com, I can check that by asking w-nz.com to check it. I’ll redirect that guy to w-nz.com to let him be checked by his proclaimed SINP Server. If he really is bram@w-nz.com, he’ll have a nice session cookie for w-nz.com and w-nz.com will check that. After that w-nz.com will redirect him back and I’ll ask w-nz.com whether he succeeded.
One major application of this authentication is that someone who posts a blog comment as noud@w-nz.com, really is/are the same guy(s) that posted before as noud@w-nz.com, for they are allowed by w-nz.com.
The second big feature of SINP is that each identity comes bundled with a XML document, which can store information about the owner like his name, email address, date of birth, etc. The SINP Server stores this document. The identity owner, the guy who owns the identity, can pick an access policy for each little bit of information in this document. You might want to share your real address only to those who you’ve explicitly allowed. Everyone can see the parts of your document you’ve allowed everyone access to. This is the one for bas@w-nz.com.
To get specific parts instead of the whole thing, or get to stuff you’ve limited access to, one needs to use SINP Negotiation. To get some specific information from noud@w-nz.com, I ask w-nz.com for this specific information, in the form of a few xpaths. Along with the xpaths I can send my own SINP address, bas@w-nz.com. The server will respond on each request according to the access policy which the SINP Server has set. There are several possibilities:
bas@w-nz.com, you can see it. You’ll have to authenticate, though. This is done via sinp authentication as described before.Another big feature of SINP is versioning, which allows caching. The version of a specific bit of information is send back on each response in negotiation. In a negotation request, I can specify the current version I already have. In case that specific part of the document hasn’t updated, the SINP server will let me know, instead of sending the whole thing.
One advantage of caching and negotation is that information can be kept synchronized with your document when it updates. A blog, on which you’ve posted a comment, might periodically check whether the information it retreived from your SINP document has changed. This can be done cheaply with negotiation and versioning.
SINP is easy to implement, it is quite simple. It also is portable, it uses widely supported technologies like XML and HTTP(S) as its base.
SINP is under development, but you can already (and really should) take a look to:
SINP is based on things I’ve seen floating around on the web, for instance Zef`s SPTP.
At the moment of writing we’re developing a PHP client, a Python client and continueing development of the PHP server. You’re welcome to participate!
We hope you like it, comments or any other forms of participation would be very welcome.
Bas, Bram and Noud.
SINP, a protocol that provides you with an identity that allows authentication and negotation of information linked with the identity as an identity document (basically the whole functionality put into a way too short sentence), which was deviced by Noud, Bram and me, has won the Capgemini Opensource Award! Lots of rejoice! You will hear more about this :-).
I’ve had to test some website I designed on IE (VMWare offcourse) and it went really bad. IE 6 sucks, that’s for sure. It was a blow in the face for me, because everything went so terribly smoothly, escpecially the CSS.
I was wondering whether it would be as bad in IE 7 as in 6, so I installed it (Genuine Advantage doesn’t work by the way).
I was amazed by the amount of improvement they made.
The website was a mess in IE6: backgrounds wouldn’t show up; no attribute selectors on CSS; blocks were positioned in absolute ridiculous locations. Whereas in IE7 it showed up pretty nicely compared to 6. It wasn’t perfect though, there were quite a few glitches in positioning (go IE box model!) and font sizes, but that’s managable.
I wonder whether IE7 took so long and why it still isn’t as bug-less and feature-complete as almost every other big browser. If microsoft wanted to make a perfect browser, they could do it easily! They’ve got more than enough very talented people and even more than enough money to hire/bribe any expert they’d want.
Maybe they’re afraid of big AJAX applications. I bet gmail took a pretty big market share of outlook. At least, that is what other people are thinking. They may be right, but google wasn’t stopped by the bugs in IE, google doesn’t use nice and semantically correct HTML (and it is the correct stuff that usually doesn’t work on IE), they just use the stuff that works anyway.
More likely they don’t care. They force website devs already to create sites that show up properly in IE, just because of its market share. Only website creators feel the pain of the buggy IE engine, not the users of the browser. Besides that it could be a pain for them to create a whole new IE, which needs to be backwards compatible with the old IE. A lot of people would be angry if their site doesn’t show up properly anymore in the new IE — and these people can’t be persuaded with the nice semantics ideology.
A little bit more pressure by alternative browsers could force microsoft to release something more profound than IE7. Although IE7 is an improvement, they could have done better.
Hash Tables are widely used in server software. A malicious user can easily forge keys in the communication with the server that will result in hashes from the keys so that they will end up in the same bucket. This will force the hashtable to grow each time this bucket is filled.
In a worst case implementation, this will result in an enormous amount of empty buckets and only one full bucket. Even if the implementation is smart and will therefore only will grow the targetted bucket, the hash table will fail its use. The hash table is meant to make lookups for a key fast by distributing the pairs in buckets, this effect is gone when all pairs are located in one bucket, which will cause linear time look-ups.
One malicious user won’t be able to crash a server, but a DDOS attack with several users would be tremendously more efficient when targeting this weakness in hash tables.
A simple solution would be to randomly pick a salt for the hash function on each new instance of a hash table. Basically we prefix each key with a random salt before we hash it. The malicious user might know the hash function, but he has to guess the salt, which neglects the effect.
Additionally logic could be added to detect an unbalanced hash table and switch the salt on when the table is unbalanced.
This could also be usefull to balance hash tables when there is no malicious user, but the keys are possibly unfortunate.
Raidcore hasn’t released drivers that support gentoo linux, only precompiled drivers for the other big distro’s.
I’ve managed to get the drivers for the bc4000 series to work on Gentoo Linux 2006.0 on linux-2.6.16-gentoo-r9 for the bc4852 card.
You need the driver SDK, which contains the source of the precompiled drivers they distribute.
I had to tweak some kernel configurations to get it to work — first of I had to turn the ‘sysrq magic key’, although it seems easy to remove all sysrq usage in the drivers itself iif you aren’t comfortable with sysrq.
I had to switch from ‘discontiguous memory’ to ‘sparse memory’ layout — the driver relies on the availability of ‘mem_map’.
In the Makefile of the bcraid there’s an issue with the PLATFORM define. It should be defines with ‘uname -m’ instead — otherwise it won’t link in the binary blob.
The bccfg init script they provide seems terribly useless, adding ‘bccfg’, and ‘bcraid’ for that matter, to /etc/modules.autoload.d/kernel-2.6 does just as fine, but cleaner.
Initially it seems that everything works fine, although I’m a bit worried about a lot of errors related to the bccfg device nodes in dmesg.
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.
last.fm is a (omfg! web2.0) service that tracks the music you play. You just install a plugin for your favourite music player and all songs you play will be send to the site. They will create nice charts, make recommendations and lots of other fun stuff.
Oh look, it even has got syndication! (my recently played tracks)
You can see nice charts about my music here.
You’ve got to love the web2.0 impact on aprilfools:
A search engine in a few lines of code with SQL on rails.
The .tgz you can download is (deliberately) corrupted. You can still recover some amusing stuff from it. Give it a try.
While working on paradox, Kaja and I felt that we needed a cross-platform threading library, which handles all the subtle differences in capabilities and semantics of each platform`s API.
After a rewrite of Kaja`s original code, I present to you ithreads. You can find the source in this subversion repository.
svn://w-nz.com/px
At this moment ithreads gives you implementations of:
Mutex
By using (one or more of) the following APIs:
ithreads will use generic implementations in case one of the primitives (eg. Semaphore for pthreads) isn’t available on your system.
I’m espacially happy with the futex based implementations. They outperform the pthreads implementation, and are a lot smaller (4 vs. ~16 bytes for a mutex in pthreads) – although they aren’t as robust (but still correct).
Support for BeOS, OS/2, Windows and more will be added, but testing them will be tricky.
The library will still need a lot of stress testing and probably still contains some bugs – you’re warned. When everything works nicely I’ll add all kinds of extra flavours of the primitives, eg. read-favouring r/w-lock.
I hope it will prove useful.