Very Computer

Have fun

Hannes
------
Hannes Reinecke                      |

                                     |  
PGP fingerprint available            |          T.Pratchett: Small Gods
see  'finger' for details            |          

ftp://zarquon.mathi.uni-heidelberg.de/pub/Linux/Net/amd-bin.tar.gz

Have fun

Hannes
-------
Hannes Reinecke                      |

                                     |  
PGP fingerprint available            |          T.Pratchett: Small Gods
see  'finger' for details            |          

: The hacked amd (+docs) can be found at
[..]

Would be nice if you provide a patch against the original sources so
everyone could build it on her/his own.

BTW, as this additional software, it would be a better style to put them
under "/usr/local".

And it would be nice to have some example maps demonstrating the access of
floppies and cd-roms via amd.

Winfried

ich waere dankbar fuer Deinen Hack.

Gruss,
        Frank.
--
Frank Grieger, MPIfR, Bonn
Hier stellt sich das MPI vor: <http://www.mpifr-bonn.mpg.de/>

The protection of being overwritten is meant for local software, that somebody
which `owns' that machine installed on his own; If you have controll of the
entire system in the upgrade process, e.g. your are the system administrator,
you dont't need that protection.

Quote:>BTW I think it is a bad idea to put additional installed software under /
>or /usr because you may loose them when upgrading the system
>software (e.g. you install a alternative version of SUNs automounter on a
>SUN), the risk is very high for most LINUX-Distributions (as they will come
>with an "amd" by default in future versions).

Besides, usually you want a system upgrade to replace that software, in case
you installed it system-wide. If you don't want to, you deselect the option in
the installation program, which ought to be possible. I believe the solution to
the updating problem lies in a reliable installation and setup programs.

Martin
--

Bogenstr. 9             http://www.comnets.rwth-aachen.de/~ost
52080 Aachen            Germany

: Traditionally '/usr/local' used to contain software local to the machine,
: while /usr contained software to be available on any host.

Maybe traditionally. But we're LINUX-specific and should follow the
FS-Standard (tsx-11.mit.edu:/pub/linux/docs/linux-standards/fsstnd).

BTW I think it is a bad idea to put additional installed software under /
or /usr because you may loose them when upgrading the system
software (e.g. you install a alternative version of SUNs automounter on a
SUN), the risk is very high for most LINUX-Distributions (as they will come
with an "amd" by default in future versions).

Winfried

: The protection of being overwritten is meant for local software, that somebody
: which `owns' that machine installed on his own;

Thats the status of amd (with respect to most LINUX-Distributions) and true
for this case.

: If you have controll of the
: entire system in the upgrade process, e.g. your are the system administrator,
: you dont't need that protection.

Why not? Sorry, I don't know what I have installed on my maschine, this is
far too much (estimating 1 GB software). At least I need this protection.

: Well, dont't you see the problem? Distributions will vary, so will your point
: of view, what is to be put in /usr/local. Now, do you want any packet of
: updated Software too be offered in two ways, either /usr or /usr/local, since
: you never know wheather the user owns a distribution that allready contains
: that stuff?

How can I be sure, that the updated version works correct? To make a copy
of everything before overwriting with the new version is not reliable
enough for a production system and uncomfortable.

The solution ist simple: everything which is not part of a distribution
goes into "/usr/local". It doesn't matter which distribution contains "my"
piece of software, I cannot be sure it will conflict with existing
config-files and so on so I put it under /usr/local (but, thats no
guarantee, of course).

: , usually you want a system upgrade to replace that software, in case
: you installed it system-wide. If you don't want to, you deselect the option in
: the installation program, which ought to be possible.

No! Many packages contain more than one binary and I'm not willing to have
a look at all files of a package before installing it.
And maybe I want to test replacement, before using it ...

: I believe the solution to
: the updating problem lies in a reliable installation and setup programs.

Yes, indeed.

Winfried

It is a problem many people have.  You have a similar one: you waste
too much time tracking what files you have changed.

Solution: all files in the distribution have a 1970 time stamp.
--

Albert Cahalan

I belive that all that tracking could be done by software rather than me.

Quote:>Solution: all files in the distribution have a 1970 time stamp.

Martin
--

Bogenstr. 9             http://www.comnets.rwth-aachen.de/~ost
52080 Aachen            Germany

: >Why not? Sorry, I don't know what I have installed on my maschine, this is
: >far too much (estimating 1 GB software). At least I need this protection.

: Well, that's your personal problem, and has nothing to do with the FS
: standard.

Of course it has. The fsstnd-1.2 says:

  The /usr/local hierachy is for use by the system adminsitrator when
  installing software locally. It needs to be safe from being overwritten
  when the system software is updated.
  [..]
  Note that software plaed in / or /usr may be overwritten by system
  upgrades [..].

So the fsstnd-1.2 grants the protection I need.

: >No! Many packages contain more than one binary and I'm not willing to have
: >a look at all files of a package before installing it.
: >And maybe I want to test replacement, before using it ...
: Again, that holds true with _any_ system update.

When I upgrade my Debain/GNU System, I have a list of what changed from the
previous version (each package).
If I install a XYZ-tar.gz file which is not part of a distribution and
binary-only, I have no clue about the differences against the installed
version - not only regarding to the files, but regarding to the behavior
of the program.
Thats a difference. For my consequences see below.

: In your previous posting, you addressed the issue of complying to standards.
: Now, the standard doesn't support your point of view.

I'm still addressing the complying of standards and the standard support
"my point of view" (sorry for citing it again):

  Loally installed software should be placed whitin /urs/local rather than
  /urs unless it is being installed to replace or upgrade software in /usr.

Would you speak of a "replacement" or an "update" in case of the provided
"amd"-binary? (Of course very recent distributions contain the "amd" but
they provide the same version ...).
At least for Linux, it still has the status of "extra" or "optional"
software.

  Note that software placed in / or /usr may be overwritten by system
  upgrades. [..] For this reason, local software should not be placed
  outside of /usr/local without good reason.

The consequence for me is (but that is not explicitly stated by the
fsstnd): all software that is not a package of a distribution should
go to /usr/local . This is a more comfortable (the only possible) way I can
be sure "this special version" is not overwritten the next time I upgrade
my distribution.

Of course my original suggestion "put the binary under "/usr/local" is no
"real" solution to the problem of "try before you buy" as it may overwrite
existing binaries.
The right way would be to put it under /usr/local/src/amd-.*  and let the
amd-Makefile do the installation. This way I can test it out before it
overwrites _any_ of my already installed binaries.

: I don't care, but please consider this before asking others to switch
: from standard installation to  other places.

Nonsense. If you wouldn't care, you wouldn't post this.

Winfried

Quote:>I'm still addressing the complying of standards and the standard support
>"my point of view" (sorry for citing it again):

>  Loally installed software should be placed whitin /urs/local rather than
>  /urs unless it is being installed to replace or upgrade software in /usr.

Quote:>: I don't care, but please consider this before asking others to switch
>: from standard installation to  other places.

>Nonsense. If you wouldn't care, you wouldn't post this.

Well, this leads to nothing. Either you agree that local means one machine at a
site, or you dont't. Further argueing doesn't make sense. But maybe some native
English speaking person could shed some light into this?

Bye, Martin
--

Bogenstr. 9             http://www.comnets.rwth-aachen.de/~ost
52080 Aachen            Germany

: Well, you obviously got a different view of local than me.

I think the fsstnd makes it more or less clear what to install
under "/usr/local" without defining what the word "local" ("local
software"?) means: software that should not be overwritten with the next
system-upgrade.

Of course you can define what "local" is to you and argue what software you
put under "/usr/local" and why.
Becomes more difficult, if you do it for "etc". Config-files under "et
cetera" ...

: Well, this leads to nothing. Either you agree that local means one machine at a
: site, or you dont't.

As I said, the fsstnd is independent of the meaning of "local".
As far as I remember, this was done to avoid such discussions ... they lead
(and led) to nothing.

: Further argueing doesn't make sense. But maybe some native
: English speaking person could shed some light into this?

I even don't see how a native English speaking person can define a word
with a that generall meaning. "local software" would be easier.
And perhaps this person can shed some light into the fact that all
config-files reside in "etc" ...

Winfried

Besides, you may not want to have that software update in case the distribution
supports it, but other people would enjoy it. And if your point of view would
be correct, it would have been easy for the fsstnd team to recommend that any
package that's not distributed within a distribution should be compiled to fit
/usr/local. They didn't.

Quote:>As I said, the fsstnd is independent of the meaning of "local".
>As far as I remember, this was done to avoid such discussions ... they lead
>(and led) to nothing.

Quote:>: Further argueing doesn't make sense. But maybe some native
>: English speaking person could shed some light into this?

>I even don't see how a native English speaking person can define a word
>with a that generall meaning. "local software" would be easier.
>And perhaps this person can shed some light into the fact that all
>config-files reside in "etc" ...

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.

Martin

PS.: I won't contribute further to this thread, as I said anything I could
possibly think of - I would like it however, if others would supply arguments
for either cause.
--

Bogenstr. 9             http://www.comnets.rwth-aachen.de/~ost
52080 Aachen            Germany

Quote:> 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

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.)

Quote:> 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.

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

Kai
--

Quote:>>> PFM-Mainz.de distributes mail bombs. <<<