From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 23 Sep 93 14:13:25 EDT Subject: Linux-Development Digest #120 Linux-Development Digest #120, Volume #1 Thu, 23 Sep 93 14:13:25 EDT Contents: Re: no libipc.a with slackware (Johannes Grosen) Re: ftp and ftpd pretty broke (Matthias Urlichs) Re: No smart serial boards??? (Matthias Urlichs) Re: To all device driver writers; boot-time messages. (Martin Koch) Linux Slowly Dying Off? (Rob Grzywinski) Re: Freeware Linux BBS - READ! (smhenry@succeed.ee.vt.edu) Intelligent Serial I/O: DIY (Jon Brawn) Re: GCC, is it a bug or isn't it? (no, it is not a bug) (Lars Wirzenius) Re: TERM is a registered trademark (sn) Re: no libipc.a with slackware (Karel Kubat) Re: To all device driver writers; boot-time messages. (Lars Wirzenius) Re: Linux Slowly Dying Off? + Lets make a game for Linux (Jeff Epler) PCI: are you thinking about this? (Michael Will) ---------------------------------------------------------------------------- From: grosen@argv.cs.ndsu.nodak.edu (Johannes Grosen) Subject: Re: no libipc.a with slackware Date: Thu, 23 Sep 1993 12:46:18 GMT In article skj@oasis.icl.co.uk (Simon Johnston) writes: >My Slackware distribution contains a kernel 0.99.12, and a dosemu 0.49. I >tried to compile the dosemu yesterday but there is no libipc library ! >does anyone have the libipc which would match the 0.99.12 kernel, and can >anyone tell me why I don't have one. The ipc calls are now in libc. There is no longer a separate `libipc'. >Thanks. > > >MODULE Sig; >FROM ICL IMPORT StdDisclaimer; > >BEGIN >(* ------------------------------------------------------------------------. >|Simon K. Johnston - Development Engineer |ICL Retail Systems | >|------------------------------------------------------|3/4 Willoughby Road| >|Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk |Bracknell, Berks | >|Telephone : +44 (0)344 476320 Fax: +44 (0)344 476084|United Kingdom | >|Internal : 7621 6320 OP Mail: S.K.Johnston@BRA0801|RG12 8TJ | >`------------------------------------------------------------------------ *) >END Sig. -- Johannes Grosen grosen@argv.cs.ndsu.nodak.edu System Administrator Intelligent Systems Cluster, Room 244 IACC Building North Dakota State University, Fargo, ND USA 51805 (701) 237-8282 ------------------------------ From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: ftp and ftpd pretty broke Date: 23 Sep 1993 09:19:56 +0200 In comp.os.linux.development, article , clau@acs.ucalgary.ca (Christopher Lau) writes: > > That's because of the net-2 kernel in general.. I'm using the telnet and ftp > clients from net-2 on a 0.99pl9 kernel, and the only problems I've had to date > are the mput/mget and the wierd problem at login where the "331 Password > required for .." message comes *after* the password prompt (Has anyone found > a fix for this?? This is a particularly wierd problem since the source > shows that the password prompt is printed *after* it tries to get the reply > from the remote, but the opposite happens when you run it.. ) > This could be stdio buffering. The password prompt thing usually uses /dev/tty instead of stdin/stdout, and if nobody flushes stdout... -- Don't force it, get a larger hammer. --Anthony -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstrasse 12 \ Unix+Linux+Mac | Phone: please use email... 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing ------------------------------ From: urlichs@smurf.sub.org (Matthias Urlichs) Subject: Re: No smart serial boards??? Date: 23 Sep 1993 09:32:47 +0200 In comp.os.linux.development, article , jonb@specialix.com (Jon Brawn) writes: > Legal: > If the requirement is that software source is made available, > then there is *no way* that most of the I/O vendors are willing > to do that. I have been toying with the idea of writing drivers > for the I/O8+, SI range and XIO range, however, I am always > put off by the software license. We aren't about to publish our > source code. > The problem is not that there's no software. The problem is that vendors typically don't say how to talk to the card on the I/O port level. Given that information, people could write their own drivers and you don't have to publish anything. Further, what do you mean "your source code"? The code on the card? Not an issue. The one for accessing the card from Unix? Would be neat to have, but not absolutely necessary given I/O port level documentation. In fact, I don't understand why you couldn't release that code since presumably the code you want to keep proprietary is the firmware on the card. > Support: > When you call us with a support call, it costs us real money to > answer the call. Each person who calls us up prevents one member > of our support team from (i) helping someone else (ii) writing up > a report of problems already seen, (iii) finding workarounds and > (iv) going to lunch. > (i) is not a reason, (ii) likewise because if nobody calls you don't get any problem reports in the first place, (iii) likewise. (iv) I can understand. ;-) > I would like to distribute just a binary of the driver with a small > C file to get it included into the kernel. Is this possible within > the confines of the Linux software license restrictions? > It's not possible because your driver accesses kernel data structures and routines which change name / size depending on the options the kernel is compiled with, eg. C vs. C++. -- When domestic servants are treated as human beings it is not worth while to keep them. -- George Bernard Shaw, "Servants" -- Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org Schleiermacherstrasse 12 \ Unix+Linux+Mac | Phone: please use email... 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing ------------------------------ From: nick@davinci.uni-paderborn.de (Martin Koch) Subject: Re: To all device driver writers; boot-time messages. Date: 23 Sep 1993 17:09:55 +0200 hpeyerl@novatel.ca (Herb Peyerl) writes: >Russell Nelson (nelson@crynwr.com) wrote: >: In article <1993Sep17.184413.6604@super.org> becker@super.org writes: >: I'm still looking for comments on the main points, especially suggestions on >: the content and (loose) format of boot-time messages. >: I'd like to see a prefix, of say, "I:" for informative messages, "W:" >: for warnings (something is not standard, e.g. COM1 using IRQ 3), and >: "E:" for an actual drop-dead error, e.g. trying to mount a MS-DOS >: partition as root. >Actually; I think you should take that a little further and change *all* >system errors to the following format: >%-- -- >So you would see errors that look like: >%TCPIP-F-EINVAL -- Invalid Argument. >%EXTFS-E-EDSKTRSH -- Lost track of Inode. Filesystem Trashed. >%EXTFS-W-ENOINODE -- Couldn't find free inode. You may have trouble later. NNNNOOOOOOOOOOOOOOOOOOOOO NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO I have to see this nonsense at work 8 hours a day. SSSTTTOOOPPP it. It's simply bullshit. You can give a simple error message, that should be enough. Why this idiotic %EXTFS-E-EDSKTRSH text. I hate VMS for it. This text is totaly obsolete. We don't want to degrade Linux to a better than nothing DOS. I think the englich explanation in combination with real error codes is enough. The Idea with w: and e: is better and could be added to the explanation text. >Then you could go a little further and modify all the console logging >so that console messages look like: >%%%%%%%%%%% OPCOM 22-SEP-1993 09:17:09.24 %%%%%%%%%%% >Message from user "news" on mynode.my.domain >Expire: no permission on history. >%NEWS-F-EPERM -- No Permission. Where the hell is your damnit smilie. I can't believe you this for real. >-- >hpeyerl@novatel.ca | NovAtel Commnications Ltd. >hpeyerl@fsa.ca | > ;-) --- Bye ;-) Martin Koch --- email : nick@uni-paderborn.de Bodelschwinghstraße 8 --- phone : +49 5251 31104 Q D-33102 Paderborn Germany ==============Escape the Gates of Hell, use Linux========== Very Mystic Shit ------------------------------ Crossposted-To: comp.os.linux.help,comp.os.linux.misc From: grzyrob@elof.acc.iit.edu (Rob Grzywinski) Subject: Linux Slowly Dying Off? Date: Thu, 23 Sep 93 15:50:08 GMT I remember back to the days where a new SLS was comming out every three weeks, the news groups were filled to the point of breaking with new updates and the project was full speed ahead. I hope not to start any crap (to put it mildly) with this, but I think that we (you) have a great product going here and I don't want to see it dying out. I have introduced at least ten people to the Linux system and they love it. We wait patiently for a new update and quickly grab it. We all also dab a little in fixing bugs, but times are tight. I hope that we can rejuvinate our love for the project and continue full speed again!!! I believe that the Wine project is a great idea, and it will get many a DOS/ Windows user over to the Linux system. I hope also the the dosemu project will liven up a bit (160+ days since an update!?!?!?) since that will drag the rest of my collegues over to the system (they can't live without their Star Wars.) Keep it goin' guys!!!!! Sincerely, Rob Grzywinski grzyrob@elof.acc.iit.edu ------------------------------ From: smhenry@succeed.ee.vt.edu Subject: Re: Freeware Linux BBS - READ! Date: Thu, 23 Sep 93 10:15:42 GMT+0200 In <27r0pu$i39@agate.berkeley.edu> bogart@ucsee.Berkeley.EDU (Ken Geis) writes: | I've seen a lot of conversation on the Linux and BBS newsgroups | recently about running a freeware Linux BBS. The responses haven't been | too appealing, especially from the 'freeware' standpoint. I've got an | idea that's perfect for the Linux environment. | Why can't we write one? I'm not up to it myself, but I'd be | glad to contribute whatever knowledge and coding I could. Let's talk, Sounds good to me, count me in! -- Steve Henry - SUCCEED BBS Operator - succeed.ee.vt.edu SUCCEED - Southeastern University Coalition of Emerging Engineering Departments ------------------------------ From: jonb@specialix.com (Jon Brawn) Subject: Intelligent Serial I/O: DIY Date: Wed, 22 Sep 1993 22:02:32 GMT I had an illuminating email exchange with Johan A. Grape at Dartmough College, Hanover, NH. 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? What is an Intelligent I/O board? Usually, a board with a processor and some RAM on it that is used to offload some of the work from the host '386/486 processor. The code that the I/O processor executes performs much of the common line discipline functionality, sush as tab expansion and convertling line-feed to carriage-return,line-feed pairs on output. Really good ones also perform input processing. They usually have enormous buffers (compared to 8 or 12 character FIFOs). Who would want to do this sort of work? The design of the board could be undertaken as an EE project, and the driver as a CS project. The aim would be to come up with a *cheep* solution rather than the most technologically advanced solution (it would be hard to compete with the RISC processor based solutions the big I/O vendors are using). 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. What about the software? Well, there are at least two pieces of software, the Linux device driver, and the code that runs on the I/O processor. At least two? Yep, the third piece of software is a configuration/management tool (or set of tools) that are used for a super-set of stty functionality (enabling the marvelous [but non-standard] features of the board, locking settings etc.), with possibly some rather nice program to help with configuring getty, uucp, SLIP, and other delights, helping to reduce the number of ``Help! uugetty ate my CPU'' type postings to the comp.os.linux.* groups. There is also an installation issue - if the driver isn't included in the normal kernel (but I don't see why it shouldn't be) then it will need some installation software [and boy, am I glad I'm not writing it]. ------------------------------ From: wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) Subject: Re: GCC, is it a bug or isn't it? (no, it is not a bug) Date: 23 Sep 1993 18:35:56 +0300 dmw@prism1.prism1.com (David Wright) writes: > I always just assumed that it would strip out anything between the > #ifdef'ed code if it was not going to be included, but noooooo they have to > try and parse it anyway. Seems like a Bad Idea (TM) to me... This has nothing to do with Linux. You might want to ask the same question in comp.std.c, and they will probably explain to you why it is better to have the preprocessor work on tokens, not arbitrary text. (The preprocessor used to work like you seem to want it, but even before the standardization there were different approaches. The standard mandates the token-based approach.) -- Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) It doesn't matter who you are, it's what you do that takes you far. --Madonna ------------------------------ From: sn@plato.chemietechnik.uni-dortmund.de (sn) Subject: Re: TERM is a registered trademark Date: 23 Sep 1993 15:23:10 GMT jefftep@cs.utexas.edu (Jeffrey Grills) writes: >In article <748663680snx@crynwr.com>, Russell Nelson wrote: >>TERM is a registered trademark of Century Software. >> >>Maybe the free "term" package should be called termlink? >> >gee, I personally don't see it being a problem. First off, they'd >have to complain. Second, they'd have to take it up with Michael, >and he's in Australia. Third, they'ed have to win. >Words that are in the common domain are exempt from this kind of thing. >term is just simply too generic for someone to trademark. It'd be like >General Motors trademarking "auto" or something.... >no way, no how will it stick. Also, as far as I know, term development is discontinued and Michael is now working on "Slap" with similar functionality. -Sven ------------------------------ From: karel@icce.rug.nl (Karel Kubat) Subject: Re: no libipc.a with slackware Date: Thu, 23 Sep 1993 15:57:08 GMT In skj@oasis.icl.co.uk (Simon Johnston) writes: >My Slackware distribution contains a kernel 0.99.12, and a dosemu 0.49. I >tried to compile the dosemu yesterday but there is no libipc library ! >does anyone have the libipc which would match the 0.99.12 kernel, and can >anyone tell me why I don't have one. Simon: The same problem occurred to me. It seems that the standard libc.a should have the ipc routines included; therefore; all you'd have to do is to remove the flag -lipc from the makefile at the location where the linking occurs (I think that this flag is somewhere in the LFLAGS definition, but I'm not sure). For me, however, this didn't work. It did produce a program and shared library, but a defect one.. Sadly, I can only use dosemu with the old Linux version (pl10), where it has to be linked explicitely with a libipc.a. The problems I have with pl12 is that Dosemu comes up, but that the keyboard is dead.. no matter which flags for dosemu itself (raw or not raw keyborad IO) are used. The error log prints messages like, "shmget(): function not supported" etc.. Any suggestions on this, how to make dosemu run with pl12? I'd be much obliged.. Karel. -- The ICCE usenet account providing access to usenet news for the ICCE Experience _WERKEN_AAN_DE_GRENZEN_VAN_HET_KUNNEN_ ------------------------------ From: wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) Subject: Re: To all device driver writers; boot-time messages. Date: 23 Sep 1993 19:04:23 +0300 nelson@crynwr.com (Russell Nelson) writes: > I'd like to see a prefix, of say, "I:" for informative messages, "W:" > for warnings (something is not standard, e.g. COM1 using IRQ 3), and > "E:" for an actual drop-dead error, e.g. trying to mount a MS-DOS > partition as root. I quite agree with this suggestion, although I'd use slithgly longer prefixes ("Info:", "Warning:", and "ERROR:", perhaps). What about making all merely informational bootup messages optional? That would make the bootup screen less cluttered and it would be easier to spot problems. -- Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) It doesn't matter who you are, it's what you do that takes you far. --Madonna ------------------------------ Crossposted-To: comp.os.linux.help,comp.os.linux.misc From: jepler@nyx.cs.du.edu (Jeff Epler) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: Thu, 23 Sep 93 17:09:27 GMT In article <1993Sep23.155008.29374@iitmax.iit.edu> grzyrob@elof.acc.iit.edu (Rob Grzywinski) writes: >I remember back to the days where a new SLS was comming out every three >weeks, the news groups were filled to the point of breaking with new >updates and the project was full speed ahead. Well, I think that the total traffic of the col.* groups put together is about the same as the old col, with maybe a little less noise. But as for new SLS's often, you're confusing one _distribution_ with the OS. The Slackware distribution has been updated (to 1.03? Or some such) just recently. The Debian release is soon to come, and I think I saw a note about the upgrade of Tamu. The kernel is still being enhanced -- pl12 is less than a month old (out of alpha) and pl13 is in alpha. The work on net stuff seems to be proceeding. Wine and Slap are going on "behind the scenes." (Perhaps some of the traffic you're missing has moved to one of the Channels..) > I hope not to start any crap (to put it mildly) with this, but I think >that we (you) have a great product going here and I don't want to see it >dying out. I have introduced at least ten people to the Linux system and >they love it. We wait patiently for a new update and quickly grab it. >We all also dab a little in fixing bugs, but times are tight. It's still going -- I really doubt that anything could hurt Linux at this time, except an possibly the simultaneous destruction of all x86 chips in the world. (Of course, there's the 68K port...) > >I believe that the Wine project is a great idea, and it will get many a DOS/ >Windows user over to the Linux system. I hope also the the dosemu project >will liven up a bit (160+ days since an update!?!?!?) since that will drag >the rest of my collegues over to the system (they can't live without their >Star Wars.) 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... (And just think: In one year's time, CFV on comp.os.linux.games... It should happen!!) What's a computer for besides games? -- Jeff Epler jepler@herbie.unl.edu (Preferred) or jepler@nyx.cs.du.edu ____ "Nuke the unborn gay whales" -- Never seen on a protest sign \bi/ I have no time for petty theft, I have no time for sex, \/ But I have time for what I like, And that is what is best. ------------------------------ From: will@luzie (Michael Will) Subject: PCI: are you thinking about this? Date: 23 Sep 1993 15:00:17 GMT Hello, Are you considering supporting the upcoming PCI-bus-architecture? It does seem to be much more usable than just local-bus, and has some nice features... Interested, Michael Will ------------------------------ ** 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 ******************************