From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 27 Sep 93 07:13:16 EDT Subject: Linux-Development Digest #130 Linux-Development Digest #130, Volume #1 Mon, 27 Sep 93 07:13:16 EDT Contents: Whence 1.0? (Chuck Fee) Re: No smart serial boards??? (Bill Pechter) Re: No smart serial boards??? (Bill Heiser) Re: Whence 1.0? (Daniel J Thumim) kernel functions (Daniel T. Schwager) Mailing list for WINE (Adam Clarke) Re: term between AIX-Linux (Duty Programmer) Re: Intelligent Serial I/O: DIY (John R. Campbell) Re: Linux Slowly Dying Off? + Lets make a game for Linux (John R. Campbell) Re: [Q] SCSI tape (auto sense between QIC-24 and QIC-11) (Kai Makisara) killer developmemt environment? (Jan Nicolai Langfeldt) ---------------------------------------------------------------------------- From: fee@cxf111.rh.psu.edu (Chuck Fee) Subject: Whence 1.0? Date: Mon, 27 Sep 1993 01:56:19 GMT I'm curious if anyone (Linus I assume) has made a new target date for version 1.0. I know it's been pushed back several times, and it really doesn't matter what number it's called as long as it works right. I've been using Linux since 0.97 (Over a year now) and a friend of mine has been using it since 0.12 and I think we've gotten pretty damn close to full functionality. It's easier to say what isn't available for Linux now than what is available. Every major piece of unix software has been ported already or is being worked on. As it stands right now, I think we could rename 0.99pl13 as 1.0, but I'd venture to guess others will disagree What else needs to be done before we can get those V1.0 press releases ready? I know some work remains to be done on the net code (which works fine for me) and I assume there are other kernel changes waiting to be made, but what is it we are waiting for to be fixed/debugged/ implemented? --chuck ------------------------------ From: pechter@i4got.lakewood.com (Bill Pechter) Subject: Re: No smart serial boards??? Date: Sun, 26 Sep 1993 22:08:36 GMT In article cliffs@hip-hop.suvl.ca.us (Cliff Skolnick) writes: >Jon Brawn (jonb@specialix.com) wrote: >: Cost: >[lot's of stuff deleted] > >: Dumb: >: I/O4 AST four port look-alike $ 300 I'll sell mine for $50 plus shipping. It's an Olivetti repackaged AST 4 port -- it's unused. I went and ethernet'd the whole damn house instead. So I don't need the twelve vt100 carcasses in the garage either. Bill -- =============================================================================== Bill Pechter | The postmaster always pings twice. Lakewood MicroSystems | 17 Meredith Drive, 908-389-3592 | Tinton Falls, NJ 07724 ------------------------------ From: bill@bhhome.ci.net (Bill Heiser) Subject: Re: No smart serial boards??? Date: Mon, 27 Sep 1993 01:16:18 GMT In article <1993Sep26.190837.7308@pioneer.ci.net> richb@pioneer.ci.net (Rich Braun) writes: > >You can run 8 ports on a Linux box using the low-cost STB 4-Com. The [...] >cost is $110 per four-port card; comes with a quad 16550 chip, full >modem and flow-control signals on all ports. If you want more than 8 >ports, though, either you need more computers or you need a smart card With the "standard" linux serial driver, even *one* line running at 38400 (14.4 modem) uses quite a bit of CPU ... so I'd had to think of running *8* lines on a non-intelligent board :-) Rich, what is your system like when all of your lines are in use? -- Bill Heiser bill@bhhome.ci.net -or- heiser@world.std.com ------------------------------ From: dthumim@athena.mit.edu (Daniel J Thumim) Subject: Re: Whence 1.0? Date: 27 Sep 1993 03:01:01 GMT I was thinking the same thing recently... Linux beats the major commercial software developers in almost every category except the one where it's EASIEST to beat them... on-time delivery. 8-) I've been using Linux since 0.97 as well, and I remember when we were promised 1.0 by January 1, 1993. This isn't intended as a flame, Linus or anyone else... just let's see if we can get moving. It seems that the last few patchlevel releases have not been any more stable than previous ones. This is not good because people usually just grab the latest kernel release, and if it's buggy that looks bad for linux. Maybe we can split the kernel into two "releases"... one which would have no new non-essential features added, but would only be debugged until it's pretty stable and renamed 1.0, the other would be an "alpha" kernel for those who prefer the bleeding edge of development, to work with all the new features. Or, we can just work on stabilizing the current release and *then* adding new features to 1.01 or whatever. There are lots of new features waiting to go in all the time, and if we're always putting in new features we can never concentrate on getting a debugged release. I think it would be a very good thing if there was at least one stable release out there that people could use, then it will allow developers to play more with alpha kernels without messing up lots of peoples' systems. Just my two cents... -- |)an dthumim@mit.edu ------------------------------ From: danny@dragon.stgt.sub.org (Daniel T. Schwager) Subject: kernel functions Date: Sat, 25 Sep 1993 18:05:17 GMT Hi all, i try to port the net-2 code to another target machine, based on the Hyperstone processor, wich was developed in Konstanz-Germany. To do this port, i must also know some things about the kernel: At the moment i have got only one easy question: what's the job of the fs_... functions in asm/segment.h (get_fs, get_ds, set_fs....). A lot of other functions use them. I believe, these routines supports data-exchange, but if somebody could explain them to me, i would be very gratefully. Danny -- ,,, (^ ^) +------------------oOO--(_)--OOo-----------------------+ | ... Real programmers use cat >a.out ... Danny | ------------------------------ From: adamc@loose.apana.org.au (Adam Clarke) Subject: Mailing list for WINE Date: Sun, 26 Sep 1993 09:12:37 GMT I was hoping that someone could mail me the address of the WINE mailing list. Also I know I have to include something in my Subject: what is it? Thanks - Adam ------------------------------ From: duty@ariel.ucs.unimelb.EDU.AU (Duty Programmer) Subject: Re: term between AIX-Linux Date: 27 Sep 1993 17:28:10 +1000 In article ralph@falcon.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes: >In article pablo@austin.ibm.com (Paul Greenwood) >writes: >>Has ANYONE every gotten "term" to work between Linux and AIX? >> >>I configured term with no problems but when I run the utility programs, >>they just hang. I sent a note to the developer. He said that he has not >>had any luck nor heard of anyone that got it working correctly. So, how >>about it, ANYONE? Very strange! I think i must have been the first one to get term running, since i supplied Michael O'Reilly with the AIX patches. What i found was this: i could run term and trsh sessions quite happily, but tupload and txconn would just hang. Since this was what i really needed, i didn't spend too much time trying to debug it. >Several posts in the linux newsgroups suggested using a bsd-like >environment (compile with bsdcc, and link with -lbsd before any other Yep! It was only about 6 months ago (maybe even less) that i saw this advice. Doing that fixed the problems, so that everything works just fine now. >- The exact commands used to compile and link the program make :-) OK, with this: # AIX: replace CC with this line... CC=xlc -D_ALL_SOURCE -D_BSD # if use a NeXT machine, then replace CC with this line... # CC=cc -DNeXT CPP=$(CC) -E DEBUGFLAGS= $(DEBUG) -O LINKFLAGS=-lbsd >- The version of AIX used % lslpp -h 'bos*' Option Name State Event Date Release User Name ==================== ========== ========== ========= =============== ========== bos.obj INACTIVE COMMIT 02/03/90 03.01.0000.0000 root INACTIVE APPLY 09/20/90 03.01.0000.0001 root INACTIVE COMMIT 09/20/90 03.01.0000.0001 root INACTIVE COMMIT 01/13/93 03.01.0006.3008 root INACTIVE APPLY 03/26/91 03.01.0003.0013 root INACTIVE COMMIT 01/13/93 03.01.0006.3008 root INACTIVE APPLY 04/18/91 03.01.0004.0017 root INACTIVE COMMIT 03/26/91 03.01.0003.0013 root INACTIVE APPLY 07/09/91 03.01.0005.0012 root INACTIVE COMMIT 04/19/91 03.01.0004.0017 root INACTIVE APPLY 07/09/91 03.01.0006.0008 root INACTIVE COMMIT 07/09/91 03.01.0005.0012 root ACTIVE COMMIT 07/09/91 03.01.0006.0008 root bosadt.lib.obj INACTIVE COMMIT 09/20/90 03.01.0000.0000 root INACTIVE APPLY 03/26/91 03.01.0003.0007 root INACTIVE COMMIT 04/18/91 03.01.0003.0007 root INACTIVE APPLY 04/18/91 03.01.0004.0015 root INACTIVE COMMIT 04/18/91 03.01.0004.0015 root INACTIVE APPLY 07/09/91 03.01.0005.0011 root INACTIVE COMMIT 07/09/91 03.01.0005.0011 root INACTIVE APPLY 07/09/91 03.01.0006.0001 root ACTIVE COMMIT 07/09/91 03.01.0006.0001 root bosadt.prof.obj INACTIVE APPLY 09/21/90 03.01.0000.0001 root INACTIVE COMMIT 09/21/90 03.01.0000.0001 root INACTIVE COMMIT 09/21/90 03.01.0000.0000 root INACTIVE APPLY 03/26/91 03.01.0003.0004 root INACTIVE COMMIT 04/18/91 03.01.0003.0004 root INACTIVE APPLY 04/18/91 03.01.0004.0015 root INACTIVE COMMIT 04/18/91 03.01.0004.0015 root INACTIVE APPLY 07/09/91 03.01.0005.0009 root INACTIVE COMMIT 07/09/91 03.01.0005.0009 root INACTIVE APPLY 07/09/91 03.01.0006.0004 root ACTIVE COMMIT 07/09/91 03.01.0006.0004 root bosadt.xde.obj INACTIVE COMMIT 09/20/90 03.01.0000.0000 root INACTIVE APPLY 03/26/91 03.01.0003.0011 root INACTIVE COMMIT 04/18/91 03.01.0003.0011 root INACTIVE APPLY 07/09/91 03.01.0005.0007 root INACTIVE COMMIT 07/09/91 03.01.0005.0007 root >- ALL (and I mean ALL) PTF's which have been applied to this AIX. >My above experience is with AIX 3.2, and I'm too lazy to track down >the sub-version and the PTFs (we have probably installed hundreds), Yeah. SO am i. rab ======================================================================== Richard Brown | E-mail: rab@tauon.ph.unimelb.EDU.AU School of Physics | Phone : +61 3 344 5081 University of Melbourne | Fax : +61 3 347 4783 Parkville Victoria AUSTRALIA 3052 | Telex : AA35185 ------------------------------ From: soup@penrij.UUCP (John R. Campbell) Subject: Re: Intelligent Serial I/O: DIY Date: 25 Sep 93 12:21:07 GMT jonb@specialix.com (Jon Brawn) writes: >The basic idea was that instead of trying to craft drivers for already existing >(expensive) intelligent I/O boards, why not design an intelligent I/O board >that uses easily (cheeply) available components, and have a linux device >driver for it covered by Copyleft? Not such a terrible idea; of course, we could look at existing boards that are not currently aggressively supported. . . . >What sort of hardware is needed? >The sort of technology I had in mind is 16450/16550 UARTs, some RAM and an >Intel 80x86 processor (easy availability of development tools), possibly with >some LEDs for debugging purposes, on an ISA host card (yep, ISA has >sufficient bandwidth), arranged to give a dual-ported interface allowing >both the host '386/486 and the I/O processor access to the RAM and the UARTs. I've worked with SDL's RISCom/Si board (and intelligent ISA 8-port board) which uses an 80186 and a pair of Cirrus CD2400's. I've done both firmware (which needs to be downloaded to the card) and the device driver. Device drivers for such cards are complicated by the fact that you need to download the firmware to it and start it up. While the driver I wrote is kinda primitive (we only needed to drive terminals in raw mode) it was never actually used- we went to "dumb" boards from SDL (the RISCom/8 with Cirrus CD180), so I've got the drivers sitting around doing nothing. SDL is also rather helpful in providing programming information on their cards and I am sure they'd welcome an additional customer base. I've been trying to get my mind into putting the RISCom/8 onto Linux but have not managed to muster the enthusiasm (3 hours commuting time takes a lot of time from my family), but anybody interested in the source code I have for the RISCom/Si is welcome to it. I've been having trouble with E-Mail, so please E-Mail me at: soup@sonosam.execnet.com Which seems to work reliably. -- John R. Campbell soup%penrij@kd3bj.ampr.org or: uunet!kd3bj!penrij!soup ------------------------------ From: soup@penrij.UUCP (John R. Campbell) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: 25 Sep 93 12:27:11 GMT jepler@nyx.cs.du.edu (Jeff Epler) writes: >I doubt any degree of development will allow me to run Xwing or Dune >II while I render in the background (At a decent speed for both.) >What we really need is people writing good shareware games to run >under Linux, using svgalib or the like. >(Anyone want to send lots of mail to people @idsoftware.com telling >them they should make DOOM run under Linux in a native fashion? :-) >But seriously -- Is anyone out there writing games for Linux? Games >are the only thing that my DOS partition from becoming /usr2.... >Surely something of at least the quality of Apogee's "sixteen colour >platform game, for the sixteenth time. But we *did* change the >sprites" series of games is possible... I really beleive that Linux _NEEDS_ a screen-saver like After-Dark's TREK stuff, both for the normal console and X-Windows. I've seen PC's at work dedicated to running the start trek screen savers (after all, once loaded they take over most of the hard drive). >(And just think: In one year's time, CFV on comp.os.linux.games... It >should happen!!) >What's a computer for besides games? Mongo not know. Mongo merely pawn in great game of life. -- John R. Campbell soup%penrij@kd3bj.ampr.org or: uunet!kd3bj!penrij!soup ------------------------------ From: makisara@vtinsx.ins.vtt.fi (Kai Makisara) Subject: Re: [Q] SCSI tape (auto sense between QIC-24 and QIC-11) Date: 21 Sep 1993 08:54:06 GMT In article <27lv70INNich@lynx.unm.edu> cyrus@jemez.eece.unm.edu (W. Tait Cyrus) writes: I have hooked an old tape drive up to my linux box (0.99.10) and find that I can't read any of the tapes created while the drive was attached to a Sun. I have hooked the very same drive up to a Sun and all is fine. It appears that SunOS auto senses and switches between QIC-24 and QIC-11. Anything like this for Linux? Thanks in advance. -- W. Tait Cyrus e-mail: cyrus@su.com Solutions Unlimited Phone: 719-260-7227 4710 Nightingale Dr. #M202 Colorado Springs, CO 80918 The Linux SCSI driver uses for reading and writing the density it can get from the drive with a MODE SENSE. If the drive autodetects the density, this density is used. The density can be usually overridden with the MTSETDENSITY ioctl (mt setdensity) if you give the ioctl after the tape has been inserted and the drive has determined the density and if you know the density codes for your drive. There is no automatic density selection in the Linux SCSI tape driver. Kai -- DISCLAIMER: The views expressed here are mine and may not always coincide with the views of my employer. * Kai Makisara * email Kai.Makisara@vtt.fi * ------------------------------ From: janl@ifi.uio.no (Jan Nicolai Langfeldt) Subject: killer developmemt environment? Date: Mon, 27 Sep 1993 10:51:22 GMT Some thoughts about nextstep, but it applies to linux as well (imho). (tho, with ups and a growing purify clone linux should be well of as unices go). Nicolai From: Mark Crispin Subject: [comp.sys.next.advocacy] NEXTWORLD has (finally) blessed a very old idea Message-Id: Date: Sun, 26 Sep 1993 14:44:51 -0700 Newsgroups: comp.sys.next.advocacy Organization: University of Washington Well, it seems that Simson Garfinkel's column in the October NeXTWORLD makes a point that I've been making for the past 4.75 years: NeXTSTEP is badly missing an interpreter in its development environment. The current NeXTSTEP environment is straight out of the 1960's: Step 1: run text editor to edit your source code (in early 1960's, use punched cards). Step 2: run compiler program to build relocatable binary. If errors, go to step 1. Step 3: run linkage editor program to build executable binary. If errors, go to step 1. Step 4: try running program. switch (what happens) case it_works: go to step 5 case core_dump: run code dump analysis program. if see cause of program, go to step 1. else fall through to next case case it_doesn't_work: while (don't_know_what's_wrong) run debugger program on your program; go to step 1 Step 5: back up your work, and go home. Now, granted that a text editor is better than punched cards, and the debugger program loop is better than a direct ``go to step 1''. But these refinements both were well in place by the mid-1960's. By the 1970's, a new model had emerged. A degenerate version of this existed on certain traditional timesharing systems (most notably ITS and TOPS-20), but its full form was on LISP based systems. In this model, the shell, text editor, and debugger were all wrapped into a single environment. You could enter in forms and incrementally execute them as you were typing them in. If you got an error, the editor window points you at the form that caused the problem, and an inspector window shows you the state, etc. You poke around, figure out what is wrong, fix the code, and...: you can resume the program at the point of the error or at some other point!!! You never bother compiling the program until you've gotten it completely debugged. Compilation is a step to make a faster version, not a part of the development process. Note that gdb/emacs simulates somewhat of this process; it implements the degenerate version of this 1970's model so that 1960's systems are less intolerable. However, gdb/emacs under NEXTSTEP is actually worse than what was under ITS or TOPS-20. On ITS/TOPS-20, a process could not be killed without the consent of its superior, and a terminated process could be resumed or restarted at some other PC of the superior's choosing (damn, I miss this feature on UNIX!! Core dumps make me puke!). Even the most hardened UNIX die-hard has to admit that ``Segmentation violation (core dumped)'' is pretty stupid behavior, compared to the ITS or TOPS-20 behavior when a program crapped out. On ITS, the shell was the debugger; on TOPS-20, there was a command that spliced in the debugger in the process tree. Either way, you were in the debugger on your crapped out process, and you could see what went wrong and perhaps even fix it and resume your program. No loss of hours of runtime because of a stupid bug. NEXTSTEP could have this capability too. It isn't a new idea. It's a very old idea. Many NEXTSTEP groupies were still wetting their diapers when this idea came into being. How can NeXT claim to be the Object Oriented Operating System and Development Environment of the 1990's when it is still in 1960's software development technology??? NeXT, it is high time that you entered the 1970's. The personal computer world is no longer CP/M and Apple II with their 1950's operating systems. We had to get rid of mainframes, but we lost 20 years of software technology in the process. Why not bring some of that back, instead of saying that you already have? -- (Rmz) Bj\o rn Remseth !Institutt for Informatikk !Net: rmz@ifi.uio.no Phone:+47 22855802!Universitetet i Oslo, Norway !ICBM: N595625E104337 ------------------------------ ** 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 ******************************