Kev009.com

Development seem to be going well for Tux3.

Daniel Phillips of Tux3 just posted the following to the LKML:

The big goals for Christmas (this Christmas!) are:

• SMP locking
• Atomic commit
• Posixly complete
• Rudimentary fsck

With the following comical reference

With atomic commit, we will progress from “buggy Ext2 equivalent with missing features” to “buggy Ext3 equivalent with missing features”.

Not a bad place to arrive at in five months, starting from scratch. Does anybody out there still doubt that the community process works, and is the best way to develop really complex software? Believe it.

See the whole post here: http://lkml.org/lkml/2008/12/10/358

1. Buy Old Computers
2. ???
3. Profit

What is retrocomputing?

I define retrocomputing [wikipedia] as the collecting and use of old computers.  Why might one do this?  Well, for one, enterprises cycle out machines fairly frequently.  2,3,4 and 5 year old systems are often sent out to scrappers in droves despite still being plenty useful.  Top of the line systems for large companies often have more than enough power for small and medium sized ones at pennies on the dollar compared to new hardware.  These machines are likely complete overkill for home use, but none the less are very useful for fun and learning.

IBM mainframe ops in the 1980s

Why?!

A lot of what I know about computers has been learned on old machines.  Hooking up a couple of servers and desktops and trying to make something useful out of them is a great exercise for the aspiring system administrator.  With open source software, it can all be done freely and easily.

Yes, you can run Linux, BSD, and Solaris from the comfort of your Windows desktop in a virtual machine (weak sauce…).  Yet there is something much different when you cluster several high technology servers together, tethered to a Fibre Channel storage array and have them share a single distributed file system.  The knowledge of setup, installation, and troubleshooting I’ve gained from mock scenarios like this I cannot compare to anyone else I’ve ever met.  Breaking things here usually means digging deep and fixing it.  If you were to screw something up at work like some of the things I’ve gotten into, it would probably cost you your job.

BENCHNET - where I rip into computers that cost as much as a house and my "production" rack

Retrocomputing is also fun.  I am personally into old IBM hardware, though old UNIX workstations of all sorts are interesting to me.  You can see my collection of IBM PS/2 and RS/6000 knowledge here: http://ps-2.kev009.com:8081/.  There is a particular thrill to booting up a machine that cost between $20,000 and $50,000 10 years ago.  Knowing that these same machine models were used to design the Boeing 777, composed the famous Deep Blue machine, and were used in the largest automotive and shipbuilding firms not to mention some of the most important space craft to date also brings a sense of power and nostalgia.  In some ways its similar to having a classic car, but different.  Maybe if that classic car was a big ass bulldozer, tank, jet or some other well engineered piece of equipment :-P.

IBM PS/2e, RS/6000 43p, PowerMac 7100, RS/6000 x2, HP Visualize c360

Nostalgia is one of the biggest things I get out of using particularly old hardware.  I missed the mainframe days, the minicomputer days, the PC and DOS days, the Apple II days (well, actually I used these a bit at a very young age), and to a degree the early Windows days.  Just like a history class, studying these old machines gives me insight as to why things are done the way they are today.  It gives me appreciation for modern systems and makes me write clean and well optimized code.  The old computer games that captivated me as a child (Sim City, Sim Tower, Sim Ant, Sim Farm, Gizmos and Gadgets, The Incredible Machine, Oregon Tail etc.) implanted a high degree of logic and understanding at a young age and it is heartwarming to revisit these.  I grew up a Mac user as well, so seeing what I was(or: was not :>) missing on PCs is also interesting.

Old MIPS UNIX server booting and logging in

Some of the benefits of retrocomputing:

• Enterprise class hardware
• Cheap, possibly even free
• Different design philosophies - not everything is x86 - a lot of this gear is quite different.  For example, UNIX workstations integrated most of what we enjoy on our PCs years before it became available to consumers.  SGI machines were doing A/V and 3D in the early 90s.  IBM midrange AS/400s have an advanced integrated database, programming languages, and environment that make PCs look like a joke for business programming.  WinFS, Object Storage Devices, etc are just now being talked about for PCs.  The channel philosophy from mainframes is still pretty new to PC servers (fibre channel), not to mention virtualization.
• If you break it, you can fix it and learn from it or toss it
• The engineering and craftsmanship in some of these systems is downright astonishing
• Old computers are works of art: they give you a window into the technology and culture of times past
• You should never trust a computer you can’t lift

It is interesting that we as humans produce such elaborate machines, only to discard them as scarp a few years later.  It is humbling and shows you the incredible progress we are making.

How?

eBay is your friend, but also look for local scrapyards or businesses doing overhauls.

If you are faint of heart, plenty of good abandonware sites exist for games and operating systems that can be run on emulators or VMs.  Check out this IBM mainframe emulator, Hercules.  Some of the original IBM OSes are public domain.

If you don’t want old PCs and big iron overtaking your house, there is plenty of good material on YouTube as well.  The Computer Museum is a good start.  Some of the consoles, offices, and outfits are hilarious.

Old SGI tech demo - pretty impressive!

Phoronix has been cranking out a slew of benchmarks recently, pitting various different Linux distros against each other and even different operating systems with their own automated test suite.

1. Ubuntu 7.04 to 8.10 Benchmarks
2. Mac OS 10.5 vs. Ubuntu 8.10 Benchmarks
3. Ubuntu vs. OpenSolaris vs. FreeBSD benchmarks
4. Fedora 10 vs Ubuntu 8.10 Benchmarks
5. “Real World” Benchmarks of the [sic x2...]EXT4 File-System
6. OpenSolaris 2008.05 vs. 2008.11 Benchmarks

What I would like to know is… are they bullshit?  I’m no statistician, yet the proximity of the numbers and lack of error bars raise my own bullshit detection meter.  See this URL for some background on statistical significance and error bars: http://www.graphpad.com/articles/errorbars.htm.

I spot plenty of outlandish things, such as FPS benchmarks for file system tests and JDK version changes through product life cycles, also to mention the somewhat unfairness of crappy binary graphics drivers across versions.  JDK 1.6.10 is SUPPOSED to be faster; results from benchmarking against this are insignificant unless it is run across all versions.  Yes.. GCC, glibc, and the kernel change between releases as well but these are not typically components that a user can swap out as easily as a JVM which should probably be bumped for security reasons anyways.

Furthermore, I realize all benchmarking should be taken with a grain of salt - one particular set of hardware and software will never map correctly to another set of hardware or software, but it should be possible to set up tests to gain some useful intelligence.

Can this kind of macro/micro benchmarking (depending on how you look at it) help weed out regressions?  GCC 4.0 was noticeably slower on x86 than 3.x (See: http://www.coyotegulch.com/reviews/gcc4/index.html, http://people.redhat.com/bkoz/benchmarks/).  At the same time I think PowerPC saw significant improvement due to auto vectorization and use of Altivec/VMX.   But it also seems to be improving over time.  I’ve heard 4.4 is supposed to be much better with a new register allocator (IRA).  This probably the most important component of modern open source operating systems, so some of the blame might be placed here if the numbers have meaning.

All of this makes LLVM look more and more appealing.  LLVM is able to do not only compile time, but also link and run time optimization.  This is very appealing for commercial software where you are given a binary blob by the manufacturer that will likely that will not change through its lifetime.  It also reminds me of Java and speedup through JVM upgrades, except this should work on any language.

“LLVM is… designed to enable effective program optimization across the entire lifetime of a program. LLVM supports effective optimization at compile time, link-time (particularly interprocedural), run-time and offline (i.e., after software is installed), while remaining transparent to developers”

One thing the Phoronix numbers do show is that things seemed to go down hill coincident with CFS (Completely Fair Scheduler), dyntick, and SLUB merging as well.

Evgeniy Polyakov of POHMELFS fame raised the alarm with some fairly significant networking regressions - how financial crisis affects tbench performance - that seem to support a general slowdown between 2.6.22 and 2.6.27.  This resulted in noise on LKML and hopefully we will see improvements soon.

I guess what I am getting at is that compute power is so cheap that it seems stupid to not have automated tests against such things these days.  Diego Petteno of Gentoo fame has been doing such things recently with Gentoo’s excellent build system.  I have set up Hudson, a Java Continuous Integration system, before to track commit regressions and such a system seems ideal for all modern software testing.

Anyways, I am interested in hearing your thoughts on benchmarking, software testing, and automation and how it can be used to improve modern software.

KDE 4.2 is set for release on January 27th.  Eager to see what is new and improved, I installed beta 1 on my Gentoo box.  KDE 4.1.80 was tagged then released late last month after the feature freeze deadline. This is a snapshot of the current development tree that will eventually be released as KDE 4.2.

A quick blurb about KDE 4.1:
Busy with other things, I never wrote about KDE 4.1 on Gentoo. I’ve been using KDE 4.1 since 4.1.1 with the kde-testing overlay which has since entered portage and been bumped to 4.1.3. This is a good release and well worth at least testing if you are a KDE user. I’ve found it to be quite stable and use it exclusively for every day work.  The Gentoo KDE team has done an excellent job creating ebuilds for it.

What’s new?

Plasma received a lot of polish and is beginning to eclipse Kicker and indeed all other desktop and panels that I have used.  Much needed features such as changing the panel height, auto-hide, and screen edge selection have been added.  The task bar is highly configurable in typical KDE fashion, allowing you to define task grouping, sorting, filtering based on current desktop or screen or minimized windows only, as well as allowing manual grouping.  The system tray also now allows hiding of unwanted tray icons.

Here’s a screen shot cluttered with various plasmoids for demonstration.  It’s nice to see the community thinking up some fun and useful plasmoids.

I wasn’t the biggest fan of the KDE 4 default menu.  Luckily, the Lancelot menu has been accepted upstream and is now an option on stock installs.  This menu is great for finding new applications (esp. new users) as well as thumbing through with the keyboard.

I’m a Firefox user, but occasionally will fire up other browsers for testing or to avoid restoring a large previous session if I am in a hurry.  I’m happy to say that Konqueror feels much faster.  It also seems to work much better on AJAX heavy sites such as Facebook.  When I spoofed the user agent to report Firefox 2, Facebook chat worked fine, an improvement from 4.1.  The continued merging of Webkit is clearly beneficial here.

One of my favorite KDE apps from 3.5, Ark, is also finally reaching feature parity.  I missed shell integration with Dolphin/Konqueror quite a bit and am happy to say it has returned.

Notifications are displayed and stack nicely in the lower right corner.  Operations such as downloading and moving files will show their status here.

Kontact gained usenet support by means of Akonadi, which now has support many for data sources.  I think I will switch from Thunderbird/Lightning to Kontact with this release.

Kate has a new VI editing mode.  This is quite a nice text editor.

Amarok is shaping up as well.  This is 2.0 RC1, so it should be released on a date close to KDE 4.2.  Take a look at the different Internet media sources.  Last.fm support is now top notch!

Digikam 0.10-beta5, which seems to be stabilizing and evolving nicely, is another nice app.  Bonus points if you can identify all the retro machines.  The one on the left was probably the worlds first “green” PC.

Okteta, an easy to use hex editior, has also been updated.

I could go on and on showing the great progress.  I hope I hit the highlights, but you can check out the feature plan for yourself here: http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan.  Noteworthy changes include improved multi-display, better desktop search with Strigi, and integrated power management.

Gentoo Installation

First, a shout out to the Gentoo KDE maintainers and testers.  Creating ebuilds for fast moving snapshots and live sources for a project this large is not an easy task.

Installation on Gentoo is fairly easy if you have layman.  ‘layman -a kde-crazy’ will add the KDE crazy overlay which has KDE 4.2 unmasked and ready for testing.  If your box is ~arch, it should be as simple as ‘emerge -av @kde-4.2′ (see comments below for more info).  I recommend using the kdeprefix USE flag if you wish to test development releases so you can fall back to stable if things aren’t working correctly.  This will slot 4.x releases.

If you want a stable and usable environment, I still recommend sticking to 4.1.3 at the moment.  If you run a mostly stable Gentoo with KDE3.5, you can find a package.keywords file in the kde-testing overlay as well as some other minor goodies.  These versions slot effortlessly so it isn’t a problem switching back and forth.

Conclusions

KDE 4.2 has come a long way since 4.0 and is a nice steady improvement over 4.1.  As I stated earlier, I use KDE 4.1.3 as my only desktop environment and am extremely pleased with it.  I have had no major issues and have had uptime of over a month in the past without crashing/restarting KDE - so the good old KDE 3.5 stability seems to be returning.  By trying the current beta out, I have no doubt that 4.2 should be just as stable by release.

Also, if you are an Nvidia user you owe it to yourself to try the latest 180.xx+ drivers.  As people have long been saying, much of the performance problems they were describing were related to Nvidia cards and poor video drivers.  With the new drivers, KDE is lightning fast.

Here’s to an on time and successful KDE 4.2 release.  I can’t wait to see what QT 4.5 and KDE 4.3 will bring!

It seems I caught the wave of interest in Linux file systems.  Here are some articles worth checking out:

• LWN has done an excellent overview of Tux3: http://lwn.net/Articles/309094/
• Phoronix subjects ext4 to performance tests against ext3, XFS, and reiser3: http://www.phoronix.com/scan.php?page=article&item=ext4_benchmarks
• Btrfs performance analysis: http://btrfs.boxacle.net/

Of course, there are some other file systems that I haven’t talked about that came up in the comments of my last post.  Most of these are special purpose, still on the fringes, or different in scope than the first article which was about local storage.

• The native flash file systems: UBIFS and LogFS.  In theory file systems like these would be ideal for SSDs, but we need manufactures to stop putting FAT/Hard disk emulation and wear leveling into their drives.  Windows is the culprit for this.  These file systems also seem keyed toward embedded device flash memories at the moment and not general purpose storage.  Neither are upstream yet.  This could be positive, as the disk format and code can be readily changed to make them compatible with future SSDs if there is a change in manufacturing.  Val Henson, a Linux file system authority, has some interesting thoughts.
• The Log file systems: LogFS (flash centric, see above), NILFS.  I believe ZFS and Tux3 share design philosophy from these.  The idea has been around for a long time but none have ever really succeeded.
• The shared disk and distributed parallel file systems: OCFS2, Lustre, GFS, PVFS.  There
  are a laundry list of these.  Some implement entire disk file systems, while others add clustering or distributing properties to other file systems.  SUSE [link] and I think Red Hat even considered using one as the default file system but booting (Grub) is an issue.
• Network file systems: these add networking to other disk file systems. POHMELFS and CRFS (distributed extension for Btrfs) are interesting new ones here.  Of course there are a laundry list network file systems for Linux.  NFS, AFS, and CIFS are the old timers.
• The others: These are more experimental or research oriented.  chunkfs, spadfs, and many more.  Many others just don’t have steam behind them yet or are dead in the water.

My overview is clearly Linux oriented, though I mentioned ZFS in passing because I think it spurred a lot of these recent developments.  That isn’t to say the BSDs are sitting still with HAMMER, and FreeBSD is keeping UFS2 moving forward while NetBSD has LFS - a log file system.

P.S.:

I plan on performing some benchmarking soon after 2.6.28 goes stable.  The list will include ext2/3/4, JFS, XFS, Reiser3 and Btrfs.  The setup will include single and multi-disk configs.  If you have any requests or suggestions for setup, please contact me.

Update: More Linux File Systems

Introduction

Although the file system is one of the most important pieces of an operating system, we generally put little thought into them these days.  Put bits in, pull bits out.  It usually works well enough for desktop systems – until the power fails - but even that is usually pretty painless these days.

On Linux, there are many contenders in the file system arena.  ext2 had been the standard for many years, though around 2001 and onward a few other choices become mainstream.  Without delving into too much history: journaling support was added to ext2 in the form of ext3, ReiserFS is released, SGI ported XFS, and IBM ported JFS in no specific order.  For a few reasons, mostly political, ext3 becomes the de facto file system for Linux.

Classic File Systems

In what I will refer to as “classic” file systems, the idea is basically the same.  They essentially bolt journaling to the traditional file system UNIX layout.  Here are the highlights from each of these:

• XFS is hailed by some for its excellent support of large files and large file systems, and has some nice modern amenities like extents, delayed allocation, and online defragmentation.  [http://en.wikipedia.org/wiki/Xfs]

  XFS is not without a fair share of faults though.  It’s a somewhat half hearted port in my opinion.  Mainly due to its IRIX roots, performance is usually comparable to the other era file systems but CPU usage is relatively high [http://www.debian-administration.org/articles/388].  Data atrocities after power outage or machine crashes seem to be common and even design decision.  This LKML posting really struck a nerve with me: http://lkml.org/lkml/2007/3/28/316.  A lot can go wrong on the hardware side of things, and if a file system is not privy to this it is a recipe for disaster.  ZFS is a hero here with checksumming, which I will touch lightly later.

  It is worth noting that XFS is still under active development and has a decent roadmap forward [http://www.xfs.org]

• ReiserFS (Reiser3) is one of the first journaling file systems for Linux.  It has some initial growing pains, but is quite a nice file system by kernel 2.6.

  Performance is excellent with small files, but its scalability is questioned by many of the Linux elite [http://en.wikipedia.org/wiki/Reiserfs].  Hans Reiser then goes on to work on Reiser4 which is essentially a rewrite.  SUSE Linux keeps a few developers on it, but it becomes pretty clear that this is a doomed file system [http://www.linux.com/feature/57788].

• IBM’s JFS is another of the UNIX ports.  JFS traces its lineage back to IBM’s AIX in 1990.  An IBM team ports and improves it for use in OS/2 and later releases the code as free, open source software (FOSS).

  The resulting Linux file system is noted for being scalable, resilient, and in particular easy on the CPU [http://en.wikipedia.org/wiki/JFS_(file_system)].  It also includes extents support.  For whatever reason the kernel community and distros don’t really latch on to it.  JFS is basically just slowly maintained throughout its life cycle.

• ext3 is a journaling extension of the Linux native ext2.  Out of all the file systems in this generation, it is probably the least technologically advanced lacking features like extents.  What makes up for this is the easy upgrade path for ext2 users, relatively simple code base, and broad upstream adoption. [http://en.wikipedia.org/wiki/Ext3]

  Broad upstream adoption makes ext3 winner for most users and distributions, and it is now the most stable and supported Linux file system.

In hindsight it seems somewhat tragic that JFS or even XFS didn’t gain the traction that ext3 did to pull us through the “classic” era, but ext3 has proven very reliable and has received consistent care and feeding to keep it performing decently.

Nextgen File Systems

In 2005, Sun Microsystems released the bombshell ZFS file system.  This ushered in the era of what I will call “nextgen” file systems.  As hard disks have gotten larger, strategies for backup, integrity checking, and support for large files have become much more important.  These file systems also aim to ease management by blurring the traditional VFS line or offering tight integration with LVM and RAID.  Silent corruption by bad hardware is also cause for alarm, and checksumming has been baked into some of these “nextgen” file systems to counter this.

In many ways, Linux was caught completely off guard and most developers weren’t thinking very hard about the future of file systems prior to the ZFS release.  Reiser4 explored some interesting ideas and aimed to be a killer file system (okay I’m really tasteless…) but Hans Reiser enjoyed a particularly bitter relationship with other kernel devs.  Luckily, some even more advanced file systems have come into existence recently.

• Reiser4 was the first effort for a next generation Linux file system.  Introduced in 2004, it seemed to have some excellent new technology including transactions, delayed allocation, and an interesting plugin architecture for adding features like encryption and compression.  Hans Reiser even advertised using the file system directly as a database with advanced metadata.

  Reiser, the primary developer, often rubbed other kernel developers the wrong way when championing his new file system.  Hans seemed to get defensive when questioned about code style and design decisions – particularly that of the plugin architecture.  I think that a lot of this was due to misunderstanding and bad tempers, but to this day Reiser4 has yet to enter Linus’s kernel tree.  With Hans Reiser’s murder conviction in 2008, the future of Reiser4 was frequently called into question.  At this point it seems unlikely that Reiser4 will ever see upstream adoption, but some of the ideas explored have already been integrated into other “nextgen” file systems. [http://en.wikipedia.org/wiki/Reiser4#Integration_with_Linux].

• ext4 was started as an effort to make a 64 bit ext3 to support large file systems.  Later, others (Lustre, IBM, Bull - see Theodore T’so comment) got involved and added extents, delayed allocation, online defragmentation, and more. [http://en.wikipedia.org/wiki/Ext4]

  ext4 enjoys forward compatibility with ext3, and limited backward compatibility if extents are not enabled.  Again the clear advantage here is that it improves upon the stable ext3 base, provides an easy migration path, and has many great developers working on it.  However, it needs to be said that ext4 is still somewhat of a “classic” file system and doesn’t have the level of features and scalability that the other “nextgen” file systems do.

• Btrfs is clearly Linux’s response to ZFS.  Started by Oracle, this project has gained backing from all of the major Linux corporations.  Traffic on LKML suggests that this will be the file system to carry on the torch from ext4.

  Btrfs’ key design feature is copy-on-write which will allow for inexpensive snapshots useful for backup and recovery.  The goal is to completely surpass ZFS however, and many exiting features such as data/journal checksums, tight device-mapper integration, built in RAID, online fsck, SSD optimization options and even in place ext3 upgrades are being worked on [http://btrfs.wiki.kernel.org/].

• On the tails of Btrfs, another advanced file system called Tux3 has been announced.  The project’s developers have been making use of FUSE to quickly prototype and test ideas.  The initial work on a kernel port has just been posted [http://lkml.org/lkml/2008/11/26/13].

  This project aims to do away with traditional journaling, instead playing back the logs (or recovering) on every mount.  It will also feature inexpensive snapshots and versioning.  The project’s developers seem to be quite good at championing their ideas, but I predict it will be up to 3 years before we see this ready for mainstream use since coding has really just begun [http://tux3.org/].

Conclusions

With ext4 coming out in kernel 2.6.28, we should have a nice holdover until Btrfs or Tux3 begin to stabilize.  The Btrfs developers have been working on a development sprint and it is likely that the code will be merged into Linus’s kernel within the next cycle or two [http://www.heise-online.co.uk/news/Kernel-Log-Ext4-completes-development-phase-as-interim-step-to-btrfs--/111742].

It seems pretty clear that Solid State Disks (SSD) will be here for good.  Theoretically these should blow magnetic storage away in terms of speed.  We are already starting to see competitive write performance, and random access and IOPS are very impressive with the latest Intel SSDs.  It is good to know that Btrfs plans to incorporate SSD optimization from the start, but these new devices may warrant yet another file system to achieve maximum speed.  I personally think that wear leveling and FAT emulation are holding these devices back and would be better implemented by the file system.

P.S.:
I’d been meaning to write this article for a while, but things have been changing rapidly with the introduction of ZFS, Btrfs, and Tux3.  I plan on doing benchmarks soon with kernel 2.6.28 against all the classic file systems, ext4, and Btrfs so subscribe to my RSS feed if you are interested.  Any comments, corrections, or questions would also be appreciated!

P.P.S.:
Wordpress seems to mangle the format of this post so the bullet justifications are off.

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..