| |||||||||||||
NIHNIHPosted Apr 26, 2007 8:24 UTC (Thu) by zdzichu (subscriber, #17118)Parent article: This week in the scheduling discussion
In all those technical discussions lack one (obvious?) observation. There are many unix-like systems running X. Many of them are open source and/or documented in detail. And none of them is known for having X interactivity problem. How those systems solve problem? Do they renice X? Why no developer checked, instead developing new syscalls (pushing work to userspace and making Linux more incompatibile with other *nixes) ?
(Log in to post comments)
NIH Posted Apr 26, 2007 8:56 UTC (Thu) by nix (subscriber, #2304) [Link] It's not just X. Most large systems involve one process doing work on behalf of another. (The elephant in the room, as ever, is database servers, which often have similar problems internally as well as between them and their client processes.)
Older Unixes often had *severe* X interactivity problems. X has long been famous for its jerky rendering (especially `jerky mouse syndrome') and CPU hogginess; the jerky mouse has gone away of late, but only by the cheat of running the mouse pointer at insanely high priority and because machines are now fast enough that moving a mouse pointer is cheap.
NIH Posted May 3, 2007 5:53 UTC (Thu) by renox (subscriber, #23785) [Link] The general purpose OS with the best interactivity I know is/was BeOS.
I think that one of the reason of the good interactivity was that a bigger part of the GUI was inside the kernel..
I doubt that you'd be able to convince kernel developers to do the same thing.
|
|||||||||||||