Linux-Misc Digest #170, Volume #20               Wed, 12 May 99 14:13:12 EDT

Contents:
  Problem with /dev/ttyS2 (Michael Powe)
  Syslog - /var/log/messages - How to Rotate ("Alexander Samad")
  Re: Proper use of /usr/local (Re: The Best Linux distribution?) 
([EMAIL PROTECTED])
  Updating kernel(compiling) (electra41)
  Re: Proper use of /usr/local (Re: The Best Linux distribution?) 
([EMAIL PROTECTED])
  Re: advice learning ([EMAIL PROTECTED])
  Re: How can use Mathematica? (Christopher Mahmood)
  Re: Nonstop flickering display (gus)
  memstat.o and 2.2.5 (Len Cuff)
  Re: A bash question (Alan Gauld)
  redhat 6.0 cd image (Gordon Vrdoljak)
  Re: Proper use of /usr/local (Re: The Best Linux distribution?) (Leslie Mikesell)
  Re: an alias for cd to set PS1=pwd (John Allman)

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

Subject: Problem with /dev/ttyS2
From: Michael Powe <[EMAIL PROTECTED]>
Date: 12 May 1999 01:49:04 -0700

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1


I'm having a strange problem with /dev/ttyS2, which is my dialout
port.  After I've boot up, I can't dial out on it because I get
"permission denied."  The perms are then 644: crw-r--r--.  After I
change the perms to 666: crw-rw-rw-, I then can dial out.  However,
the perms keep getting changed back.  I did not have this problem
until I upgraded to kernel 2.2.7 last week -- that included a complete
system upgrade for all subsidiary elements listed in the kernel
documentation -- pppd 2.3.7 &c.

Any suggestions?

mp

- --
powered by GNU/linux since Sept 1997                 Penguin spoken here
           [EMAIL PROTECTED]    http://www.trollope.org
Michael Powe                                        Portland, Oregon USA
  "Would John the Baptist have lost his head if his name was Steve?"

=====BEGIN PGP SIGNATURE=====
Version: GnuPG v0.9.0 (GNU/Linux)
Comment: Encrypted with Mailcrypt 3.5.1 and GNU Privacy Guard

iD8DBQE3OUB7755rgEMD+T8RAgAuAJ4qAqCA08jh7rWIbd6rL6Pb4h21FwCfbex4
enlSM1arOktV+fw2LEmbyP0=
=vn/M
=====END PGP SIGNATURE=====

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

From: "Alexander Samad" <[EMAIL PROTECTED]>
Crossposted-To: 
alt.os.linux,alt.uu.comp.os.linux.questions,aus.computers.linux,comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup,it.comp.linux,it.comp.linux.setup,linux.redhat.misc,uk.comp.os.linux
Subject: Syslog - /var/log/messages - How to Rotate
Date: Wed, 12 May 1999 17:09:28 +0100

How do I organise to rotate these or limit there size.  I have just pointed
some of our network devices (Cisco Routers + Catalyst) to syslog to my linux
box and boy do they start to fill it up.


Also how can I get the messages from say a specific router placed into its
own file or directory


Thanxs
AlexS

Can you also email please

--

Alex Samad
Pareto Partners
[EMAIL PROTECTED]



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

From: [EMAIL PROTECTED]
Subject: Re: Proper use of /usr/local (Re: The Best Linux distribution?)
Crossposted-To: comp.unix.bsd.freebsd.misc
Date: Wed, 12 May 1999 02:08:30 GMT

Leslie Mikesell <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
        >snip<
:>      I'm still not sure of what you mean.  Are you saying that if the
:>      distribution can install the FooBar package, it should go in /usr
:>      but if you install it yourself later it should go in /usr/local?
: 
: Yes, that's the way the Linux distributions work.

        Hmm, lame.

:>      -This is all assuming that FooBar *isn't* a "system" component, just
:>      an extra package the "distribution" thinks is "cool" enough to let
:>      you install at system install time.
: 
: The point is that it is being maintained by the distribution provider.
: The function of the program is not so relevant as the fact that
: you are out of sync with the distribution. 

        This sounds very close to the Microsoft "Everything is part of the
        OS" idea.  It's a bad idea.

        >snip<
: Linux systems don't put anything in /usr/local.  That is your space.

        Then they put it in /opt or where?

        >snip<
:>      Do you define "distribution" as being the base system (kernel + OS
:>      system components and utilities) or do you define it as the base
:>      system + all the random toys that nearly every single Linux and *BSD
:>      system installer will offer to install for you durring base system
:>      install?
: 
: If it comes with the distribution it doesn't go in /usr/local regardless
: of anyone's concept of whether it is part of the base system or not.

        Ok, then where does it go, /opt, /usr, or someplace else?

: (My take on this is that any program that knows how to call system()
: or popen() includes all the others...).

        Er, huh?

        >snip<
:>      *everything* is "included" (or at least damn close to it) in nearly
:>      all Linux and *BSD "distributions".  The distinction should be
:>      system components vs non-system components.  No sane system defines
:>      it as anything else.
: 
: No one can ever decide that.  The real distinction is whether you want
: to keep your local modified copy after a complete system re-install.

        "system", that's the key word here.  *System* re-install, not system
        + kitchen sink.

: Thus nothing in a system re-install should ever overwrite anything in
: /usr/local.

        Agreed.

        >snip<
:>: If you have /usr/local as a separate partition or a symlink to a directory
:>: in another partition you can safely wipe out your system partition(s) and
:>: reinstall the latest of everything
:>
:>      Define "everything".  The system or the system + extra toys such as
:>      Gimp that the "distribution" may include?
: 
: Everything on the CD/ftp site - the things you expect to overwrite with
: updated versions when you do a complete reinstall.

        On most CD's/FTP sites that pretty much includes 99% of *all*
        software that you could install.

:>: without losing any of the other software you have installed there. If a
:>: system update clobbers anything in 'your' directories you might have to
:>: wade through a backup to sort things out.
:>
:>      "System", that's the key word here, *system update*.  Not system
:>      plus all the neat little toys that every "distribution" allows one
:>      to install at "system" install/update time.
: 
: Why do you want to have to sort these things out from your own additions
: and modifications when it is time for an update?

        I don't have to.  That's what package databases are for.

: With the Linux layout you can keep /home and /usr/local on different
: partitions and simply clobber / and /usr with the new stuff,

        And this is different then any other system, how?  Also, define "new
        stuff".  Do you mean a new version of the system, or a new version
        of Gimp, Enlightenment, MySQL?

: then put any config files worth keeping back in /etc.

        And config files for local apps aren't in /usr/local/etc why,
        exactly?

: If you stick to a strictly controlled upgrade path (like only one *bsd
: flavor) you may not care about this sort of thing, but if you want the
: option of switching to a completely different distribution with a minimum
: of trouble it works out nicely.

        You, I, and most sane people have no problem agreeing that the
        system has no business installing *system* components into
        /usr/local.  It's non-system components into /usr simply because the
        install CDROM thought it would be nice to ship them for optional use
        that dosn't make sense.

        I'm still looking for a single, reasonable reason why any system
        install/upgrade should ever be placing things it might *optionally*
        include like Gimp, Enlightenment, or MySQL into a place like /usr. 
        More over why an RPM, DEB, or <insert package system> wouldn't
        install to the same target prefix as the same app uses when the
        distribution installed it for you.

        It then follows that since Doom shouldn't use a prefix of /usr and
        since the prefix used should be the same regardless of when it is
        installed (optionally durring system install off a CDROM or later
        from a down loaded package), then it should use a non-system prefix. 
        The two common ones are /usr/local and /opt.  Take your pick, but
        installing Doom into /usr because it's "included in the distribution"
        is simply stupid.

-- 
-Zenin ([EMAIL PROTECTED])

        My code is filled with comments!  It's just that my comments are
        written in Perl.

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

From: electra41 <[EMAIL PROTECTED]>
Subject: Updating kernel(compiling)
Date: Wed, 12 May 1999 19:18:13 +1000

I have RH 6.0. It uses kernel 2.2.5-15. Few questions:
a) What the "15" at the back means?
b) I want to compile my own kernel with a lot of stuff set as module.
How can I boot the new kernel, since at boot, RH 6 will find module
dependencies, and will stuck if it couldn't find one.
On previous version(RH 5.1), I still can boot (at least to text mode)
even if it couldn't find the modules.dep.
Thank you.



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

From: [EMAIL PROTECTED]
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: Proper use of /usr/local (Re: The Best Linux distribution?)
Date: Wed, 12 May 1999 07:22:42 GMT

In article <7has01$kea$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Leslie Mikesell) wrote:
> In article <7haktd$7f$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:

> I use most of those things on most of my machines, and am willing to
> waste a couple of dollars of disk space to have them for
> experimentation and reading the manual on the machines that don't
> really need them.

That's not the point -- I don't want things installed unless I decide to
install them and do so myself, in which case both *BSD and Linux would
put them in /usr/local.  It's Linux's insistence on installing things
into /usr because they're on the same CD as the rest of the system
software that's annoying.

> Apache is as much a part of a modern system as sendmail - at least
> my systems.

I won't berate you for using sendmail, this time.

As far as Apache is concerned, I always do a custom installation because
new minor version releases are coming out literally every month, making
whatever's on the CD obsolete pretty much as soon as I get my hands on
it.  From that point on, the beat-ass version of Apache under /usr will
never be used, unless that's where I install *my* version, which would
then be wiped out during a system upgrade with another [obsolete]
version.

> Installing them is optional.  That's not the point. You should be
> able to have your own modified copy and it shouldn't have to live
> in the same place as the distribution version.

I don't really agree with the "optional" part -- I was never asked if I
wanted *particular* applications installed, just which "distribution" I
wanted.  Technically you're right, I could have stuck with a bare-bones
install, but "all-or-nothing" isn't my idea of a decent option.  Better
to browse through a FreeBSD-style ports collection.

Furthermore, if you have your own modified copy of an application, why
on earth would you need the distribution version at all?  There's no
point in putting non-system applications in /usr, except for bundling
reasons.

> But I *want* the apps upgraded along with the system,

Then upgrade them yourself.  Compared to a system upgrade, it's trivial.

>  Isn't it
> counterproductive to have to think about whether someone else
> considered something a part of the base system or not and whether
> or not you installed a modified version that you want to keep?

Huh?  If it's part of the base system, it's in /usr.  If I installed a
modified version, it's in /usr/local.  Nobody installs anything in
/usr/local but me.  Nothing gets installed into /usr except during a
system install or upgrade.  I fail to see any chance for confusion.

> I don't understand your arbitrary distinction between system
> and non-system, or how it relates at all to local modifications.

It's not my distinction [in that I didn't come up with it], it's not
arbitrary, and local modifications only apply to non-system
applications.  This is the way it's always been, before Linux came
around and decided to do things bass-ackwards to make their installs
simpler at the expense of creating compatibility and administrative
problems.

> Symlinks are quick and easy.  Perl is just about the only thing that
> really needs to appear in /usr/local/bin because the path is
> regretably hard coded in too many places.

What you call "regretable" others call "standard".

> It also needs to appear
> in /usr/bin on Linux for the same reason.

...which is undeniably wrong.  /usr/bin is perl4, not perl5.  Many,
many, many install scripts depend on this.  perl4 is stable and is
frequently used to install other basic software [such as perl5!], which
is why it's included on *BSD under /usr/bin.  The latest version of
perl, to be installed by the admin, goes in /usr/local/bin.

I suppose perl serves as a perfect example of what is meant between
"system" and "non-system", in a more traditional context.  Things are
"system" if they've been around long enough that they're not really
going to change any more [eg sh, ksh, perl4] and are common dependencies
for other applications.  If an application is completely "optional" or
undergoes frequent revisions, it's "non-system".

Basically, if you can modify it without screwing up your whole system,
and have a *reason* to modify it, it shouldn't have been in /usr in the
first place.

--
-Bill Clark
Systems Architect
ISP Channel
http://locale.ispchannel.com/


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

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

From: [EMAIL PROTECTED]
Subject: Re: advice learning
Date: Wed, 12 May 1999 16:31:51 GMT

Try RedHat Secrets 5.2 (if you're using RedHat).  It's a pretty good
book and can be found at most big stores.

I have a small review of it http://www.emuse.net/linuxbooksrecommend.htm

http://www.emuse.net is a small Linux portal I put up to help me in my
daily linux work.  It's got Linux links, linux books, linux download
sites, linux newbie help, etc.

Hope that helps,

Randy

In article <[EMAIL PROTECTED]>,
  Los <[EMAIL PROTECTED]> wrote:
> Carlos m>>> I am a fairly new linux user, I am looking for soem advice
> as far as resources , there's so much, I want some guidance as into
what
> to read and what is garbage,, I have mastering linux, linux for
dummies,
> and special edition using linux, But still There might be something
> better,, I got thru the installation part pretty easy,, I only had
> trouble with my sound card which is not supported that's all,,,
Thanks,,
>


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

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

From: Christopher Mahmood <[EMAIL PROTECTED]>
Subject: Re: How can use Mathematica?
Date: 11 May 1999 05:18:57 -0700

John Girash <[EMAIL PROTECTED]> writes:

> So instead of making a (possibly incorrect) statement, I'll ask a question:
> why would one, having legally purchased a copy of Mathematica whilst a
> student, have any reason to pay Wolfram more $$$ for the exact same software?
> I guess I (incorrectly) inferred that there was a licence-renewal scheme in 
> place to enforce the double payment.
I don't speak for Wolfram, but I have a bit of experience with Mathematica
licenseing.
Wolfram swears the student and full versions are identical and as far as i can
tell they are.  This wasn't always the case-- I remember when the win3.1 
student version wouldn't use the x87 chip and limited the amount of mem.

The only differences I've found are the obvious ones:  the student version prints
"Mathematica for Students" on every postscript page, title bar, etc. and doesn't
come with a hardcopy of the Mathematica tome (although it comes on disk).
It does come with a t-shirt though!

> 
> Part of my confusion also arises out of the occasional "do not buy Mathematica
> b/c of the registration process" complaints that show up on usenet; a deja.com
> search on (past) "mathematica register" will give some of them if you can wade
> through all the "LEO-Archiv" hits.  My concern is largely due to the following 
> anecdote:
> 
> 1. User legally purchases Mathematica, installs/registers it, it works fine.
> 2. User's harddrive crashes; manufacturer sends a larger one as replacment.
> 3. User restores system from backup.
> 4. Mathematica no longer accepts the old registration key.
> 5. User contacts Wolfram and is told that the registration key is hardware-
>    dependent, and pretty much any system upgrade will require a new key.
It true for the most part.  When i bought my first copy of 3.0 (two years ago?),
EVERY time you recompiled the kernel you had to go through the registration
process again.  I bought another copy about a month ago for a second machine
and have since upgraded the kernel three times without Mathematica 'noticing'
so maybe they've softened the license checks a bit.

With that said, it's an excellent product and well worth $150.
-ckm

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

From: gus <[EMAIL PROTECTED]>
Subject: Re: Nonstop flickering display
Date: Wed, 12 May 1999 17:52:44 +0100

Telnet in from a remote machine. Modify the startup so that it opens a
console, not an xdm. Then swap the monitor for one that works.

If this does not work, then the Video card is probably dead. If it does,
then the monitor is probably dead.

Cheers

gus

david letchumanan wrote:
> 
> Hi there, I am not sure of previous posting of this question right.  So, I
> 
> am doing it again.  We have a pritserver running S.u.S.E 5.1 Linux.  A
> 
> while ago we just swapped the monitor without any changes to the
> 
> xf86setup.  It was working fine.  Yesterday I did a "shutdown now -r" on
> 
> it.  PC came back upto starting xdm...,(it goes into xwindow straight) but
> 
> the the display won't come up.  Just keeps flickering.  We are unable to
> 
> stop this.  (We tried "Ctrl+Alt+F1" and no help).  PC is functioning and
> 
> the printing is just fine.  Just the flickering display.  Please help.
> 
> How can we get in.  We do not have boot disk.  Thanks.  David L (one of
> 
> the newbie)
> 
> ------------------  Posted via SearchLinux  ------------------
>                   http://www.searchlinux.com

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

From: Len Cuff <[EMAIL PROTECTED]>
Subject: memstat.o and 2.2.5
Date: Wed, 12 May 1999 18:39:24 +0100
Reply-To: Len Cuff <[EMAIL PROTECTED]>

Can anyone help please.
Scenario -- SuSE 6 loaded and working on kernel 2.0.36. Decide to
upgrade to kernel 2.2.5. All goes well, boots fine and working. xosview
won't work any more so get new version + library needed. Install and
xosview works again.

Changed my SCSI card from AVA1505 to AHA1542 and the system decided to
chew my SCSI drive. Put old 1505 back in and get system almost back.
Restore 'most' things from tape and all seemed to work again. Tried
xosview and back to not working again. Tried re-install (rpm's) and get
the following message :-

/lib/modules/misc/memstat.o : unresolved symbol(s). when I try to rpm
xosview.

I have recompiled the kernel and all is fine but memstat.o doesn't
change. I know I've missed the obvious but I'm damned if I can see it !!
Cheers,
        Len

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

From: Alan Gauld <[EMAIL PROTECTED]>
Subject: Re: A bash question
Date: Wed, 12 May 1999 13:48:04 +0100

Niel Markwick wrote:
> > command. However, I want the exit status of statement 1 while not
> > breaking the pipe.
> This is not possible with a pipe, because with a pipe, both commands
> execute simultaneously - you will have to use temporary files.

Or you might be able to use a tee in the pipeline to 
capture status in the intermediate file. You could 
then wrap statement2 in a shell script that checks 
the tee output - which can include stderr...

Not always possible tho' and a real performance killer!

Alan G.

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

From: Gordon Vrdoljak <[EMAIL PROTECTED]>
Subject: redhat 6.0 cd image
Date: Wed, 12 May 1999 10:59:34 -0700


==============3862F0DEADA31846C4526B9E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,
I was wondering if there was any site I could download the entire redhat
6.0 cd from.

--
Any comments appreciated.  Please send them to: [EMAIL PROTECTED]
as well as this newsgroup.
Gordon Vrdoljak.



==============3862F0DEADA31846C4526B9E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
Hello,
<BR>I was wondering if there was any site I could download the entire redhat
6.0 cd from.
<PRE>--&nbsp;
Any comments appreciated.&nbsp; Please send them to: [EMAIL PROTECTED]
as well as this newsgroup.
Gordon Vrdoljak.</PRE>
&nbsp;</HTML>

==============3862F0DEADA31846C4526B9E==


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

From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.unix.bsd.freebsd.misc
Subject: Re: Proper use of /usr/local (Re: The Best Linux distribution?)
Date: 12 May 1999 12:31:14 -0500

In article <7hba7n$idh$[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>
>That's not the point -- I don't want things installed unless I decide to
>install them and do so myself, in which case both *BSD and Linux would
>put them in /usr/local. 

Linux wouldn't put them in /usr/local.  You might put them there yourself,
or the default install of something you pick up from somewhere might
put them there.

>As far as Apache is concerned, I always do a custom installation because
>new minor version releases are coming out literally every month, making
>whatever's on the CD obsolete pretty much as soon as I get my hands on
>it.  From that point on, the beat-ass version of Apache under /usr will
>never be used, unless that's where I install *my* version, which would
>then be wiped out during a system upgrade with another [obsolete]
>version.

This is exactly the reason that you don't want the distribution
installed version to land in the same spot as your locally modified
copies.

>
>> Installing them is optional.  That's not the point. You should be
>> able to have your own modified copy and it shouldn't have to live
>> in the same place as the distribution version.
>
>I don't really agree with the "optional" part -- I was never asked if I
>wanted *particular* applications installed, just which "distribution" I
>wanted.  Technically you're right, I could have stuck with a bare-bones
>install, but "all-or-nothing" isn't my idea of a decent option.  Better
>to browse through a FreeBSD-style ports collection.

Huh?? What Linux distribution doesn't give you a list of apps?
RedHat has a large list of basic groupings, plus options to
take 'everything' or to choose individual components from the
groupings.

>Furthermore, if you have your own modified copy of an application, why
>on earth would you need the distribution version at all?  There's no
>point in putting non-system applications in /usr, except for bundling
>reasons.

I usually wouldn't want the distribution one, but I don't want to
pick thousands of files I want/don't want individually, and I
don't want anything off the CD to clobber anything of mine even
if I make a mistake. 

>> But I *want* the apps upgraded along with the system,
>
>Then upgrade them yourself.  Compared to a system upgrade, it's trivial.

They are both trivial if you just blow in the whole thing at once.
And someone has tested all the pieces together.

>>  Isn't it
>> counterproductive to have to think about whether someone else
>> considered something a part of the base system or not and whether
>> or not you installed a modified version that you want to keep?
>
>Huh?  If it's part of the base system, it's in /usr.  If I installed a
>modified version, it's in /usr/local.  Nobody installs anything in
>/usr/local but me.  Nothing gets installed into /usr except during a
>system install or upgrade.  I fail to see any chance for confusion.

I thought the freebsd ports/packages system installed things under
/usr/local which then become mingled with the things that you
need to maintain yourself.  I'm easily confused.  I want the
unmodified installations to go one place, the ones I expect to
have to tweak even after the next upgrade in another.

>> I don't understand your arbitrary distinction between system
>> and non-system, or how it relates at all to local modifications.
>
>It's not my distinction [in that I didn't come up with it], it's not
>arbitrary, and local modifications only apply to non-system
>applications.  This is the way it's always been, before Linux came
>around and decided to do things bass-ackwards to make their installs
>simpler at the expense of creating compatibility and administrative
>problems.

Ummm, right.  That certainly explains the morass of stuff that lives under
/var and /opt and the like, depending on the vendor's whims.


>> Symlinks are quick and easy.  Perl is just about the only thing that
>> really needs to appear in /usr/local/bin because the path is
>> regretably hard coded in too many places.
>
>What you call "regretable" others call "standard".

Sigh... you can't possibly think hardcoded paths are a good idea, can
you?  Or the assumption that /usr/local/anything even exists?

>I suppose perl serves as a perfect example of what is meant between
>"system" and "non-system", in a more traditional context. 

It is a great example of why any such assumptions are inherently
broken.  I'm sure I've seen it under /var or /opt a time or two.

>Things are
>"system" if they've been around long enough that they're not really
>going to change any more [eg sh, ksh, perl4] and are common dependencies
>for other applications.  If an application is completely "optional" or
>undergoes frequent revisions, it's "non-system".

Ah, I get it.  If you can predict the future you can decide what
belongs under /usr/local.  You have to know when the next revision
will happen. 

  Les Mikesell
   [EMAIL PROTECTED]

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

From: John Allman <[EMAIL PROTECTED]>
Subject: Re: an alias for cd to set PS1=pwd
Date: 12 May 1999 11:32:43 GMT

Thanks - \w was what i was looking for.

==================  Posted via SearchLinux  ==================
                  http://www.searchlinux.com

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


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

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

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Misc Digest
******************************

Reply via email to