Onebase Project Releases "KDE-3.3 Beta 1" LiveCD

The Onebase Linux Project has released a special flavor of its
OnebaseGo-2.0 edition, which includes the complete KDE 3.3 Beta 1
"Klassroom" suite and KOffice 1.3.2. The main purpose of this
flavor (LiveCD) is to try, test and report bugs on this beta version.
And also to provide a technology preview for KDE users.

The Onebase Linux Project is a community-driven Free and Opensource undertaking, with the objective of providing a complete, multi-purpose operating system based on the Linux kernel. OnebaseGo is a portable OS (LiveCD) that comes in a CD with all the features of Onebase Linux. It comes with state-of-the-art remastering called Docking, eXtended package store and HD-installer.


could we somehow track the usage of the cds for bug reporting ?

By chris at Wed, 2004/07/14 - 5:00am

Also nice for checking if some reported bugs were fixed meanwhile, and help clean the bug database.

By John BugReporti... at Wed, 2004/07/14 - 5:00am

It would be interesting to distribute a live CD like this with the UsageMonitor [1] that sends reports to some central place. I wonder what app people try first? Last? How long they use it for?

[1] http://www.kdedevelopers.org/node/view/376

By mbucc at Wed, 2004/07/14 - 5:00am

It would be great. BTW I would like to let you know
that customizing the Onebase LiveCD is very easy.

In three steps have Usage monitor in the CD.
(with this remastering).

[1] click the "Dock" icon in the desktop
[2] Update gallery (ol-apps -u) and Create a .olm for your application (reference:
and copy the .olm to the approtiate category folder in /mnt/dock/olgo/ONEBASE/etc/OL/gallery/
and install it using command: olm-go -b packagename
[3] Click the "un-dock" icon in the desktop to auto generate
a new ISO.

Ofcourse this includes an additional step of creating
a .olm as it is yet to be in the gallery.

Sample .olm link:

By all4one at Wed, 2004/07/14 - 5:00am

The problem with a normal user is that s/he can't compile KDE betas (due to time constraint, and not all KDE users have Fast computers or the patience to see all those packages getting compiled). Hence s/he is unable to report any bugs. This LiveCDs or Precompiled Binary packages will improve KDE bug reports which leads to bug fixing which finally leads to better KDE.

I wish the 'Best of Luck' for the endeavor. Hey KDE Developers, Why don't you put binary packages which you have compiled for your distro at ftp.kde.org?

By Asif Ali Rizwaan at Wed, 2004/07/14 - 5:00am

Onebase Linux already has source and binary package
installation support for KDE 3.3B. And I notified this to the
Webmaster, but it is yet to make it to their package list.

Probably I did not inform them in the right way, dont know.
Or they may be busy.

By all4one at Wed, 2004/07/14 - 5:00am

Where i can find the source sources of this LiveCD ?

By RMS at Wed, 2004/07/14 - 5:00am

It uses the original KDE sources.

The package management system in Onebase is OLM. And it (OLM)
uses simple scripts called .olms to install software.

The tarballed OL-apps gallery is found at this link

And you find more about OLM from here:

By all4one at Wed, 2004/07/14 - 5:00am

Excuse me for this OFFTOPIC post. But I think this bug report is rightly important for KDE 3.3...


CONTENT of the Bug Report:

I have noticed that KDE and GNOME and other (Mozilla) are unable to handle large files effeciently without losing responsiveness.

Like KWord can't handle large Documents whose pages are in 100's. Konqueror can't load a >3MB file quickly. KWrite, Kate, Kedit are also getting unresponsive for atleast 10-15 seconds to load a mere greater than 3 MB file.

Surprisingly, I have found that Elvis and Emacs and Links (not lynks) browser are very efficient in handling large files.

Please Observe:
Elvis, Emacs, and Links browser takes 2-3 seconds to load a >3mb file. The processor utilization goes to 100% for just 1-2 seconds here.

whereas any KDE application, Mozilla 1.7, firefox 0.9, Netscape 6.1, gedit, galeon etc. takes more than *15* seconds and still remain unresponsive. upto 15 seconds the processor utilization goes to 100% (used ksim). And As long as the BIG file is loaded, the application which is loaded with the Big file remain somewhat sluggish, like scrolling becomes slow or takes 1-2 seconds.

Expected behavior of KDE Applications:
1. Like 'elvis' text editor KDE application MUST use temporary files for loading any file, small or big. Here is elvis about:

"1. WHAT IS ELVIS-2.2_0
Elvis is a clone of vi/ex, the standard UNIX editor. Elvis supports nearly all of the vi/ex commands, in both visual mode and ex mode. Elvis adds support for multiple files, multiple windows, a variety of display modes, on-line help, and other miscellaneous extensions.

Like vi/ex, Elvis stores most of the text in a temporary file, instead of RAM. This allows it to edit files that are too large to fit in a single process' data space. Also, the edit buffer can survive a power failure or crash. "
please note:
"Elvis stores most of the text in a temporary file, instead of RAM. This allows it to edit files that are too large to fit in a single process' data space."

This is what I feel KDE lacks... KDE Applications are sluggish with medium to large (1mb-10mb) files due to loading the file into ram only (as I assume, I don't have proof, because I am not a developer :))

Please Follow 'Elvis' way of handling files, which is quite efficient. Or Emacs also loads huge files as quickly as in one to two seconds.

Amazingly a well formatted 5 MB English-To-Hindi HTML files gets loaded in "LINKS" (not "lynx") browser in just 2-3 seconds whereas all other browsers take around 15-30 seconds or just get hung.

I humbly request you superb developers to kindly look into the 'Efficient loading of files' by elvis, emacs, and 'links' browser. and 'Inefficient loading of files by KDE applications.'


By Smith at Wed, 2004/07/14 - 5:00am

someone in #kde-devel mentioned that Kate was recently enhanced to support larger files. Apparently getline() isn't what it's cracked up to be. You should try the beta and see if you notice a speed up.

By Ian Monroe at Thu, 2004/07/15 - 5:00am

I just tried it and the loading speed is much better - I was working with some large files a few days ago and they took 5-10 seconds to load, but now the delay is barely noticeable.

By Richard Garand at Fri, 2004/07/16 - 5:00am

Well, I booted it under QEMU and it asks for a password to let you enter X?
I can't find it at the link:


without password i can't login to test... empty password and root username don't work.

By emmanuel at Wed, 2004/07/14 - 5:00am

The password is mentioned in the support and features page of
OnebaseGo in its Website. (onebaselinux.org)

Username: root
Password: one

Note: There is an errata, the volume in kmix is turned to
mute by default. You need to increase it.

By all4one at Wed, 2004/07/14 - 5:00am

This is superslow, when I have the file, I will post a torrent here.

By Magnus Lundstedt at Thu, 2004/07/15 - 5:00am

Here is the torrent of this liveCD:


I am seeding it @ max 10 mbit for now.

By Magnus Lundstedt at Thu, 2004/07/15 - 5:00am

...it's a 600mb image!

If the developers find this is a good idea for getting more people to beta-test, then someone could make a "tighter" betaKDEliveCD with _only_ the software to test and the required dependencies, that would be 200-300mb no?, an easier size for downloading. And if someone does that distribute it on BitTorrent from the first moment.

By me at Thu, 2004/07/15 - 5:00am

its indeed big. but I am impressed with onebase's features... if it wasnt the fact I just installed debian, I'd go for it ;-)

and at least I will try the docking feature... thats really cool!

By superstoned at Thu, 2004/07/15 - 5:00am

My complete /opt/kde-3.3 installation (with one additional language, KOffice and some apps like k3b) is almost 600MB too. Of course this is uncompressed but then the CD has to contain other stuff like Linux, GNU and X-Server too.

By Anonymous at Thu, 2004/07/15 - 5:00am

I would really love to see a "kde.org LiveCD"...

Just stuff it with all kde's dependencies and release a mini CD always with a public kde release?!?

Nowdays there are sooooo many simple scripts that could do the building, why not start to use one of them?

It's silly to hunt for a different LiveCD at each kde release...

By Nobody at Fri, 2004/07/16 - 5:00am

Yes. In my opinion a much smaller live CD would better for testing KDE Beta version or Release Candidates.

Maybe a SLAX based Live CD would be the right way:


At the moment this SLAX CD uses the latest stable KDE and is a relatively small but fine Live CD.

By Bend Lachner at Fri, 2004/07/16 - 5:00am

SLAX does not contain all KDE modules (no kdeaddons, kdeedu, quanta, kdevelop, ...).

By Anonymous at Fri, 2004/07/16 - 5:00am

I read that any statically compiled application (./configure --enable-static ) application is faster than normal (shared library) application.

Has anybody tried a fully static KDE? Is it faster?

By Asif Ali Rizwaan at Thu, 2004/07/15 - 5:00am

If it is only one KDE application you are running, it might be faster (if it was possible). But multiple KDE-applications share their libraries and would use much more memory if you statically linked them all.

By Allan S. at Thu, 2004/07/15 - 5:00am

You can't build KDE that way

By Sad Eagle at Thu, 2004/07/15 - 5:00am

In webbrowsing mode konqueror is crashing when I try to open a new tab CTRL-SHIFT-T.

Strangely, in filemanager mode this crash does not happen.

Apart of that, the flicker fixes seem to make konq just better and look
more polished professionnal.

Keep up the good work, I can't wait for the the release of 3.3!

By ac at Thu, 2004/07/15 - 5:00am

Maybe I should add that these problems occur with kde 3.3b1 from the onebase live-cd... :-)

By ac at Thu, 2004/07/15 - 5:00am

Hi, I've tried this version, and just playing for some time, I've been able to crash two apps (one is Kwrite, the other I don't remember).
I'm a newbie, but what surprised me was that the error box appeared (seg_fault?) telling that "back tracing" was not possible because of the gdb (or something like it) missing.
I'm wondering why for a distro that has the porpouse of finding bugs, there is not an automatic notify mecanism like the one Mozilla has (when Mozilla crashes, the stack and other important, for the programmer, information are sent to the Mozilla site for furhter investigation).
In addition, since when you get an app crash you are not able to remember exactly the 14 steps that drove you to that crash, would be great having a sort of "activity recorder" turned optionally on, that can log what you did and could "play" the sequence again, step by step.
Just some thoughts...
Marco Menardi

By Marco Menardi at Fri, 2004/07/16 - 5:00am

hem onebase is not a bug-finding distro, i'm using it all day long actually

By bacon at Tue, 2004/08/03 - 5:00am