Re: Why the DOS has many ntfs read and write driver,but the linux can't for a long time

From: Yaroslav Rastrigin
Date: Mon Jan 09 2006 - 08:55:46 EST


Hi, Kasper,
> > without worrying about my on-the-road availability.
> > Suspend to disk has nasty tendency to ruin my whole hot live X session, since X can't properly restore VT on resume.
> > Overall performance isn't that bad, either, but I just can't understand, why KATE (Kde more or less advanced editor) takes twice as long to start
> > as UltraEdit in _emulated_ (VMWare) Windows XP running on this same box.
> i can not take this seriously.. on both my laptop and workstation, the
> kate window is up in less than a second after i either run kate from a
> terminal, or select it in the kde menu..
Well, I could find more or less reasonable explanation of this behaviour - different VM policies of two OSes and
strangely strong and persistent belief "Free RAM is a wasted RAM" among kernel devs. Free RAM is not a wasted RAM, its a memory waiting to be used !
Whenever it is needed by apps I'm launching or working with.
>
> unless ofcourse you are not using kde, and kate is the first kde
> application you start, then it will need to load much more than simply
> kate, at which point you cant really say what you are doing, since it
> would be somewhat like comparing half of windows's startup time +
> ultraedit startup time to kate startup time...
No. Fully loaded KDE session (without kdesktop and kwin, since I don't use first and using my own WM instead of second).
So almost all necessary libraries are hot and loaded, and all what's missing is a dozen of Window's and Pixmap's to allocate and two threads to
handle events. And it takes seconds, not tens of a second, as in UltraEdit case
>
> >
> > So, the question remains the same - whom and how much I need to pay to solve abovementioned problems ?
> >
>
>

--
Managing your Territory since the dawn of times ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/