But you have both, MySQL log files and systemd logs? So, I still don't get what your problem is. In sysvinit you have zero information. And ps or netstat is not a reliable solution, because it is always different from service to service and from system to system. In ps you have to know the executable, in netstat the name of the service. On my Ubuntu server, for postfix you have "master", for nginx you have "nginx.conf". And of course the name will differ from system to system. Furthermore, services can opt in into the logging of systemd, it is not mandatory. So, I'm really confused what you want. You want that systemd takes over logging, or you still want your old logging files?
On systemd I do "systemctl start foo" and I get info that the service was actually started and runs, or that the service did not started. With the init scripts I don't have any response and I need to use ps or netstat to figure out whether or not the service actually runs. That is because systemd is using cgroups to track the started service, but sysvinit have no service management at all.
If you want info and logs why the service didn't started, use "systemctl status foo", or use the journal with "journalctl -n 20" or filter "journalctl _SYSTEMD_UNIT=foo". That's no different from the usual "dmegs|grep foo".
Your logging issues are too unspecific and I have no idea what you actually talking about. On Fedora 20 I have all the usual logging files in/var/log. Even your missed/var/log/messages is there.
No, it will not. It just shows a yellow triangle. If you want a security policy that does what you describe, then Chrome should not display that web site at all.
No, it does not. The Window Manager have dependency on systemd, not the other way around. If the Gnome developers deciding that they need systemd, it's not systemd fault. You are free to open a bug ticket, but in the end it's the decision of the Gnome developers to use a particular technology.
That's why people want systemd. If I look at sysvinit scripts, there are a ton of magic stuff going on that I don't know, and maybe nobody knows. On Ubuntu 12.04 the sysvinit script for Apache is over 7000 bytes long, and it includes bad stuff like "# wait until really stopped" with a loop of kill and sleep. The ClamAV init script is even bigger, over 9000 byes long. Is there any maintainer who really knows what it does?
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:
If called without parameters, it will show the full contents of the journal, starting with the oldest entry collected. [...] Output is interleaved from all accessible journal files, whether they are rotated or currently being written, and regardless of whether they belong to the system itself or are accessible user journals.
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.
It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process.
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?"
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.
Copyright law was created to "To promote the Progress of Science and useful Arts", not to grand a monopoly right for the creator. The limited monopoly right is just the means to promote art, not the desired outcome. The current law of 150+ years (or is it now 300 years?) is absolutely not proportional. With better technology the copyright terms should be shortened and not extended. With our current digital technology, the term should be 5 years or even shorter. Almost everything today should be fair use, so that the authors finally create new characters and new stories, instead to reboot and retell the same stories over and over again.
No, the problem is with extensions, and we should get rid of extensions once and for all. Those are an artifact of 1980s DOS times, and should not be used at all by modern systems. Maybe they are convenient for the user to see what kind of type the user should expect, but nothing more and the "hide extension" "feature" just shows the _problem_ of file extensions.
Modern systems should recognize file types based on the content of the file, not on some stupid extension. For example, a.jar,.ooxml and.odf file is just a zip file with special content. The system should recognize the content and open it as a Jar executable, or in your office app. That way, the system can ensure that the file type matches the file name, and activate anti-virus scans on any executable, be it.com,.exe or.jar or the silly nakedpic.jpg.exe.
I'm using Linux with Firefox 35.0 and if I just drag one shape over the diagram the CPU goes to over 20%. For typing text into a shape the CPU goes up to 10%. Even f I just hover my mouse cursor over the shapes the CPU goes up to over 10%. Comparing that to VisualParadigm (Java) where the CPU stays at about 10% for dragging shapes and stays at between 0% and 1% in idle. Sorry but JavaScript is at least still 15 years to be on par with Java or other languages, if ever JavaScript reaches the same performance of Java, which is very doubtful.
In my opinion, the WC3 must release a DOM bytecode specification and drop JavaScript as part of the standard. That way, anyone is free to use any language for the Web and we can have binary bytecode embedded in the HTML pages, which additional type and runtime information. How about the WC3 just adopt the JVM bytecode? We already have a JavaScript script engine in Java.
Yes, I have it from various micro-benchmarks sites. I myself didn't wrote or did any of those benchmarks, because it's useless anyway. Java is fast for my needs, and there are various high performance libraries in Java, like http://code.google.com/p/effic...
Slashdot Mirror
But you have both, MySQL log files and systemd logs? So, I still don't get what your problem is. In sysvinit you have zero information. And ps or netstat is not a reliable solution, because it is always different from service to service and from system to system. In ps you have to know the executable, in netstat the name of the service. On my Ubuntu server, for postfix you have "master", for nginx you have "nginx.conf". And of course the name will differ from system to system. Furthermore, services can opt in into the logging of systemd, it is not mandatory. So, I'm really confused what you want. You want that systemd takes over logging, or you still want your old logging files?
What does it matter? If Gnome and systemd are both their developments, good for them.
On systemd I do "systemctl start foo" and I get info that the service was actually started and runs, or that the service did not started. With the init scripts I don't have any response and I need to use ps or netstat to figure out whether or not the service actually runs. That is because systemd is using cgroups to track the started service, but sysvinit have no service management at all.
If you want info and logs why the service didn't started, use "systemctl status foo", or use the journal with "journalctl -n 20" or filter "journalctl _SYSTEMD_UNIT=foo". That's no different from the usual "dmegs|grep foo".
Your logging issues are too unspecific and I have no idea what you actually talking about. On Fedora 20 I have all the usual logging files in /var/log. Even your missed /var/log/messages is there.
No, it will not. It just shows a yellow triangle. If you want a security policy that does what you describe, then Chrome should not display that web site at all.
No, it does not. The Window Manager have dependency on systemd, not the other way around. If the Gnome developers deciding that they need systemd, it's not systemd fault. You are free to open a bug ticket, but in the end it's the decision of the Gnome developers to use a particular technology.
That's why people want systemd. If I look at sysvinit scripts, there are a ton of magic stuff going on that I don't know, and maybe nobody knows. On Ubuntu 12.04 the sysvinit script for Apache is over 7000 bytes long, and it includes bad stuff like "# wait until really stopped" with a loop of kill and sleep. The ClamAV init script is even bigger, over 9000 byes long. Is there any maintainer who really knows what it does?
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...
If called without parameters, it will show the full contents of the journal, starting with the oldest entry collected. [...] Output is interleaved from all accessible journal files, whether they are rotated or currently being written, and regardless of whether they belong to the system itself or are accessible user journals.
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.
It is also my understanding that SystemD is taking the approach of wrapping up quite a number of those software pieces into one tool/process.
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...
Copyright law was created to "To promote the Progress of Science and useful Arts", not to grand a monopoly right for the creator. The limited monopoly right is just the means to promote art, not the desired outcome. The current law of 150+ years (or is it now 300 years?) is absolutely not proportional. With better technology the copyright terms should be shortened and not extended. With our current digital technology, the term should be 5 years or even shorter. Almost everything today should be fair use, so that the authors finally create new characters and new stories, instead to reboot and retell the same stories over and over again.
No, the problem is with extensions, and we should get rid of extensions once and for all. Those are an artifact of 1980s DOS times, and should not be used at all by modern systems. Maybe they are convenient for the user to see what kind of type the user should expect, but nothing more and the "hide extension" "feature" just shows the _problem_ of file extensions.
Modern systems should recognize file types based on the content of the file, not on some stupid extension. For example, a .jar, .ooxml and .odf file is just a zip file with special content. The system should recognize the content and open it as a Jar executable, or in your office app. That way, the system can ensure that the file type matches the file name, and activate anti-virus scans on any executable, be it .com, .exe or .jar or the silly nakedpic.jpg.exe.
I'm using Linux with Firefox 35.0 and if I just drag one shape over the diagram the CPU goes to over 20%. For typing text into a shape the CPU goes up to 10%. Even f I just hover my mouse cursor over the shapes the CPU goes up to over 10%. Comparing that to VisualParadigm (Java) where the CPU stays at about 10% for dragging shapes and stays at between 0% and 1% in idle. Sorry but JavaScript is at least still 15 years to be on par with Java or other languages, if ever JavaScript reaches the same performance of Java, which is very doubtful.
In my opinion, the WC3 must release a DOM bytecode specification and drop JavaScript as part of the standard. That way, anyone is free to use any language for the Web and we can have binary bytecode embedded in the HTML pages, which additional type and runtime information. How about the WC3 just adopt the JVM bytecode? We already have a JavaScript script engine in Java.
http://en.wikipedia.org/wiki/J...
Yes, I have it from various micro-benchmarks sites. I myself didn't wrote or did any of those benchmarks, because it's useless anyway. Java is fast for my needs, and there are various high performance libraries in Java, like http://code.google.com/p/effic...