you are also such a KDE hater that you would prefer a Windows 95 machine over a KDE one?

I must do something very wrong that I have no problems with the latest KDE 4 desktop.
and possible some others also, or why is KDE desktop of the year?

and do you use Thunar for file browsing on XFCE?
does it also have a terminal included, like dolphin when I press F4, I think this feature is one of the reasons why dolphin is the filemanager of the year. of course split view without patching is also cool, and all the other features

Having been part of a project to try switching small organisations over to Linux, I can safely say that KDE was the desktop that needed least support. This was back in the days of Gnome 2, which I liked a lot but thought was not ideal for new users. As it turned out I was right. The people given Gnome needed a great deal of hand holding, whereas the people given KDE had more or less no issues. Some might regard that as proof that KDE is too Windowslike. Personally I think it's just about adherence to common design standards.
I use KDE most of the time. The other DE's are OK and they all have their special unique look and feel, but KDE just does what it's supposed to (apart from still not having a right click 'mount iso' option in the menus).
The project was using Slackware towards the end, the choice of which more or less destroyed the project. The Ubuntuites wouldn't use it but we'd invested a few thousand in the choice so that was that.
Long story. Better not repeated.

1 members found this post helpful.

What's wrong with journald? I know there were a lot of complaints about binary logs, but they aren't forced, and you can output to various syslog programs to have the normal log (you can do this inconjunction with binary logs, or you can disable those completely). Is there something else that's bad about it besides the binary logs?

The problem is, why do I need two systems loggers? why must I have journald installed to get my logs? Its like installing GNOME + KDE just to be able to use KDE, it makes no sense. If systemd was truly modular you would be able to remove journald completely and just use rsyslog, but you can't because anything that comes out of potterings mouth is horse s**it! Being able to choose what "modules" at build time is no more modular then recompiling all drivers in to the linux kernel everytime you add a peice of hardware.

1 members found this post helpful.

It's not just the fact journald is required, it's the fact its design is the absolute worst.

1. It creates unnecessary binary logs. Logging should be in plaintext because of chroot. Any common editor can read a log, even cat/tee, and you can grep search for certain fail points.

2. It parses upon boot. No log needs to parse itself. Logging is strictly output only and doesn't need checks. Plus, it's fire and forget. By running the parser, you check for errors and if an error is found, it halts the boot process until the log is fully scanned, checksumed, and then a fix is attempted.

3. The binary journal corrupts very easily if /(root) fails to dismount on shutdown/reboot cycles. All operating systems have this same exact issue, and to combat corruption, they parse the filesystem write back journal for errors and try to use the filesystem tools to check the write back state again files for error and then make repairs as needed. This directly ties back to both forementioned points.

And honestly that's why systemd is poorly designed. One single daemon acts like a concrete and steel wall dropped in front of a speeding race car on the backstretch of Circuit de la Sarthe without warning. One failed shutdown and KABOOM the race car slams the wall into a flaming pile of junk.

2 members found this post helpful.

@ReaperX7, I understand all that, but that is all based on journald using binary logs, which it doesn't have to do. You can disable binary logs and lose the benefits it provides (being able get immediate logging as soon as the init RAM disk is started all the way to the final shutdown of the system, and the ability to store memory dumps directly in the log) and just use the output to syslog (which I would do in a heartbeat, since I think binary logs are a bad idea).

I do agree with /dev/random's point about why do we need journald if we're just outputting to syslog, but that it "willfully compounds an unfixable single issue" while being able to disable binary logs and output directly to syslog proves that point inaccurate.

1 members found this post helpful.

I'm not a KDE hater. I just think that Gezley has made a few valid points. I've been using KDE since version 2.2, and all through version 3.x up to 4.10.5. KDE is one of those projects that suffers from what I call the Sisyphos syndrome. You know, that guy from the Greek mythology, condemned by the gods to push a heavy rock up a hill, only to see it tumbling down. In short, once a project is mature enough to be usable in a production environment, the developers feel an urge to send everything downhill and start from scratch.

KDE has some really great apps. Dolphin, Okular, Gwenview, K3B, to name only a few. I really love working with these apps. Now I suggest you install a complete KDE desktop in a production environment, meaning something with at least a couple hundred users. And then you simply watch what happens. Computer is slow? Well, that's because Nepomuk is eating 100% of the CPU. Desktop freezes? Well, that's because you must have enabled a desktop effect that's not handled correctly by KWin. All your appointments are lost? Sorry, you shouldn't have created a new category in KOrganizer. The taskbar has suddenly disappeared? Well, simply erase your ~/.config directory and restart everything from a pristine configuration. KMail has lost your mail? Well, that's because IMAP filtering still hasn't been fixed after all these years. Etc. etc.

As an admin, you quickly develop a zero-tolerance-policy for that sort of nonsense. Hence my choice of Xfce, which works perfectly, and which is also extremely popular among my users. And I don't care if Justin Bieber is musician of the year, I'd rather listen to my old Wayne Shorter records.

6 members found this post helpful.

kikinovak, that at least explain why you do not install it for you clients where you what to take away freedom in desktop usage as much as possible.
but that makes the KDE desktop not per se bad and the hate tirade from gezley which you absolutely clearly confirmed is an incompetent stupid hate tirade from someone who does not understand what KDE is and something totally than your explanation.

you might have your problems with KDE but you have also to understand that KDE never promised to be a company desktop, for ever stable, ...
I think this is a clear statement from KDE.

You not actually disabling it though, al you are telling it is to pipe it to /dev/null it still is recording the info, just into a black hole.
http://forums.fedoraforum.org/showthread.php?t=292543

Doesn't matter if you "disable" or "mask" it journald is always required and is never really off.

In the thread you just referenced, it states (emphasis mine):

Certainly sounds like it is not starting up to me.

But, you totally missed the point of my post. I agreed with you that I think it is stupid to require journald just to pipe it to syslog. I don't like the fact, with systemd, that they don't usually provide you with any way to use alternative programs to their own. All I'm saying, is that if you're hating on journald because of the binary logs, you DON'T have to use them. You may still need to use journald to pipe the output to another logging utility, but you don't have to keep binary logs when using journald. That was my ONLY point in responding to ReaperX7's post.

2 members found this post helpful.

OMG thats just laughable. I wouldnt even use an operating system that i had that little control over or required such convoluted tricks. Stuff like that is why i quit windows.
Not to mention one that didnt give me text logs or allow me to make alterations to boot/services and kernel as i liked.

1 members found this post helpful.

What? My response or the way journald operates? If it is towards the route taken to prevent the service from starting up, reading the systemctl page on disable and mask clears up what they do. Disable prevents the system from starting up that service unless it is manually started (maybe systemd has a direct call to journald that will bypass a disabled service, or maybe that user didn't type the command properly, I don't know). Mask prevents that from even happening, since it links the service with /dev/null. (See this if you're at all interested)

If that "laughable" was geared towards my response, let me reiterate that I am in no way interested in journald or systemd. But I can't deny that there are benefits with them that aren't provided with our current setup. But those benefits, in my book, certainly do not outweigh the disastrous downsides they are adding. I just try to find out lots of unbiased information on something before I decide if it is worth it or not, and I try to present the facts as unbiased as possible.

3 members found this post helpful.

My remark wasnt geared toward your response but rather the functioning of systemd. Doing a google search for "systemd problem forum" is pretty enlightening.

Just had a good laugh at your updated title

(... and at the GNU Hurd reference too - If Hurd doesn't go with systemd, I am pretty sure that LP will understand he has gone too far )

GNU/Hurd has dmd, and systemd is Linux only, not Hurd. Different kernel altogether.