From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 29 Nov 93 22:13:21 EST Subject: Linux-Development Digest #272 Linux-Development Digest #272, Volume #1 Mon, 29 Nov 93 22:13:21 EST Contents: Re: Don't use Motif for free sw: it now requires runtime royalties! (Mark Lacey) Re: Don't use Motif for free sw: it now requires runtime royalties! (damercer@mmm.com) Re: Appletalk under LINUX? (Michael Griffith) AFS? (Sanjay S Vakil) Re: Creeping featuritis (post --rant --flame) (Brandon S. Allbery) Re: Comments from the "TAMU Crap" author (Brandon S. Allbery) packet fragmentation and kmalloc (Basil P. Duval EPFL - CRPP 1015 Lausanne CH) Many questions. (SAINTJOANIS Emmanuel) Re: Comments from the "TAMU Crap" author (David E. Wexelblat) Re: Comments from the "TAMU Crap" author (David E. Wexelblat) Re: Comments from the "TAMU Crap" author (David E. Wexelblat) Re: crap xconfig comments (David E. Wexelblat) Re: Don't use Motif for free sw: it now requires runtime royalties! (Amancio Hasty Jr) Re: Don't use Motif for free sw: it now requires runtime royalties! (Barry A. Warsaw) Re: ESC [ m (was Re: console.c questions) (Brandon S. Allbery) ---------------------------------------------------------------------------- Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: lacey@zamboni.sps.mot.com (Mark Lacey) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Mon, 29 Nov 1993 23:15:25 GMT > No (and you have most-likely already been through this), don't use > Motif for anything...It's > > - Ugly In your opinion. I haven't seen anything that I like more. NeXTStep, Macintosh, Xaw, Xw, etc. all included. I believe Motif was chosen from several dozen (maybe more?) entries to the OSF. > - Slow I don't know what you mean by that. Most of the Motif applications I have seen have been much faster than OpenLook applications, although the Motif Window Manager seems somewhat slower than twm (which I'm definitely willing to live with since twm sucks rocks). > - Difficult (read impossible) to program Maybe for you. I dunno, I've been doing X programming for a couple years now and have never found it very difficult (although deciphering documentation can sometimes be a pain). > Just waiting for GNU to come out with an interface spec... :-) Why, so you can wait 5+ years for an implementation? > greg -- Mark M. Lacey [lacey@zamboni.sps.mot.com] ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: damercer@mmm.com Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Reply-To: damercer@mmm.com Date: Mon, 29 Nov 93 22:37:57 GMT Mario Klebsch DG1AM (mkl@rob.cs.tu-bs.de) wrote: : aad@dvorak.amd.com (Anthony A. Datri) writes: : >>Xaw is small and fast, but there is not a trace of the : >>consistence, that make a GUI easy to use. : >How can pseudo-3D art-deco borders around everything POSSIBLY make an : >application easier to use? A button is a button, regardless of what stupid : >decorations are around it. In fact, the Motif toolkit can make an application : >*harder* to use because the stupid borders swell the window size so much : >that your windows end up obscuring each other more. : Agreed. The use of color or shades of grey in motif is awful. Some weeks : ago I saw Motif for the first time. I was supporting the port of a MS-Windows : application using a portable C++ library to a unix box using motif and the : same library. We used a greyscale X display. And I had problems to see wether : the radio buttons were pressed or not. But fortunatly, when we delivered the Use the selectColor resource to set the color you want to see when radio buttons are selected, for instance: *selectColor: Red : software, the client had an X-sever software for a PC, which was not able to : allocate some colors needed by motif. So motif switched back to B&W and the : radio buttons were fine ??? (and we did not have the problem of explaining : our client that it was his own wish to use motif). : The next thing I noticed was, that all the dialog boxes had to be resized. : This is not the fault of motif, but of the programming style in out application. : But it is an indicator, that the decoration around buttons,... needs a lot of : space on screen. We probably will have workstations with 30" screen soon.. :-) Try setting the shadowThickness resource. Setting it to 1 and setting the topShadowColor == bottomShadowColor leaves a 2d button. Setting it to zero removes the button borders completely. Of course, you also lose the animation of the button push as the top and bottom colors swap. : There is no need for any button, shade or anything else on output only : applications like a perfmeter or a clock. And in motif can easily be removed. : You probably can see, that I am critical to all GUI implementations I have : seen. And this is the point. We all know that 3D shades do nothing to make : applications easier to use. But they do nothing to make them worse exept : wasing some CPU power. But wasting CPU power is very popular :-). We should : better discuss the thinks _missing_ in the widget sets and GUI implementations, : because this can trigger someone to implement the things missing. : And there are a lot things missing in almost every GUI I know, especially the : ones we can use on unix boxes. : Mario : -- : Mario Klebsch, DG1AM, mkl@rob.cs.tu-bs.de (49) 531 / 391 - 7457 : Institut fuer Robotik und Prozessinformatik der TU Braunschweig : Hamburger Strasse 267, 38114 Braunschweig, Germany I've used every major GUI. I like Motif the best. -- Dan Mercer Applications + Plus Reply To: damercer@mmm.com "The Mad Pedant" ====================================================================== About a year ago I told the following joke which got a strong positive reaction from only 1 in 5 (all males my age - 40+) and shrugs from the rest. I wonder if it is more relevant now? "What does Mogadishu mean in Somali?" Answer - "Saigon" ------------------------------ From: grif@ucrengr.ucr.edu (Michael Griffith) Subject: Re: Appletalk under LINUX? Date: 29 Nov 1993 22:30:26 GMT In article <2ddnh9$dhf@tamuts.tamu.edu>, Troy Thoele wrote: >Greetings. > >I know this sounds like a stupid question, but does anybody know about a >package that can turn a Linux machine into an Mac file server? > >I have 4 Appleshare file servers, and would like to replace them with my >linux machine. > >If anybody knows of an appletalk-PC card driver for linux, I would like >information on this as well. Easy. Get CAP (the Columbia Appletalk Package). It does this type of stuff and more. -- Michael A. Griffith grif@cs.ucr.edu -- Michael A. Griffith grif@cs.ucr.edu ------------------------------ From: sanj@ATHENA.MIT.EDU (Sanjay S Vakil) Subject: AFS? Date: 30 Nov 1993 01:40:44 GMT Is anyone working on AFS for Linux? sanj ------------------------------ Crossposted-To: gnu.misc.discuss From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Creeping featuritis (post --rant --flame) Date: Mon, 29 Nov 1993 22:33:23 GMT In article haley@scws6.harvard.edu (Elizabeth Haley) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >>Programs like tar might incorporate a mechanism to run the filter themselves >>(compare the "z" option to GNU tar for compression). The difference being > >You'll at least have to add a flag to the header of the file, which >means changing the format of any storage program, which might be o.k. >for cpio and tar, but maybe not dd. I do like the idea of the filter Prepend it and have the filter strip it. (See also the 3B1's "gd" driver.) That way tar could even be modified to use a (DOCUMENTED!) scheme to detect the header and run the filter automatically. ---Or omit the header entirely and just stream it. It only causes problems if you pick up in the middle that way, and tar/cpio/whatever can't handle that anyway. (Note that, unless the support is *truly* integral to tar or cpio, you can't handle this case: the first block of a non-initial volume is liable to be part of a file, not a tar or cpio header.) >>Not so far as I know. The point is to plug in a RAID array in place of an >>external disk, and let the array's firmware do the work. > >Ahhh. I thought perhaps a cool controller would send a specific >failure message to the console, along with its happy little buzzer. Maybe some do; in that case it could just as easily be via a separate monitor process and interface (e.g. a serial port!). >>and write it to disk, it's got a major problem if the disk driver and/or >>filesystem are separate tasks which are blocked by the higher-priority real- >>time task. > >I have seen a few A/D board that had large caches, specifically so you >can just dump it once and a while, as cpu time permits. Then it's just This is for non-real-time systems. Real-time implies reading it as it comes in and possibly processing it. ++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: Comments from the "TAMU Crap" author Date: Mon, 29 Nov 1993 22:35:59 GMT In article <2ddbs1$qbg@hpcan240.mentorg.com> dave_clemans@mentorg.com writes: >David E. Wexelblat (dwex@aib.com) wrote: >: Yeah, I guess we could make the server print that out. Probably should. >: But this is 3rd grade math here. >: Manual verification should be done MANUALLY, BEFORE starting the server. > >It's false to assume that sufficient information is available to do >such manual verification. For example, IBM's "mass market" system, the >PS/1, typically comes with ABSOLUTELY NO TECHNICAL INFORMATION/SPECS AT ALL!!! I can confirm that; my mother bought a PS/1, and I was horrified by the lack of specifications. I have no idea whatsoever how to configure her monitor. Of course, since all she's running is the preinstalled MS-Windows, she doesn't have to worry about it. *That* is how the industry manages it... ++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: duval@elpp1.epfl.ch (Basil P. Duval EPFL - CRPP 1015 Lausanne CH) Subject: packet fragmentation and kmalloc Date: 29 Nov 1993 23:12:50 GMT Reply-To: DUVAL@ELPP1.EPFL.CH Hello world, I got 0.99.14 compiled and saw that the ip.c had ip defragmentation installed. I have sucessfully used a PCNFS client called NFSShare from a mac to connect to a VAX and SUN etc, and found that the only problem with the rpc.pcnfsd's that I found for Linux was that the blasted piece of software for the mac did its best to send the largest packets you have ever seen (8k+) whenever the file to be transfered was bigger than a single packet. This packet was send fragmented and up to now, Linux blew. Now, things ARE better, but it replies that it "refuses" to allocate 8045bytes "at the moment" and only gives say 4000bytes in the kmalloc call. So, again my software doesn't get through Linux. So my question: 1) should I get into the kernel routines and allow for more memory to be set aside for kmalloc. 2) should I get into the net software and allow more buffers or what ?? If anyone has any bright ideas, please yeild them up. small files transfer ok and it would be real nice to see the whole thing fly... Basil P. DUVAL EPFL/CRPP 1015 Bassenges Lausanne, Switzerland Email: DUVAL@ELPP1.EPFL.CH ps: version 0.99.14 on my dx2 wd80.. (16bit) system has net problems. If the route is listed in "route -a" then the connection goes, if not, after a couple of hours use, I get my net software a bit stuck. All returns to normal following a reboot, but I did not have this problem with 0.99.13s..... hoh hum ------------------------------ From: saintjoa@platon.emi.u-bordeaux.fr (SAINTJOANIS Emmanuel) Subject: Many questions. Date: Mon, 29 Nov 1993 11:47:47 GMT Ou trouver les sources du lovely-fucky color-ls ? Pourquoi la console X ne revient pas OK apres un Control-Alt-F1 ? Pourquoi SuperProbe me dit que ma carte est WD90C30, et que seul chipset "pvga1" fonctionne correctement ? In english: Where to find sources of the lovely-fucky color-ls ? Why doesn't my X come back correctly when I have a look on another console, by Ctrl-Alt F[1-6] ? Why SuperProbe tells me I have a WD90c30 and that doesn't work on X ? Only chipset pgva1 is ok. -- --------------------------------------- | saintjoa@esope.emi.u-bordeaux | | | | "Ich bin ein Linuxer" J.F. Kennedy | --------------------------------------- ------------------------------ From: dwex@aib.com (David E. Wexelblat) Subject: Re: Comments from the "TAMU Crap" author Date: Mon, 29 Nov 1993 23:08:23 GMT In article <1993Nov29.061255.16674@leland.Stanford.EDU> malouf@leland.Stanford.EDU (Rob Malouf) writes: >In article dwex@aib.com (David E. Wexelblat) writes: >>IF we picked a specific set of supported boards and supported monitors, >>then we could do things trivially by table look up. But you folks >>want us to support everything known to mankind. The generic problem >>is hard, perhaps impossible, to solve. >> >>Don't ever think there is any correlation between a BIOS or a Windows >>driver and what we have to do for XFree86. The folks who write the >>BIOS or write the Window driver: >> >> a) Only have to worry about one board. >> b) Know EVERYTHING there is to know about that one board. > >Why not take advantage of this info? Since I don't have a manual for >my monitor, I used the tseng3.exe program distributed with SVGAlib to >get the register settings used by the drivers that came with my video >card. Then, I configured SVGAlib to use those register settings and >used a modified version of vgaset to give me the timing values for >each SVGAlib mode. Voila! I was finally able to get 1024x768 to work in >non-interlaced mode. This method probably won't work for anything >fancier than an ET4000-based card, but then people with fancier >equipment probably have manuals too. > >Rob Malouf >malouf@csli.stanford.edu This is where the generic modes in README.Config came from (except the VESA modes, which came from the official VESA documents). Writing a GENERIC mode grabber is a pain in the ass. Just as for my comments above, writing a mode grabber for a specific chipset is fairly simple; writing a generic one is difficult. It's something somebody should do. I don't have time. -- David Wexelblat (703) 430-9247 Fax: (703) 450-4560 AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166 Formerly Virtual Technologies, Inc. Mail regarding XFree86 should be sent to "Ooh, are you feelin' satisfied? Come on, let us give your mind a ride." -- Boston, "Feelin' Satisfied" ------------------------------ From: dwex@aib.com (David E. Wexelblat) Subject: Re: Comments from the "TAMU Crap" author Date: Mon, 29 Nov 1993 23:10:09 GMT In article <2ddbs1$qbg@hpcan240.mentorg.com> dave_clemans@mentorg.com writes: >David E. Wexelblat (dwex@aib.com) wrote: >: In article <1993Nov25.220028.2203@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes: > >: Jeez, DO IT BY HAND! > >: Hsync == Dot-clock/Horizontal-Total >: Vrefresh == Hsync/Vertical-Total > >: Yeah, I guess we could make the server print that out. Probably should. >: But this is 3rd grade math here. > >: Manual verification should be done MANUALLY, BEFORE starting the server. > >It's false to assume that sufficient information is available to do >such manual verification. For example, IBM's "mass market" system, the >PS/1, typically comes with ABSOLUTELY NO TECHNICAL INFORMATION/SPECS AT ALL!!! > >The only way I was able to get it running XFree86 at all was to assume that >because the label on the monitor said it was built in Korea, that maybe >it was a Samsung monitor, and the Samsung numbers from modeDB.txt >would apply. > >dgc If it's false to assume that it can be done manually, then it's false to assume that the server can do it. End of argument. -- David Wexelblat (703) 430-9247 Fax: (703) 450-4560 AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166 Formerly Virtual Technologies, Inc. Mail regarding XFree86 should be sent to "Ooh, are you feelin' satisfied? Come on, let us give your mind a ride." -- Boston, "Feelin' Satisfied" ------------------------------ From: dwex@aib.com (David E. Wexelblat) Subject: Re: Comments from the "TAMU Crap" author Date: Mon, 29 Nov 1993 23:20:42 GMT In article <2ddgaf$s5e@senator-bedfellow.MIT.EDU> dmuir@ATHENA.MIT.EDU (Douglas Muir) writes: >I'm still fuzzy on one thing with BIOS/Windows drivers vs. XFree86 drivers. >I understand the part about how the guy who writes the BIOS driver knows >everything about the video card. What I don't get is how he knows about the >monitor which is connected to that card. After all, what we're really >talking about here is blowing up a monitor. So these BIOS modes/Windows >drivers, do they just set the video timing for the lowest common denominator >for a given mode (i.e., 640x480 @ 60hz) or is there some way that they can >detect that the monitor can do 640x480 @ 72hz? Both. All of them have lowest-common-denominator modes. They also often read jumpers or switches to know how to do higher ones (e.g. the "Set this switch if your monitor is capable of 48kHz horizontal sync", as one of my cards says). > If they're just setting the >lowest common denominator, why don't the people who want to make easy X >installations just write a simple script that checks how much video ram the >user has on his machine, and based on that, offers him a choice of the >standard modes (i.e. 640x480, 800x600 & 1024x768 for 1M), then spits out an >Xconfig for that mode, using the lowest common timing parameters. People >who know what they are doing can always compute better modes for themselves. >Or am I still missing something? > You're missing something. Specifically, README.Config. This is exactly what these modes do. We don't have a script because I ran out of time to get one written. So I wrote a document enumerating what my script would have done if I had the time to do it. But the other thing you're missing is that this problem is the entire reason VESA came into existence. (a) SuperVGA modes and (b) monitor timings. All the board vendors had the same problems we have with odd hardware. So VESA timing specification were invented. The timings in README.Config will work on 100% of modern multi-sync monitors, and likely on 90%+ of older monitors. There's also the fact that XFree86 gives you the flexibility to do odd modes. When's the last time you saw an SVGA card in DOS or Windows actually use all of its memory and give you an 1152x900 display? I've never seen it. >-Doug > My challenge still stands. I challenge anyone to show me a modern monitor (say, made since mid-1991) for which there is no working mode in README.Config for all of the specifications of the monitor. I'm willing to bet that no such monitor exists. Note that this doesn't necesarily apply to fixed-sync or multi-frequency monitors (i.e. ones with multiple discrete sync frequencies, rather than ranges). I would expect that the vast majority (80-90%) of these are configurable from the modes in README.Config. -- David Wexelblat (703) 430-9247 Fax: (703) 450-4560 AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166 Formerly Virtual Technologies, Inc. Mail regarding XFree86 should be sent to "Ooh, are you feelin' satisfied? Come on, let us give your mind a ride." -- Boston, "Feelin' Satisfied" ------------------------------ From: dwex@aib.com (David E. Wexelblat) Subject: Re: crap xconfig comments Date: Mon, 29 Nov 1993 23:25:34 GMT In article <2d8mep$fb4@cville-srv.wam.umd.edu> bbfaus@wam.umd.edu (John E. Krokes) writes: >In article , >Brett Person wrote: >>Well, I've never seen a monitor get fried by teeaking with the monitor >>settings. I have seen OS/2 and other pieces of software do this trick to >>calc frequencies. Under this logic, we should all quit using OS/2 and >>Windows. >> >Amen to this! > > _____________________________________________________________________________ >( John E. Krokes -- "Mag" -- First Accolade to The One True Dave ) > ) bbfaus@wam.umd.edu Most useful UNIX command: sleep 240 & ( >(_____________________________________________________________________________) > You've also seen the software put up BIG HAIRY NASTY disclaimers about damaging your monitor. At least, all the ones I've see do (ATI, #9, Orchid). As was pointed out in another message in this thread, people seem to be far more willing to accept damage from things they've paid for than from things they got for free. An interesting observation, anyhow. -- David Wexelblat (703) 430-9247 Fax: (703) 450-4560 AIB Software, Inc., 46030 Manekin Plaza, Suite 160, Dulles, VA 20166 Formerly Virtual Technologies, Inc. Mail regarding XFree86 should be sent to "Ooh, are you feelin' satisfied? Come on, let us give your mind a ride." -- Boston, "Feelin' Satisfied" ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Mon, 29 Nov 1993 19:26:53 GMT In article aad@dvorak.amd.com (Anthony A. Datri) writes: >>A soon to be release derivative of 386bsd will cost $40 for the CDROM >>and that includes X,gcc,kernel, tcp/ip,etc.. -- a fully functionable >>system but of course is not going to have Motif. > >>Also Linux has a CDROM distribution -- they are advertising on the >>latest issue of Byte and I am pretty sure that it does not have >>Motif -- The Linux SLS CDROM distribution is also very low cost. > >One of things that bothers me about both 386BSD and Linux is that there appear >to be a near infinite number of variations, and nobody will so much as >explain what "SLS" is supposed to mean. > SLS -- "Soft Landing Software" from a DOS bail out :-) Well, the 386bsd side is very simple, bsd/386 -- BSDI, commercial unix system 386bsd 0.1 --Public release by William Jolitz who was originally one of the principal architects at BSDI. FreeBSD -- Public release by the original patchkit group for 386bsd-0.1 I think that Walnut Creek CDROM team up with the FreeBSD group to pull together the CDROM distribution. NetBSD -- Public release by another group which has a slight different goal. For intance, there is a NetBSD amiga port group. This group tends to be more technically aggressive. It too will have a CDROM. Currently, NetBSD has dynamic shared libraries similar to the sun os mechanism. Both FreeBSD and NetBSD are organized effforts to bring bsd technology to the masses. Hope this helps, Amancio -- This message brought to you by the letters X and S and the number 3 Amancio Hasty | Home: (415) 495-3046 | ftp-site depository of all my work: e-mail hasty@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/X ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: warsaw@nlm.nih.gov (Barry A. Warsaw) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw) Date: 29 Nov 1993 22:02:24 GMT >>>>> "AAD" == Anthony A Datri writes: AAD> I've been hoping for this for years, but it hasn't happened AAD> yet. I'm sure that the existence of one would spur the OSF AAD> to make incompatible changes more often, But isn't this exactly what a blessed API standard is supposed to eliminate?! ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: ESC [ m (was Re: console.c questions) Date: Mon, 29 Nov 1993 23:12:08 GMT In article davis@pacific.mps.ohio-state.edu (John E. Davis) writes: >So, who is in charge of correcting the termcap entries for Linux? It seems >that I now have to hardcode escape sequences into my programs. I wish I knew; the entry for xterm's function keys is a bit screwy as well (or at least the terminfo one is; hello, Zeyd...). ++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 ------------------------------ ** 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 ******************************