At aKademy I had the chance to talk to Chris Schlaeger about SUSE, its relationship with the KDE community, his view of the Linux enterprise desktop and the speed of development of several key features in KDE (a Dutch translation can be found at Bart&David).
.imgboxrt{
border:1px dotted #000;
float:right;
margin-left:5px;
margin-right:10px;
}
.imgboxlft{
border:1px dotted #000;
float:left;
margin-left:10px;
margin-right:5px;
}
Please introduce yourself and explain your role within the KDE project.
My name is Chris Schlaeger and I'm the Vice President of Research and Development SUSE Linux at Novell. I'm a long time KDE developer and I used to be the maintainer of KSysguard and before that I worked on the previous version called KTop and I hacked on kdelibs.
Not long ago Novell acquired two companies that deal with Linux: Ximian and SUSE. While Ximian is a derivative from the GNOME project, SUSE is well known for its support of KDE. How does this all come together?
Better than most people seem to believe. Novell is committed to supporting both GNOME and KDE desktop environments in its Linux desktop. We are fortunate to have acquired a robust set of desktop technologies through our acquisitions of Ximian and SUSE LINUX, giving our customers a considerable amount of choice.
We are working on our next generation Enterprise Desktop currently called Novell Linux Desktop which will feature a KDE desktop as well as a GNOME desktop. In the enterprise market the situation is still very open regarding which desktop will have the greater following. For a Linux provider like Novell it is a great opportunity to offer both desktops to our customers and see where the market is going.
During your presentation at aKademy you mentioned that SUSE offers two product lines now:
Novell Linux Desktop and Novell SUSE Linux Personal/Professional. What are the differences between these product lines?
Novell's Linux desktop is currently still under development. We are still offering the SUSE Linux desktop, however this is based on the SUSE LINUX Enterprise Server 8 code base, which has now been superseded by version 9 (released in August of this year). This represents our business offering as opposed to our consumer product offering.
They both target very different user groups which have different requirements. We have the old traditional SUSE products which really target the private user who is using Linux at home.
The Personal/Professional versions are consumer products targeted at home users. Users who either want to do very little or very specific work with their PC like writing email, surfing the web, word processing, spreadsheets, printing and the like. For those people we have the Personal version. The Professional version is basically the swiss army knife of Linux. You've got everything in there that we feel is of some interest and benefit to our customers. Both products have a comparatively low purchase price and are therefore very cost effective.
We provide security updates for a period of 2 years for these products which is something customers tend to forget. There is a lot of work that needs to be done to keep the products secure during their lifetime. A new version is released roughly every six months.
However, in the enterprise arena 2 years doesn't cut it as people want 3 or 5 years support at minimum. So for the enterprise customers we created a new product which was called SUSE Linux Desktop. The next version will be a Novell Linux Desktop which will be based on the SUSE LINUX Enterprise Server 9 code base and combines the best of SUSE LINUX Desktop and Ximian Desktop. It will have a lifetime of around 18months and we guarantee to provide support and maintenance for the product for up to five years. Also the quality assurance is much higher. In an enterprise arena you need to do integration tests to a much higher degree and we test extensively so that we don't inject any side effects when we provide fixes. That's the main reason why the enterprise versions are more expensive and also the software collection is more targeted to the needs of the customers we try to address.
What do you think are the strong points of KDE as an enterprise desktop?
KDE is a very good enterprise desktop environment and it offers all the functionality you would expect nowadays from an enterprise desktop. So from a desktop perspective it is ready. But there are still missing features on the application side. People expect more and there are some areas like the OpenOffice.org integration and the browser question that needs to be resolved.
Also accessibility is one of the hot topics where more work is necessary. But when there is a good foundation we can build on and a lot of work is being done in all areas to improve KDE. Also I'm very glad that the KDE team recognizes the enterprise market as a very important target audience they have in mind when they write software.
Could you tell me any typical enterprise features of KDE you are using?
One of the features for example is the Kiosk lock down mode. That's clearly something you normally wouldn't use in a home setup. Well maybe you want to restrict the ability of your kids to do certain things ton your PC. That is also a way to use the Kiosk mode. But primarily the Kiosk functionality is meant for use as an information terminal or on the corporate desktop where the system administrator just wants to expose the necessary functionality to the users.
Novell also has its own ZENworks. Are there any plans to integrate ZENworks with KDE ?
ZENworks is an enterprise management console. ZENworks was originally written for Windows and now
the next version called "ZENworks for Linux" will also support Linux. It is a complementary tool and is
the tool that administrators use for mass administration. So it does software inventory management and
it *controls* the lockdown. ZenWorks does not provide the actual lockdown functionality, but it
provides the configuration values. On the client you would need the counterpart that actually knows
how to implement the values that ZENworks has.
There have been some rumours, corroborated by some CVS commits, which show work going on in KDE-PIM on a configuration wizard for the Novell Groupwise client. Also the aKademy interview with Will Stephenson talks about the integration of Groupwise functionality in Kopete. Can you elaborate more on this?
We are working on the integration of KDE tools in the other products from Novell. Groupwise is the most prominent of these and is a collaboration tool that offers messaging, calendar and mail services to the user. You can now use KDE tools such as Kopete together with the Groupwise messenger and you can use Kontact to access the corporate calender and address-book and also for email.
Just curious, how long did it take to program the Novell Groupwise integration into Kontact, Kopete and KAddressbook, and how many people were involved?
It was quite amazing that we were able to do this. The messenger integration was done by Will Stephenson in 2 months. Even more surprising was the integration of Groupwise into Kontact. In less than a week developers got it running. We were able to exchange data from the server to the client. Sure, there are still bugs in there and we need to iron these out but I'm glad that it was done so quickly. I'm sure we can get it ready for the next deadline for the Novell Linux Desktop.
How will this evolve with regard to KDE and who will maintain this stuff?
We have some KDE people on board and we currently have an offer on our website for a KDE developer, especially for the KDE-PIM area. One of the tasks would be to maintain the Groupwise and messenger integration.
During your talk at aKademy you said we needed fewer toolkits. What do you mean by that?
Linux is plagued by too many toolkits. We've got Tcl/TK, Java, Motif, Athena Widgets or the old X toolkit, GTK, and Qt, and all of them look and feel totally different. Applications written in those toolkits do not follow the same standards and guidelines and are a mess to use. Especially if you have them side by side or you need to use them frequently.
Some of toolkits do not really cut it today. There is little support for accessibility, there is hardly any support for hotkeys. We just need to get rid of them. It was great that they were there and they served their purpose but I personally would like to see as few toolkits as possible in the future. They are still projects that come with their own toolkit like Mozilla and OpenOffice.org. I'm sure we can find a solution there that these toolkits can integrate and behave very well with the rest of the desktop.
During aKademy the Accessibility Forum and Usability Forum were very successful. What is your opinion about these disciplines, and how should they fit into the KDE development process?
I think it is important especially because the most interested enterprise customers we have are government agencies and they have strict rules on accessibility conformance (section 508 is mandatory in most of the US in the government agencies). If we want to get involved in that market then we need these features and they are not there yet. So I am glad that there is work going on in these areas and SUSE is a very active contributor. For instance, we have a blind developer on our team who did the first support for braille displays. SUSE Linux was the first distribution not only usable but also installable from scratch by a blind person using YaST in text mode. Of course text mode is fairly easy compared to graphical user interfaces and having a good off screen model and screen reader is a significant amount of work. Trolltech and Sun have done really a lot of work in this area and we really hope that with Qt4 and KDE4 we can profit from this and offer this technology to users.
What will Novell/SUSE do to improve the experience on the desktop?
We are working on OpenOffice.org to make it integrate better with the desktops. On SUSE 9.1 you saw already the first fruits of this work - if you start OpenOffice.org it looks like a KDE application. It is a first step but it is far from complete: if you open a file you get a totally different file dialog that is not only awkward to use, but also doesn't fit into the KDE look and feel. The same for printing. That is still something we need to overcome but we are working on this and probably will have better integration with the next product.
So that's one piece of the experience on the desktop, the OpenOffice.org part is there. Something going on with the Mozilla browser part as well?
Well that started on aKademy where we discussed this on the first day. The question came up during a discussion I had with Matthias Ettrich and a few others. It is currently a pain to the user to need two installed browsers, one browser which works for this website and the other browser which works for the other website. Konqueror is fast and nicely integrated, but Mozilla renders more pages better.
Customers that do web application development heavily use DHTML and other special features that Konqueror doesn't handle very well and it is a lot of work to implement this. Although I like KHTML and the architecture quite a bit I am sad to say that probably the Gecko rendering engine will be the dominant one used in the enterprise arena, and as KDE developers we've got to make sure that we can integrate Gecko fairly well into KDE.
So Lars Knoll and Zack Rusin started working on this at aKademy and I was delighted when they put me aside and showed me what they have done in just three days. It is amazing! I think it is the right way to go! It is a bit sad for KHTML and I hope that despite this people will still maintain it as it is a nice lightweight browser. If it would be a purely technical decision, KHTML has the better architecture, but sometimes you need to go the shortest way to get to your target.
What about technology like D-BUS (the Desktop Bus) and HAL (the Hardware Abstraction Layer)? What are your thoughts on that?
I think D-BUS will come probably with KDE4, not earlier than that. It is a lot of work to implement that properly but I think it is going in the right direction. We need to integrate the desktop and the operating system much deeper. So that you can control the hardware on the desktop or have the right feedback on the desktop.
If I connect a camera currently I get a nice icon on the desktop where a Konqueror browser is opened. SUSE has that for quite a while, but if you look at how we implemented this ... It is a real pain and doesn't work 100% reliable. The problem is with the hotplug system of the underlying OS and the way we have to communicate those kernel events into userspace. D-BUS hopefully will solve some of these problems in the long run. It is a lot of work but it is going in the right direction and I'm sure we will adopt that.
Do you think the KDE desktop should ready itself for that kind of technology?
I think that there is a general understanding within the KDE developer community that D-BUS is the right way to go. Not for KDE3 but probably for KDE4.
Currently we have developers, translators and documentation writers as part of the KDE development process. How do you think other disciplines like accessibility and usability should participate in the development process?
I think they should participate and the KDE project should adapt their structures to integrate those groups as well. It is important to have their work integrated but that is something you should ask the KDE release coordinator to see how we can fit these people into the process. But for example, who could have imagined that we would have more then 50 languages in KDE? Surely this will also happen to other areas like accessibility and usability, as there is some good work going on to get people involved.
Where would you like to see the future of KDE go, and what new features would you like to see in future releases?
KDE has made tremendous progress over time. I joined the project when it only had a few dozen people and now it is 700 people strong and is constantly growing, and the enthusiasm of the project hasn't decreased at all. It is now not only working on the core part but also working on parts like accessibility, translation to many languages, documentation work, artwork and other areas which are not directly linked to the core code-hacking. I'm glad this is going on and we need more of this in the future. We need more applications in the future, and good accessibility support, OpenOffice.org integration and the browser problem are the most practical features would like to see in the next release.
How will the relationship between Novell and KDE evolve?
I'm sure that we are going to sponsor KDE development in the future. We have (I think) sponsored every major KDE event, like we did with aKademy this year. So why should we stop now?! Novell is very much committed to KDE!
Comments
Well, what I mean is that what I see on my screen looks better using konqueror.
I'm using mozilla right now, and the drawing (is that a better term than rendering then) is terrible.
I se only very few sites where konqueror falls short due to CSS, but maybe my browsing is too limited. I have never had any problems myself though, with the relatively simple sayout that I like.
There are several fairly simple CSS rendering bugs with Konq.
As one example, there's a fairly obvious bug which you can see on many pages that use absolutely positioned elements (yes, it's in the bug reporting system, and has been for a year or so). I use these to implement page-number sidenotes on all the HTML editions of Project Gutenberg texts which I produce. As a result of Konq's flaws, these are much less readable in Konq than in any other modern browser.
I love Konqueror the file manager, but dislike the browser. The browser's just really poor at rendering pages, and it's a little too integrated with the FM. For example, I like HTML documents to open in a text editor in the FM, but that behavior isn't exactly desirable for browsing.
I'm not hoping that KHTML development will stop, but I'm hoping that these absurd contentions about it being better at displaying web pages than Mozilla and Opera would.
I have this nagging feeling that it's Novell's fault that there's not enough manpower on KHTML. They could easily afford one or two developers to work fulltime on KHTML -- maybe even stretch it to three. One for dhtml, one for css2 and one to integrate Apple's work.
That way, they wouldn't have to shed crocodile tears about KHTML and they wouldn't be stuck with taking shortcuts, but could plan for the long term.
And one or two KMail develoers, two or three for KDevelop and of corse they should hire 10-20 KOffice developers. Or simply about 200 KDE developers. Why don't they hire > 5000 developers to outflank MS?
Maybe they have to look at their costs?!?
Well, they already hired the KTop developer :-)
But seriously, you're right. Some guys, Waldo, David, etc, are really the people that bring KDE to a higher level, obviously not the one interviewed.
Lately I find myself using khtml by way of Konqueror 90% of the time. Konqueror needs a little bit more profile differences between web and file browsing but the khtml itself has been getting a big boost by the Mac people who are using the code to make a new IE free web browser and putting the changes back in the tree for KDE to use. The Konqueror interface itself needs an easy way to set different home pages and button layouts for both profiles but the khtml rendering these days is awesome! Not many people use the gecko engine in Konqueror which is simply a menu click away as long as the gecko bindings were installed and there is a gecko based browser installed. I wonder when a khtml based browser will show up for windows? I know one will exist in Mac very soon if it doesn't exist already. I use Konqi for banking as well but not with a native agent string as many do not recognize it even though it says "Mozilla 5 compatible" but the Konqueror name throws it off.
Let me put another issue on the table: Languages. Support for all European languages is crucial when you want to sell it to the EU.
Don't let it die. There are loads and loads of sites it cannot render properly but the speed it has over Gecko is so great I for one will still keep using it when I can.
That makes two of us. I really hope KHTML continues being developed.
It's an outstanding piece of software.
Count me in too.
I agree. Keep up good work!
same here I love khtml. I don't want that patchy gecko stuff.
Me as well. Although what I'd actually like would be for Opera to be open sourced and integrated with KDE (it's the only non-KDE app I still use on a regular basis; the GIMP would be the second if I had any need for it), but that's obviously not going to happen, so making Konqueror more Opera-like is the next best thing ;). KHTML > Gecko for that.
In fact, I would appreciate being able to choose which engine to run. khtml is fast, low memory, etc. I will be choosing khtml
I like it very much and us it every day. Don't give up khtml (neither do koffice).
Wolfgang
if you look at these stats :
http://cia.navi.cx/stats/project?s_catalog=3
you can see that kde has not many developers compared to the other projects.
Where do you see on this page an information about the developer amount?
Unless i'm reading it wrong it seems to show that KDE is the most active OSS project.
...which means that the KDE developers achieve that much with very little resources. That speaks for the quality of the Qt toolkit and the KDE framework.
...and, I should add, also reflects the quality of the developers who built that base.
According to the page you listed KDE is the most active Open Source project listed. Where are you getting # of developers?
Bobby
Who was/how many people were working on a project, subproject, package or module can be seen on CIA by browsing the respective pages. KHTML for example had 19 people touching some code there in the last 2.52 months, see http://cia.navi.cx/stats/project/kde/kdelibs/khtml
so as you can see on CIA , kde has 561 developers (see the related column on the left) - can anyone provide numbers of other projects (closed source) ??
how many developers does microsoft have on - for example - longhorn ? and they work 8 hours a day i suppose....
Keep in mind that most of those developers are translators. Artists and stuff are also included, not only programmers.
There are usually not more than one or two CVS accounts for the leaders of a translation team.
How many workers do TrollTech has on Qt, working 8 hours a day I suppose?
26 (Source: http://conference2004.kde.org/slides/eirik.chambe-eng-keynote.tar.bz2)
"I think D-BUS will come probably with KDE4, not earlier then that."
*than that*
-
"During your talk at aKademy you said we needed less toolkits. What do you mean by that?"
*fewer* when dealing with multiple items.
-
"It is a real pain and doesn't work 100% reliable. "
*reliably 100% of the time*
I believe Fab's email address is [email protected], and I know that he would appreciate having a native english speaker check articles for The Dot. So when you are ready to take the next step up from griping, you know what to do...
--
Simon
Ok, email sent.
Thanks for your email and offer to help. This is the way to go.
Ciao
Fab
Thanks, you have to realize that most of us are not native-English speakers :)
KDE has to many options that make it dificult to use when it comes to end users. If kde could do the same gnome has done, well, it will be a winner.
Nice try! Go troll somewhere else.
I agree.
An enterprise desktop needs to be simple to help avoid help issues.
I've been a linux user for nearly 10 years and a gnome user for a large portion of that.
I found KDE to be very powerful and configurable but also very overwhelming for anyone that has come from a windows/gnome/mac background.
Overwhelming is not what you want to support in a 1000+ enterprise desktop environment.
It's not good having 10,000 settings for everything as thats where users will break things and put more pressure on support.
I think Novell is doing a great job attempting to address these issues and I have actually seen their work on the Novell Linux Desktop and it is quite amazing what they have done in such a short time.
> An enterprise desktop needs to be simple to help avoid help issues.
gconftool-2 -t string -s \
/apps/metacity/global_keybindings/run_command_1 \
"Delete"
gconftool-2 -t string -s \
/apps/metacity/keybinding_commands/command_1 \
"xscreensaver-command -lock"
gconftool-2 -t string -s \
/apps/metacity/global_keybindings/run_command_2 \
"c"
gconftool-2 -t string -s \
/apps/metacity/keybinding_commands/command_2 \
"xmms --play-pause"
gconftool-2 -t string -s \
/apps/metacity/global_keybindings/run_command_3 \
"b"
gconftool-2 -t string -s \
/apps/metacity/keybinding_commands/command_3 \
"xmms --fwd"
gconftool-2 -t string -s \
/apps/metacity/global_keybindings/run_command_4 \
"t"
gconftool-2 -t string -s \
/apps/metacity/keybinding_commands/command_4 \
"aterm"
gconftool-2 -t string -s \
/apps/metacity/global_keybindings/run_command_5 \
"m"
gconftool-2 -t string -s \
/apps/metacity/keybinding_commands/command_5 \
"aumix -v +5"
gconftool-2 -t string -s \
/apps/metacity/global_keybindings/run_command_6 \
"m"
gconftool-2 -t string -s \
/apps/metacity/keybinding_commands/command_6 \
"aumix -v +5"
gconftool-2 -t string -s \
/apps/metacity/global_keybindings/run_command_7 \
"e"
gconftool-2 -t string -s \
/apps/metacity/keybinding_commands/command_7 \
"emacs"
How do you explain this simple stuff on telephone in case a Customer calls ? It's easier to tell them to go into Control-Center->Regional&Accessibility->KHotKeys. I know this is a bad example but there are many other situations under GNOME where you have to manually alter GConf keys to get what you want.
You can do it with gconf-editor.
> An enterprise desktop needs to be simple to help avoid help issues.
My digital camera isn't simple and can you set the time on your VCR or program channels on a car radio the first time you've seen that model car? Computers are by nature not simple and software is by nature not universally configurable for all users.
> Overwhelming is not what you want to support in a 1000+ enterprise desktop environment.
No, you want Kiosk mode and a competent administrator. KDE can help with the first part and it can lock down anything and everything on the desktop. I've met people who administer companies on this level with KDE. They love it.
For a community distro (Fedora, Debian etc), supporting both GNOME and KDE makes sense, these distros attract developers.
For a corporate product, supporting both environments is simply idiotic. Remember these CIOs have likely never heard of KDE and GNOME, so the choice is meaningless to them. In fact in a vaccum they might actually make the wrong choice and be left high and dry by a vendor suggesting they do an about-face, doubling training costs. For new users in businesses, they want something that "just works", not a Mandrake-like kitchen sink.
I know the developer community feels strongly that the receptionist at FooBar corp has a mature opinion on KHTML vs Gecko but do a gut-check here...as long as they can perform the tasks they perform in Windows in a predictable fashion, thats all they want.
> ..as long as they can perform the tasks they perform in Windows in a predictable fashion, thats all they want.
I second that !
...but... A lot of intranet webbased CRM systems make heavy use of DHTML..., which is not very well supported by khtml... sad, but true. Still, webbased CRM systems can support an entry for Linux on the desktop. If it works on Linux, you could set up cheap boxes for employees without buying windows licenses (btw. that's what .net is all about: It's just there to prevent _interoperable_ webbased applications that need a modern browser and no windows os any more)
Let me think,
consumers need all the choices but only 2 years of security updates? That is the reason why consumers have still many Windows 98 PC around? 2004 - 1998 = 2 years, correct?
Busineses / enterprises look for 5 years of support (I'm not sure about that).
The main reason for (small) businesses and consumers to keep old OS versions around is that the hardware does not support the bloated new version. I think if Linux could offer an upgardeable but resource aequivalent version, most consumers would take it. It would be wise to distinguish between a core that is supported longer (and or upgraded) and a nice to have app level, where support is stopped after 2 years.
Also, don't do fake support the latest races. My KDE 3.3.0 on SuSe 8.2 (yes my cranky old machine would not handle a 9.1 well, not to mention the upgrade effort) just rendered my configuration and capability for signing and crypting e-mails brocken. Why? Because the underlying GnuPG and several libs have not been upgraded. That is painful, very painful.
And don't get me started on Kontact (crashes all over the place, crappy partial integration, not worth the time waiting for it to install, but much needed to make a ral dent in the enterprise space) or Konquerer (which I love an use daily, but it crashes with all sorts of plug-ins - Flash, Java, ..., and I can't control which site pulls those things on me. By the way PDF support looks very poor). Also there are a few nasty behaviors in KMail or KOrganizer, that should have been debugged before release.
Enough of my rant. I wish KDE and SuSE a bright future (and me more stable releases)
K
http://www.conficio.com/
> 2004 - 1998 = 2 years, correct?
2004 - 1998 = 6
n/t
SuSE Linux Desktop for example has longer support (4 years?) and fewer updates (every second year?). Just like SuSE Enterprise Server or Red Hat Enterprise Linux on the server.
The users targeted by "ordinary" SuSE packages usually update with every or every second release...
"The main reason for (small) businesses and consumers to keep old OS versions around is that the hardware does not support the bloated new version."
Hmm. Well my scanner is not supported by WIN-XP, no driver, Linux has no problem with old hardware. The scanner has the same features than a new one, only the plug has changed to usb.
WinXP creates hardware waste because of lack of commercial support for drivers.
New software is usually buggy but most parts of KDE are matured. Only releases and usage and active maintanance leads to more stable releases.
I never liked Mozilla. Since i use Kde (Version 1.1), i used Konqueror as Filemanager and Browser.While Konquerors usability as a webbrowser were very limited in former versions, Konqi now matured to a cool and fast browser.Since the very first versions of Konqi, i hoped that it will be some day like it is now - the swiss army knife with very fast startup, nice options and font rendering, anti-popup and cookie-handling.
A long time ago i have choosen Konqueror as my main webbrowser because it felt right.Mozilla was already there and ways in front from the technical abilities, but i never liked it.It wasn't the look only.
It makes me very sad to read by people sentences like this:
>It is a bit sad for KHTML and I hope that despite this people will still maintain it as >it is a nice lightweight browser. If it would be a purely technical decision, KHTML >has the better architecture, but sometimes you need to go the shortest way to >get to your target.
Please also support your veteran users !
I often think the demands of ENTERPRISE BUSINESS or COMPANIES will set the
direction of Kde development.In favor of new users old ones are not so important anymore.People like me, that got accustomed with certain kde things and have their favorite applications, started to love applications and how they matured read are frightened by such statements.
It gives users feelings like "Don't get used to do things this way, tomorrow it will be or feel different so don't start to like how it works or looks now !"
The Kde developers started to work on konqueror because there was a need for a webbrowser that follows the look and feel of the 'K Desktop Environment'.
If Khtml is cleaner and technically superior why drop it or slow down development ?
When this happens for Gecko, could that happen everytime kde developers find out that other technologies are some steps in front, to adopt this other technology ?
What a waste of valuable programming efforts to have a short fast solution!
It is like capitulation.Like "We don't get it working the way we want it (now), so we see who did it and take that existing one."
So my wish to the kde developers out there:
Please don't drop or neglect KHTML !
Users like me would be very sad :,(
If there is a need to integrate Gecko into Konqi please make it an option.
Perhaps the only way to work with long lasting environments is to choose the console - i don't hope that.
Heiko
Long time Kde user and great fan of Konqueror
Nobody within KDE is suggesting dropping KHTML or even introducing a dependency to Gecko. The only thing that changed is that lazy distributors now have the choice packaging up to three different HTML rendering engines (KHTML, Opera, Gecko) for Konqueror.
I use gentoo. So this wouldn't be a problem for me, i think.
If this is only a question of configure switches, then things are not so bad.
Integrate gecko into konqueror because of the need of distributors seem to be ok to me since it was basically done in about 3 day at aKademy (I think). So it does not eat up much time.
But it would not be understandable why to throw away all this great work. khtml is cool and technically better than gecko. Keep it.