Subject: Linux-Development Digest #839
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Fri, 17 Jun 94 09:13:11 EDT

Linux-Development Digest #839, Volume #1         Fri, 17 Jun 94 09:13:11 EDT

Contents:
  Re: IDE PERF. PATCH SECURITY HOLE (Simon Ferrett)
  Re: SCSI NCR drivers (Bernd Driegert)
  Disk-compression for Linux (albayrak@cc.helsinki.fi)
  Re: PLIP throughput.. (Alan Cox)
  Re: PGP 2.6 for Linux (Alan Cox)
  Re: Yggdrasil Linux with GNU C++ ?? (Bjoern Giesler)
  Re: SCSI NCR drivers (Drew Eckhardt)
  file locking over a local network won't work! (dave sims)
  memory with buslogic 445S (Bill Heiser)
  Re: cp truncate some dos files, why? (Romano Giannetti)
  Linux/XF86 bug (Michael Cederberg)
  Re: IDE PERF. PATCH SECURITY HOLE (Mark Evans)
  Re: SCSI NCR drivers (Shahid Ikram Butt)
  Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13. (Mark Evans)
  Re: PLIP throughput.. (Mark Evans)
  Re: problems with kernel-modules (Rob Janssen)
  Re: DOSEMU and Novell (Mark Evans)
  Re: Linux and symmetrical multiprocessing (Eric Youngdale)
  Re: IEEE 488 (GPIB, HPIB) (Claus Schroeter)
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Re: IDE PERF. PATCH SECURITY HOLE (Brandon S. Allbery)
  Re: assembly language & Linux (ATTN!) (Linus Torvalds)

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

From: c9108932@sage.newcastle.edu.au (Simon Ferrett)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: Fri, 17 Jun 1994 05:52:17 GMT

rob@pe1chl.ampr.org (Rob Janssen) writes:

>In <1994Jun14.174453.28689@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:

>>NO ONE BUY A SEAGATE 1239A. ITS CRAP! (it even got bad sectors, yeah,
>>on an IDE drive (!), after only one year!)

>I have enough experience with Seagate ST-225's and ST-238's to not even
>consider buying any product from this company the rest of my life....

I have a seagate ST3655A and it works absolutely fantastically...
I dont think seagate is a bad compay at all - maybe you just made a couple
of bad choices?


-- 
Simon Ferrett - c9108932@cs.newcastle.edu.au
Floccinaucinihilipilification: the action or habit of estimating as
=============================  worthless.

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

From: bernd@batman.RoBIN.de (Bernd Driegert)
Subject: Re: SCSI NCR drivers
Date: Thu, 16 Jun 1994 12:11:18 GMT

drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:

>>any update on the release date? 

>Nope.  I finally have more time to spend on the driver, and probably
>put in more hours on it last night than I had in the last two 
>weeks combined, and fixed a lot of nasty bugs, but they're not quite 
>ironed out yet.

You work on an driver for the 810, do you plan to support the 820/825 
(don't know exactly, I think ist Wide SCSI), maybe in the future ?

>-- 
>Drew Eckhardt drew@Colorado.EDU
>1970 Landcruiser FJ40 w/350 Chevy power
>1982 Yamaha XV920J Virago

-Bernd
-- 
================================================================================
Bernd Driegert           bernd@adamant.RoBIN.de             Voice: 49-6109-68860
A mathematician is a device for converting coffee into theorems.  (Paul Erd"os)

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

From: albayrak@cc.helsinki.fi
Subject: Disk-compression for Linux
Date: 15 Jun 1994 22:49:54 GMT


        I would like to discuss about on-fly disk compression. My
        opinion is that implementing DoubleSpace(R) and Stacker(R)
        -type compressing file-system is one of the most important
        future enhancements needed for Linux.

        Probably the lack of such feature is because of Unix's
        history. Traditionally Unix has been used by organizations and
        for many years disk-space has not been problem for them. But
        now, when Linux is widely used by (usually) poor students and
        scholars, it is time to use those possibilities that
        disk-compression can give. That's what I think.

        Few questions:

        1. Is there anyone or any group currently implementing such
           thing or is there anyone out there who might be interested
           to do that?

        2. What are the main problems that could arise when
           implementing on-fly-compressing for Linux (or Unix)?
        
        3. Would it be better to implement whole new file-system
           rather than compress data through some existing
           file-system (like ext2) by using a large file as an compressed
           'disk' (that's how Stacker and DoubleSpace does it).

        4. Is there any compression-algorithms (sources?) suitable to
           task?

        Thanks for your interest.

        -Ali-

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: PLIP throughput..
Date: Fri, 17 Jun 1994 08:58:11 GMT

In article <CrHpFo.1w1@cs.vu.nl> john@cs.vu.nl (John Romein) writes:
>The actual throughput depends very much on the speed of the processors
>that are used.  The plip-code is very CPU-intensive, because it has to
>split and shift each byte into two 4-bit quantities, and toggle a 5th bit.

That trust me has nothing to do with it. A 386 can do that splitting at
a good 2Mb/second. The problem is that each nibble you send you wait for the
other machine to acknowledge it and you _wait_ you can't leave it for an
interrupt or anything useful. If you wait too long you have to run another
task and lose plip for a while so you dont just hang for ages.

Whats really bad is a 386SX16 one end and a fast 486 the other.. makes the
486 suffer a lot.

Alan



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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: PGP 2.6 for Linux
Date: Fri, 17 Jun 1994 09:03:57 GMT

In article <2tpt25$dut@bigblue.oit.unc.edu> ewt@merengue.unc.edu (Erik Troan) writes:
>In article <2tna93$k1i@pccross.msk.su>,
>Eugene Crosser <crosser@pccross.msk.su> wrote:
>>In <061394122515Rnf0.78@runic.mind.org> thantos@runic.mind.org (Alexander Williams) writes:
>>
>>>>If anyone knows what's up, I would appreciate a hint.  As a side comment, I
>>>>wonder if any linux site is going to carry the binary of PGP 2.6...

>Sunsite won't carry it (I have at note in Incoming to that effect). We're in
>the US, and it isn't worth the hassle.

No but the sources at ftp.demon.co.uk for the non US PGP2.6 are just fine and
have a linux make entry

Alan


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

From: un4e@rzstud1.rz.uni-karlsruhe.de (Bjoern Giesler)
Subject: Re: Yggdrasil Linux with GNU C++ ??
Date: 16 Jun 1994 18:50:36 GMT

sysop@comet.sb.sub.de wrote:
: Hi,
: i have seen here in a german store a Distribution of
: Linux 1.1 from Yggdrasil named PLUG and PLAY LINUX !

: I looked at the package, and ask the dealer, but it wont
: help me to find out: Is this Linux Distribution delivered with
: GNU C++ - Compiler ?

Yes.


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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: SCSI NCR drivers
Date: 17 Jun 1994 10:16:40 GMT

In article <CDRPBQH@batman.robin.de>,
Bernd Driegert <bernd@batman.RoBIN.de> wrote:
>drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes:
>
>>>any update on the release date? 
>
>>Nope.  I finally have more time to spend on the driver, and probably
>>put in more hours on it last night than I had in the last two 
>>weeks combined, and fixed a lot of nasty bugs, but they're not quite 
>>ironed out yet.
>
>You work on an driver for the 810, do you plan to support the 820/825 
>(don't know exactly, I think ist Wide SCSI), maybe in the future ?

If some one were to donate a NCR53c825, and a nice FAST+WIDE 
device of some sort to insure that WDTR messages were being 
handled correctly, definately :-)  

Actually, supporting most of the chips in the NCR53c7xx/NCR53c8xx 
family is the ultimate goal, with the ordering being something 
like NCR53c810, NCR53c815 (detection changes), NCR53c820
(add handling for WDTR messages, programming of registers
on reselection), NCR53c825, NCR53c720 (modify assembler
to use NCR53c720 register mappings), and NCR53c710 (modify
the NCR code to use INT instructions instead of INTFLY
instructions to signify command completion, come up with
a workarround for the ADD WITH CARRY instructions (probably
with DSA structure alignment). 

The NCR53c700 is a lot more problematic - it has no dsa register
and the corresponding table indirect addressing mode, can't read 
it's own registers, lacks a MOVE MEMORY instruction, and 
allthough I've made some preliminary provisions for support it
in the code, I don't plan on pursuing it any furthur.

-- 
Drew Eckhardt drew@Colorado.EDU
1970 Landcruiser FJ40 w/350 Chevy power
1982 Yamaha XV920J Virago

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

From: sims@csepp011.acsys.com (dave sims)
Crossposted-To: comp.os.linux.help
Subject: file locking over a local network won't work!
Date: 16 Jun 1994 18:31:20 GMT

Hi Linuxers, I have two Linux boxes connected by a network.  The whole
thing installed pretty easily from the Slackware distribution.

Except that I can't get file locking to work over the network.

Basically, I have two processes that each repeatedly lock a file,
write some data to it, then release the lock.  This works fine if both
processes are on the same machine.

However, if one process is on another Linux box with an NFS mounted
filesystem, the file locking doesn't work at all (the data file I'm
writing to gets all messed up).

What's wrong?  Do I need some sort of 'lock manager daemon' running?
Doesn't Linux NFS support file locking?  Any tips or hints would be
appreciated.

Thanks,
Dave Sims
-- 
Dave Sims                                       PGP encryption key available
Internet:  sims@usa.acsys.com                   on my home page.
WWW:       <A HREF="http://cnn.acsys.com:5050/dave.html">my home page</A>

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

From: bill@bhhome.ci.net (Bill Heiser)
Crossposted-To: comp.os.linux.misc
Subject: memory with buslogic 445S
Date: 17 Jun 1994 10:36:29 GMT

I seem to recall seeing something posted about being limited to <16mb of
memory when using the Buslogic BT-445S.  Is this still the case with the
Buslogic driver?  Or can I have > 16mb (i.e. 32mb) of memory now?

Will there be a performance hit due to the issues of addressing >16mb
on the ISA bus?  This is a 486/66 with ISA slots and VL slots.

Thanks,
Bill
-- 
Bill Heiser:    bill@bhhome.ci.net,  heiser@world.std.com

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

From: romano@pimac2.iet.unipi.it (Romano Giannetti)
Subject: Re: cp truncate some dos files, why?
Date: 17 Jun 1994 07:52:21 GMT

In comp.os.linux.development, Barry Yip kam-wa (g609296@win.or.jp) wrote:
> Barry Yip kam-wa (g609296@win.or.jp) wrote:
> >It seems that cp and other commands too will truncate some dos files
> >such as msbackup.hlp (314236). When use cp to copy to another place, it
> >changes to msbackup.hlp (248). So there are holes in the file that cp
> >won't handle. Sorry if it sounds stupid as I am not a unix guru. Any
> >work around for this. Someone can enlighten me on this.

> Me again :-)

> OK it seems the fault is conv=auto fstab. So someone can tell me what's the
> problem for this case.

...is the 249th char an ascii 26? :-)

--
*******************************************************************************
Romano Giannetti        * DII-EIT, University of Pisa(E stands for Electronics)
romano@iet.unipi.it     * Dpto Electr. y Electronica, Facultad de Fisica
                        * Universidad Complutense de Madrid
*******************************************************************************

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

From: mceder@find2.denet.dk (Michael Cederberg)
Subject: Linux/XF86 bug
Date: 16 Jun 94 19:06:54 GMT

Hi there!

I have discovered something that looks like at bug in Linux or XFree86:
Try typing "kill -9 -1" in an xterm (you don't have to be root). On my
machine the system locks up.

Facts:
486DX2-66, 16MB, VLB IDE controller, ATI Mach 32.
Linux 1.1.18, XFree86 2.1

Michael Cederberg
-- 

Michael Cederberg  [mceder@find2.denet.dk]
---
Technical University of Denmark

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

From: evansmp@mb52112.aston.ac.uk (Mark Evans)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: Fri, 17 Jun 1994 11:17:16 GMT

Mark Lord (mlord@bnr.ca) wrote:
: In article <CrGHMM.3M5@frobozz.sccsi.com> kevin@frobozz.sccsi.com writes:
: >In article <2tn06k$sm@bmerha64.bnr.ca>, Mark Lord <mlord@bnr.ca> wrote:
: >>In article <CrFA2D.2IK@ucdavis.edu> kevin@frobozz.sccsi.com writes:
: >>..
: >>>2.  "Read-only" access to a device means just that: you can read
: >>>    attributes, data, etc. from the device, but you can't make any
: >>>    changes to either the status or the data.  Changing a device
: >>>    to multiple-mode should thus require write access to the device,
: >>>    since that's an attribute change.
: >>
: >>Hmm.. on my system, I want my "read-only" devices to be just as fast
: >>as my read-writable ones.
: >
: >...and for normal operations (i.e., data reads/writes), it isn't a problem,
: >because the open() system call takes care of access control.
: >
: >The ioctl() interface is different, of course, but do you really
: >use it often enough that speed is enough of a concern that it would
: >override implementing the "correct" behavior?

: The ioctl() call to enable multiple sector reads needs to be done
: once per drive after each system reboot.  It does not modify the drive
: or any data on it in any physical way, but rather it sets a state in
: the linux hd.c disk driver.    

A sensible check might be to only alow it to work if the "whole disk" device
is being used, minor divided by 64 is zero.

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

From: sib1@Ra.MsState.Edu (Shahid Ikram Butt)
Subject: Re: SCSI NCR drivers
Date: 17 Jun 1994 06:27:24 -0500


Any plans for Adaptec PCI SCSI support ?


Shahid
   ______________________sib1@Ra.Msstate.Edu____________________________
                  Cruising Information Super Highway
                  WWW : http://www.msstate.edu/~sib1

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

From: evansmp@mb52112.aston.ac.uk (Mark Evans)
Subject: Re: AF_UNIX SOCK_STREAM broken even in kernel 1.1.13.
Date: Fri, 17 Jun 1994 11:19:28 GMT

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:

: I hope so. I consider the current AF_UNIX support to be totally inadequate 
: although its awfully good at running X

This was, after all, what it was written to do. :-)

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

From: evansmp@mb52112.aston.ac.uk (Mark Evans)
Subject: Re: PLIP throughput..
Date: Fri, 17 Jun 1994 11:23:32 GMT

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
: In article <2tns8c$6v5@agate.berkeley.edu> genie@sting.Berkeley.EDU (Gene Choi) writes:
: >>If I remember correctly, using LapLink, some people were copying
: >things over the parallel port at least 50-100kbytes/sec,  Sure

: Laplink can lock the machine solid for the transfer.. Linux has things to do
: and the parallel port wasnt designed for this.

On this type of theme, I remeber an interface card (serial) being reviewed about
6 months ago. This card uses it's own processor, so as to avoid locking up
the machine. Not really a problem with dos and I don't think PCW tried it
under anything else. Has anyone tried this sort of hardware with Linux.

The point with PLIP is that the host CPU has to do just about everything,
even a standard UART provides more assistance.


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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: problems with kernel-modules
Reply-To: pe1chl@rabo.nl
Date: Fri, 17 Jun 1994 07:20:30 GMT

In <CHRIS.94Jun16180944@ludlow.franken.de> chris@ludlow.franken.de (christopher_drexler) writes:


>my system: 486/50, 16mb ram, 8mb swap, kernel 1.1.18, modutils-0.99.15


>I'm trying to develp an interrupt-driven device-driver so i was very glad
>about the possibility to insert and remove the driver at runtime.

>it happend that insmod found some 'unresolved externels' when inserting
>the driver, so i examined the kernel-symbol-table which is read by insmod.
>i found out that some symbols, which are not in this list, may be used, while
>others may not.

>example: 'irqaction' not usable
>         'interruptible_sleep_on' not usable

>         'outb_p' usable

Of course, outb_p is a #define, which is resolved at compiletime.  A
function is a different thing, it is resolved at linktime or module loadtime.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

Crossposted-To: comp.os.linux.help
From: evansmp@mb52112.aston.ac.uk (Mark Evans)
Subject: Re: DOSEMU and Novell
Date: Fri, 17 Jun 1994 11:28:46 GMT

Rob Janssen (rob@pe1chl.ampr.org) wrote:

: >I need to have DOSEMU run on 2 different cards, because the netx client
: >will give me a security breach if 2 users try to login from the same
: >ethernet hardware address.  I have asked the novell group if vlm's fix
: >this (like the OS/2 requestor), but no one has replied.  I really need
: >to have the ability to run multiple DOSEMU sessions into my Novell
: >server, so any pointers are appreciated!

: It would not be reasonable to use a 2nd card only for that purpose,
: wouldn't it?
: Indeed what I would like to know is how one can setup multiple sessions
: from a single machine (with a single ethernet address).  Once that is
: known, I could add the support required for it in the dosemu packet
: driver, if support is required there.

This depends on what the SERVER is happy with. However I belive it is
the case that NT can actually do this. Not sure how it does it though,
possibly you need a NLM loaded on the server for it to allow a multi-
user client.

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

From: ericy@cais.cais.com (Eric Youngdale)
Subject: Re: Linux and symmetrical multiprocessing
Date: 17 Jun 1994 11:36:51 GMT

[Bunch of attributions deleted to satify my anal newsreader which 
complains about the ratio of new/old being too low]
>>>Now if we can just figure out the organization which lurks behind the 
>>>nom-de-compute "Eric Youngdale".
>
>>      I need to get a life.  Perhaps I should say that we need to get a 
>>life :-).
>
>You probably have to go on a world tour to show the folks that you really
>exist...

        Well, I will be in Heidelberg.  Not being a student means that I 
cannot take off for weeks at a time like some people do :-).

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

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

From: clausi@chemie.fu-berlin.de (Claus Schroeter)
Subject: Re: IEEE 488 (GPIB, HPIB)
Date: Fri, 17 Jun 1994 11:42:29 GMT

carlesp@cnm.es (Carles Perello) writes:


>
>Hello!
>
>Some weeks ago I saw a post from someone interested in a 
>IEE488 driver for linux. As I am willing to use a National
>Instruments PC2A.2 with linux, I am also *very* interested
>in using or helping to develop such a thing. 
>
>At the moment I do not have any technical information from
>the NI card, and NI didn't answer a request of info for this
>card. Maybe because I am overseas :)
>
>Hope I got some answer! Thanks!
>
>Carles (carlesp@cnm.es)
>

Hi Carles,

the PC2A.2 card uses the NAT4882 Chip from National Instruments
this chip can be used as an NEC7210 or an TI TMS9914A depending
on the state of the MODE pin 2 that is controlled by an DIP-Switch
on the board. Some time ago i got some Code from Leo Spikman for
the NEC7210 chip but i haven't tested yet. Using this DIP-Switch
you can configure this card to 7210 Mode and try it out.

if you're interested in this piece of code send mail to

clausi@chemie.fu-berlin.de

PS: I hope we will have an ftp server for Linux-Laboratory stuff soon
that holds all this secrets of driver programming for data-aquisition
and process controll. i'm working on it so be patient.


clausi

 

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix,comp.arch.storage
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Fri, 17 Jun 1994 04:37:06 GMT

[This was originally cross posted to comp.os.research, the moderator
removed the other groups when he accepted the thread ... Please
follow up to comp.os.research so we can move to a better forum for
continuing this. Enjoy "The RAID 7 Disk Subsystem - band-aid and
white elephant" thread ...JB]

In article <2thi8oINN1q1@slate.summit.novell.com>,
-candee-+Kovach K.R. <krk@summit.novell.com> wrote:
>>The current UNIX filesystem architecture is critically flawed
>>on all major fronts - performance, reliability and security - and
>>lacks key features of the main frame market it replaces.
>>OS work today is done mostly by follow the herd, critical thinking
>>is a lost art.
>>
>>Either Novell and the key players need to get the clue, or UNIX
>>will be replaced in the passing of time (the 90's).
>
>Can we get a posting by one or more of the authors of prior postings
>of references to work that solves some or all of the problems of
>performance, reliability and security?
>
>I would like to get a clue, but have been at least partially blinded
>by the fact that UNIX file systems and UFS are generally what is taught
>and held up as examples of how to do file systems. So in particular
>I would like to see how other OS's solve the problem.
>
>Kurt Kovach                    "My opinions are my own."
>Novell, Summit

I'm attempting to move those topics in this thread to
comp.os.research and combine with the thread on RAID as
a bandaid due to filesystem architecture problems. This
should be even more interesting than the opening shots
in this thread, and will include topics I have presented
since the late 70's to mid 80's and have been largely ignored
or discounted.

I have a significant beef with the educational systems treatment
of the "Computer Science" dicipline and how students are taught.
This is the outcome of not only how my formal education progressed
during the early 70's but how current graduates must be mentored
to re-examine their teachings which they accept as the gospel
according to Thomposon, Richie, and Joy - and the thousands of
converted missionaries.

This series was fun, and I think necessary to introduce the cold
reality that things are far from perfect. I don't think a two line
bug report would have served the purpose or opened up the degree of
thinking and discussion necessary to have it sink in.

Some of the Major topics to follow in this comp.os.research series are:

        * How we got here today (partly covered in this thread)
          and why that was acceptable then and not now.

        * the evils of partition filesystem management, specifically
          the performance and resource partitioning impacts (old data
          presented to thousands in the past conferences, but lost)

        * the evils of block at a time filesystem architecture
          as formalized and standardized by the kernel filesystem
          interfaces (old data again from both presentations
          and postings in other groups).

        * Locality problems and how they strangle disk performance.
          A well structured arguement for radical architecture
          changes. The problem goes past just filesystem design
          as defined by UNIX implementation, and extends into
          core kernel services, drivers, disk subsystems.
          (old data again ... widely known, but not acted upon).

        * Ignorance of physics and physical properties which
          criple UNIX filesystem performance and reliability.
          Sub topics include seek management, rotational latency
          management, data scrubbing, integrated clustered
          ecc with automatic recovery from multiple data block
          failures. Data placement techniques for reliability.
          (Old data presented in other conferences, training
          seminars, and to clients).

        * Statistical caching, data replication, data migration
          and fully transparent backup and recovery techniques.
          Why mirroring, stripping and RAID in the current
          designs are just flat wrong and stupid. Alternative
          architecture presented which obsoletes these techniques
          and greatly moves us forward. (old data not widely
          presented elsewhere, primarily to my internal staff
          and clients).

Why comp.os.research ... because the data above is enough to
fill a book or a three day seminar, and will invite too many
cranks to divert the dicussion if held in a non-moderated
forum. ... I have a limited amount of time to fight the issue.
I normally make my living consulting on these topics, not
training people for free.

My detractors at SCO called the above the "Big Bang Theory"
since I repeatedly said the base problem with UNIX filesystem
performance was the initial design ... and that no significant
improvement could be made without a near complete redesign
which abandoned all the current interfaces and knowledge.
This is a scarey commitment to make when your bussiness is
to follow the technical lead of other providers. At first
I took "Big Bang" as an insult (as it was intended I guess)
then realized it was kinda cute and really reflected the
scope of the problem. Sometime things really are just wrong
from the begining ... when viewed with hindsight and changing
requirements. I think the design and tradeoffs were brillant
for 1974 ... and simply do not apply today.

Should the moderator of comp.os.research choose not to
host this debate ... we might need to find a third party
to moderate an alt.filesystem.research group.

I will probably force all mail to this account to bounce
as well, given the shit I received over this thread. If you
have an interest in the thread and would like a private
channel let me know soon.

The key policy of any design should be coordinated by
the responsible technology architects and the Systems
Architect (or Architecture Team) which is responsible
for coordinated features and overall consistancy.
This group must have, not only detailed knowldge of the
of the product, but the external experience and critical
thinking skills necessary to evaluate proposals with
conformity to a long range plan in mind. This is not
a place for wannabies or one membership one vote.
Nor is it a function to be filled by seniority or popularity.

UNIX has suffered greatly since this control function has
not been applied to the massive disjointed growth
in the product forced by competetive interests. The
relationship between the various key vendors, standards
efforts, customers, universities, wannabees, and
USL/Novel is a crazy product circus one could never
dream up with a clear mind. Every vendor and every
wannabie implements new features that are irreconcilable
with the future.

John

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: Fri, 17 Jun 1994 11:17:14 GMT

In article <c9108932.771832337@sage.newcastle.edu.au>, c9108932@sage.newcastle.edu.au (Simon Ferrett) says:
+---------------
| rob@pe1chl.ampr.org (Rob Janssen) writes:
| >In <1994Jun14.174453.28689@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
| >>NO ONE BUY A SEAGATE 1239A. ITS CRAP! (it even got bad sectors, yeah,
| >I have enough experience with Seagate ST-225's and ST-238's to not even
| >consider buying any product from this company the rest of my life....
| 
| I have a seagate ST3655A and it works absolutely fantastically...
| I dont think seagate is a bad compay at all - maybe you just made a couple
| of bad choices?
+------------->8

Seagate has a severe quality control problem:  sometimes you'll get a good
drive that works reliably, but it's a crapshoot.  I had better luck than many
with their older drives (ST225 and ST251N) back when I didn't know any better
:-) but I don't consider it worthwhile to play games of chance with my data as
the chips...

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT.              Linux iBCS2 emulation

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

From: torvalds@cc.Helsinki.FI (Linus Torvalds)
Subject: Re: assembly language & Linux (ATTN!)
Date: 15 Jun 1994 21:36:11 +0300

In article <1994Jun15.135924.17830@dxcern.cern.ch>,
Dan Pop <danpop@cernapo.cern.ch> wrote:
>In <2tmpm0$ejg@klaava.Helsinki.FI> torvalds@cc.Helsinki.FI (Linus Torvalds) writes:
>
>>Any porters out there should feel happier knowing that DEC is shipping
>>me an AlphaPC that I intend to try getting linux running on: this will
>>definitely help flush out some of the most flagrant unportable stuff. 
>>The Alpha is much more different from the i386 than the 68k stuff is, so
>>it's likely to get most of the stuff fixed. 
>>
>Unfortunately, the AXP cpu has the same endianess as i386. :-)

Yup.  On the other hand, I don't really think endianess is a major
problem (whatever Windows/NT claims), and I haven't made *that* many bad
assumptions.  One of them was some bad code in the termios layer which
used to use endianess assumptions to copy some 32-bit values in
'termios' to the 16-bit equivalents in 'termio' (note the missing 's'). 
That one was already fixed due to the 68k port (there are probably
others, and filesystem stuff can get hairy, but it shouldn't be too
bad). 

The real problems would tend to be memory management (which is
essentially identical to the i386 in the 68k) and device drivers.  On an
AlphaPC the device drivers shouldn't be that bad due to it using a
PC-type bus and devices.  But I expect 64 bits to make for some
interesting changes. 

The __asm__ stuff from which this all started is generally mostly a
beauty wart which mostly makes it harder for porters who do not know the
i386 architecture closely.  In the kernel it's just a nuisance, while it
can really hurt in user programs which could possibly be ported easily
otherwise. 

                Linus

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


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