Re: X is painful
Stephen Early wrote: Creating a user interface under X that is as good as NextStep is just a matter of getting every X application author to agree to adhere to the same policy. I wish you luck. Herbert Xu wrote: I agree that this is very diffcult. But the Debian developers should do their best at getting Debian programs to cooperate. Stuart Lamble wrote: This isn't trivial. As Stephen said, X provides the basics for graphical development; it doesn't provide any fancy schmancy stuff like menus, push buttons, etc. That's done by such things as Motif, xforms, Qt, etc. Converting an X program from one such library to another is a less than easy task.. so any attempt to produce a uniform interface is going to fail. Simple as that. But we have some fairly powerful tools at our disposal. Probably the most powerful of which is the shell command line. If we define simple set of shell command line operations to do menus, push buttons, etc., for our purposes, we can provide arbitrary programs to fill those needs. If we do it properly (just focus on providing the semantics we need, from simple commands), we should be able to plug in new programs as technology advances. Note that, in the long run, this doesn't tie us to X. Simple technologies which may lead in the right direction are TK (wish/wishx/expectk/..), and perhaps things like xmessage or 9menu. I think it's a good idea to avoid being too closely tied to the featurism of things like motif, or even xlib. [I think that patterning our efforts after the technologies developed at lucent (plan9, etc.) would be a good thing -- but I don't want to push this *too* hard.] -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
cdu31a
Package: disks-i386 Version: 1996-07-14 A friend is trying to convert to Debian from Slakware. He's using buzz-fixed off an Info Magic cdrom, and can't get the installation boot disk to recognize his cdu31a. At the lilo prompt, he's type linux cdu31a=0x230,0 This lilo parameter worked fine under slakware. Any suggestions? Thanks, -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: Protections against a mad maintainer?
Jonathan, writing from vega.netg.se: Believe me, if you want to make sure that an upload from you is untracable... It can be done .. Untraceable is a matter of degree. Forging someone's pgp signature is about as difficult as breaking into a commercial software publisher's office and replacing the master-copies of software there. Sure, it can be done, but this possibility doesn't favor one distribution channel over another. Also, untraceable has a strong element of risk -- you're going to have a presence somewhere, but does anyone care enough to want to investigate that presence? If someone cares, then maybe you find out you're not as untraceable as you'd thought. -- Raul
Python, minicom problems
Paul Kautz: Some packages seem to 'require' things they shouldn't need. For example, gnuplot can run (believe it or not, I've used this) with a terminal of 'dumb,' outputting text graphs etc., but needs xlib. I solved this last time by just installing xlib, even though I wasn't running X. This is a consequence of the way that shared libraries are currently implemented by the standard startup code that comes with gcc. HJLu has written a rather nice document describing the underlying mechanisms -- I think that it should be possible to develop an alternative strategy that lets you test for the presence of a library at the time that you run into the first system call into that library. The biggest issue would be deciding how to tell the compiler which libraries should be given this special treatment. I'm a little uncertain that the obvious solution (do it for all shared libraries, or do it for none) will always do the right thing for libc. Followups to this message should go to debian-devel (or maybe linux-gcc@vger.rutgers.edu). -- Raul
Re: Debian 1.1 man more
Ian Jackson: How about having each pager program use update-alternatives to provide a possible variant of /usr/bin/pager, and then having man configured by default to use /usr/bin/pager ? Another possibility would be to fix more so that it can scroll backwards. This shouldn't take more than 20 lines of code (copy stdin to a temporary file if it's not seekable), and would work on smaller systems. [There are a couple optimizations that could be made, but I'd hate to see them get in the way.] -- Raul
