And the schools don't dare inform parents of all the risks - parents would say "What, are you crazy? I'm going to risk my kids future so you can get a stupid trophy for your office? DIAF."
I wish you were right, but experience with the parents of brain-damaged young athletes indicates otherwise.
Maybe it's time to consider that they're engaged in willful child endangerment? Nobody, not even a concussed-out coach, wants to be labeled a child abuser.
Maybe so, but it's clear from what happened at Penn State that they just don't want the label. There's way too much tendency to turn a blind eye.
RPC allows proprietary software to leverage the functionality of your GPL software, which might go against your intent, as RPC becomes the de facto interface of increasing number of components...
Honestly, I don't buy into the whole non-GPL can't link GPL argument in the first place.
Suppose I were to tell you to grab your copy of the 3rd paperback printing of Game of Thrones and look at the second sentence on page 320. Does posting that sentence make this post a violation of GRRM's copyright? Of course not - I didn't copy anything in his book - simply mentioning that it exists and that it contains a page 320 in no way makes this post a derivative work.
Well, when you link a binary to a shared object, all you do is write a bunch of cross references saying that this function call should be replaced with an address associated with this symbol. Then a linker will replace those references when your code is loaded. None of this involves copying anything. Assuming the shared object is in RAM already being used by something else, your OS isn't even copying the GPL code at all when this happens, but even if a copy were made it is an unmodified copy of the shared object which isn't being redistributed - ie it is permitted by the GPL.
Sure, everybody says that you can't link non-GPL code to GPL code, but I am not convinced that a court is certain to uphold this. I could see issues if you try to bundle GPL and non-GPL software into a single larger work, but if you distribute the non-GPL stuff without the GPL content that problem goes away.
The main issue is no one wants to fight the court battle.
But frankly, this has all been kind of irrelevant anyway - you can distribute source packages, let the client do a compile on install, and ignore the entire affair.
It's essentially a project financed behind the scenes by Microsoft to delay the release of Linux updates-- hardware products (like Raspberry PI) that make use of Debian are currently stalled at Wheezy while the whole mess sorts itself out.
He said explanation, not a transcript of the signals you receive from the CIA in your fillings.
What unnecessary code? I'm genuinely curious what you think is completely dispensable as a system service at the init system level.
I mean we need something to launch processes, something to resolve dependencies of processes (init.d has insserv and the LSB headers), networking, disk mounting, time synchronization, authenticating and user session management (else how do your sysadmins log on from central administered sources?). We need process monitoring, logging, we'd like to have cgroups for security. We need some sort of time-based job scheduler.
Which one of these things are you going to drop? Which things are completely inseparable from systemd?
It also tends to be that people who forego cellphones still choose to utilize everyone else's. At some point that's a violation of the social contract - you're making yourself uncontactable, but taking advantage of that utility surrounding everyone else. Moreover, you're also starting to demand people adhere to your schedule on your terms: see complaining that people won't kowtow to your contact hours.
With a few hundred people who attend town hall meetings and debates, post on that rep's Facebook wall, call into the local radio station when the rep is on etc, a dozen or so active citizens might well swing a representative's vote,
That's so cute that you believe that! The average congressional campaign cost USD$1.2 million this year. Money talks and it's corporations and other monied interests that are doing the talking, not "concerned citizens." Sure your congressperson will pat you on the head and say "I work hard to make sure our district gets what it needs! I work for you." But the truth is they work for those who pay their way.
You must think things work as they did back in 1946 when this was written. Sorry champ. Those days are long gone.
Money doesn't talk as much as people think, and the return rate on dollars to candidates elected for SuperPACs remains poor. It only works when the messaging goes unchallenged.
Really? Because my immediate reaction was to laugh out loud at the naivete. Companies care about bottom lines. They don't care about security, as amply demonstrated by banks which can have vulnerabilities pointed out to them, and then try to criminally prosecute the guy who tells them, and don't fix the problem.
This has happened over and over right here on Slashdot.
How the hell do you think changing PID 1 is supposed to be phased?
It is literally the first process which runs on Linux. Please explain "phased change" when something that fundamental is being altered. You might as well say "I'm outraged we had to get kernel 3.x all at once! It should've been a phased upgrade...."
Actually you only need a correct answer for 1 program: the one running on the firmware of the robot. At which point the question is simply "over the input space, can the program provide outputs which end human lives?"
Of course depending how you define that, you can take this right into crazy town - plenty of cellphones have ended human lives over the possible input space.
This is class political strategy BS: "look at how much drama we're causing! Something is clearly wrong!"
It's why most successful projects have benevolent dictators: because it shuts down most of the political strategems people translate to democracies of any sort.
"RELP is TCP based with another layer of protocol over the top."
You could say the same about HTTP or any other application level protocol,
I don't know, maybe my point was spelled out in the immediately following sentences which you didn't read?
Because you just went on to prove the entire point I was making by talking all about extra network protocols and daemons all created to make networked syslog reliable while you're in the middle of complaining about using a separate daemon to make journald network exportable.
At this point, I have no idea what you think the problem is other then "oh my god journald is new and scary". Because you've been explaining in excruciating detail exactly why you wouldn't use the raw logging protocol of a local system to actually communicate over a network because networks aren't reliable.
In which case, we return to the original issue: what exactly is the problem with using a special purpose daemon for exporting logs over the network? You know, the aforementioned separation of concerns which in any other thread on systemd is apparently the only thing people can talk about?
Yes. You should clearly protest this unfair characterizing by leaping to the defense of people sending rape and death threats to women who write anything which could be construed as criticism! That'll show how peaceful and non-violent you are!
Ban alcohol. A study on the economic cost of alcohol as a function of police resources, ambulance and hospital resources, lost productivity due to injuries and illness, and straight up population destruction, pegs the mean lost productivity at $20 billion per year.
Of course, we're not doing that because history tells us it will be a lot more if we do. Still...
Part of it is also the reason that it should not be considered inconceivable that the way ratings tend to work for sex and violence has something of a schism. Now, generally I think the schism is bad - we can deal with this issue better. But at the same time, in thinking about explaining to children why something is or is not appropriate, violence is a lot easier to explain with far fewer edge cases:
Is violence okay? No. Ever? Very rarely. When? It is okay to defend yourself if attacked. You should try and avoid having to do so.
That will get you through 99% of individual life until you get to geopolitics and the diplomacy of nationstates, which a good deal of people will get through life without needing to know about anyway.
Sex on the other hand?
When is that okay? What is okay? Why do some people do that? What is normal? There's a neverending well of questions there, all of which have complicated answers, and which society has an active, ongoing and vitriolic argument about.
There is no concise answer. The simplest things get complicated fast, and very much unlike violence, people seeing depictions or media messaging about it don't have the option (in most cases) of dealing with it by simply not dealing with it. I can avoid most or even all violence and most of us will during our lives. But I and my children are not going to avoid issues of sexuality and it has the potential to be very much a defining element of how their lives will evolve.
To bring it back to the McDonalds and Coke point, this is very much the same reason they advertise. Because you have to eat. You do eat. They're not asking or trying to get you to do something so uncommon. And they know how your nose and satiation responses work. Unless you have an absolute policy of just "no" towards them, then all they've got to do is make "mcdonalds" or "I want a coke" come to the front of your brain with some type of positive feeling when you're anywhere near them.
Except correlations can be due to chance. You can test this, by picking things which can't possibly be causally linked, running the same statistic analysis, and observing how often you get a correlation hit.
And it's important to know this, because such a statistical issue was very much the cause of various excited reports of radiation, cellphones, powerlines and every other type of factor "somehow" increasing risk for cancer, despite the absence of any measurable causative effect.
Until it was realized that if you ran the analysis on any set of variables, you'd always get "roughly double" the risk even if the question was "cancer rates vs. mean daily use of swear words" or "cancer rates vs. global population of pirates".
Which is why they don't just report the result. Because without context, the result is meaningless.
This list isn't a technical complaint, it's a bullet point list which provides no information on what the actual problem is supposed to be.
"overly complex" is a subjective term. Compared to...what exactly? init scripts aren't simple, and they're modular seeing as how daemon dependencies are a real thing. And I'm curious exactly which 70 pieces of systemd can't live without each other, because I genuinely don't know. I do know that it can't be all of them, since I run systemd and don't use the dhcp, network or cron replacements. So, logind maybe? Journalctl is kind of indispensable, but so is syslog on anything else.
Same issue with PID 1. What concerns? What is in PID 1 that is a problem? Why shouldn't it be there? Because the amount of functionality people keep implying is there (the aforementioned 70 daemons) distinctly are not. Whereas, having my init process be cgroups aware and able to use that functionality to provide isolation seems like a pretty good idea to me, seeing as how solid jailing support is sorely missing from Linux.
I'm happy to concede the lib dependencies are an issue. I don't know enough about the underlying plumbing concerns to know if it's avoidable, or who should be blamed - i.e. a lot of systemd is actually a Gnome pull in, which then just flows on to Gnome apps. Which would make it a Gnome problem, more then anything else.
systemd has this exact switch. Ubuntu flavored systemd default configuration is to not write binary logs and parse everything directly to syslog.
Cue some example of seeing a half flushed log line in a file, as though someone actually got any information from that line.
It's becoming rapidly apparent to me that the people who complain no one listens to their complaints about systemd haven't realized they don't listen or attempt to learn about what they're complaining about.
" rsyslog in TCP mode is how you achieve this currently" False. It is possible to lose messages even with TCP mode. This is why rsyslog introduced RELP. And if you knew about this then you'd also know that rsyslog supports compressing the log stream over the network, rendering the size efficiency argument rather moot. Since you should be encrypting your network transit anyway, you;d know that enabling compression is a single line config. (I've never seen an un-compressed encrypted stream)
RELP is TCP based with another layer of protocol over the top. And you're going to be doing disk buffering in any robust system based on it. And I see no one wailing and complaining about it being "too complicated" because hey, network programming is hard, which was my original point. The assumptions involved in sending reliable network messages are manyfold and varied, and depending what you want absolutely don't work if you don't have any type of local buffer.
1. Portable. eg: there is more than one size of byte and byte ordering. The generating systems architecture and platform can change over time and it should not impact the next point. 2. Archival. The file needs to be read back, maintaining all information, years from now, despite changing systems and requirements. 3. Accurate. There should be a minimum of processing over the entire life-cycle, whereby errors can occur. 4. Integration friendly. On large log infrastructure, the initiating machine's log format is only the first step of the log's life. It must be usable by many other tools.
Text logs are in no way portable. People think they're portable because they can read them (you know, if they speak English), but ubiquitously we all grep through a hundreds of thousands of lines of logs by looking for a string we think might be there. Writing a regex to reliably get a log is an exercise in massacring that text back to the broadest conceivable category of things it could be and hoping some version update doesn't change the format. Heaven help you if you have localization concerns.
This is why we have log aggregation systems - no one wants to keep tons of redundant data, they want to sort it into their indexed, databased format that actually provides useful information.
At which point it is very much worth questioning why we're outputing so much text in the first place, when we could output precise binary structs, checksummed and signed, use the bit-savings for redundancy if we wanted and then only render text when it's needed. Which can either be instantaneous if you're paranoid, or never, if you're an embedded device with space concerns.
IMO: the article is wrong. Many of the reason that systemd is hated are technical. And those technical reasons have expressed, and then ignored, many times.
Why are you not okay with this situation? Is there a risk that the systemd log viewer binary on your system will suddenly go away, and you will be unable under any circumstances to somehow get another one?
Is such a (possible, but extremely contrived) situation likely, and if you were worried about it, why did you install a syslog daemon? And why have you never been similarly concerned about how you'd view logs if your syslog daemon stopped writing them?
Also, you realize rsyslog reads systemd log files natively right? As in, not via the syslog protocol, but it parses the binary format and extracts text directly. So number of programs which read is greater then 1, probably greater then 2 (just not to my knowledge) and - oh yeah - the entire format is documented and freely available online.
Slashdot Mirror
And the schools don't dare inform parents of all the risks - parents would say "What, are you crazy? I'm going to risk my kids future so you can get a stupid trophy for your office? DIAF."
I wish you were right, but experience with the parents of brain-damaged young athletes indicates otherwise.
Maybe it's time to consider that they're engaged in willful child endangerment? Nobody, not even a concussed-out coach, wants to be labeled a child abuser.
Maybe so, but it's clear from what happened at Penn State that they just don't want the label. There's way too much tendency to turn a blind eye.
And it's also never been perfectly true, otherwise nobody anywhere ever would have had their system broken by package upgrades.
RPC allows proprietary software to leverage the functionality of your GPL software, which might go against your intent, as RPC becomes the de facto interface of increasing number of components...
Honestly, I don't buy into the whole non-GPL can't link GPL argument in the first place.
Suppose I were to tell you to grab your copy of the 3rd paperback printing of Game of Thrones and look at the second sentence on page 320. Does posting that sentence make this post a violation of GRRM's copyright? Of course not - I didn't copy anything in his book - simply mentioning that it exists and that it contains a page 320 in no way makes this post a derivative work.
Well, when you link a binary to a shared object, all you do is write a bunch of cross references saying that this function call should be replaced with an address associated with this symbol. Then a linker will replace those references when your code is loaded. None of this involves copying anything. Assuming the shared object is in RAM already being used by something else, your OS isn't even copying the GPL code at all when this happens, but even if a copy were made it is an unmodified copy of the shared object which isn't being redistributed - ie it is permitted by the GPL.
Sure, everybody says that you can't link non-GPL code to GPL code, but I am not convinced that a court is certain to uphold this. I could see issues if you try to bundle GPL and non-GPL software into a single larger work, but if you distribute the non-GPL stuff without the GPL content that problem goes away.
The main issue is no one wants to fight the court battle.
But frankly, this has all been kind of irrelevant anyway - you can distribute source packages, let the client do a compile on install, and ignore the entire affair.
It's essentially a project financed behind the scenes by Microsoft to delay the release of Linux updates-- hardware products (like Raspberry PI) that make use of Debian are currently stalled at Wheezy while the whole mess sorts itself out.
He said explanation, not a transcript of the signals you receive from the CIA in your fillings.
What unnecessary code? I'm genuinely curious what you think is completely dispensable as a system service at the init system level.
I mean we need something to launch processes, something to resolve dependencies of processes (init.d has insserv and the LSB headers), networking, disk mounting, time synchronization, authenticating and user session management (else how do your sysadmins log on from central administered sources?). We need process monitoring, logging, we'd like to have cgroups for security. We need some sort of time-based job scheduler.
Which one of these things are you going to drop? Which things are completely inseparable from systemd?
The biggest problem with the Kindle is it's very easy to forget you need to charge it "sometimes".
If there was ever a device that would benefit for long range wireless charging, even at just a trickle, it'd be the Kindle.
It also tends to be that people who forego cellphones still choose to utilize everyone else's. At some point that's a violation of the social contract - you're making yourself uncontactable, but taking advantage of that utility surrounding everyone else. Moreover, you're also starting to demand people adhere to your schedule on your terms: see complaining that people won't kowtow to your contact hours.
With a few hundred people who attend town hall meetings and debates, post on that rep's Facebook wall, call into the local radio station when the rep is on etc, a dozen or so active citizens might well swing a representative's vote,
That's so cute that you believe that! The average congressional campaign cost USD$1.2 million this year. Money talks and it's corporations and other monied interests that are doing the talking, not "concerned citizens." Sure your congressperson will pat you on the head and say "I work hard to make sure our district gets what it needs! I work for you." But the truth is they work for those who pay their way.
You must think things work as they did back in 1946 when this was written. Sorry champ. Those days are long gone.
Money doesn't talk as much as people think, and the return rate on dollars to candidates elected for SuperPACs remains poor. It only works when the messaging goes unchallenged.
Really? Because my immediate reaction was to laugh out loud at the naivete. Companies care about bottom lines. They don't care about security, as amply demonstrated by banks which can have vulnerabilities pointed out to them, and then try to criminally prosecute the guy who tells them, and don't fix the problem.
This has happened over and over right here on Slashdot.
So, unlike FreeBSD then, which is all managed under one giant repository for development purposes despite representing many individual applications?
You know...exactly like systemd (~70ish utilities managed under 1 repository).
How the hell do you think changing PID 1 is supposed to be phased?
It is literally the first process which runs on Linux. Please explain "phased change" when something that fundamental is being altered. You might as well say "I'm outraged we had to get kernel 3.x all at once! It should've been a phased upgrade...."
Actually you only need a correct answer for 1 program: the one running on the firmware of the robot. At which point the question is simply "over the input space, can the program provide outputs which end human lives?"
Of course depending how you define that, you can take this right into crazy town - plenty of cellphones have ended human lives over the possible input space.
This is class political strategy BS: "look at how much drama we're causing! Something is clearly wrong!"
It's why most successful projects have benevolent dictators: because it shuts down most of the political strategems people translate to democracies of any sort.
"RELP is TCP based with another layer of protocol over the top."
You could say the same about HTTP or any other application level protocol,
I don't know, maybe my point was spelled out in the immediately following sentences which you didn't read?
Because you just went on to prove the entire point I was making by talking all about extra network protocols and daemons all created to make networked syslog reliable while you're in the middle of complaining about using a separate daemon to make journald network exportable.
At this point, I have no idea what you think the problem is other then "oh my god journald is new and scary". Because you've been explaining in excruciating detail exactly why you wouldn't use the raw logging protocol of a local system to actually communicate over a network because networks aren't reliable.
In which case, we return to the original issue: what exactly is the problem with using a special purpose daemon for exporting logs over the network? You know, the aforementioned separation of concerns which in any other thread on systemd is apparently the only thing people can talk about?
23.23.142.124
Did a digit go missing? Get flipped? Maybe it meant to say 231.23.142.124
It's redundant in the sense that it's useless. Not redundant in the sense that it's robust.
Yes. You should clearly protest this unfair characterizing by leaping to the defense of people sending rape and death threats to women who write anything which could be construed as criticism! That'll show how peaceful and non-violent you are!
Ban alcohol. A study on the economic cost of alcohol as a function of police resources, ambulance and hospital resources, lost productivity due to injuries and illness, and straight up population destruction, pegs the mean lost productivity at $20 billion per year.
Of course, we're not doing that because history tells us it will be a lot more if we do. Still...
Part of it is also the reason that it should not be considered inconceivable that the way ratings tend to work for sex and violence has something of a schism. Now, generally I think the schism is bad - we can deal with this issue better. But at the same time, in thinking about explaining to children why something is or is not appropriate, violence is a lot easier to explain with far fewer edge cases:
Is violence okay? No.
Ever? Very rarely.
When? It is okay to defend yourself if attacked. You should try and avoid having to do so.
That will get you through 99% of individual life until you get to geopolitics and the diplomacy of nationstates, which a good deal of people will get through life without needing to know about anyway.
Sex on the other hand?
When is that okay? What is okay? Why do some people do that? What is normal? There's a neverending well of questions there, all of which have complicated answers, and which society has an active, ongoing and vitriolic argument about.
There is no concise answer. The simplest things get complicated fast, and very much unlike violence, people seeing depictions or media messaging about it don't have the option (in most cases) of dealing with it by simply not dealing with it. I can avoid most or even all violence and most of us will during our lives. But I and my children are not going to avoid issues of sexuality and it has the potential to be very much a defining element of how their lives will evolve.
To bring it back to the McDonalds and Coke point, this is very much the same reason they advertise. Because you have to eat. You do eat. They're not asking or trying to get you to do something so uncommon. And they know how your nose and satiation responses work. Unless you have an absolute policy of just "no" towards them, then all they've got to do is make "mcdonalds" or "I want a coke" come to the front of your brain with some type of positive feeling when you're anywhere near them.
Except correlations can be due to chance. You can test this, by picking things which can't possibly be causally linked, running the same statistic analysis, and observing how often you get a correlation hit.
And it's important to know this, because such a statistical issue was very much the cause of various excited reports of radiation, cellphones, powerlines and every other type of factor "somehow" increasing risk for cancer, despite the absence of any measurable causative effect.
Until it was realized that if you ran the analysis on any set of variables, you'd always get "roughly double" the risk even if the question was "cancer rates vs. mean daily use of swear words" or "cancer rates vs. global population of pirates".
Which is why they don't just report the result. Because without context, the result is meaningless.
This list isn't a technical complaint, it's a bullet point list which provides no information on what the actual problem is supposed to be.
"overly complex" is a subjective term. Compared to...what exactly? init scripts aren't simple, and they're modular seeing as how daemon dependencies are a real thing. And I'm curious exactly which 70 pieces of systemd can't live without each other, because I genuinely don't know. I do know that it can't be all of them, since I run systemd and don't use the dhcp, network or cron replacements. So, logind maybe? Journalctl is kind of indispensable, but so is syslog on anything else.
Same issue with PID 1. What concerns? What is in PID 1 that is a problem? Why shouldn't it be there? Because the amount of functionality people keep implying is there (the aforementioned 70 daemons) distinctly are not. Whereas, having my init process be cgroups aware and able to use that functionality to provide isolation seems like a pretty good idea to me, seeing as how solid jailing support is sorely missing from Linux.
I'm happy to concede the lib dependencies are an issue. I don't know enough about the underlying plumbing concerns to know if it's avoidable, or who should be blamed - i.e. a lot of systemd is actually a Gnome pull in, which then just flows on to Gnome apps. Which would make it a Gnome problem, more then anything else.
Did you...not take economics 101?
What do you think capitalism is?
systemd has this exact switch. Ubuntu flavored systemd default configuration is to not write binary logs and parse everything directly to syslog.
Cue some example of seeing a half flushed log line in a file, as though someone actually got any information from that line.
It's becoming rapidly apparent to me that the people who complain no one listens to their complaints about systemd haven't realized they don't listen or attempt to learn about what they're complaining about.
" rsyslog in TCP mode is how you achieve this currently"
False. It is possible to lose messages even with TCP mode. This is why rsyslog introduced RELP. And if you knew about this then you'd also know that rsyslog supports compressing the log stream over the network, rendering the size efficiency argument rather moot. Since you should be encrypting your network transit anyway, you;d know that enabling compression is a single line config. (I've never seen an un-compressed encrypted stream)
RELP is TCP based with another layer of protocol over the top. And you're going to be doing disk buffering in any robust system based on it. And I see no one wailing and complaining about it being "too complicated" because hey, network programming is hard, which was my original point. The assumptions involved in sending reliable network messages are manyfold and varied, and depending what you want absolutely don't work if you don't have any type of local buffer.
1. Portable. eg: there is more than one size of byte and byte ordering. The generating systems architecture and platform can change over time and it should not impact the next point.
2. Archival. The file needs to be read back, maintaining all information, years from now, despite changing systems and requirements.
3. Accurate. There should be a minimum of processing over the entire life-cycle, whereby errors can occur.
4. Integration friendly. On large log infrastructure, the initiating machine's log format is only the first step of the log's life. It must be usable by many other tools.
Text logs are in no way portable. People think they're portable because they can read them (you know, if they speak English), but ubiquitously we all grep through a hundreds of thousands of lines of logs by looking for a string we think might be there. Writing a regex to reliably get a log is an exercise in massacring that text back to the broadest conceivable category of things it could be and hoping some version update doesn't change the format. Heaven help you if you have localization concerns.
This is why we have log aggregation systems - no one wants to keep tons of redundant data, they want to sort it into their indexed, databased format that actually provides useful information.
At which point it is very much worth questioning why we're outputing so much text in the first place, when we could output precise binary structs, checksummed and signed, use the bit-savings for redundancy if we wanted and then only render text when it's needed. Which can either be instantaneous if you're paranoid, or never, if you're an embedded device with space concerns.
IMO: the article is wrong. Many of the reason that systemd is hated are technical. And those technical reasons have expressed, and then ignored, many times.
Name 1 that isn't something about binary logs.
Why are you not okay with this situation? Is there a risk that the systemd log viewer binary on your system will suddenly go away, and you will be unable under any circumstances to somehow get another one?
Is such a (possible, but extremely contrived) situation likely, and if you were worried about it, why did you install a syslog daemon? And why have you never been similarly concerned about how you'd view logs if your syslog daemon stopped writing them?
Also, you realize rsyslog reads systemd log files natively right? As in, not via the syslog protocol, but it parses the binary format and extracts text directly. So number of programs which read is greater then 1, probably greater then 2 (just not to my knowledge) and - oh yeah - the entire format is documented and freely available online.