From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Tue, 30 Nov 93 22:13:09 EST Subject: Linux-Development Digest #278 Linux-Development Digest #278, Volume #1 Tue, 30 Nov 93 22:13:09 EST Contents: Re: Comments from the "TAMU Crap" author (David E. Wexelblat) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (Brandon S. Allbery) Re: Comments from the "TAMU Crap" author (Brandon S. Allbery) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (Brandon S. Allbery) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (David Brooks) Re: Makefile Bug In 0.99.14 Kernel (Ben Taylor) Sample Generic SCSI code (Lawrence Foard) Re: Creeping featuritis (post --rant --flame) (Michael I Bushnell) Re: Creeping featuritis (post --rant --flame) (Michael I Bushnell) Re: Creeping featuritis (post --rant --flame) (Michael I Bushnell) Blown monitor (Kevin B. Thompson) ---------------------------------------------------------------------------- Crossposted-To: comp.windows.x.i386unix From: dwex@aib.com (David E. Wexelblat) Subject: Re: Comments from the "TAMU Crap" author Date: Tue, 30 Nov 1993 22:19:29 GMT In article <2dg8gl$d3d@boa.CS.Berkeley.EDU> curtis@boa.CS.Berkeley.EDU (Curtis Yarvin) writes: >In article <1993Nov30.171408.4161@kf8nh.wariat.org>, >Brandon S. Allbery wrote: >> >>...only if it's for a supported chipset. Check the OS/2 Installation Guide. >>And in any case, while you might be able to do it with Linux dosemu, you can't >>do it *portably* with *every* *ix that XFree86 runs on. XFree86 is NOT Linux- >>specific! > >YUURGH! I've heard this mantrated ten or fifteen times and the >more I hear it the sillier it sounds. > >Of course XFree86 isn't Linux/BSD-specific. Of course there are >three or four people out there running it on old Esix 3.2D >boxes that don't have decent commercial X support and are in >Madagascar so they can't download Linux from the net or have it >mailed to them by JANA because the lemurs would break the CD case. >Of course. And I'm not saying this is wrong. > >But saying "we refuse to add this feature because it wouldn't >work on Esix 3.2D" is like saying "we refuse to support >acceleration because it won't work on the ET4000." It's >dogmatic and silly. > >I appreciate the good work that the XFree86 people have done, >but it pisses me off when political termites like this eat >their way into a good project. > >c Get frickin' real. Three of the four originators of XFree86 run SVR4 (the other ran SVR3). A long, long, long, time ago we made a decision to not use dynamic loading for handling a bunch of things because SVR4 was the ONLY supported OS that could do dynamic loading. So we came up with the Link Kit. Where would all you Linux folks be, where would your TinyX be, your choice of whether or not to have PEX in your server, if we had said "Well, we use SVR4, and we have dynamic loading, so to hell with everyone else." We have ALWAYS maintained this policy, and we will always maintain this policy. You can stomp up and down and throw tantrums all you like. But we run this project, and we run it for the benefit of users of a dozen different OSs, not just one. You are asking for wholesale nasty changes to the way XFree86 works. For the benefit of one or two of the OSs. I think not. Sorry to say, the world does not revolve around Linux. Never has, never will. At least not as long as I'm at the controls of this thing. Believe me - it has little to do with politics. If we were being political, you can be DAMN sure I would be doing things for my own benefit, rather than spending 80-90% of my time solving other people's problems. It has a simple, pragmatic reason. We have to maintain this code. We want as much commonality as humanly possible. Across ALL platforms. Stick THAT in your pipe and smoke it. -- 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 From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: Tue, 30 Nov 1993 22:48:43 GMT In article <2dft45$fj0@snoopy.cis.ufl.edu> kem@prl.ufl.edu (Kelly Murray) writes: >OpenLook was even /worse/ an alternative, since it was only SUN who owned the >monopoly, and not a consortium of many different companies. You are >quite right that a MONOPOLY is most always bad news for consumers. Sun and AT&T. On the other hand, the XView source code is in the X11R5 contributed software distribution and XView 3.2 will probably be in R6; not much of a monopoly when the source is free... >I'll speculate it will be about 6-12 months before you'll be able >to buy such a library. This is probably why OSF is now trying to >be more agressive in enforcing their copyrights --- they don't have much >time before their current sole-source status is gone. Heh. No worry to them at all; it's no accident that they're preparing Motif 2.0 right now. (It's Bigger! It's Slower! It's Buggier! It's Uglier! It's not 100% guaranteed to be CDE-compatible! And best of all, IT'S STILL PROPRIETARY! ---Sheesh.) ++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 ------------------------------ Crossposted-To: comp.windows.x.i386unix From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Comments from the "TAMU Crap" author Date: Tue, 30 Nov 1993 23:22:35 GMT In article <2dg8gl$d3d@boa.CS.Berkeley.EDU> curtis@boa.CS.Berkeley.EDU (Curtis Yarvin) writes: >Of course XFree86 isn't Linux/BSD-specific. Of course there are >three or four people out there running it on old Esix 3.2D >boxes that don't have decent commercial X support and are in How about people running it on SCO in place of BrokenDesktop? (Rather like the people running the stock R5 server on Suns to avoid xnews...) I'm glad you think Linux and *BSD are worth supporting, but I strongly doubt that they're the *majority* of XFree86 users. ---And in any case, that is the publicly stated opinion of the XFree86 development team as well. Now if you can convince *them* that Linux and *BSD are so much more important than every other Intel *ix, maybe you'll get somewhere. But I'm not betting on 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 ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: Tue, 30 Nov 1993 22:58:03 GMT In article rhealey@sirius.aggregate.com (Rob Healey) writes: > I disagree that OpenLook was worse. OpenLook was a L&F, OLIT, XView > and whatever Sun actually called it's version were implementations. Sun's implementation of the OPEN LOOK GUI is XView. But XView is more than an OPEN LOOK GUI implementation; it's a replacement toolkit. XView's API is a modified version of the SunView API, as opposed to Xt. (AT&T's OLIT, on the other hand, is based on Xt.) ---I still think Xt is underdesigned, but the API has now been rather definitively frozen by COSE so I guess we're stuck with it. Yech. ++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: dbrooks@osf.org (David Brooks) Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: 1 Dec 1993 00:26:09 GMT I know I said I wouldn't write any more, but I feel I should correct three errors of fact that have appeared in this thread, and which may mislead others. pcg@aber.ac.uk (Piercarlo Grandi) writes: | 3) The rather extraordinary requirement for runtime library | royalties on each machine running an OSF Motif application | has been introduced with 1.2x, just about at the same time | COSE adopted Motif and OSF found themselves with no | significant competition, Sun and AT&T being vanquished. Motif 1.2 was first shipped in May 1992, and the license terms were announced at least 30 days before this (and probably more; I can't quite remember). COSE was about a year later. pcg@aber.ac.uk (Piercarlo Grandi) writes: | There are zillions of special cases; I also understand that if one cares | and has money the OSF might sell them a license with ad-hoc | conditions. Not true. Contrary to our charter anyway. preece@predator.urbana.mcd.mot.COM (Scott E. Preece) writes: | (b) that the | black box is staffed mostly by people either on loan from or hired from | the core group of principal member companies Not been a policy since October 1988. Staff are hired on the open job market. Some of them, naturally, come from the sponsor companies, but that's because they are some of the biggest (ex-)employers around, anyway. There's no sense in which they are seconded to promote their ex-employers' interests. Me, I'm ex-Prime. -- David Brooks, Open Software Foundation dbrooks@osf.org ------------------------------ From: s9ubxt@almserv.uucp (Ben Taylor) Subject: Re: Makefile Bug In 0.99.14 Kernel Date: Tue, 30 Nov 1993 23:10:44 GMT cjs@netcom.com (Christopher Shaulis) writes: >I believe that there is a bug in the new 0.99.14 kernel's makefile. >Apparently the symbol KERNELHDRS is defined but never used, so none >of the sub-makefiles (and thus the programs spawned from them) have >any earthly idea where to look for the include files. The quickest >solution to the problem seems to be appending "-I /usr/src/linux/include" >to line 77 of the main make file. That is the line which defines >the symbol CC. Sigh. For those of us who build the kernel on something other than a intel platform, this won't work, unless you have the source in /usr/src/linux/include. I don't. KERNELHDRS was in a pl0.99.13's release of the top level Makefile, and I modified the Makefile (net) from /usr/src/linux/include to ${KERNELHDRS}. I started using it at level 0.99.13p and found it in 0.99.13t. Guess I've got some work for 0.99.14 ahead of me. >Hope this helps someone, >Christopher >cjs@netcom.com Ben s9ubxt@fnma.com ------------------------------ From: entropy@world.std.com (Lawrence Foard) Subject: Sample Generic SCSI code Date: Wed, 1 Dec 1993 01:07:07 GMT -- ====== Legalize: >==--< | have given us jacks. . . \ / You are ~1,000,000,000,000,000 .1ms NAND gates have a nice day. . . . \/ The true theory of everything will run on a finite turing machine. . . . ------------------------------ From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell) Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) Date: 01 Dec 1993 00:41:21 GMT In article <1993Nov3004.29.31.28914@silverton.berkeley.edu> djb@silverton.berkeley.edu (D. J. Bernstein) writes: This shortsightedness means that you end up writing multi-volume support for tar and writing it _again_ for cpio. Duplicate. Duplicate. Bad. Bad. You have to extend tar. Fine. It wasn't perfect. Why don't you think for a few minutes and come up with a flexible extension that _lets_ you keep multi-volume support in a separate program? Give tar an option to print, on whichever file descriptor, a sequence of numbers saying where the file should be split. Give your file splitter a way to understand this sequence. Poof, problem solved. UNIX makes it so easy to avoid writing the same code again and again and again. Why don't you take advantage of that? The splitting program also needs to tell tar where the splits occur, because each tape has to have a volume header. In addition, some archive formats might need to start with a special sequence (as, for example, ar does). In addition, GNU tar can permit a split after any block, not just after any file. So, what we really have is that your "simpler" scheme would set up a bi-directional channel with another program, and some protocol for negotiating splits. And, I challenge that the "simpler" code to implement this would be more complex than the actual code in GNU tar. And that "simpler" (but actually more complex code) would have to be reproduced in every program that wanted to use the separate split utility. Moreover, the user interface is now *much* more complex. You have something like tar ... --splitter-output=3 --splitter-input=4 | |&3 |&4 split ... (except, of course, that shells don't actually support the needed feature.) Almost all of the complexity of the tar code volume splits is bent around making sure that each archive is nearly independent, but that a file can be split across the boundary--and this would need to remain, in tar, even under your scheme. All that remains (which your scheme would eliminate from tar, and replace with ever more complex code) is the following: (in the "read a new block" routine): $$$ err = rmtread (archive, ar_block->charptr, (int) blocksize); if (err == blocksize) return; if ((err == 0 || (err < 0 && errno == ENOSPC) || (err > 0 && !f_reblock)) && f_multivol) { union record *head; try_volume: if (new_volume ((cmd_mode == CMD_APPEND || cmd_mode == CMD_CAT || cmd_mode == CMD_UPDATE) ? 2 : 1) < 0) return; ... } $$$ and in the "write a block" routine: $$$ if (err < 0 && errno != ENOSPC && errno != EIO && errno != ENXIO) writeerror (err); /* If error indicates a short write, we just move to the next tape. */ if (new_volume (0) < 0) return; $$$ and the routine new_volume: /* We've hit the end of the old volume. Close it and open the next one */ /* Values for type: 0: writing 1: reading 2: updating */ int new_volume (type) int type; { int c; char inbuf[80]; char *p; static FILE *read_file = 0; extern int now_verifying; extern char TTY_NAME[]; static int looped = 0; if (!read_file && !f_run_script_at_end) read_file = (archive == 0) ? fopen (TTY_NAME, "r") : stdin; if (now_verifying) return -1; if (f_verify) verify_volume (); if ((c = rmtclose (archive)) < 0) msg_perror ("Warning: can't close %s(%d,%d)", ar_files[cur_ar_file], archive, c); global_volno++; volno++; cur_ar_file++; if (cur_ar_file == n_ar_files) { cur_ar_file = 0; looped = 1; } tryagain: if (looped) { if (f_run_script_at_end) { closeout_volume_number (); system (info_script); } else for (;;) { XXX Here is a default routine, retained for backward XXX compatibility, to perform the functions of the XXX --info-script option when none is provided } } if (type == 2 || f_verify) archive = rmtopen (ar_files[cur_ar_file], O_RDWR | O_CREAT, 0666); else if (type == 1) archive = rmtopen (ar_files[cur_ar_file], O_RDONLY, 0666); else if (type == 0) archive = rmtcreat (ar_files[cur_ar_file], 0666); else archive = -1; if (archive < 0) { msg_perror ("can't open %s", ar_files[cur_ar_file]); goto tryagain; } #ifdef __MSDOS__ setmode (archive, O_BINARY); #endif return 0; } -- +1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, +1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. 1105 Broadway | Then Jonathan made a covenant with David Somerville, MA 02144 | because he loved him as his own soul. ------------------------------ From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell) Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) Date: 01 Dec 1993 00:42:13 GMT In article <2dfil8$ej4@news.mantis.co.uk> mathew@mantis.co.uk (Nick Collision) writes: So can we take it that the Hurd will have the same approach? Try to provide a superset of all the features found in POSIX, BSD, System V, v7, and so on and so on and so on..? No, actually it won't. The BSD features are now a superset of the Posix features, and of the v7 features. As for binary compatibility, no effort is being spent on that (but it's pretty trivial to do anyway). -mib -- +1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, +1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. 1105 Broadway | Then Jonathan made a covenant with David Somerville, MA 02144 | because he loved him as his own soul. ------------------------------ From: mib@geech.gnu.ai.mit.edu (Michael I Bushnell) Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) Date: 01 Dec 1993 00:43:34 GMT In article rsi@netcom.com (Rajappa Iyer) writes: (Mib said): >You apparently haven't thought about it at all. The reason that >multi-volume support needs to be in tar is so that later volumes can >be complete archives, and (except for the file split between volumes) >can be read without needing context from a previous volume. Seems to me that the whole discussion is missing one of the basic principles behind the tool approach. Combine to extend instead of duplicating code. Multivolume backups can be handled with existing tools--- /bin/sh, ls, xargs, tar, gzip etc. spring to mind. A little creative use of existing tools can get you far more mileage from the system than writing monolithic monsters that do everything from backup to fixing you coffee (not that the last bit wouldn't be welcome :) Offhand, I would say that I have come across less than a dozen "new" feature which I found truly useful and could not be (almost) trivially implemented using "conventional" tools. Ladies and gentlemen: homework assignment. Please go back and read Kernighan and Pike's book "The Unix Programming Environment." And digest it. Please! You apparently haven't thought about it at all. You CAN'T get multivolume archives with existing tools that provide anywhere near the desired functionality. And, as for proposed new tools, see my last post. -- +1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, +1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. 1105 Broadway | Then Jonathan made a covenant with David Somerville, MA 02144 | because he loved him as his own soul. ------------------------------ From: kbt@philabs.philips.com (Kevin B. Thompson) Subject: Blown monitor Date: Tue, 30 Nov 1993 21:48:35 GMT I've seen several posts regarding monitors that were blown by XFree. I have a Gateway monitor and ATI ultra pro card (Mach 32). I'm not sure if XFree had anything to do with it, but a few weeks after I got Linux/XFree up and running on my system, my monitor started acting weird: it would irregularly get a yellow tint when I booted, which would sometimes go away after a few minutes, and sometimes it would go away, but then come back. I got a replacement monitor. I haven't had the problem since, but when I boot I still sometimes get yellow foreground text on a black background, sometimes white on black. *SHRUG* Anyone have a similar problem? ------------------------------ ** 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 ******************************