oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest145

From:     Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To:       Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date:     Fri, 9 Sep 94 16:13:12 EDT
Subject:  Linux-Development Digest #145

Linux-Development Digest #145, Volume #2          Fri, 9 Sep 94 16:13:12 EDT

Contents:
  Re: Novell routing between IPX/TCPIP? (Alan Cox)
  Has anyone compiled logdaemon-4.3 login w/skey ?? (James P. Anderson III)
  Future of Linux (Corey Brenner)
  DOOM (Re: 320x200 X resolution?) (Harald T. Alvestrand)
  Re: Future of Linux (Alan Cox)
  Survey: who wants f77,cc,c++,hpf for linux? (Larry Meadows)
  Re: Alpha Linux (Bill Hay)
  rewriting news software (Michael Dillon)

----------------------------------------------------------------------------

From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Novell routing between IPX/TCPIP?
Date: Fri, 9 Sep 1994 09:35:20 GMT

In article <34i23i$9o@nkosi.well.com> cames@well.sf.ca.us (Bob Kaehms) writes:
>Does anyone have any ideas on how I could turn Linux into a router for
>both TCPIP and IPX?  what would it take to get IPX routing available on
>Linux? Buy-in from Novell?  Anyone familar enough with IPX to know whether
>or not this is doable without Novell?

It'll route TCP/IP already. Given a rip/sap daemon for multiple ports it'll
route IPX too. Now as to the RIP/SAP daemon ..

Alan


-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  iialan@www.linux.org.uk   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

------------------------------

From: anderson@zymurgy.bms.com (James P. Anderson III)
Subject: Has anyone compiled logdaemon-4.3 login w/skey ??
Date: 09 Sep 1994 14:49:11 GMT

I keep getting  the following errors when I make linux-skey in the
login directory.  When I try various combinations of defines, i.e.
POSIX_TERMIOS and SYSV I get other errors (related to tty stuff).

login.o: Undefined symbol _getttynam referenced from text segment
login.o: Undefined symbol _getttynam referenced from text segment
../lib/libutil.a(login.o): Undefined symbol _ttyslot referenced from text segment
make[1]: *** [login] Error 1

I'd appreciate hearing from anyone who gotten this package to compile
cleanly on 1.1.49, gcc-2.5.8/gcc-2.6.0 libc-4.5.26.

Thanks,

Jay

--
======================================================
James P. Anderson III         anderson@optical.bms.com
Senior Network Engineer                          N3JMC
Bristol-Myers Squibb Pharmaceutical Research Institute
Princeton, NJ 08543               Work: (609)-252-6039


------------------------------

From: brennerc@saucer.cc.umr.edu (Corey Brenner)
Subject: Future of Linux
Date: Fri, 9 Sep 1994 13:49:01 GMT

Linux on mach is currently being developed by some kind souls using Mach 4
(I believe) as a base microkernel and developing a Linux server for it.

Find more information at http://step.polymtl.ca/~ldd

I was pointed at this page by LDD himself (forget the name, remember the 
initials :) ).

The project is really intriguing and I will hopefully be joining soon... 
hope to see more development along these lines!

Corey Brenner.



------------------------------

From: hta@uninett.no (Harald T. Alvestrand)
Crossposted-To: comp.os.linux.misc
Subject: DOOM (Re: 320x200 X resolution?)
Date: 9 Sep 1994 10:04:14 GMT

In article <CvuCws.9JJ@serval.net.wsu.edu>, a0017097@wsuaix.csc.wsu.edu (Christopher Wiles) writes:

|> : P.S.  DOOM for X exists, and will hopefully be released soon.
|> 
|> Yeah ... fingering help@idsoftware.com reveals the same message re: Linux 
|> port as it has for the last two months: "RSN!! RSN!!"
|> 
No longer, it seems? Today (Fri Sep  9 12:03:44 METDST 1994) it says:

 LINUX: An X version with 16-bit sound is running.  It'll likely
 perform like a dog on mortal systems, but it's very smooth on my
 DX/2 66.  At sunsite.unc.edu:/pub/Linux/Incoming/linxdoom.tgz.
 May be moved.  Remember: it was just for fun and is not supported.
 Do not send e-mail to tech support, please.

Poor sunsite....
-- 
                   Harald Tveit Alvestrand
                Harald.T.Alvestrand@uninett.no
      G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
                      +47 73 59 70 94
My son's name is Torbj<62>rn. The letter between "j" and "r" is o with a slash.

------------------------------

From: iialan@iifeak.swan.ac.uk (Alan Cox)
Subject: Re: Future of Linux
Date: Fri, 9 Sep 1994 09:14:31 GMT

In article <CvJExM.5I@odin.apana.org.au> john@odin.apana.org.au (John Saunders) writes:
>With every body talking the future of Linux, how about this idea.
>We use the Mach microkernel as a base and implement Linux on top of it.
>The new name will be MacLinux and it comes with a free burger!

People are already playing with Linux/Mach. Mach BTW is hardly a microkernel
in size.....

Alan


-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  iialan@www.linux.org.uk   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

------------------------------

From: lfm@pgroup.com (Larry Meadows)
Crossposted-To: comp.lang.fortran
Subject: Survey: who wants f77,cc,c++,hpf for linux?
Date: 7 Sep 1994 22:24:25 -0700

Hello

Given the interest in Linux, I thought I'd post a short survey:

1. Are people interested in a commercial compiler suite for Linux on
   Intel Architecture platforms? The suite would include true compilers
   for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
   High Performance Fortran. C, f77, and C++ could support shared memory
   parallelism (thread-based) if system support is available in Linux.
   HPF would support socket-based communications on networked systems,
   and could support custom interconnects.

2. How much would people pay for such a product [ loaded question ]?

3. What distribution media would be required?

4. Is there interest in accompanying GUI/non-GUI debuggers and
   performance analysis tools?

You can post or send me e-mail:

Larry Meadows
The Portland Group
lfm@pgroup.com

Thanks.

------------------------------

From: wish@dumain.demon.co.uk (Bill Hay)
Subject: Re: Alpha Linux
Date: Thu, 8 Sep 1994 10:16:43 +0000

Albert D. Cahalan (adc@bach.coe.neu.edu) wrote:

> Why drop one? 
> 16 bits = short int
> 32 bits = int
> 64 bits = long

Because an int should be the natural wordsize of the processor and should
therefore be 64 bits.

--
Bill Hay

------------------------------

From: mpdillon@halcyon.com (Michael Dillon)
Subject: rewriting news software
Date: Fri, 09 Sep 1994 01:24:45 +0100

In article <34j2b2$loj@plts.org>, tal@plts.org (Tom Limoncelli) wrote:
> As if there weren't enough already.
> --tal
> 
> 
> Read This Before You Write a Newsreader, News Transport System, etc.
> --------------------------------------------------------------------
>                 By Tom Limoncelli
> DRAFT: Last updated 09/06/94
> 
> This document is not a FAQ.  A FAQ implies that someone asked questions
> and someone else answered said questions.  That's not what this
> document is about.  This document is written because of all the people
> that didn't ask, or didn't know to ask, and got in trouble because of
> it.  People constantly post to the net that they are writing some kind
> of software and in the process of asking other questions they reveal
> that they are doing something else that is, well, stupid.  This
> document attempts to point out common stupid mistakes so that you can
> avoid them.  Wow!  How amazingly useful!  Isn't that nice of Tom?
> Well, actually it's a sad statement on the understanding of netnews
> technology that makes these stupid mistakes are common.  Very common.
> Common enough to make this document useful.  So, this is not a FAQ,
> this is a warning.
> 
> Point #1:
> "I think I'll write a newsreader!"
> Stop.  Stop right there.  I have a suggestion that will save you a lot
> of time:  Go to a movie.  Rent a video.  Volunteer with a local
> first-aid squad.  Feed the homeless.  Just do anything other than write
> a newsreader.  There are enough already.
> 
> "...but I'm going to write one that does something nobody has done before!"
> Yeah, right.  Before you say that, learn nn, trn, gnus, and tin.  Now
> tell me you've thought of something new.  Can you add this new feature
> to one of the old newsreaders?  Yes you can.  Plus, you'll save a
> million sysadmins grief when they have to go and install yet another
> newsreader and figure out how to build it.  It's much easier to isntall
> a updated version of an old newsreader.
> 
> "...well I could, but I really want to make my system stand-alone".
> Then go stand alone in a corner until you've changed your mind.  If you
> don't, you'll spend all of your time writing silly parts like user
> interfaces, figuring out your command structure, getting it to compile
> on every kind of Unix in the world, etc.  Heck, you'll waste most of
> your time just writing the install script.  Really!  Just add your
> feature to some other newsreader.
> 
> For example, a scoring system for articles could be the basis for an
> entire newsreader.  However, by adding this feature to trn (creating
> strn), the author was able to build an entire newsreader with all those
> great trn features, but concentrate on what he considered "fun" (i.e.
> the scoring system).
> 
> Here's another example:  TMNNN was an attempt to make an entirely new
> netnews system where things would be a lot more hypertext'ish.  Rather
> than just add these brilliant ideas to a newsreader (or to C News and
> modify a newsreader to take advantage of the new data), the author
> tried to re-invent the entire newstransport.  The project was never
> completed.  I'm sure the author didn't get to spend much time on that
> part that really interested him either.
> 
> Point #2:
> If you are writing a newsreader or transport from scratch, here's what
> I think the areas of interesting research would be:
> 
> Wait a second, you aren't sure what's a transport and what's a
> newsreader?  Well, that's a sure sign that you shouldn't be writing
> this software just yet.  Much of the work of writing any software that
> interacts with netnews can be avoided if you KNOW THE CURRENT
> TECHNOLOGY FIRST.  Read all the RFC's, install C News or INN once or
> twice.  Install tin, trn, nn, and readnews.  Read the O'Reilly book.
> If anything, read the 2 Usenix papers about C News (same place you'll
> find the C News code) and Rich's Usenix paper on INN (stored where INN
> is stored).  Heck, they're just plain good reading for anyone that
> writes software.
> 
> Point #3:
> If you are writing a newsreader or transport from scratch, here's what
> I think the areas of interesting research would be:
> 
> Advanced user interfaces -- I don't mean Athena Widgets vs. MOTIF vs.
> OpenWindows, etc.  All those damn GUI-based newsreaders add ABSOLUTELY
> nothing to the state of the art... except maybe permitting the
> mouse-generation to access the technically elite Usenet (which, being a
> "More Power To The People" kind of guy, I feel is a good thing).
> However, I think an advanced UI is something that reads news for you.
> Read the Usenix papers on RightPages or Ferret.  Or, how about
> something that lets me post articles in a way that lets me communicate
> better (for some definition of "better").  Something that
> cross-references articles in a way that is more useful than currently
> available.
> 
> Disconnected Mode -- Every pissant BBS user uses QWK and has all sorts
> of fancy QWK newsreaders.  Nobody has invented something as nice as
> this for netnews.  On the other hand, QWK *SUCKS*.  Boy does it suck!
> It is the embodiment of BAD SOFTWARE DESIGN.  It is the best example of
> everything wrong with the way PC software authors create systems.  Why
> not take the idea of QWK (but not the bad implementation) and apply it
> to netnews and you've on your way to fame.
> 
> Better posting -- Wanna be famous?  Make a seriously amazing MIME
> posting tool.  Or, make a idiot-proof, GUI-based, bullet-proof posting
> system that doesn't prohibit you from adding funky headers.  Want real
> fame?  Separate the posting mechanism from the newsreader.  Define an
> interface between newsreaders and newsposters and then make a couple
> newsposters.  Try to get every newsreader to add support to your
> newsposter.  Then we'll hear things like, "I use trn with FreshPost"
> and "Oh, I use trn too but I use MagicPost, it has better MIME
> capabilities".  Fame and fortune await you!
> 
> New storage systems -- Everyone talks about storing netnews in a
> compressed form, as a database, on a special "newsfs" filesystem, etc.
> etc.  Nobody actually implements it.  What's stopping you?  How about a
> storage system that makes expires happen blindingly fast?  INN has
> hooks for this and all INN utilities uses these hooks.  Make the change
> once and all (most) INN code supports it.
> 
> HypertextNews -- Why store quoted text?  Why not just store a code
> which specifies the quoted article and which lines?  Newsreaders that
> support it could let you click on the quoted text and view the lines
> specified, the whole article, or whatever!  Make a system that is also
> backwards compatible and you'll win the nobel prize!
> 
> There are plenty of ideas where those came from.  Please don't just
> write yet another newsreader
> 
> Point #4:
> Never re-invent the wheel.  Why write a text editor when you can just
> call $EDITOR?  (Unless your amazing new feature is a better editor...
> in which case you shouldn't be writing a newsreader, you should be
> writing something that all newsreaders can us be calling
> ${EDITOR:-/your/new/program}.
> 
> Why get bogged down writting tons of NNTP code when you can link to a
> pre-written client library?  NNTP-t5 and INN both generate pre-written
> client libraries that anyone can link to and they do all the work for
> you.  Best of all, they are similar enough that you can write your code
> so that it works when linked to either.  It would be nice if someone
> wrote a library with all the same calls that read everything off the
> disk instead of via NNTP.  Then you could link a NNTP-based newsreader
> to this library and turn it into a non-NNTP-based newsreader.  Why not
> write a new library that checks a flag and reads news via either NNTP,
> the file system, on a special compressed system, or by smoke signals.
> 
> 
> Point #5:
>                           THINGS TO DO OR NOT TO DO:
>                           --------------------------
> 
> USE "MODE READER": When you talk to an NNTP port, the first thing you
> should do is send the command "mode reader".  Pay attention to the
> error messages.  "500" means "I don't know that command" (proceed as
> normal), "200" means "good".  Anything else and you don't want to talk
> to this server.
> 
> USE A PRE-WRITTEN DATABASE: Don't use your own database, use NOV.  Link
> to the NOV library so you don't have to implement any of it.  It does
> all the work for you.  Kill your sysadmin if they want to install tin's
> database,  trn's database, nn's database, etc. (unless you get your
> hard disks for free).
> 
> POSTING: DON'T VALIDATE HEADERS: When the user wants to post an
> article, give them an editor with the minimum headers and accept
> whatever you get back.  If any changes were made, send everything
> verbatuim to "inews -h".  "inews"'s job is to validate the headers,
> insert missing ones, silently delete certain ones, etc.  Don't try to
> do all this work in the newsreader.  Sysadmins often hack their inews
> to add some special feature... don't undo their work or require them to
> re-add this hack to every newsreader they install!  (The NNTP POST
> command is the same as piping to "inews -h" except you must include a
> "From:" header).
> 
> POSTING: DON'T WORK TOO HARD #1: The "inews -h" command requires only
> two valid headers:  "Subject:" and "Newsgroups:".  Don't send it
> anything else (unless the user inserts it him/her self).  For example,
> why figure out how to format the date properly?  The format is very
> specific and if you get it wrong, the transport silently drops the
> article.  Why try at all when you know that "inews -h" generates a
> perfect one for you?  Also, if the user inserts a "Reply-To: foo@bar",
> let them.
> 
> POSTING:  DON'T WORK TOO HARD #2: The NNTP "POST" command reuqires only
> 3 valid headers:  "Subject:", "Newsgroups:", and "From:".  It will
> generate the rest if they are left out.  Don't do the work yourself.
> 
> POSTING:  DON'T GENERATE A PATH HEADER:  Don't generate a Path: header.
> With networks changing so often, it is impossible to generate
> one that is correct for all sites.  Let "inews" or NNTP's "POST"
> command generate it for you.  They will generate it properly
> because they were installed (and maybe modified) by someone that
> understands the site's special configuration.  The person that installs
> the newsreader is often someone different, and is often installed by
> joe loser that thinks netnews was invented 3 months ago when he
> first discovered alt.sex.
> 
> POSTING:  MORE HEADERS NOT TO GENERATE:  When generating a post's
> headers, don't insert the date header, munge the Sender:, From:, etc?
> That is what inews's job.  "inews"'s only purpose in life is to take
> the crap that the user input, add the missing required headers, check
> the output, and reject obviously bad input.  It will send it to the
> spool or post it via NNTP.  Why does everyone think they can out-do
> inews by doing the work themselves?
> 
> NNTP POSTING: DON'T USE IHAVE:  Use the NNTP "POST" command, not the
> NNTP "IHAVE" command.  If you use NNTP's "ihave" command then you have
> done about a week duplicating all the work that inews (or NNTP's "POST"
> command) does, wasted about a week of programming time to get
> everything "just right"... and when someone installs their software on
> an INN server, they'll find that it doesn't work.  Duuuh!
> 
> WHEN YOUR USER IS IDLE, DON'T GENERATE TRAFFIC:  If your user isn't
> typing, mouse'ing, clicking, etc. your newsreader shouldn't be
> generating work for the server.  Imagine 5,000 users all leaving your
> program running when they leave for lunch.  EXCEPTION: If you are
> implementing some fancy read-ahead model, but then you shouldn't be
> reading too far ahead if the user seems to have walked away from their
> terminal, eh?
> 
> IF YOU LOSE YOUR CONNECTION, HANDLE IT TRANSPARENTLY:  Write your code
> so that if your NNTP connection closes you handle it gracefully.  You
> shouldn't go into an infinite loop, or spin in a "open->error->open"
> loop chewing up CPU time.
> 
> WHEN YOUR CONNECTION IS CLOSED, RECONNECT GRACEFULLY:  Write your
> code so that you reconnect without the user being warned a zillion
> times.  Maybe put "Reconnecting to server" in a status line, but
> don't require the user to click on "OK".  Give the user the feeling
> that they always have a connection, even when they are talking to
> a server that disconnects after 30 seconds of idle time.
> 
> WHEN YOUR CONNECTION IS CLOSED, DON'T RECONNECT UNTIL YOU HAVE TO:  If
> your connection closed it was for a good reason.  Either you closed it
> because your user was idle, or the server closed it because it felt
> your user was idle, or maybe the server went down.  Don't reconnect
> until you need to issue your next NNTP command.  Example: If a server
> has 400 connections when it reboots, you don't want 400 clients all
> pummeling it with packets trying to start new connections while it is
> trying to come up.  Plus, when the service is operational again, only
> those connections that are actively used should be reconnecting
> anyway.  If you delay reconnecting until the user needs it, the load on
> the server will be smoothed out since everyone won't be connecting at
> the same time.
> 
> WHEN YOUR USER IS FOR A LONG TIME, DISCONNECT:  If your user is idle
> for more than 5 minutes, why not close the NNTP connection?  If you
> followed the above advice, the reconnect will be seemless and the
> users will not notice.
> 
> WHEN YOUR CLIENT IS FOR A LONG TIME, DISCONNECT:  NNTP servers should
> disconnect if a connection hasn't seen traffic for 5-10 minutes.
> Let the newsadmin set this time limit, and let them disable
> this feature if they need to.  In a perfect world, all newsreader
> disconnect after 5 minutes of idle time, all servers will disconnect
> after 5 minutes of idle time, and all re-connects will be transparent
> to the user.  However, since we don't live in a perfect world, we
> have to do our best to do our share.
> 
> DISCONNECT EVERY 4 HOURS:  Whether idle or or not, disconnect from the
> server every 4 hours.  This lets any file handle leaks on the server
> get flushed out.  If you followed the above advice, your users
> won't notice.
> 
> DON'T GENERATE VANITY HEADERS:  Don't include a header that identifies
> what newsreader the user is using.  Son-of-RFC1036 explicitly states
> that this is A Bad Thing.  If you haven't seen this header before it
> basically looks like: "X-Newsreader: this was posted by a user that
> uses FooReader v33.1 which is the software that I wrote and I put this
> header in because I'm boring and immature and think that I can make
> myself famous by adding this header when it really just shows how
> shallow I am."
> 
> Sorry if this document offended anyone.  Well, not really.
> -- 
> Tom Limoncelli -- tal@plts.org (home) -- tal@big.att.com (work)
> Write to me for info about internet mailing lists on these topics:
> Drew University Alumni/ae, IXO/tpage users, New Jersey Unix Sysadmins' Group
> (like SAGE), New Jersey motss, North East motss, BiNet/New Jersey, and more!

--
Michael Dillon                 Internet: mpdillon@halcyon.halcyon.com
C-4 Powerhouse                  Fidonet: 1:353/350
RR #2 Armstrong, BC  V0E 1B0      Voice: +1-604-546-8022
Canada                              BBS: +1-604-546-2705

------------------------------


** 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
******************************