2010 November

 

 Trustfabric or, “Can halp me?”

November 30, 2010

So, a while ago (like three months ago), I got an email from Joe to beta TrustFabric.

It looked a little like this:

from TrustFabric
to rodent {at} rodent.za(.)net
date Tue, Oct 19, 2010 at 10:12 PM
subject TrustFabric Alpha Invite
mailed-by li41-197.members.linode.com
hide details Oct 19
Hi,

Joe Botha has invited you to join TrustFabric.

To join the TrustFabric Alpha service please follow this link:
http://www.trustfabric.com/?invite_code=….

If you like TrustFabric feel free to invite your friends via the Invite page.

Please keep up with TrustFabric news:
Blog: http://www.trustfabric.org/
Twitter: http://twitter.com/TrustFabric

————–

Welcome to a new way of thinking about personal information management.

TrustFabric simplifies the admin in your life. It’s a safe and easy way to
selectively share the personal information you are required to share.

During the sign up process you’ll be asked to chose a TrustFabric
Identifier (TFID). Once you’re signed up you can create documents,
establish relationships and control who you share your information with.

We’d like to hear your feedback on:
* Usability
* Features you’d like to see

Please note:
This is an Alpha version, it can break or go down. We’re aiming to add
features every month from now on, so it will probably be down for upgrades.

Have fun.

Regards
The TrustFabric Team

The conundrum, or my memory fails

Today, I was trawling my (mostly unread) personal mailbox and came across the invites, and thought: “Hey, let me try this TrustFabric thing” — Joe’s been blogging about it a lot!

So, I cannot recall whether I actually clicked on the link or not (my longterm memory is handled by my mail client and browser password agent).

But the invite link is now dead, it just takes me nowhere. And when trying to login with my usual credentials, I get a simple “Login Failed”, with a faint reference to retrieve my password.

And I can’t recall whether I gave TF my details or not, or actually registered. (Typical user conundrum).

The invite link (http://www.trustfabric.com/?invite_code=xxxx) just displays the usual site without any additional information like “This invite has already been used”, or anything useful. In fact it appears to be a bog standard redirect to the main page.

So, I tried “password retrieval”. When prompted for my TFID I just hit my email address, which apparently doesn’t work. And my cellphone number either.

So, here’s my conundrum. Am I registered ? If at least the invite link told me that I’d already used it, I’d have been reasonably sure. Right now I don’t whether I registered or not. I also don’t know where to go from here, or contact to do anything. I’m lost. I got an invite. But it’s either invalid, or expired, or I never used. I also dunno how to fix this…

Either way, I have no idea of finding out what my TrustFabric status is.

Note to web 2.0 people — If you send out a link, that may persist in an email for years, or months best you make sure that it continues working or displays something useful. An HTTP link with query string arguments is a CONTRACT. Dont’ BREAK IT.

Joe. Whip.them.programmers.some.more….

And HALP!

Update

Apparently my invite was used, and my TFID is NOT my email addy but my Nick. Thanks for the help Joe!

Internet | 1 comment
1 response to “Trustfabric or, “Can halp me?””
  1. Joe says:

    I’m guessing your invite was used.

    TDIF: rodent, joined 2010-10-19 23:24:26

    Let me know if you can’t reset your password and I’ll send you a new invite.

    Thanks for the suggestion above. Feel free to email me or use the feedback form inside the TrustFabric UI if you have more suggestions.




 

 Linux splice() and company

November 9, 2010

So, I’ve been working as ever, hard on getting some stuff to scale.

For example Lusca/Squid.

I’ve already done the non-threaded async event driven loop, for neoGUARDIAN, our transparent SMTP cunning gadget, and it’s been doing great snooping on SMTP traffic to find out if you’re a spammer or not.

I used Danga::Socket and some clever linux ioct’ls to get full transparency incorporated, meaning that you wouldn’t even know if I’m snooping on your TCP port or not. Interestingly enough, the interpreted perl is not whatsoever the bottleneck. I’ve been quite impressed with the scalability of the thing, especially when offloading the hard work to a Gearman style worker asynchronously.

Now, however something else has grabbed my attention.

The linux splice() and tee() syscalls.

Imagine a file descriptor, hooked up to a client socket, and another to a server socket. Typical relaying proxy style.

Now, instead of having to read() from one copying stuff to a buffer and then write()ing it to another buffer, you can simply tell the linux kernel to connect the two socket handles together, and the kernel will take care of connecting the source and destination without any user space copying.

Now add a tee() similar to the Unix “tee” command, and you can write the data being sent and received by ┬áthe two sockets to disk. In fact, they don’t even need to be sockets.

Can anyone say caching proxy ? Lusca has really made some strides in breaking out this kind of code so that it can be modularized, but it’s still going to take some serious hacking because the old squid code base really does depend so much on memcpy()ing things around.

The splice() functionality also supports splicing()ing from virtual memory and other kind of neat things.

It’s in my mind the ultimate way to get to the ZeroCopy style of I/O.

Certainly, portability is an issue, but then again, most modern systems start emulating Linux syscalls simply due to their elegance. It wasn’t always so, in fact Linux emulates a lot of BSD/SySV style stuff, but that comes with the Unix domain…

The question is… Is portability in code worth the performance penalty?

I’m almost keen to start a Lusca Linux-only port. Quite frankly I haven’t given a toss about portability ever, and I’m sure it would probably end up being a better product. Take nginx for example. Yes it will run on win32, but it sucks.

If your Operating System ┬ákernel doesn’t support some standard features required to get scalability then I’m sorry, but you’re fucked. Why should developers have to #ifdef crap just to make sure it compiles on some ancient thing?

The Java fanbois will probably jump at this opportunity to indicate the portability and awesomeness of their environment, but all I can say is that not living close to the kernel will always mean that you’re screwed due to the happy “compile once run anywhere” mantra. Good luck in “import System.Socket.Splice” or whatever it might be called in Java.

For me, it’s simple, either port it to your kernel or whine at your vendor (futile, isn’t it?)

In my mind it’s time to pick a platform and let the kernels match the portability. The effective implementations will survive. The crap ones will die.

Natural select()ion for the win.

Unix Development | Leave a comment