[ale] [Fwd: Advertising on ale.org] - OT MS vs Apple vs Linux/UNIX

[Michael B. Trausch]

On Thu, 2015-09-10 at 11:29 -0700, Alex Carver wrote:
> Not if it's an all or none proposition.
> 
> Example, right now I can set up filters to have rsyslogd take syslog
> input and either drop it to a file or, for things that are noisy,
> shuttle them off over the network to something that actually has a
> reasonable amount of storage (something many of my embedded systems
> don't have).  For the documents that I can find, *everything* goes to
> the journal with no option to filter and you must choose to have all
> of
> it go to disk and/or duplicate it over the network.  You can't have a
> mix.  If I'm wrong about this I want to see the documentation about
> how
> to filter what gets written to the journal and what doesn't.
I'd be a bad one to try to find that, because it's not functionality
I've ever used.  I've rather preferred the approach of fixing the
squeaky wheel.  See, to me, logs are useless if one needs tools like
HP's OpenView to grok them.  Instead, the signal-to-noise ratio should
be correct: there should be very little noise in the first place.
My motivation for attacking the problem like that is simple: there's
very little reason to apply filtering between the syslog/journal's
entrypoint, when you can avoid the whole invocation in the first place
(saving several context switches in the process).  Adding filtration
adds context switches.  More context switches are bad.  I therefore
consider noisy processes to be misbehaving, and either repair or
replace them.  Thank goodness for having source code.
Call my view tainted: I've been doing an awful lot that requires very
precise timing lately, and even an extra context switch at a bad time
can throw my timing off.  On the flip side of the coin, I don't want my
process to be of higher execution priority than the kernel, because
then I can miss things which are *coming at me* from the physical
hardware. A noisy process is therefore absolutely intolerable, and the
additional overhead of filtration even more so. Cut the problem off
where it starts, and nothing downstream has to compensate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150910/031994b5/attachment.html>