The latest KC KDE, number 25, is out. Aaron J. Seigo sums up some exciting news about KMail integration with the German-government-funded Aegypten security project, a revamp of the KConfig network, a discussion about registering KDE mime types with the IANA, and a lot more regarding the dawning KDE 3 beta release. Get it while it's hot.
Dot Categories:
Comments
the printing wizard image seems to be offline - can someone help?
Click on the second link, the first one is to a non-existant jpeg.
Click on the second link, the first one is to a non-existant jpeg.
No, GeoCities is playing tricks on you. Try to copy the link and paste it in the location bar, press enter, and you should be able to see the images.
where's 2.2.2?
The release schedule at
http://developer.kde.org/development-versions/kde-2.2.2-release-plan.html
is claiming monday (november 19) for the release date. Any of you develheads want to verify?
The packages were sent to the packagers earlier this week. So in reality KDE 2.2.2 is done, but we have to wait for the hard working packaging people to create distribution specific releases.
OT: My dream scenario for the future is that one LSB package is created, which would work with all the major distributions that are LSB compliant. Maybe someone could create an "LSB release" of KDE 2.2.2 just to set an example?
Aren't the tarballs LSB enough?
What is the benefit of more LSB compliance? I want ( and I will get ) an i586 ( or AMD-specialized? ) binary ( I definitly need this 0.2% speed gain :-) ). No LSB can give me that.
Congrats on the 25:th KC KDE. This one, I have to say, was the most interesting and nicely crafted yet. I'm a notorious mailing list reader, still I've managed to miss some of the juicy stuff presented in this KC. Good job.
As I posted on nov 9, "Let's Make KDE the Best Desktop Environment",
please see:
http://dot.kde.org/1005265771/1005440042/
And the HTML file is at:
http://sanskrit.gde.to/hindi/dict/eng-hin.html
Now while doing weird and stupid things in KDE, I downloaded this 3.9mb html file which is a English-to-Hindi Dictionary, GPLed,. Here is the performance Test of various Web Browsers which passed to display this HTML file correctly:
1. MS IE 5.5: Quickly Rendered the page, but became sluggish. Just passed.
2. Opera 5: (on Linux and Windows 2k): Quickly Rendered the page but with Garbage: Failed badly. but no sign of sluggishness.
3. Lynx: Super fast rendering of the page. Exceptional for a text browser.
4. Mozilla 0.7: started to show but never completed to render the page, instead it get response less. Failed. became unstable
5. Konqueror: Our favourite konqueror browser, not just became un-responsive, but also made KDE to slow down to an extent that you can't work!!! HopeLessly failed!!! not just it became unstable it even destabilized KDE :(
6. Netscape 4.77: The next faster browser after Lynx to display the page, and not even let the user feel that the file is such huge. This is the Winner!!!
Personally I love Konqueror, but the fact is Opera 5, Mozilla 0.7, and Konqueror 2.2 are not yet there to be considered serious Web Browsers. I wish and hope that Konqueror will surpass Netscape. Konqueror should compete with Netscape instead of Mozilla or any other 2nd grade browsers like ie. I feel that Konqueror failed because of Mozilla's engine being used to render the html pages.
Even I opened that 3.9mb html file with KEdit, though first it became sluggish it is loaded, but it was fine.
Oh Specifications:
Windows 2000,
RedHat Linux,
KDE 2.2,
Celeron 400,
128mb SDRAM,
keyboard, mouse and monitor with a modem ;)
Err...I think you're being a little unfair one Mozilla there. Mozilla 0.7 is ancient, 0.9.6 is due out tomorrow. I've got the page loading on a nightly build right now and it seems to be coping fine, it becomes sluggish while rendering the page, but once it's fully downloaded, it's perfectly fine.
Why are you using such an old version of Mozilla?
I have tested with what I got at my disposition. I am happy with Konqueror, I don't use other browsers. But when Konqueror crashed, then I tried to find out is it all the same with other browsers? but I found that Netscape was good. Even this result won't make me use Netscape, since I love Konqueror's look & feel.
Files like this one should be outlawed anyway :-) No, seriously, have those people ever heard of splitting things like this?
Files like this one should be outlawed anyway :-) No, seriously, have those people ever heard of splitting things like this?
Use the latest konq from debian/sid, a pIII733 and 512MB ram, it loaded fine. It slows down a little bit while scrolling down, but quickly picks up. I was even able to scroll around easily while it was still d/ling. It definetly wasn't a big deal. Granted, I have much more ram and processing power than you do, but I'm not "top of the line", or even close (less than 1/2 the speed of the top AMD and intel procs).
Having said that, of course there are always performance tweaks that can be added. And I can garuntee that the devs are doing as good a job as they can while still maintaining the maintainability and correctness.
PII/400 256MB RAM, Konqueror 2.2.2-ish. rendered just fine, scrolling was fine, the rest of the desktop remained responsive.
perhaps he was hitting swap?
Yes, KDE+Konqueror are not satisfied with 128mb ram :(, this proves that Netscape is efficient and konqueror is a memory hog! I wonder how 128mb is not enough/sufficient for konqueror to display a 3.9mb file, whereas netscape 4.77 just do it fine???
I hope KDE won't expect us to be like Microsoft users, get the speedest processor and tons of ram!!! BTW, I tested that on Win2k too! I upgraded 128mb from 64mb just for KDE! Now KDE is asking for more :(
I tried loading the page in question in a KDE 3 konq window on my KDE 2.2 desktop. Both are built from CVS and I'm running an Athlon Thunderbird 950 with 512 MB RAM. I have a DSL connection but this page loaded slow... about 13 KB/sec and then stalled. Even at 49% loaded it scrolled okay with just minor glitches. I expect it would have behaved better once fully loaded as they always do. I have 12 desktops and had kmail, multiple konqs, kdevelop, cervisia, Quanta and other apps open... no slow down.
> I hope KDE won't expect us to be like Microsoft users, get the speedest processor and tons of ram!!! BTW, I tested that on Win2k too! I upgraded 128mb from 64mb just for KDE! Now KDE is asking for more :(
KDE 3 appears to be more memory efficient. A recent build had web pages loading at incredible speed too but the build from a few days ago got really slow for some reason. I believe you will function better in low resource environments with KDE 3...
However... anyone who's time is worth anything and is running into swap files might want to consider adjusting priorities. I remember years back spending $700 for 4 4 MB SIMS. Prices have fallen... a few years back I spent $140 each for two 128 MB DIMMS. I can now buy them for $13! I can get a 256 for $24 and a 512 for 49. Unless you are in a less privleged area of the world (my heartfelt wish that hardare fell from the sky for you) I think that $13 to $24 to stop swimming in the syrup of swap files is well worth it. RAM will speed up under powered systems before processors. I have an Athlon 700 system that does not recognize more than 64 MB until you set it in lilo. Until I noticed the low system resources a K6 500 Mhz machine with 128 MB was running circles around it.
Word to the wise... RAM is cheap and swap is misery.
I tried loading the page in question in a KDE 3 konq window on my KDE 2.2 desktop. Both are built from CVS and I'm running an Athlon Thunderbird 950 with 512 MB RAM. I have a DSL connection but this page loaded slow... about 13 KB/sec and then stalled. Even at 49% loaded it scrolled okay with just minor glitches. I expect it would have behaved better once fully loaded as they always do. I have 12 desktops and had kmail, multiple konqs, kdevelop, cervisia, Quanta and other apps open... no slow down.
> I hope KDE won't expect us to be like Microsoft users, get the speedest processor and tons of ram!!! BTW, I tested that on Win2k too! I upgraded 128mb from 64mb just for KDE! Now KDE is asking for more :(
KDE 3 appears to be more memory efficient. A recent build had web pages loading at incredible speed too but the build from a few days ago got really slow for some reason. I believe you will function better in low resource environments with KDE 3...
However... anyone who's time is worth anything and is running into swap files might want to consider adjusting priorities. I remember years back spending $700 for 4 4 MB SIMS. Prices have fallen... a few years back I spent $140 each for two 128 MB DIMMS. I can now buy them for $13! I can get a 256 for $24 and a 512 for 49. Unless you are in a less privleged area of the world (my heartfelt wish that hardare fell from the sky for you) I think that $13 to $24 to stop swimming in the syrup of swap files is well worth it. RAM will speed up under powered systems before processors. I have an Athlon 700 system that does not recognize more than 64 MB until you set it in lilo. Until I noticed the low system resources a K6 500 Mhz machine with 128 MB was running circles around it.
Word to the wise... RAM is cheap and swap is misery.
OK, Here's another trial, by a person with 128 MB. Konqueror started loading the page, and was responsive at first. But as the page kept loading, it started sucking up more and more memory. Eventually it started pushing everything else out into swap. But there were only a few megabytes of other things that could be swapped out. Apparently Konqueror was actively using all of the ~95 MB of memory that it had gobbled, so none of it could be swapped out either (even when I wasn't using that window). So the end result was that my computer was thrashing the disk 100% of the time, just sitting there, moving things back and forth between disk and RAM as fast as it could. This resulted in absolutely the worst disk thrashing I have ever seen. So apparently the problem is that Konqueror takes too much memory storing webpages after rendering them, and it doesn't let any of that memory swap out if it isn't being used.
I tried this page both in Konqueror and Galeon.
In konq the speed was acceptable, I downloaded the file in 50 kb/s and was able to scroll the page all the time, with just a little slowdown in scrolling... But when the page was done and I hit the back button konq crashed. The rest of system never got affected though.
In Galeon it was VERY fast and responsive all way through and showed no signs of instability. It also needed less ram to render the page.
Spec:
PII 300, 160 mb ram, ATA33
Debian sid, 2.4.15-pre1-preempt, KDE 2.2.1, Galeon 0.12.7/Mozilla 0.9.5
that's because galeon is essentially a stripped down version of mozilla.
I'm sure if you tried embedded-konqueror or netraider on it, it'd load faster/use less ram than galeon, because khtml is a LOT lighter than gecko is. that's why the nautilus folks are going to use gtkhtml2 more (a port of khtml), instead of gecko.
You're sure? Dude, try it, and Konq ain't that good. This is a definate problem in Konq.
You're sure? Dude, try it, and Konq ain't that good. This is a definate problem in Konq.
I did. It works. Maybe your Konq is borked.
Years later, and I hate to bring these old things back to life, but if you take
a gander with Netscape 7.1, after AOL got ahold of it, it is now the slowest
browser on the market.
KDE is thrashing for some reason, currently, but it is related to user and X times.
kdeinit keeps popping in and out, but there is something wrong in all of the browsers and gui's.
Somewhere, along the line, someone forgot that machine code executes the fastest of all. There is far too much "scripting" in all current programming, and far too much Microsoft influenced bad programming practices.
A screen takes maybe 3 meg, same as a television, bits [changes from one to zero or zero to one]. Useless extended bits, rastering, colorization in 3 gig colors [which is not possible, but it looks nice for salesmen trying to sell you an accelerator card], and the rest of the garbage put into television [because that is what a monitor is, like it or not] are killing displays.
gui should be handled by machine code only.
It should have sufficient areas to readily update the screen at the speed of the memory bus. About 3 meg for each screen. A microfunction is called to refresh the screen not by transferring data, dummies, but by changing the point to the screen area! This results, dummies, in a once clock screen refresh!
Gee, I wrote a machine code segment to do this 20 years ago! I had a Commodore refreshing the screen so fast you could not perceive the change [less than one microsecond - things like ALT+TAB should have no problem doing this, but remember to put a waitlock on the key combo so the screens don't switch at a millions choices per second].
For future reference, KDE, change the pointer! Not transfer the whole screen!
When will they ever learn programming.
Pointers were invented to fix bad programming habits.