As interesting as needless pedantry is, it may worthwhile moving this 
discussion or being more constructive.

If the discussion is to continue I would recommend you both hash out exactly 
what the structure would be and stop metaphorically attacking inanimate 
objects.

You both obviously have a lot of input, maybe you can find where the conflicts 
are and then bring those conflicts forward for the community to observe and 
possibly comment on.

This is just my opinion of course but it seems obvious the discussion is not 
progressing very rapidly.

Best Regards,

Sarton


On Thu, 19 Jul 2007 11:46:12 am Brett Lymn wrote:
> On Wed, Jul 18, 2007 at 03:31:54PM -0400, Greg A. Woods wrote:
> > Anyone with any decent amount of experience managing unix systems, and
> > I've got a whole hell of a lot more than many people do, can see from
> > its manual page alone what its inherent design limitations are.
>
> I am well aware of your experience - you should not assume everyone
> else is a neophyte.  Having used logadm I can tell you that just
> reading the man page you have missed some important facilities.
>
> > If it
> > looks and smells like a rock, talks and walks like a rock, feels like a
> > rock, and hurts like a rock, then it's either a rock or a very near
> > relative of a rock, and we all know what rocks are like.
>
> Yes, but is it kimberlite which may contain a diamond or a chunk of
> slate?  This is what I was getting at - you are says "oo look, here is
> a rock", I am telling you you have missed some important information
> because you have only looked at the man page.
>
> > No, not really.  newsyslog is meant only to keep syslog files (and other
> > similar system log files) from growing to fill all available disk space,
> > or more concisely to "maintain system log files to manageable
> > sizes".
>
> Oh dear, then I suppose you are going to argue what exactly
> constitutes a system log?  Why should newsyslog only deal with
> syslogd?  Isn't that against the unix philosophy?  I think it should
> be a tool that can, generically, manage logs - the right tool for the
> right job instead of reinventing the wheel every time something else
> needs to have logs managed.
>
> > Anything over and above that is not, and never was, its job.
>
> So, a syslog log is a totally different and separate thing from a
> squid log, apache log, sendmail log, <inser foo here> log?  No.  We
> need a tool that can flexibly handle rotating any log.
>
> > Today the benefits of data compression, even that of historical log
> > data, are highly over-rated.
>
> I am glad to see that someone lives in a world where there are vast
> vistas of disk to keep a reasonable depth of highly repetitive data.
> Some places don't have this luxury and their management have an
> expectation that reports can be generated on the data for a reasonable
> time period.
>
> > As I've explained ad nauseam in another post, it is quite trivial to
> > design and implement additional programs which provide further abilities
> > to fully "manage" log files, and to do so in a more safe and secure
> > manner than could ever be done by extending or enhancing newsyslog.
>
> What you have done is say "here is this round thing, it's not like
> that syslog round thing".  I have yet to see where you demonstrate
> that using newsyslog is any less safe & secure, just saying so does
> not make it fact.
>
> > In this case if the person doing
> > the design can fully understand and explain why syslogd doesn't create
> > the files it writes to then perhaps they're qualified to come up with
> > something half-way decent.
>
> Or squid or apache or.... that's the problem there are a lot more
> things generating log files apart from syslogd - all the logs should be
> managed in a centralised consistent manner.
>
> > Personally I like using config files to gather similar or related
> > information about objects or tools, and I'm quite happy with the
> > relatively free-style "table" form used by many unix tools.
>
> Who said anything about this not being the case?  The solaris
> logadm.conf is precisely that - you can edit the file manually.
> I may have missed it but I didn't see any mention of a suggested
> format for the newsyslog changes - I don't think it progressed that
> far.