F20 System Wide Change: No Default Syslog

[Dan Fruehauf]

On Tue, Jul 16, 2013 at 1:55 AM, Lennart Poettering <mzerqung at 0pointer.de>wrote:

> On Tue, 16.07.13 00:55, Dan Fruehauf (malkodan at gmail.com) wrote:
>
> > +1 - same here. You're far from being alone.
>
The +1 BTW was on Miroslav's comment. Obviously I'm against that change.

> >
> > I'm still trying to get used to the new systemd in Fedora and still
> trying
> > to think why I need it. Altogether for my day to day use I find it as
> added
> > complexity with no real benefit cerca f15.
> >
> > Unix/Linux for me is the simplicity of text files. If I lose the
> simplicity
> > of text files I just wonder what is left for me? A bunch of vague files
> in
> > a binary format I need complex  tools to decipher? Might as well just
> > install win7 and utilize my gfx card.
>
> Well, there are certain things on Unix that are text files and many
> things that are not. Binary log files have a long tradition on Unix, for
> example in wtmp and utmp. We have binary files in /etc, and everywhere
> else.
>
And the reason for that being? I have no idea either, it's probably too old
to be dug. Howver yes, I'd like these to be text based as well.

>
> journalctl is certainly not a "complex tool" to understand. Command
> lines usually get shorter by using it rather than the equivalent for
> /var/log/messages.
>
People might also argue the event viewer in windows is not a "complex
tool". See where it got them. Mind you event viewer is probably a bit more
mature than journalctl.

>
> "cat /var/log/messages" becomes just "journalctl"
>
> "tail -f /var/log/messages" becomes "journalctl -f"
>
> "tail -n 100 /var/log/messages" becomes "journalctl -n 100"
>
> "grep foo /var/log/messages" becomes journalctl | grep foo"
>
All of these examples add a magnitude of complexity in terms of code. I'm
unconvinced.

>
> And the outputs of these files are the exact same text streams you are
> used to. However, enhanced with a lot of niceties that make them more
> user friendly. For example, you get colors based on the log level, or
> there's a line drawn between reboots. You get the time zone corrected,
> and you get unconditional PID data, you can filter very very easy, the
> data is unfakable and so on.
>
> Just think about this:
>
> "journalctl -b" shows you output of the current boot only
>
> "journalctl --since=today" shows you the output of today only
>
> "journalctl -p notice" shows you only notice and error messages
> (i.e. all the important stuff)
>
> "journaclctl -u crond" shows you only the messages from cron.
>
> ... and so on.
>
> Now try to think how hard it is to express queries the same way on
> classic syslog. And how slow they become on larger database because they
> aren't indexed.
>
> journalctl makes a lot of things easier, much easier. If you say it is
> complex or difficult to use I am pretty sure you never had a closer look
> at it.
>
> (Also, I am not sure what you mean by "vague". Please note that the file
> format is fully documented:
> http://www.freedesktop.org/wiki/Software/systemd/journal-files/ also, we
> commited to an API for them and more)
>
I'm pretty sure somewhere also the windows binary format is documented.

>
> > Lets try to keep things simple. This is why we use Fedora. This is why I
> > use Fedora.
>
> We are certainly making things simpler by introducing nice query tools
> like journalctl and by reducing the number of packages we install by
> default, and by removing redundancy.
>
Nice query tools? Lets go with a RDBMS to store the logs then?

And for a short story about a system (I had nothing to do with) which based
their log files in a RDBMS and their configuration in XML format. Failed
miserably. The end.

Another question while we're at it - what happens if and when you decide to
change your binary format for storing files for whatever reason? Is that
when we understand that we should have been left with just text based files?

>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130716/4f0788c3/attachment-0001.html>