And even then, it never even helped the init at all. If journald is corrupted by a drive/partition improperly dismounting, it hangs the boot process. None of the parallelization claiming init solutions have been able to properly kill every single process correctly to where a partition/drive can avoid a dismount issue. In fact bsd/sysvinit still suffers this bug. If journald didn't have to parse itself at boot and only did a simple overwrite as other logging daemons do it wouldn't have said issue. Init helped? Not at all. Runit has this problem, as does Bootscripts, s6, launchd, SMF, svchost, God, etc.

If anything the addition of journald as mandatory only makes this issue compounded. Even Lennart can't fix this issue because here's the linchpin... IT CANNOT BE FIXED.

This problem is on every operating system out there and there have been no solutions to permanently fix this issue, only bandaids in the form of root partition check at boot systems to clean up the partition journals before remounting from read-only to read+write to which you the person can only hope and pray nothing was corrupted beyond repair, deleted, or the partition table didn't get killed.

here is a KDE developer saying where systemd could be an advantage.
http://blog.davidedmundson.co.uk/blo...emd-and-plasma

I think it is clear that the future KDE will require systemd.
If you have a lot of ugly code that you can replace,if no one takes over you will replace it.

I wonder what would leeds to more mass exodus,
a non functional KDE or systemd
its good that we do not need now to think about that

Easy: don't follow the links in Michael Larabel's articles on phoronix.com about systemd

"Could" is a heavy handed word, but honestly they only see a short term goal. Plus giving up control of DE daemons from kded to the init system seems a bit ill fated. It's nice to have internal service supervision, but keep it internal. The DE and init are completely separate entities.

no, not that easy, got this link via a german site

i think it is not
do you have any other opinions that we can compare ?

sure, for example, I think that if you post some info is more productive than just post an opinion wit out any info at all like trolls do.

that would make this thread almost all just trolling

It's only clear it is being considered but only considered for one aspect, logind truly. This part of systemd is fickle and duplicated. The only other thing they would like is the service supervision portion, but even then, already duplicated a dozen times over. Otherwise KDE/Plasma is going to just continue on as-is.

Weak argument really, in my opinion.

and how do you think did we reach 85 pages to a thread with this topic?

what this ?
this is possible for the devs the only argument that counts

Not to place judgment, but they'd be damn foolish to entrust systemd with how KDE operates. That's literally a cop-out to saying the KDE developers are getting lazy and don't want to clean up their own damn coding mess and want someone else to do it for them. And then what? If they want better design, do it yourself first, not dump your sh*t on someone else.

If that's the case, then KDE can be lined up right beside Gnome in the pasture graveyard. Goodbye and good riddance to bad rubbish if that's their fickle excuse. Sorry, but there's no real way to say it less directly.

1 members found this post helpful.

i doubt supporting only logind would cut out any code (compared to console-kit, not that there are other logind alternatives)

actually i can't think of anything in the thing that lets DE's trow out a noteworthy amount of code
if you got something, id appreciate it

Indeed, you can. But there is a caveat: Someone has to maintain those solutions. It has literally taken years for someone to take up Consolekit maintenance . The Linux landscape is ever changing, which means that even the traditional solutions will have to adapt in one way or the other to changes (like kdbus, for example).

This is also totally dismissing the features that systemd provides for other projects, which are not offered (or only in a very convoluted way) by the traditional solutions. For example, here is a blog post from a KDE developer about why they use systemd and why they see it as a good thing: http://blog.davidedmundson.co.uk/blo...emd-and-plasma
Unless someone provides options to those developers that match the features that systemd offers you will see the traditional solutions being phased out.

It is indeed needed. Other projects do not make themselves dependent on systemd components for fun, they do it because systemd provides them with functionality they don't get from any alternative. While your servers may run for now without systemd, you will see the day coming where even there systemd is needed, because your daemons will want to use functionality of systemd components.
If you don't want that it is essential to provide alternatives that give the same functionality to developers. I have linked to a post from a KDE developer in my previous post, I recommend to read that and ask yourself how you would react if someone demands from you not to use the new functionality, with the claim that all the functionality is already there.