Slashdot Mirror
KDE 3.0 beta 1 is out
From the development team who tries to break every development speed record (last month they released KDE 2.2.2) comes KDE 3.0 beta 1, with lots of new features, new QT (3.0.1). It is beta 1 so expect crashes. You can find release notes and download locations over . A full feature list of whats planned to be on KDE 3.0 is also available (hmm, quite a big list) and some screenshots are available here. Please read the README files for your favorite distribution before installing the files as those packages are not replacing the KDE 2.2.X binaries (if you have it installed).
The feature list URL is incorrect. The right one is this
Don't Panic
I believe that this is the first KDE "release" where KPilotDaemon supports USB-based palm devices (such as Visors). Anyone know if there are meaningful conduits using the archeitecture, though?
Solution to blink tags: wrap them in another blink tag, with a javascript delay loop, so they cancel each other out
That's what I first hoped. That Slashdot had finally started to mirror URLs they link to, to protect other sites from the rampant bandwidth rape which comes with a mention on /.
Alas, it was only a typo...
A few people have been complaining here that KDE 3.0 looks the same as KDE 2.x. I just wanted to clear a few things up:
- First of all, KDE 3.0 is largely an architectural upgrade - we have moved to the new Qt 3.x series, and this needs to be reflected in KDE 3.x. The Qt 3.x series has a lot of bug fixes and additional features such as database connectivity, better handling of data structures and the like - this increased stability is passed on natively to KDE 3.0.
- In terms of interface updates, KDE 3.0 will see some updates but bear in mind that this update was aimed at primarily porting the codebase to Qt 3.x. Any additional interface updates will be added as the need arises - we always like your suggestions and bug reports are always welcome.
- KDE 3.0 is largely about increased functionality - examples include better JavaScript, a more integrated Konqueror, new modules such as the KDE Educational Module, the font installer, kernel compiler etc. These things are really likely to appear in 3.1 and further releases.
- For those of you who are gonna bitch and moan about KDE, GNOME, XFree86, Kernel, Mesa etc...why not just help to correct the things you don't like. You don't need to be a coder to help ny project - *everyone* can help an open source project.
Please be patient folks and keep those bug reports coming in - we value your help.
Jono Bacon
--- Jono Bacon - http://www.jonobacon.org/ Writer - Web Developer - Musician
If your in the UK and need a fast download of KDE, or just about any other download, try http://www.mirror.ac.uk/ or ftp://ftp.mirror.ac.uk/ http://www.mirror.ac.uk/sites/ftp.kde.org/pub/kde/ unstable/kde-3.0-beta1/
ftp://ftp.mirror.ac.uk/sites/ftp.kde.org/pub/kde/u nstable/kde-3.0-beta1/
Check out the icons at kde-look.org
Yes. At first sight, KDE looks a lot like Windows. KDE is supposed to make the switch from Windows to Linux easy.
However, there are true advancements. Those are not eyecandy. You won't see them at first sight. But if you begin to use KDE, you'll soon love them.
F.e. there is the kio layer. Any KDE program can load from and save to any file service. Open a script in your IDE directly from a FTP server and save it back to the server. kio accepts plugins. If you write a Freenet plugin, any program can load from and save to freenet.
And this is just one example. Look at how programs and components can be integrated using kparts. Or at how nationalisation is done.
So you're claiming your KDE needs 450MiB memory? Wow, I wonder how I managed to run it on a machine with just 96MiB RAM and 128MiB swap (and a lot of free memory was still available).
Seriously, understanding 'top' or 'ps' output is not that simple as it seems. The formula for computing used memory from numbers given by 'top' is : Used_memory = mem used + swap used - cached - buff . Now go again to measure your memory usage, and if your number is still higher than 100MiB for plain KDE, there's something wrong with your install. For me, the number for a booted computer with plain KDE started is less than 50MiB (I'm not sure how much exactly and I'm not going to close all apps and logout just to find out).
Also, important portion of KDE's memory usage comes from gcc/glibc/binutils inefficient handling of C++ libraries ( see http://dforce.sh.cvut.cz/~seli/en/linking2 ). This is being worked on.
It would be nice if this got moderated up. I'm getting tired of repeating it.
Have you submitted bug reports/feature requests for any of these (especially konq crashes)? KDE needs your input to fix these things. Complaining on /. doesn't count :)
."
:)
"Anti-aliased fonts are great, but there are times when aliased fonts are actually preferable. In particular, I used anti-aliased fonts, but in terminals, I *really* want a regular-old courier font. At 1024x768 in my terminals, anti-aliasing makes it difficult to tell the difference between and m and n or a , and
konsole -noxft
It's a life saver, since most AA fonts don't render well in konsole anyway
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
Something that has not been mentionned either here or on www.kde.org: the printing infrastructure has been improved from 2.2.x and because they've switched to Qt 3.0, they can now support bi-di scripts (i.e. your "normal" western alphabets as well as right-to-left ones like arabic and hebrew).
AFAICT, besides the functionality improvements in KMail (and Konqueror, but less obvious IIRC), the ones in the printing system will be the most obvious to end-users.
...or (horror of horrors) compile glibc yourself with Jakub Jelinek's prelinker patches, if you can find them (they seem to have disappeared off the net).
The dynamic linking of libraries is by far the biggest cause of KDE program startup slowness. A big desktop environment has a lot of shared libraries to link to an application at runtime, it's expensive computationally (particularly for C++ libraries), and the way the glibc dynamic linker works right now, it's done every time an application is started or a library is dlopen()'ed (such as when embedding a KPart). It can also cause swap thrashing on machines with limited memory (the entire library must be read into memory to perform the address relocation, only after relocation can the VM drop pages of the library) and obviously, disk contention between this swapping and the application loading can slow things down even further.
What the prelinking patches do (don't get them confused with the objprelink hack which, while useful, is not a long-term or efficient solution) is move the linking time from application startup time to system startup time. A tool runs at system startup, immediately after ldconfig runs, which loads and relocates libraries in its search path, then notes down the relocation addresses. Then, later, when the dynamic linker is asked by an application to load a library, it simply uses the values that were cached earlier. Any libraries that have not been 'prelinked' are simply relocated as normal. The linker also makes sure that non-prelinked libraries are not relocated into the same address space as any prelinked libraries that are not currently loaded.
The next major version of glibc will hopefully include library prelinking by default, but I haven't been following glibc development closely enough to know for sure. Let's keep our fingers crossed. Note that it's not just KDE that will benefit from this, Mozilla will gain a great deal (it, like KDE, is mostly C++ code split into many shared libraries) and even GNOME will benefit a little - doing the dynamic linking on C libraries still costs processor time, although it's much less than with C++ libraries.
The next biggest cause of KDE startup slowness is icon loading - currently every app has to search through the entire set of available icons on startup in order to load the icons that it needs. Not very efficient. Given that KDE has several hundred icons available already and that is likely to increase over time, it needs a solution. Waldo Bastian is apparently working on an icon server for KDE 3.0, which will do that search once, cache the data, and then respond with appropriate icons when an app asks, rather than forcing the apps to do it themselves every time. I'm hoping it also makes it easier and faster to do image compositing (overlays and so forth) with icons.
To sum up: glibc 2.3 together with KDE 3.0 should make a huge improvement to app startup (and KPart embedding) time, and, assuming the KDE guys are tight with their code, may even make KDE 3.0 usable on machines that couldn't effectively run KDE 2.x.
Using GCC 3.1 to build your applications will help.
Right now, you can install Red Hat's rawhide distribution to get KDE 3 built with a snapshot of GCC 3.1.
No, I think that the GNOME project is doomed. In fact, I knew they were doomed the moment that Sun and HP endorsed it.
Why? One word explains it all. CDE.
It was supposed to unify the desktop. Take over the world. Destory Microsoft.
What really happened was that it got stagnant and eventually died.
I already see this happening with GNOME. Just a year ago, I would see new things out for GNOME all the time, whether it be new packages, new features, or what not. Now, I see new things like once every two months.
I've said this before, and so have a lot of other people. But, the momentum of the GNOME project has gone down tremendously. It is going towards stagnation.
This is why I think that KDE will ultimatly succede.
Uh, KDE doesn't take over 20 hours to compile.
Here are the times from http://hints.linuxfromscratch.org/hints/kde.txt
:
kdeaddons: 6 min
kdeadmin: 7 min
kdeartwork: 2 min
kdebase: 82 min
kdegames: 21 min
kdegraphics: 11 min
kdelibs: 55 min
kdemultimedia: 31 min
kdenetwork: 27 min
kdepim: 9 min
kdeutils: 18 min
kdetoys: 4 min
kdoc: 1 min
koffice: 55 min