On Tue 22 Apr 2008, Michael Biebl wrote:
> Justin B Rye wrote:
>> Package: rsyslog
>> Version: 3.14.2-1
>> Followup-For: Bug #475303
>>
>> Speaking as a user with scripts that parse my logfiles for me, I'd
>> say this change should at a bare minimum have been mentioned in a
>> changelog/NEWS file along with an explanation of how to revert it
>> (in terms clearly intelligible to users who have never previously
>> had a reason to learn the format of syslog configuration files).
>
> I admit, that the transition was suboptimal and not announced as it
> should have been.
Additionally /usr/share/doc/rsyslog/examples/sample.conf.gz still
mentioned (and still does!) that when there are no templates defined,
"... Templates compatible with the stock syslogd formats are
hardcoded into rsyslog. So if no template is specified, we use one
of these hardcoded templates. ..."
That was NOT the case with the previous version! There was also no clear
example of how to force the "stock syslogd format" if the default was
changed.
I too find the new timestamp *very* difficult to read, and I don't see
much advantage to them in a normal environment. All they attain is extra
disk space wasted.
If I had encountered these new timestamps the first time I installed
rsyslog, I would have immediately reinstalled the old syskolgd.
> I thus have disabled high precision time stamps for now (uploaded as
> 3.14-2-2) and will only reenable them, when all affected Debian packages
> have been updated to support them. When that happens, I will add a
> proper notice in the NEWS file (together with explanations how to
> disable that feature).
> I assume, that people that write custom scripts to parse log files are
> either knowledgeable enough to update their scripts or disable this
> feature again (so I won't add a debconf question, because I don't think
> that's a good idea).
Suddenly changing an output format is very bad...
I urge you to make the high precision time stamps NOT the default
automatically! I'm sure that the lack of use was not primarily the lack
of knowledge of them, but the fact that people don't like them.
Paul Slootman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
