From: Florin Andrei <florin@sgi.com>
To: linux-kernel@vger.kernel.org
Subject: desktop and multimedia as an afterthought?
Date: Mon, 12 Jul 2004 11:57:40 -0700 [thread overview]
Message-ID: <1089658659.15341.56.camel@stantz.corp.sgi.com> (raw)
I'm not a kernel developer. I don't watch this mailing list too often.
I use Linux for pretty much everything, and especially for multimedia
(capture, process and edit video, music and sound processing, MIDI,
etc.).
I'm interested in anything that could make my system work better for my
multimedia apps. I used the Con Kolivas patches very early on, and i'm
also watching with interest the recent preemption patch posted by Ingo
Molnar.
I could be wrong, but it seems to me that at least a part of the kernel
development team has the desktop and multimedia issues very low on the
priority list.
The CK patches floated around as separate patches for a long time, even
though they brought significant improvements to the kernel w.r.t.
desktop and media.
Now the stock 2.6 kernel has a pretty bad problem with the latency.
Also, there seems to be a reluctance in accepting the autoregulated
swappiness patch, even though it markedly improves the overall behaviour
of the system as a desktop.
I am not familiar with the intricate technicalities of the Linux kernel,
so there might be purely technical reasons for keeping multimedia
improvements at an arm's length.
But on the other hand, there are many Linux users, myself included, that
repeatedly noticed how bad the stock Linux kernel is from a multimedia
perspective and how big are the improvements brought by these
seldom-if-at-all-included patches.
The CK patches have devouted "cult followers".
Projects such as PlanetCCRMA, which attempt to build a multimedia-ready
Linux distribution, are running kernels patched with the CK patches by
default.
On the Linux multimedia mailing lists and forums, one can often hear
advices in the vein of "use such-and-such patch if you want your system
to do any serious multimedia work, the vanilla kernel sucks."
And rightly so. If i reboot my computer into Windows and perform the
same multimedia tasks, there are fewer chances of it skipping frames or
otherwise behaving improperly for multimedia work than on Linux running
the vanilla kernel.
I mean, go read the forums. No one in the multimedia community uses the
vanilla kernel. They could be all wrong, sure, but there's lots of them.
:-)
There's a feature of the human brain to see patterns everywhere - i
think i see a pattern here. :-) It's like the desktop in general and
multimedia in particular matter a whole lot less than anything else on
Linux.
It seems like there's a split-brain situation within the Linux
community, with the core kernel developers sitting on one side of the
rift, and the multimedia people on the other side.
Now, i remember someone saying, a while ago, that the server stuff is
pretty much done, and the interesting things are going to happen on the
desktop. That sounds plausible, but if the kernel has poor support for
typical desktop scenarios, how are those big desktop improvements going
to take place?
I'm not saying that the whole thing happens on purpose. I'm just saying
that perhaps the latency and swappines issues and all might deserve a
bit more attention.
Thank you, and i'm looking forward to constructive criticism.
--
Florin Andrei
http://florin.myip.org/
next reply other threads:[~2004-07-12 18:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-12 18:57 Florin Andrei [this message]
2004-07-12 19:12 ` desktop and multimedia as an afterthought? Mark Hahn
2004-07-12 20:47 ` Paul Davis
2004-07-12 21:25 ` Florin Andrei
-- strict thread matches above, loose matches on Subject: below --
2004-07-12 20:45 Albert Cahalan
2004-07-12 23:54 ` Paul Davis
2004-07-13 0:18 ` Con Kolivas
2004-07-13 1:11 ` Paul Davis
2004-07-13 3:25 ` Florin Andrei
2004-07-13 0:24 ` Andrew Morton
2004-07-13 1:49 ` Thomas Charbonnel
2004-07-13 10:22 ` Andrew Morton
2004-07-13 11:01 ` Thomas Charbonnel
2004-07-13 3:22 ` Florin Andrei
2004-07-13 8:30 ` Takashi Iwai
2004-07-13 11:09 ` Kasper Sandberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1089658659.15341.56.camel@stantz.corp.sgi.com \
--to=florin@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.