On Tue, Oct 14, 2008 at 09:04:34PM -0700, Garrett D'Amore wrote: > >GNOME isn't interesting since we can fix that. Presumably there's some > >significant unbundled software that is broken like this. For case 1), > >isn't LD_PRELOAD of a fixup library better? > > I'm not sure how LD_PRELOAD really solves the problem, except that it > requires users (and desktop environments, potentially!) to alter their > environment. This is not a good solution, IMO. The best solution is > one where everything Just Works.
Yes, but at what cost? > And yes, if Gnome (and any other desktop sound systems) can be "fixed", > it certainly makes my life easier, and at that time I'd be happy to yank > the code. Then that seems the way to go. Have you filed bugs against the relevant code? Is it easy to find examples on google codesearch? > One of my significant questions, though, is, are we certain that no > other useful cases for this information exist. Certainly there places > throughout the kernel that uses this information, although they are all > for fairly "bundled" components (such as the filesystem code, dtrace and > kstat helpers, etc.) You're using it for two things: 1) hacks for particular applications We're not Microsoft and we're not obliged to bend over backwards for applications stepping out of the APIs guaranted by the binary compat guarantee. There comes a point where doing this is an awful idea for long term maintainability. A perfect example would be changing the libc allocator if the binary is SimCity (yes, they really did do this). Brands are a much much better solution to this general problem. 2) providing ownership information Arbitrary strings are a terrible way of indicating this. Some form of contract would be the clean, correct way of doing something similar in Solaris, along with contract decoration. > The idea is a panel app that shows all the commands and gives individual > control over the levels associated with each running command. > > Windows Vista has something like this. Our own sdtaudiocontrol has the > same thing, but only shows the process id, which isn't terribly > informative to ordinary humans. > > But in any case, the problem I have here is that I have to retain > fidelity to the OSS APIs. It's a shame there isn't liboss or something then. To say the least, not a great design, but I think you know that already :) Again, which mixer is both important to Solaris and unbundled? regards john _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
