I think Krusader is the best file manager at all. Using drag-and-drop with multiple windows is just a pain on MS Windows and Mac OSX.

Almost everyone I know who doesn't use a twin panel filemanager have an incredible messy 'home' catalogue. Things just get dumped there, and because reorganising using MS Explorer sucks, the crust just accumulate.

Not sure, but I don't think so. It works a little different from simple folder syncronisation tools.

First it compares the two folders and then display display the differences using kdiff (or similarities, depending on the filters). There are various ways and options for filtering this, but when satisfied, one use the filtered output to synchronise the folders.

So it gives one a very good overview of what is going to be synchronized, and what exactly you want to synchronise at all. So folder synchronisation for the control freak.

Different strokes....
I think KDE has a brilliant UI that supports my workflow wonderfully. I find it much better than Mac OSX and MS Windows in almost every aspect. Haven't used Gnome since the early 2.0 days, but I never liked how it worked or how it looked, and I found KDE programs superior for my use: K3b, Krusader, Kmail, Amarok, Kontakt, Digikam, Gwenview, KTorrent, Konsole are IMHO superior what else I have seen on Linux.

Never had KDE Plasma crash on me, even with extreme loads.

Krusader is a KDE favourite of mine. Very underrated. It is twin panel, tabbed file-manager, with masking filters (e.g. select only "*.otd" files), the ability to unpack archives, and has superb "synchronise folders" feature. It's mass rename feature is very good too.

I look forward to the GPG backend to Kwallet. I was never quite sure how safe the encryptet wallet was, but with GnuPG I know what I get.

Ctrl-Click to launch URL's directly from Konsole looks nice too. It is a "right mousebutton" context menu at the moment, but clicking underlined URL's just seems right.

Great for "journalctl" with the "-x" switch that enables the catalogue db's, so that error messages in the log file are displayed together with full explanations and URL's pointing to support and documentation etc.

I assume you mean about RHEL using systemd.

The RHEL 7 beta is out, and it uses systemd:
https://access.redhat.com/site/discussions/644203

Fedora is an excellent platform for learning systemd, but a beta evaluation of RHEL 7 can be had here:
https://access.redhat.com/site/products/Red_Hat_Enterprise_Linux/Get-Beta

I have no problem with people having different preferences. In fact my main problem with systemd haters are exactly that they continually slander open source developers like Poettering just for making a init system that they evidently doesn't use or have any real knowledge about.

Content free statements like "Unix philosophy means ..." doesn't convince either. grep, sed, cp, diff etc. are all useful tools, but I have absolutely no problem with Linux users that doesn't know anything about them, but just uses a GUI like Gnome for everything.

Make it easy for people to use Linux I say, and with systemd it will actually become feasible to write a proper GUI program for showing log files that can do sorting and filtering and what not, due to the fact that the journal is structured. Not only that, it will function across all systemd distros without a tons of distro specific code.

Red Hat, Fedora, CentOS, SUSE, OpenSUSE, Arch Linux, Mageia, Sabayon Linux all enables systemd as default. There are probably many more, and certainly many more to come in the future. Besides that, distros like Gentoo and Debian have systemd as an option. Hey, even a slacker is working on systemd support on Slackware.

All desktop environments like Gnome, KDE, LXDE are integrating systemd like crazy because it saves them from a lot of OS specific code. At present you can either use systemd in order to hibernate/sleep, or rely on the unmaintained abandonware like ConsoleKit.

No one has bothered updating ConsoleKit for the last 1½ year, so it may contain huge security holes, who knows? Who cares?

Ah, the ad hominem attacks begin. As said earlier, you systemd haters just seem unable to have a technical argument. I understand why you hide as an AC.

Sure, no UI is intuitive (excepting the nipple), you still have to learn something if you want use the CLI to inspect the log file. It is just that very basic 'journalctl' knowledge gives the newbie an easy and consistent way to obtain useful information.

Just one man page to look at, instead of several (and the man page for grep is pretty intimidating for a newbie too). No need to learn piping to combine 'tac' and 'grep'. No need for grep Kung Fu just to show what went wrong since last boot.

Just the fact that systemd has indexed all entries in the log file (journal) makes it a breeze to use for both newbies and experienced SA's since it allows for e.g. autocompletion of all services that has ever written in the journal.

I don't think making syslog only register error levels above "Error" is a solution. After all, seeing that a service is starting correctly can be very useful debugging information too.

I don't share your view, that only people mastering awk, sed and grep should be allowed to use Linux, and while I love the power of e.g. GNU tools, I don't think they should be mandatory to learn just to perform basic system maintenance.

As a newbie desktop user coming from Windows, there are so many new concepts to learn, adding for them incomprehensible CLI magic doesn't help their transition at all.

I still remember how hard it was to learn all those things when I was a Linux newbie.

If you admin Linux machines, then I find it amazing that you haven't heard of systemd. The majority of Linux distributions are changing to it. There is a very vocal minority who rants against this development, they apparently have cushy jobs where they never need to learn anything new.

Systemd is the most significant change in Linux for a decade at least, since it changes and unifies many core aspects on how Linux works.

But even if you too find systemd foreign to the knowledge to have accumulated, try to give it a serious chance by eg. getting F20 and walk through "The systemd for Administrators Blog Series" at http://www.freedesktop.org/wiki/Software/systemd/

The new RHEL 7 will be pure systemd, so will the upcoming SUSE and CentOS etc, so not having thorough knowledge on how it works will seriously impede future job opportunities for Linux SA's that don't posses systemd skills.

The AC brigade is out in force tonight I see. Anyway.

Your example shows exactly what is wrong:
1. What error? How does the newbie know what to grep for without knowing what is written in the log? A 'grep "some error"' will of course miss both "Error" and "", but also miss errors indicated with "Failure" or "Warning".
2. The newbie can be swamped with error messages since your simplistic grep (without -i switch and path, and no pager too) just dump every "some error" logged the last couple of months unto the terminal. The journalctl example just showed errors generated since previous boot, something that is much harder to do with grep only.

The journalctl example shows how simple it is to filter the log so that only essential information is shown.

I really recommend you try to actually learn systemd. Get F20 and hack away.
This is a good starting point:
http://www.freedesktop.org/wiki/Software/systemd/

You can still use all the grep, sed, awk Kung Fu you know with journalctl, it just makes it so much easier.

I read his comment just fine, my comment about CPU, as you would have understood if you had read carefully what I wrote, was a general observation that systemd-journald is a really fast lightweight daemon that doesn't consume much memory, or _even_ CPU time. (BTW, I can't fathom any scenario where a daemon does so much RW that it causes a system slowdown, without that daemon sucking up CPU time.)

The OP may have experienced slowdown problems after his upgrade, but systemd-journald in it self wasn't the cause of it. Yes, I can imagine problems upgrading from eg. F17 to F19 without modifying the config files, since the systemd journal wasn't persistent in early Fedora versions, and running both systemd-journald and syslog may double the amount of disk writes.

Just go for it. Fedora 20 is worth investing some time in, since it is systemd based and therefore shows the direction that most Linux distribution are heading. All the knowledge you gain about systemd and its tools like "journalctl" can be directly used in future Linux distro's like RHEL, CentOS, SUSE, etc.

So instead of wasting time getting to know a particular distros home made tools for eg. managing daemons, you can learn a set of standard tools that can be deployed exactly the same way across many different Linux distributions.

I think any System Admin out there should seriously start to learn systemd, even if their present production servers doesn't support it yet, because some day they will.

You are trying to be sarcastic but that doesn't help one bit. Some people don't seem to like systemd, and that is ok with me, but what I find hilarious about the systemd haters are that they can't seem to argue their case in any coherent technical way, they always seem to use ad hominem attacks combined with a considerable dose of paranoid conspiracy speculation. I think your problem is that you actually doesn't have any real knowledge or experience with systemd, that way you are bound to loose any technical argument.

The plain fact is that I am right and you are wrong. It is hard for newbies that they have learn several different programs and the concept of piping just to view logs. Getting to know 'grep' is only part of their problems, they also need to know what to grep for. grepping for "error" doesn't help if the crucial message is "critical failure".

With systemd a single line can tell them about all the errors that has happened since they booted the system, and the output is even nicely color coded.
It is simple to perform log filtering on a systemd box, that would otherwise requires pretty advanced grep, sed/awk skills.

I think there was a systemd bug that caused syslog to freak out. But besides that, systemd-journald is lightening fast and lightweight on a proper systemd distro like Fedora. It on takes 300 K memory (+3 Megabyte shared mem) on my desktop system. I haven't seen it even suck up 1% CPU time ever.

systemd often keeps logfiles around for longer than many syslog implementations that uses a simple cron/time based logrotate. Since the journal is indexed size isn't really a issue.
You can tweak the maximum size etc., but it unless you are starved for space, a couple of hundred megabytes for many months of log files aren't bad.

Also, systemd-journald logs much more that any sysvinit/syslog implementation is capable of, especially stuff that happens early in the boot process.

All in all I find that "systemd-journald" is extremely fast and resource lightweight, and I just love how well designed and documented the systemd tools are.