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:     Tue, 6 Sep 94 21:13:05 EDT
Subject:  Linux-Development Digest #132

Linux-Development Digest #132, Volume #2          Tue, 6 Sep 94 21:13:05 EDT

Contents:
  Re: Mosaic and other TCP/IP problems (Stewart Allen)
  Re: WARNING about shadow-mk package (Mohan Kokal)
  Re: Alpha Linux (Peter Holzer)
  Has ARP been fixed ? (Anders Ostling)
  Re: NOVELL lan driver for linux ?? (Kevin Kitchens)
  Re: IDE Performance enhancement (Patrick Doyle)
  Re: WARNING about shadow-mk package (Larry Doolittle)
  Re: Alpha Linux (Andrew Ukrainec)
  OS/2.99 Boot Manager and LINUX Slackware problems (Tiger II)
  Re: WARNING about shadow-mk package (Viktor T. Toth)
  Help finding iBCS2, and "Screens" software (Dennis McNamara)
  Re: WARNING about shadow-mk package (Joe Zbiciak)
  Re: Linux Inside T-Shirts, Now Printing! (Jim Trocki)
  UMSDOS and New Linux Kernel (Ian V. Quickmire)
  Re: Not all memory seen on Compaq Deskpro M (EISA) (Mark Stockton)
  Re: Future of linux -- the sequel (Donald Becker)
  NET releases and non-8-bit aligned subnet masks (Larry Augustin)

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

From: stewart@oec.com (Stewart Allen)
Subject: Re: Mosaic and other TCP/IP problems
Date: 6 Sep 1994 13:56:55 GMT

Bart Kindt (bart@dunedin.es.co.nz) wrote:

: [Stuff deleted}

: This could be a explanation of problems I am having with SLIPLOGIN.
: The Sliplogin program often 'hangs' after a user has disconnected (e.g. hung 
: up his modem). What happens is that the close(0) call does not return. The 
: next line is the exit(1) command, which should have killed the Sliplogin 
: program, but this line is not reached. The problem is intermittant, and 
: especially seems to occur when there is still some SLIP data going over the 
: line when the connection is broken. I have been trying to find a solution to 
: this problem for months, but no luck.

: Could this be related? What can be done about it? Can I write a work-arround 
: which first flushes the SLIP stuff, before closing?

: Bart.

 This is the same problem I am experiencing if, after 60 idle seconds, the
 close command completes. The definition for this is in the kernel code in
 /usr/src/linux/net/inet/tcp.h and you'll see this vicious hack:

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to sucessfully 
                                  * close the socket, about 60 seconds  */

 I've recompiled the kernel with this value set from 5 to 1*HZ without
 difficulty on uncongested networks. As of yet, I have not experienced
 truly adverse effects... use at your own risk.

--

 -- -  Stewart Allen * stewart@oec.com * 617.562.5826 * FAX 617.562.0038  - -- 
         M.I.S. Manager * Open Environment Corporation * 617.562.0900          
                       25 Travis St * Boston, Ma * 02134                       
 -- - -- - -- - -- "That's my story and I'm stickin' to it"  -- - -- - -- - -- 

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

From: magnus@cegt201.bradley.edu (Mohan Kokal)
Subject: Re: WARNING about shadow-mk package
Date: 6 Sep 1994 15:18:21 -0500


A quick note, 

After going through the earlier posts, I noticed something. 
In my distribution , the current shadow-mk package, I had forgotten
to change the line 
 -$(INSTALL) -c4755 /bin/login 
to be 
 -$(INSTALL) -c4700 /bin/_login
I had instead put in 
 -$(INSTALL) -c4755 /bin/_login 
The perms were all ok in my first release before I had noticed an error in
the Makefile .

Anyhow, please change your /bin/_login and /bin/login programs to have
the following permissions :

   /bin/login    4711        owned by root  [this is the login.secure prog]
   /bin/_login   4700        owned by root  [this is the original login   ]

A new release of the shadow-mk distrib will be uploaded onto ftp.procyon.com
once their server has its problems resolved. They seem to be experiencing
some problems. The new release should hopefully be there sometime this week.

The new release will have the following fixed:

a) permissions for /bin/login and /bin/_login
b) source code will be included for login.secure by J. Zbiciak [installed as 
   /bin/login].

Please email any further questions/requests/whatever to me at any of the 
following addresses :

magnus@cegt201.bradley.edu 
magnus@cs1.bradley.edu 


-- 
Consistency Is Victory. 
magnus@cegt201.bradley.edu                              -Mohan Kokal

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

From: hp@vmars.tuwien.ac.at (Peter Holzer)
Subject: Re: Alpha Linux
Date: 6 Sep 1994 21:27:55 GMT

ukrainec@soma.crl.mcmaster.ca (Andrew Ukrainec) writes:

>In article <ADC.94Sep6123815@bach.coe.neu.edu>,
>Albert D. Cahalan <adc@bach.coe.neu.edu> wrote:

[Anton Ertl:]
>>   >If it will be, I hope
>>   >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.

[Peter Holzer:]
>>   Then you have to drop either the 16 bit or the 32 bit int type. Both
>>   options may make some people unhappy. The 32 bit int is a reasonable
>>   compromise. It also breaks all those programs which assume that a
>>   pointer and an int are just the same thing, which is a good thing IMHO.
>>
>>Why drop one? 
>>16 bits = short int
>>32 bits = int
>>64 bits = long

This is, what OSF/1 does. So `the OSF/1 idiocy' bemoaned by Anton must
be that int is 32 bit instead of 64. If you have 64 bit int and 8 bit
char (I don't think you want to change that) you can have either 16 bit
shorts or 32 bit shorts. You can't have both (unless you invent a new
type like `short short' or `long short'). This means that either the 16
bit or the 32 bit integral type is not accessible from C.

>Another observation: at least according to the K&R C specification, short
>int, int, and long int are not defined to be any specific bit length, and
>can all be equal to same bit length, as a matter of fact.  The programmer
>who writes expecting short int = 16 bits should know that the code will not
>necessarily be portable.

>Therefore, there shouldn't be a problem defining

>short int = 32 bits
>int       = 64 bits
>long int  = 64 bits

>or all of them = 64 bits.  This makes more sense to me than int = 32 bits.

No problem as far as standard C goes. There is a problem with existing
software, however. There are lots of places in a Unix kernel where the
existence of a 2-byte integral type is assumed. If you don't have such
a type you will have problems. If you are lucky you can use 32-bit
integers instead and just waste space. If you are unlucky, you will have
to use a struct or an array of two chars instead and rewrite your code
accordingly. I am quite sure the Deccies had a lot of fun by changing
the size of of two types (long and pointer), especially in networking
code.

        hp
-- 
   _  | hp@vmars.tuwien.ac.at | Peter Holzer | TU Vienna | CS/Real-Time Systems
|_|_) |------------------------------------------------------------------------
| |   | It's not what we don't know that gets us into trouble, it's
__/   | what we know that ain't so. -- Will Rogers

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

From: anos@elmrd6.ineab.ikea.se (Anders Ostling)
Subject: Has ARP been fixed ?
Date: 6 Sep 94 18:41:22 +0200

Hi guys

It seems like the ARP module is broken. It lists all my entries with
completely invalid IP addresses, but correct MAC address. Is somebody
working on this ? Is it solved ? When did it break ?

I'm running 1.1.49 with a ELNK III card.

/Anders

-- 
  +-------------------------------------------------------------------------+
  |                     Internet anos@ineab.ikea.se                         |
  | _  _    Voice +46-42-25 73 08, Fax 25 73 70, Attn: Anders Ostling       |
  |  \  \  \             IKEA Northern Europe AB, Sweden                    |
  | _/ _/ _/                                                                |
  +-------------------------------------------------------------------------+

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

From: cprklk@gsusgi2.Gsu.EDU (Kevin Kitchens)
Subject: Re: NOVELL lan driver for linux ??
Date: 6 Sep 1994 14:50:46 GMT

alberto gaiga (gaiga@c700-1.sm.dsi.unimi.it) wrote:
: Dear Linuxers,
: I have a PC on a NOVELL lan, I would like to use it
: with linux...
: You know... dos is not Uni*!
: Well, the question is this:
:       The novell is attached to Internet,
:               is there a way to let my pc
:               share this link? Can my Pc
:               run linux and use novell to reach
:               the outer world?
: The only way that I can figure is to use another
: PC as MSDOS-SLIP server and attach my machine to it.

: Any help will be appreciated very much.
: PLEASE ANSWER WITH MAIL!!!
: Best regards,Alberto.

PLEASE ANSWER TO THE LIST TOO!!!!

Kevin

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

From: wdoyle@hilbert.coe.northeastern.edu (Patrick Doyle)
Subject: Re: IDE Performance enhancement
Date: 6 Sep 1994 21:54:51 GMT

In article <deuelpm.6.2E6A792D@craft.camp.clarkson.edu> deuelpm@craft.camp.clarkson.edu (Pete Deuel) writes:
:
:
:>About IDE multiple-sector: the rate of a "dd" off the disk doubles when
:>setting 8-sector transfer on the Quantum disk in my machine at work.
:>I did not time the difference in compilation speed, but again it will
:>probably not make so much difference.
:
:I have to think that, if there is to be any noticible speed difference, you 
:really must stick to disk-intensive applications.  I would guess kernel 
:compilation is not THE thing to test this with.

It may not be THE thing to test this with, but it is THE thing I do
most often (at the current time, the kernel I compile most often is
the mach4 kernel, but the principle still applies).  Consequently, it
is THE thing I am most interested in optimizing, not how quickly can I
fill/copy a disk.

-patrick

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

From: doolitt@recycle.cebaf.gov (Larry Doolittle)
Subject: Re: WARNING about shadow-mk package
Reply-To: doolittle@cebaf.gov
Date: Tue, 6 Sep 1994 15:12:11 GMT

Gary Paul Gortmaker (gpg109@huxley.anu.edu.au) wrote:
: doolitt@recycle.cebaf.gov (Larry Doolittle) writes:

: >Either way, I suggest you uuencode login.secure (if it's not an
: >ASCII shell script :-) and post it to these newsgroups.  A lot
: >of people here are competent with unassemblers.

: ...killing a fly with a cannon -- what about strace?  <grin>

I started playing around with strace, hexdump, and gdb,
not to mention string, objdump, and ldd :-).  Note that
strace is inadequate by itself - it doesn't preclude the
possibility of some back door existing that would change
the program's behavior.  I haven't finished going through
it with gdb, but what I have gone through is consistent
with the info posted by Joseph Zbiciak.  e.g., its check
on -h and limiting its arguments, which libraries it
uses, chaining to /bin/_login, etc.  I am unlikely to make
any absolute determination that there are not back-doors,
since it would be more effective for everbody to use a
binary freshly compiled from the posted source.

         - Larry Doolittle   doolittle@cebaf.gov

P.S.  The one thing I could not convince gdb to let me do
is start stepping through the program without a symbol table
loaded.  Is this possible?  What's the trick?  - LD

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

From: ukrainec@soma.crl.mcmaster.ca (Andrew Ukrainec)
Subject: Re: Alpha Linux
Date: Tue, 6 Sep 1994 18:06:54 GMT

In article <ADC.94Sep6123815@bach.coe.neu.edu>,
Albert D. Cahalan <adc@bach.coe.neu.edu> wrote:
>   >|> Alpha is making everything 64 bit clean and this will apply to the EISA
>   >|> drivers.
>
>   >Only if Linux on the Alpha will be a 64-bit-OS. 
>
>   I sure hope it will be. Who wants a 32 bit OS on an Alpha?
>
>   >If it will be, I hope
>   >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
>
>   Then you have to drop either the 16 bit or the 32 bit int type. Both
>   options may make some people unhappy. The 32 bit int is a reasonable
>   compromise. It also breaks all those programs which assume that a
>   pointer and an int are just the same thing, which is a good thing IMHO.
>
>Why drop one? 
>16 bits = short int
>32 bits = int
>64 bits = long

Another observation: at least according to the K&R C specification, short
int, int, and long int are not defined to be any specific bit length, and
can all be equal to same bit length, as a matter of fact.  The programmer
who writes expecting short int = 16 bits should know that the code will not
necessarily be portable.

Therefore, there shouldn't be a problem defining

short int = 32 bits
int       = 64 bits
long int  = 64 bits

or all of them = 64 bits.  This makes more sense to me than int = 32 bits.

-- 
         Andrew Ukrainec                 ukrainec@soma.crl.mcmaster.ca 
          <    (*) >               /  \             < (*)    >           
Communications Research Laboratory      McMaster Univ, Hamilton, Ontario

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

From: robisojf@uc.edu (Tiger II)
Subject: OS/2.99 Boot Manager and LINUX Slackware problems
Date: 6 Sep 1994 21:57:24 GMT

I repartioned my hard drive with OS/2 2.99 and then installed Linux. Now
boot manager says the drive is not formated at all. Any suggestions would
be helpful. Thanks in advance.
   ____________                      _   _ | Address: robisojf@uc.edu
       _/     /                      /   / | Descript: SDA, spelunker
      _/                            /   /  |           Banjo, Guitar            
     _/   /  /--/ /--| /---|       /   /   |           Mandolin, Dobro,
    _/   /  /  / /--/ /           /   /    |           three kids,  
   _/  _/  /__/ /__  /          _/  _/     |           OS/2 Fan, GUI 
             /                                         member, Linux Fan
           _/   "My opinion is expressed as: I'm Mister Cellophane Man."

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

From: vttoth@vttoth.com (Viktor T. Toth)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
Subject: Re: WARNING about shadow-mk package
Date: Tue, 6 Sep 1994 12:31:08

In article <im14u2c.778835074@cegt201> im14u2c@cegt201.bradley.edu (Joe Zbiciak) writes:

>And again:  I do apologize for any inconvenience this may have caused
>anyone.  The shadow-mk package is not insecure.  The login.secure is
>indeed what it was titled.  I do hope that this post lays to rest any
>suspicion about the shadow-mk package, its contents, and its author.
>I also apologize to Mohan Kokal for not realizing that such a small piece
>of code would cause such a large number of people to label him as a
>cheap-and-dirty cracker.  

I have been reading this thread with great interest; first, I became (as did 
many others) concerned about the possibility that code was distributed with 
ill intent (even though I am not presently a user of the shadow-mk package); 
later, I was simply curious as to the resolution of this.

Let me just say something LOUD AND CLEAR: I do *NOT* believe that you have any 
reason to apologize to anyone. There was a sad misunderstanding here; with the 
ever-present threat of viruses, trojan horses, and what not, people have a 
good reason to be concerned; but all YOU did was provide the result of your 
labors for all of us to use and enjoy, for which the least that you deserve is 
our thanks. There is absolutely no reason for you to feel guilty when you have 
contributed good code to the public domain.

I do not believe that the original poster has any reason to feel guilty 
either. He did the right thing; posted a warning to all of us when there was 
reason to believe that code with ill-intent was circulating and executing 
regularly on our machines with root privileges. Unfortunately, no matter how 
tactful you are, this is something that's very difficult to do without 
implicating the author of the code in question.

So anyways, all I meant to say (since it appears nobody else said it) is that 
you should both be thanked by the rest of us.

Viktor


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

From: dmcnamar@netcom.com (Dennis McNamara)
Subject: Help finding iBCS2, and "Screens" software
Date: Tue, 6 Sep 1994 21:51:17 GMT

I'm told iBCS2 is an emulator package to allow SVR4 and XENIX software
to run on Linux. I was told to ftp to tsx-11.mit.edu, but that site
doesn't respond. And Archie at my site couldn't find it.

So does anyone out there know where I can find it? Thanks in advance
for your help.

BTW, I've been calling Linux "Screens" to my friends, emphasizing that
you get 6 full screens, each with their own login and processing
independently, instead of messy "Windows" all on the same screen. I've
convinced a couple Windows die-hards to make the switch to Linux :-)

-- 
Dennis McNamara dmcnamar@netcom.com
Purveyor of Fine Software: Composer's WorkBench,
Instructor at /usr/school, a better way to learn C and Unix. BBS 415-564-8896


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

From: im14u2c@cegt201.bradley.edu (Joe Zbiciak)
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,comp.os.linux.help
Subject: Re: WARNING about shadow-mk package
Date: 6 Sep 1994 17:26:40 -0500

In <im14u2c.778871634@cegt201> im14u2c@cegt201.bradley.edu (Joe Zbiciak) writes:

>>>>>   install -m4755 login $(LOGINDIR)/_login

>>nothing is keeping users from just typing /bin/_login -froot,
>>and exploit the original security hole.... (Permissions should
>>be 744 or something like that)

[snip]

>This is indeed a valid question.  The correct permissions for
>/bin/_login should be either 4500 or 0500, not 4755.  I spoke

[snip]

>I will investigate this situation further.


Here are the results of my investigation:  

The incorrect permissions on /bin/_login were due to a mixup when
updating the shadow-mk package's Makefile to correspond to the 
Makefile from the other shadow release.  

** The 4755 perms do not appear present a security risk, however. **

The original /bin/login will deny any logged in user from using
the -f (username) option if they lack sufficient privledge.  Period.
Indeed, the only reason -froot was a problem was that /bin/login
determined that the "active user" calling /bin/login was indeed root
and therefore had permission to use the -f switch.  Any user, once
logged in, cannot use the -f option unless that user is indeed root.

For those persons interested in verifying this statement, log in
as a regular user and type "/bin/login -f root" or "/bin/login -froot"
and see what happens.  You'll not become root.  The problem was in
rlogin and console logins, where /bin/login was being invoked by
root itself, rather than being invoked as suid-root.  Apparently, the 
old /bin/login uses getuid() instead of geteuid() to determine the 
real user id of the user executing the program.


--Joseph R.M. Zbiciak
  Systems Administrator & Programmer
  Texas Networking Systems, Inc.

DISCLAIMER:  Neither this post, nor any other post made by me, reflects
             the opinions of my various employers, unless EXPLICITLY
             stated.  All opinions stated herein are mine unless otherwise
             noted.


                                          := Joe Zbiciak == im14u2c@ =:
                                          :- - cegt201.bradley.edu - -:
        If it works, Don't fix it.        : -  camelot.bradley.edu  - :
                                          :-Finger for PGP Public Key-:
                                          :===========================:

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

Crossposted-To: aus.computers.linux,alt.linux.sux,alt.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
From: trockij@cyanamid.com (Jim Trocki)
Subject: Re: Linux Inside T-Shirts, Now Printing!
Reply-To: trockij@cyanamid.com
Date: Tue, 6 Sep 1994 17:28:31 GMT


In article ac@drasnia.it.com.au,  jean-paul@drasnia.it.com.au (Jean-Paul Chia) writes:
>
>Well.. The GNU Generation is just text, because the cost to print the pciture 
>of it would be around $28 US. Unless you really like the picture, and you really
>really want the picture version, then mail me, and maybe I can print a few.
>Anyways, Here is the Linux Inside one, I can't seem to find the GNU one. :)
>I'll post it ASAP..
>Thank you.
>- JP
>

  It's a little late, but here's a motto:

   "make config; make dep; make clean; make zlilo, not war."     :-)





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

From: ianq@hookup.net (Ian V. Quickmire)
Subject: UMSDOS and New Linux Kernel
Date: Tue, 6 Sep 1994 18:40:41

Yes, I am one of those using UMSDOS with Linux 1.0.0 mainly for test purposes. 
However, I have it running, have my config done, and have X up and running, 
and don't really want to have to start over again using another FS.

My question is:

To upgrade my kernel from 1.0.0 to the latest stable version, is UMSDOS now an 
integral part of Linux code, or will I be unable to keep up with patches while 
using UMSDOS?

If I want to upgarde, do I need UMSDOS patches as well, and are they keeping 
up with Linux development?

Thanks much ...



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

From: marks@schooner.sys.hou.compaq.com (Mark Stockton)
Subject: Re: Not all memory seen on Compaq Deskpro M (EISA)
Reply-To: marks@schooner.sys.hou.compaq.com
Date: Tue, 6 Sep 1994 21:40:23 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <3478e2$m45@Athena.McRCIM.McGill.EDU> panisset@CIM.McGill.CA (Jean-Francois Panisset) writes:

: >I have a Compaq Deskpro 486/33M, which is an EISA bus machine with the
: >processor on a card. The machine has 20M of RAM, which is happily seen
: >by the power-on test, the EISA diagnostics/setup disk and
: >DOS. Unfortunately, neither the 1.0.8 nor the 1.1.49 kernels see more
: >than 8Mb of this memory.

: The kernel gets the amount of memory by calling INT 15H, function 88H,
: before going into protected mode.  This function should return the
: "number of Kbytes of extended memory".  Probably the problem is somewhere
: here...

: In the past, there was an option "mem=xxxx" to override the amount of
: memory, which was necessary for systems with more than 64M.  However,
: now that I look in the 1.1.49 sources this is no longer there :-(

: Rob
: -- 

I haven't seen any systems limit RAM to 8mb.  However, we've successfully
gotten systems to recognize more than 16MB by editing 
/usr/src/linux/init/main.c and hardwiring the value of memory_end. 

   was: memory_end = (1<<20) + (EXT_MEM_K<<10);
   now: memory_end = 20*1024*1024;

Also, verify that memory is configured for linear mode in your EISA
configuration.

MarkS
--
Mark Stockton
marks@schooner.sys.hou.compaq.com

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

From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
Subject: Re: Future of linux -- the sequel
Date: 6 Sep 1994 15:39:26 -0400

In article <34esks$n4a@rs18.hrz.th-darmstadt.de>,
Joachim Schrod <schrod@iti.informatik.th-darmstadt.de> wrote:
>In article <CvMKy4.3Bz@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) writes:
>> In <34d4t0$2c22@yuma.ACNS.ColoState.EDU> pyeatt@cervesa.cs.colostate.edu (Larry Pyeatt) writes:
>> 
>> >In article <348vsp$68c@cesdis1.gsfc.nasa.gov>, becker@cesdis.gsfc.nasa.gov (Donald Becker) writes:
>> >|> >                                        $6400 minumum
>> >|> 
>> >|> That's just way more than a reasonable Linux box will cost.
>> 
>> >Define "reasonable."  I defined reasonable to be "something similar to
>> >SGI Indy.  You can't get that sort of performance with cheap parts.
>> 
>> Hey come on, he explained how all prices that added up to that $6400
>> were way above current street-price for PC parts.
>
>Yeah, but he used $33 Ethernet cards (I assume NE2000s) and explained
>that 4MB is enough to run Linux+X and compared these parts to
>respective workstation equipment. IMHO that disqualified him.

No, that's not what I posted.

I pointed out that with Linux you have the option of using $30 ISA ethernet
adapters or $12 monochrome video adapters if those parts of the system don't
matter to you.  But  I was assuming that a reasonable system would have at
least one (perhaps two) 32 bit bus-master ethernet adapter and an
accelerated video adapter.  Not that these would cost a lot more: in the PC
world you can get an excellent PCI or VL adapter based on a AMD chip for well
under $100 (VL:$64 and PCI:$69), and get a 5 year warranty with it.

I also stated that the disks and memory were essentially the same for both
systems, implying that I assumed identical configurations. I wasn't assuming
a 4M memory system, just pointing out that I had done real work in Linux
with 4M.  Linux+X works well in 8M, while I doubt the SGI would even boot on
an 8M system.

>As an example, I'm currently thinking about upgrading my 16MB to 32MB
>since it's not enough for serious work. The AIX system at work is
>already short at memory with 32MB, 64 or 128 MB would be fine. How
>can I put 128 MB in my VLB PC? That's the reality I'm living in, and

Errr, 128M in a PC?  Well, buy it. Most motherboards on the market today
support 128M.  What? You old 386SX in the closet doesn't?  Well, that's not
the strawman we are talking about, is it?

>I suppose Larry has a similar environment. I was even astonished that
>he listed only a 400 MB disk, I wouldn't buy anything below 1 GB.

The best $/MB in the market right now is on a 540M E-IDE disk.  The next step
up is a 1M SCSI disk.  Either is fine, and less expensive than the DRAM.

>On the other hand, might be that peripherie prices in the US are
>really as low, I would love to have a `nice' 17" monitor (i.e.,
>one that has ca. 80 kHz, 135 MHz, Trinitron if possible) for $ 850.
>But I suspect that Donald's term `nice' is simply a different one than
>mine.

"Nice" is the 21" Viewsonic on my desk at work.  But my 14" generic monitor
at home is also "nice" because it displays a sharp 1024x768 without taking
up the whole desk.  It's all in what you like -- I find I prefer the smaller
screen in text mode when I'm hacking code.

-- 
Donald Becker                                     becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882         http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html

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

From: lma@dayton.Stanford.EDU (Larry Augustin)
Subject: NET releases and non-8-bit aligned subnet masks
Date: 6 Sep 94 22:34:51 GMT

A (hopefully) quick question.  Which versions of Net and the kernel
support non 8-bit aligned networks/netmasks?  I couldn't find any
mention of this in the FAQs.

Thanks,

Larry


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


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