From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 27 Nov 93 04:13:06 EST Subject: Linux-Development Digest #264 Linux-Development Digest #264, Volume #1 Sat, 27 Nov 93 04:13:06 EST Contents: Re: ESC [ m (was Re: console.c questions) (Mika Liljeberg) Re: [Q] >2 IDE HD's with linux (Juergen Baumann) Re: Don't use Motif for free sw: it now requires runtime royalties! (Amancio Hasty Jr) Re: Creeping featuritis (post --rant --flame) (Elizabeth Haley) Re: ESC [ m (was Re: console.c questions) (Brandon S. Allbery) Re: 1542B and DSP3160 bad I/O Performance (Harald Milz) Re: Creeping featuritis (post --rant --flame) (Brandon S. Allbery) Re: Linux/68k Version 0.06 released (Alan Braggins) Re: Creeping featuritis (post --rant --flame) (Greg Lindahl) Re: Creeping featuritis (post --rant --flame) (David Fox) Re: Linux/68k Version 0.06 released (Steve Parkinson) Re: [Q] Big modem installation for Linux? (Christian Weisgerber) Re: Creeping featuritis (post --rant --flame) (Elizabeth Haley) ---------------------------------------------------------------------------- From: liljeber@karhu.Helsinki.FI (Mika Liljeberg) Subject: Re: ESC [ m (was Re: console.c questions) Date: 26 Nov 1993 23:40:57 +0200 In article davis@pacific.mps.ohio-state.edu ("John E. Davis") wrote: > But how can a program do the *right* thing? Is there an ESC sequence that > returns the default attributes? Take `less', `most', or any other paging > program, for example. How can it be fixed so that the colors of the screen are > properly restored when it exits? It gets its information from termcap and > termcap says use ^[[m to turn off bold. CSI m restores the terminals rendering attributes to defaults. This is standard. CSI 8 ] stores the current rendering attributes as defaults. This is unique to the Linux console driver. The normal way to define colors for a virtual console is: setterm -foreground -background -store > /dev/tty?? This is equivalent to the command sequence: CSI 3 m CSI 4 CSI 8 ] CSI means the command sequence introducer, ESC [ Check out the setterm man page for more info. Mika -- Mika Liljeberg Email: liljeber@hydra.Helsinki.FI Helsinki University Mika.Liljeberg@cs.Helsinki.FI Dept. of Computer Science ------------------------------ From: JUERGEN_BAUMANN@ASCO.central.de (Juergen Baumann) Subject: Re: [Q] >2 IDE HD's with linux Date: Wed, 24 Nov 1993 17:42:00 +0200 Moin! pattjin%ucsee.eecs.berkeley.edu@UUCP.ZER hackte am 23.11.93 nachfolgendes in die Tastatur, um meinen kranken Geist bezueglich '[Q] >2 IDE HD's with linux' zu erhellen: PU> I was wondering if anyone has a patch that will enable linux to work PU> with > than 2 IDE HD's...there are device drivers for DOS that allow PU> up to 4 IDE HD's (using the secondary IDE port at 0x170 (i believe)). if you've got an IDE-Interface, that answers on any new IO-address, it's quite possible to connect more IDE-Drives, but no more than two at one Interface! (btw. every OS can access them with drivers for the new addresses) Nevertheless, I've never seen an interface with changeable IO-addresses and the interfaces with possibility connecting 4 IDE-drives are so expensive that you might better buy a scsi-controller... jb ********** replies always as PM! (I get only Z-Net packets) *********** ## CrossPoint v2.1 ## ------------------------------ 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: Fri, 26 Nov 1993 23:25:43 GMT In article muts@compi.hobby.nl (Peter Mutsaers) writes: >>> On 23 Nov 1993 04:20:45 GMT, shane@nugget.spr.com (Shane Hartman) >>> said: > > >For large institutions and companies, who used to be the traditional >users of Unix/X11, this $400 doesn't make much difference; but for the >mass market for personal use it does. If you want to see MS-DOS etc. >replaced by an open operating system then a (commercial) Motif cannot >be part of it. This might cause a market-failure for desktop Unix and >thus give leave the desktop to MS-Windows or its descendants while >there is a real chance now to change this. >-- 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. Both Linux and 386bsd CDROM distributions are cheaper than MS/DOS and Windows 3.1. It is pretty safe to assume that is going to take a major effort to provide motif for the masses and that we will most likely have to either develop a Motif clone or deploy a new graphics standard. Actually, Motif is just a component a good GUI builder is also needed for all of us. The equivalent of Visual C++... Fortunately, ParcPlace has donated a binary distribution of uib to both Linux and 386bsd. Yes, I am aware that there are commercially available GUI builders;however, they just don't compete in terms of cost to the full development systems like Symantec or Visual C++. Since, Windows/NT requires more resources than the Unix systems now is the time to strike :-) Perhaps with X11R6 things will get better... 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: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) From: haley@scws6.harvard.edu (Elizabeth Haley) Date: 26 Nov 93 22:48:58 GMT richard@harlequin.co.uk (Richard Brooksby) writes: >haley@scws6.harvard.edu (Elizabeth Haley) wrote: >> complex behemoths, possesing perhaps much power, but being quite slow >> about the functions they originally performed... >Hear hear! >My complaint is that the GNU project is _accelerating_ this process by >producing old tools with many, many, new `enhancements'. Stop it! >I find multi-volume IO very useful, for example. But don't add it to >tar, dd, cpio, etc. Think first, and make a new tool for the purpose, >and keep it simple. Hmmm... Actually, something like Multi volume I/O is a good thing, in my estimation. That's like adding cruise-control to a car for long trips. The point I am trying to make is the need to avoid feature that are added strictly because it is a popular pipe. One example would be to add a pager to tar for the -t option, so you don't have to pipe the list through a pager. Maybe this is an extreme example, but I can definately see it happening. One must endeavor to ascertain a program's popular function, and code within that boundary. Tar(1) is for archival storage managment and backup. Ar(1) is for library function archive management. It would not be appropriate for Ar to deal with tapes, except on an abstract level (i.e. as a file like /dev/rst0). Cat(1) is a file movement program. It should not add to files, and there is some question as to whether it should change them as in -e or -v, but since it is traditionally used to display short files to the user on terminals that might not accept > ASCII 127 characters, or might freak out on < ASCII 32 characters, it is perhaps appropriate to modify their display. Any others? And what should a kernel do? -- Hacksaw ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: ESC [ m (was Re: console.c questions) Date: Fri, 26 Nov 1993 23:24:28 GMT In article davis@pacific.mps.ohio-state.edu (John E. Davis) writes: >In article <1993Nov26.123548.25876@kf8nh.wariat.org> bsa@kf8nh.wariat.org >(Brandon S. Allbery) writes: > >Just enough to break things... I've seen it happen. Some color terminals *do* > >do it that way... and some broken programs assume the terminal does it that > >way... and *both* have resulted in garbled screens. > >program, for example. How can it be fixed so that the colors of the screen are >properly restored when it exits? It gets its information from termcap and >termcap says use ^[[m to turn off bold. The termcap entry is wrong. To turn off bold the sequence is \E[21m. The use of \E[m is a "bug" which is propagated for compatibility with older programs. \E[21;22;24;25;27m turns off all attributes without affecting colors. Note also that terminfo specifically describes the "sgr0" capability as resetting background and foreground colors to the default for the terminal, so the behavior of \E[m is appropriate for "sgr0". ---But doesn't agree with what most termcap-based programs expect for the equivalent operation. ++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: hm@seneca.ix.de (Harald Milz) Subject: Re: 1542B and DSP3160 bad I/O Performance Date: Fri, 26 Nov 1993 08:19:02 GMT Reply-To: hm@seneca.ix.de Eric Youngdale (eric@tantalus.nrl.navy.mil) wrote: : > The synchronous negotiation is enabled with a jumper that you set on : > the Adaptec - from what I recall this cannot be set via software, so the kernel : > does not have anything to do with this part. If my memory is correct, the : > 1542C can have synchronous negotiation enabled on a device by device basis, : > while the 1542B would have it enabled for all devices. That's right, Eric. As for the 1542C, you can stop the boot process with CTRL-A to enter the adapter setup. This looks quite similar as the EISA setup for the 1742A as far as negotiation and device interrogation is concerned. You can choose synchronuous transfer separately for every device. That's not possible with the 1542B *sigh*. : > The reason that it is apparently left turned off on the default : > configuration is that some devices do not like synchronous negotiation. The Well, the DSP3160S should like it because it is a SCSI2 device. But, alas, even with the 3160 I didn't get more than: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 150 331 43.2 492 16.6 304 12.8 377 58.5 829 24.1 28.2 12.0 This was mesured with the `bonnie' disk IO benchmark from the SSBA 2.0 benchmark suite by AFUU. If anyone is interested in this benchmark and doesn't find the sources elsewhere, I can send them via mail. It was written by Tim Bray in 1990. Machine: 486DX-33 ISA with 1542B and 8MB RAM. : > Note that even without the synchronous negotiation enabled, the Adaptec : > can do synchronous transfers, but for this to happen the scsi device itself : > must initiate the negotiation. Do you know any SCSI devices that initiate synchronuous transfer themselves? Ciao, hm : > And lines to code before I sleep, And lines to code before I sleep." Before, not when? ;-) -- _ _ _ _ __ __ _ _ E-Mail: hm@seneca.ix.de | |_| |__ _ _ _ __ _| |__| | | \/ (_) |___ | _ / _` | '_/ _` | / _` | | |\/| | | |_ / I used DOS, |_| |_\__,_|_| \__,_|_\__,_| |_| |_|_|_/__| that's why I use Linux. ------------------------------ Crossposted-To: gnu.misc.discuss From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Creeping featuritis (post --rant --flame) Date: Sat, 27 Nov 1993 01:10:37 GMT In article haley@scws6.harvard.edu (Elizabeth Haley) writes: >richard@harlequin.co.uk (Richard Brooksby) writes: >>I find multi-volume IO very useful, for example. But don't add it to >>tar, dd, cpio, etc. Think first, and make a new tool for the purpose, >>and keep it simple. > >Hmmm... Actually, something like Multi volume I/O is a good thing, in >my estimation. That's like adding cruise-control to a car for long >trips. I think he's saying that multi-volume I/O should be a separate filter instead of an option added to tar, dd, cpio, etc. Which makes sense; that way, if you want to use some other program to read or write the tape/floppy/whatever, you can use the filter to get multivolume I/O instead of having to hack it into the program or trying to force tar/cpio/whatever to do what you want. (Of the programs mentioned, dd makes the most sense for a multivolume filter because it's already a filter for modifying I/O, e.g. block sizes.) >Cat(1) is a file movement program. It should not add to files, and Um, no. "cat" concatenates files onto its standard output stream. "cp" and "mv" are file "movement" programs. >there is some question as to whether it should change them as in -e or >-v, but since it is traditionally used to display short files to the >user on terminals that might not accept > ASCII 127 characters, or Actually, this usage is something of a holdover from the days when a "tty" was a KSR33... It's appropriate for e.g. "more" or "less" to do this, though. >Any others? And what should a kernel do? That one's hard to call. What a kernel should do depends on the market you're aiming for; business users tend to need a lot more special kernel routines than academic and research folks, which is one reason why SVR4 is so much larger than V7 and (earlier?) BSD. I tend to get into conflicts over this, because while I myself prefer the minimalist approach, things which I can see being provided as user mode daemons in the minimalist approach have a nasty tendency to become major bottlenecks unless kernelized when the environment is 200 users querying a multi-million-record database... (That last is going to become a problem when Mach 3-based kernels start pusing into the DP arena. If you wondered why Microsoft didn't make NT a true microkernel, now you know.) ++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.unix.amiga From: armb@hamsta.setanta.demon.co.uk (Alan Braggins) Subject: Re: Linux/68k Version 0.06 released Date: Fri, 26 Nov 1993 17:09:28 GMT In article <2d2qni$nij@bmerha64.bnr.ca> Hamish.Macdonald@bnr.ca (Hamish Macdonald) writes: > > Actually, you have a third choice. You could patch the machine code > in the "bootstrap" binary to skip the 68040 check. I don't know how > many of you are willing to try to do this. Not without either instructions or a dissassembler. > - if (c != 'y' || c != 'Y') How do I change that "||" to a "&&" in binary, being a smaller change than removing the whole test? ------------------------------ Crossposted-To: gnu.misc.discuss From: gl8f@fermi.clas.Virginia.EDU (Greg Lindahl) Subject: Re: Creeping featuritis (post --rant --flame) Date: Sat, 27 Nov 1993 02:12:34 GMT In article <1993Nov27.011037.28089@kf8nh.wariat.org>, Brandon S. Allbery wrote: >I think he's saying that multi-volume I/O should be a separate filter instead >of an option added to tar, dd, cpio, etc. Which makes sense; that way, if you >want to use some other program to read or write the tape/floppy/whatever, you >can use the filter to get multivolume I/O instead of having to hack it into >the program or trying to force tar/cpio/whatever to do what you want. Unless, of course, you want features in a multi-volume tar that can't be implemented by using a filter, such as having a table-of-contents on every volume so you can still recover after losing some of them, especially the first one. Or, say, being able to mount just the volume containing the one file you want to restore. Or being able to compress the archive, have one bit flip in the first volume, and still restore most of it. You can pick great examples of things that should always be filters, but industrial-strength full-featured multi-volume backups isn't it. ------------------------------ From: fox@graphics.cs.nyu.edu (David Fox) Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) Date: 27 Nov 93 01:22:33 GMT I don't see what the big difference is between calling the enumerate lines program "enumerate" or "cat -n". So a few hundred more bytes of text get mapped, big deal. Cat is probably already mapped and "enumerate" probably isn't. Nor do I see the problem with typing "yes '' | awk '{print NR}' | head -100". Why should I care that its inefficient as long as it finishes before I can release the enter key? I'm getting cynical in my old age... -david ------------------------------ From: parkinso@aludra.usc.edu (Steve Parkinson) Crossposted-To: comp.unix.amiga Subject: Re: Linux/68k Version 0.06 released Date: 26 Nov 1993 18:57:54 -0800 Here are the instructions again for those who missed it. (This is to patch the bootstrap loader to work with a 68040. Theres no need to patch if you don't have a 68040) >I disassembled the bootstrap program as you suggested, Hamish.. >I changed the byt at offset 0x0d72 from 67 to 60 >(this changes a BEQ to a BRA, skipping the code you highlighted) Steve -- =========================================================================== Steve Parkinson Commodore Amiga A4000/040, SCSI, 450MB. parkinso@usc.edu Computer Science Major at U. Southern California =========================================================================== ------------------------------ From: naddy@mips.ruessel.sub.org (Christian Weisgerber) Subject: Re: [Q] Big modem installation for Linux? Date: 26 Nov 1993 19:02:22 +0100 bairds@penchiss10.ee.pdx.edu (Scarrow) writes: > It should be possible to design [multi-serial] > cards that would handle, say, 8 lines per slot, but from what I've seen they > typically use 4. Dumb cards for 8 or 16 ports are available, too. As for the connectors: My Fourport-clone uses an "octopus" cable, I guess 8 ports could be done with RJ45-jacks, for 16 one will need some kind of expansion box. -- Christian 'naddy' Weisgerber, Germany naddy@ruessel.sub.org ------------------------------ Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) From: haley@scws6.harvard.edu (Elizabeth Haley) Date: 27 Nov 93 07:03:50 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >>my estimation. That's like adding cruise-control to a car for long >>trips. >I think he's saying that multi-volume I/O should be a separate filter instead [stuff deleted] >the program or trying to force tar/cpio/whatever to do what you want. (Of [and again] Twould be nice, but what if the poor sod having to dearchive things is not told it's multiple volume? All she's/he's left with is "Sudden EOF!" >>Cat(1) is a file movement program. It should not add to files, and >Um, no. "cat" concatenates files onto its standard output stream. "cp" and >"mv" are file "movement" programs. Err, sorry miscommunication there. I was going to say display, but I think of "more" or "less" for that. I am referring to all such programs which read a file and send it to stdout. >>there is some question as to whether it should change them as in -e or >>-v, but since it is traditionally used to display short files to the >>user on terminals that might not accept > ASCII 127 characters, or >Actually, this usage is something of a holdover from the days when a "tty" was >a KSR33... It's appropriate for e.g. "more" or "less" to do this, though. My tektronix 4107 terminal will not display > 127 ASCII Characters either... It strips the eighth bit. >>Any others? And what should a kernel do? >That one's hard to call. What a kernel should do depends on the market you're >aiming for; business users tend to need a lot more special kernel routines >than academic and research folks, which is one reason why SVR4 is so much >larger than V7 and (earlier?) BSD. I tend to get into conflicts over this, >because while I myself prefer the minimalist approach, things which I can see >being provided as user mode daemons in the minimalist approach have a nasty >tendency to become major bottlenecks unless kernelized when the environment is >200 users querying a multi-million-record database... (That last is going to >become a problem when Mach 3-based kernels start pusing into the DP arena. >If you wondered why Microsoft didn't make NT a true microkernel, now you >know.) I am curious, what kind of kernal routines do business users use that academic types wouldn't? Beyond the database thingy mentioned above, isn't most of the rest pretty much standard? As a side note, how efficient is Mach with disk access, compared to other things? It seems to me that businesses ought to consider hiring programmers to make totally custom kernels if their business relies on fast transaction management. Most of the computers can be standard boxes, but the critical server should have the transaction requests built-in to the kernel, along with the duplication and redundancy code for safety and robustness. Then all you need is an extremely standard way of making queries, and maybe a fast box with 512 Megs o' RAM. Not to mention MUCH better magnetic media speeds. Anyway, on with the show... -- Hacksaw ------------------------------ ** 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 ******************************