On Tue, 2003-03-18 at 19:24, Austin wrote: > 1. Spiffy new sounddrake. > If I knew perl, I'd do it myself, but alas... > I'd like to see a more intuitive setup. What card is detected? What > drivers do you want, alsa or oss? Do you want a sound daemon?
"I have no drivers, but I want to use remote sound via esd/nas/etc."? "I want my sound server to accept remote connections from any machine my X server allows connections from/has a current connection from"? "I want both drivers for both/all my detected soundcards--this one is card 0 (primary), that one is card 1, etc."? > > 2. Spiffy new fontdrake. > > It's looking a bit dated; it's not all that easy to use; it would be cool > > to have more features. I'm sure someone can think of something to do to > > it. It should let you view uninstalled fonts and select them easily from the same interface. It should have options to show a complete font table (like gfontview). It should have more robust error-handling (if some step doesn't work, like converting a TTF to PDF, tell you what went wrong, and ask whether you want to install whatever worked or not). Instead of just saying "You can still install the normal way," it should tell you what the normal way is (especially useful if there was any error). > > 11. Superchaged applications. > > While I'm all for an rpm system and i586 optimization, there are a few > > applications that REALLY suck as they are. ATLAS, transcode, and > > mjpegtools come to mind. They are rediculously slow. Narfi has some > > benchmarks I think. Some options are: > > a) put athlon/P4/mmx rpms on club > > b) put athlon/P4/mmx rpms in unsupported > > c) someone write a script that will rebuild them locally with more > > optimization d) someone write a script that will rebuild any srpm locally > > for local architecture > > I've suggested (d) a few times to Deno and others and got quite rude > > responses. I think it might be a cool feature... definitely media > > worthy. You could install a stock distro, then rebuild anything > > resource-heavy (XFree, ATLAS, transcode) for your local architecture with > > no rpm or tarball knowledge. It's just an idea. Options c) and d) are pretty easy--if your local architecture settings actually specify what you have, anything you build will be optimized appropriately, so the only script you need is rpmbuild -ba or --rebuild.... The problem is urpmi. First, urpmi has to know that you want P4mmx if possible, 586mmx if not, plain 586 as a fallback. That's not too hard--but how does it choose between 1.4.1-2mdk.p4mmx.rpm and 1.5.0-1mdk.586.rpm? If I have mything-1.4.1-2mdk.P4mmx.rpm installed, and mything-1.5.0-1mdk is on one of the mirrors, what does urpmi do?
