"As I understand it, it bundles a large number of services into a single process" - looks like you have only been reading slashdot comments rather than documentation at sites like http://www.freedesktop.org/wik... ?
a lot of it is down to configuration as to how many services are run by systemd. I'm using opensuse 13.1 and the only systemd services that appear to be running on my system are journald, logind and udevd.
is that systemd getting it wrong or the human that set the configuration up incorrectly? is it "init"'s problem if a startup script file is wrong? Your learning curve is going to have to happen at some point if you are moving to systemd from sysvinit.
if you change the format of formatted text files, your tools/scripts will break as well. if they change the format then the tools will change as well - that was a stupid post to try and dismiss binary logs, you need to try and find a better one.
sysvinit is still there, so just don't install systemd. The only "hairball" dependencies that systemd needs to run that i can see are journald and udev, everything else appears configurable (please correct me if i'm wrong). Udev does not need systemd, it will work without it. I'm still in the process of investigating, for my peace of mind, the claims made by detractors to see if they are true, a lot of them so far seem to be repeated hysterical opinions on misinformation.
so configure journald to simultaneously spit out text log files to syslog/rsyslog or you can export them to text files when you need them. its not hard.
"When you were a kid did you ever do something stupid because $stupid_kid did it?" - Journald can be configured to spit out text logs to syslog/rsyslog as per now if that suits you. Why not give some reasons why binary logs are the devil incarnate?
from your post you sound like the sort of admin that doesn't test new systems to destruction before deployment so then i'd also be worried about you wanting to update working machines
Probably best if you do some of your own investigation into Systemd as to what you can configure in and out of its usage. Don't rely on the misinformation peddled in these postings . e.g. one of the biggest bits of misinformation is that systemd only emits binary logs but if you check the config options you will see
"ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect. By default, only forwarding wall is enabled. These settings may be overridden at boot time with the kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=", "systemd.journald.forward_to_console=" and "systemd.journald.forward_to_wall=". When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below."
Most of the complaints against journald are unfounded. it can be configured to spit out text logs to rsyslog at he same time so all the scripts relying on text logs will still work as normal
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect. By default, only forwarding wall is enabled. These settings may be overridden at boot time with the kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=", "systemd.journald.forward_to_console=" and "systemd.journald.forward_to_wall=". When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.
"a system administrator expects a system to be up and running for maybe a decade with little effort" - well, that gives him/her a lot of time to learn the new system, test and document it fully before deployment
Money to Apple and Google for each transaction. I can see the retailers wanting a solution that's cheaper for them because they are charged for each transaction via the credit/debit card system
"Why does anyone think that it's "more convenient" to use NPC than swiping a credit card?" - who the fuck knows? its seems like a solution looking for a problem - unless its cheaper (customer or retailor) to use the phone based solution
I rather all vehicles were electric because i'd like to walk around towns and cities that didn;t smell of car fumes and i see that as a valid target for cutting back on pollution.
The only reasons for not using nucleur is the safety of the fuel and possibly the setup costs otherwise it would be top of the list for power stations and all coal and gas ones would be decomissioned (although its good to have diversity in power generation)
Slashdot Mirror
"As I understand it, it bundles a large number of services into a single process" - looks like you have only been reading slashdot comments rather than documentation at sites like http://www.freedesktop.org/wik... ?
a lot of it is down to configuration as to how many services are run by systemd. I'm using opensuse 13.1 and the only systemd services that appear to be running on my system are journald, logind and udevd.
nope but "Anonymous Coward" is a synonym for "generally being a twat"
is that systemd getting it wrong or the human that set the configuration up incorrectly? is it "init"'s problem if a startup script file is wrong? Your learning curve is going to have to happen at some point if you are moving to systemd from sysvinit.
"And you don't have to modify vi to edit their config files. " - could you explain why?
if you change the format of formatted text files, your tools/scripts will break as well. if they change the format then the tools will change as well - that was a stupid post to try and dismiss binary logs, you need to try and find a better one.
i'm sure everyone has screwed up at some point, its just the implication that sysvinit system is problem free that gets me
"I like systemd, it pisses people off and that makes me happy" - Mr Poettering i presume.. :)
sysvinit is still there, so just don't install systemd. The only "hairball" dependencies that systemd needs to run that i can see are journald and udev, everything else appears configurable (please correct me if i'm wrong). Udev does not need systemd, it will work without it. I'm still in the process of investigating, for my peace of mind, the claims made by detractors to see if they are true, a lot of them so far seem to be repeated hysterical opinions on misinformation.
so configure journald to simultaneously spit out text log files to syslog/rsyslog or you can export them to text files when you need them. its not hard.
its only an installation/configuration issue to solve, the code/scripts are already in place
"When you were a kid did you ever do something stupid because $stupid_kid did it?" - Journald can be configured to spit out text logs to syslog/rsyslog as per now if that suits you. Why not give some reasons why binary logs are the devil incarnate?
you mean to say a decade is not long enough????? jeez, i'd worry about the admin quality if he/she couldn't do it in a decade
you've never ever had a screw up in any of your boot/startup/restart scripts on your init systems????
" simply that it's a monolith " - that again is a reworked dictionary definition to suit an argument. systemd is not a monolith
from your post you sound like the sort of admin that doesn't test new systems to destruction before deployment so then i'd also be worried about you wanting to update working machines
vitriolic trolls....
Probably best if you do some of your own investigation into Systemd as to what you can configure in and out of its usage. Don't rely on the misinformation peddled in these postings . e.g. one of the biggest bits of misinformation is that systemd only emits binary logs but if you check the config options you will see
"ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall= Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect. By default, only forwarding wall is enabled. These settings may be overridden at boot time with the kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=", "systemd.journald.forward_to_console=" and "systemd.journald.forward_to_wall=". When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below."
Most of the complaints against journald are unfounded. it can be configured to spit out text logs to rsyslog at he same time so all the scripts relying on text logs will still work as normal
http://www.freedesktop.org/sof... - here's the option from the link.
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
Control whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the kernel log buffer (kmsg), to the system console, or sent as wall messages to all logged-in users. These options take boolean arguments. If forwarding to syslog is enabled but no syslog daemon is running, the respective option has no effect. By default, only forwarding wall is enabled. These settings may be overridden at boot time with the kernel command line options "systemd.journald.forward_to_syslog=", "systemd.journald.forward_to_kmsg=", "systemd.journald.forward_to_console=" and "systemd.journald.forward_to_wall=". When forwarding to the console, the TTY to log to can be changed with TTYPath=, described below.
"a system administrator expects a system to be up and running for maybe a decade with little effort" - well, that gives him/her a lot of time to learn the new system, test and document it fully before deployment
it shouldn't be hard for all those highly experienced admins that know better
Money to Apple and Google for each transaction. I can see the retailers wanting a solution that's cheaper for them because they are charged for each transaction via the credit/debit card system
I've got a debit card i can just tap on the terminal to pay, doesn't need a pin.
"Why does anyone think that it's "more convenient" to use NPC than swiping a credit card?" - who the fuck knows? its seems like a solution looking for a problem - unless its cheaper (customer or retailor) to use the phone based solution
I rather all vehicles were electric because i'd like to walk around towns and cities that didn;t smell of car fumes and i see that as a valid target for cutting back on pollution.
The only reasons for not using nucleur is the safety of the fuel and possibly the setup costs otherwise it would be top of the list for power stations and all coal and gas ones would be decomissioned (although its good to have diversity in power generation)