From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 14 Nov 93 18:13:17 EST Subject: Linux-Development Digest #227 Linux-Development Digest #227, Volume #1 Sun, 14 Nov 93 18:13:17 EST Contents: Re: Motif - Pay? BAH! (EurIng Chris Thoday) Re: Moving an X-Window from one computer to another. (Brandon S. Allbery) Re: Motif - Pay? BAH! (Brandon S. Allbery) Re: To - Do list for Linux (Michael Fuhr) Re: Motif - Pay? BAH! (System Overlord) Re: Motif - Pay? BAH! (Grant Edwards) Re: Moving an X-Window from one computer to another. (Rui-Tao Dong ~{6-HpLN~}) Re: Moving an X-Window from one computer to another. (Just a fellow traveller...) Re: Berkeley Fast Filesystem (Piercarlo Grandi) Re: Motif - Pay? BAH! (Chris Flatters) Re: Berkeley Fast Filesystem (Ian McCloghrie) ---------------------------------------------------------------------------- From: chris@thoday.demon.co.uk (EurIng Chris Thoday) Subject: Re: Motif - Pay? BAH! Reply-To: chris@thoday.demon.co.uk Date: Sun, 14 Nov 1993 14:08:49 +0000 In article <2bv87oINNpd@junk.cis.ohio-state.edu> dohm@cis.ohio-state.edu "peter j dohm" writes: >I don't have Motif. I refuse to purchase a binary-only distribution, >and a source distribution is too pricey. Therefore, I'd like to throw >out a project idea if the legalities allow for such... > >I'd like to begin programming a Motif clone that we can pass around >under GPL to whomever would like it, assuming that we can legally >get around the naming conventions, etc. (by this I mean, can we call >the cloned functions the same names as the Motif ones, etc... ?) > >Ideally it would be a drop-in replacement for Motif, allowing the end >user to simply create a soft-link to the "clone" library with a name >libXm.a and they would (in a nutshell) have a transparent replacement. I don't think this is possible because much X programming consists of using standard functions (such as XtSetValues) on non-standard data structures (i.e widgets). You will need to supply the `include' files which define the widgets and the application programs will need to be recompiled. In order to get application software to work you do not need to copy the appearance of Motif -- only the functionality. Making this distinction might help to reduce the effort involved. I read that there are 75 pages of reference information in the "OSF/Motif Programmer's Reference" for the XmList widget alone. You clearly need all the simplifications you can get. There appears to be some confusion in some people's minds between window managers and clients. In general, the widget set used for the client has no bearing on the choice of window manager. There are two reasons why this is not entirely true: a) The client may expect certain functions to be carried out by the window manager. These may vary between one style guide and another. I do not have access to the Motif Style Guide but I suspect that this is not a significant problem. For example, if the style guide prescribes that the window menu provides the method of closing the application then this function may be missing from the application itself. b) Mixing applications and window managers based on different widget sets means that there is less opportunity for shared libraries to conserve memory. X applications in general, and Motif in particular, tend to be slow because of huge memory requirements. Perhaps the solution is to persuade people who are writing software for Free distribution (in the GNU sense) to avoid using Motif in the first place. This thread started with a desire to be able to use software written for Motif without having access to the Motif libraries. I would like to suggest an alternative project: how about producing a widget set that would allow developers to produce applications consistent with the look-and-feel of Motif so that such applications could co-exist with commercial applications? Do we really need software that requires 75 pages of reference documentation to describe a simple operation? -- EurIng Chris Thoday, chris@thoday.demon.co.uk, Software Engineer 8 Victoria Street, RUGBY, a Director of the European X User Group Ltd Warwickshire, CV21 2HN, UK info@exug.demon.co.uk ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Moving an X-Window from one computer to another. Date: Sun, 14 Nov 1993 15:27:14 GMT In article <2c4idp$jj@news.u.washington.edu> davidb@stein3.u.washington.edu (David Barr) writes: >If it is just an xterm session, then yes, you could do this by using >"screen". Screen would let you have up to ten sessions within one >xterm, and you can move those sessions to another terminal without >interuption. > >The solution I presented is not X specific, but I don't know of a way >to do this with X programs. With X programs in general? You can't. You'd have to move the entire X state of the client (not just "window"! Remember, a scrollbar is a separate window. And possibly more than one window under XView or Motif. And a client can have more than one top-level window). This includes GCs (well, GContexts), colormaps, etc. (which I will collectively refer to as "resources", meaning SERVER resources, not the stuff you put in ~/.Xdefaults.) And what do you do if there isn't a compatible visual on the other system? Move a window tree with an 8-bit PseudoColor visual to a screen which only has a 1-bit StaticGray visual? Now, in theory an extension to Xlib could be developed which would download the client's entire set of resources from the server, sever the connection, connect to the server on the other screen, and upload the resources. It could query the new server for available visuals, choose the most compatible one, and adjust the resources to be uploaded to be compatible with the new server. A lot of work. And probably a failure: (1) who defines "compatibility"? An 8-bit PseudoColor to 1-bit StaticGray mapping that will work for xterm won't necessarily work for xv. And different people --- or different displays --- may want different mappings when moving xv in that fashion. (2) how do you re-share resources? A resource the client was using on the original screen may have been shared with other clients on the screen. In particular, if a program uses CopyFromParent for a window attribute when creating a window, then downloads that attribute from the server to move the window, it won't get CopyFromParent back... it'll get whatever the value was that was inherited. (3) What if some resource --- a font, a cursor, whatever --- needed by the client to be moved isn't available on the new server? Reconnect to the old server and download it? (ugh) ---And what happens if it's a scaled font and the new server doesn't have font scaling compiled in? Or you're moving it from a Sun with xnews's font format? I somehow doubt we'll be seeing this capability for X windows in general any time soon. (Of course, if someone would like to prove me wrong... :-) ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Motif - Pay? BAH! Date: Sun, 14 Nov 1993 15:30:38 GMT In article <2c56ru$esb@kea.doc.ic.ac.uk> na2@doc.ic.ac.uk (Nicholas Ambrose) writes: >yes, but arent all Motif apps dynamically linked in some way ? thus meaning >that if you try to run stuff, you still need the libraries on the machine, as >they are loaded at run-time ? Nope. In fact, several apps using the Motif widget set have specifically been statically linked for Linux, so people can use them without having to buy Metrolink's package just to run the binaries they've pulled off tsx-11 or sunsite. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: mfuhr@cwis.unomaha.edu (Michael Fuhr) Subject: Re: To - Do list for Linux Date: Sun, 14 Nov 1993 16:04:29 GMT winstead@cs.tulane.edu (Teddy Winstead) writes: >Has anyone ported xvtdl to Linux? Please let me know what needs to be >done to this beast to make it compile, cause I can't figure it out. Here are some notes I took when I was beta-testing xvtdl-5.0 (I think most were still valid for the final release): ======== Imakefile Commented out the line that reads "SVR4LIBS = -lintl". gfm.c Stole regexp.h from a Sun to get compile() and step(). gcm.c #ifdef'd out strcasecmp() for Linux. xdefaults.c Modified an #ifdef to #include for Linux (to get the definitions for F_OK and R_OK). lex.yy.c Don't use the original. Copy lex.yy.c-8bit-kludge to lex.yy.c and add the following line: #define yywrap() 1 Tried using flex, both with no options and with the -8 option; neither worked. ======== As I recall, I had some trouble with lex.yy.c in the final release that I didn't have with the beta. Unfortunately, I won't be able to provide any more help, because I'm moving soon and will probably have lost my account by the time you read this. Mike -- Michael Fuhr "Never trust a man who agrees with you. mfuhr@cwis.unomaha.edu He's probably wrong." -Unknown ------------------------------ From: kender@executor (System Overlord) Subject: Re: Motif - Pay? BAH! Date: 14 Nov 93 01:48:49 GMT Reply-To: kender@esu.edu Slaving away in a dark room, osyjm@cs.montana.edu (Jaye Mathisen) produced: > >I am not a Mosaic user, but WTF does the choice of window manager have >to do with the libraries required to build a program? >-- Motif is not only a window manager, but a GUI specification. There is an API that is used for programming applications that fit the Motif GUI spec, and it is the fact that money needs to be paid out to get this library that is the reason why a number of people want to work on a freely distributable version of the motif developement libraries. D -- |Dan Garcia,Kender@esu.edu|If privacy is outlawed then only outlaws will have | |#include | privacy - Phil Zimmerman, author of PGP | |Coram Deo|Death to Barney| This space for rent - mail ideas to me -- | | GCS/MU d--() -p+ c++(c+) l++ u+ e+(*) m++(*) s !n h f+ !g w+ t++(--) r+ !y | ------------------------------ From: grante@hydro.rosemount.com (Grant Edwards) Subject: Re: Motif - Pay? BAH! Date: Sun, 14 Nov 1993 20:42:32 GMT Nicholas Ambrose (na2@doc.ic.ac.uk) wrote: : yes, but arent all Motif apps dynamically linked in some way ? thus meaning : that if you try to run stuff, you still need the libraries on the machine, as : they are loaded at run-time ? Nope. When I buy commercial X stuff for my SPARC running X11R5, I am often asked whether I want the OpenWindows or Motif versions. I usually get the statically linked Motif version. I don't have OpenWindows or Motif libraries, but I do run Motif applications -- but I can't compile them! -- Grant Edwards |Yow! I know things about Rosemount Inc. |TROY DONAHUE that can't even |be PRINTED!! grante@rosemount.com | ------------------------------ From: rdong@playmate.mat.jhu.edu (Rui-Tao Dong ~{6-HpLN~}) Crossposted-To: gnu.emacs.help Subject: Re: Moving an X-Window from one computer to another. Date: 14 Nov 93 21:54:29 GMT >>>>> On Sun, 14 Nov 1993 15:27:14 GMT, bsa@kf8nh.wariat.org (Brandon S. Allbery) said: bsa> With X programs in general? You can't. You'd have to move the bsa> entire X state of the client (not just "window"! Remember, a bsa> scrollbar is a separate window. And possibly more than one window bsa> under XView or Motif. And a client can have more than one top-level bsa> window). This includes GCs (well, GContexts), colormaps, etc. bsa> (which I will collectively refer to as "resources", meaning SERVER bsa> resources, not the stuff you put in ~/.Xdefaults.) Emacs 19 is supposed to be able to close itself from one server and re-open to another server. I haven't had any success yet. It'll be nice if I can re-open emacs from my SPARC to my Linux machine over TERM and re-connect itself to the SPARC if the phone hangs up. Has anybody tried that? Regards, Rui-Tao Dong ~{6-HpLN~} Department of Mathematics rdong@playmate.mat.jhu.edu The Johns Hopkins University (410)516-7406(O) (410)516-5549(Fax) Baltimore, Maryland 21218 ------------------------------ From: jedubins@unix.amherst.edu (Just a fellow traveller...) Subject: Re: Moving an X-Window from one computer to another. Date: 14 Nov 1993 17:13:49 -0500 Of course this problem is much more difficult to handle with X-windows because of many of the environmental concerns that Brandon brought up, but I can think of at least one environment that does this pretty well: Macs. In some ways it's like comparing apples and oranges, because you can't move a a window from _one machine to another_- but individual machines can have multiple displays you can move windows, and the mouse pointer across. It's one of the capabilities I've always liked in the make environment. It would be neat if the X environment had software extensions to allow us to do something like this. I wonder if the X consortium would consider adding this to the next release after X11R6. Jim ------------------------------ Crossposted-To: comp.os.linux.admin From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: Berkeley Fast Filesystem Reply-To: pcg@aber.ac.uk (Piercarlo Grandi) Date: Sun, 14 Nov 1993 22:39:17 GMT >>> On 13 Nov 1993 15:19:42 GMT, brock@cs.unca.edu (J. Dean Brock) said: J> OK, OK. Everybody. Pull out your copy of The Design and J> Implementation of 4.3BSD Unix Operating Systems and read how J> fragments are really allocated before posting any more messages on J> this topic. J> Files CAN use multiple fragments. No... J> A 42k file WILL consist of 8 full blocks followed by 2 fragments. No, it will consist of 5 8KB (always assuming an 8KB/1KB fs, instead of any other more or less plausible one) full blocks plus a 2KB fragment; a 2KB fragment is not just 2 consecutive 1KB fragments. Thus the 1KB (in an 8KB/1KB fs) usually mentioned as the "fragment size" is actually the "fragment granularity". The FSS must keep separate lists of free fragments for each of the 8 possible fragment sizes; if the list for the fragment size one need is empty, a full block (or a larger fragment) is broken in two; the two parts are added to the free list for the appropriate fragment size. There might well be many 1KB fragment free, but no 2KB fragment around. The same is true in memory, with the modifications to the availability of VM (if the VM page size is equal to the fragment granularity one only needs a single size of buffers, or perhaps two, as one can make virtually contiguous the granules of a fragment that are physically discontinuous). Just to bury once and for all all this nonsense about blocks and fragments, as if Eric Youngdale's work were not enough, I will mention here the really terrifying details of the consequences of the FFS fragmentation scheme on incore buffers -- if you are under 18 years of age, or you are impressionable, or suffer from a weak heart, don't read on. You were warned! Ok, most files grow by appending at the end of the file. Suppose the file size starts such it is an even multiple of 8. One byte gets written: the FFS buffer manager finds a 1KB buffer and puts the byte into it. Now 1024 bytes are appended. The buffer manager finds a 2KB buffer, and moves the byte in the old 1KB buffer, plus the new 1024 bytes, into it. Every time 1KB more are written, a buffer with the larger size is allocated, the contents of the previous buffer are moved to the new larger and so on. This sad thing happens for all blocks that make up a file, as they are filled they grow from a 1KB frgament to a full 8KB block (if ever), KB by KB. When the buffer that overflows is finally 8KB long, or the file is closed, space for it is allocated on disk, and it scheduled for writing to that space. If the space requested is a full 8KB long, a full block is allocated; if it is 1-7 KB long, the "free list" on disk for that size is searched; if it is empty, a larger fragment or a full 8KB block will be split; as in a 6KB free fragment being split into say one 4KB free and one 2KB newly busy ones. If you have VM pages that are <= 1KB then growing an N KB incore buffer into an N+1 KB buffer can be done without copying by changing page tables. If VM pages are large, as on a Sun3, for example, one might consider copying things around every time a block grows, which is impossibly expensive (for each 8KB written to a file, the first 1KB gets copied 7 times, the second 1B gets copied 6 times, and so on...). The alternative is to resort to using 8KB buffers thruout, which is is only very expensive, as many files are way smaller than 8KB, so the amount of memory devoted to buffers will be in general wasted for well over 50% of its capacity, but this for one thing did not trouble the Sun people, who has ensured that in general memory was over 50% wasted in internal fragmentation anyhow. Now does anyone see why a block/fragment scheme is crazily complicated? ------------------------------ From: cflatter@nrao.edu (Chris Flatters) Subject: Re: Motif - Pay? BAH! Reply-To: cflatter@nrao.edu Date: Sun, 14 Nov 93 22:40:48 GMT In article 5a8@fbi-news.informatik.uni-dortmund.de, klute@tommy.informatik.uni-dortmund.de (Rainer Klute) writes: >In article <2bv87oINNpd@junk.cis.ohio-state.edu>, dohm@cis.ohio-state.edu (peter j dohm) writes: >|> I'd like to begin programming a Motif clone that we can pass around >|> under GPL to whomever would like it, assuming that we can legally >|> get around the naming conventions, etc. (by this I mean, can we call >|> the cloned functions the same names as the Motif ones, etc... ?) > >OSF has given resp. will give (I'm not quite sure) the Motif *specification* to >X/OPEN. That means, Motif will be an open standard. Everybody who wants can get >the specification and implement his own Motif. The OSF/Motif specification has been submitted for fast-track approval as an X/Open interface standard. In parallel with this, the IEEE P1295.1 Modular Toolkit Environment draft standard (Motif again) has finished the first ballot and looks to be on track for approval early next year. Chris Flatters cflatter@nrao.edu ------------------------------ From: imcclogh@cs.ucsd.edu (Ian McCloghrie) Crossposted-To: comp.os.linux.admin Subject: Re: Berkeley Fast Filesystem Date: 14 Nov 93 21:06:06 GMT keith@ksmith.com (Keith Smith) writes: >Optimizing code _at the computer_ for disk geometry was an interesing >idea that should now be killed. One should now leave the low level data >movement optimizations to the DRIVE. Then a given drive can use it's >cache & knowledge of the drive makeup to optimize on a per drive basis, >probably much more efficiently than you could with the CPU. The obvious >benifits are simplifying filsystem code to block clustering. The problem with this idea is that while the disk controller knows everything about the disk, it doesn't know anything at all about the filesystem structure. Said fs structure information becomes necessary to do cylinder grouping, etc. If the OS can do cylinder/head/sector positioning, it can make much more intelligent choices about what to put where than the controller hardware can. Take as an example a filesystem doing striping in software, if the disk controller remaps your request to somewhere else on one drive, but not on the other, you've lose a lot of the benifit. -- /~> Ian McCloghrie | Commandant of Secret Police - Cal Animage Beta. < < /~\ |~\ |~> | | <~ | email: ian@ucsd.edu Net/2, USL 0! \_> \_/ |_/ |~\ |__| _> | Card Carrying Member, UCSD Secret Islandia Club ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************