Subject: Linux-Misc Digest #130
From: Digestifier <Linux-Misc-Request@senator-bedfellow.MIT.EDU>
To: Linux-Misc@senator-bedfellow.MIT.EDU
Reply-To: Linux-Misc@senator-bedfellow.MIT.EDU
Date:     Wed, 18 May 94 18:13:24 EDT

Linux-Misc Digest #130, Volume #2                Wed, 18 May 94 18:13:24 EDT

Contents:
  GNU Hurd Task List and Call for Volunteers (Michael I Bushnell)
  Re: Slackware installation and kernel recompilation (zachary brown)
  Re: [SU PASSWD] Getting a password to SU (Mark P. Nelson)
  Re: Improving Linux performance: What works best? (Hans de Hartog)
  Re: 3C509 (Etherlink III) support (Miguel Blanco Alvarez)
  Re: InfoMagic CD set - WOW! (William Henning)
  Re: Improving Linux performance: What works best? (Stephen White)
  software communists was Re: BRIEF/vi Compatible GUI Text Editor (Kevin B. Fluet)
  Re: Standard Linux GUI (Theodore Ts'o)
  NEC-SCSI & Mitsumi-CD-ROM (Birkenmaier Rainer)
  Re: Learning C++ on Linux? (Jason Merrill)
  Re: Learning C++ on Linux? (Mike Stump)
  Re: Improving Linux performance: What works best? (Matthew Dillon)
  Problem Interrupting Terminal Output (Y. H. Chen)

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

From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
Crossposted-To: gnu.misc.discuss,comp.os.mach,comp.os.linux.development,comp.unix.pc-clone.32bit
Subject: GNU Hurd Task List and Call for Volunteers
Date: 18 May 1994 17:54:47 GMT


Now that the Hurd can run (albeit haltingly) on its own, it is
possible for people who do not have Mach 3.0 single-servers to
contribute without much trouble.  (However, if you don't have a
single-server, you probably won't be able to use a debugger, but that
doesn't mean you can't do debugging, right?)

We at the FSF don't have any expertise in setting up Mach 3.0
machines; the machines that we do development on belong to the Open
Software Foundation and were set up by them.  So one of the things on
the task list is to organize things so that people (like us and most
of you) who don't know how to do it can do it.  It's not impossible to
figure out, it's just a pain and a marvelous thing for a volunteer to
do.

You can get Mach 3.0 from CMU; you get the C library and the Hurd from
us.  You need the soon-to-be-released version 1.07.6 of the C library
and the latest Hurd snapshot (as well as our special version of MiG)
from alpha.gnu.ai.mit.edu.

All our work is based upon i386.  The Hurd (except for a few programs;
see the Hurd README file) is machine independent.  The C library
should not be too much trouble to port.  Ports and information about
porting difficulty for either of these are greatly desired.

The Hurd is not yet self-hosting.  While you are welcome to fetch the
code and put things together, it is not likely that you will have a
useful system right now.  But you might be able to do significant work
(see the task list below).  And, even if you can't do significant
work, I'm interested in hearing about any places where you had
particular difficulty.

If you want to start on one of these tasks, please let me know so I
can keep track of volunteers properly.  This task list will be updated
periodically; gnu@prep.ai.mit.edu always has the latest version.

        -mib

GNU Hurd Task List Version 1.0.

If you would like to work on one of these, please contact mib@gnu.ai.mit.edu.


Mach 3.0 Work

  o Mach 3.0 comes with CMU makefiles that depend on a drecky environment.  
  It would be very helpful to have makefiles and installation stuff so
  that it worked well for cross-compilation between systems and used 
  GNU tools.

  o MiG needs to be made able to support cross-compilation.

  o A replacement for MiG that understood C .h files.

  o Bootstrap tools and documentation to help people set up Mach 3.0
  machines if they already have Linux; if they already have Net BSD;
  if they don't have anything.

  o Mach 3.0 needs to provide support for task virtual timers similar
  in functionality to the Unix ITIMER_PROF and ITIMER_VIRTUAL timers.

  o Mach 3.0 needs to provide a way for users to do statistical PC
  profiling similar to the Unix profil system call.

  o Mach 3.0 needs a facility to automatically send task and thread 
  status on task/thread exit to a port that can only be changed by
  a privileged user; this would be used to implement process 
  accounting.

  o Mach 3.0 needs a facility to find out what task is the parent of
  a given task.

  o Mach 3.0 needs a facility to find out which pages of a task's
  address space are in core to implement Unix's mincore call.

  o Mach 3.0 needs a facility to do msync.

  o Mach 3.0 needs a replacement for MEMORY_OBJECT_COPY_CALL that 
  works at least for the cases needed in ordinary files.  (Write mib if
  you want to know what the problem is and some ideas about how to
  solve it.)

  o Mach 3.0 needs proxy memory objects.  (mib can tell you what these
  are and why they are important.)

  o Mach 3.0 needs a way to do per-task resource counters that are
  accessible to servers called by the task.

  o Mach 3.0 needs facilities to implement resource limits of various sorts.

  o Mach 3.0 needs a way to have a thread's CPU time statistics
  include time spent by servers on its behalf.

  o Of course, free ports are always necessary to machines that don't
  already have free ports.

  o Much work can be done doing research in how to improve Mach VM
  performance and timesharing scheduling policy.


Hurd work (these are brief descriptions; mib can give more information):

  o We need a translator for /dev.

  o We need a replacement for utmp and wtmp that understands the
  Hurd `login collection' concept.  Programs like who and finger
  then need to be changed to use this.

  o We need some existing shell programs changed to do Hurd things:
  like ls, su, fsck, tar, cpio, etc.

  o Some new programs need to be written: login, getty, ps, tools
  for new filesystem features.

  o Shadow directory translators.  (Roland has the beginnings of this.)

  o A system for write, send, talkd and so forth to bleep users;
  this should be integrated with the utmp replacement above.

  o X.

  o A filesystem for /tmp that uses virtual memory instead of disk.

  o Filesystem implementations (using libdiskfs) for other popular
  formats, especially the Linux formats as well as MSDOG.

  o Transparent FTP translator.  
  
  o NFS client implementation.  You should start with BSD's 4.4 code
  and support the extensions they support; don't worry about Hurd
  extensions right now.  (The server we want to write ourselves
  because it will probably involve changing the Hurd interfaces.)

  o A fancy terminal driver that uses readline and supports detach/attach.

--
+1 617 623 3248 (H)    |   The soul of Jonathan was bound to the soul of David,
+1 617 253 8568 (W)   -+-   and Jonathan loved him as his own soul.
1105 Broadway          |  Then Jonathan made a covenant with David
Somerville, MA 02144   |    because he loved him as his own soul.

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

From: zbrown@lynx.dac.neu.edu (zachary brown)
Subject: Re: Slackware installation and kernel recompilation
Date: 18 May 1994 09:00:56 -0400

[extra deleted]
<> 
<>    2) If I compile the kernel included in the D series without changing any
<>    of the defaults, do I get an identical kernal to the one included on the
<>    a series?
> 
> That won't be easy: if there is no config file, the "make" will try to make
> one by asking you questions.
> 
What I meant was:

If, when I make the config file, I just press <enter> to all its questions,
would the compile produce an identical kernel to the one that comes with
Slackware?

In other words, if I just want to change a single aspect of the kernel,
can I press <enter> at each prompt during make config, except for the
prompt that controls the aspect I want to change?

>
>  _______________________________________________________
> | -Alex Freed (The opinions expressed are my own.     |                   
> |             However everyone is entitled to them.)  |                   
> | freed@adobe.com                                     |
>  -------------------------------------------------------


lovitlovit
Linux, the internet, libraries and fire departments are good.




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

From: mpn@alleleb.berkeley.edu (Mark P. Nelson)
Subject: Re: [SU PASSWD] Getting a password to SU
Date: 17 May 1994 17:29:21 GMT
Reply-To: mpn@alleleb.berkeley.edu

Dave Thomas (dave@thomases.demon.co.uk) wrote:


: I've a shell script that starts up DIP/SLIP. It has to be run as
: root.

: I'm looking for a way of running it from non-privileged sessions.
: However,
       
Try chmod 4755 dip

--
Mark P. Nelson (mpn@alleleb.berkeley.edu)
While I'll admit that anyone can make a mistake once, to go on making the
same lethal errors century after century seems to me nothing short of
deliberate.--V.

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

From: dehartog@kwetal.comcons.nl (Hans de Hartog)
Subject: Re: Improving Linux performance: What works best?
Date: 15 May 1994 23:13:16 +0100

Richard Haakma (richard@ricks.ak.planet.co.nz) wrote:
: mlord@bnr.ca (Mark Lord) writes:

: >In article <dhdCpKC40.Cpy@netcom.com> dhd@netcom.com writes:
: >>I have a 486 DX2/66 with 8mb RAM, an UltraStor 34F SCSI controller and
: >>a 1.8GB Quantum SCSI hard disk.  (I also have a 1MB Cirrus Logic video
: >>card, a NEC 4FG monitor, and a BocaBoard 2016 multi-port serial card,
: >>but I don't think any of those are relevent).
: >>
: >>The system is being used as a platform for my original Internet-oriented
: >>online service software.
: >>
: >>When news is being processed through the system, I find that it slows
: >>down to a crawl.  I would like to speed it up.  I'm thinking of one or

I'm using INN on same sort of machine and have no complaints, but ......
I have 16Mb and I'm sure that increasing the amount of memory still will
increase overall performance.

        TANSTATMM: "There Ain't No Such Thing As Too Much Memory"
-- 
 _____________________________________________________________________________
 Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
 Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands 

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

From: miguel@lucy.crs4.it (Miguel Blanco Alvarez)
Subject: Re: 3C509 (Etherlink III) support
Date: 18 May 1994 14:54:18 GMT

In article <2rd7eu$7b6@rbse.Mountain.Net> evanev@Mountain.Net () writes:
>Anyone know if support for 3COM 509 cards (Etherlink III) is being added 
>or under testing, etc...

   Yes, there is, and is not under test, it's fully working. As I'm writing
this, I'm getting files through this card from my PC at litio.quimica.uniovi.es
It's really fast, and it worked without a single problem.

   But you should be better reading the Hardware Compatibility List at sunsite
when you have this kind of questions. There you'll find a better answer (more
complete, I mean).

   Miguel

    Miguel Alvarez Blanco           |  "All that is gold does not glitter,
miguel@hobbit.quimica.uniovi.es     |   not all those who wander are lost."
Temporary address: miguel@crs4.it   |           Bilbo Baggins.


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

From: bhenning@bhami.wimsey.com (William Henning)
Subject: Re: InfoMagic CD set - WOW!
Date: Sat, 14 May 1994 04:07:31 GMT

I am extremely pleased with their service too. I ordered the CD's on Monday,
and received them on Thursday or Friday (I did not check my mail Thursday).
I have not tried the CD's yet, but they sound very good...

Bill

-- 
----
  
bhenning@bhami.wimsey.com   - Linux & OS/2 user at home, OS/2 developer at work

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

From: steve@adam.com.au (Stephen White)
Subject: Re: Improving Linux performance: What works best?
Date: 18 May 1994 01:04:11 -0000

David H Dennis (dhd@netcom.com) wrote:
: I'm using cnews instead of inn because all the great linux wizard words
: say that inn should only be used if I'm getting stuff from a network.

: Any other comments on inn vs C?

Using INN on a UUCP feed here.

No problems at all. INN still uses the standard "rnews" unbatcher, so it
slots straight in with Taylor's UUCP.

Don't worry too much about INN being permanently resident. Most of it gets
swapped out anyway.

I ran INN on a 386/33 with 4MB RAM for a while, and while it thrashed the
disk a bit, it was acceptable.

--
  steve@adam.com.au

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

From: kevin@valis.ampr.ab.ca (Kevin B. Fluet)
Subject: software communists was Re: BRIEF/vi Compatible GUI Text Editor
Date: 18 May 1994 07:07:32 GMT

rob@Cygnus.COM (Rob Savoye) writes:

>  Also to note, is that unlike the rest of Unix, none of the newer versions
>of crisp past 2.2.e (many years old) have the source released. I personally
>don't like the idea of taking all the source of a decent program proprietary.
>A truly free (GPL'd) systems like Linux shouldn't be ruined by "non-free"
>software. (I don't run motif on Linux either)

What utter garbage!  Any time someone releases a commercial product for
Linux, all you software communists come out of the woodwork and whine that
it isn't free.  

There are NO decent word processors for Linux (oh, ok ,EMACS--yeah, right),
and if someone wants to charge for something that does the job right, GREAT!
It makes Linux all the better if commercial apps are supported.  I was glad
to pay $80 for my Uniboard licence (Uniboard is the ONLY decent BBS software
that runs under Linux).  I'll be the first one to snatch up a copy of
Novell's Linux offering.  If it does the job better than the free software
available, why wouldn't I pay a reasonable price for it?  

-- Kevin

============================================================
Kevin Fluet               WorldGate Public Access Internet
kfluet@ccinet.ab.ca       Edmonton, Alberta, Canada
kevin@valis.ampr.ab.ca    modem: (403)444-7685

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

From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: Standard Linux GUI
Date: 18 May 1994 16:21:24 -0400
Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)

   From: aappel@panix.com (Andrew Appel)
   Date: 17 May 1994 13:46:41 -0400

   Is it just me or does anybody else feel that what the Linux (UNIX) 
   community needs is a SINGLE, STANDARD, ONLY ONE, Graphical User Interface 
   (GUI)?  The purpose of a GUI is to reduce the learning curve when moving 
   from application to application in a graphical environment.  Unfortunately, 
   due to the lack of any real (FREE) standards, it is just as aggravating 
   to move between many X applications as it is between most TEXT applications.

   I'd love to see Linux workstations in every home, every office, all 
   across America and the World, but the reality is that Microsoft Windows, 
   Macintosh, and NextStep are all standard GUIs that the average users can 
   figure out.  For those of you who don't understand purchasing in large 
   corporations: "IT IS THOSE AVERAGE USERS, NOT THE TECH WEENIES, THAT ARE 
   MAKING THE PURCHASING DECISIONS!"

Great.  Why don't you write the Singls, Standard, ONLY ONE, Graphical
User Interface, and the try convince everyone to port their programs to
use it.  Bearing in mind, of course, that nearly everyone working on 
Linux is a volunteer, and you can't do things like "do it this way or we
won't give you access to the source code" like they do in commercial
ventures.

For myself, I hardly ever use a GUI since I can type faster than most
people can mouse, so I don't care what the GUI looks like --- as long as
I have a way of getting around it.

It should be noted that NeXTStep has the problem that if you don't like
click-to-focus, go to Hell.  You can't change it.  "And there shall be
one, and only one, GUI".  I dealt with this particular problem by
refusing to do any development on the NeXTStep.....  if you piss off
enough developers, you can very easily doom a volunteer effort.
(Although this case, it's not a problem; everyone will ignore you if you
just rant and rave about how you're commanding everyone to use the some
particular GUI.)

Give it up.  It won't work.

                                                - Ted

P.S.  If you really want to do this, why don't you port all existing
applications that you want to use to a standard GUI, and put together
your own distribution?  That's the Linux Way, and if it's really that
great, everyone will start using it.

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

From: S_BIRKENMAI@rzmain.rz.uni-ulm.de (Birkenmaier Rainer)
Subject: NEC-SCSI & Mitsumi-CD-ROM
Date: 18 May 1994 15:39:23 GMT

Hi Linuxers !!

I've got a little question:

Is there a driver-support for:

- the PCI-to-SCSI bridge from NEC (the quasi-standard for on-board SCSI
  adapers on PCI boards)

- The Mitsumi CD-ROM FX 001 D (the double-speed one)

Is it included in any distribution (I'm especially interested in the
Slackware-Distribution).
If not:
- how can I get the drivers and
- how to install them ???

If possible e-mail me please (I actually have no time to read news
regularely)

Many thanx in advance

Rainer !

--+++<<<< s_birkenmai@rzmain.rz.uni-ulm.de >>>>+++--


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

Crossposted-To: comp.lang.c++,gnu.g++.help
From: jason@cygnus.com (Jason Merrill)
Subject: Re: Learning C++ on Linux?
Date: Wed, 18 May 1994 20:57:15 GMT

>>>>> Sujat Jamil <sujat@shasta.ee.umn.edu> writes:

>> Also, is GCC's c++ compilation really good enough for me to learn c++?
>> I have read, though not understood, about how g++ is still limited
>> compared to 'cfront' (whatever that is -- I gather it is some
>> commercial c++ compiler) but I don't know if this deficiency is
>> anything that I'm going to be frustrated by as I take my first steps
>> at learning the language...

> Is this really true?  Doesn't g++ aim at ANSI C++ compliance?  Could
> someone please comment?

g++ does indeed aim at ANSI C++ compliance.  Of course, it's not there yet.
It's very difficult to be compliant with a standard which doesn't exist,
and there are no C++ compilers which are fully compliant with the latest
working paper.

That said, I don't believe that any of g++'s shortcomings would be a
problem for someone learning C++, unless you're trying to use exception
handling.

(What am I going to say?  "No, we really don't care about the standard,
we'll implement what we damn well please"?)

Jason Merrill
g++ developer

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

Crossposted-To: comp.lang.c++,gnu.g++.help
From: mrs@cygnus.com (Mike Stump)
Subject: Re: Learning C++ on Linux?
Date: Wed, 18 May 1994 21:03:01 GMT

Yes, cfront is limited compared to g++, and yes, g++ is limited
compared to cfront.  They have different sets of bugs.  They both have
bugs.  Both development teams are working to have zero bugs, they are
not done.

Does this mean you shouldn't learn C++?  Does this mean you shouldn't
use a compiler to learn C++, but rather just write code on paper and
pretend to run it in your mind?  I don't think so.  I think one can
use either compiler to learn C++.

Yes, g++ aims at ANSI compliance, so does cfront.

For example, gcc 2.6.0, when released will have the new ANSI C++
boolean data type (bool, true and false).  Will cfront have it by the
time g++ is released?  Probably not.  What if you wanted to learn this
part of C++, or use it?  g++ will offer a slight advantage over cfront
in this respect.

In article <Cq0C45.83G@news.cis.umn.edu>,
Sujat Jamil <sujat@shasta.ee.umn.edu> wrote:
>In article <2rbqlf$i8i@crcnis1.unl.edu>,
>Jeff Epler <jepler@herbie.unl.edu> wrote:
>>
>>Also, is GCC's c++ compilation really good enough for me to learn c++?
>>I have read, though not understood, about how g++ is still limited
>>compared to 'cfront' (whatever that is -- I gather it is some
>>commercial c++ compiler) but I don't know if this deficiency is
>>anything that I'm going to be frustrated by as I take my first steps
>>at learning the language...
>
>Is this really true?  Doesn't g++ aim at ANSI C++ compliance?  Could
>someone please comment?

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

From: dillon@apollo.west.oic.com (Matthew Dillon)
Subject: Re: Improving Linux performance: What works best?
Date: 17 May 1994 22:39:11 -0700

In article <2qo3ka$nlv@bmerha64.bnr.ca> mlord@bnr.ca (Mark Lord) writes:
:In article <dhdCpKC40.Cpy@netcom.com> dhd@netcom.com writes:
:>I have a 486 DX2/66 with 8mb RAM, an UltraStor 34F SCSI controller and
:>a 1.8GB Quantum SCSI hard disk.  (I also have a 1MB Cirrus Logic video
:>card, a NEC 4FG monitor, and a BocaBoard 2016 multi-port serial card,
:>but I don't think any of those are relevent).
:>
:>The system is being used as a platform for my original Internet-oriented
:>online service software.
:>
:>When news is being processed through the system, I find that it slows
:>down to a crawl.  I would like to speed it up.  I'm thinking of one or
:
:Presumably you are already using  inn  rather than  cnews  or  bnews  ?
:-- 
:mlord@bnr.ca   Mark Lord       BNR Ottawa,Canada       613-763-7482

    Get more memory.  I/O bandwidth isn't so important if Linux can cache
    the directory heirachy and history database.  Give yourself another
    8MB of ram (16MB total).  If you are really pushing a lot of news,
    get even more memory :-)

    Personally, I use INN to deal with news.  It's a bit harder to setup,
    but once you've got it up and running it pretty much takes care of 
    itself.  The only thing that takes major CPU on my machine in the news 
    subsystem is when I run mthreads to thread the heirarchy for trn.

    Pulling news generally doesn't take much in the way of resources... it's
    pushing news that takes CPU.  There are two general methods of 
    transfering news with INN:

    (1) Downstream site requests news from you by specifying a timestamp..
        i.e. it wants all news that came in after a certain date.

        Advantages:     You do not need to setup formal news batching for
                        the site, just add the host to your access list.

        Disadvantage:   It plays havoc with your machine because INN must
                        do some major thrashing to figure out what articles
                        to send. (Becomes apparent when transfering a lot
                        of newsgroups)

    (2) You explicitly queue articles to the remote machine.

        Advantages:     Article paths are appended to a dedicated file for
                        the remote machine as news comes in.  INN does not
                        need to search the news heirarchy to figure out
                        what articles to send.  No thrashing occurs, and
                        when the remote host connects, you just shove the
                        pathlist to it.

        Disadvantages:  You have to setup a formal 'link' for each remote
                        machine.

    There are other tricks you can play... if you don't care about wasting
    a bit of bandwidth, you can break up the news batching into smaller
    chunks... i.e. have the remote machines request news more often so you
    do not have to batch so much at a time.  This spreads the load out and
    allows your machine to cache the data better.  For example, if you are
    feeding 10 other machines and have them request news once an hour, the
    relatively small amount of data that is transfered to one machine
    will likely remain in the cache when requested by some other machine.
    On the otherhand, if the machine's only request data once a day, the
    amount of data that needs to be transfered is likely to not remain
    fully cached for other machines to take advantage of, causing it to
    be re-read for each machine.

                                            -Matt

-- 

    Matthew Dillon              dillon@apollo.west.oic.com
    1005 Apollo Way             ham: KC6LVW (no mail drop)
    Incline Village, NV. 89451  Obvious Implementations Corporation
    USA                         Sandel-Avery Engineering
    [always include a portion of the original email in any response!]


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

From: chen@dspark.ece.uiuc.edu (Y. H. Chen)
Subject: Problem Interrupting Terminal Output
Date: 18 May 1994 17:14:16 GMT

I have following Linux problem.  Does anyone out there have
this problem and have it solved ?

PROBLEM:

My problem is that it's hard to interrupt the output display
while I am logining on other workstations.  It is under-
standable that it takes a while for the system to response,
but sometimes the window dies.

MORE INFORMATION

I am using Linux 0.99.14 and XFree86 2.0 on IBM 486SLC2 with
a COMPAQ 1024 COLOR MONITOR and a BOCA SUPERVGA CARD.

Any help or information is appreciated.

Thanks In Advance,
Yong Hua Chen
chen@dspark.ece.uiuc.edu


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


** 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-Misc-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.misc) via:

    Internet: Linux-Misc@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-Misc Digest
******************************
