Subject: Linux-Development Digest #320
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 16 Oct 94 22:13:13 EDT

Linux-Development Digest #320, Volume #2         Sun, 16 Oct 94 22:13:13 EDT

Contents:
  Re: A badly missed feature in gcc (Tim Morley)
  Re: Adaptec AHA-2940 PCI SCSI card support.... (Mark A. Horton KA4YBR)
  Adaptec addresses and numbers (Mark A. Horton KA4YBR)
  Any plans for 'trace'? (Justin Beech)
  Re: 1.1.53 - fdformat - IOCTL error still there (Jon Lasser)
  Help: printcap for bj10e (Lai...)
  Re: A badly missed feature in gcc (H. Peter Anvin)
  Re: Shared Libs: working toward a permanent solution? (H. Peter Anvin)
  Re: Improving SLIP latency under Linux (John Richardson)
  Re: IS anyone reading users' complaints? (Mr D R Barlow)
  Re: We a FAQ: Linux vs. *BSD!!! (Holger Veit)
  Re: We a FAQ: Linux vs. *BSD!!! (Charles E Meier)
  Re: 8-bit colour ANSI and ncurses (Rasmus Lerdorf)
  SPEC 1170 for Linux? (Marc Fraioli)
  Re: GNUStep...Is It Real or Just a Hoax?!? (Dan Pop)
  Kernel 1.1.54: Error compiling (Bart Kindt)
  Re: Data security under Linux (Hugh Strong)

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

From: [email-masked]. (Tim Morley)
Subject: Re: A badly missed feature in gcc
Date: 14 Oct 1994 14:12:06 +0100

In article <[email-masked]>,
Bruce Thompson <[email-masked]> wrote:
>
>As a postscript, I find the notion of supporting multiple comment
>syntaxes as unusual in the extreme. I know of no other language than
>C++ which has multiple comment syntaxes. I have yet to encounter a
>compelling reason for it besides backward-compatability which isn't
>_that_ compelling for me.
>

If I remember correctly Algol68 has comments of both types, though I
can't remember what characters it uses....

Tim M

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

From: [email-masked] (Mark A. Horton KA4YBR)
Subject: Re: Adaptec AHA-2940 PCI SCSI card support....
Date: Wed, 12 Oct 1994 15:31:19 GMT

Edward S Peschko ([email-masked]) wrote:
: hey all --

: Any plans (*please*) for developing support for the AHA-2940 PCI SCSI 
: board??

        Why don't you ask your friendly Adaptec company why they won't
        release their specs so a driver can be written for them for 
        FREE?  Don't blame Linux and its developers for the failings
        and short-sightedness of a certain hardware manufacturer.

: Ed

: (ie: This really sucks. I have a $5K system, with a 4MB VRAM card (and yes,
: its diamond unfortunately) 4xPlextor, etc. etc... and its TOO NEW for linux!
: If something doesn't come out soon, I guess it is just going to have to be
: SCO...)

        Well, that's one solution.  Go out and spend your $5,000.00 to get
        the equivalent (almost) software that you can get for free with
        Linux.  I just threw out SCO ODT 3.0 (was wasting one of my disk
        partitions) and got rid of AT&T SVR4 over a year ago. 
        
        I just tried to send an email to the Adaptec people about the 
        2940 support (I have a 1500 system network deal brewing and about
        to install and would like to use their equipment, but it looks
        like NCR or BusLogic is going to get it instead - Adaptec's
        loss!)    BTW: this is the response I got from them :

From n4hgf!emory!eng.adaptec.com!support Wed Oct 12 08:25:03 1994
Date: Wed, 12 Oct 94 00:56:46 PDT
From: n4hgf!emory!eng.adaptec.com!support (Tech Support Account)
Subject: Technical Support  
Apparently-To: [email-masked]
Status: RO

===========================   A D A P T E C     =========================

Thank you for your message regarding "2940 support for Linux".

Currently, your e-mail request cannot be forwarded to the appropriate 
individuals within Adaptec. At the current time, the Technical Support
group does not offer Internet support.

In the interim, the following alternate resources may be of assistance to you:

Sales:  (800) 959-SCSI

Technical Support Voice (408) 934-7274
Technical Support BBS:  (408) 945-7727
Technical Support FAX:  (408) 945-6776
Interactive Fax System: (408) 957-7150
Literature Hotline:     (800) 934-2766
Software Order Line:    (800) 442-7274

Adaptec's Technical Support may also be reached by mail at:

Adaptec, Inc.
Technical Support M/S 105
691 So. Milpitas Blvd.
Milpitas, CA  95035
USA

Adaptec's Sales Department may also be reached by mail at:

Adaptec, Inc.
Sales Department
691 So. Milpitas Blvd.
Milpitas, CA  95035
USA

If you are in Europe, you may want to contact our European Technical
Support Offices at the following numbers:

General:32-2-352-3411
Fax:    32-2-352-3400
French: 32-2-352-3460
English:32-2-352-3470
German: 32-2-352-3460

If you are in Japan, you can reach the Adaptec forum on the NiftyServe
On-line Service.

This message has been computer generated.

Once again, thank you for your message.

=============================================================================

So there you have it... call your vendor and complain... don't complain about
Linux not supporting YOU, complain about your hardware vendor not supporting
YOU!  :)

        -- Mark

--
"Linux!  You can spend more, but you can't buy better! "
============================================================
Mark A. Horton       ka4ybr           [email-masked]
P.O. Box 747 Decatur GA US 30031-0747   [email-masked]
+1.404.371.0291 : 33 45 31 N / 084 16 59 W    [email-masked]

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

From: [email-masked] (Mark A. Horton KA4YBR)
Subject: Adaptec addresses and numbers
Date: Wed, 12 Oct 1994 15:39:06 GMT

Hello all,

        I have been trying to pry some information out of Adaptec about
        their 2940 cards and potential Linux support from them (Well, I
        can dream, can't I?!) and just thought I'd share this set of 
        phone numbers and addresses I got in return for my trouble.  
        Maybe if enough people called and wrote, they might recognise
        us.  (Am I dreaming again?)   - Mark

        Actually, I'm going for the NCR and BusLogic support now myself.

From n4hgf!emory!eng.adaptec.com!support Wed Oct 12 08:25:03 1994
Date: Wed, 12 Oct 94 00:56:46 PDT
From: n4hgf!emory!eng.adaptec.com!support (Tech Support Account)
Subject: Technical Support  
Apparently-To: [email-masked]
Status: RO

===========================   A D A P T E C     =========================

Thank you for your message regarding "2940 support for Linux".

Currently, your e-mail request cannot be forwarded to the appropriate 
individuals within Adaptec. At the current time, the Technical Support
group does not offer Internet support.

In the interim, the following alternate resources may be of assistance to you:

Sales:  (800) 959-SCSI

Technical Support Voice (408) 934-7274
Technical Support BBS:  (408) 945-7727
Technical Support FAX:  (408) 945-6776
Interactive Fax System: (408) 957-7150
Literature Hotline:     (800) 934-2766
Software Order Line:    (800) 442-7274

Adaptec's Technical Support may also be reached by mail at:

Adaptec, Inc.
Technical Support M/S 105
691 So. Milpitas Blvd.
Milpitas, CA  95035
USA

Adaptec's Sales Department may also be reached by mail at:

Adaptec, Inc.
Sales Department
691 So. Milpitas Blvd.
Milpitas, CA  95035
USA

If you are in Europe, you may want to contact our European Technical
Support Offices at the following numbers:

General:32-2-352-3411
Fax:    32-2-352-3400
French: 32-2-352-3460
English:32-2-352-3470
German: 32-2-352-3460

If you are in Japan, you can reach the Adaptec forum on the NiftyServe
On-line Service.

This message has been computer generated.

Once again, thank you for your message.

=============================================================================

--
"Linux!     Guerrilla UNIX Development     Venimus, Vidimus, Dolavimus."
============================================================
Mark A. Horton       ka4ybr           [email-masked]
P.O. Box 747 Decatur GA US 30031-0747   [email-masked]
+1.404.371.0291 : 33 45 31 N / 084 16 59 W    [email-masked]

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

From: [email-masked] (Justin Beech)
Subject: Any plans for 'trace'?
Date: Sun, 16 Oct 1994 08:03:09 GMT

One command I sorely miss, especially when things are not
going well, is 'trace', the Sunos command for spewing out
the system calls a process does, with arguments.
I know this is Sun special, but its a very useful special.
Anybody else miss trace?

--
Justin Beech
[email-masked]

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

From: [email-masked] (Jon Lasser) 
Subject: Re: 1.1.53 - fdformat - IOCTL error still there
Date: 12 Oct 94 14:54:00 GMT
Reply-To: [email-masked] (Jon Lasser) 

-> > Very shortly after patch52 came out, a few persons observed an
-> IOCTL error > when using fdformat. I figured it would be better in
-> 1.1.53,
->
-> For me 1.1.53 does not boot at all.
-> The kernel hangs after the CSLIP message, probably when detecting the
-> ethernet card (ne 2000).

I have an NE2000 and .53 boots just fine -- what's your interrupt,
address, etc? I'm frankly not sure of mine, but I'll check it out...

Jon

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

From: [email-masked] (Lai...)
Subject: Help: printcap for bj10e
Date: 14 Oct 94 09:52:19 +0800

Could anyone out on the net give me some help on my bj10e printer?  I'm really
lost at its printcap file.....Thanks....

Jason

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: A badly missed feature in gcc
Reply-To: [email-masked] (H. Peter Anvin)
Date: Sat, 15 Oct 1994 15:24:16 GMT

Followup to:  <[email-masked]>
By author:    [email-masked] (Jeff Kesselman)
In newsgroup: comp.os.linux.development
> 
> I think, perhapse, you are missing the point of the examples because of 
> possibly not having studied compiler theory (no shame in that, we all 
> have to make choices as to what to study.)  There really is no such 
> thing as an 'artificial example'.  A language syntax is defined by the 
> set of legal programs that can be written with it.  There are no 'better 
> or worse' programs as far as the synatx is concerned, all that is legal 
> has equal standing.  This is pretty basic to language theory.  Thsu the 
> examples are legal syntax, that woudl become illegal, and thats all that 
> really matters.
> 

Oh, I have studied compiler theory all right.  I have also done quite
a bit of practical programming, and quite frankly you sound like you
need to get out of the theory and smell the coffee, so to speak.  The
theory tells us how to get from point A to point B, not which point
should be point B.

I define an artificial example as one which would involve constructs
that would never occur in actual programming practice (obfuscated C
contest doesn't count).  I hold that a change to the standard that
only invalidates such artificial examples is permissible, since it
will not affect the real goal -- being able to compile programs and
have them do what you intend them to do.

        /hpa

-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: Shared Libs: working toward a permanent solution?
Reply-To: [email-masked] (H. Peter Anvin)
Date: Sat, 15 Oct 1994 15:29:47 GMT

Followup to:  <[email-masked]>
By author:    [email-masked]
In newsgroup: comp.os.linux.development

> Note that the code above could probably be optimized in various ways;
> for one thing, it's really only necessary to load segment registers
> in routines that are public entrypoints that can be called from
> client code or from other libraries.  Also, it might be possible to
> use the CS register instead of FS or GS as the library base "pointer";
> the implementation would look quite different but mostly the same
> principles would apply.  But these are just "possible optimizations";
> the code as I presented it should work just fine.
> 

Actually, a code segment selector (which CS has to point to) is quite
different from a data segment selector, so this would not work.  Also,
I would generally assume it would be most convenient to keep CS
zero-based, but I could be wrong, since I am not that well versed in
the details of the current PIC implementation.

        /hpa
-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
"All sysadmins love logs."  -- Me after deleting 87 Mb worth of log files

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

From: [email-masked] (John Richardson)
Subject: Re: Improving SLIP latency under Linux
Date: 13 Oct 1994 16:47:28 GMT

In article <[email-masked]>,
Michael Callahan <[email-masked]> wrote:

>Actually, what you would really like is to have a SLOW baud rate
>for transmitting to the modem, and a FAST baud rate for receiving
>from it.  The problem with having a FAST baud rate for transmitting
>to the modem is that the Linux host can fill up the modem's 
>transmit buffer rapidly, at which point the modem has a couple
>seconds of data to send, so _no matter what the Linux host does_,
>a new interactive packet will have to wait a couple of seconds
>for delivery.

I'm not sure about this: I don't think my modem has a transmit
buffer (hehe, try getting information from supra! Argh) and 
I have a laggy interactive response.  I have been in contact
with linux users who have faster modems with no internal buffers
at all who suffer from the same problem.

>
>If instead you transmit to the modem more slowly, you'll never fill
>up the transmit buffer (much).

I agree, if this is the problem.

>
>On the other hand, you lose bandwidth, obviously.
>
>I wouldn't be surprised if a 9600 baud connection to a 14.4
>modem session gave the best latency results for interactive
>traffic with simultaneous bulk traffic.  On the other hand,
>it's slow.

something like this might require a driver change to slip...
it would be interesting to try...

--
John Richardson
[email-masked]

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

From: [email-masked] (Mr D R Barlow)
Crossposted-To: comp.os.linux.misc
Subject: Re: IS anyone reading users' complaints?
Date: 16 Oct 1994 18:04:23 +0100

In article <[email-masked]>,
        [email-masked] (Breakdown) writes:
>                                         If I were deve-
>loping the kernel, I'd probably make sure I went through 
>all 200+ daily problem reports and figure out if there's
>a real problem behind each and every one of them....

Fine.  Are you developing the kernel?

If I were developing the kernel I'd get EXTREMELY PISSED OFF when
people post crap like this to newsgroups.  It's FREE, remember.  If
you want guaranteed support, go and buy it from someone.

Followups to .misc in the absence of an advocacy group

Daniel

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

From: [email-masked] (Holger Veit)
Crossposted-To: comp.os.386bsd.development
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: 16 Oct 1994 17:05:44 GMT

Jordan K. Hubbard ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Ken Hughes) writes:
:    Normally I would agree, but in this case I doubt that ignoring the
:    questions will stop them from being asked.  New people come into these
: 
: Read what I said more carefully, please.  I didn't propose to stop the
: questions, I simply proposed to stop the answers.  The questions will
: keep coming in, but will "quench" themselves far more quickly if
: people simply ignore them.  We're always going to have this question,
: there's no doubt, so the best we can do is try to minimize the amount
: of damage it does.

Surely, various knowledged people who know both systems will follow this
silent agreement not to reply to the questions, but the past shows that
it is mainly the missionary kind of posters who want to pull newbies
into the direction that "their OS" is "the best of all existing worlds
ever seen in the universe" and who do not fear to lie that e.g.
*BSD has no shared libraries yet and needs hundreds of MB to install, or
Linux trashes disks or is instable like DOS (exaggeration intended, 
don't reply to that; we know this is untrue).
These statements were usually those that cause replies and flames from
the other camp.

You can appeal to the serious people (that do exist in both camps)
not to reply, but you can't stop the best-OS crusaders. I don't know
what is better for a newbie: to get an almost neutral comparison in
the form of a FAQ (possibly set up together by the serious people), or a 
warped picture of some OS in the style of a salesman's blurb.

--
         Dr. Holger Veit                   | INTERNET: [email-masked]
|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
|__|  /  Center for Computer Science       | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              | Had a nightmare yesterday:
|  |/    53754 St. Augustin, Germany       | My system started up with
                                           | ... Booting vmunix.el ...

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

From: [email-masked] (Charles E Meier)
Crossposted-To: comp.os.386bsd.development,comp.unix.bsd
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: 16 Oct 1994 15:15:05 GMT

In article <[email-masked]>,
Jesus Monroy Jr <[email-masked]> wrote:
>Jordan K. Hubbard ([email-masked]) wrote:
>: In article <[email-masked]> [email-masked] (Ken Hughes) writes:
>:    Normally I would agree, but in this case I doubt that ignoring the
>:    questions will stop them from being asked.  New people come into these
>
>: Read what I said more carefully, please.  I didn't propose to stop the
>: questions, I simply proposed to stop the answers.  The questions will
>: keep coming in, but will "quench" themselves far more quickly if
>: people simply ignore them.  We're always going to have this question,
>: there's no doubt, so the best we can do is try to minimize the amount
>: of damage it does.
>:
>       Jordan,
>               please consider the damage that a newbie could
>       do, if they answered the question.  That alone should
>       convince you of the unsoundness of your idea.  
>
>       Yes, there is a big problem with this idea, but we have
>       a bigger problem.  That is, I'm tired of agruing with
>       you (and a hunderd) other converts (sp?).  I know for
>       a fact I can't get you to do the 386bsd thing with me,
>       so why should I bother.   By the same token, I am not
>       going to allow you to "bad-mouth" 386bsd.  Given the
>       oppertunity (sp?) I will continue.   You know my staying
>       power in this issue and we won't have any winners in
>       an on going "flame-war".   This is a good solution 
>       so that we my go back to work.    Mind you, next week
>       I'm interviewing for a job of about $70K.  I won't fight
>       you, but I can sure make it so you can't win.... 
>
>               resort to reason... rethink your strategy.
>

Kind of ironic seeing Jesus Monroy start a thread complaining about
wasted bandwidth and asking others to "resort to reason..."

cem

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

From: [email-masked] (Rasmus Lerdorf)
Subject: Re: 8-bit colour ANSI and ncurses
Date: 14 Oct 1994 06:41:20 -0400

[email-masked] writes:

>I think that if the console driver is modified to accept new escaape
>sequences, a new termcap/terminfo file should be included as well.  My
>etc/termcap does not give any of the alternate character set entries
>(as,ae,ac) for the console terminal.

There is already stuff in the console driver that is not reflected in
the termcap/terminfo.  Like ^[[10;11;12m  and others.

*Rasmus*

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

From: [email-masked] (Marc Fraioli)
Subject: SPEC 1170 for Linux?
Date: 16 Oct 1994 17:42:21 GMT
Reply-To: [email-masked]

Well, it looks like X/Open has published the final version of SPEC 1170,
and it only costs $250 US for the book and CD-ROM of the spec.  This seems
like something Linux really ought to be compliant with, and it's pretty
cheap.  Should we all chip in and get a copy for Linus?  Or perhaps 
X/Open will donate one for good PR with the Open Systems community?
I'm including a copy of their announcement in case people here didn't
see it.

>Newsgroups: alt.windows.cde
Path: news.clark.net!news.sprintlink.net!howland.reston.ans.net!pipex!uknet!cix.compulink.co.uk!gbb
>From: [email-masked] ("Graham Bird")
Subject: Single UNIX Specification
Message-ID: <[email-masked]>
Organization: Graham Bird, Director of Branding, X/Open Company Ltd.
Date: Sat, 15 Oct 1994 17:29:33 GMT
X-News-Software: Ameol
Lines: 99

Please note that the following press release will be issued world-wide by 
X/Open on Tuesday 4th October 1994.

***

DRAFT PRESS RELEASE FINAL VERSION   10/3/94

SINGLE UNIX SPECIFICATION NOW AVAILABLE

New York; 4th October 1994:  X/Open Company Limited, the independent open 
systems organisation, today announced that the single specification for 
UNIX had been published and is now publicly available.  The specification 
(hitherto known as Spec 1170) has been ratified and agreed by the world's 
largest computer systems vendors under the 'Fast Track' industry review 
process initiated and managed by X/Open.

The process of developing the single UNIX specification was endorsed on 
1st September 1993 by over 75 software and system suppliers.

The publication of the specification completes the transition of UNIX, 
from being a collection of diverse products, into a standard set of 
Application Programming Interfaces (APIs) described in a single 
specification.

David Smith, of leading computer industry analyst International Data 
Corp, commented "API specifications such as the single UNIX 
specification, or Spec 1170, are what we have long believed are the right 
level for standardisation and unification to occur in the UNIX market."

The single UNIX specification is now available in book or CD-ROM form 
from X/Open or its world-wide publishing partner Prentice Hall Inc.

The published specification was launched today by X/Open Vice President 
and Chief Technical Officer Mike Lambert.  Speaking at industry trade 
show UNIX Expo, Mr Lambert said, "The publication of the single UNIX 
specification is an important milestone for the open systems industry. 
 >From now on, UNIX will mean the same thing to everybody.  System 
vendors, software developers and users can all focus on making the most 
from a unified market."

For the X/Open User Council, which represents over 80 leading 
implementers of open systems, Chairman Denis Brown (Vice President, PRC 
Inc.) commented, "We welcome the industry initiative to unify the UNIX 
APIs.  Now we are looking forward to the new generation of UNIX products 
appearing on the market."

X/Open is now preparing a set of software testing tools which will 
rigorously check the compliance of operating system products to the 
single UNIX specification.  Systems passing these tests from suppliers 
entering into a trademark license agreement will be awarded the UNIX 
brand by X/Open.  The tests will be available in line with the agreed 
end-of-year delivery date. 
The single UNIX specification delivers benefits for all sections of the 
open systems market.  It enables system vendors to develop and market 
their own implementations of UNIX while continuing to support a single, 
common set of Application Programming Interfaces (APIs).  Software 
applications developers may now save the cost of producing and supporting 
multiple product versions.  User organisations can save time and cost in 
procuring and maintaining systems by specifying UNIX in their 
procurements.

The specification, which covers system interface definitions, system 
interface and headers, commands and utilities and networking services, is 
priced at $250.00 in book form and on CD-ROM.  The single UNIX 
specification can be obtained by contacting your nearest X/Open office or 
by e-mail request at [email-masked] or from Prentice Hall Inc., 
ISBN 1-85912-054-7.

About X/Open

X/Open, founded in 1984, is a world-wide, independent, company dedicated 
to bringing the benefits of open computer systems to market.  The company 
markets products and services to computer system buyers, system 
suppliers, software developers and standards organizations.  By 
integrating prioritized requirements and expertise from each of these 
groups, X/Open is able to evolve and manage a comprehensive set of 
publicly available open systems specifications, including de facto and 
international standards, which define the Common Applications Environment 
(CAE).  X/Open operates a test and verification procedure for products 
developed in line with its specifications, and awards its brand as the 
mark of compliance.

ends

X/Open and the "X" device are registered trade marks of X/Open Company 
Limited.  UNIX is a registered trade mark in the United States and other 
countries, licensed exclusively through X/Open Company Ltd.

============================
Mark Riminton
T: +44 (0)932 252900
F: +44 (0)932 253670
E-mail: [email-masked]
============================

---
Marc Fraioli          | "They couldn't hit an elephant at this dist- " 
[email-masked]         |    - Last words of Union General John Sedgwick,
                      |    Battle of Spotsylvania Court House, U.S. Civil War

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

From: [email-masked] (Dan Pop)
Subject: Re: GNUStep...Is It Real or Just a Hoax?!?
Date: Sun, 16 Oct 1994 21:29:37 GMT

In <[email-masked]> [email-masked] (Marc Fraioli) writes:

>In article [email-masked],  [email-masked] (Dan Pop) writes:
>>
>>It's slightly more than $4000 for the base model, which doesn't include
>>a DAT drive and has no level 2 cache (only 32 KB of L1 cache).
>>
>Are you sure about that price?  I thought it was $3995.  I hadn't heard
>anything about a DAT drive either though.

Last week, IBM made a presentation of the 40P. The price they quoted
for the base configuration was about 7100 CHF and the current exchange
rate is 1 USD = 1.3 CHF.

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

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

From: [email-masked] (Bart Kindt)
Subject: Kernel 1.1.54: Error compiling
Date: Mon, 17 Oct 1994 06:48:30 GMT

I have been trying to compile kernel 1.1.54.
I downloaded 1.1.52 complete, and compiled. No problem.

I patched 1.1.53 and 1.1.54 from the / (root) with: 
patch -p < patch53  (and 54)
I did not see any errors during the patch, but it is imposible to read anyway.

Make config: enable all IP stuff, all else as default.
'Make dep' works ok, 'make clean' ok, 

'make' fails in the area: 
tools/build.c , problems with N_MAGIC, ZMAGIC QMAGIC ,  implicit declar; 
undeclared, incomplete type....
Then stuff about: unused variable 'sb'   and   'major_root' may be used 
uninitialized....
Error 1
End of story.

Is it me doing something wrong? I have been patching from 1.1.19 and never had 
any problems until today.  

Any help appreciated.

Thanks,
Bart.

====================================================================================
Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New Zealand
====================================================================================

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

From: [email-masked] (Hugh Strong)
Crossposted-To: comp.os.linux.help
Subject: Re: Data security under Linux
Date: 14 Oct 1994 13:52:12 GMT

Zack T. Smith ([email-masked]) wrote:
: 1.
: Is there any way to 'wipe' i.e. overwrite with zeros the unused
: space on a Linux formatted partition?
:  
: Thanks for any info,
:  
: Zack Smith
: [email-masked]

Yes.  If you use ext2fs, there is an attribute available ('s' I think)
which will mark a file for secure deletion.  Check out the man pages
for lsattr (1) and chattr (1).  It goes without saying that this
must be done BEFORE you delete the file. 

                                                -- Hugh Strong
                                                [email-masked]

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

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