Useful stuff for your blog-reading pleasure.

All | General

Friday February 20, 2009

Challenges and Opportunities 2009

Me speaking at #cando09 This Wednesday I was invited to speak at "Challenges and Opportunities 2009", an informal, almost barcamp-like gathering of startup companies and other bright and innovative people in the center of Munich. The name is the topic and so the focus was on how to make the best of the current economic situation. Surprisingly, the overall feeling of the conference was quite relaxed, almost cheery, as if the econonmy wasn't really that relevant. Just the right attitude to have, I'd say.

Nicholas MacGowan von Holstein of Twidox.com took the effort of putting this event together, which was a remarkable feat, given that he was in the middle of entering open beta with his startup at the same time. Twidox is a new startup company that offers a platform for the collaborative exchange of high-quality documents. The idea comes from Nicholas' experience during his university days where students would spend a lot of time researching publications and trying to find relevant papers to a certain topic. Twidox lets you both publish and search for documents and helps you make sense out of them through tagging, rating and other mechanisms. Actually, there are quite a few parallels to our own SunSpace document management system and so it was not surprising to see Nicholas and Peter having a great interest in each other's work.

Each presentation was limited to 5-10 minutes which was a good thing to keep the pace going. We heard from Terry Bibra about Yahoo's strategy of openness, Stephan Uhrenbacher from Qype talked about principles they observed when creating their startup, Ingo Dahm from Microsoft highlighted some opportunities that today's technologies offer and Nicholas Kirschner of High-Tech-Gründerfonds offered his insight as a venture capitalist about the good, the bad and the ugly of VCs during difficult times. The ticketing logistics of the event were done through Amiando, a fast growing German startup that provides streamlined ticketing operations to everyone. Felix Haas from Amiando offered his own views as a startup, highlighting flexibility in finding the right business model and pointing out that startups don't necessarily need to go for a multi-million Dollar exit.

My own talk was about "Survival 2.0", inspired by Tim Bray's "The Fear Factor" talk at FOWA 2008 that he also elaborated about in a series of inspiring blog posts. Tim talked to developers, so I mixed in some of my own experience of having gone through the Dot-Com Bubble and made a 5-point list of tips to get you through tough times, that everyone of us can use today. Most, if not all of these tips are just common sense, it's just that we sometimes tend to lose our common sense when the going get's tough...

The fine people at Tiburon-TV have recorded the talk and you can watch a video of "Survival 2.0" here. The slides are available from Twidox as well. It's all in German but if you're interested, I can send you a translated version of the slides so you can use them for your own presentations.

Also, check out the Twitter buzz around this event's #cando09 hashtag. It's quite fascinating how dynamic instant communication has become today...

"Challenges and Opportunities 2009" has been brought to you by Constantin's Blooog.
This entry was created on 2009-02-20 02:07:25.0 PST and is associated with the following tags:
challenges events opportunities presentations startup tips twidox videos web2.0
You're welcome to use this Permalink , add a comment below or send your feedback to constantin at sun dot com.

Thursday November 01, 2007

7 Tips for Enhancing Your Email Efficiency

I think I sent my first email in 1987. We lived in Rome, Italy and my brother and I shared a modem with which we collected our very first online experiences on a Commodore Amiga 500.

Today I receive about 500-700 emails a day on my Sun account. Not counting Spam (most of which is filtered by our mail system anyway). That's a lot, but over time I grew accustomed to dealing with more and more email as efficiently as possible.

Here's what helps me use email as a productivity tool rather than a burden, while still having fun. This is going to be a long post, but if your Inbox currently has more than 100 emails, possibly sitting there for more than a week or two, then I promise you an easy to use way of getting your Inbox to 0.

Zero mails in your Inbox. Once and for all. Still, you will be informed about what's going on and it'll be earlier, with less effort, and more reliably.

The Email Client

In my email carreer, I've use a lot of mail clients. During university days I started with the classic mail(1) on SunOS 4 and it's counterparts on VMS and on an IBM 3090 mainframe. Then I've used Elm for a long time, then Pine. When I joined Sun in 1998, one of the first things I did was to compile myself Pine so I could keep my habit of reading email on a terminal.

Why on a terminal? It's always quicker and more efficient than a GUI (Yes, I'm one of those old-schoolers that still prefer vi as their favorite text editor). It really is. So much that I'd like to make it...

Email-Efficiency Rule #1: Make sure you can use your email client with keystroke commands only.

When dealing with hundreds of emails, the extra time to move the mouse cursor and to click on some buttons etc. really adds up. Learning keystrokes might seem tedious at first, but it will quickly become second nature and you'll be amazed at how quickly you can scan through emails with just one hand sitting on your keyboard, while having your other hand free to drink coffee while reading email.

After a while, I migrated to another email client called Mutt. This introduced two major new features that made my email-life much, much easier: Threads and Filters.

A threading email client automatically groups emails that have the same subject (or that are related to each other based on the header information) into threads. Threads are more efficient to read because they contain all emails related to a certain subject or conversation in one go. And more importantly: You can delete dozens of "Please take me off this list" or "me too" emails and other uninteresting discussions with a single keystroke!

Mozilla Thunderbird supports threads very nicely, so does Apple's Mail and of course GMail, only they call it "conversations" (and they dig up all related mail from the past too, which is very nice).

Message filtering is another powerful feature of modern email clients. It lets you pre-sort email into folders or assign different colors/priorities/etc., based on simple rules. I don't feel comfortable with automatically filing away emails without at least looking at their subject. So I use rules exclusively to assign priorities to emails: Emails that are addressed directly to me or come from my management chain automatically get prioritized highest. Emails where my email address shows up on the CC line or that is addressed to working groups that are dear to my heart get the second highest priority. All other email gets normal priority. Emails from Sun get a different color than external email. Other similar rules are of course possible and can be very useful.

Using filters makes it easy to get a picture of what's going on when you only have a few minutes to check email in between meetings or when on the go, without risking to overlook any important email. Therefore, let's postulate...

Email Efficiency Rule #2: Let your email client do the reading before you do.

I now use Mozilla Thunderbird to read my Sun email. At some point, I just felt that there has to be a way to efficiently read email and still use a GUI, and Thunderbird is quite good at it: It supports keystrokes, threads nicely, you can program complex rules to pre-digest email easily and it is multi-platform, open source and contributed to by Sun.

With threading and rule-based priority sorting enabled, my 500-700 emails a day split into about 10-20 "Highest" and another 30-40 or so "High" priority emails. This is much more manageable as I can work through the higher prioritized emails with a more concentrated mind before quickly scanning through the rest just in case there's something interesting there.

For my personal email, I use Google's GMail, because it completely outsources my need to archive emails, has a great browser-based user interface that can be accessed from anywhere (even a mobile phone) while still feeling like a real application and of course it suppors keystrokes, has very nice threading support and it supports filters too.

After my company gave me a Nokia E61i so I can read email on the go, I had a new problem: Nokia's email client doesn't support threading nor message filters (please tell me if you know a better email client for SymbianOS), and hundreds of truncated sender/subject lines on a mobile phone aren't really useful. So let's have a look at the server side of the picture:

The Email Server

Today, the two main mail server protocols are POP3 and IMAP4. POP3 basically dumps all your email onto your client, then (optionally) forgets about it as soon as you connect to your mail server. Not good if you're on the go. And then you need to take care of all archiving yourself. And what if you access the same mail box from different clients?

IMAP4 on the other hand lets your client choose whether to only pull headers or the whole message, it supports server-side folders to sort your mail into and you can keep your mail on the server while accessing it from multiple clients out of multiple devices and still everything stays perfectly synchronized.

So, whenever possible, choose IMAP4. If you can't choose IMAP4, change your email service. Fortunately, Google just introduced IMAP4 support, in case you want to read your Mail with something else than their web interface.

Thanks to IMAP4, we don't have to organize our mails on our clients, instead we should go by...

Email Efficiency Rule #3: Keep your emails on the server, always.

Really. There's no point in downloading all your email to some client that can suffer a hard-drive crash or a virus infection or whatever. Chances are that your email server is a much more reliable machine than your email client and it minimizes the bandwidth needed to read and manage emails to what your brain can handle without downloading hundreds of emails that you'll never read past the subject line. You can still dump your favorite folders to disk or to a CD for archiving purposes, once in a while, if you want to.

Back to my mobile-phone-can't-thread-nor-prioritize problem. One feature of the Sun Java System Communications Server that we use is server-side filtering. It lets you forward, file or delete mails based on simple rules. Again, I like to be conservative here, so I never want to automatically delete anything, just file away what I know for sure is not important enough to waste my precious mobile phone's bandwidth with.

The utter majority of the emails I get are from internal and external mailing lists that I subscribed to or not or that otherwise find my email Inbox. These are natural candidates for "If the mail was addressed to <insert mailinglist alias here>, then file it to <some folder>" type of rules. Keeping it simple, I only use one folder for this purpose, called "ToBeRead". You could also name it "Inbox2" or "Later" but the important thing here is to actually treat this folder as a real Inbox folder the next time you have some time and a more comfortable client. Don't create a growing monster pile of unread mail because you started playing with rules, it won't really help you.

Email Efficiency Rule #4: Let your email server do some reading, too.

Sorting email on your server is different from sorting email on your client: The former gives you a bandwidth choice that enables the use of mobile devices or helps you quickly check email through a web interface (by pre-sorting email into folders), while the latter helps you look at your email in the right sequence (by threading and prioritizing it).

I just checked my Sun mail through the Nokia E61i after not having checked mail for a day (today is a bank holiday in Bavaria) and I have 47 new mails. I didn't check my ToBeRead folder, but I'm sure it has more mails than I can handle on a mobile device comfortably. Seems to work for me (and I've seen a couple of mails that will make nice new rules to my server-side filter).

I usually don't check emails after work hours, in the weekend or during bank holidays. I seem to be immune to the Crackberry disease, which I guess is a good thing. This brings us to the most important Email efficiency part of all:

Email Workflow

One of the first trainings that Sun sent me to after I was hired was about time-management. This is a fascinating subject by itself but it turns out that a lot of the principles taught under the umbrella of time-management can be applied beautifully to organizing your email.

If you're looking for a great blog on the subject of life hacks (a term for "when geeks start digging into time and self management") then check out Merlin Mann's "43Folders". If you prefer to read a book, then I can highly recommend David Allen's "Getting Things Done" (GTD).

Here's an easy but very efficient email workflow that is very similar to the GTD workflow:

Go to the next email in your Inbox and ask yourself:
"Do I need to do something because of this email?" (or: "Is it actionable?")
- If the answer is "yes", then you either have to reply to the email or do some action that is associated with it. Now ask yourself:
  "Can I do it in less than 2 minutes?"
- File away or delete the email. There's no more reason for it to sit in your Inbox.
Go to 1.

After a couple of iterations, you should have an empty Inbox. Really. 0 emails. Take a deep breath, celebrate and get used to it.

"But now I have this big and long to do list!" I hear you say. Well, that might be true, but a to-do list and an email Inbox are really two different things. Email is for communication, your to-do list is a way for you to organize your tasks. Never mix them up.

The important thing here is to get rid of all those emails in your Inbox. Feel the joy of hitting the delete key or filing away that email with the knowledge that it has been dealt with, once and for all!

Email Efficiency Rule #5: Develop an email workflow that helps you clean your Inbox.

You're invited to try the above workflow or you can develop your own. The point is to have a system that helps you get your Inbox to zero and free your mind for what's really important (Hint: It isn't email). Your workflow should be easy to implement, no matter how, where and when you read email. There should be no excuse left that prevents you from cleaning up your Inbox.

Having an empty Inbox has a great motivational power. You'll feel as if a big weight has been taken off your shoulder. You'll feel free to actually get some work done, instead of looking at all those emails. Try it out just once, but beware: Having an empty Inbox can be highly addictive...

Two things are left now: Dealing with that long to-do list and an easy and efficient way of filing those emails that you've dealt with already. As said, dealing with to-do lists is the subject of a whole science and I can only encourage you to check out one of the many sources on time and self management. This introduction might be a good start.

So what to do about filing emails? I know quite a lot of colleagues with elaborate folder systems that they use to file their emails and stuff in. One can base a filing structure on project names, client names, products, events, themes, priorities, whatnot. My easy answer to this problem is: File everything into one single folder, then let the computer find it when you need it.

Really, it works. Modern email clients are very good at searching through vast amounts of email. In fact, thanks to IMAP, it's actually the server that does it for you. I have just one single folder on my mail server that I use for filing mail away, it has thousands of emails and it is called "file". That's it.

You still think it can't be that simple? Well the ultimate test is: Will you be able to find any particular email quickly and easily? With an elaborate filing system, based on many different folders, this may or may not be the case. I've seen many colleagues try different folders while desperately looking for that one important email. Did I sort it into the client's folder? Wait, it was related to that project so it's probably in that folder. Or was it in "Pending"?

If you only have one folder to file stuff in, you rely on using your email client's search mechanism. This gives you at least four different ways to search for an email:

By person: If you're looking for a particular email, you probably remember its sender or recipient. Search for that person, then find the email in the results. Done.
By keywords in the subject: Think of one or two words that are guaranteed to show up in the subject of the mail you're searching for.
By time: Some study has found that the most brain-friendly way to organize stuff is by date/time. Try to remember the point in time you got or sent that email, then scroll back in time in your filing folder. This works best for emails associated with projects, stuff that is quite recent, etc.
Full text search: If all else fails, do a full text search. This shouldn't happen often, but works as a last resort. And it's reasonable quick on modern computers. Quicker than going through all those other folders...

Of course, combinations work well, too. Searching by person, then subject or time usually works for me 99% of the time. I only need to resort to full text search about once every 6 months.

Email Efficiency Rule #6: File away your email and let the computer do the searching.

Filing or deleting? When in doubt, file! Storage space has become cheap and search algorithms have become so powerful that there really is no reason not to file everything. Google has made this a major point when advertising their GMail service, and they're right.

So we now have found a good email client that supports keystrokes. We teached it how to thread and how to prioritize our emails. We like to keep emails on the server because they're really better off there and we let the server do some pre-work so we can deal with low-bandwidth situations. We've developed an email workflow that empties our Inbox in no time and an easy way to file all those emails too, relying on our computer's ever increasing power to always find what we look for.

We're almost in email heaven now, but we want to make sure to stay there and avoid going back to email hell after the next period of hectic activity or after a long vacation that filled up our Inboxes to DOS-inducing levels. We want to attack the problem at the root.

Remember those server-side rules that said "Email addressed to X should be filed into Y for later review"? Well, why did you subscribe to that newsletter/mailing list/discussion group in the first place? Is email really the right way to stay current on a certain subject?

The truth is: No. Email is a communication mechanism between people who know each other and have to say something to each other. It is not a news delivery mechanism (RSS can do that better and more efficiently). It is not a way to gather and harvest information (Google and other search engines on the internet can do it better). And it is not a discussion forum (Use Newsgroups, IM and chat or web based forums).

So let's go through our server-side rules and ask ourselves: Do I really want to keep subscribed to this service? Why don't I switch to a pull model for staying informed where I'm in control vs. being flooded by all those "informational" emails that I don't have the time to read anyway?

There's also email minimization potential with day-to-day emails to and from your co-workers. Do you really need to forward that email to your 30 or 100 other co-workers that may or may not be interested in that particular news item? Is that joke, video, URL really so funny that your entire office has to look at it? Do you really want to be "kept posted" on all minutiae of that process or just receive a short "done" notification at the end?

Email Efficiency Rule #7: Go on an email diet. Limit newsletters/mailing lists/mass emails to a necessary amount and write/forward emails only when necessary. Especially when addressing a large group of people.

I know that this rule is the hardest. But think of it. It makes sense. It may not be easily implemented everywhere (And I'm known for being an occasionally passionate participant in large email discussions myself), but using the right information resource/channel for the task at hand is often a very good idea.

Let me know if the above tips and rules are helpful to you. Share your own secrets of email efficiency. Let me know how large your Inbox is and whether you like it or not. What is your perfect way of dealing with large amounts of email?

"7 Tips for Enhancing Your Email Efficiency" has been brought to you by Constantin's Blooog.
This entry was created on 2007-11-01 15:56:50.0 PST and is associated with the following tags:
effectiveness email gtd hacks life management time tips useful
You're welcome to use this Permalink , add a comment below or send your feedback to constantin at sun dot com.
Comments [2]

Thursday September 06, 2007

7 Easy Tips for ZFS Starters

So you're now curious about ZFS. Maybe you read Jonathan's latest blog entry on ZFS or you've followed some other buzz on the Solaris ZFS file system or maybe you saw a friend using it. Now it's time for you to try it out yourself. It's easy and here are seven tips to get you started quickly and effortlessly:

1. Check out what Solaris ZFS can do for you

First, try to compose yourself a picture of what the Solaris ZFS filesystem is, what features it has and how it can work to your advantage. Check out the CSI:Munich video for a fun demo on how Solaris ZFS can turn 12 cheap USB memory sticks into highly available, enterprise-class, robust storage. Of course, what works with USB sticks also works with your own harddisks or any other storage device. Also, there are great ZFS screencasts that show you some more powerful features in an easy to follow way. Finally, there's a nice writeup on "What is ZFS?" at the OpenSolaris ZFS Community's homepage.

2. Read some (easy) documentation

It's easy to configure Solaris ZFS. Really. You just need to know two commands: zpool (1M) and zfs (1M). That's it. So, get your hands onto a Solaris system (or download and install it for free) and take a look at those manpages. If you still want more, then there's of course the ZFS Administration Guide with detailed planning, configuration and troubleshooting steps. If you want to learn even more, check out the OpenSolaris ZFS Community Links page. German-speaking readers are invited to read my german white paper on ZFS or listen to episode #006 of the POFACS podcast.

3. Dive into the pool

Solaris ZFS manages your storage devices in pools. Pools are a convenient way of abstracting storage hardware and turning it into a repository of blocks to store your data in. Each pool takes a number of devices and applies an availability scheme (or none) to it. Pools can then be easily expanded by adding more disks to them. Use pools to manage your hardware and its availability properties. You could create a mirrored pool for data that should be protected against disk failure and that needs fast access to hardware. Then, you could add another pool using RAID-Z (which is similar, but better than RAID-5) for data that needs to be protected but where performance is not the first priority. For scratch, test or demo data, a pool without any RAID scheme is ok, too. Pools are easily created:

zpool create mypool mirror c0d0 c1d0

Will create a mirror out of the two disk devices c0d0 and c1d0. Similarly, you can easily create a RAID-Z pool by saying:

zpool create mypool raidz c0d0 c1d0 c2d0

The easiest way to turn a disk into a pool is:

zpool create mypool c0d0

It's that easy. All the complexity of finding, sanity-checking, labeling, formatting and managing disks is hidden behind this simple command.

If you don't have any spare disks to try this out with, then you can just create yourself some files, then use them as if they were block devices:

# mkfile 128m /export/stuff/disk1 # mkfile 128m /export/stuff/disk2 # zpool create testpool mirror /export/stuff/disk1 /export/stuff/disk2 # zpool status testpool pool: testpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM testpool ONLINE 0 0 0 mirror ONLINE 0 0 0 /export/stuff/disk1 ONLINE 0 0 0 /export/stuff/disk2 ONLINE 0 0 0 errors: No known data errors

The cool thing about this procedure is that you can create as many virtual disks as you like and then test ZFS's features such as data integrity, self-healing, hot spares, RAID-Z and RAID-Z2 etc. without having to find any free disks.

When creating a pool for production data, think about redundancy. There are three basic properties to storage: availability, performance and space. And it's a good idea to prioritize them in that order: Make sure you have redundancy (mirroring, RAID-Z, RAID-Z2) so ZFS can self-heal data when stuff goes wrong at the hardware level. Then decide how much performance you want. Generally, mirroring is faster and more flexible than RAID-Z/Z2, especially if the pool is degraded and ZFS needs to reconstruct data. Space is the cheapest of all three, so don't be greedy and try to give priority to the other two. Richard Elling has some great recommendations on RAID, space and MTTDL. Roch has also posted a great article on mirroring vs. RAID-Z.

4. The power to give

Once you have set up your basic pool, you can already access your new ZFS file system: Your pool has been automatically mounted for you in the root directory. If you followed the examples above, then you can just cd to /mypool and start using ZFS!

But there's more: Creating additional ZFS file systems that use your pool's resources is very easy, just say something like:

zfs create mypool/home zfs create mypool/home/johndoe zfs create mypool/home/janedoe

Each of these commands only takes seconds to complete and every time you will get a full new file system, already set up and mounted for you to start using it immediately. Notice that you can manage your ZFS filesystems hierarchically as seen above. Use pools to manage storage properties at the hardware level, use filesystems to present storage to your users and applications. Filesystems have properties (compression, quotas, reservations, etc.) that you can easily administer using zfs set and that are inherited across the hierarchy. Check out Chris Gerhard's blog on more thoughts about file system organization.

5. Snapshot early, snapshot often

ZFS snapshots are quick, easy and cheap. Much cheaper than the horrible experience when you realize that you just deleted a very important file that hasn't been backed up yet! So, use snapshots whenever you can. If you think about whether to snapshot or not, just do it. I recently spent only about $220 on two 320 GB USB disks for my home server to expand my pool with. At these prices, the time you spend thinking about whether to snapshot or not may be more worth than just buying more disk.

Again, Chris has some wisdom on this topic in his ZFS snapshot massacre blog entry. He once had over 60000 snapshots and he's snapshotting filesystems by the minute! Since snapshots in ZFS “just work” and since they only take up the space that actually changes between snapshots, there's really no reason to not doing snapshots all the time. Maybe once per minute is a little bit exaggerated, but once a week, once per day or once an hour per active filesystem is definitely good advice.

Instead of time based snapshotting, Chris came up with the idea to snapshot a file system shared with Samba whenever the Samba user logs in!

6. See the Synergy

ZFS by itself is very powerful. But the full beauty of it can be unleashed by combining ZFS with other great Solaris 10 features. Here are some examples:

Tim Foster has written a great SMF service that will snapshot your ZFS filesystems on a regular basis. It's fully automatic, configurable and integrated with SMF in a beautiful way.
ZFS can create block devices, too. They are called zvols. Since Nevada build 54, they are fully integrated into the Solaris iSCSI infrastructure. See Ben Rockwood's blog entry on the beauty of iSCSI with ZFS.
A couple of people are now elevating this concept even further: Take two Thumpers, create big zvols inside them, export them through iSCSI and mirror over them with ZFS on a server. You'll get a huge, distributed storage subsystem that can be easily exported and imported on a regular network. A poor man's SAN and a powerful shared storage for future HA clusters thanks to ZFS, iSCSI and Thumper! Jörg Möllenkamp is taking this concept a bit further by thinking about ZFS, iSCSI, Thumper and SAM-FS.
Check out some cool Sun StorageTek Availability Suite and ZFS demos here.
ZFS and boot support is still in the works, but if you're brave, you can try it out with the newer Solaris Nevada distributions on x64 systems. Think about the possibilities together with Solaris Live Upgrade! Create a new boot environment in seconds while not needing to find or dedicate a new partition, thanks to snapshots, while saving most of the needed disk space!

And that's only the beginning. As ZFS becomes more and more adopted, we'll see many more creative uses of ZFS with other Solaris 10 technologies and other OSes.

7. Beam me up, ZFS!

One of the most amazing features of ZFS is zfs send/receive. zfs send will turn a ZFS filesystem into a bitstream that you can save to a file, pipe through bzip2 for compression or send through ssh to a distant server for archiving or for remote replication through the corresponding zfs receive command. It also supports incremental sending and receiving out of subsequent snapshots through the -i modifier.

This is a powerful feature with a lot of uses:

Create your Solaris zone as a ZFS filesystem, complete with applications, configuration, automation scripts, users etc., zfs send | bzip2 >zone_archive.zfs.bz2 it for later use. Then, unpack and create hundreds of cloned zones out of this master copy.
Easily migrate ZFS filesystems between pools on the same machine or on distant machines (through ssh) with zfs send/receive.
Create a crontab entry that takes a snapshot every minute, then zfs send -i it over ssh to a second machine where it is piped into zfs receive. Tadah! You'll get free, finely-grained, online remote replication of your precious data.
Easily create efficient full or incremental backups of home directories (each in their own ZFS filesystems) through ZFS send. Again, you can compress them and treat them like you would, say, treat a tar archive.

See? It is easy, isn't it? I hope this guide helps you find your way around the world of ZFS. If you want more, drop by the OpenSolaris ZFS Community, we have a mailing list/forum where bright and friendly people hang out that will be glad to help you.

"7 Easy Tips for ZFS Starters" has been brought to you by Constantin's Blooog.
This entry was created on 2007-09-06 11:20:15.0 PST and is associated with the following tags:
adoption community data filesystem free howto innovation introduction open opensolaris opensource software solaris storage tips unix zfs
You're welcome to use this Permalink , add a comment below or send your feedback to constantin at sun dot com.