John Levon wrote:
> On Wed, Oct 15, 2008 at 09:14:46AM -0700, Garrett D'Amore wrote:
>
>
>> Sometimes yes. But the installed base of applications here is *huge*.
>>
>
> It's not really about install base though. It's about how many of these
> applications can't be easily fixed or upgraded, or automatically
> detected, and a library-hack solution is too much of a pain for.
> realplay could well be one example there: I'd be annoyed if I discovered
> I had to press a "make realplay work" button. Making YAMixer work? Not
> so bothered.
>
> regards
> john
>
I'm thinking that the library hack solution is too much of a pain for
the desktop environments. (I'm thinking about KDE and Gnome here,
mostly. But also other things like XFCE, Afterstep, ... ad naseum.)
If we can get to the point where we get the main candidate applications
converted and can drop the "whitelist" to an empty set, then I'd be
happy to nuke the reading of the u_comm field.
I think either psargs or comm may be useful for mixer panel applications
that are designed to the OSS APIs though. Originally I had planned to
just formulate a string consisting of the pid ("process id 12345") which
is less useful, but doesn't need me to look in the uarea. But since I
needed the uarea u_comm field to trigger the workarounds for these other
applications, I figured it made sense to use the psargs at the same time
to provide more meaningful content to the panel app.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
