An evening with the family...

shouldn’t we finally move away from this ugly MoinMoin theme? It’s not only the most ugly and spartan theme one could imagine (it even beats our main web presence in ugliness) — it does not even try to comply with some corporate design. The only things that remind me that I’m actually surfing a Debian related site are the URL and the words “Debian Wiki” on the top left. (There is a chance that the link-colors match the Debian-Red too, but I’m slightly colorblind, so I’m not sure) MoinMoin can do better. Please look at Ubun… oops I mean bazaar’s homepage, they’re using MoinMoin too and it looks much more appealing than our wiki.

Whilst downloading, installing and running Debian packages is easy, fun and “free”, most Web applications aren’t. I can’t be the only one that thinks there is a problem somewhere as for example, where are the all the Web applications listed on Freshmeat? I have an idea for a Web application though I thought it would be cool to make it as Free software though it can be a pain.

• Getting a reliable host
• Host has to be Debian and probably unstable to get the cool stuff :)
• You probably want to have root, hence dedicated
• It is probably expensive and you might have to watch bandwidth
• You have to create accounts, where your colleagues also want root.
• You could use sudo though you’ll probably get frustrated with it and end up with “ALL = NOPASSWD: ALL” and no one checks the logs ;)
• You’re probably want Xen and a few IPs
• Since Web application packaging with current tools is near impossible with all the different httpds and DBMSes, you’ll probably have to use some odd hand crafted setup.
• You will probably want a DBA sooner or later, to figure WTF is going on with your DBMS ;)
• You’ll probably end up with a several step build&deployment process (that’s bad)
• Testing (if you ever get that far) will probably be a kludge
• To lower the barrier of entry, you will probably go for PHP which is great to deploy. Scary to secure.
• Though non-PHP avenues will probably require FastCGI. And FastCGI on Apache last time I checked is PAIN.
• Your developers probably can’t run the Web application locally as it such a pain to setup (esp. forget offline)
• You might have some “privacy policy” that makes sharing log or database data difficult amongst developers.
• Your Web application will probably need mail server access at all the pain that comes with that.
• Your application will have to deal with difficult abuse problems like spam that ordinary applications don’t usually deal with.
• If your project’s site becomes popular you’ll have a ton of maintenance and scalability head aches that will probably require money to be thrown at the problem.
• Someone will think your Web design stinks. Then if you use some “designer”, he creates some awful XHTML template and some fixed px style sheet with images replacing text. ;)

I think there is a few more “barriers to entry” problems running a Web application as a free software project. Web hosting is generally quite poor and a lot of the Web centric deployment/packaging tools aren’t up to scratch. Though there are a couple of amazing examples of “open source” Web sites, like the stuff My Society do. Nonetheless I would like to see Debian as an even better Web application platform.

Whilst downloading, installing and running Debian packages is easy, fun and “free”, most Web application services aren’t. I can’t be the only one that thinks there is a problem somewhere as for example, where are the all the free software Web services listed on Freshmeat? I have an idea for a Web application though I thought it would be cool to make it as Free software though it can be a pain.

1. Getting a reliable host
2. Host has to be Debian and probably unstable to get the bleeding edge stuff :)
3. You probably want to have root, hence dedicated
4. It is probably expensive and you might have to watch bandwidth
5. You have to create accounts, where your colleagues also want root.
6. You could use sudo though you’ll probably get frustrated with it and end up with “ALL = NOPASSWD: ALL” and no one checks the logs ;)
7. You’re probably want Xen and a few IPs
8. Since Web application packaging with current tools is near impossible with all the different httpds and DBMSes, you’ll probably have to use some odd hand crafted setup.
9. You will probably want a DBA sooner or later, to figure WTF is going on with your DBMS ;)
10. You’ll probably end up with a several step build&deployment process (that’s bad)
11. Testing (if you ever get that far) will probably be a kludge
12. To lower the barrier of entry, you will probably go for PHP which is great to deploy. Scary to secure.
13. Though non-PHP avenues will probably require FastCGI. And FastCGI on Apache last time I checked is PAIN.
14. Your developers probably can’t run the Web application locally as it such a pain to setup (esp. forget offline)
15. You might have some “privacy policy” that makes sharing log or database data difficult amongst developers.
16. Your Web application will probably need mail server access and all the pain that comes with that.
17. Your application will have to deal with difficult abuse problems like spam that ordinary applications don’t usually deal with.
18. If your project’s site becomes popular you’ll have a ton of maintenance and scalability head aches that will probably require money to be thrown at the problem.
19. Someone will think your Web design stinks. Then if you use some “designer”, he creates some awful XHTML template and some fixed px style sheet with images replacing text. ;)

I think there is a few more “barriers to entry” problems running a Web application service as a free software project. Web hosting is generally quite poor and a lot of the Web centric deployment/packaging tools aren’t up to scratch. Though there are a couple of amazing examples of “open source” Web services, like the stuff My Society do. Any other good examples? Nonetheless I would like to see Debian serve as an even better Web application platform. Update: I think “services” makes more sense than “application” in this context… I hope you’ll agree.

Ok, so Xfce 4.4.1 (bugfix release) is out since some days. I've packaged this new version, which is mostly ready in our svn. So 4.4.0 won't be uploaded to unstable at all, and we will upload directly 4.4.1 in sid in some days. The thing which blocked us to upload to unstable was gtk2.10, and it has been uploaded yesterday, so nothing is blocking now and we should be able to upload really soon.

The packages are available from my repository for ppc and sparc. I've changed the layout to add an UNRELEASED branch, so people using it are warned that those packages are even more unstable than unstable. Those packages are packages which have not been uploaded to debian, and thus may be unusable.

Alway prefer packages coming from pure Debian repositories, but if you want to test and help us correct mistakes, you can use the repository (and report bugs to our mailing list).

For etch users, I'll prepare 4.4.1 backports, but as I don't have hardware access, they will be only ppc and sparc binaries. Maybe other will be able to build backports for other arches.

While taking a coffee break while driving to Dudesconf in A Coruna today, I saw Hamburg in the news on spanish TV. It seems the weather in Hamburg is so good currently, that it's newsworthy on spanish TV :-)

As long as it doesnt rain too much, I dont care about the weather... And currently I'm happy to sit here in a gym with around 20 Debian geeks, and look forward to get some Debian stuff done on the weekend... debian-community.org really deserves some attention, but I won't be surprised if dont find time the next 36h.

For those who wonder: Dudesconf really is DebConf.es3 - I have no idea why it's not called like this.

Waking up at 5am (I know, not a decent hour, though I don't choose when a plane leaves), cycling to the railway station with all my luggage (no buses drive that early...), taking the train (actually 3 trains as there are 2 stops) for 1.5h, arriving at the airport, hearing about some strike, checking in and being told strike will be over when my plane takes off (9am), waiting, plane being delayed till 10am, waiting, plane being delayed till 11am, waiting, plane being delayed to 1pm, eating, waiting, plane being delayed till 3pm, queueing for information (which was going to take ages), plane being cancelled. Apparantly some firemen didn't like that they didn't get food tickets nor paid overhours I should have known that taking a plane to Spain is risky. My previous attempt: ... arriving in the airport, trying to be checked in, being told that tickets have been cancelled, making calls, being told that travel agency forgot to confirm a second time and that new tickets have been booked for 2 days later, going home, night before take off seeing that ticket to Spain has been cancelled (ticket back still valid), going to the airport anyway, being called that everything is ok, arriving at the airport, being told that I have 2 tickets for the same flight... Sorry to the people who expected me to be in Spain, I'm not going to try my luck again tomorrow, though I'll try to be happy on IRC

Yesterday afternoon, we started our information meetings with employees about our Linux on the desktop project. We're underway on our migration.

But before I talk about that, I need to back up and describe what the project is.

We are converting approximately 80% of our 150 or so PC users to Linux desktops. They're Debian etch (4.0) running Gnome, Firefox (Iceweasel), Evolution, NFSv4, and SystemImager. Over the coming days and weeks, I'll be writing about why we're doing this, how we're making it happen, things we've run into along the way, and the technology behind it.

Today I'd like to start with a high-level overview of the reasons we started investigating this option.

It became apparent that Vista was going to be a problem for us. Most of our desktop PCs are not very old, but Vista meant a significant degradation in performance from the Windows XP Pro that most people were running. A performance dip so significant, in fact, that it would have created a significant negative impact on employee productivity.

We tend to buy PCs with Windows licenses from the vendor (Windows preinstalled). As such, we knew it wouldn't be long before XP-based machines would be hard to find. If we stuck with Windows, we'd be running a mixed-OS network -- which we knew from experience we did NOT want to do. The other option would be to replace all those old PCs. The direct costs of doing that, with the associated Vista and Office licenses, would have been more than $200,000.

So we started to look at other options -- changing the way we license Windows, sticking with XP for awhile, or switching away from Windows. This last option sounded the most promising.

I took a spare desktop-class machine, representative of the hardware most end users would have, and installed etch (then testing) on it. I spent a bit of time tweaking the desktop settings, making things as transparent to the user as possible. We liked what we saw and started pursuing it a bit more. We knew we had some Windows apps we couldn't discard, so we tested running them off a Windows terminal server with the Linux rdesktop client. That worked well -- and the appropriate Server 2003 licenses plus CALs would still be far cheaper than a mass migration to Vista.

To make a long story short, we are getting quite a few benefits out of all this. One of the most important is a single unified system image. Excepting a few files like /etc/fstab, every system gets a bit-for-bit identical installation from the server, updated using rsync. /home is mounted from the network using NFS (v4). So our users can sit down at any PC, log in, and have all their programs, settings, email, etc. available. A side benefit is that hardware problems become minor annoyances rather than major inconveniences; if your hard disk dies, we can just bring up a different PC. We had tried numerous times to make roaming profiles work in Windows, but never really achieved a reliable setup there -- perhaps because it seemed virtually impossible to assure that each Windows PC had the exact same set of software, in the exact same versions, installed.

More to come.

As mentioned previously I was invited to talk about Debian at the Long Island Linux User Group. Much to my embarrassment I had forgotten I had actually spoken at this venue before way back in 2003. But the audience (which of course included many members who had joined since then) were receptive, and asked lots of questions which I like. I did my "Three Pillars of Debian" talk updated for Etch with snazzy new slides — feel free to use them in your own presentations if you like. I was supposed to speak for two hours and ended up speaking for three. So hopefully I managed to impart some useful information and maybe make some new recruits. I would like to publically thank John Teddy and all the people at LILUG for inviting me. Also, note for the future: I really ought to learn how to correctly pronounce Hocevar. Sam, you should put up an audio clip somewhere.

A lot of people have asked me about the Tim Wu piece in Slate about Wikitravel. I've commented already about the article in Wikitravel's Logbook: 8 April 2007. The upshot: Wu got a lot of things really wrong about Wikitravel (like saying we didn't have any hotel listings for Bangkok). But if our readers get things wrong, that means Wikitravellers need to do some more work to help them get things right. User errors are developer errors writ large; we can do better. But I think Tim Wu missed the main reason Wikitravel guides will always be better than proprietary guides: they are Free Cultural Works. Where I come from, that means a lot. I wrote to Tim about his article, and he responded really kindly. The thing I liked most is that when he got home, he updated Wikitravel with the information he picked up on his trip to Thailand. That is pretty cool. I'm not taking others' responses to the article too seriously. Wikitravel got a Webby Award nomination for Best Travel Site the same week. As Tom Wolfe said, "The lead dog is the one they always try to bite in the ass." And Oscar Wilde: "The only thing worse than being talked about is not being talked about." (Thanks to Hugh!) tags: wikitravel travel tim wu slate

Off to San Juan We're getting prepared this morning to head out to Puerto Rico for the first annual World-wide Wikitravel Get-together. Our flight leaves at 2:20PM, so we've got kind of a leisurely morning to get ready. As usual, we're pretty tense: what are we forgetting? And I usually get hung up on unnecessary stuff to deal with. I should probably print out the Spanish phrasebook from Wikitravel, because my Spanish is pretty rusty. And I should download all the WT pages about Puerto Rico destinations to my laptop, just to know where we should fill in. And we can't find the charger for our camera's battery. And I want to bring a certain pair of cargo pants, but there's a button missing. Do I have time to sew on another? Of course, all these anxieties melt once we get out of the house and into a taxi to the airport. Once you can't do things, you stop worrying about what you should do. I think. The more I learn about Puerto Rico, the more fascinated I am. San Juan (Puerto Rico)'s Old Town is a UNESCO World Heritage site. The giant telescope at Arecibo is world-renowned as the SETI site. The islands of Vieques and Culebra are isolated and fun, and Fajardo and Rincon has world-class surfing. My friend Biella Coleman gave me a great list of travel tips for San Juan and Culebra, which have been a big help in our planning. OK, enough blogging: gotta get to work sewing on that button. (I've been stalling long enough for Maj to have found the camera charger under a baseball hat. Yay!) tags: get-together07 wikitravel travel Puerto+Rico biellacoleman

Today's post (previous parts) tries to show what benefits other init systems can offer.I'm picking 'minit' as an example; not because it's the ultimate solution or anything, but because I happen to know it quite well. I used to be the package maintainer for some time, and I've also used it on an embedded system (where it was a perfect match). However, it's not very distribution-friendly; it's great when you can invest some time into configuring it (such as when building an embedded system) but not when it should ideally work automatically out of the box. The Debian package is still there, but it's orphaned. Still it's well written, clean code; there shouldn't be any bigger bugs in there.The first thing to notice is that minit is tiny. It's statically linked, but only about 6.5 kb. Regular init is 86 kb plus some libraries (despite actually not doing much during init!). This makes it very well-suited for embedding.But now for the benefits of minit over regular init:1. Service monitoring. This is the biggest point: minit will keep an eye on the services and restart them when needed. (Another thing very useful in embedded situations, btw.)Minit doesn't use the start/stop paradigm of sysv/shell-style-init. Instead it has a "run" script for every service. If a service is flagged as 'respawn', it will automatically be restarted when the run script quits; therefore the applications should not background themselves. This offers some benefits, for example the init process will be notified by the kernel of a termination, and can immediately respawn the service; in contrast to other monitoring systems suchas monit it doesn't rely on 'busy polling'.2. Dependency handling. Minit handles startup dependencies. If a service lists another service as a dependency, it will bring that service up first.3. Parallel startup. Unless an ordering is given via dependencies, minit will start the services in parallel.4. Control apps. In minit, you don't start a service by running some random shell script. Instead you call "msvc -u servicename", which will signal minit to bring up the service (and it's dependencies). This would (there currently is no policy for minit) be especially useful in SELinux, but it also allows to e.g. give a user the permission of running "sudo msvc -u" without introducing a huge security hole, since this cannot be used to execute arbitrary scripts. "msvc" can also be used to check if a service is up. (Another benefit for embedded systems, since that removes the need for pid files, which then need a ram (writeable) filesystem)I'll also give an example for a minit service:A service is represented by a directory in /etc/minit which can contain various files. I'm going to look at getty/1 example; which will bring up a console login on the first terminal. There are three files:

• a symlink named 'run' to /sbin/getty, which is the daemon we want to bring up
• a file named 'params' containing the parameters for the getty application, one per line
• an empty file named 'respawn', since we want the login screen to reappear

If the service would need it, there could also be a file called "depends" listing service dependencies.This allows minit to start the getty with no overhead. There is no shell script being executed or anything (note: sysvinit also does this for gettys, but it's not being used much for other services).Of course minit isn't perfect. I've already said that it isn't particularly distribution friendly. This is because it uses a lot of magic files (e.g. an empty file named 'respawn' to flag a service as needing to be respawned), and it's configuration files aren't easy to handle automatically. The often frowned-upon 'symlink farms' of sysv-shell-style init are much better here.Another thing that is missing from minit is an automatic rollback of dependencies. If we told minit to bring up service 'a', which lists dependencies 'b' and 'c', minit will bring these three up. If we tell it to shutdown 'a', it will however not shutdown 'b' or 'c'. And unfortunately, even if we shutdown 'b', it won't shutdown 'a'. If you want a more complex dependency handling (or things such as runlevels), you need to do this externally. (An example is my 'enitdir' app, it adds runlevel support to minit, and allows switching of runlevels by replacing a symlink; Services are added and removed from runlevels by adding a symlink to the service into the runlevels directory. By using dnotify, this also takes virtually no CPU time.)Minit also lacks a differentiation between a 'started' and a 'running' service. It has support for 'sync' services, such as e.g. mounting a filesystem. It will wait for this operation to complete before it starts services depending on it. However, there are services that will continue to run, while not being instantly available when the exec() was called. Sometimes it would be nice if a service could go into a 'started' state, then do some cleanup work, and then when actually running the real service signal minit that it's now 'running'.As a last malus, minit won't print progress messages to the console. A minit boot is pretty much silent, directing it's output to some logging processes. There are good reasons for this (since services are started in parallel!), but it makes debugging harder, and users might be wondering what their system is actually doing (though some users prefer to see a colored 'busy' bar)...I guess this concludes this series of blog posts. Maybe someone can follow up with some details on upstart (which seems to be the most promising init replacement)? I hope to have given an impression on where there is room for improvement in our current init to one or the other. Now we just need some people to actually work on a better support for other inits in Debian...

I have just read the Presentation Zen blog post about PowerPoint.

One of the interesting suggestions was that it's not effective to present the same information twice, so you don't have notes covering what you say. Having a diagram that gives the same information is effective though because it gives a different way of analyzing the data. I looked at a couple of sets of slides that I have written and noticed that the ratio of text slides to diagram slides was 6:1 and 3:1 in favor of text, and that wasn't counting the first and last slides that have the title of the talk and a set of URLs respectively.

So it seems that I need more and better diagrams. I'll include most of the diagrams I use in my current SE Linux talks in this post with some ideas on how to improve them. I would appreciate any suggestions that may be offered (either through blog comments or email).

The above diagram shows how the SE Linux identity limits the roles that may be selected, and how the role limits the domains that may be entered. Therefore the identity controls what the user may do and in this example the identity "root" means that the user has little access to the machine (a Play Machine configuration). I think that the above is reasonably effective and have been using it for a few years. I have considered a more complex diagram with the "staff_r" role included as well and possibly including the way that "newrole" can be used to change between roles. So I could have the above as slide #1 about identities and roles with a more detailed diagram following to replace a page of text about role transition.

The above diagram shows the domain transitions used in a typical system boot and login process. It includes the names of the types and a summary of the relevant policy rules used to implement the transitions. I also have another diagram that I have used which is the same but without the file types and policy. In the past I have never used both in the one talk - just used one of the two and had text to describe the information content of the other. To make greater use of diagrams I could start with the simple diagram and then have the following slide have all the detail.

The above diagram simply displays the MCS security model with ellipses representing processes and rectangles representing files.

The above diagram shows a simplified version of the MMCS policy. With MMCS each process has a range with the low level representing the minimum category set of files to which it is permitted to write and the high level representing the files that it may read and write. So to write to a file with the "HR" category the process must have a low level that's no higher than "HR" and a high level that is equal or greater than "HR". The full set of combinations of two categories with low and high levels means 10 different levels of access for processes which makes for a complex diagram. I need something other than plain text for this but the above diagram is overly complex and a full set is even more so. Maybe a table with process contexts on one axis, file contexts on another and access granted being one of "R", "RW" or nothing?

I also have a MLS diagram in the same manner, but I now think it's too awful to put on my blog. Any suggestions on how to effectively design a diagram for MLS? For those of you who don't know how MLS works the basic concept is that every process has an "Effective Clearance" (AKA low level) which determines what it can write, it can't write to anything below that because it might have read data from a file at it's own level and it can't read from a level higher than it's own level. MLS also uses a high level for ranged processes and filesystem objects (but that's when it gets really complex).

This last one is what I consider my most effective diagram. It shows the benefits of SE Linux in confining daemons in a clear and effective manner. Any suggestions for improvement (apart from fixing the varying text size which is due to a bug in Dia) would be appreciated.

The above diagrams are all on my SE Linux talks page, along with the Dia files that were used to create them. They may be used freely for non-commercial purposes.

If anyone has some SE Linux diagrams that they would like to share then please let me know, either through a blog comment, email, or a blog post syndicated on Planet SE Linux.

The desktop enviroment is not a religious thing for me. IMHO, they all (3 of them) have missing parts which are present in the others. I never really used Xfce.

OTOH, I have been switching back and forth between GNOME and KDE during my time as a GNU/Linux user. Since I always found that one of the environments was missing things which were present in the other, I think I have switched at least 3 times both ways by now.

Now, with the release of GNOME 2.18, I will have one less reason to think to move away from GNOME, which is the current desktop environment. One of the apps I was missing in GNOME was a filelight-like application that would show usage in a very intuitive graphical way. Now it seems that baobab (commonly known as Disk Usage Utility) has a ring chart similar to filelight's. Yay!

Now, if somebody would take the task of rewriting granslator, I would be more than glad to drop kbabel...

Note: I was disapointed that GNOME Space Chart never made it to public... that disappointment lasted until now.

I wonder what on Flying Spaghetti Monster's green earth compels people to write their own build systems for no good reason. And yet, you still can do worse: you can adapt someone else's system to the point where it works for you. Which is why busybox shows "kernel source is at (path to busybox source)" when beginning to compile. And the pain only grows from there.

I’ve just released Webconverger (Web kiosk) USB&ISO versions built with stable Debian etch. Webconverger has received some good feedback and press. I would like to thank Daniel Bauman for his rather excellent Debian Live work on which Webconverger is based. I was hoping that Webconverger could support every locale, now it looks like I need to produce a separate ISO/IMG (or at least apt-get hooks) for every locale. One reason is that Iceweasel/Firefox extensions don’t scale very well. Try install every locale and dictionary extension. I dare you. :) Sidenote: I wonder why no one has packaged the dictionaries for Iceweasel. In other news, I’ve been playing around with scim (keyboard switcher) and Korean locales. It seems to work though the title bar didn’t render hangul characters right in dwm. After some investigation I discovered there isn’t such a thing as a single “generic” Unicode font. This came as a shock to me. :) Typical ttf only have 65536 glyphs, so no one font will do. Jeff Zhang also informed me about free Unicode fonts. Though I think especially in CJK environments proprietary fonts are unfortunately more common. Or I don’t know why microsoft-gulim isn’t in msttcorefonts. Anyway the Korean version of Webconverger turned out OK, though I doubt any Koreans will be using it. It’s all sadly ActiveX out there. My package wordpress 2.0.10 didn’t quite make it to etch in time as I was waiting for CVEs! 2.0.10 will be coming soon though… It always amazes me how much work can get done in breaks like Easter. It’s great that etch is out. And whoa, the weather is great.

"Beta" is short for "BETrAying". It means the web site isn't honest to you about the benefits for you, what they are doing with the data or what they are telling you. Examples:

• Download services: 'all download slots are busy, please wait 15 seconds' - not true, but they just would like you to look at the ads for 15 seconds
• Social networking: Myspace claims "foo is in your extended network". Even when you are the Google robot or using an anonymizer. This is a hard-coded string, not a calculated connection.
• Most Web 2.0 services: we have no idea how to continue providing this service for free once our venture capital is used up.

So spelled out it would be like:

Sorry, we're not telling you the truth about our service and the benefits, and that's why we're calling the service beta; once we've found out how to do it right and still earn some money with it, we'll remove the beta sign.

"Beta" is short for "BETrAying". It means the web site isn't honest to you about the benefits for you, what they are doing with the data or what they are telling you.Examples:

• Download services: 'all download slots are busy, please wait 15 seconds' - not true, but they just would like you to look at the ads for 15 seconds
• Social networking: Myspace claims "foo is in your extended network". Even when you are the Google robot or using an anonymizer. This is a hard-coded string, not a calculated connection.
• Most Web 2.0 services: we have no idea how to continue providing this service for free once our venture capital is used up.

So spelled out it would be like:

Sorry, we're not telling you the truth about our service and the benefits, and that's why we're calling the service beta; once we've found out how to do it right and still earn some money with it, we'll remove the beta sign.

etch is finally out of the door! Hooray! Congratulations to everyone involved, forget about what the /. crowd is saying, this looks likely to be a very solid release. If you happen to be in Hong Kong, there will be a Debian etch release party this Sunday afternoon. Please do come along, it’ll be fun. I’ve also translated the etch release announcement into Chinese, but it seems a bit more work needs to be done before it will appear on the Debian website. In the meantime following is a copy of the Chinese translation: (more…)

The linux kernel includes a SCSI target infrastructure since 2.6.20. Most of the code is located in the userspace and supports iSCSI, ibm i/pSeries virtual SCSI and Xen SCSIback. To work properly it needs a bunch of patches on top of 2.6.21-rc. After I got it working I did some tests with bonnie. First the target:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           32124  17 18063   6           45815   4 324.6   0

Now with the vSCSI initiator:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           18513   9 16208   5           34003   3 221.4   0

And the iSCSI initiator:

Version  1.03       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
                 2G           31631  14 12809   4           39241   5 306.3   1

As this tests was done on one OpenPower machine, all transfers uses DMA between the two systems. The vscsi case is currently limited to 128KiB per request, maybe this is a problem.