From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 25 Nov 93 03:13:08 EST Subject: Linux-Development Digest #259 Linux-Development Digest #259, Volume #1 Thu, 25 Nov 93 03:13:08 EST Contents: Re: Linux/68k Version 0.06 released (Steve Parkinson) Re: Creeping featuritis (post --rant --flame) (Richard Brooksby) Re: Creeping featuritis (post --rant --flame) (Richard Brooksby) Re: Driver for Mitsumi FX001D? (William S. Kaster) Net-traffic logger. (L Lundman) Re: Creeping featuritis (post --rant --flame) (Brandon S. Allbery) Re: [Q] Big modem installation for Linux? (Dave Truckenmiller) Re: 1542B and DSP3160 bad I/O Performance (Eric Youngdale) Re: DECnet for linux (Donald J. Becker) Question about porting linux to other platforms. (Chris Fisher) Re: WANT Slackware for 5.25 disks (William Fang) Re: Linux/68k Version 0.06 released (ROOT - System PRIVILEGED Account) Re: Pentium & gcc ??? (Chris Smith) ---------------------------------------------------------------------------- From: parkinso@aludra.usc.edu (Steve Parkinson) Crossposted-To: comp.unix.amiga Subject: Re: Linux/68k Version 0.06 released Date: 24 Nov 1993 16:37:06 -0800 Note about unix on 68040 Amiga. NetBSD and Linux have both recently aquired 68040 capability. However.. don't get too excited.. There is still a lot of work to do on both ports. Someones asks: Is there a 68040 Unix for the amiga yet? Answer: Yes, but only if you're experienced with unix, and are willing to put up with the possibility of crashes. To anyone wanting unix on their 68040, just be patient, and it'll come! StevE -- =========================================================================== Steve Parkinson Commodore Amiga A4000/040, SCSI, 450MB. parkinso@usc.edu Computer Science Major at U. Southern California =========================================================================== ------------------------------ Crossposted-To: gnu.misc.discuss From: richard@harlequin.co.uk (Richard Brooksby) Subject: Re: Creeping featuritis (post --rant --flame) Date: Wed, 24 Nov 1993 13:09:21 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) wrote: > Where I come from, cat did block-by-block copies using stdio; cat -u > did block-by-block copies using read()/write() (and was so much more > efficient that I got into the habit of using -u always; some > versions of cat avoided stdio altogether and simply ignored -u). It > was only when someone decided to adopt the stupid BSD "cat -n" > nonsense that cat ended up being inefficient all the time. Horay! Someone who knows what they're talking about. I was about to despair. Can we persuade anyone else? --- Richard Brooksby Technical Manager (Harlequin) / Parallel Compiler R&D / Esprit COMPARE Project Research and Development / MLWorks Project / Harlequin +44 223 872522 (voice) / +44 223 872519 (fax) ------------------------------ Crossposted-To: gnu.misc.discuss From: richard@harlequin.co.uk (Richard Brooksby) Subject: Re: Creeping featuritis (post --rant --flame) Date: Wed, 24 Nov 1993 13:04:42 GMT kjetilho@ifi.uio.no (Kjetil Torgrim Homme) wrote: > I wrote: > > for i in `yes "" | cat -n | head -100`; do ... > > Richard Brooksby: > > I hope you don't write this sort of thing _and_ complain about the > > speed and memory requirements of other people's software. > > Do you think 100 expr's (and 100 test's as well if you are using > Ultrix) is more efficient? (Yes, I hear you, use Perl.) You're missing the point entirely. My complaint is that GNU is a chance to make things better, not worse. All these GNU tools are making their way into our lives in one way or another, and yet they are repeating the same basic design mistakes. > Richard: > > Look, I don't think cat -n is stupid for aesthetic reasons. It's > > stupid because it signifcantly complicates the operation of cat. > > Unless you foolishly write cat as line-in line-out (or even, horrors, > > char-in char-out) then cat -n is an entirely different program to cat! > > (and that's essentially how GNU cat is implemented) Oh no! > Granted, but your optimal cat won't be cat! What are you talking about? It concatenates things! I can write a cat that takes (in general) O(1)* instructions instead of O(n), provided it doesn't have the `-n' option. (* In case you're unfamiliar with this notation, it basically means that it'll take a constant number of instructions instead of a number depending on the lengths of the files.) The options provided on many of the tools, _especially_ the options added to the GNU tools, do _not_ improve the program. > Actually, I'd be more concerned about the -e and -v switches if I > were you. And -n comes from BSD, not GNU. Agh! That's precisely the point. That's NO excuse for having them! > Design your own set of disparate/disjunct programs and release > them. Don't expect us to suffer incompatibilities due to aesthetic > reasons (yes, I _do_ think that's what they are). Do you have an answer to the paragraph of my article which justifies my viewpoint? Did I not explain clearly why these are _not_ aesthetic reasons? Features are fun! Neophilia is fun! But I don't think they're a good idea. Here it is again, in case you didn't read it the first time: > So, what we end up with are several different programs glued together > in some unholy manner in the same binary. Bad design! The result: > bad code, bugs, unmaintainability, inefficiency, and, in the end, > major software disasters. > > The point is that you can have simplicity, efficiency, _and_ power! > Simplicity of design means faster development, fewer bugs, > adaptability. > > In an ill though-out rush for the power, we are sacrificing more > important long-term principles. I think your code using yes, cat, and head is fun and witty, but I don't think that's a basis for designing a decent system. Too many people think it is. --- Richard Brooksby Technical Manager (Harlequin) / Parallel Compiler R&D / Esprit COMPARE Project Research and Development / MLWorks Project / Harlequin +44 223 872522 (voice) / +44 223 872519 (fax) ------------------------------ From: wsk@mayfield.hp.com (William S. Kaster) Subject: Re: Driver for Mitsumi FX001D? Date: 25 Nov 1993 02:13:29 GMT Arthur van Leeuwen (arthurvl@sci.kun.nl) wrote: : Hi, : Last saturday I bought an Mitsumi CD-ROM drive, : but when I had it installed the linux-kernels I had : didn't recognize it. : It's a dual-speed multi-session drive. : Does anybody have drivers for this particular CD-ROM : drive or could somebody help me writing it? : It's an MITSUMI FX001D. I have this drive and the standard Mitsumi driver works fine. You do have to edit the mcd.h file that is in the linux headers directory. (Sorry away from the Linux box right now). You will want to make sure that the interrupt and address information matches waht you have set up with the dip switches on your card. Pretty easy to find. Regards, -Bill -- ------------------------------ From: lundman@kauri.vuw.ac.nz (L Lundman) Subject: Net-traffic logger. Date: 25 Nov 93 15:22:33 We've designed and built a network-traffic usage logger for linux, which charges per byte to a user of network usage in for example: ftp, telnet or any other tcp/udp connection the user wishes to use/compile. Reports can be produced for each user specifying hosts and byte count to and from each host. Why am I tell you this ?:) Just incase someone else is in the same position as we and have to pay for each byte to/from our machine and would want something similar. Later Kef -- =============================================================================== Jorgen Lundman eMail: lundman@kauri.vuw.ac.nz, lundman@rata.vuw.ac.nz. 8 Atua Street My thoughts are my own and not VUW's.. Johnsonville,wgtn "The reason people get lost in thought is because it's New Zealand such an unfamiliar territory" : (Unknown) Phone: +64 4 782 724 (GMT+11 hrs) ------------------------------ Crossposted-To: gnu.misc.discuss From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Creeping featuritis (post --rant --flame) Date: Thu, 25 Nov 1993 02:42:26 GMT In article richard@harlequin.co.uk (Richard Brooksby) writes: >I think your code using yes, cat, and head is fun and witty, but I >don't think that's a basis for designing a decent system. Too many >people think it is. Well, I personally come at this from the now-apparently-obsolete tool-user side: have a utility that numbers lines, a tool that generates lines ("yes" is from V7; I'm still waiting for some helpful idiot to invent "yes -n" to number "yes"'s output!) etc. Now the pipe is: for n in `yes "" | nl | head -10`; do echo $n; done Or, even better and somewhat more useful in real situations, a count-generator program: for n in `count 10`; do echo $n; done (and yes, I do consider "count" reasonable since it's an enabler for shell scripts. Besides, using "yes" to generate a full block of output and "head" to truncate it to fit seems wasteful to me.) ++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: trucken@hecto.cs.umn.edu (Dave Truckenmiller) Subject: Re: [Q] Big modem installation for Linux? Date: Thu, 25 Nov 1993 03:03:58 GMT In <2ctvt7$adg@penchiss10.ee.pdx.edu> bairds@penchiss10.ee.pdx.edu (Scarrow) writes: >joel@rac6.wam.umd.edu (Joel M. Hoffman) writes: >>Why only eight? I'm currently using two modems and a serial line, >>having told one of the modems to use com3 (I forget which int.) So at >>least 24 should be possible, and probably 32. No? >Keep in mind that 24 ports would take up 6 card slots and 32 would take up 8 >card slots. For example, on the 386 here at work we have 6 card slots total, >so a good maximum is really about 16 lines (with another slot for a multi-I/O >card and yet another slot for the monitor). It should be possible to design >cards that would handle, say, 8 lines per slot, but from what I've seen they >typically use 4. Depends a lot on the external connectors, too. The mini- >dins used by my current card really couldn't squeeze 8 onto a single slot. >Someone said that used terminal servers aren't too bad nowadays. I'm looking >at setting up a private network (probably starting with only around 4 to 8 >lines, but eventually hoping to get bigger) and am wondering how cheap is >cheap? :) Digiboard makes a card that fits into one slot in your computer and connects to an external box having 16 serial ports via an 8-wire cable. Several of these boxes can be chained together to produce something insane like 256 (or possibly many more, I can't remember) ports on a single PC. Performance on a 486 computer is very good. (Much better that I thought it might be.) I've used several of these for customers, and all are very happy. I don't know what the current prices are. Also, they don't yet have drivers for Linux, but they might be willing to change that if there is enough interest. I just thought I'd mention that, in general, there are ways to get lots of serial ports on your PC box without using up all the slots, and without having to resort to terminal servers. -- -Dave =================================================================== Dave Truckenmiller (trucken@cs.umn.edu) [ ASCII picture ] ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: 1542B and DSP3160 bad I/O Performance Date: Thu, 25 Nov 1993 03:19:03 GMT > One >of these days, I will run a user-mode simulation with profiling so that I can >try and identify any remaining bottlenecks. OK, I got the user-mode program working which uses the kernel code for the buffer cache, the request queueing, block device read/write, and all of the scsi stuff. I mainly did this because I wanted to see if there are bottlenecks anywhere that we should know about. On my 486/33, I get around 7.5Mb/sec throughput, where the simulation starts by calling block_read and goes all the way through to the scsi_debug low-level driver (which is basically a simulator). I have also experimented with profiling (which I have not done much of in the past), and I am getting really weird results. The gprof report says that we are spending about 20% of the CPU time in a function which returns immediately, and it gives time tics to other functions that are never called at all. Go figure. Anyway, I am going out of town for the next couple of days, so I thought that I would upload this so that other people can fiddle with it. If someone can figure out why the profiling is screwed up, I would appreciate it. I was hoping to use this information to further optimize the buffer cache, but the reports that I am getting are useless. THe source code is on tsx-11 in pub/linux/ALPHA/scsi/bench-01.tar.gz. Anyway, it would appear as if the theoretical maximum I/O rate is well above what people are seeing. I would guess that the actual hardware I/O transfer rate is the limiting factor for people using clustering. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ From: becker@super.org (Donald J. Becker) Subject: Re: DECnet for linux Date: Wed, 24 Nov 1993 14:44:39 GMT In article <1993Nov22.213106.992@ludens>, wrote: >I'm also interested in this (DECnet and Linux). I've very limited knowledge >about it, so if there's someone who knows more, plese share with us. >The problems I know of : > 1. Eth addr : DECnet (Pathworks for DOS at least) modifies the card's > eth addr, while Linux NET code uses the hardwired one. This isn't a hard problem. Most of the drivers already do the "right thing" and set the hardware address at open() rather than at boot-time. I'll pay attention to this as I update the drivers. For those not in the know, IP on "DIX" ethernet works by having a globally unique six octet (byte) read from an on-ethercard PROM, and stored in address-match registers. To communicate the initiating machine sends a _broadcast_ Address Resolution Protocol (ARP) packet that asks "what hardware address should I use for this IP address". DECnet works by putting locally-sequentially-assigned six octet addresses in those registers. DEC was part of "DIX", so the standard mandates the capability to set the hardware address. Since every machine has a fixed hardware address (even if the ethernet adaptor is changed) you just look its number up in a local table. > 2. multicast addr : DECnet uses it, but unimplemented in actual NET > code (as I know) I've put the device-level support for multicast in most of my ethercard drivers. There is still some mid-level work that needs to be done (final filtering [[ On DECnet Defined services (like the local printer) are assigned multicast addresses, so e.g. a freshly-attached workstation can just multicast its print request without knowing what machine will handle it. ]] >So its impossible without a major change in networking kernel code... Major changes? It's a SMOP;->. -- Donald Becker becker@super.org IDA Supercomputing Research Center 17100 Science Drive, Bowie MD 20715 301-805-7482 ------------------------------ Crossposted-To: comp.os.linux,comp.os.linux.help,comp.os.linux.misc From: cfisher@cs.uah.edu (Chris Fisher) Subject: Question about porting linux to other platforms. Date: Thu, 25 Nov 93 04:51:10 GMT I am with a group of people who are interested in porting any version of Linux to run under the SGI architecture. Any information or any pointers that one may have would be most appreciated. Thanks you. -- [Mail to:] cfisher@uahcs2.cs.uah.edu cfisher@axposf.pa.dec.com "Try and prove to a man that he is not immortal..." ------------------------------ From: int877w@lindblat.cc.monash.edu.au (William Fang) Subject: Re: WANT Slackware for 5.25 disks Date: 25 Nov 1993 07:04:52 GMT Mark Buckaway (mark@datasoft.com) wrote: : a cute boy!! (pschen@Winkie.Oz.nthu.edu.tw) wrote: : : Hello: : : Is there Slackware version for 5.25 disks? : : I very need it. : A 3-1/2" drive is only about $60-70CAN. Being that you are in Taiwan where : alot of these things come from, it should be much cheaper. : The Slackware disks are designed for 3-1/2 and will not fit on a 5-1/4 : disk. According to the readme's the author may release a 5-1/4 in the : future (read never). You can run a program called fdformat which will allow 1.44M on standard 1.2M 5.14" disks. I don't think the custom boot disk format is going to work. - Jim ------------------------------ From: root@ericsbox.video.arizona.edu (ROOT - System PRIVILEGED Account) Crossposted-To: comp.unix.amiga Subject: Re: Linux/68k Version 0.06 released Date: 25 Nov 1993 07:08:05 GMT Marc Duponcheel (marc@offline.be) wrote: : In article <2d0lss$kok@bmerha64.bnr.ca> Hamish.Macdonald@bnr.ca (Hamish Macdonald) writes: : > *) A memory management rewrite supporting the following new features: : > 1) 68040 support. : > : > * 68040 Floating Point Support Package incorporated. : If someone gets Linux running on a A4000/40 *please* post to this group ! Well, I tried. I got the kernel and the filesystem from tsx-11, all I get is: Amiga Linux Bootstrap version 1.2 Copyright 1993 by Hamish Macdonald and Greg Harp Amiga 3000 CPU: 6840 -- Alright! with 68882 FPU Amiga Linux does not currently support the M68040 Do you want to continue? If I type y or yes or anything else I get the dos prompt back. :-( Linux is so nice I had to get a 386-40 but I would like it also on my Amiga. I will try again in the morning. Send me e-mail or post you ideas. :-) -Eric : -- marc. : ################################################################################ : email preferred address marc@offline.be [= me@home] : aka marc@offline.UUCP ub4b!offline!marc offline!marc : if [me@home] fails mdu@abacus.be [= me@brussels.work] : or mdp@cimad.be [= me@antwerp.work] : fido 2:292/603.26 Marc.Duponcheel@p26.f603.n292.z2.FidoNet.Org [= me@home] : bix mduponcheel mduponcheel@BIX.com [= me@home] : ################################################################################ ------------------------------ From: csmith@convex.com (Chris Smith) Subject: Re: Pentium & gcc ??? Date: Thu, 25 Nov 1993 07:17:20 GMT In article <2cvpjk$rf@mailgzrz.TU-Berlin.DE> wpp@marie.physik.tu-berlin.de (Kai Petzke) writes: Newsgroups: comp.os.linux.development Date: 24 Nov 1993 14:03:32 GMT The 486 is still overpriced. When you take a look at the prices of AMD, they aren't much cheaper. Probably AMD agreed to not start a price war and Intel agreed to stop the legal war. This is totally irrelevant, but probably they are just profiteering like any sensible company would. Prices will come down *after* the clamoring stops. Anyway, adding -m586 is not hard. - First, catch your Pentium. - Second, the basic 586 thing is that it can issue two instructions at a time, when lucky. See alpha.md for how to do this. - There are many fine points, and you can spend as much time on them as you please. See ADJUST_COST and the other machine descriptions for ideas. But the above probably gets a large part of the possible benefit. ------------------------------ ** 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 ******************************