Kev009.com

So I bit the bullet and installed KDE 4.0 on Gentoo. Version 4.0.4 recently hit the tree, and with some minor hackary to package.unmask and package.keywords I have a nice spartan KDE 4.0.4 desktop that I am typing this in.

My observations:

Like Gentoo’s KDE3 packaging, you are given KDE4 pretty much as it is packaged upstream. It certainly lacks the polish that Fedora 9 and OpenSUSE 11 have been able to apply.

The desktop is somewhat of an afterthought at this point. Basic icon grid alignment and drag selection don’t work. Icons on the desktop are treated as widgets which means you can rotate them and such which may be something to build on in the future. However this area basically needs work.

Oxygen is beautiful. Seriously, everything looks stunning and it does not get in the way. Its not gaudy. Very professional. Still room for improvement though, I.E. icon set isn’t complete, consistency.

kwin’s built in composting is awesome. This is exactly the kind of thing I’ve been waiting for. It doesn’t have the heavy weight and gaudy appearance of Compiz or Vista. This will be a major productivity boost. Tabbing through windows, expose-zoom overview, and a heads-up of virtual desktops are the things I will use. The light shadowing and animation are also refreshing and professional. Nothing to get in the way here, it is stable and speedy.

The application launcher is a major pain in the ass. The integrated search is handy, but it just takes too many damn clicks to find an app otherwise. This will be especially unwelcome by new users since you might not know if the app you want is in ‘Internet’ or ‘Development’ or ‘Multimedia’ or even ‘More Applications’ under any of these. Every time you click the menu it starts from the favorites pane and does not remember the category you were in. I don’t think the Windows 95 style start menu is the final or best UI answer, but it beats this Vista style menu and the OS X dock abomination hands down.

Basically, plasma as a whole needs work. Widgets seem pretty glitchy. Also responsible for the above desktop nuances.

Apps are hit or miss. Gwenview is great for thumbing through pictures. okular does the same for documents. Dolphin works very well for most tasks, while Konqueror is there for you otherwise. Many of the games have been updated and are pretty good. Marble, Kalzium - just plain cool. Ark was one of my unsung heros on KDE3. It is severely lacking in KDE 4.0. I hope that it gets some attention, and shell integration back too! A lot of other utilities are either absent or need work as well.

Amarok 2 has yet to be released, but this will be a major influence when it is.

Speed! KDE4 is quick. This is a welcome relief. Once KDE4 starts to gel, I’d imagine it will run at least as well as KDE3 on old hardware. Build speed was much quicker with cmake, which is very welcome on Gentoo.

Stability is much improved in this release. It still is not business-grade. Trivial apps seem to crash on exit and such.

The Weird? The default window size for just about everything seems unnecessarily small. I find myself having to resize pretty much everything before I can use it.

In conclusion, KDE 4.0 is a giant leap forward but it is a work in progress…

If you are migrating from KDE3 on an old install, best wait as there is some adjustment. KDE 4.0 as packaged in Fedora 9 and OpenSUSE 11 seem quite usable however. I wouldn’t hesitate to install them on a new PC. I will certainly keep KDE 4.0 installed and re-evaluate with 4.1, but KDE3 has a better work flow for my use at the moment.

It reminds me a lot of Apple’s OS 9 to OS X transition. I’ve been following the development for some time. From the alphas, betas, and release in January, I’m quite surprised by where we are at today. Things are much better than they were just six short months ago. A lot of work has taken place and we are really forging the foundation for a first rate competitor in the PC desktop arena for the next 10 years. KDE 4.1 should be be released near the end of the summer. I believe it will be enough to convert many KDE3 users over. Things should really calm down and align by 4.2 and it will no doubt in my mind be the best desktop environment whatsoever at this point.

A lot of people are having trouble with Ableton Live 7.  This is especially true with MIDI functionality.  It stems from the fact that Live 7 defaults to the DirectMusic MIDI interface.  Apparently DirectMusic then has to do emulation because the standard Microsoft MIDI driver is not DirectMusic native (Microsoft, we will never understand you..).  This is true for most USB MIDI devices.

This was affecting me by introducing high latency into MIDI I/O with my Novation Remote 61 SL and Akai MPD24.  Initially all seemed well.  Gradually, hitting a note on my keyboard would get slower and slower until the point where it was unusable.  We’re talking hit a key and wait tens of seconds before the note plays.

Luckily the fix is pretty easy.  Open up the MIDI preferences, and click the small arrow next to all your inputs and outputs.  Now simply click the port type and it will change from DirectMusic to MME.

According to the forums, there are no drawbacks to this approach.  It is unfortunate that Ableton decided to make this a default since so many people have had troubles with it.

Wow!

I just downloaded the Fedora 9 KDE live spin.  I am impressed.  I tried a few of the betas along the way, but this is very polished.  Much better than Ubuntu’s try at KDE4.

It feels  very responsive and works very well, even as a LiveCD under VMWare.  This is KDE4.0 done right.  I’m banking on OpenSUSE 11 having an even better build from the betas I’ve seen.

By KDE 4.1’s arrival, I imagine KDE will be ready for prime time and most users will be able to migrate over.

But all in all, if you want a nice Linux desktop right now, Fedora 9 seems to have hit it pretty well.

My thoughts on the growth of the Linux kernel and the status quo of using and developing software..

Prompted by discussion of this article: 1986 Mac Plus Vs. 2007 AMD DualCore. You Won’t Believe Who Wins

–

[Ed: My response to accusations of Linux Kernel bloat]

The [Linux] kernel never has really been the problem. In 1 to 2 MB of compressed/compiled code on my computer (gentoo-sources + my custom .config and a couple of patch sets from future merges), there is some of the most advanced file system, networking, protocol, hardware and scheduling code ever conceived. Indeed, there are many areas that need work and are constantly being updated, but find me a kernel that supports NUMA, scales quite linearly with SMP, implements fair queuing of IO and CPU scheduling, has NO tick interval, virtualization and supports a wide gamut of platforms and hardware. It runs on systems as small as a microcontroller and as large as BlueGene/L. Did I mention it is free and I can learn from and hack on it?

The kernel isn’t really expanding at a rate to be concerned with, because only a small subset ends up being needed for most users and systems. No, the problem really lies in user space on UNIX systems. Modern UNIX userland involves many many layers of programs interacting and building on top of each other. I really don’t see it getting better in the future either. As higher and higher levels of programing languages are being used, more and more layers are added to the onion. This can make a programmer’s life easier and allows more complex systems to be designed, but there are many drawbacks as well. Bug creep, feature creep, usability, complexity, and resource usage all come to mind.

Do I know the answer? Not at all. I don’t think there is one. Software will develop organically in the wake of hardware progress for the foreseeable future. If and when this progress slows, perhaps things will change course. A sea change of compiler optimization, small is beuatiful engineering, and an emphasis on efficiency..

Chris Mason announced an early alpha release of his new Btrfs filesystem, “after the last FS summit, I started working on a new filesystem that maintains checksums of all file data and metadata.” The Linux answer to ZFS?

read more | digg story

I have a laptop, a workstation, and a server at home that I use daily. I also have a collection of code, documents, and music that are useful to have locally on all three — especially the laptop when traveling. For a while I would just copy files over the network (NFS and CIFS), or use the server but this has gotten tedious as the amount of data has grown. So I went looking for a syncing app.

I had two requirements:

• It must not run as a service - I don’t want yet another program loading at boot time or hogging RAM. Transfers should use NFS. Preferable since I am already running it and for speed.
• It must be initiated from the client side - I don’t want to SSH into computer X to push or pull an update

Unison

Unison has received a lot of hype. It certainly shows a lot of potential. Amongst notable features, it supports bi-directional syncing. You can have changes in the local and remote directories and interactively merge them. It also has a GUI for simplifying this and handling collisions. During my test, performance was terrible and it crashed during the merge. I read somewhere in the FAQ that using Unison with NFS isn’t ideal. It prefers to use SSH or a socket, which goes against one of my requirements. In short, this is a program to watch and it may be suitable for smaller file sets — but it simply did not work well here. The final strike is that it is no longer a research project and only lightly maintained.

rsync

rsync is a very powerful program. Its method of file transfer minimizes I/O and is fast. It is essentially unidirectional, so it lacks the power that Unison has in this regard. For my use case, this won’t be a problem since updates happen on one system at a time and are usually pushed to the server. Gentoo users will be all to familiar with rsync when updating portage with ‘emerge –sync’.

Using rsync is simple. ‘rsync -av SOURCE DESTINATION’ will be suitable for most jobs. A quick view of the man page will give a rundown on the options. Using a hub and spoke topology, I can sync all three in any direction: laptop <–> server <–> workstation.

I’m not sure why I waited so long to do this. It is incredibly efficient and easy and I recommend a similar setup if you have two or more computers. It nicely complements a version control system for things that don’t need to be tracked over time.

I’ve had a pretty advanced email system running at home (Postfix, SpamAssassin, Dovecot, Fetchmail) for over a year. The original goal was spam filtering for some 10 year old POP3 mail accounts from my old ISP that were heavily spammed. I couldn’t be more pleased with the system; false positives [not spam] are next to zero and very few false negatives [spam] slide through. I might even write a guide for doing a similar setup in the future, but not today.

One of the kinks along the way involved fetchmail. There was an email account that I needed delivered to two separate local user’s inboxes. fetchmail and alternative getmail have no way of doing this natively from what I could tell. You simply can’t have the same mail account twice. The question on IRC brought about strange solutions such as using procmail or aliases, but there were several disadvantage I could think of, especially involving the per user Bayes learning provided by SpamAssassin.

So I got to thinking, what if I simply fooled fetchmail into thinking that the account was actually two different accounts or servers. And here it is, .fetchmailrc.

poll bowling2-kev
uidl
proto pop3
auth password
via pop.isp.tld
user “bowling@isp.tld”
pass “supersecretpassword”
keep
is kev009

poll bowling2-bowling
proto pop3
auth password
via pop.isp.tld
user “bowling@isp.tld.”
pass “supersecretpassword”
is bowling

There are two key things going on here. The first account uses the keep attribute, similar to the “leave mail on server” option in client software. The interesting bit is in the second account. If you look on the line beginning with ‘user’, there is a trailing period. I am simply taking advantage of the fact that fetchmail thinks this is a different host. In reality the final period is the FQDN (Fully Qualified Domain Name), including the root DNS zone so it is the same host.

I speculate that if entries were added to the /etc/hosts file, this could be scaled to more than two users. Also, uidl and keep across all the accounts could prevent the chance of a mail going to only the final fetchmail entry, if it arrives between fetches. The disadvantage would be overflowing mailboxes if they are not externally pruned, and longer fecthes.

So there you have it, a quick and dirty hack for fetchmailing one remote account to two local users.

Just taking a moment to express my appreciation for IBM. Yes, I’m a bit of an IBM fanboy.

POWER6 is geared for release, and it’s badass. Check out this Ars Technica article for a good run down:
IBM’s POWER6 flies the coop at 4.7GHz

Simply put, IBM is the only company competing with Intel on Silicon process technology. IBM is part of an alliance with Freescale, Chartered, Samsung, AMD and others so their innovation can and will trickle down to the consumer market.

This is what I’m talking about:
Made in IBM Labs: 10 Chip Breakthroughs in 10 Years

Thank you.

“The Gentoo project is pleased to announce the much-delayed release of Gentoo Linux 2007.0. This release met with several delays due to an abnormally high number of security vulnerabilities in large packages which had to be rebuilt using the newer, secure versions of the packages.” A new installer, and much needed install media bumps round this one out.

read more | digg story

So Linux kernel 2.6.21 is finally out and all the buzz is about the Tickless Kernel patches. Wanting to drink the kool aid, I downloaded the freshly released gentoo-sources. Unfortunately it looks like amd64 support has not yet made it in.

I pulled some numbers on my main workstation, a dual Opteron machine. The first command lists the number of interrupts. You’ll notice that the ‘timer’ interrupt is primarily firing on CPU1. Below this is the output of `sensors`. Here you can see CPU1, again which ‘timer’ is firing, is running about 13°F higher than CPU0. These numbers are pretty consistent when I let the machine idle, so I am going to postulate that the timer interrupt is responsible for the thermal difference. It will be interesting to revisit the issue once amd64 support is added to CONFIG_NO_HZ, and I will post as soon as the results are in.

kev009@kev-ws-amd64 ~ $ cat /proc/interrupts
CPU0 CPU1
0: 969 9294483 IO-APIC-edge timer
1: 10545 28 IO-APIC-edge i8042
6: 0 3 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 0 0 IO-APIC-edge rtc
9: 0 2 IO-APIC-fasteoi acpi
12: 5 127 IO-APIC-edge i8042
15: 276725 718 IO-APIC-edge ide1
16: 746315 1666 IO-APIC-fasteoi ehci_hcd:usb1, nvidia
17: 59746 5990 IO-APIC-fasteoi libata
18: 282186 1581 IO-APIC-fasteoi ohci_hcd:usb2
19: 0 0 IO-APIC-fasteoi ohci_hcd:usb3
26: 280054 128 IO-APIC-fasteoi EMU10K1
28: 355905 111 IO-APIC-fasteoi eth0
38: 0 15 IO-APIC-fasteoi aic79xx
39: 160124 1762 IO-APIC-fasteoi aic79xx
NMI: 2068 1916
LOC: 9294591 9294562
ERR: 0
kev009@kev-ws-amd64 ~ $ sensors -f
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:
+120 F

k8temp-pci-00cb
Adapter: PCI adapter
Core0 Temp:
+133 F

My x86 server was a bit more evenhanded with its interrupts, so I can’t do a thermal comparison like the above. So throwing caution to the wind I compiled a pair of 2.6.21 kernels: one with CONFIG_NO_HZ and CONFIG_HIGH_RES_TIMERS, and the other without. Armed with a kill-a-watt meter, its time to see if there is any empirical evidence on power usage.

Tickless/High Res: 98-101 ~100VA

250Hz Tick/”Low Res”: 99-103 ~102VA

With this hardware (IBM x330, dual 1GHz PIII, ServerWorks OSB4 chipset) I see about a 1-2 volt-ampere average drop.

I’d be interested in seeing others results, particularly on mobile hardware. Many laptops have a current discharge sensor that could be used to monitor and measure the difference. I suspect that the difference would be more noticeable if you run a 1000Hz tick as well. Please leave a comment or trackback with your thoughts and results.