All they did compare was one memory access vs. another memory access, and showed that Strings are inefficient compared to a byte array. Because the first code will concatenate Strings in memory, the second code will concatenate byte array data in memory, and then both are written to disk. The disk-access test should have been:

    for (int i=0; i numIter; i++) {
                    writer.write(addString);
                    writer.flush();
                    writer.close();
    }

I have the impression that it's their core business. My point was that Red Hat is publicly traded and thus they are much more transparent than private businesses and the value of their stock reflects the performance.

That is your opinion. I wrote reasons why I think it is proven and obviously a lot of Linux distributors think that, too. Lets assume you are correct and it is unproven and will break in RHEL 7 and a lot, if not all, customers will get very angry with Red Hat and switch to sysvinit or stick to 6 or switch to a different distribution or to Windows. Do you think Red Hat will live with that risk? So, why would Red Hat use systemd in their enterprise distribution if they not think it is ready? Red Hat, Inc. is even a publicly traded company and since May 2014 their stock continues to grow in value, i.e. there is no sign that customers are running away from RHEL 7.

You are free to use RHEL 6 or any other distribution that don't use systemd if you think it is unproven. You can even deinstall systemd on RHEL 7 and continue with sysvinit. PS: nice no true Scotsman fallacy.

Are you joking right? You are saying that it is in production use for 11 months, and it had about 2 years of testing in Fedora, and that is "unproven"?

What are you talking about? In the core systemd have only 5 daemons: systemd, journald, networkd, logind and user session, and it depends only on dbus, cgroups, autofs and kdbus. That is very minimalistic. The rest are optional daemons and tools that make your life easier.
http://en.wikipedia.org/wiki/S...

I'm still compelled to ask the same question, so what? Biological systems had 3.5 billion years to evolve. That is a lot of time for evolution and surviving of the fittest. If you look at biological organisms, they are in fact based on simplicity. Our mammalian brain is based on the amphibian and the fish brain. That is because we evolved from fish ancestors and then from amphibian ancestors. That is one example of from simple to complex. In the cell we have DNA->RNA->Proteins. That is also from simple to complex, because the first life had only proteins, then it got RNA for genetic information and enzyme in one, then it got DNA only for genetic information. Or eukaryotes evolved after prokaryotic cells, and eukaryotes fussed with chloroplast and mitochondrion cells to form our modern animal/plant cells. Also, single celled life lived long before multicellular life evolved, etc. etc. You can find simple to complex everywhere in biology.

1. my impression is that systemd is just more transparent about it, because syslog just drops the corrupted log entries silently.
2. that is just wrong. journald just rotates the log files, nothing is lost. journald shows all partials log files together as one journal:

http://www.freedesktop.org/sof...

That is nice, but so what? A star is more complex than the gas cloud it originated from, a galaxy is more complex than the cloud of stars it originated from. In nature complexity always comes from simplicity.

So, your issue with systemd is that it works just like syslog, only that systemd makes the issue more transparent by showing corrupted logs instead of just silently drop them like syslog?

"Transferring log messages via rsyslog or snmp traps is CURRENTLY the only resolve here and it is one I find to be annoying."

Just like you would without systemd. I don't see why you think then it is a bug of systemd. I think you should open a feature request.

Your understanding is wrong. systemd init have only a few components, and everything else is in independent daemons/tools. It follows exactly the Linux "Philosophy".

So, where is the bug and where is your issue on how the issue was solved? Systemd just rotates on corruption, and the issue is resolved. What do you want? That systemd magically fixes the corruption, that systemd can go back in time and retrieve the log message? There is absolutely nothing that any computer can do on file corruption, or on sudden power loss.

"The next question seems obvious to me though - how do we avoid that in the future?"

Have better hardware, have a RAID, transfer the log messages over the network, have a UPS on your computer, invent a time machine.

Can you define "SystemD also has integrated into it"? Because that what you have listed are independent daemons that offer functionality and are not "integrated" into systemd. The only "integration" you have is the common name prefix "systemd-" like "systemd-tty-ask-password" to avoid name conflicts.

"At one point, if your logging didn't work, it broke your keyboard so you could not terminal in. Don't you love it when two unrelated services with no logical dependencies can some how affect each other?"

What are you talking about?

Fedora is a testing ground for Red Hat Linux, you know, the predominant server distribution. Red Hat Enterprise Linux have systemd starting with version 7.0 and Ubuntu just joins the ranks of every other enterprise Linux distribution to use systemd, like SUSE Linux Enterprise Server and Mageia. So, you are ignorant of the facts to call systemd an "unproven product".

There is already a check of the file type, by the application and by the shell (for native executables). So, I don't see any problems. Why shouldn't the system being exempt from counting a file type look-up as a use? The Linux file utility and the libmagic library can already detect thousands of different file types, and servers already make the check for the MIME type of a file for security reasons. The focus should be on security not on simplicity.

http://en.wikipedia.org/wiki/F...
https://github.com/threatstack...
http://www.iana.org/assignment...