<test>

Thanks AC!

In high-load servers logging can be quite disk intensive. Effectively doubling that I/O can be extremely detrimental to the performance of the machine.

Just how useful these features are depends on the user. The usefulness of these features does not outweigh the fact that *I DON'T WANT BINARY LOGS*.

I wish you pro-systemd people would please quit telling me what I do and do not want. Systemd offers me almost no benefit but does disrupt many aspects of my systems *FOR NO BENEFIT TO ME*.

If this is good for you, please, by all means, use systemd. But leave me the option to not use it. You do not know what is best for me and I didn't ask for your opinion. I especially did not request that my options be limited by a group that is as controversial as the systemd folks.

And your solution 1). offers absolutely no benefit to me 2). does not exist yet

There are hundreds or thousands of tools in the UNIX userland that have been written to interact with text files. Why re-invent the wheel?

I do not want binary logging and with systemd I have no option. I have many other issues with systemd. I, like many many other people, do not want systemd.

It's not like the journal format is some state secret. It's documented and there are already several journal parsers to choose from.

Which does absolutely nothing to remedy the issues I have with systemd logging. But thanks for playing.

At least with journald you can have logging done just binary, just text or both types simultaneousl

False. You cannot log only to text with systemd. And who wants twice the I/O (binary and text) to appease the systemd folks when text logs have been not only the defacto standard, but a rudimentary part of the UNIX philosophy. There are several other reasons I don't like systemd ( try to chroot to a broken system and tell me how much fun that is if the system is a systemd system ) but binary logging with no text only option is arrogant and a show stopper for me as well.

I like VSSL -- very secure socket layer :P
It could even be written/pronounced VeSSeL. Loose definitions of vessel could even be applied to the functionality of SSL.

Normally the fix is:

rpm --rebuilddb
yum clean metadata

Was there more involved for your fix?

I believe I am dumber as a result of watching that video. That has to be one of the funniest, most out of touch things I have seen in a long time.

Awesome!! So if the ACA is such a fucking success where is the $2500/year I am supposed to be saving vs. the actual observed increase of ~$2000/yr I see now?

Oh wait.. I must be a republicrat for even mentioning that and thus not worthy of a response.....

Did you, you know, configure the location for those? I have used several KDE weather plasmoids and they all worked well.. once I configured the location. I am pretty sure that you would need to do the same with MS widgets. Just sayin.

Equally long we already could have switched to a full wind and solar powered world.

citation please.

Comparing the number of EOs to arrive at any sort of conclusion is much like measuring productivity by lines of code written/comitted. The raw numbers tell very little.

This reminds me of the SCO lawsuit, where the most they ever found was, what, 7 lines of infringing code which SCO themselves had nicked from AT&T UNIX?

A little off-topic I know, but IBM was never found to have infringed on any code from SCO. SCO tried to *claim* some code that was already licensed under a FLOSS license was the same as their code and thus infringed on their IP. They made a big deal of this to the press forcing them to sign NDA's & "showing them the code".

3) Yeah, we can send you a patch for that and you can compile the kernel SRPM, or

RH does not support custom compiled kernels. Basically, if you compile your own kernel there is no reason to use RH because you have just "voided your warranty" and the whole system is considered suspect.