Tech Insider					     Technology and Trends


		   Linux Activists Mailing List Archives

From: kaufman@eecs.nwu.edu (Michael L. Kaufman)
Subject: Lets make it easier on the new folks
Date: Mon, 27 Jan 1992 03:58:55 GMT

I have an idea.  As more and more people get involved with Linux, they
will be going to ftp the software from the sites. I just tried to get the 
software and there were about eleventy-dozen directories to go through. How 
about lets make a big tar files with everything (including the diskwrite, and 
shoelace utilities) that a new person who wants to get the works will need.
Or, if that would be too large, how about a file that contains a list of the
files.  Just an idea.

Michael

-- 
Michael Kaufman | I've seen things you people wouldn't believe. Attack ships on
 kaufman        | fire off the shoulder of Orion. I watched C-beams glitter in
  @eecs.nwu.edu | the dark near the Tannhauser gate. All those moments will be
                | lost in time - like tears in rain. Time to die.     Roy Batty 

From: h108373@cs.tut.fi (Hakkarainen Kimmo)
Subject: Re: Lets make it easier on the new folks
Date: 27 Jan 92 15:45:33 GMT


kaufman@eecs.nwu.edu (Michael L. Kaufman) writes:

> I have an idea.  As more and more people get involved with Linux, they
> will be going to ftp the software from the sites. I just tried to get the 
> software and there were about eleventy-dozen directories to go through. How 
>about lets make a big tar files with everything (including the diskwrite, and 
> shoelace utilities) that a new person who wants to get the works will need.
> Or, if that would be too large, how about a file that contains a list of the
> files.  Just an idea.

The big-tar-file is not the best aproach because these files will not
fit in floppies.

I think that the list of programs and their locations should exist. The
promblem is that there is not the absolutely right place for every utility.
At the moment I have five directories for binaries. The first excuse is
that directories containing at least 1,4 MB of disk space are not easy
to back up. The second is the ease of update utilities in groups, (as
fileutils).

I think that everyone who is porting something should include a readme-file
to tar file. That would contain information about location or something
like that. 

kimmo

--
Kimmo Hakkarainen (h108373@cc.tut.fi)

From: abc@banjo.concert.net (Alan B Clegg)
Subject: Re: Lets make it easier on the new folks
Date: 27 Jan 92 18:09:16 GMT

In article <H108373.92Jan27174533@naakka.cs.tut.fi> 
h108373@cs.tut.fi (Hakkarainen Kimmo) writes:
>The big-tar-file is not the best aproach because these files will not
>fit in floppies.

Right.  There must be smaller parts available, but each must be self-sufficient
and self-documenting.

>I think that the list of programs and their locations should exist. The
>promblem is that there is not the absolutely right place for every utility.
>At the moment I have five directories for binaries. The first excuse is
>that directories containing at least 1,4 MB of disk space are not easy
>to back up. The second is the ease of update utilities in groups, (as
>fileutils).

Yes, there is an absolutely right place.  We just have to create it.
Obvisously, cat, dd, and related programs belong in /bin.  mtools, less,
and relatives belong in /usr/local/bin.  Now, do we cross-link /usr/bin and
/bin like SunOS has done?  Do we put all "required-to-run-single-user" binaries
in /sbin?  I would like to form a mailing list of people that are interested
in helping out in setting some standards for directory locations.  The current
state of affairs *MUST NOT CONTINUE*

With the current state of affairs, I am almost 100% sure that nobody has the
exact same file structure!  I have created a file system mirror on
banjo.concert.net in ~ftp/pub/Linux/Release with what I think the file system
should look like.  Please look it over!  It holds all sym-links to make 
the system run, as well as all binaries that I could find, and source moved
into what I believe to be the correct places.

>I think that everyone who is porting something should include a readme-file
>to tar file. That would contain information about location or something
>like that. 

Yes.  Every tar file should contain information on where the binaries and
source should live.  Many of the current binary distributions were created
from the file system root (tar cf thing.tar /usr/bin/thing*) and that is *NOT*
acceptible [IMHO, of course].

We have to created a standard environment for the common locations for
files, and it needs to occur soon.. [before 0.13??]

Please contact me via e-mail if you wish to have input on the formation of
standardized places and standardized methods of file distribution.

-abc
-- 
abc@concert.net                         Alan Clegg - Network Programmer
                                        MCNC -- Center for Communications

From: tthorn@daimi.aau.dk (Tommy Thorn)
Subject: Comments to Directory Standard (banjo.concert.net)
Date: 28 Jan 92 14:53:29 GMT

I think that we should develop standards/recommendations for most things, like:
kernel patches, portede programs, directory structure, and so on. It would
ease the cooperations a lot. Of course, these are not enforceable.

Alan B Clegg writes:

   Yes, there is an absolutely right place.  We just have to create it.
   Obvisously, cat, dd, and related programs belong in /bin.  mtools, less,
   and relatives belong in /usr/local/bin.  Now, do we cross-link /usr/bin and
   /bin like SunOS has done?

Not if it can be avoided. But what is the real difference between /bin
and /usr/bin?

   I would like to form a mailing list of people that are interested
   in helping out in setting some standards for directory locations.  The
   current state of affairs *MUST NOT CONTINUE*

Hear! Hear!

   I have created a file system mirror on banjo.concert.net in
   ~ftp/pub/Linux/Release with what I think the file system should look like.
    Please look it over!

Well, things like lesskey.man less.hlp zip* unzip mkdir mkfifo ..
surely doesn't belong in /usr/bin. The available less is configured
wrongly. less.hlp belongs, I think, in /usr/local/lib/less.hlp

zip* unzip in /usr/local/bin

mkdir mkfifo in /bin

AND NO link to any of these

Personally, I think that we should try to put things where they belong under a
"normal" unix, including any of the GNU utilities. We don't need any
/usr/local/gnu or /usr/gnu dirs, they are only for sites having the gnu stuff
as an alternative to the standard utilities. We should also avoid gxxx, like
in gld, perhaps with the notable exection of gcc.

   Yes.  Every tar file should contain information on where the binaries and
   source should live.  Many of the current binary distributions were created
   from the file system root (tar cf thing.tar /usr/bin/thing*) and
   that is *NOT* acceptible [IMHO, of course].

We need to make installation REAL SIMPLE AND FAST. I suggest the
following standard for distributing ported programs.

Everything should be contained in a [compressed] tar file with a:

  - README, a short explanations of how this version differs from
    the original, if it does, and how it was compiled.

  - PREREQUIST, again which kernel, but also which version of the
    original.

  - Makefile, not for compilation, but for installation!! After having
    checked that you agree with paths and so, you just type 'make install'
    perhaps as root.

  - Patches, context diff against the original.

  - Binaries

  - Optionally, manual pages, also with full path.

Kernel patches should also be a [compressed] tar file containing:

  - README, describing what the patch does/is.
  - PREREQUIST, a precise statement of which version of the
    kernel the patches applies, and which, if any, patches that
    was already applied.

Sources belong in /usr/src, linux sources in /usr/src/linux, etc.

Maybe we should split patches and binaries, but I don't like that, as you
would properbly end up having only one of either.

/Tommy
--
Tommy Thorn                       email: tthorn@daimi.aau.dk
Computer Science Department       "People shouldn't work because they love it,
Aarhus University                  they should work because it hurts."
DENMARK                            -- Bob Sparacino, former Xerox executive

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/