Subject: Linux-Misc Digest #803
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:     Sat, 12 Mar 94 23:13:08 EST

Linux-Misc Digest #803, Volume #1                Sat, 12 Mar 94 23:13:08 EST

Contents:
  Re: Filenames on Sunsite (Erik Troan)
  Re: Linux and Tapestreamer (Michael Will)
  Re: You're an idiot!!!! (rm -fr /usr) (Michael Will)
  XMETER Wanted!! (Brad Cain)
  tcp wrapper (Brad Cain)
  Re: ex2fs / xiafs: File System Stability (Stephen Tweedie)
  Info on chosing PC UNIX(summary) (Estella Pok)
  Re: "Reverse-engineering" (Alasdair Grant)
  Re: "Reverse-engineering" (John F. Haugh II)
  Re: SoftPC/Linux? (John F. Haugh II)
  Re: File System for Both (Michael L. VanLoon)
  DEC PCI motherboards (Elan Feingold)
  Re: Upgradability? (Charles Hedrick)

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

From: ewt@sunSITE.unc.edu (Erik Troan)
Subject: Re: Filenames on Sunsite
Date: 12 Mar 1994 18:38:44 GMT

In article <1994Mar5.205800.13706@thelake.mn.org>,
Steve Yelvington <steve@thelake.mn.org> wrote:
>
>I've noticed a lot of filenames on sunsite.unc.edu of this form:
>
>             xpaint2.1.1-linux.tgz
>
>The .tgz ending is fine for programs that are going to be stuffed into a DOS
>file system, but this filename obviously isn't DOS-compatible, so why use
>.tgz when you mean .tar.gz?
>

One good reason is to keep sunsite's INDEX files looking sane. Any file
names of more then about 20 characters screw up the columns.

Erik

-- 
===========================================================================
"I'm not like that -- except when I am"   ewt@sunsite.unc.edu  = Erik Troan
                                          sasewt@unx.sas.com
    - Nora from "Pump up the Volume"

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

From: michaelw@desaster.sunflower.sub.org (Michael Will)
Subject: Re: Linux and Tapestreamer
Date: Tue, 1 Mar 1994 02:35:32 GMT

spring@diku.dk (Jesper Honig Spring) writes:
>Is it possible to use a tapestreamer under Linux and if so
>which products, brands, is "worth" buying for this purpose.
If you can afford I would recommend SCSI-tapes rather than 
floppy-streamer-tapes - it is faster, reliable (and that is
what is important on backups, mind you :-) ) and exchangable.

I once wrote on a SUN in a 120MB-Drive at a 525-MB-Tape-cartridge
about 100MB, took it home, and had no problems at all reading it.

I use a Wangtec-5525ES-tape which backs up my 400-something-MB
without trouble, quite fast...

>Is there any tapestreamer applications available for linux/X.
I do not know of any. 

I use "tar" to backup, "mt" to position the drive.

The devices are /dev/nrmt0 for nonrewinding-magnetic-tape or the like
and /dev/rmt0 for automatic-rewinding-magnetic-tape, it rewinds after
every action, I do not use it.

Cheers, Michael Will
-- 
Michael Will <michaelw@desaster.sunflower.sub.org>   Linux - share and enjoy :-)
Life is not there if you can't share it...        Hazel'O'Connor  Breaking Glass
Happily using Linux 0.99p15e with X11R5, \LaTeX, cnews/nn/uucp/TERM and:     PGP!
                         Analysis ist "kleiner Epsilon".

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

From: michaelw@desaster.sunflower.sub.org (Michael Will)
Subject: Re: You're an idiot!!!! (rm -fr /usr)
Date: Tue, 1 Mar 1994 02:45:43 GMT

gene@insti.physics.sunysb.edu (Eugene Tyurin) writes:
>One graduate student in our group by mistake erased ALL contents of
>his home directory including the programs he wrote for 6 month for his
>research. And the most sad and important: SGI Irix doesn't give a shit
>about Ctrl-C or Ctrl-Z pressed while rm does its dirty job. :-(
6 months of research without backup? He is an idiot.

Cheers, Michael Will
-- 
Michael Will <michaelw@desaster.sunflower.sub.org>   Linux - share and enjoy :-)
Life is not there if you can't share it...        Hazel'O'Connor  Breaking Glass
Happily using Linux 0.99p15e with X11R5, \LaTeX, cnews/nn/uucp/TERM and:     PGP!
                         Analysis ist "kleiner Epsilon".

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

From: brad@bach.udel.edu (Brad Cain)
Subject: XMETER Wanted!!
Date: 11 Mar 1994 12:56:21 -0500

Has anyone been able to compile xmeter under linux??

If so, can you please tell me where I can get the binaries
(or, send them uuencoded)



-- 
****************************************************************************
brad@ravel.udel.edu            Brad Cain                               N3NAF
cain@snow-white.ee.udel.edu    University of Delaware Electrical Engineering

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

From: brad@bach.udel.edu (Brad Cain)
Subject: tcp wrapper
Date: 11 Mar 1994 12:57:04 -0500

Has anyone ported a tcp wrapper to linux??



-- 
****************************************************************************
brad@ravel.udel.edu            Brad Cain                               N3NAF
cain@snow-white.ee.udel.edu    University of Delaware Electrical Engineering

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

From: sct@dcs.ed.ac.uk (Stephen Tweedie)
Subject: Re: ex2fs / xiafs: File System Stability
Date: Thu, 10 Mar 1994 18:03:57 GMT

Hi all,

In article <tgmCMG7Es.1uo@netcom.com>, tgm@netcom.com (Thomas G.
McWilliams) writes:

> Robert Sink (sinkr@universe.digex.net) wrote:
> : Hello all - I was wondering if anyone could comment on the stability that 
> : Linux offers running the ex2fs and/or the xiafs file systems?  Do they tend
> : to operate well under pressure, etc?

> In the strictest sense the xiafs is more stable. The code has been
> essentially frozen for over a year with no ill effects. The ext2fs is
> still under development.

Depends on what you mean.  "Stable" doesn't mean bug-free, it can mean
"no longer under development".  I've fixed a ext2fs race conditions in
the past which were also present in xiafs, but despite my mail, the
xiafs problems never got fixed.

Ext2fs is actively maintained.  There are things which the developers
are doing to improve the filesystem, and future projects include file
undeletion and access control lists.  However, the current core
filesystem code is *extremely* stable.

Ponder this --- the last significant bug fixed turned out to be in the
Linux VFS core, not in the ext2fs itself.  Bug reports have been
regurlarly trickling in about the "bit already cleared" bug in ext2fs
since its release, so the bug was attributed to ext2fs itself.  It
turns out that this attribution was only due to the greater popularity
of ext2fs rather than to its "stability".  (By the way, I accept that
this popularity is more a result of SLS's original preference over
xiafs rather than because of any rational choice between the two.)

> ...  there seems to be a problem with the ext2fs recovery tools.
> Hardly a fortnight passes without some ext2fs tale of woe where the
> recovery tools only have made matters worse.

... and on inspection most of these turn out to be solved in later
versions of e2fsck.  In particular, Ted Ts'o's new ALPHA e2fsk is
being migrated into the regular e2fsprogs distribution, and it is far
faster and more robust than _any_ of the other fscks available for
other Linux filesystems.  xfsck has never been able to deal correctly
with half of the corruption modes which e2fsck tackles.

> However, I suspect that many times the ext2fs problems are due to
> operator error or hardware problems and are not a direct reflection
> on the safety of the ext2fs.

Well said.  You don't know the half of it. :-)

> The xiafs was designed primarily to provide a stable, safe file
> system by leveraging pre-existing debugged code. It provides the
> basic most wanted features without complexity. The ext2fs has
> been geared toward more features and expansibility. The ext2fs
> is more complex and ambitious.

True, ext2fs _is_ more complex and ambitious.  It also offers better
performance, and a couple of performance tuneups in pl15 increase its
margin over xaifs.  That does _not_ mean it is not robust; I have
spent a very great deal of time testing ext2fs, and as far as I know
it is perfectly reliable.  It is certainly better at digging itself
out of a hole after a crash than xiafs is.

Remember, though, that I'm an ext2fs co-developer, so I might just
conceivably be a tiny bit biased. :-)

Cheers,
 Stephen.
---
Stephen Tweedie <sct@dcs.ed.ac.uk>   (JANET: sct@uk.ac.ed.dcs)
Department of Computer Science, Edinburgh University, Scotland.

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

Crossposted-To: comp.unix.sysv386,comp.unix.pc-clone.32bit
From: pok@tiger.vill.edu (Estella Pok)
Subject: Info on chosing PC UNIX(summary)
Date: Sat, 12 Mar 1994 17:39:47 GMT

Hi Net:
        I posted a question on searching PC Unix early and I received kindly
help from many folks on the net. I appreciated those people who helped
and would like to share the info I got with the net. Any one who is
interested in getting some infomation on chosing PC UNIX can drop me
an email, I'll happy to send it to you. By the way, Tom Svaleklev
(tsva@ineab.ikea.sa?), I couldn't send the info you wanted becuase my
mail system complained about your address.

Estella Pok

Internet: pok@tiger.vill.edu or pok@monet.vill.edu

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

From: ag129@ucs.cam.ac.uk (Alasdair Grant)
Subject: Re: "Reverse-engineering"
Date: Thu, 10 Mar 1994 18:25:25

In article <1994Mar8.170350.1@vaxc.stevens-tech.edu> p1nadeau@vaxc.stevens-tech.edu writes:
>        Nobody is going to be researching advances into IBM compilers in 
their>free time. "Lots 'n' lots" of people will be researching Gnuware in 
their free>time. The idea is that the free time of us commie programmers far 
exceeds the>paid time of those IBM deckslaves.

You seem to have little idea of what is involved in "research".  I can't
remember if Chaitin won the ACM Turing award (computer science's top
annual award), but Backus did, to name two of IBM's compiler developers.
The number of people who are capable of improving GCC's parsing or code
generation is far, far, smaller than the number of its users.

>        In "The Mythical Man-Month", Fred P. Brooks puts forth some axioms 
of>software engineering he learned after managing the OS/360 project at IBM. 
As>you may or may not know, OS/360 was the kind of big-time commercial bone-
headed>blunders that IBM is so famous for and that would NEVER happen with a 
labor of>love like Linux.

OS/360 was a massive success, technically _and_ commercially.
OS/360 is probably what's driving your payroll (if you work for a 
living, which I doubt).  OS/360 was so advanced that modern microkernels
and RISCs have more in common with it than with PDP-11s, Vaxes, BSD Unix
and suchlike.  People have claimed innovations for RISC that have been 
in OS/360 all along (some people seem to think that all early computers
looked like a Vax).

Also, top managers don't write books about their failures!

>        Some of the postulates state that informality increases productivity.
>The best debugging takes place after-hours in a machine room, where the
>programmers can relax despite the large amounts of caffeine present simply
>because the 9-to-5 pressure is off. In the FSF paradigm, software is developed
>in a COMPLETELY informal environment, becoming formal only after the maintainers
>of the code freeze a release.

Really?  What about Linux changes made hurriedly as a result of 
breakages in production environments?  Or are you saying Linux works
100% correctly in production environments?

>        Another suggestion made by Brooks is that programmers be given a
>"playpen" area to fool with their code before its sent to the integrators. The
>size of the "playpen" for any given FSF project is astronomical compared to the
>tiny little development labs of IBM.

In size but not variety.  The fact that Linux doesn't support MCA, and
doesn't talk AppleTalk or NetWare, just shows how limited the scope of
most peoples' "play" really is.  IBM (or Microsoft or Novell) don't
test things on a few thousand Dell 386s; they get lots of different
stuff, plug it all together, and fix the bits that break.

Incidentally, which IBM development labs have you been to?

>        Brooks also shows that the more communication necessary between members
>of a software development team, the more time will be wasted and the bigger
>chances for a SNAFU. Figures show that the average amount of time a software
>engineer spends on spec/design/code/test is roughly HALF his working hours, the
>other half going to all those boring meetings and phone conversations. 

Well I may be stupid but I don't pretend to complete superiority.  
Even when the software I'm working on is "mine", conversations and 
discussions with colleagues and users are what makes it meet their needs.  
If you choose Linux as the strategic operating system for a million 
dollars' worth of hardware (plus whatever as yet unknown hardware you 
are going to replace it with in 3 years' time) you don't just throw 
it in and hope for the best.

>Statistically, once the initial work on a project
>is done, the fastest progress is made by flying through the spiral as fast as
>manpower allows. The inference is obvious.

So when can we expect Linux v1.0?

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

From: jfh@rpp386 (John F. Haugh II)
Subject: Re: "Reverse-engineering"
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Date: Fri, 11 Mar 1994 01:42:20 GMT

In article <tgmCMG1vp.JoM@netcom.com> tgm@netcom.com (Thomas G. McWilliams) writes:
>But the error in this line of reasoning is assuming that authors of
>GPL software are motivated by charity. I say GPL authors are 
>motivated by economic self-interest. Unfortunately most people
>have a limited concept economy, usually limited to some visible
>exchange involving money. But real life involves many economies
>where the choices and gains (or loss) are more subtle. The
>restricted sense of economics usually applied to discussions of
>the GPL are analogous to attempting to do mathematics without
>the irrational numbers or the concept of zero. You can only take
>the discussion so far. Economics and individual choice often
>have no direct correlation with any monetary fee at all.

I've made no such assumption about GNU contributors.  In '89 when
I originally approached the FSF about putting Shadow under the GPL
I did so because I wanted Shadow to be fairly widespread.  There
were a number of reasons I eventually chose not to do so, and none
of those had anything to do with charity.  Likewise, when I 
recently posted the GNU Shadow Password Library, it was done for
the same reason as the first time -- to make sure that Shadow is
widely available and widely used.

That I don't have "charity" in mind does not negate the fact that
Cygnus benefits from things which are "given" to them.

As for your claim about various and sundry "subtle" forms of
economics, I am a professional programmer.  I write operating
systems for a living.  Expecting me to =stop= writing operating
systems and start being a CD-ROM distribution company is quite
unrealistic.  As for companies like Cygnus, their continued
existence is only proof that people with creative imaginations
haven't bothered to really screw them just yet.  Try figuring out
how Cygnus is going to make money doing bug fixes when some customer
decides to resell (or give away for free ...) those bug fixes.  Now
how do you expect Cygnus to make its payroll?  More of these creative
non-monetary economic principals you're thinking of?
-- 
John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: jfh@rpp386.cactus.org
 There are three documents that run my life: The King James Bible, the United
 States Constitution, and the UNIX System V Release 4 Programmer's Reference.

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

From: jfh@rpp386 (John F. Haugh II)
Subject: Re: SoftPC/Linux?
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Date: Fri, 11 Mar 1994 01:48:07 GMT

In article <1994Mar10.122328.14006@wubios.wustl.edu> david@wubios.wustl.edu (David J Camp) writes:
>In article <1994Mar9.214309.67781@yuma> jmiller@terra.colostate.edu (Jeff Miller) writes:
>>Seeing how SoftPC runs reasonably well on Suns and Macintoshes, how hard
>>would it be for Insignia to make a PC emulator for the PC over Linux? I
>>think a product like this would bring Linux the compatibility it needs,
>>and the following it deserves.
>>
>>I could then format my drive and make one big Linux partition :)
>
>There is a product called "Locus Merge" that does this quite well.  I
>am not certain if it has been ported to Linux.  -David-

It's actually called "DOS Merge" and most likely hasn't been ported
anywhere near Linux.  LCC is a commercial venture and they don't make
no money giving software away ...
-- 
John F. Haugh II  [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ]   @'s: jfh@rpp386.cactus.org
 There are three documents that run my life: The King James Bible, the United
 States Constitution, and the UNIX System V Release 4 Programmer's Reference.

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

From: michaelv@iastate.edu (Michael L. VanLoon)
Crossposted-To: comp.unix.bsd
Subject: Re: File System for Both
Date: 11 Mar 94 04:29:59 GMT

In <2lom94$7tc@news.nynexst.com> hjl@nynexst.com (H.J. Lu) writes:

>David J Camp (david@wubios.wustl.edu) wrote:
>: Is there a filesystem that works under both Linux and BSD?  I would
>: like to develop both on the same system without deleting my code each
>: time.  -David-

>I think both Linux and xxxxBSD can mount the floppy DOS filesystem. But
>I am not sure if the xxxxBSD can mount a DOS partition on a hard drive.
>Linux is fine.

NetBSD can do both.

I wouldn't want to mangle my files through DOS if they were important,
however.  If Linux can't do Berkeley FFS, it might be something to
consider adding.

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 Michael L. VanLoon                 Iowa State University Computation Center
    michaelv@iastate.edu                    Project Vincent Systems Staff
  Free your mind and your machine -- NetBSD free Unix for PC/Mac/Amiga/etc.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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

From: elan@tasha.cheme.cornell.edu (Elan Feingold)
Subject: DEC PCI motherboards
Date: 11 Mar 1994 03:07:43 GMT
Reply-To: elan@tasha.cheme.cornell.edu (Elan Feingold)


Anyone try Linux with any of the DEC PCI motherboards with any success?
Just curious, as I will be an employee soon, so I could obtain one cheaper...

Thanks, 

elan

--
===========================================================================
|  Elan Feingold       |                                       |
|  CS/EE Depts.        |                          |
|  Cornell University  |     ( .sig currently under construction )     |
|  Ithaca NY 14850     |                        |
===========================================================================

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

From: hedrick@heidelberg.rutgers.edu (Charles Hedrick)
Subject: Re: Upgradability?
Date: 12 Mar 94 20:40:53 GMT

rhung@physics.ubc.ca (RYAN HUNG) writes:

>I'm waiting for the release 1.0 of the Linux kernel before I install
>Linux.  However, I've been wondering: considering the rapid rate of change
>in Linux, how easy is upgrading?  Say, for example, there were a kernel
>upgrade.  Do distributions usually provide upgrade packages that can run
>quick and easy?  Or is a lot of hacking necessary?

This depends entirely upon what sort of upgrades you want to do.  I
use the distribution only as a way to bootstrap, and then upgrade
pieces as appropriate.  This makes sense if you follow these newgroups
and have reasonable access to the net.  Then every month or two you
can spend an evening applying update.  If you don't want to follow the
newsgroups, then you'll have to depend upon the procedures supplied
with the distribution you're using.  I can't comment on that, as I've
never done an update that way.  (I've used Linux since its first
public release, and have updated incrementally in a continuous manner.
I've never installed a distribution on my home system, though I've
used one on a system at Rutgers.)

In order to do kernel upgrades yourself, you need to keep up to date
on the kernel, gcc, and libc.  You don't need every release of gcc and
libc, but you can't fall too far behind.  All three of things things
(kernel, gcc, and libc) involve retrieving fairly large (order of 1
MB) compressed tar files, and installing them.  There are typically
about 3 files (you want things like binutils that are released with
gcc, and libc releases may advise you to take a new ld.so).

For gcc and libc installation is pretty straightforward: the main
procedure is cd to root and untar the file, though there is one other
thing necessary to get the symlinks right.  There are detailed
installation instructions in the release notes.

The kernel requires you to delete your existing /usr/src/linux, untar
the kernel distribution file in /usr/src (it creates a directory
called linux), make config, answer questions about your configuration;
make depend, and make (or perhaps "make zlilo" if you want the make
command to install the new kernel for you).

Once you've done one of each kind of upgrade (kernel, gcc, libc), it's
fairly straightforward.  Beyond these things, now and then you'll want
to upgrade other utilities, as you see announcements of things that
look interesting.  But there's no need to be compulsive about this --
Linus and the libc maintainers do a good job with upward
compatibility.  Old programs will continue to work, except in unusual
cases (and I think those cases are getting more and more rare).  I'm
still using things that are over a year old.

If you want to keep up with the alpha micro-releases of the kernel,
you can use diffs.  There is a diff from each edit to the next, so you
just apply those with patch and then type "make clean; make depend;
make zlilo" or some variation on that.  (You may need "make config" if
the configuration file has been changed by a patch.)

In none of these cases should any "hacking" be required, though if
your setup doesn't exactly match the expectations of whoever wrote the
release notes, you may need to figure out where to put a symlink, when
you have to delete an existing file, or something like that.  (Of
course that might be what you mean by "hacking".)

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


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