Subject: Linux-Development Digest #297
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Wed, 12 Oct 94 19:13:07 EDT

Linux-Development Digest #297, Volume #2         Wed, 12 Oct 94 19:13:07 EDT

Contents:
  Re: FTP slowdown under 1.1.52 with hdparm on (Shaune Beattie)
  Mounted floppy BECOMES read-only for no reason! (Joel M. Hoffman)
  FS resource forks, to be or not to be?(Was: ext2fs vs. Berkeley FFS) (David Jeske)
  Linux SLIP interactive response (John Richardson)
  Re: X-Windows support Weitek Power 9000? (Peter Benschop)
  Re: ext2fs vs. Berkeley FFS (David Jeske)
  Re: Kernel 1.1.53 - no BOOM (Andries Brouwer)
  Re: PGP for Linux?? ("Brian E. Gallew")
  3c505 driver ? (Zheng Huang)
  hdparm - does it work? (Was: Re: FTP slowdown under 1.1.52 with hdparm on) (Mark D. Roth)
  Re: Linux Mud (Gordon Chan)
  Re: ext2fs vs. Berkeley FFS (Joe Smith)
  Re: A badly missed feature in gcc (Dan Pop)

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

From: [email-masked] (Shaune Beattie)
Subject: Re: FTP slowdown under 1.1.52 with hdparm on
Date: 12 Oct 1994 17:28:41 GMT

Mark D. Roth ([email-masked]) wrote:
: Here are some figures I got, which I found to be fairly consistant:

: multcount     user    system  clock   %CPU
: 0             0.21    20.69   0:46.74 44.7
: 2             0.34    21.53   0:47.69 45.8
: 4             0.37    18.75   0:49.94 38.2
: 8             0.37    11.90   1:10.54 17.3
: 16            0.29    12.37   1:10.55 17.9

: I'd rather have the wall-clock time, personally... :)

I got even worse... with zero multcount my cpu usage is over 97%... and a 
transfer of around 3.5Meg/sec  (from memory but around there).
With multcount up to 32 no change was seen, but with multicount at 64 or 
128 (the max for my drive) the CPU usage dropped to ~30% *but* the 
transfer rate plumeted to just over 1Meg/sec  (using both the -t option 
of hdparm and also just doing a time on a large dd).
My system is a P90 16Meg ram 512K cache EIDE 540Meg drive (conner) using 
the on board enhanced controller on the PCI micronics motherboard.
Are these figures totally wrong? I would have expected maybe 5Meg/sec and 
a *lot* less CPU usage... might explain why my swap seems to thrash 
so much. (if it's of any relavance windoze refuses to use 32bit disk 
access anymore, although I'm positive it did when I got the system.)

 -----------------------------------------------------------------------------
|Snail:                  |Email: (choose one of)     |Tel: +44(0)223 501878   |
|Shaune Beattie          [email-masked]            |(From 13/10/94)         |
|St. Catharine's College [email-masked] |Thought for the day...  |
|Cambridge CB2 1RL       [email-masked]   |I need a better sig :)  |
 -----------------------------------------------------------------------------

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

From: [email-masked] (Joel M. Hoffman)
Subject: Mounted floppy BECOMES read-only for no reason!
Date: Wed, 12 Oct 1994 17:18:27 GMT

I'm trying to write to a mounted floppy (my b:) using a script that
I've used for a long time with a:.  But it fails in the middle,
complaining about a read-only FS.  Here's the crux of the problem:

        Script started on Wed Oct 12 13:10:34 1994
        # mount -t msdos /dev/fd1d360 /b:
        # touch /b:/a                           <- This works
        # rm /b:/a                              <- And this works
        # touch /b:/fli
        touch: /b:/fli: Read-only file system   <- WHAT THE H*LL???
        # exit
        
        Script done on Wed Oct 12 13:10:59 1994

The only difference between a: and b: (other than size) is that b:
doesn't indicate media change.  Any advice will be gratefully
accepted.  This one is driving me crazy!

Thanks.

-Joel
([email-masked])

-- 
=============================================================================
|_|~~ Germany, Europe. 1944.    "The diameter of the bomb was 30 centimeters,
__|~| 16 Million DEAD.           and the diameter of its destruction, about 7
                                meters, and in it four killed and 11 wounded. 
 cnc  Bosnia, Europe. 1994.     And around these, in a larger circle of  pain
 cnc  HOW MANY MORE?          and time,  are scattered two  hospitals and one
                          cemetery.   But the young woman who was  buried  in
                    the place from where she came, at a distance of more than
             than 100 kilometers, enlarges the circle considerably.   And the 
      lonely man who is mourning her death in a distant  country incorporates
into the circle the whole world.  And I won't speak of the cry of the orphans
that reaches God's chair and from there makes the circle endless and godless."
=============================================================================
     Tell Clinton to stop the genocide:  [email-masked]

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

From: [email-masked] (David Jeske)
Subject: FS resource forks, to be or not to be?(Was: ext2fs vs. Berkeley FFS)
Date: 11 Oct 1994 20:45:11 GMT

[email-masked] (Albert D. Cahalan) writes:

>In article <[email-masked]> [email-masked] (Peter Mutsaers) writes:
>>>> On 11 Oct 1994 01:04:11 GMT, [email-masked] (David Jeske) said:

>>>> For example..(not a NeXT example, but rather a UNIXish example)

>>>> Backgammon.app     <directory>
>>>> Backgammon.app/Backgammon          <same name file is program executable>
>>>> Backgammon.app/whiteCircle.tiff    <tiff image of the white playing piece>
>>>> Backgammon.app/blackCircle.tiff    <tiff image of the black playing piece>
>>>> Backgammon.app/local-config        <some machine configuration>

>>It would be trivial to modify the shell (like bash) to do this: If it
>>finds a directory somewhere in its path, with the name (maybe with an
>>extension like .app) of the program that the user wants to execute, it
>>will descend into that directory and start the executable file that is
>>in it.

>This would almost do the job.  cp, gzip and such would need to treat
>it as a file though, without tar.  I do think a simple flag is still
>needed to avoid the filename extension mess DOS uses to recognize
>executables.  This would need to be done in a standard way so that
>all the shells, filemanagers, and file utilities would recognize the
>directory as a complete unit.

However, when is this going to be enough. You rationalize adding just
"one bit" to tell UNIX that the directory is really a "unit" that 
belongs togeather. Then later, someone else wants his special kind of
unit, and someone else wants his special kind of unit.. and pretty soon
it might as well be a filename + XX bits of special stuff... similar
to the "filename + 3 characters of extension" like in DOS. It's the
same mess in a different light. If we just limit the damage, leave
file permissions usable as they have always been and just use the 
seemingly unlimited filenamespace to make these kind of expansions then
we can keep compatibility alive and not have to keep "addings another
darn bit" to the file bits everytime someone wants something.

Again, I have to make reference to NEXTSTEP, where everything is based
entirely on filename extensions and everything is very clean (in my
opinion). Your not limited to silly 8 by 3 filenames, in fact, extensions
are of different lengths. Filenames still often contain spaces and the 
like (although I can't stand to put spaces in filenames) there is no
visible distinction in the NeXT environment between ".rtf" (rich text)
and ".rtfd" (rich text directory). One would never know that a .rtfd
file was a directory if you didn't look into it further. 

The resource fork approach:

The HPFS approach (NT or OS/2) is just to not bother with even creating
the limits of the file permission bits and such. Just allow arbitrary
additions to the file. In this way someone could add their own custom
extensions to the permission system without breaking everything. I 
personally see the use of these extra "appandages" to files as actual
data forks as bad. Even if only because it makes it a pain in the butt
to move programs in from non "forked" filesystems. Try to get a Mac
program onto a mac from the internet when you don't have ShrinkIt, or
whatever their using these days. 

The question that remains in my mind about these resource type filesystems
is whether or not resource forks (or whatever your going to call them)
are a "secure enough" place to put permission information. Is it 
practical to implement UNIX like security on OS/2 via the extended
attributes? If it is, then this sounds like a very flexible system,
it may come with it's own set of headaches, but it sounds intereesting.
If not.. then forget it.

-- 
David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programmer
   CoCreator of the GTalk Chat Software System  - online at (708)998-0008
                   [email-masked]  (NeXTMail accepted)

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

From: [email-masked] (John Richardson)
Subject: Linux SLIP interactive response
Date: 12 Oct 1994 03:04:14 GMT

I finally got Trumpet winsock and installed it with the same SLIP
parameters that linux uses.  The result:  interactive winsock 
performance during ftp sessions is just as bad as linux!
In addition, under the same parameters, linux (stock slackware 2.0.0)
ftp outperformed windows ws_ftp by about 100 to 200 bytes/sec.
Of course, this could be due to line noise etc...

this means two things:

o we aren't any worse than MS-Windows
o we may be better than MS-Windows :)

I'd be interested in hearing someone from the *bsd camp... or anyone
who has run both linux and another OS on their PC.

--
John Richardson
[email-masked]

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

From: [email-masked] (Peter Benschop)
Crossposted-To: comp.os.linux.help
Subject: Re: X-Windows support Weitek Power 9000?
Date: 12 Oct 1994 17:53:04 -0000

In article <[email-masked]>,
John Willing <[email-masked]> wrote:
>To start, I bought my system awhile back before checking the hardware list
>and ended up buying a A.I.R Star 2000 Video board.

[stuff deleted]

>
>I would like to know if the Weitek P9000 is supported under X-Windows and
>if so, for what vendors.
>
>If there is any development in progress, I would love to be a Beta tester.
>
>----------------
>John Willing 

The new XFree86 3.1 release has support for the Weitek (=STAR) P9000.
I beta-tested the P9000 server for my STAR 2000 board, and there were
no problems. 

I do hope you have a 17"+ monitor, because unfortunately virtual desktop is 
not supported by the P9000.

The new release can be found on all the major ftp sites and binary versions
are available for Linux, FreeBSD etc.

Peter Benschop.

 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 |      Peter Benschop       |        E-mail :         | Eckartseweg Zuid 197|
 | Student of the University |  [email-masked]  |  5623 PB Eindhoven  |
 |  of Technology Eindhoven  |    [email-masked]    |    The Netherlands  |
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

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

From: [email-masked] (David Jeske)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 11 Oct 1994 20:53:16 GMT

>Don't be influenced by the over-featurism that Linux offers.  CP/M
>is simple, therefore it must be better.  There's no need for all
>the overhead of protected memory, device files, file sizes, attributes,
>etc.
>Albert Cahalan
>[email-masked]

I look at the "featurism" in Linux in a completely different manner.
The complexity of protected virtual memory is implemented to make the
user level implementation simpler. As a result of the "complex" memory
system used in UNIX, the user level programs just see one flat contigious
block of memory.

Device files are similar. The user level sees only one type of "i/o" and
that is to files. Whether it's a file on disk, a file in memory, or
a serial I/O stream, it's all file i/o. The other choice would be to
simplify the filesystem to no longer have character and block special
files and instead provide different kernel calls for operations to these
types of devices. As a result you would have 3 different "open", 3 
different "close", 3 different "read", "write" and whatever else
calls. The complexity (in the kernel) of the block and character
special files are to hide the specifics from the user. A type of 
"object orientation" if you will. 

One might think initially that adding resource forks will also move more
of the complexity into the kernel. It is, however, complicating the 
user-level model of what a file is. Instead of having a simple concept
of "file streams orginized into a heirarchial directory structure",
one would be adding another dimension to what user level programs would
have to do to deal with files. Every time you wanted to copy a file, 
"cp" would have to go through all the forks of a file, much as it goes
through all the files in a directory. Why bother making 1 step into 2?

-- 
David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programmer
   CoCreator of the GTalk Chat Software System  - online at (708)998-0008
                   [email-masked]  (NeXTMail accepted)

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

From: [email-masked] (Andries Brouwer)
Subject: Re: Kernel 1.1.53 - no BOOM
Date: Tue, 11 Oct 1994 20:34:06 GMT

[email-masked] (Mark A. Horton KA4YBR) writes:

: After 3 consecutive hangs while posting news articles while 
: processing news, I have punted on kernel 1.1.53 and gone back to
: 1.1.50.  No panic, no messages, no boom.... just a solid hang on
: all VCs, telnet sessions, and dial-ups... no commands could be 
: processed at all.  The only way out was a reset button reboot.  

: System configuration information follows:

: Console: colour EGA+ 132x44, 24 virtual consoles

No doubt this has nothing to do with your hangs, but I have never
seen anyone mention this here before: virtual consoles above 16
are second class citizens in the sense that the ioctl VT_GETSTATE
only works on the first 16 (the v_state field of the struct vt_stat
is a short, and can map only 16 consoles).
I don't know what software would use this info from VT_GETSTATE.

[Btw, 1.1.51 is just fine for me, except for the floppy driver problems.]

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

From: "Brian E. Gallew" <[email-masked]>
Subject: Re: PGP for Linux??
Date: Wed, 12 Oct 1994 13:21:09 -0400

[email-masked] writes:
> "since about forever" PGP compiles out-of-the-box under Linux.
> grab a copy of the source code and type 'make'.

Really?  I've been trying to build 2.6, and it doesn't.  It is having
problems resolving the cpu-specific routines.

=====================================================================
| It's nice to be important, but it's *important* to suck up to the |
| sysadmin  -- Me                                                   |
=====================================================================

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

From: [email-masked] (Zheng Huang)
Subject: 3c505 driver ?
Date: 12 Oct 1994 18:20:54 GMT

Hi,

I tried to config my linux(slakware 2.0) to work with my 3c505 network card,
but I can't find the 3c505.c file in linux src directory under drivers.
For some reason, the 3c505 is been commented out from the config file. Could
someone tell me how I can make 3c505 work with linux.

Thanks so much for the help.

--

==================================================================
    John  Huang  / [email-masked] / Springfield, IL

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

From: [email-masked] (Mark D. Roth)
Subject: hdparm - does it work? (Was: Re: FTP slowdown under 1.1.52 with hdparm on)
Date: 12 Oct 1994 17:55:03 GMT

[email-masked] (John Gotts) writes:

>Mark D. Roth ([email-masked]) wrote:
>: Here are some figures I got, which I found to be fairly consistant:

>: multcount    user    system  clock   %CPU
>: 0            0.21    20.69   0:46.74 44.7
>: 2            0.34    21.53   0:47.69 45.8
>: 4            0.37    18.75   0:49.94 38.2
>: 8            0.37    11.90   1:10.54 17.3
>: 16           0.29    12.37   1:10.55 17.9

>: I'd rather have the wall-clock time, personally... :)

>You might mention what hard drive/controller you are using.

Oooops...<sheepish grin>.

The controller is a generic VLB card that handles 2 HDDs, 2 FDDs, 2
serial, 1 parallel, and 1 game port.  I can't tell you much more than
that; it came with my mail-order system with only minimal docs.

I have 2 HDDs on the chain.  The first one, which is the one I was
testing the hdparm stuff on, is a 250MB Conner drive, model CP30254.
I have it partitioned with a 20M swap partition and the rest for
Linux, in case that matters.  The other HDD is a really old Western
Digital 40M HDD (28ms access...I *used* to think it was fast...) which
I only use for DOS.  Needless to say, it's not used very often.

-- 
   [email-masked] | Mark D. Roth | http://www.cen.uiuc.edu/~mr4342/
     (GEEK CODE 2.1) GCS d-- H+ s++:- g+ p1>4+ !au a-- w++@ v-(*)
        C++>$ UL+>++++ P--- L++>+++ 3 E(-) N++ K++ W--- M-- V-
   po Y+ t++@ 5+ !j R-- G tv b+ D+ B--- e+(*) u+@ h>++ f+ r@ n+@ y?

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

From: [email-masked] (Gordon Chan)
Subject: Re: Linux Mud
Date: Sun, 9 Oct 1994 03:31:28 GMT

          Try circleMUD (a diku mud derivative)  ...  it was developed
directly on linux.  (at least the 2.20 version).  I also got AberMUD,
TinyMUSH, PennMUSH, dgd (and LP mud server), ... workin on linux
straight with little or no changes made to the original code.

                                                  Gord J.C.

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

From: [email-masked] (Joe Smith)
Subject: Re: ext2fs vs. Berkeley FFS
Date: 12 Oct 94 14:15:07

And now for something even sillier... aren't tar archives standard
unix multi-fork files?  Ok, it's a loss having to scan through the
archive to find all the entries.  How 'bout one of the (free) archive
formats with a directory: zoo or zip, e.g.?  There's already lots of
code around to manipulate them and the utilities too.

Unix' real strength lies in it's foundation of solving real problems.
I hope it never 'evolves' to the point that it starts determining what
I need before I know I need it, like other more popular but less
useful alternatives.

<Joe
--
 Joe Smith
 University of Pennsylvania                    [email-masked]
 Department of Physiology                      (215) 898-0485 - work
 Philadelphia, PA 19104-6059                   (609) 854-6428 - home

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

From: [email-masked] (Dan Pop)
Subject: Re: A badly missed feature in gcc
Date: Wed, 12 Oct 1994 22:50:39 GMT

In <[email-masked]> [email-masked] (H. Peter Anvin) writes:

>Followup to:  <[email-masked]>
>By author:    [email-masked] (Dan Pop)
>In newsgroup: comp.os.linux.development
>> 
>>
>> They're valid C code, nevertheless. A C compiler which fails to translate
>> correctly valid C code is broken by definition.
>> 
>
>True, but there is no law against extensions (which may conflict with
>obscure standard constructs) if you can turn them off.
>
I prefer the other way 'round. The default should be the standard 
compiler and any extensions should be enabled using options.

gcc is not working this way (it compiles GNU C by default, not ANSI C)
and this creates lots of problems to the unsuspecting beginner, because
it accepts a lot of invalid ANSI (or K&R) code which is valid GNU C
code.

Dan
--
Dan Pop 
CERN, CN Division
Email: [email-masked]
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

** 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: [email-masked]

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

    Internet: [email-masked]

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