<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 16, 2013 at 1:55 AM, Lennart Poettering <span dir="ltr"><<a href="mailto:mzerqung@0pointer.de" target="_blank">mzerqung@0pointer.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 16.07.13 00:55, Dan Fruehauf (<a href="mailto:malkodan@gmail.com">malkodan@gmail.com</a>) wrote:<br>
<br>
> +1 - same here. You're far from being alone.<br></div></blockquote><div>The +1 BTW was on Miroslav's comment. Obviously I'm against that change.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
><br>
> I'm still trying to get used to the new systemd in Fedora and still trying<br>
> to think why I need it. Altogether for my day to day use I find it as added<br>
> complexity with no real benefit cerca f15.<br>
><br>
> Unix/Linux for me is the simplicity of text files. If I lose the simplicity<br>
> of text files I just wonder what is left for me? A bunch of vague files in<br>
> a binary format I need complex tools to decipher? Might as well just<br>
> install win7 and utilize my gfx card.<br>
<br>
</div>Well, there are certain things on Unix that are text files and many<br>
things that are not. Binary log files have a long tradition on Unix, for<br>
example in wtmp and utmp. We have binary files in /etc, and everywhere<br>
else.<br></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
journalctl is certainly not a "complex tool" to understand. Command<br>
lines usually get shorter by using it rather than the equivalent for<br>
/var/log/messages.<br></blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"cat /var/log/messages" becomes just "journalctl"<br>
<br>
"tail -f /var/log/messages" becomes "journalctl -f"<br>
<br>
"tail -n 100 /var/log/messages" becomes "journalctl -n 100"<br>
<br>
"grep foo /var/log/messages" becomes journalctl | grep foo"<br></blockquote><div>All of these examples add a magnitude of complexity in terms of code. I'm unconvinced. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And the outputs of these files are the exact same text streams you are<br>
used to. However, enhanced with a lot of niceties that make them more<br>
user friendly. For example, you get colors based on the log level, or<br>
there's a line drawn between reboots. You get the time zone corrected,<br>
and you get unconditional PID data, you can filter very very easy, the<br>
data is unfakable and so on.<br>
<br>
Just think about this:<br>
<br>
"journalctl -b" shows you output of the current boot only<br>
<br>
"journalctl --since=today" shows you the output of today only<br>
<br>
"journalctl -p notice" shows you only notice and error messages<br>
(i.e. all the important stuff)<br>
<br>
"journaclctl -u crond" shows you only the messages from cron.<br>
<br>
... and so on.<br>
<br>
Now try to think how hard it is to express queries the same way on<br>
classic syslog. And how slow they become on larger database because they<br>
aren't indexed.<br>
<br>
journalctl makes a lot of things easier, much easier. If you say it is<br>
complex or difficult to use I am pretty sure you never had a closer look<br>
at it.<br>
<br>
(Also, I am not sure what you mean by "vague". Please note that the file<br>
format is fully documented:<br>
<a href="http://www.freedesktop.org/wiki/Software/systemd/journal-files/" target="_blank">http://www.freedesktop.org/wiki/Software/systemd/journal-files/</a> also, we<br>
commited to an API for them and more)<br></blockquote><div>I'm pretty sure somewhere also the windows binary format is documented. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Lets try to keep things simple. This is why we use Fedora. This is why I<br>
> use Fedora.<br>
<br>
</div>We are certainly making things simpler by introducing nice query tools<br>
like journalctl and by reducing the number of packages we install by<br>
default, and by removing redundancy.<br></blockquote><div>Nice query tools? Lets go with a RDBMS to store the logs then?<br><br></div><div>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.<br>
<br></div><div>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?<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering - Red Hat, Inc.<br>
</div><div class="HOEnZb"><div class="h5">--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a></div></div></blockquote></div><br></div></div>