If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

You are forgiven. Still I find it pretty funny you decided to troll this thread to pieces. No one mentioned anything about CLA until you decided it was time to show the world you can't tell the difference between Commercial CLA and FSF CA.

Now can we get back to the topic? Gnome gains a log viewer for the most detailed logging mechanism for Linux. AdamW, do you think this will impact distribution quality?

I wouldn't see it as having much of a direct impact, really. It'll be useful for sysadmins, I guess. But you can already do all sorts of stuff with journalctl, this is mostly just making it more obvious and available to those who haven't bothered to look into journalctl's capabilities or are uncomfortable with a command line, really.

Journal is really cool because a lot of things are indexed. If you check the design for this Logs application, you'll see that the idea is that the journal would distinguish between the various applications and log their output. Meaning: no need to ask people to run some command in the terminal or look at stuff like ~/.cache/gdm/session.log (lately if not using journal) or ~/.xsession-errors (older), etc. Everything would be captured by default

Note: journal lately is a bit slow on my install, so that must be fixed. It used to be ok, guess some kind of regression.

The journal grows over time, like any system log. Its backing files are rotated, like any system log. But unlike most logs, when you just call journalctl with no arguments, you get _the whole thing_, from day 0, whenever you turned journald on. If you've been running your system for a while, especially if you're a typical dev or tinkerer who runs (or writes...) busted stuff from time to time, it's likely your journal is _huge_. (You can see how huge by doing a 'du' in /var/log/journal). Any time you just run 'journalctl' and hit End, or something similar, journalctl has to iterate over the entire XXGB of data you have in there, which is why it gets slow.

There's various things you can do about this. If you don't care about logs from months ago, you can happily just wipe the older files in /var/log/journal; just look at the file dates to see what date ranges each file covers. You can also just use smarter journalctl commands. The one I use the most often is 'journalctl -b', which is 'show me all messages since I booted'. You can also pass in absolute or relative date ranges (like 'all logs in the last week') and stuff, if you check the man page.

I didn't claim it specified a requirement, I said they used the GNU libc, which is accurate for most Linux distributions. Including the one funkstar runs.

systemd devs silently assume it get's built and runs in a gnu environment. It uses GNU extensios to libc making it fail even to build under e.g. uclibc rendering systemd unusable under embedded systems...

systemd devs silently assume it get's built and runs in a gnu environment. It uses GNU extensios to libc making it fail even to build under e.g. uclibc rendering systemd unusable under embedded systems...

Thank you. This whole anti-CLA jihad is just an excuse for anti-KDE bashing.

The crucial thing with copyright assignment and licensing agreements is whether you trust the entity holding the copyright. With the FSF, I have no doubts. With Oracle, I have plenty of doubts. With someone like Digia you don't really know, but there are safeguards in place, so that's OK.

systemd devs silently assume it get's built and runs in a gnu environment. It uses GNU extensios to libc making it fail even to build under e.g. uclibc rendering systemd unusable under embedded systems...

Certain embedded usage, as systemd is used on embedded already. Only the ones relying on a different library will then fail. Anyway, learned something new, cool