Announcement

Collapse
No announcement yet.

GNOME Gets A Log Viewer For Systemd's Journal

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Honton View Post
    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.

    Comment


    • #12
      Originally posted by bkor View Post
      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.

      Comment


      • #13
        Looks like another project that wisely follows Apple's approach to its log viewing service.

        Comment


        • #14
          I thought systemd was OK until they added that journal abomination. Now I wish systemd never existed.

          Comment


          • #15
            Originally posted by Honton View Post
            And let us hate systemd despite we all know it is the standard today.

            Tldr: systemd rants are so 2010, move on and accept the new standard.
            You still fail to tell us why systemd exactly is a standard if the most used distributions don't use it.

            Comment


            • #16
              Originally posted by pingufunkybeat View Post
              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...

              Comment


              • #17
                Originally posted by schmalzler View Post
                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.

                Comment


                • #18
                  Originally posted by schmalzler View Post
                  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

                  Comment


                  • #19
                    Originally posted by Honton View Post
                    move on and accept
                    Thanks, but no thanks.

                    Originally posted by Honton View Post
                    the new standard
                    You wish.
                    Last edited by prodigy_; 02 October 2013, 04:29 AM.

                    Comment


                    • #20
                      Originally posted by Honton View Post
                      KDE is seeing a steep decline anyway, so who cares?
                      Yes, it is alarming. They will have to backtrack and bring back the classic mode before everyone jumps ship.....

                      What safeguards?
                      How are the safeguards activated?
                      What does thes safeguards protect?
                      The KDE Free Qt Foundation is an organization with the purpose of securing the availability of the Qt toolkit
                      Last edited by pingufunkybeat; 02 October 2013, 06:48 AM.

                      Comment

                      Working...
                      X