

KDE 2.2 Released 334
Well, we had covered it being tagged last week, and now, after a hardware problem with one of the main download servers, KDE is ready for download. Except that you'll probably want to go to the mirrors to actually get it. You can get more about it about it from Dre's dot.kde post, or you can read the KDE announcement - and have a good time!
Improvements... (Score:4, Insightful)
1) Was KDESUPPORT not upgraded? It wasn't in the Mandrake binary section or the source section. They should either include it or put a link so people who AREN'T UPGRADING can download it (if it is still necessary).
2) After install ROOT logged in fine, but my users had to kill some
3) First Crash! Something (KDE Daemon) poped up with a SEGFAULT and then disappeared. Nothing seemed to be affected.
4) It is faster and more responsive. I like the new eye candy. Automatic antialiasing (if you turn it on in the Wizard) and everything looks SMOOTH!
5) Better compatibility with some of the web sites I visit. No problems any more for my kids when playing Flash games on Disney.COM. Now if I could figure why half the sites (like Disney) find my Flash plugin and the other half (like Cartoon Network) DON'T, I'll be happy.
Over all, a nice desktop. A very good first impression.
Re:Improvements... (Score:2)
KDESupport is actually just a couple of packages (audiofile and libxml2) that the KDE team didn't develop, but are still neccessary to run KDE2.
Re:Improvements... (Score:2)
I believe it's no longer supplied, since the general consensus is that most modern Linux distributions contain all the programs/libraries that kdesupport did anyway.
Re:Improvements... (Score:4, Informative)
On the Red Hat side, I've replaced it with the non-kde subdirectory on ftp.kde.org.
2) kdm configuration has changed quite a bit, but I don't see what could be causing this. Please send me your old kdm config files.
3) backtrace?
4) agreed
5) The best way to fix this is to tell them to fix up their setup - we can't keep trying to figure out what proprietary browsers are doing forever.
Most of the cases where Konqueror "misrenders" something can be traced down to the fact that it's actually more intelligent than it's proprietary counterparts. Take a look at a couple of changes in the KDE_2_2_BRANCH in CVS for examples.
Mosfets Icon themes manual no longer online (Score:2, Interesting)
It used to be on http://www.mosfet.org/themeapi [mosfet.org]
But Mosfet removed that page...in some moment of rage [mosfet.org]
Mirrrors list (someone had to do it, right?) (Score:5, Informative)
ftp://gd.tuwien.ac.at/hci/kde
ftp://sunsite.cnlab-switch.ch/mirror/kde
ftp://sunsite.mff.cuni.cz/MIRRORS/ftp.kde.org/p
ftp://ftp.rz.uni-wuerzburg.de/pub/unix/kde
ftp://sunsite.informatik.rwth-aachen.de/pub/Lin
ftp://sunsite.auc.dk/pub/X/kde
ftp://ftp.dataplus.se/pub/linux/kde
ftp://ftp.dit.upm.es/linux/mirrors/ftp.kde.org/
Asia:
ftp://ftp.au.kde.org/pub/kde
ftp://casper.yz.yamagata-u.ac.jp/mirror/kde
ftp://linux.sarang.net/mirror/desktop/kde
Africa:
ftp://ftp.sun.ac.za/sites/ftp.kde.org/pub/kde
ftp://ftp.na.kde.org/pub/kde
America:
ftp://ftp.matrix.com.br/pub/kde
ftp://mirror.chpc.utah.edu/pub/kde
ftp://ftp.rutgers.edu/pub/kde
Now, could anybody tell me when the debian (potato) packages of the 2.2. will be available?
Mosfet's Liquid Style Engine (Score:4, Interesting)
For a great visual effect, check out the Liquid style engine which was designed for this version of KDE. I'm running it now, and it looks beautiful:
http://www.mosfet.org/liquid.html [mosfet.org]
-Karl
Re:Mosfet's Liquid Style Engine (Score:2)
I installed it on a build of KDE from last friday at home and to say the least I was stunned.
I run KDE from XWIN32 on my windows machine on a lan network and the performance of the widgets and alpha-blending was 4-5x faster than my G4 466 running OSX. (Remind you, this is over a terminal!!)
If you are impressed with the OSX widgets and menu transparancy, this is a must-see.
(NOTE: It does require a build of 2.2 or (2.2alpha) to work.
Cheers
Debian Packages (Score:2, Informative)
Oh Boy! (Score:2, Funny)
Good way to promote a product (Score:1)
Now that is has been discovered that porn comes in even clearer and sharper with kde 2.2, there's going to be a HELLOVA lot more people downloading KDE now :)
Seriously, kudos to you KDE Developers!
BTW: I never stress about the gooey keyboards... i have a ton in the back... i change then every few hours ;)
Been running it for a week now, great release. (Score:4, Informative)
New features I like:
Pulsating icon when program is loading
Interface cleanup - Finally looks good on hi-res LCD
Bug fixes - Browser is getting more usable day by day
Kdevelop - intriguing program. Hope it continues to mature at it's current pace. Very familiar coming from MS Vis Studio.
Koffice - Hope to see you at 1.1 soon! looking great
Schemes, Colors, Sounds and everything are much snappier
Control panel cleanups!
Setup wizards (makes it easy for windows converts
And lots of GUI toys & options - can change icon & font rendering, window popup speed and much more. eye candy for sure
Again, compile times suck. It takes a few hours to compile kde_base alone on a 1ghz P3 with a gig of memory.
Hopefully Gcc 3.01 /3.1, QT 3.0 and KDE 3.0 will be the killer desktop. 2.2 is a VAST improvement, but only that.. an improvement on existing interfaces and bugfixes.
I do like KDE's object model of sorts, widgets and kparts. Very will thought out implementations, i just hope they learn to quit breaking binary compatibility with each major release :)
Keep up the good work KDE team!
Re:Been running it for a week now, great release. (Score:2, Informative)
Well... after all I've heard they're going to break binary compatibilty one more time with KDE 3. After that, it won't be necessary to do this any more, because of some feature in QT and/or KDE 3.
Does anybody know more about this?
Re:Been running it for a week now, great release. (Score:2)
Re:Been running it for a week now, great release. (Score:2, Informative)
It's not really like that. The decision to break binary compatability was based on the desire to use new features in Qt 3, and encouraged by the fact that gcc 3.0 is going to disrupt BC anyway. Given that decision, you may as well take the opportunity to patch up API's that could use some further improvement.
Re:Been running it for a week now, great release. (Score:2)
Re:Been running it for a week now, great release. (Score:5, Informative)
Doesn't GCC 3 break binary compatibility regardless? KDE decided to move to QT3 when they did so end-users would have easier time. If they did it otherwise, users would lose binary compatibility when changing to GCC 3, and then again when moving to KDE/QT 3. This way they can move to GCC/KDE/QT 3 in the same time, breaking binary compatibility only once (instead of twice)
There was a long discussion about this among KDE-developers
Re:Been running it for a week now, great release. (Score:2)
I'm amazed at how fast 2.2 is over 2.1. That said, the prelinker is a released tool - since KDE does not do *any* packaging whatsoever, it's up to the distro to decide how they want to compile it (in theory, you don't *have* to use gcc), what package format, what directories, etc. Since KDE is released for Solaris, AIX, BSD, etc, the prelinker may or may not apply.
In SuSE's case, I notice that there is an "experimental" directory that came down when I wget'ed the entire group of packages. Maybe those are the prelinked binaries?
Incidently, for those who might be wondering what the Fine Manual I'm talking about, see the Dot article at: http://dot.kde.org/996240227/ and some of the original technical bits here: http://www.suse.de/~bastian/Export/linking.txt
And yes, the gcc team is apparantly aware of this, and will be taking some of this into consideration when new revisions are made to the linker.
--
Evan
Re:Been running it for a week now, great release. (Score:2)
Re:Been running it for a week now, great release. (Score:2)
Besides, standards compliance is not GCC 3's only feature. It is also one of the most portable and retargetable compilers out there (perhaps THE most), which was always the main killer feature.
Re:Been running it for a week now, great release. (Score:2)
>>>>>>>>>
Yes. Because I tend to stick very closely to "safe" code, which is always a good practice, no matter how standards complient your compiler. There is, of course, a balance, but GCC's balance point is in the wrong place.
That would be complete stupidity. GCC 3 is a godsend for C++ developers, and a firm base for future speed improvements.
>>>>>>>>>>
Well, let's see what shapes up. Of course, the competition isn't standing still either. IntelC++, for example, is very fast, makes great code, and is quite standard complient (not to the point of GCC, but very close). If only it didn't cost so damn much...
Besides, standards compliance is not GCC 3's only feature. It is also one of the most portable and retargetable compilers out there (perhaps THE most), which was always the main killer feature.
>>>>>>>>>
90% of the world runs x86, deal with it. Something useful to a very limited portion of the population cannot be billed as a "killer" feature. Maybe if GCC was billed as an embedded compiler, that would be true, but as a compiler for Linux/x86, that feature carries little weight.
I have no doubt that GCC will improve. Whether it will every be better than its competitors, however, is totally up in the air. As it stands, 3.0 is not much better than 2.95.3 in any respect other than standards complience. If 3.1+ changes this, then great. Otherwise, not so great.
Re:Been running it for a week now, great release. (Score:2)
When I started using GCC, nowhere near 90% of GCC targets were for IA32. It could build for 68000, Sparc, PDP-20, etc. I remember hacking on the code generation for a summer job I had ages ago, since the ANSI C compliance was so good (for the time). That is why I said that the retargetable nature of GCC was always its "killer feature". Telling me to "deal" with the fact that 90% of targets NOW are intel, is an assinine retort.
GCC 3.0 is a nice step forward, and perhaps compile speeds will improve in future releases. If that isn't good enough for you, spend the $400-$500 for Intel's compiler, you damn cheapskate. Meanwhile, I'll spend that money on a faster CPU, more RAM, a bigger disk, AND have money left over for good sushi.
GCC is *good* for developers, since commercial compilers have to perform at least as well as GCC in order to expect any sales. So the non-free "competition" must not stand still to remain relevant. As of GCC 3.0, we have the makings of a very good baseline for C++ (and even C99, to some extent) support, and it will just get better. Deal with it yourself.
Re:Been running it for a week now, great release. (Score:2)
>>>>>
God I love being me...
When I started using GCC, nowhere near 90% of GCC targets were for IA32. It could build for 68000, Sparc, PDP-20, etc. I remember hacking on the code generation for a summer job I had ages ago, since the ANSI C compliance was so good (for the time). That is why I said that the retargetable nature of GCC was always its "killer feature". Telling me to "deal" with the fact that 90% of targets NOW are intel, is an assinine retort.
>>>>>>>
I meant that right now, 90% (or some other big percentage) of people using GCC are running x86. That's just the simple truth of the world.
GCC 3.0 is a nice step forward, and perhaps compile speeds will improve in future releases. If that isn't good enough for you, spend the $400-$500 for Intel's compiler, you damn cheapskate. Meanwhile, I'll spend that money on a faster CPU, more RAM, a bigger disk, AND have money left over for good sushi.
>>>>>>>>
Hey, I never said it wouldn't get better. I'm just saying it really isn't that great. And aside from better complience, there is no real tangible improvements in 3.0, despite the extensive changes.
GCC is *good* for developers, since commercial compilers have to perform at least as well as GCC in order to expect any sales. So the non-free "competition" must not stand still to remain relevant. As of GCC 3.0, we have the makings of a very good baseline for C++ (and even C99, to some extent) support, and it will just get better. Deal with it yourself.
>>>>>>
Again, I never said that it wouldn't get better. I'm just saying, that at this point, commercial competitors such as icl have almost as good complience, much better speed, much better code generation, and are more developer friendly (icl has GREAT error messages). Sure GCC will get better, but it isn't that great yet.
Superb (Score:3, Informative)
Well worth the upgrade. It's slicker and feels faster than before, and the "kpersonalizer" is a nice quick way to tune your environment. Konquerer is nice, but still a bit clunky, so Moz wins for me here. KMail simply goes from strength to strength.
If you've not done it yet, go for it. You won't be disappointed, you'll certainly be impressed at the hard work that has clearly gone into this environment. Well done the KDE team!
Re:Superb (Score:2)
Does it do IMAP this time?
KDE and Ximian Gnome Can't Get Along? (Score:5, Interesting)
While I enjoy using gnome more than kde, I like to occassionally use kde by selecting kde in gdm. However, with kde 2.2, this no longer seems possible. Does someone have any suggestions to allow gdm with kde 2.2?
Re:KDE and Ximian Gnome Can't Get Along? (Score:2)
Here's what I'd like to see (Score:3, Interesting)
Good to see desktop enviroments live and well (Score:2)
Perhaps linux on the desktop isn't dead [slashdot.org] yet, dispite what Microsoft and others keep insisting...?
Re:Good to see desktop enviroments live and well (Score:3, Insightful)
In their Linux Myths article they said `Linux on the desktop makes absolutely no sense'. I doubt Microsoft ever acknowledged that Linux on the desktop was ever alive, much less previously living but now dead.
problems... (Score:3, Insightful)
i know it sounds petty, but until something is done to make all of these things less linux-y and more transparent, linux will forever be a server closet geek toy.
sorry.
Ok, user friendly with no installer? (Score:4, Interesting)
-josh
Re:Ok, user friendly with no installer? (Score:2)
Re:Ok, user friendly with no installer? (Score:2)
On the other side of the world - in Europe, the picture is different. KDE is very popular in Europe (most KDE developers are from Europe and outside USA) and Redhat DOES help a bit. Bero (who is one of their employees) does package the KDE for Redhat for releases. Redhat did load some hardware for the KDE team in LinuxTag - so it's not exactly black & white scenario..
some notes (Score:5, Informative)
Just few words about this release (and future road-map)..
This is the final major version of KDE 2.2 - expect KDE 2.2.1 next month with all the last-minute bug fixes (without any new features), and translations update..
The next major version is going to be KDE 3.0 that will be out at around January 2002 featuring QT 3.0.x (with all the QT 3 features), and some changes in the backend, among other things. Most of KDE will be ported from 2.2 to 3.0. SO people who want to either developer QT or KDE applications might want to download QT 3 snapshot and play with it. It's got some bugs - but it's pretty stable.
People who would like to contribute to the KDE development are most welcome to join - you don't have to be a C++ programmer in order to contribute - Graphics artists, GUI guru's, HTML experts and others are more then welcome to join the big KDE famility of developers..
I thin it's also a good time for you - the reader/user to post what do you want to be changed in KDE? what do u hate about KDE? what do you like? What do you think should be improved? What do you think should be removed? most of the KDE developers read slashdot - so maybe your request will be fullfilled - you never know...
As for other platforms - expect KDE 2.2 to be available within days for Solaris (X86 & Sparc), HP/UX, SGI's Irix, IBM AIX, and others..
Enjoy the release people - lots of work has been done on this one - and you get as a bonus %30-%50 speed increase..
Site-specific popup policy (Score:4, Interesting)
Popup windows are annoying on some (okay, most) sites, but a few require them in order to make use of the site.
-Karl
Re:Site-specific popup policy (Score:2, Interesting)
Re:Site-specific popup policy (Score:5, Insightful)
Re:Site-specific popup policy (Score:2)
Of course I'm kidding. But keep in mind that most "pop-under" ads only pop up at the beginning of page load. That is, when you click a link.
Suggestions (since you asked for them) (Score:2)
There is one feature that GNOME has that KDE doesn't which, quite honestly, is the reason I use GNOME as *my* primary desktop. And it's the silliest thing, and perhaps the easiest to implement into KDE, yet I've asked a few times and even spoke to a few KDE developers at the ALS last year about it, and I've yet to see it arrive.
It's the desktop pager/guide. The desktop pager in GNOME (Desk Guide 0.4 in the version of GNOME I'm running now) is much more configurable. You can have multiple workspaces and these workspaces can have multiple windows (configured by the colums/rows option in the GNOME control center).
Thus, if I wanted to duplicate the multiple-workspace desktop a-la KDE - then I would pick 4-6 workspaces and configure these workspaces to have 1 row and 1 colum, hence having just the viewable screen real-estate for each workspace.
But, I don't particularly like that configuration. I want one big workspace with multiple rows/columns, so I can drag stuff to the side and it be on a different row/column of the same workspace. And I don't think KDE allows me to do this, hence I use GNOME.
Now, I know that is silly, but that is why I use GNOME over KDE as my primary desktop. However, I am impressed with KDE 2.x and I use Konq as my primary browser. So, if that could be squeezed into 2.2.1 or 3.0, I'd love it.
Re:Not quite clear what is missing... (Score:3, Insightful)
I want one huge workspace that can scroll. Not 4 individual workspaces - which is what KDE has.
I want to be able to drag an app to the corner of my screen and be able to go to the adjacent view and see the app.
Follow the steps listed in my post under gnome using the control panel, and you'll see what I mean. KDE doesn't have the colums/rows option for each workspace.
Re:some notes (Score:4, Insightful)
Packaging... (Score:3, Informative)
There is even a script in the kdesdk to package single apps. Aa long as the distributors don't do it, there is nothing KDE can do about it.
make 'find' for Konsole as it is in OpenStep (Score:2, Interesting)
What we at our company are almost YELLING about at some places ... we're all used to OpenSTEP and some of us are still using it just because of the Terminal.app. When you have some process or script that outputs tons of stuff, you just press Ctrl+F, you get a find panel, you enter your search keyword and it moves the terminal buffer to the right place and highlights what you've searched for. I think OS X has something simmiliar. :) Such feature greatly simplifies the daily job of the sysadmin.
If such functionallity would be added to KDE, there'll be no reasons for us to keep OpenStep anymore, expect for sentimentallity.
Re:make 'find' for Konsole as it is in OpenStep (Score:2)
Re:some notes (Score:2)
Sorry, I don't play that game. That's what they do in the closed source world. Always chasing after the latest software. Don't get me wrong, I will be using KDE 3.0. But I won't be doing any KDE development. I tired of chasing after Qt.
How many X11 programs written ten years ago compile perfectly fine today? How many Motif programs written ten years ago compile perfectly fine today? Will today's Qt-2.3.1 program compile with next year's Qt? Hah!
I like Qt. It's well organized and sensible. But this is going to be release 3.0. Not 0.3.0. You would think Trolltech would have the API hammered out by now. Give us a break and freeze the damn interface and let us catch up!
Re:some notes (Score:2)
Don't get me wrong, I don't think an API should be frozen in stone. But a lot of attention needs to be made to the existing source and binaries that were made for last months API.
Re:some notes (Score:2)
Re:some notes (Score:2)
Re:some notes (Score:2)
And so are total newbies who don't know anything about computers yet - feedback from those people can be vital. Most of us simply don't notice if something is not intuitive because it's what we're used to.
If you think you can't do anything that would be useful, please check out usability.kde.org [kde.org] and convince yourself of the opposite. We need the feedback...
Re:some notes (Score:2)
Twist some arms and get C++ apps to load faster. Konqueror takes 18 seconds or more, and I'm pretty sure most of it is accounted for by resolving function addresses for every object with virtual functions. It's not KDE's fault, but they may be able to either fix it or get someone else to.
Re:some notes (Score:2)
Re:some notes (Score:4, Redundant)
Fixed. Get the glibc, binutils and prelink packages from the current Red Hat Linux beta, and run prelink --all.
Work with the GNOME people (and vice versa) (Score:5, Insightful)
Users don't pick their apps based on toolkit. They pick them based on quality. For almost all users, that's going to be a mix of KDE and GNOME apps.
Create a standard for:
* Component models. Really. We know its hard to agree on, but it must be done.
* File types - > application mapping database (some people call these MIME types).
* Launcher menus. Application developers and end users are tired of having to add new apps Mozilla to two different sets of menus. Nobody says `I want a QT app...oh, and by the way, can it be a web browser'?. They say `I want a web browser'. They don't care about toolkits and neither should the desktop menus.
* Panel applets.
* Icons. GNOME uses 48 x 48. KDE uses various sizes (which is probably a better way to do it - 48 x 28 icons do notRe:some notes not look pretty). Have a kind word to the GNOME folk and suggest they use the same approach as KDE.
* Package deployment. I'd love to download KDE via Ximian's Red Carpet, or a KDE interface for the same.
Re:Work with the GNOME people (and vice versa) (Score:3, Informative)
For menus etc., we are using the desktop file standard (with the exception that gnome hasn't converted its translations to UTF8 yet) - with a sane setup, you can get an application into both menus at the same time (e.g. the
Re:Work with the GNOME people (and vice versa) (Score:2)
Yes I can. I still think its broken:
1. End users not have to need to do work to have menus that are logical (sorting apps by toolkit is illogical). All it takes is for distro packagers to have to use a symlink.
2. Users shouldn't have to maintain 2 redundant sets of the same information.
3. Packagers shouldn't have to put something into two menus, create 2 sets of icons, etc
It is bad anough to make it unusable. Try Ksysguard, Kmenuedit, or the kde file associations dialog box with the GNOME apps in your menus - the icons don't resize, so you've got a combination of 16 x 16 and 48 x 48 icons that makes the creen almost unreadable. KDE 2.2 new highlight-mouseover effect also seems to fail on some GNOME icons...
PS bero; Like your work. The new version of RPM required by KDE 2.2 requires a new version of Glibc that doesn't seem to exist in the non KDE packages on the mirrors.
Re:Work with the GNOME people (and vice versa) (Score:2)
That's not how it works. Anything in
2. Users shouldn't have to maintain 2 redundant sets of the same information.
3. Packagers shouldn't have to put something into two menus, create 2 sets of icons, etc
See (1) - they don't. Put it in
Re:Work with the GNOME people (and vice versa) (Score:2)
Its great this directory exists - why then doesn't Red Hat use it more? Every release up to the 7.2 beta is still sticking GNOME programs in their own seperate submenu within KDE.
Re:Work with the GNOME people (and vice versa) (Score:4, Informative)
There is activity going on on their mailing list [redhat.com]. E.g. right now they're coining up a standard for storing image thumbnails so Nautilus, Konqueror and the GIMP will be able to share them.
Re:some notes (Score:5, Informative)
I would dearly love to roll out KDE as the Unix desktop at work - works great on Intel platforms (with > 64MB RAM to avoid "excessive" swapping to disk) but ran into some problems when trying to get it working under Solaris. I haven't tried 2.2 yet - hopefully this fixes some of these issues.
What I would like to see changed are its resource requirements. Slim it down! We're considering replacing our current X-terminals (some old Labtams, Tektronix and NCD boxes) with diskless PCs running Linux - disks are not an option. If KDE can run on a diskless machine with 128MB RAM (with an NFS-mounted
Increase scalability. Apart from RAM, KDE spawns a bunch of processes. On a workstation this isn't a problem, but scale it up to a several hundred users on a large box and things can get a bit ugly. (Haven't pushed it this far - extrapolating for a handful of trial users.) Do you really need so many kdeinit jobs?
I love KDE; my boss likes it. Now if I could just get it to work as well as the users expect things to work...
Re:some notes (Score:2)
A diskless X terminal runs only the X server. It is irrelevant what window manager and apps you are using -- the system requirements would still be the same. (All the apps, including the window manager run on the app server). So, even 32 MB would do. The only thing you need to ensure is that the client and network are able to handle the resolution and color depth you want to use. Obviously the higher the resolution and color depth the more bandwidth and client resourses it will take, but still at 1280x1024x16 bit color a low-end pentium with 32 MB RAM and 100MB/s network would do just fine.
Increase scalability. Apart from RAM, KDE spawns a bunch of processes. On a workstation this isn't a problem, but scale it up to a several hundred users on a large box and things can get a bit ugly. (Haven't pushed it this far - extrapolating for a handful of trial users.) Do you really need so many kdeinit jobs?
Apparently you are not aware of shared memory. If two users run the same app, they will not use twice the memory. The program text is shared among all instances, only data is private. In fact using a one big box shared amoung a number of clients is a lot more efficient than lots of less-powerful workstations both in terms of memory and CPU utilization: 90% of the time a workstation is idle (a secretary types a document; a developer types code, etc.) and 10% of the time it is too slow for a given task (start word processor; compile program, etc.)
As for the kdeinit processes they each run a different thing. They are not copies of the same process. The explanation I heard is that kdeinit is used as a wrapper because Linux's ld works slow for C++ apps. (Somebody in the know, please post a more detailed expanation about it.)
Re:some notes (Score:2)
In the traditional model, yes; this is what our prototype is doing. However, given that the that the *minimum* system readily available these days is a Duron 850MHz with 128MB stick of SDRAM, it seems rather wasteful not to put this to good use. NCD provides Netscape and ICA on some of their xterms, and we've tried this successful on the Linux-based "xterm" too. Moving the window manager to the terminal is the logical next step, but admitted more of a giant leap...
Ignoring the technical issues of running the window manager locally, the more stuff added to the boot image, the longer the boxes take to boot. While this shouldn't be an issue, users who have been exposed to Windows will reboot the terminals with Ctrl-Alt-Del at the merest hint of a problem...
More likely, we'll harvest the spare CPU cycles after hours - imagine a Beowulf cluster of Duron-based xterms...
Apparently you are not aware of shared memory.
Actually I am aware of shared memory, which is why I built everything with shared libraries to minimize the memory usage. There were some memory savings using shared libraries, but the actual memory usage of the limited trial indicated that we would have trouble with a full user load.
Re:some notes (Score:2, Informative)
if you have your KDE clock set to blink and show seconds etc, that kind of bandwidth will chew up your LAN in no time.
and as soon as you start web browsing you can kiss your LAN good bye if you have lots of clients on the same LAN.
Bloat (Score:2, Insightful)
Re:Bloat (Score:3, Informative)
And yes, most of kde does not use RTTI, STL, and exceptions (Qt uses RTTI afaik, but it's not as big of a bloat maker as exceptions are).
Also, about, execution speed, c++ is only barely slower than c. HOWEVER, g++ compiled c++ programs with lots of shared libs take forever to be loaded. This seems to be bugs in g++ that the team is fixing. The same prelinking time does not occur in other compilers (visual c++ comes to mind).
There are several approaches that the kde project has compensated for this. First was kdeinit. Kdeinit linked the majority of kde and qt shared libs and then loaded the app, resulting in less memory usage. Now, with 2.2, there is a objprelink. This reduces time of loading of many kde apps from 30% to 50%.
In the future, g++ will probably be fixed. Meanwhile, there will be other prelinking solutions (some have already been announced)
Re:Bloat (Score:2, Insightful)
> C++ lets the programmer go lazy on many things
> at the expense of bloat and execution speed.
Such as?
> Even "Hello world" examples are much larger in
> size than C equivalents.
The following *C++* program compiles to a 3368 byte dynamic binary on my Linux box:
#include
int main() { printf("Hello, world!\n"): }
Oh whats this? You say thats not a C++ program but a C program? Hate to break it to you, but (with a few exceptions) any valid ANSI C program is also a valid ANSI C++ program.
- Arcadio
Re:Bloat (Score:2)
enum myEnum {ONE, TWO, THREE};
myEnum e = 2;
This is invalid in C++, because of C++'s type checking. Casting would correct the problem.
struct myStruct {
typedef char myStruct;
because in order to create an instance of myStruct, you must prefix it with struct, which distinguishes it from the "char" myStruct. You can't do this in C++, because you don't need to prefix myStruct with struct to use it.
J
Re:some notes (Score:2)
Not to mention this /. thread [slashdot.org]. Unfortunately from the open-source perspective, they're using these Linux terminals primarily to run commercial software packages [slashdot.org]: WordPerfect, Excel, PowerPoint, and Access.
Tim
Re:some notes (Score:1)
Cookbook is currently in KDE CVS, in the kdenonbeta module. I've got some older versions and screenshots up at http://www.mcs.kent.edu/~dwatson/cookbook.html, but the webserver has been screwy, so it may or may not work.
If you want to latest version, you can get it from CVS. It should be fairly stable, despite the fact that I'm madly adding new features to make it more like what I want
You'll need KDE2.2 for it to work properly, though, because I use KDEPrint. Or you could just hack the makefiles and remove the #define QPrinter KPrinter
Re:tear away menus (Score:2)
This option is available long time ago - enabled as default for example in the K menu..
Re:tear away menus (Score:2)
Rich.
Re:some notes - Fix the Fonts please (Score:2)
Re:some notes - Fix the Fonts please (Score:2)
And no, not once was it faulty hardware to blame.
p.s. next time you troll, you need to be more subtle.
Re:GO AWAY M$ MUNCHKIN (Score:2)
Re:some notes - Fix the Fonts please (Score:2)
Rich.
Re:some notes (Score:2)
Re:some notes (Score:2)
Re:Backwards compatibility (Score:3, Interesting)
Most of KDE will stay the same, and QT is around 90% source compatible (not binary compatible)..
So basically - moving an application from KDE 2 to KDE 3 shouldn't take more then a few tweaks.
Lars from TrollTech has been playing for fun in ported the entire KDE libraries from QT 2.X to 3.0 beta in a few hours - so if few hours takes to move something this big - then it shouldn't take for an avrage programmer more then an hour or so..
You should also remember - by the time that KDE 3.0 will be out - most of the distributions will move from GCC 2.9X to 3.0.X or 3.1 (if everything goes according to the GCC team) - so the developers will have to do some work - regardless of KDE or Gnome applications...
KHTML & IE compatibility. Bah! (Score:2)
* KHTML: extended compatibility with IE's parsing and tokenisation fallbacks for really malformed HTML.
This really disappoints me. A web browser needs to follow the spec [w3.org] and do exactly what the web author says, not necessarily what the web author thought he/she said. One reason for this is interoperability: web authors never know which browser people will be using to view their site. For instance, in a few years, many people could be web browsing from their cell phones using "Nokia Integrated Browser" or something. So, web authors must get the idea that the only long term solution is to write valid code -- and having web browsers that "guess" at what the web author "intended" to write in their code doesn't reinforce that.
Re:KHTML & IE compatibility. Bah! (Score:5, Insightful)
Seriously though, your hardline standards-compliance stance is an idea whose time has either passed or whose time is not yet come. Some facts:
Screen Shots (Score:2)
Re:Screen Shots (Score:3, Informative)
Re:It broke RH71 (Score:2)
You need to install the stuff from the non-kde directory. It contains libraries that are needed by KDE (but not part of KDE).
Missing X libraries and RH7.0 (Score:2)
I've got similar problems. I've got a RH7.0 box, and when I try to install KDE, it starts complaining about needing libXft, and libXrender. Of course, there is no mention of either in the README (such as what version of XF86 is required), nor is there a version of X in the non-kde directory. This is also ignoring the collisions on libcrypto, libssl, python, liblber, libldap, librpm and librpmio. Just a little frustrating.
Luckily, I haven't done a --nodeps like the README suggests.
So, anyone know what the magic versions are?
It has been taken care of (Score:3, Informative)
The new kde2.1 and the new gnu-bintools and glibc (not the recent gcc 3.0 compiler) fix the error. According to the press release you can expect %30-%50 improvment on load times because the excess object swaping and loading has been taken care of.
Re:It has been taken care of (Score:2)
Re:Developpers and speed (Score:2)
>>>>>>>>
BeOS was developed on 66MHz PPCs with 16MB of RAM and it shows. The damn thing runs like hell on mediocre machines, and even faster on faster ones.
It would be nice if they all had a small machine like you described on their network so that they could INSTALL their rapidly developped applications for TESTING. That might lead to some optimizations being done that don't happen now.
>>>>>>>>
Its not just optimizations. Its the whole mindset that features are more important than basic usability.
OTOH maybe it would be better if the KDE project started suggesting 400mhz and 256RAM as a minimum for a useable "desktop workstation", and saved time by *not* optimizing the code for old machines. It's an engineering question worthy of debate.
>>>>>>>>
That's ridiculous! And Linux people claim that Win2K is bloated! An OS (and by extension, a GUI environment) is just a helper. A lowly piece of code that has no other reason for existance than the fact that it is sometimes useful to the application. Nobody wants to run KDE-2, they want to run their apps. The OS code should just get the hell out of the way and leave all the processor they can do the application. I don't mind my 3D renderer sucking up resources like anything. Hell, I'm getting a dual Athlon soon just so I can feed it more. But moving windows around on my desktop is a means to an end, not an end in itself. Thus, it deserves very little of my processor time, whether my machine is a dual 1.2GHz monster, or a wimpy 300Mhz weakling.
Re:Developpers and speed (Score:2)
It was also far from what it is today, no journalling filesytem, very crude "Media Kit", very little drivers, horrible VM (still does), etc. etc..
I went back to PR2 on my BeBox, since the latest release (R5) is about 50% slower for most things. Of course driver/application support on PPC is even more pathetic than x86 (imagine that) so it really doesn't matter. The once glorious and ultra-hip BeBox is now a SSH terminal box
Yes it even needs it's own HUB since no 100Mbit network card works in it...not that the network kit would benefit from it.
-adnans
Re:No Solaris 8 binaries !!! (Score:2)
Re:RedHat 7.2 (Score:2)
Re:Does it run with Mac OS X? (Score:2)
yeah, the would be Gnome you where thinking of (as compiled under the FINK [sourceforge.net] project). and of course you need to run it under XFree, it doesn't run directly under Quartz/Aqua. but FINK has been moving along pretty well, so KDA may not be that far away...
sean
Re:KDE vs Gnome (Score:2, Informative)
Re:Compiling 2.1 now, worth the upgrade? (Score:3, Informative)
The release notes [kde.org] are worth reading over.
...j
(jackass has been cancelled [free2air.org]. eep!)
Re:too bad the red hat RPM's suck (Score:2)
Re:I've tried KDE 2.2, it's so good (Score:3, Funny)
Re:Sharing user's home directories (Score:2)
It should really be possible to share this home directory not just between Mandrake/RH but older versions and other different versions too. I mean, how difficult could it be to just make the config directories configurable? (e.g.
The problem is this applies to many programs
I ended up doing some really hacky stuff with a number of symbolic links into a "shared" spare partition. OK, I could never do that with Windows at all, but its still far from ideal.
Re:Sharing user's home directories (Score:2)
KDEHOME without space.
Re:Sharing user's home directories (Score:2)
Re:and... (Score:3, Informative)
2.2 works great on FreeBSD, the only problem I've found so far is that SSL is completely shot. So you'll have to do without https for a while in Konqueror. Too bad.
Re:Where are the themes gone ? (Score:2)
You can make KDE look pretty awesome (IMHO) using the styles etc. provided in the release though.
Rich.