The much-anticipated release of KDE 3.1, originally
scheduled
for this week, has been delayed, most likely until early next month.
On the positive side, the delay could not have been for a better reason.
Dirk Mueller, the KDE 3.1 Release Coordinator,
explained
that the delay was caused by a security audit of the 3.1 CVS tree. The audit was prompted by the identification of a class of vulnerabilities by
FozZy from the "Hackademy Audit Project" (thanks to FozZy and all others
who help identify security issues in KDE, and a big thanks to Dirk
Mueller, Waldo Bastian, George Staikos, Lubos Lunak and the others
who are leading or helping in the current security audit).
After discussing the issues with the packaging engineers and KDE
developers, and in
light of the upcoming year-end Holidays, the decision was virtually
unanimous to wait until early January for the official 3.1 release.
While the decision was a difficult one, and is sure to disappoint quite
some people, hats off to the KDE Project for making the right decision
and treating security with the utmost importance that is warranted.
The security fixes will be backported to KDE 2.2.2.
In the meantime, what was to have been KDE 3.1 (with some, but obviously
not all, of the security audit completed) has been re-tagged as
KDE 3.1 RC5 and is now available for testing. The KDE Project
hopes that with this release more bugs will be found and reported by the
community so they can be fixed while the security audit continues.
Stay tuned.
Comments
I wanted to start by congrats to KDE, it takes a lot of courage to pull a working and viable entity off the shelves and patch it later (read: i now fully beleive the linux world IS bettter than the "other guys")
Now admittedly, I am a near linux/power hungry newbie, but I need to ask: does it really matter if your x comes up 0.1ms slower if it means that it is more secure? I am mainly writing in reponse to those who are raving that 3.1 loads faster. Personally, I would eat a few extra seconds if it meant that everything I need to be secure loaded everytime. If you happen to make something load faster, but without sacrificing security/functionality, then I would love to see your code.
Well, never undeestimate the effect of 1ms on a p4@3Gz on a 486 SX system ;)
true enough, but you see the point. Loading linux up everyday for a typical use where it is being shutdown every night, well, this is still going to be a slow process.
you still need to load a keyboard in order for it to work properly, there isn't much you can do to prevent that. now if you need to load on more module in order for the computer to be safe from some of the people in this thread, then this is where my point comes into play.
I'm running RC5, and I've noticed a lot of improvements in things that I use.
However, I also noticed how much longer this release took to compile than other releases. KDE is getting way too fat with a high number of apps few people ever use. I hope that the KDE team does some research and a policy shift soon, and starts trimming the fat.
I would also like to see a release branch where there's a feature freeze and a focus on stability, reducing the memory footprint, and increasing performance.
Other than that, I have very little to complain about. KDE is (imo) clearly the best desktop available.
I agree. And the bad thing is that it was very easy to prevent this problem, just by doing separeted packages instead of a few with lots of things in side.
For example: I never use noatun, but as I don't wanted to crash anything by removing it from makefile, there was I compiling something I don't use...
> I never use noatun, but as I don't wanted to crash anything by removing it from makefile, there was I compiling something I don't use...
#####
You certainly don't configure by hand every time, but use a custom configure script instead, no? Simply add a line like this before the configure command:
export DO_NOT_COMPILE="noatun"
I think it's more appropriate to have the user set what they'd like installed than to make them turn off what they don't. And there are, between all of the KDE bundles, so many applications that this is very tedious.
IMO, the solution is to narrow the focus of these bundles down to the most important, most needed/wanted applications. Move the rest of them out. The developers of those applications might be offended, but it's the right thing to do. KDE's getting porky.
And you know what they say. You can't teach a pig how to sing. It wastes your time, and it annoys the pig.
Maybe someone should create a ncurses program for running KDE configure scripts that have all those kind of options?
It would help people a lot IMHO.
There was a discussion about what matters, binaries or sources, for the end-user in kde-core-devel.
Well, take the number of hidden options that exists in configure (most users dosen't even know about export) and I tell you: what matters are binaries :(
"KDE is getting way too fat with a high number of apps few people ever use.".
My view is the more applications, the better. KDE can be packaged to only include the basic desktop and no/few applications, or packaged to include everything.
Some distributions make seperate packages for all programs (i.e. noatun has it's own RPM), some only make one large package for every KDE package (i.e. kdemultimedia is just one big package). This is a packing issue.
My view is that KDE should include as much as possible, giveing users the option to choose what parts they want. Noone is forceing you to install everything.
I'm no computer wizard, but even I have figured out how to split the KDE packages into seperate, smaller RPM's giveing my girlfriend, parents and friends the ability to choose what spesific parts of KDE they want.
I have been useing KDE since 2.2, and spendt much time on the new searching for good KDE apps for everything. Alot of the stuff I've downloaded seperatelly over the years has now made it into KDE, and I think that's just great. No more browsing every apps homepage to check for updates, just upgrade KDE and get the latest stable versions of everything (and again, it -is- optionall if I want to install these parts or not).
I think KDE should have ONE (not two, three, just the best one) application for everything as standard.
I can't disagree more. If you asked around, I think you'd find most people would disagree also.
People should not have to make subpackages out of the various KDE suites to eliminate the applications that, when it comes down to it, most people realistically don't use. This may be anecdotal, but just about everyone I've talked to has complained about KDE bloat, many moreso than I ever have.
People don't really have a lot of choice when it comes to narrowing that stuff down. It takes over 9 hours on a 1.5G machine to install most of the packages associated with a KDE release.
Call me crazy, but that's excessive for a desktop distribution, at least half of the applications of which are not widely used.
1. It's a manual process for those who compile KDE to remove them (if it is in fact possible).
2. The makers of binary packages for linux distros and other unix platforms alike have to default to compiling everything, and therefore forcing this bloat upon their users.
3. Most people are not rolling custom RPM's of the KDE stuff for their friends and neighbors, and most people are not the beneficiaries of such packages. Most people are getting everything + the kitchen sink.
Take it for what it's worth. KDE should focus on building a good, stable, small footprint core, and let people tack on additional applications with secondary packages as it suits them.
Throwing every little kde application in the world into these bundles might be great for having a lot of bullets on a Gnome vs KDE comparison chart, or a presentation or something -- but ultimately it results in a lot of wasted bandwidth, CPU time, disk space and unnecessarily complicates an otherwise gorgeous desktop suite.
I would appeal very strongly to the KDE committee to make some adjustments in this way.
Well, a nice thing would be to have a small "[kx ]dialog" based script/makefile-thingy, which asks which parts you want to compile.
Would be nice if somebody would try to implement something like this.
Like ./configure --ask-for-packages
and then a dialog pops up where you can select/deselect the various subdirs.
Alex
Yes. The word is focus.
But even limiting to a maximum of 3 per category would be an
be a big improvement. This also applies to the Distros.
For the intial install less is more.
Later one can install any package you want.
Cant - per package group - there be voted what packages go in it? So each new KDE release would be released via publicly the current most populair KDE based apps?
This would strip at least some bloat for each package group.
I'm just going to wait for KDE 3.1. I'm running RC3 right now, and it works great. I've got a question though: Will there be patches? I'd hate downloading all the code on 56k again.
Do it again, baby ...
Just do it again ...
Download is a great love act ...
As an end-users and dedicated KDE user I think that waiting to release the next version a month or two is absolutely the right decision. I have migrated from the land of Redmondians because I get sick and tired of over-priced and underperforming products. If Bill, Steve and their many men of merry would have taking the time to develop and audit their software properly they wouldn't be getting such bad press and putting their clientele's data at risk. I can wait for better coding. KDE 3.0x is working just fine for right now. Sure, I want all the improvements I've been reading about. But, It just goes to show that you can have it feature rich and fast or you can take your time and have a better product with new features and better code/security by doing it right in the first place. Keep up the good work!
Thanks again for giving me an alternative that works. :)
if these RPMs complain that libart_lgpl2-2.so.2 is missing, get it from:
ftp://rpmfind.net/linux/KDE/stable/koffice-1.2/Mandrake/8.2/libart_lgpl2...
just installed mdk to try out kde3.1rc5, and didn't want to install all the "bulk" and scrapped some apps during the installation... anyways, i think there should be a note with the binaries saying that this rpm is needed in order to run this kde release (without it, when you type "startx" it just quits after briefly showing the X screen, without displaying any error message...).
no reply necessary (i guess) - just actions (as suggested above) should be taken ;)
dunno about you but i have been a kde user since 2.2 and there is one thing im sure of : even after they complete their audit and delay release, the damn thing will still have bugs, will still crash, and will still eventually be found to have security holes, so just release the damn thing.
:p
if it actually is solid, i will sh*t a gold brick and send them a chunk of it.