[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: RH8: wtf do I find APXS ???
- From: -{ Rene Brehmer }- <metalbunny metalbunny net>
- To: redhat-list redhat com
- Subject: Re: RH8: wtf do I find APXS ???
- Date: Tue May 6 13:14:01 2003
On 05 May 2003 15:08:33 -0600, Bill Anderson wrote something about "Re: RH8:
wtf do I find APXS ???" what the universal translator turned into:
> On Mon, 2003-05-05 at 13:56, -{ Rene Brehmer }- wrote:
> > On 05 May 2003 01:43:34 +0300, Marius Andreiana wrote something about "Re:
> > RH8: wtf do I find APXS ???" what the universal translator turned into:
> >
> > > On Du, 2003-05-04 at 17:06, -{ Rene Brehmer }- wrote:
> > > > Hi y'all
> > > >
> > > > Totally newbie here, and totally dumbfound by the way program files are
> > > > spread all over the system when installed....
> > > we can see that :)
> >
> > Actually ... I worked alot with Linux 3-4 years ago ... but haven't touched
> > it since ... so most things are gone out the window ... like starting a
> > fresh ... with a steep learning curve because I have to deal with it at work
>
> Actually the basics are still the same. The file-system has no
> appreciably changed in that time.
No ... but back then I did most of the work directly from X ... this time
I'm trying to avoid touching the machine directly and doing everything by
SSH ... because the machine's gonna be disconnected from external hardware
once it's up and running ... so figured I might as well get used to the SSH
And back then I didn't have the need for anything for what the RPMs offered
... it never became a setup I could use for anything serious ... didn't have
the time to get into it ... so I just never had to really deal with the
system as such ... fstab and inittab was about the only things I had to deal
with...
> rpmfind.net can tell you the same information quicker. There is also an
> rpm on the RH discs that contains an RPM database of all the rpms in the
> distribution. It is installed in a separate location so you can query
> it.
Problem was that I didn't know that I had to install an extra RPM to get it
... figured it was just standard part of Apache for Linux ... plus I though
I had installed everything Apache ... guess I didn't ... haven't had time to
check yet ...
> > >From experience with friends and acquaintances, just getting to the manual
> > can be a trial in itself ... the man system is apparently not transparent
> > enough for all Window jockies to figure out ...
>
> www.linuxdoc.org
> www.linux.org
> www.linux.com
Will check 'em out ...
> > As old DOS and OS/2 man, my biggest challenge have been to learn the Linux
> > way of doing things ... and especially figuring out where the h... RH puts
> > the files ... especially since they seem to change the locations with every
> > distro ... so where I learn to look for things on one machine, is not where
> > to find it on another ... I can't see the benefit of seperating the bins
> > from supports so greatly as it's apparently done on my RH8 ... all I request
> > is bins one place, docs another, conf somewhere third ... and so on ... but
>
> OK, so you put all your binaries in /usr/bin. What happens when /usr
> needs to be mounted on a different partition? There are *many* reasons
> for differentiating the different binary/config locations. This is not a
> redhat-ism, it's been a Unix concept for decades.
Wouldn't the problem be the same, nomatter if the bins were in /usr/bin,
/usr/share/bin, /usr/local/bin, /usr/sbin, /etc/bin, /etc/sbin, or what not
???
I think I found around 16 bin folders on my search ...
I just mean it can be difficult to figure out which bin dir I should go look
in when the RPMs are installed ... or maybe I've just not figured out yet
how to know where it puts everything...
I'm all for the conf being in etc, the docs being in usr/share/doc (believe
it's where they are currently)...
> Another significant benefit: security. By having different binary
> directories, you can have different levels of access to various
> binaries.
> Another one: /usr on it's own parititon, /usr/local on it's own. When
> doing an upgrade/new install, you can wipe out /usr w/o losing all the
> additionally installed software you installed into /usr/local.
>
> > keep bins near bins, conf near conf (okay, most conf are in /etc/ I've
> > found, but still ...). Mike logic says me that /usr/ is user files ... when
> > it's actually where 90% of the bins are ... and user files are in /home/ ...
> >
> > It's merely the naming and organization that seems a bit messy and not
> > entirely logical ... of course I could build everything from scratch and put
>
> It is logical once you understand. Think of /usr as "universal system
> resources' and pronounce it USS-err, as opposed to USE-er, and that may
> help as well. :^)
See ... that's one thing the many "start with Linux" books forget ... they
never mention why the system is laid out the way it is, and why folders are
called what they are ...
But I guess it'll make more sense as I get more Linux machines past my desk
... my work is more configuring the hardware, getting the right drivers, and
testing that the machines work properly ... than actually setting up the
system ... most Linux server buyers wants to do that themselves ... so
luckily this headache is more with my home server ....
Rene
Rene Brehmer
aka Metalbunny
http://metalbunny.net/
References, tools, and other useful stuff...
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]