Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

KDE 2.2 Released 334

Posted by Hemos from the come-and-get-it dept.
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!
This discussion has been archived. No new comments can be posted.

KDE 2.2 Released More

KDE 2.2 Released

Comments Filter:

  • Improvements... (Score:4, Insightful)

    by chill ( 34294 ) on Wednesday August 15, 2001 @10:15AM (#2110596) Journal
    Now that I've installed it and played for a hour...

    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 .kde files in their home before it would use KDM instead of WDM. I like the Preferences Wizard.

    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.
    • Was KDESUPPORT not upgraded?

      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.

    • 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).

      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)

      by bero-rh ( 98815 ) <bero AT redhat DOT com> on Wednesday August 15, 2001 @12:25PM (#2136218) Homepage
      1) kdesupport is gone. It was a collection of libraries that are used by KDE, but not part of KDE.
      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.
  • It is possible to use icon themes in KDE, but the online manual for creating them is no longer online :-(
    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)

    by pdiaz ( 262591 ) on Wednesday August 15, 2001 @09:13AM (#2111136)
    Europe:
    ftp://gd.tuwien.ac.at/hci/kde
    ftp://sunsite.cnlab-switch.ch/mirror/kde
    ftp://sunsite.mff.cuni.cz/MIRRORS/ftp.kde.org/pu b/ kde/
    ftp://ftp.rz.uni-wuerzburg.de/pub/unix/kde
    ftp://sunsite.informatik.rwth-aachen.de/pub/Linu x/ kde
    ftp://sunsite.auc.dk/pub/X/kde
    ftp://ftp.dataplus.se/pub/linux/kde
    ftp://ftp.dit.upm.es/linux/mirrors/ftp.kde.org/p ub /kde

    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)

    by kdgarris ( 91435 ) on Wednesday August 15, 2001 @10:00AM (#2119229) Journal

    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
    • Yeah,

      I installed it on a build of KDE from last friday at home and to say the least I was stunned. ;-) KDE has never looked quite so good. I would love to see this rolled into the main CVS.

      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)

    by qlippoth ( 446729 )
    KDE 2.2(Final) Debs are available in the unstable tree. If you normally run the stable tree, you may want to switch over to unstable, install just the needed kde packages, then switch back. deb http://http.us.debian.org/debian unstable main contrib non-free

  • Oh Boy! (Score:2, Funny)

    by Anonymous Coward
    I am pleased to announce that since my porn came in 78% clearer now that I'm using KDE 2.2 (automatic antialiasing all da way!), I got off in 2 seconds instead of 3. Thank you. You've made my day the best ever, and also made my keyboard a gooey mess.

    • 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)

    by cybrthng ( 22291 ) on Wednesday August 15, 2001 @08:38AM (#2132358) Homepage Journal
    KDE 2.2 is a huge leap in usability for KDE. I personally can't wait for 2.2.1 as they may include a prelinker for compiling that optimizes the loadtimes on the applications. It shouldn't take the amount of time it currently takes to load, but it is usable.

    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!

    • 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 :)

      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?

      • KDE3 will be almost a direct port of KDE2 to QT3. In the process they're going to clean up the problems in their APIs that they've uncovered since releasing KDE2, thus breaking compatibility with most KDE2 apps.
    • Good point. How does it handle antialiasing of fonts?

    • Re:Been running it for a week now, great release. (Score:5, Informative)

      by 10Ghz ( 453478 ) on Wednesday August 15, 2001 @09:05AM (#2143469)
      i just hope they learn to quit breaking binary compatibility with each major release :)

      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

    • I personally can't wait for 2.2.1 as they may include a prelinker for compiling that optimizes the loadtimes on the applications.

      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

  • Superb (Score:3, Informative)

    by rleyton ( 14248 ) on Wednesday August 15, 2001 @08:21AM (#2133092) Homepage
    I was all ready on Monday to get my SuSE install of KDE upgraded, but disappointed when it didn't appear. Tuesday's announcement of hardware problems (don't they always hit you when you least expect it), meant a bit of rummaging about (and ftp.suse.com dropped my connections frequently), but thankfully SuSE RPM's were available on ftp.mirror.ac.uk - So I've been running it for a couple of days now.

    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!

  • KDE and Ximian Gnome Can't Get Along? (Score:5, Interesting)

    by idonotexist ( 450877 ) on Wednesday August 15, 2001 @02:33PM (#2133442)
    Apt-getting kde, noticed kde removes gdm. I thought --- well, I'll install kde 2.2 and then reinstall gdm. After installing kde, apparently an install of gdm is not possible without removing kdm and kde.

    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?

  • Here's what I'd like to see (Score:3, Interesting)

    by dmelomed ( 148666 ) on Wednesday August 15, 2001 @12:20PM (#2133655)
    Less bloat. More optimizations. You shouldn't neet lots of resources to move windows around and copy and paste. 1.x release was actually bearable on a 64 or 128 MB machine, can't say the same about the new release. I know this is asking for impossible, but maybe people who moderated my previous post a troll can prove me wrong, and have a large C++ project have a memory foot print/resource usage that these kinds of binaries could have (C instead).
  • This looks to be a pretty solid release.

    Perhaps linux on the desktop isn't dead [slashdot.org] yet, dispite what Microsoft and others keep insisting...?

  • problems... (Score:3, Insightful)

    by Anonymous Coward on Wednesday August 15, 2001 @09:14AM (#2138652)
    one thing that drives me nuts about linux is that there are all these different desktops with all these competing standards. there's no one API for instance to add an icon to the desktop or a program group, because each one of these systems does everything totally differently.

    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)

    by joshv ( 13017 ) on Wednesday August 15, 2001 @08:32AM (#2140206)
    Such a major project with an emphasis on usability and user friendliness and the package has no installer. Sure different distros can wrap it up in whatever package manager they use, but this is still a pain. Why can't they have something like mozilla's binary installer so end users (who may not know their distro) can download it and just go.

    -josh
    • I agree. A lot of KDE upgrades I avoid simply because I'm afraid of the incompatibilities it can cause with my current distro (in this case, RedHat 7.1). I normally wait for a Linux company to place the new interface into their distro, then download that instead.

  • some notes (Score:5, Informative)

    by HeUnique ( 187 ) <hetz-home AT cobol2java DOT com> on Wednesday August 15, 2001 @08:29AM (#2140970) Homepage
    Hi people,

    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)

      by kdgarris ( 91435 ) on Wednesday August 15, 2001 @09:37AM (#2110272) Journal
      Konqueror already has the ability to allow or not allow Javascript on a per-site basis,a nd also has an option to disable the Javascript window.open function globally, but what I'd really like to see is the ability to disable window.open on a site-specific basis as well.

      Popup windows are annoying on some (okay, most) sites, but a few require them in order to make use of the site.

      -Karl
      • yeah, I'd kill for that functionality too! I'm thinking this could be scaled up to a per-site profiling system where the useragent, javascript and other options are all defined for each site. That way it could be more easily extended to handle other often abused features that are so handy to turn off (javascript alert() calls, Flash, etc)

      • Re:Site-specific popup policy (Score:5, Insightful)

        by Drone-X ( 148724 ) on Wednesday August 15, 2001 @12:29PM (#2139632)
        but what I'd really like to see is the ability to disable window.open on a site-specific basis as well.
        Or even better, ignore window.open being used when loading or unloading a page but allow it when I click a link. Now that would effectively stop banners without having to keep going to the configuration dialog.
        • Great job. Now we'll have banners that only pop up once you click a link. You've ruined everything.

          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.
    • Disclaimer: I use both KDE and GNOME at the house. I have several computers, and I have my computer-illiterate girlfriend using KDE 2.1 with little problem.

      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:some notes (Score:4, Insightful)

      by rleyton ( 14248 ) on Wednesday August 15, 2001 @08:34AM (#2125507) Homepage
      A small gripe - but what I'd most like to see is some breakout of the individual apps into seperate packages. As my post above [slashdot.org] states, I love kmail - but I do wish I could keep up with stable(ish) development releases of that, without having to download the entire kdenetwork module.

      • is done by the distributors. Debian for example splits the kdenetwork in the different applications.(AFAIK)

        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.
    • I think 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...

      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.
      If such functionallity would be added to KDE, there'll be no reasons for us to keep OpenStep anymore, expect for sentimentallity. :) Such feature greatly simplifies the daily job of the sysadmin.

    • SO people who want to either developer QT or KDE applications might want to download QT 3 snapshot and play with it.

      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!
    • 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..

      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...
    • I thin[k] 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?

      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.

    • Work with the GNOME people (and vice versa) (Score:5, Insightful)

      by Nailer ( 69468 ) on Wednesday August 15, 2001 @10:13AM (#2141944)
      My suggestion: work closer with GNOME (and vice versa. Its entirely possib;le to have 2 seperate projects without the current incompatibility and lack of standards between the two.

      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.
      • A good idea in theory - but in practice, this can be quite hard. For example, for panel applets, both desktops drag along large libraries - and while it is possible to display GTK widgets in Qt applications [knome.org], you don't want the memory requirements that introduces.

        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 /etc/X11/applnk menu on Red Hat Linux), so it's not quite as bad as you make it sound.
        • with a sane setup, you can get an application into both menus at the same time (e.g. the /etc/X11/applnk menu on Red Hat Linux)

          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.
          • 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.

            That's not how it works. Anything in /etc/X11/applnk is merged directly into both the KDE ang GNOME menus, without introducing a new top level entry.

            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 /etc/X11/applnk and it's ok
            • Oops, thought you meant /usr/share/applnk (what KDE uses). /me gets educated :)

              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:some notes (Score:5, Informative)

      by ozbird ( 127571 ) on Wednesday August 15, 2001 @09:22AM (#2157769)
      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...

      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 /home directory) - this would be a real winner.

      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...
      • If KDE can run on a diskless machine with 128MB RAM (with an NFS-mounted /home directory) - this would be a real winner.

        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.)

        • A diskless X terminal runs only the X server.

          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)

        by Matthew Luckie ( 173043 )
        and you might want to look at X protocol compression as well, such as LBX or any of the alternatives listed at the bottom of this [linuxdoc.org] page.

        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)

        by dmelomed ( 148666 )
        Don't take this as a flame, but I don't think it's easy to slim down a project like this. It's OO, it's C++, what can be expected? C++ is a higher level language, resulting in slow compilation times and bloat. The gain is shorter developement cycle at the expense of bloat. Same goes for Mozilla.
  • From the changelog [kde.org]:

    * 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)

      by A coward on a mouse ( 238331 ) on Wednesday August 15, 2001 @04:27PM (#2142264)
      You're absolutely right. And if, by adhering to a standard not adhered to by the browser used by the rest of the world, 90% of pages look like shit in Linux, well, fsck 'em, we didn't want to look at those pages. And if nobody uses Linux because 90% of all web pages look like sh*t, well, fsck them too, we don't want those kind of people using Linux. I'm sure that everyone will feel so bad that the colicky Linux users aren't participating that the world will change.

      Seriously though, your hardline standards-compliance stance is an idea whose time has either passed or whose time is not yet come. Some facts:
      1. The defacto standard *is* IE. If you don't believe this, you are in denial.
      2. The vast majority of web authors are not interested in finding a "long term solution". Not only is finding long term solutions difficult, but doing so harms the web author's job security and besides, most clients expect a complete re-work of their site every once in a while, to keep it fresh.
      3. As a result of the above, most of the web is optimized for IE.
      4. Approximately 0% of average users give a good goddamn whether the web page they are viewing is standards compliant.
      5. Approximately 100% of average users don't care if the browser uses black magic to render the pages as long as the pages be readable.
      If Linux wants to attract users, Linux will need a browser that can render the millions of pages already written for IE somewhere near as well as IE can render them. On the other hand, if Linux is hoping to go down in history as a highly standards-compliant system that was too good for this world, then your way is the right choice.
  • Hey..what about some screen shots, but first I must read the changelog ummmm.

Slashdot Top Deals

"If it ain't broke, don't fix it." - Bert Lantz

Close