College is not needed to learn how to learn things.
I think it's important to point out that while you may not have needed college to give you a good learning methodology, the parent poster and likely many other people do. And for those who don't need college to do so, they may learn how to learn faster in college than they would have without college.
My point is still valid no matter the victim or the culprit. I was merely using the previous scenario as an example. It's just as true if the roles were reversed or in any other number of scenarios.
For example, let's say that a parent has told their child that they're not allowed to eat any candy until after dinner because it would spoil their appetite. The parent then proceeds to pour a bowl of candy onto a nearby table and then walks out of the room. And of course, the child takes and eats some candy once the parent leaves. Now, is it the child's fault for taking the candy? Absolutely. However, the parent should have known better than to leave such a temptation for the child in such an accessible place and then walk away. The parent should also carry some blame because it was a foolish thing to do.
My prior example was not meant as a commentary on telling women (or really anyone) what they can and cannot wear. Rather, it was meant to show that in certain situations it is unwise (and I posit even immoral) to do things that would be an obvious temptation to another party to do wrong. Not that that would make the culprit any less blame worthy.
it is possible for a butt naked woman to walk up to a sex starved man, and the man to know he has no right to touch her without her consent, and to simply not touch her. if he chooses to touch her without her agreeing then he, and he alone, has committed a crime. she has committed no crime. none
you are responsible for your choices and what you do. no matter the temptation. no matter the context
the actions that come out of you is your fault only. 100%
The problem I have with such a view is that it completely absolves the "victim" of any blame whatsoever. Now, that doesn't mean that in your scenario that the person who touches the woman is not at fault. He is. Absolutely, he is. But is it not also morally wrong to put someone into a situation where you know they're going to have a hard time doing the correct/legal thing?
Of course, that requires that the "victim" be fully aware of the potential dangers of what they're doing, and in the larger context of this conversation that's just not the case. However, my point still stands. Just because one is a victim does not mean that one can be wholly absolved of any wrongdoing. Naturally, the culprit holds full blame for their actions, however in the larger context the victim can also hold at least some part of the blame for putting the culprit in such a situation.
It's also married to the logging daemon. So add in the complexity of that, please. Also, you'll have to throw in d-bus and udev, since it ate those too and those are core services for it as well.
You're right, it requires journald, dbus, and udev (if it's not running in a container). And if you want to do process monitoring or device monitoring during boot those (dbus and udev, not journald) are a requirement anyway. Which is why Upstart pulled them in. They do add some complexity, sure, but they're fairly well tested components and again, not very large by comparison. And in the end, you end up with a system that can give you more information about a failed boot, or even attempt to solve problems with failed startup services since it can get more detailed information about what went wrong.
Having Unix Domain sockets is minimally troubling, because it's minimally complicated. Adding IP networking is more troubling, because it's more complicated. It provides not just attack surface, but also more opportunities to make mistakes which could result in PID 1 cratering. . . . Right now I can mix and match syslogs, init daemons, whatever. systemd wants to take that away from me.
As far as I know PID1 doesn't do IP networking. That's another (optional) component, so the attack surface should be the same as any other IP networking daemon. Unless I'm missing something?
I see a lot of people saying that it's possible for things to go catastrophically wrong during a systemd init, but so far there it really hasn't happened too often. It's usually something like one of the core components is missing or it's related to one of the earlier versions of systemd. And it was certainly possible for things to go terribly awry when using SysV init, as I personally encountered that once. I don't know, I can see why more code could mean more potential breakage, but that just doesn't seem to be the case.
And you can still mix and match most things, including logging systems (you just have to have at least journald).
Some things about a system need to be complicated.
PID 1 is not one of those things, nor does it need to be married to a specific log daemon.
The core part of systemd isn't that complicated. And on the user side it's significantly more simple. You can't mess up your boot process by mistyping something in one of the boot scripts (one of the problems with using sh scripts for boot). I'm not sure exactly why they tied it directly to journald other than journald having a better interface (and being available earlier in boot than other logging daemons), plus it's still possible to use another logging daemon if you want. Albeit it will run alongside journald.
Ergo, parts of systemd need to be complicated.
Which parts, and why? So far, no one has given a satisfactory argument as to why the complexity now encompassed by systemd needs to be part of a single project, let alone one controlled by someone who has shown themself to be not particularly competent.
It's not like systemd is some huge single project. It's all in one repository, but it's actually made up of a bunch of smaller, modular projects that are all under the "systemd" umbrella. And I really don't think it's relevant to bring the maintainer of the project into this. The community at large has swayed the direction systemd has taken quite a bit (as evidenced by the huge amount of feedback in the mailing lists) and apart from some core standpoints the maintainer is flexible.
The "simple solution" argument really loses steam when you think about the kernel. It's not exactly a simple piece of code. It's complicated. With many different parts that do many different things. Is the kernel a problem?
Yes. Yes, the kernel's all-encompassing complexity is a problem. It causes serious problems all the time. Like, for example, just trying to build a kernel. When was the last time you built a kernel of any complexity from the source tarball and without starting with an already-proven-working-on-your-hardware
However, the problems caused by breaking up the kernel were perceived as being more serious than the problems caused by not breaking up the kernel. Is that true? It's hard to say. Minix is only now becoming vaguely usable as a general-purpose OS for normal users, and the Hurd is still more like the Butt... of every joke about microkernels. Granted, if they'd received more support then perhaps they'd be dramatically further along, but their architecture is part of the reason they haven't had more support. It's sort of inseparable from them. If Linus had chosen to write a microkernel-based system, it's conceivable that far fewer of the people who made Linux the success that it is today would have gotten involved. Likewise, there's no guarantee that anyone who helped make Linux great would have worked on the Hurd or on Minix — perhaps most of them (those attracted to Linux by the GPL aside) would have gone into one of the BSD camps.
Systemd is broken up into modular parts, so it's actually more like Minix than Linux in this regard. Obviously the PID1 part isn't modular, but it's also not terribly large or complex in comparison to the project as a whole.
It's complicated because it needs to be so, just as systemd must be.
No. PID 1 ought to be as simple as possible, so that it can be as trouble-free as possible. If PID 1 causes a problem, then someone ought to be taken out and shot. No, okay, not really, but it is unforgivable. If one thing needs to work properly, it's the kernel, and the second thing that needs to work is the process that starts and maintains the other processes. Indeed, the need for simplicity in PID 1 is the reason why inetd is still a separate thing even today, regardless of what you call it... unless, of course, your system is based on systemd. There are real and good reasons not to have any kind of bidirectional networking in your PID 1, most of which should be intuitively obvious to anyone who has given this issue even a cursory thought.
Finally, there's really no reason why there has to be only one facility for starting processes. There's nothing wrong with init starting some processes itself, and starting some scripts which start some processes, and starting a script which starts a daemon which starts processes in response to network connections. In fact, this is precisely the issue that cgroups was designed to solve! You create cgroups with simple file- and directory-based commands, because this is Unix[like] and everything's a file, etc. And you put the processes that belong to specific tasks into them, and it doesn't matter how the processes are started, because they all belong to certain cgroups and therefore they're easy to manage. Yet, somehow, systemd got its foot in the door by being the guardian of all cgroups.
What was needed wasn't one collection of daemons to rule them all. What was needed was one collection of utilities based around a useful LGPL, BST, etc-licensed library to simplify using cgroups. Instead, we got this mess and we're arguing about it instead of something really meaningful like which text editor is best.
Again it seems to me like you're thinking systemd the PID1 part is the entire systemd project group, but it's not. PID1 doesn't require that much. As for having sockets in PID1, I don't see the problem. You say that it should be obvious why it's troublesome, but I don't see why so if you could please humor me and tell me why.
Anecdotally I've not seen it cause any problems so far. I have, however seen a broken init script prevent booting.
"I think Michael is like litmus paper - he's always trying to learn." -- Elizabeth Taylor, absurd non-sequitir about Michael Jackson
