From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Cc: florin@sgi.com
Subject: Re: desktop and multimedia as an afterthought?
Date: 12 Jul 2004 16:45:54 -0400 [thread overview]
Message-ID: <1089665153.1231.88.camel@cube> (raw)
Florin Andrei writes:
> 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.
You're right, but you imply that this is bad. It would only be
bad if _all_ of the kernel development team had the desktop and
multimedia issues very low on the priority list. It would be
far worse if everyone worked on multimedia issues.
> 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.
Reluctance is good. Reluctance keeps out bloat. Reluctance supplies
time to investigate alternate ideas that might be better.
> 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.
This is expected. It's how proposed features get widespread testing.
> 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."
...
> 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.
It's too bad that the multimedia community didn't participate
much during the 2.5.xx development leading up to 2.6.0. If they
had done so, the situation might be different today. Fortunately,
fixing up the multimedia problems isn't too risky to do during
the stable 2.6.xx series.
> 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.
Nah. People do forget about problems if nobody is reporting them.
Since the problem reports came in late, you get to be last.
> 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?
Much of that is about hot-plug, laptops going to sleep,
busy disks being ripped from the machine, support for
recent video card features, and so on. Multimedia is only
a small part of the big picture, even for desktop usage.
next reply other threads:[~2004-07-12 23:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-12 20:45 Albert Cahalan [this message]
2004-07-12 23:54 ` desktop and multimedia as an afterthought? 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
2004-07-13 12:09 ` [linux-audio-dev] " Martijn Sipkema
2004-07-13 14:55 ` Paul Davis
2004-07-13 22:37 ` Martijn Sipkema
2004-07-13 22:31 ` Fons Adriaensen
2004-07-13 19:12 ` Bill Huey
2004-07-13 20:00 ` Lee Revell
2004-07-13 22:44 ` Martijn Sipkema
2004-07-13 22:08 ` Bill Huey
2004-07-13 23:37 ` Martijn Sipkema
-- strict thread matches above, loose matches on Subject: below --
2004-07-12 18:57 Florin Andrei
2004-07-12 19:12 ` Mark Hahn
2004-07-12 20:47 ` Paul Davis
2004-07-12 21:25 ` Florin Andrei
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=1089665153.1231.88.camel@cube \
--to=albert@users.sf.net \
--cc=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.