Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA22296; Sat, 30 Sep 95 05:16:12 EDT
Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP
	id AA03197; Sat, 30 Sep 95 05:15:44 EDT
Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.12/2.3JIK) id FAA11908 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Sat, 30 Sep 1995 05:14:00 -0400
Message-Id: <199509300914.FAA11908@senator-bedfellow.MIT.EDU>
From: Digestifier <Linux-Development-System-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development-System@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU
Date:     Sat, 30 Sep 95 05:13:56 EDT
Subject:  Linux-Development-System Digest #864

Linux-Development-System Digest #864, Volume #1  Sat, 30 Sep 95 05:13:56 EDT

Contents:
  Re: help w/ glibc make (Bill Hogan)
  Re: Anyone working on /ftp fs? (H. Peter Anvin)
  Re: /proc/dev: virtual device entries (/dev replacement) (H. Peter Anvin)
  Re: non-GNU C++ compiler? (David Fox)
  DRQ error with my IDE (root)
  Re: NeXT floppies? (Chris)
  Re: Proposal: LASP (Linux Application Standards Project) (Kai Henningsen)
  Re: Idea: Generic BIOS disc driver (Kai Henningsen)
  Re: FSSTND: meaning of /usr/local ? was: SUCCESS: automatic floppy/cdr (Kai Henningsen)
  Re: Proposal: LASP (Linux Application Standards Project) (Kai Henningsen)
  Re: Macintosh Re: Linux File System (Kai Henningsen)
  Re: USEP-0.0.2 (Davor Cubranic)

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

From: Bill Hogan <bhogan>
Subject: Re: help w/ glibc make
Date: 30 Sep 1995 05:28:31 GMT

What `glibc' are you talking about?

  Last time I looked, GNU `glibc' has not been ported to Linux.

   Bill


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

From: hpa@loki.yggdrasil.com (H. Peter Anvin)
Subject: Re: Anyone working on /ftp fs?
Date: 30 Sep 1995 06:04:20 GMT
Reply-To: Peter.Anvin@linux.org (H. Peter Anvin)

Followup to:  <44hgsp$jt5@cwis-20.wayne.edu>
By author:    tom@tom.cc.wayne.edu (Thomas R. Stevenson)
In newsgroup: comp.os.linux.development.system
> 
> Would I do an archie search on ftpfs or userfs or what? Thanks!
> 

Like most other Linux stuff, it's on sunsite:

trantor 117 % cd /ftp/sunsite.unc.edu/pub/Linux/ALPHA/userfs
trantor 118 % ls
INDEX              INDEX.short.html   userfs.lsm
INDEX.html         userfs-0.9.tar.gz
trantor 119 % 

Make sure you get the 0.9.1 patch also -- I guess it is still in
Incoming.

        /hpa

-- 
PGP public key available - finger hpa@terminus.storm.net
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

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

From: hpa@loki.yggdrasil.com (H. Peter Anvin)
Subject: Re: /proc/dev: virtual device entries (/dev replacement)
Date: 30 Sep 1995 05:52:49 GMT
Reply-To: Peter.Anvin@linux.org (H. Peter Anvin)

Followup to:  <DFoKA0.Is9@gcs.com>
By author:    danm@gcs.com (Dan Miner)
In newsgroup: comp.os.linux.development.system
>
> During my last episode with too many partitions on an HD, I discovered
> an idea for making major/minor numbers rather dynamic and almost pointless
> for users to know.  It's mostly device registation change.
> 
> A device driver would register itself somewhat like is done now except
> it would receive a "major" (call it a device id).  At this point, you
> still can't "access" the driver.  It needs to register logical devices.
> Here is where the "minor" would be available for registation in any way
> the driver sees fit.  Now in the /proc, it would have a directory called
> /proc/dev which contains the device entries as the ones found in /dev.
> Here is an example sequence:
> 

Dynamic devices have a lot of problems associated with it, primarily
loss of permissions, but also booting in limited spaces (e.g. boot
disks).  This is really only a problem for SCSI disks, and we're
already working on 16-bit minor number support, at which time there
will be no problem allowing for lost of drives and lots of partitions.

        /hpa
-- 
PGP public key available - finger hpa@terminus.storm.net
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

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

From: fox@graphics.cs.nyu.edu (David Fox)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: non-GNU C++ compiler?
Date: 30 Sep 1995 03:17:20 GMT

In article <44hjqv$1oi@news.udel.edu> rshutt@extacy.cwt.udel.edu (Randall Shutt) writes:

] >No, you are not close, and you deserve *serious* flames.  Only post
] >when you have direct knowledge or experience in the future.
] 
]   Are you some kind of retard?  DO you think you are GOD telling this poor 
] huy what to post and what to not post.  Well, here is a truely informative
] piece of direct knowledge gained from experience.  
] 
] jbuck@synopsys.com is a fascist, elitest, scum of the internet, wanna
]                               be genius. 

Just great, defending everyone's right to mislead everyone else
without fear of criticism.  I guess the important thing is for you
to feel good about yourself, right?  This "everyone's opinion is
just as valid as everyone elses" crap belongs in a group therapy 
session, not here.
-- 
                    http://found.cs.nyu.edu/fox/
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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

From: root <root@serv01.net-link.net>
Subject: DRQ error with my IDE
Date: 29 Sep 1995 23:29:16 GMT

Got a nifty little error popping up after adding another 1.275 Gig conner
to my system.

  Running: Linux 1.2.13
           Micron Pentium 100 / 32 meg ram
           2 1.275 Gig Conner   
           IDE on the motherboard

Sep 29 18:51:09 leol kernel: hdb: DRQ error: status=0xd0 { Busy }
Sep 29 18:51:10 leol kernel: hdb: DRQ error: status=0x52 { DriveReady
SeekComplete Index }
Sep 29 18:51:11 leol kernel: ide0: do_ide_reset: success


Sometimes it recovers, other times it will hang with the drive light on, it
takes a power down to bring it back to life, naturally the FS is corrupt.

Do I have a dumb/Broken IDE controller?
Any insight welcome.

Thanks
        Chris

Please reply with email: chris@serv01.net-link.net


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

From: gt1355b@acmey.gatech.edu (Chris)
Subject: Re: NeXT floppies?
Date: 29 Sep 1995 17:56:45 GMT

C Shamis (cshamis@erinet.com) wrote:
: Bill Burris (burris@Phys.UAlberta.CA) wrote:
: : 
: : Has anyone written a driver, or working on a driver to read NeXT
: : floppies on Linux?

: NeXT's used flopitcal drives, not floppy-floppies.

: Didn't they?

No, they use 2.88 meg floppy drives that can read and write FAT, HFS (macintrash
), and NeXT (kinda like BSD) file systems.  I've heard that there is a kernel
patch to read/write NeXT file systems, but I don't know where it would be.  Try
the LSM.

chris
--
Chris Ricker : gt1355b@prism.gatech.edu : The Georgia Institute o' Technology
"I got a threshold, Jules.  I got a threshold for the abuse I'll take.  And
you're crossing it.  I'm a race car and you got me in the red.  Redline
7000, that's where you are.  Just know, it's...dangerous to be drivin' a 
race car when it's in the red.  It could blow."  --Vincent Vega--

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

Date: 30 Sep 1995 01:32:00 +0200
From: kai@khms.westfalen.de (Kai Henningsen)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Proposal: LASP (Linux Application Standards Project)

mrd@ecs.soton.ac.uk (Mark Dobie)  wrote on 18.09.95 in <43jr9e$lmv@marr.ecs.soton.ac.uk>:

> In <5triJFfzcsB@khms.westfalen.de> kai@khms.westfalen.de (Kai Henningsen)
> writes:

> >That, I have to see to believe. X "out of the box" is missing just about
> >everything those other systems have, also "out of the box".
>
> I don't know. After all, you can set up colours, fonts and screen
> backgrounds, play with window decorations and desktop layout and have a
> powerful root menu system and virtual desktop at your disposal.

Most (all?) of which needs firing up your trusty old text editor ... this  
is supposed to be a GUI. Other systems come with support for changing  
whatever of this they consider changeable.

> What sort of things were you thinking of?

How about, what's generally called a desktop? That includes a *lot* of  
functionality. *All* of the other systems have it. The Mac Finder, the MS  
Windows File and Program Managers, the OS/2 WPS - the X nothing. This is  
an *essential* part (more like two thirds) that's missing completely.

> >For example, have a consistent user interface. I'd say that's about 70% of
> >the job a windowing system has to do, and X fails.
>
> It is consistent - all the windows have consistent decoractions and
> respond the same to user interaction. If anything, this is more

Tell another one, this one wasn't even funny.

> consistent in X (where the window manager is in control) than in MS
> windows 3.x (where apps can do what they like on the desktop).

Just plain wrong. That's probably because of the X concept of "window  
decorations", which doesn't exist elsewhere for the simple reason that  
it's broken by design. Other systems have *lots* of system-provided  
interface elements, which include what X calls "window decorations" (as if  
those things were only for looks instead of for function!) but certainly  
are not limited to those. For some nontrivial examples, take file  
selectors or color selectors, but menus and dialog controls are just as  
important.

> If you're talking applications, then it's 70% of what a *GUI toolkit*
> has to do. How applications use the toolkit is up to them. You get
> inconsistent apps in MS windows too.  The difference with X is that
> there is a choice of toolkits, so you get a wider variety of behaviour.

First, there are bad programs everywhere. The majority of programs,  
however, is consistent even under MS Windows.

Second, that "wider variety of behaviour", as has been pointed out a  
number of times, is a bug, not a feature.

> >> Example: For years the size of text in a MS windows title bar was hard
> >> coded into the hardware display driver.
>
> >Ah yes. And that's *inconsistent*? ROTFL.
>
> Of course it is inconsistent - why should my font change when I change
> to 24 bit colour mode?

I don't like windows at all (I much prefer either MacOS or OS/2), but this  
is ridiculous.

> >Windows is ugly, yes. But X is ugly too.
>
> X is only as ugly as you configure it :)

You can't configure it non-ugly.

Kai
--
>>> PFM-Mainz.de distributes mail bombs. <<<
Internet: kai@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/~kai/

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

Date: 30 Sep 1995 01:52:00 +0200
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Idea: Generic BIOS disc driver

ericg@unixg.ubc.ca (Eric Gisin)  wrote on 22.09.95 in <43td4c$e5a@nntp.ucs.ubc.ca>:

> Do you need to go into V86 mode or 16-bit protected mode to call the BIOS?
> The later is much faster, and I remember OS/2 1.? called the BIOS from
> protected mode. I wonder why OS/2 dropped support for BIOS disk I/O later
> on?

Surprise: it didn't.

If you want to use *any* BIOS-supported disk with OS/2, just load a device  
driver named ibmint13.i13 (now what could that name possibly imply ...)

Sure, it's slow. But it *works*.

Shouldn't Linux be able to do what OS/2 can? Surely IBM doesn't have  
better programmers?

Kai
--
>>> PFM-Mainz.de distributes mail bombs. <<<
Internet: kai@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/~kai/

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

Date: 30 Sep 1995 02:13:00 +0200
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: FSSTND: meaning of /usr/local ? was: SUCCESS: automatic floppy/cdr

ost@comnets.rwth-aachen.de (Martin Ostermann)  wrote on 25.09.95 in <4450rt$6ti@zruty.comnets.rwth-aachen.de>:

> I didn't mean to explain somebody the English word `local' (or `etc') but to
> evaluate what the FSSTND could have meant. E.g. it states "The /usr/local

What the FSSTND meant, and what was discussed it seems like every month on  
the FSSTND mailing list, is that /usr/local is for software the admin  
grabs from the net and installs, while all the rest is for software that  
comes with the distribution, that is, as one big package.

There is no "the admin must do this" as the FSSTND doesn't address admins.  
It addresses distributors. According to the FSSTND, admins can do whatever  
they want.

However, distributors cannot - they *have* to leave /usr/local alone.

Now, the obvious conclusion is that the *default* installation of a single  
software package - like amd - should be in /usr/local *if* it's expected  
to be installed by individual admins. If it's primarily addressed at  
distribution creators, it should keep out of /usr/local.

And there is one important exception: stuff that "belongs" into other  
places should go there no matter what. (This one is fuzzy by design.)

> On the other hand, /usr/local is nothing the fsstnd created. It has a long
> tradition within the Unix comunity, thus not defining it would mean
> compliance to the old terms.

That tradition, of course, matches what the FSSTND defines.

None of which have anything to do with host-local versus site-wide. That's  
a completely different issue.

Kai
--
>>> PFM-Mainz.de distributes mail bombs. <<<
Internet: kai@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/~kai/

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

Date: 30 Sep 1995 02:38:00 +0200
From: kai@khms.westfalen.de (Kai Henningsen)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: Proposal: LASP (Linux Application Standards Project)

rpj@ise.canberra.edu.au (Ross Johnson)  wrote on 23.09.95 in <440fgf$bjj@csc.canberra.edu.au>:

> As you've just illustrated, there's nothing in any of these windows systems
> that forces consistency. It's entirely voluntary. What we see as

Nope. It's not entirely voluntary.

However, that was not the point. The *point* is that *users* want  
consistency. And they want it really bad.

> "consistency" probably has more to do with the restricted number of widget
> libraries available for use in the system. That doesn't in itself lead to
> consistent or intuitive applications.

Interestingly, *only* those "restricted" systems have consistent and  
intuitive applications. X has th opposite. I'm willing to convict on that  
data.

> >Unfortunately, the window manager concept of X prevents us from having
> >standardized ways to do things.
>
> No it doesn't. It does, however, encourage experimentation, exploration, and
> diversity. These are admirable traits.

Umm ... that's not "No", that's just a different way of stating the same.

And when I compare the amount of "experimentation, exploration, and  
diversity" under X and, say, under MacOS - the answer is that MacOS does  
quite enough of encouraging, and X goes way overboard in that respect. And  
that is not an "admirable trait", but the exact opposite.

Just to emphasize this, other systems *do* have "experimentation,  
exploration, and diversity". They usually have it in that a program  
changes one or two features from the standard. On the other hand, under X,  
there is *no* standard, so they change everything.

That's not "hey, neat idea", that's "why can't those dummies do anything  
like anybody else".


Kai
--
>>> PFM-Mainz.de distributes mail bombs. <<<
Internet: kai@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/~kai/

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

Date: 30 Sep 1995 03:25:00 +0200
From: kai@khms.westfalen.de (Kai Henningsen)
Subject: Re: Macintosh Re: Linux File System

cbbrown@io.org (Christopher B. Browne)  wrote on 27.09.95 in <44c3bl$p2b@ionews.io.org>:

> In article <44ajh6$7vb@srvr1.engin.umich.edu>,
> HASDI RODZMANN HASHIM <hasdi@news-server.engin.umich.edu> wrote:
> >: Yes. but Linux is THE unix itself. What applies to Unix does usually
> >apply to Linux.
> >
> >Since Linux is still a few years old, don't you think it is a good idea
> >to have an improved file system where you can tag information or add more
> >fields? At least, whenever a file is being moved or deleted, there should
> >be some way to signal another program to update the ".AppleDouble".
>
> Impertinent comment: As this is all talking about *Mac* structures,
> shouldn't it be the *Mac* software that handles this?

Of course (to be exact, the Mac-server package running on Unix). I expect  
it usually does.

> The Mac originally needed this sort of thing because it was missing the
> concept of "subdirectories."

Nonsense.

The Mac needs this because Mac files have a different structure than Unix  
files. Besides slightly different information of the type Unix stores in  
the inode (for example, 32 bit each file type and file creator (program)  
info), Mac files consist of two "forks" where Unix files have only one:  
the data fork and the resource fork (a sort of mini database containing  
things like icons, dialog box definitions, strings (good for  
localization), and for 680x0 programs, even the program code).

The obvious way to store these two forks on Unix (and therefore the way  
it's always done) is to use two Unix files. One stores the data fork, one  
the resource fork plus additional file info (like the type and creator  
mentioned above).

It's not only Unix. MacOS can mount MSDOS FAT floppies; when they store  
Mac files on them, a similar same system is used (the additional file info  
goes into a file named finder.dat). Here is a real-life example:


 Volume in drive A is Transport 2    Serial number is 165A:10E2
 Directory of  a:\*.*

RESOURCE.FRK <DIR>     23.09.95  23.43 _H__D
!interfa.tar  1167360  23.09.95  23.49 ___A_
desktop             0  23.09.95  23.43 _H_A_
finder.dat        460  23.09.95  23.49 _H_A_
     1.167.820 bytes in 3 files and 1 dir    1.167.872 bytes allocated

 Directory of  a:\resource.frk\*.*

.            <DIR>     23.09.95  23.43 ____D
..           <DIR>     23.09.95  23.43 ____D
desktop           345  23.09.95  23.51 ___A_
           345 bytes in 1 file and 2 dirs    512 bytes allocated

    Total for:  a:\*.*
     1.168.165 bytes in 4 files and 3 dirs    1.168.384 bytes allocated
       288.768 bytes free

Note that the (hidden) file "desktop" has an empty data fork and a  
nonempty resource fork; all the others are the other way around.

Looking into the (binary) file finder.dat reveals that the Mac names of  
the files on this disk are "Desktop" and "Interfaces.tar", respectively.  
The file type and creator info of these is 'FNDR', 'ERIK' and
'TARF', 'TAR ', respectively.

Ah yes, and there's an empty directory named "Desktop Folder" which has no  
FAT equivalent at all.

> If a document needs to have additional information not previously defined,
> then it's perfectly reasonable to package it up in a *directory,* which
> is a very nice, well-defined way of grouping a set of associated files.

That's probably the reason this system is nearly never used in "real  
life".

> files/"forks" there may be inside.  This seems to me to be much more
> satisfactory than the Apple Way where there are two files.

Nonono. The "Apple Way" has one file, because it also uses HFS (MacOS  
"hierarchical file system" - with subdirectories, you know; those are so  
deeply ingrained in MacOS that the standard way to describe a file (a  
FSSpec) is a triple volume id, directory id, filename) to store those  
files.

When something like a network file sytem has to emulate those forks, it  
usually does all the needed housekeeping. Otherwise, Mac users would get  
upset.

> Perhaps a further conclusion:
>   Software authors should *not* have their programs generate a plethoria
>   of files (myfile.doc, myfile.log, myfile.ndx, myfile.hack) that sit in
>   the current directory.  They *should* create a directory, and place
>   all of those files in the directory.

Well, you tell them! Unfortunately, they don't seem to listen.

Maybe that's the reason MacOS has forks. That way, you can at least keep  
the "little stuff" with the main file. Like the last cursor position or  
the revision control info for a plain text file - the data fork remains  
plain text, so every program that understands plain text can use the file.

A better way to do this (for files that are *not* plain text) is supposed  
to be the OpenDoc file format, Bento. I haven't seen it yet.

Kai
--
>>> PFM-Mainz.de distributes mail bombs. <<<
Internet: kai@khms.westfalen.de
Bang: major_backbone!khms.westfalen.de!kai
http://www.westfalen.de/~kai/

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

From: cubranic@calypso.hermes.si (Davor Cubranic)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: USEP-0.0.2
Date: 28 Sep 1995 21:20:27 GMT

Sander Plomp (plomp@together.net) wrote:

[ about configurability of applications ]

[In summary: 1. lots of configurability makes things more complicated        ]
[            2. multiple ways to configure make things even worse (dotfiles, ]
[               environment variables, Xresources, ...                       ]

: Configurability isn't a goal in itself, it serves a purpose: to allow
: a user to adapt the program to his setup and personal preferences.
: This purpose should be achievable with minimal effort. A system that
: achieves 90% satisfaction with easy to use tools is way preferable
: over one that does all but is too complicated for most users.

In many ways I extremely like exmh's configuration model: there is
a system-wide app-defaults file, but every user can override it with his
own preferences.  Furthermore, user can write his own modules to override
exmh's default ones (so UI can be completely changed, for example).  Nota
bene: _can write_, basic configuration involves nothing more than changing
an entry in Preferences... dialogues.  

IMHO a program should be as configurable as possible from its configuration
file, be it in X resources format or in some other, more structured,
standard (if I remember right, config files in project Athena are organized
around entities or objects -- perhaps someone could provide more details).
For that "90% satisfaction with easy to use tools" all basic options should
be configurable from the program through preference dialogs, like in exmh
or Netscape, for example.  Those more knowledgeable demanding, or just
plain adventurous, could still fire up their trusty vi or emacs on the
(plaintext) configuration file and hack it as much as they need.  
Additionally, if UI is done in, e.g., Tk, there could be the option of
drop-in user modules to completely override the original ones, but this
is not really necessary.


: To keep things simple you need:
:   - a simple configuration model. Too many levels and modes of
:     configuration just confuses matters.
OK, how about this: possibly Xdefaults level (to be discouraged for 
those that don't know what they're doing), system wide application 
configuration, and per-user application configuration (with the 
possibility that some options are settable only in system-wide file 
if that's necessary for the system security).

:   - it should be easy to find out what can be configured, and how
:     to do it. To give a bad example: under windows there is no 
:     standard place (or even name) for 'preferences/options/...'.
How about Options menu with 'Preferences...' and 'Save options' among
other choices (like in Netscape)?  That's logical and sensible enough.
:     And many programs can set most options from the program itself, 
:     but not *all*.
I think only basic options should be settable from preferences menu,
more esoteric ones (like hacking support in exmh) should be left in
config file to keep preferences dialogs concise and simple.

:   - look and feel standards, e.g. guidelines for name and format of
:     the config files. A standard place and subdivision method for 
:     program options. 

How about system-wide in some */lib/app-defaults directory, per user
as dot files in his $HOME or (maybe better) as files in .app-custom
directory of sorts.  All this and other facets of configuration
should be thoroughly fleshed out on the discussion list first, of course.

:   - It should be simple to make authoritative changes in a single
: spot.
:     A user shouldn't be forced to try getting many configuration files
:     to agree on something. 
User would look in his file, sysadmin in app-defaults in this kind of setup.

Interested in further discussion,

Davor

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


** 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-System-Request@NEWS-DIGESTS.MIT.EDU

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

    Internet: Linux-Development-System@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-System Digest
******************************