Systemd 217 Will Introduce Its New "Consoled" User Console Daemon

[blackout23]

What argument? That the person making the claim has the burden to provide the evidence for that claim? I don't see how an unsourced wikipedia article refutes that.

I was talking about him not you.

[pal666]

which is why it is modular. It is still monolithic, like the kernel, like Xorg

no, it is not "monolithic, like the kernel"
kernel does not have stable internal api.
it is "modular, like kernel+userspace".

[TheBlackCat]

I was talking about him not you.

Okay, fair enough.

[rober]

systemd seems to be beautiful thing at least on beginning. Now is start to grow and we've got some terrible thing. Can't wait for uselessd and I'm hoping that Arch will switch to more reasonable thing.

Arch without systemd? I don't want to be rude... but that'd be a really sad thing for me...

[Attent?ter]

good thing: this will probably will make things better related to the console daemon.
not a good thing: another thing under the control (and dependent) of systemd.
At least that's what I understood.

[cjcox]

systemd and friends are just different...

Reading all of this the point really is that systemd and friends are "different". It's going to take a lot of relearning. There's some documentation out that helps, and obviously there's a lot of stuff (especially the "friends" aspect) that has yet to be written and/or brought to a reasonable stable state.

It's fun, it's also painful.

I've been playing around with docker for example on a CentOS 7 build using a centos7 base for my docker images and it's sort of a pain that there aren't init.d scripts for services since systemd has some problems (I think still?) inside of a container. Just one of the pains.

So.. while this isn't necessarily a stopper to a Linux "expert"... the typical Linux enterprise is going to suffer for quite some time.

Usually Linus speaks up when changes are being made, even to userspace, that cause a lot of instability (note: that instability here means undocumented and/or unlearned things that are actually under a great deal of change).

For simple things, people won't notice much. But I fear that for many "systems", the switch to systemd and friends will cause a lot of problems early on. And even if learned, as I mentioned, it's still evolving and changing....

Red Hat isn't totally stupid... they realize that they have to support RHEL 5 and 6 for quite some time. I'm just worried that Red Hat 5 and 6 will be sort of like "Solaris 8" in that people will ride those versions "forever" just because of the radical change.

[maslascher]

Just replace systemd by GNU to see how stupid it is to complain that the scope of the systemd project is expending. Nobody would ever complain "they put a whole desktop shell in a compiler", so please, cut it out with the "they put X and X in an init system" or "systemd is too big". The "systemd project" aims to provide a consistent OS middleware for Linux, it necessarily has a wide scope.

Ok, I get it. Systemd makes life a lot easier but not all of users of systemd wants ALL of this stuff. uselessd is a cure for that.
Peace.

[Teho]

Ok, I get it. Systemd makes life a lot easier but not all of users of systemd wants ALL of this stuff. uselessd is a cure for that.
Peace.

Well if you are fine with udev and journald then there's a lot simpler solution: disable those components in compile (virtually everything is optional) or run time.

[jrch2k8]

first uselessd is a joke site and it wont be adopted by anyone in its current path(will be too insecure and won't provide any benefit over old sysV)

second, the systemd requires interdependencies(the term you were discussing for 4 pages) because systemd use the kernel security frameworks and all sub process are sandboxed by the kernel for security, so they require those interfaces available from the main daemon in control of PID1 and this is not because systemd want to control anything but because the kernel requires it this way to handle security properly(you can check LKML and see why were designed this way, btw this happens too in Solaris and OS X and AIX but since you don't have 300 different init systems there you won't notice it).

The problem here is nobody except systemd developers took the time to work on this level of security with kernel guys and those who had the skills to try replace it saw no need to since systemd do it quite good and decided to contribute there instead, so all people left are trolls or crybaby without the technical skills to do anything or even understand why was done this way going vocal trying to use big words like bloated, big, etc. trying to convince people.

so what is stopping X init system to offer the same features as systemd, nothing just get a guy with enough technical level to speak with with kernel developers and implement at least basic cgroups, namespace and seccomp into it and provide an compatible API, thats it and its way better than rollback systemd to the 80's security structure of sysV just because you arent able to understand why is more secure this way

[Delgarde]

Now why did they use the systemd umbrella instead of keeping every project separate, or under the Fedora name?

Well, that's obvious enough. It's under the "systemd" umbrella because it's the systemd developers doing it - and it's not under the "Fedora" name because it has nothing to do with Fedora, except in so far as some of the systemd developers work for Redhat...

As to why they put everything into one big code base, that I don't know. I assume it has to do with not wanting to deal with API stability guarantees on internal libraries shared between components.