The Politics of systemd Part 3

Message

mv · Post by mv » Sat Jul 28, 2018 6:43 am

steveL wrote:DCOP over AF_TIPC is what we want.

dbust turned into crap

The first you mentioned several times, but I read some informal descriptions and still do not see the technical reasons you have apparently in mind:
What is so much better on communication using TIPC vs. sockets?
Is it speed? security? Both and/or other things? Why?
The only argument which I found so far is actually in favor of dbus: Sockets can possibly be more easily exported over net (not sure about TIPC here).
Can be you be a bit more verbose, please? (Also, e.g. what specifically had changed in dbus recently which has "broken" it?) (Note that it is still possible to use dbus without policykit).

Post by **pjp** » Sat Jul 28, 2018 4:49 pm

FYI, I merged a few posts here from the "SystemD free system/gentoo".

If some replies here seem out of place, that may be why. A couple/few of them are old enough to exist in this thread several pages back, so they'll likely go unnoticed here.

Yamakuzure · Post by **Yamakuzure** » Mon Jul 30, 2018 10:53 am

steveL wrote:
Yamakuzure wrote:Erm, yes. Dbus brought nothing new to the table except
Erm, nope.
You really should do your research before making such bald assertions.
It's not like this has not been discussed on these forums, several times that I recall.

Sorry that I didn't make this clear: D-Bus brings a lot to the table other available IPC mechanisms do not out-of-the-box. Unavailable IPC mechanisms like DCOP do (of course) not count. And TIPC (aka "Cluster Domain Sockets") is something completely different. But see below.

steveL wrote:DCOP over AF_TIPC is what we want.

And someone thought it would be a great idea to kill DCOP and switch to D-Bus, so that's off the table. Lamentable, yes, but still irreversible, no matter how often and hard we bang our head onto the table. (I did, when I saw that move. I was outraged that a perfectly fine system was replaced by ... that...)

I can see why you favor TIPC. It is already what kdbus (that has nothing to do with D-Bus, btw.) never achieved, it is included in the kernel.
But TIPC is meant for clusters. If D-Bus is overkill... well... I'd favor it anytime anyway over D-Bus. But how do you advertise using Cluster oriented messaging mechanisms on single-machine systems?
Yes, that would still be the (much) better variant to D-Bus. Unfortunately I can't see this happening anytime soon.

Naib · Post by **Naib** » Mon Jul 30, 2018 12:17 pm

but isn't that because aspects of the "linux desktop" has evolved to a swarm of processes that need to intercommunicate. CORBA and DCOP provided aspects of this but clearly didn't scale otherwise KDE & GNOME would not have opted for a common solution. Now maybe DCOP was more capable than CORBA (that would explain why some KDE dev's were more vocal in replacing DCOP than GNOME developers were in replacing CORBA).

Such an architecture requires a more complex communication stack and maybe DBus over-engineered the problem... they definitely implemented it poorly. The concern is such a bus is becoming used more and more and systemd heavily relies on it. From their perspective they are blind for the period between the kernel launches init to the point the file-system is mounted and dbus is up and running and as such there will be some push for a kernel-level IPC. Does it need to be as complex as DBus --> KDBus --> Bus1 ? dunno but their architecture will push for something that can accept dbus-like message it so init and udev can communicate before mount & dbus is live. Could they push dbus packets over some other kernel IPC? of course they can (you can push usb over tcp/ip transparently to the host machine) now whether systemd would accept this before handing over to userland is a different question

Anon-E-moose · Post by **Anon-E-moose** » Mon Jul 30, 2018 12:46 pm

and maybe DBus over-engineered the problem... they definitely implemented it poorly

*NEWS-FLASH* Engineers around the world are hunting for their pitchforks and torchs over the usage of the word engineered with d-bus. Stay tuned for latest developments

Naib · Post by **Naib** » Mon Jul 30, 2018 1:10 pm

Anon-E-moose wrote:
and maybe DBus over-engineered the problem... they definitely implemented it poorly
*NEWS-FLASH* Engineers around the world are hunting for their pitchforks and torchs over the usage of the word engineered with d-bus. Stay tuned for latest developments

pfft... you know what I mean... There is actually an architectural spec w.r.t. DBus so some thought into the needs took place as oppose to organic growth boxing an implementation in. However the flip-side of this was it was "designed by committee" and I honestly cannot think of any design by committee that did not fail in some way as they try to accommodate too much and appease too many to produce an accepted design.

Anon-E-moose · Post by **Anon-E-moose** » Mon Jul 30, 2018 1:23 pm

IT was meant to be funny, thus the lol.

From what I remember the "spec" was done long after it had been implemented and put into play in the linux world, thus the reason for much of the convoluted and downright crappy code in parts of it. It should be combed through with a fine toothed comb and rewritten to be clean from the start, following a proper spec. JMO.

Naib · Post by **Naib** » Mon Jul 30, 2018 1:38 pm

oh I get that, but good old Poe's law ... some people may take understanding for acceptance & advocating.

The spec probably was written and formulated after the fact as every single part of linux has been ad-hoc organic growth. No proper system design. Fantastic problem report management does make up for this.

I agree with actually stepping back looking at the use cases, looking at what problems such as dbus is meant to solve and seeing if dbus actually meets them would be advisable but who is going to do that? especially when what exists "works™" The fact one of the arguments to force in kdbus was performance related highlights this and iirc Linus stepped in an actually looked at the userland side of things and listed out a lot of implementation issues which would speed up dbus.

This removed their argument that the need for kdbus was performance related as userland could be improved, in some places trivially (iirc systemd has a separate implementation that appears quite lean: sd-bus but cannot be used alone) yet they are still pushing for an in-kernel IPC and the present argument is early interprocess communications bespoke to systemd

Anon-E-moose · Post by **Anon-E-moose** » Mon Jul 30, 2018 1:56 pm

IIRC the early need for dbus/kdbus/<bus-1/whatever the latest is> was predicated on the need for messages, for logging early in the boot process.
As Linus and others pointed out, that's kind of what the print functions in the kernel were for, not for a log per se, but so that users could see what was going on.

It's funny that unix has been around for a very long time (computer time) and has gotten by without the need for an init system to send messages to a log mechanism early in the boot process.

OTOH, I don't see the push for kdbus/bus-1 to be included in the kernel in the last year.
Now what that means, I'm not sure, they could have given up, they could be rallying for an even greater push to have it included, or perhaps RH will simply install it in their kernels and let the rest of the linux ecosystem do what they want. Time will tell on this aspect.
Part of the lack of push, is I think they've worked on the internals of d-bus to make it faster.

Naib · Post by **Naib** » Mon Jul 30, 2018 2:07 pm

I think you are right, not only in re-grouping for a different way to force something into the kernel (whether it is needed or not is a different story... I wouldn't be surprised if an argument along the lines of virtualization and logging will be played) but also in improving dbus.

bus1 as a kernel IPC hasn't seen much activity, but dbus-broker ( https://github.com/bus1/dbus-broker ) and sd-bus (system-d implementation of dbus) have with an aim to be faster and lightweight.

At least they took on board the criticism of solving the problem in kernel-space when user-land had so much still to offer.

axl · Post by **axl** » Tue Jul 31, 2018 12:55 am

Ant P. wrote:
axl wrote:
Ant P. wrote:Gentoo's own service manager has been on life support for the past 5.

I'm sorry. What's a service manager?
A part of the system with clearly defined boundaries and responsibilities that runs on top of an init system. OpenRC was this until it started poorly reimplementing "cool" features from other software the current maintainer had been playing with.

You mean like a daemon manager? /etc/init.d/daemon start|stop|restart? or systemctl start|stop|restart daemon?

If that's what you're referring... good riddance. no distro ever caught a daemon at it's fullest and we should not pretend it to be possible.

I'm starting to feel pretty comfortable being a nazi about both systems. most people can't actually prove to know one.

actually both systems hide the fact that people don't understand their programs and would and could do jack without an init system and "service manager" that does that for them.

which I think it's a damn shame. how hard can it be to learn, _ONCE_, how to operate an apache from console. or a postfix. or an iptables firewall. there's a finite number of daemons in every mans life. should not start an init flamewar just because you can't control your daemons.

axl · Post by **axl** » Tue Jul 31, 2018 1:44 am

I got here in 99 because I was tired to compile cyrus-imapd and postfix and amavis and php manually in slackware. it was horrible work with terrible inconsistency in libraries even in short periods of time like 6 months.

I still remember now, my mom was doing the christmas tree and I was compiling gentoo right next to it. that was my 99 x-mas gift. gentoo.

People need to be comfortable with just /bin/sh as init. and go from there. build everything ground up.

and also be placed mid systemd and figure that out.

I think everyone should do both. And I really do not think anything will change in the next 10 years. Both schools of thought are here to stay. Both types of system coexist.

And if you want to work in the field, you need to be comfortable with both.

Besides, it's just a stupid simple layer. Doesn't help at all with "services". I call em daemons. It's what they were originally called and I still think it's fitting. People still dont know how to control em. rely on "service manager". poor delusional people.

Yamakuzure · Post by **Yamakuzure** » Tue Jul 31, 2018 9:15 am

axl wrote:People need to be comfortable with just /bin/sh as init. and go from there. build everything ground up.

Sorry, but that is too extreme. My first thought was the bs word, but I restrained myself.

What would you do when you had to face an empty sh and had to start everything from there?
Right, you would start to write an init script.
Then you want to replace something and run into dependency problems. What'd you do?
Right, teach your script to start things in the correct order.

... and after a decade or so, you have a service manager. Maybe like runit, maybe like openrc, or anything else.
What good did that decade do to you? Nothing. Nothing but pain and a lot of wasted hours.

And now you know why LFS is rarely used and DIY is dead.

axl wrote:Besides, it's just a stupid simple layer. Doesn't help at all with "services". I call em daemons. It's what they were originally called and I still think it's fitting. People still dont know how to control em. rely on "service manager". poor delusional people.

You know, most people want to work with their computers and not permanently on them. We are Gentooers, we already have enough of the latter. Thanks.

krinn · Post by **krinn** » Tue Jul 31, 2018 9:30 am

axl wrote:Doesn't help at all with "services". I call em daemons. It's what they were originally called and I still think it's fitting.

A service could have no usage in background, a daemon is made for that. So your concept of service is wrong, you mistake it with deamon that's all.

khayyam · Post by **khayyam** » Tue Jul 31, 2018 11:20 am

axl wrote:I'm sorry. What's a service manager?

Ant P. wrote:A part of the system with clearly defined boundaries and responsibilities that runs on top of an init system.

axl wrote:You mean like a daemon manager? [...] If that's what you're referring... good riddance. no distro ever caught a daemon at it's fullest and we should not pretend it to be possible.

axl ... you're past the point of being an annoyance with your constant trolling, speculative prognosis, and circular reasoning. Are we supposed to know what "caught a daemon" possibly means, or what might qualify the absolute condition of "at it's fullest"? You act as though you have insight when your entire argument turns on pronouncement, and arbitrary association.

axl wrote:I'm starting to feel pretty comfortable being a nazi about both systems. most people can't actually prove to know one.

Good for you ... but could you refrain from treating the forum as though it were your personal lebensraum.

axl wrote:actually both systems hide the fact that people don't understand their programs and would and could do jack without an init system and "service manager" that does that for them. which I think it's a damn shame. how hard can it be to learn, _ONCE_, how to operate an apache from console. or a postfix. or an iptables firewall. there's a finite number of daemons in every mans life. should not start an init flamewar just because you can't control your daemons.

Which translates as: "here I am starting a flamewar because I can't control my behaviour, or mind."

axl wrote:I got here in 99 because I was tired to compile cyrus-imapd and postfix and amavis and php manually in slackware. it was horrible work with terrible inconsistency in libraries even in short periods of time like 6 months. I still remember now, my mom was doing the christmas tree and I was compiling gentoo right next to it. that was my 99 x-mas gift. gentoo.

In which case you remember incorrectly, the initial gentoo release was not until July 2000.

best ... khay

fredbear5150 · Post by **fredbear5150** » Tue Jul 31, 2018 4:01 pm

actually both systems hide the fact that people don't understand their programs and would and could do jack without an init system and "service manager" that does that for them.

which I think it's a damn shame. how hard can it be to learn, _ONCE_, how to operate an apache from console. or a postfix. or an iptables firewall. there's a finite number of daemons in every mans life. should not start an init flamewar just because you can't control your daemons.

I don't understand car tyre technology - but that doesn't mean that any time soon you will see me head into my garage with some sheets of rubber, a few steel belts and a box of tools to go and make my own tyres!

Post by **pjp** » Tue Jul 31, 2018 4:26 pm

Merged previous 6 posts from systemd or openrc.

Anon-E-moose · Post by **Anon-E-moose** » Tue Jul 31, 2018 4:31 pm

pjp wrote:Merged previous 6 posts from systemd or openrc.

Way to pollute a perfectly civil thread.

Yes, I posted with sarcasm in hand *laugh*

steveL · Post by **steveL** » Sat Aug 04, 2018 2:01 am

axl wrote:I got here in 99 because I was tired to compile cyrus-imapd and postfix and amavis and php manually in slackware. it was horrible work with terrible inconsistency in libraries even in short periods of time like 6 months.

I still remember now, my mom was doing the christmas tree and I was compiling gentoo right next to it. that was my 99 x-mas gift. gentoo.

Lies.
Krinn asked you flat out whether you even use Gentoo, and what a surprise, you evaded the question.

Sticking "I LOVE GENTOO" in your signature does not prove anything.
In fact it sticks out like a sore thumb.

axl wrote:And if you want to work in the field, you need to be comfortable with both.

Oh please.
Stop lying.

axl wrote:Besides, it's just a stupid simple layer. Doesn't help at all with "services". I call em daemons. It's what they were originally called and I still think it's fitting. People still dont know how to control em. rely on "service manager". poor delusional people.

You really are delusional if you think any of us believe a word of what you write.

Lay off the kool-aid; it's making you talk stream-of-consciousness nonsense which only makes you and other systemdbust fanbois look even more clueless than already thought.

steveL · Post by **steveL** » Sat Aug 04, 2018 2:05 am

Naib wrote:some people may take understanding for acceptance & advocating.

No, we just take your lack of understanding of sociopolitical and cultural matters to be a given, since we've read your various meandering posts about how great it would be if "everybody just got along", and we know you do not have a clue when it comes to software engineering either.
Why would you? You're an electrical engineer who works with high-voltage power.

Interesting as that might, or might not, be as a domain, it is only one sphere of software applications, and from your perspective it's your whole profession.

Where there is useful crossover, is in functional (or "black-box") testing, which would be a much more fruitful discussion, imo.
In that spirit, you should read this.

steveL · Post by **steveL** » Sat Aug 04, 2018 3:43 am

steveL wrote:DCOP over AF_TIPC is what we want.

dbust turned into crap

mv wrote:The first you mentioned several times, but I read some informal descriptions and still do not see the technical reasons you have apparently in mind:

They're in the last link I gave.

The assumptions at the end actually work in our favour.

See also the next two posts (and the main post's breakdown of the signal flow.)

Essentially TIPC is exactly what dbus is trying to be, only done correctly, and available across platforms for nearly 20 years, with much more solid technical provenance (Ericcson, not Poeterring.)

mv wrote:Also, e.g. what specifically had changed in dbus recently which has "broken" it? (Note that it is still possible to use dbus without policykit).

You always ask me this, and you always mention polickysh1t like I care.
The initial protocol spec was fine, rather harmless.
Eveything since then, from when sievers and poeterring got involved in design and working on code, is total crap.

I am sorry if you can't see it, but I don't have headspace to take thirty posts arguing the toss.
I simply don't see it as relevant; nor do I see it as something on which anyone else should waste time and mental focus.

Take a look at the uses people put DCOP to. Now factor in that it was twice as fast as dbust from the beginning.
And what you have just read about TIPC, including on its site.
Then you will see why it is better simply to write-off dbust as a dead-end path.

mv · Post by mv » Sat Aug 04, 2018 4:33 am

steveL wrote:They're in the last link I gave.

Thanks for the interesting link. Compared to this the wikipedia page appears misleading: It contains none of the mentioned facts clearly. (As mentioned, not even the tunneling capabilities were clear from wikipedia, although admittedly these seem to be relatively new).
Perhaps many people aren't aware of it who actually should. I am not speaking about dbus developers (they certainly are and choose to ignore due to NIH) but e.g. KDE folks.

You always ask me this

I never talked/asked about technical details of dbus. In fact, the first time I looked at details was a few days ago...

steveL · Post by **steveL** » Sun Aug 05, 2018 1:22 am

mv wrote:Perhaps many people aren't aware of it who actually should. I am not speaking about dbus developers (they certainly are and choose to ignore due to NIH) but e.g. KDE folks.

KDE is a huge project; the people who know what they're doing tend to work on their specific projects, in their spare-time from employment in the field or academia. They also want to enjoy their real lives.
As with other big projects like the kernel or Gentoo, it's relatively easy for a newcomer to carve out an area and (unlike the kernel only) fsck it up.

This explains how we got here, and it also explains why it's unlikely to be KDE as a project who sorts it out; it's far more likely to be a patchset, perhaps contributed by someone looking to become a KDE developer (and thus prepared to jump through all the hoops and the long review process.)
The same thing applies to all the systemdiot hooks scattered through the codebase; elogind provides the same, but the point is not to have platform-dependent calls anywhere except in one specific module, called via a stable platform-independent ABI (that can be provided on other platforms like the BSDs without any hostility required.)

I'm only presuming this still has not been done, since it was given as a spurious "reason" why systemdbust was needed; because the basics were not being done right.

I never talked/asked about technical details of dbus. In fact, the first time I looked at details was a few days ago...

OK, but you've definitely asked me that question before, also about other lamedesktop projects.

Like I said, though, start with the uses DCOP put to, and that it was twice as fast as dbust from the beginning.
That means that it was already the wrong move to use dbust, afaic; no implementor would need to know more.

The question of speeding up DCOP, should first consider using GNOME's ORB, since that was faster still, and allows much more interoperability out of the box; then move on to the transport (for which TICP is the clear winner.)

But starting with a worse implementation, that is slower, is just plain dumb.
Doing so only to end up with something that does not even deliver on the initial uses of DCOP, is cause for letting people go.

It's got to be about what it enables for the end-user.
--
Hopefully no-one needs an explanation about why the "irreversible" argument is completely risible when it comes to software.

Tony0945 · Post by **Tony0945** » Sun Aug 05, 2018 2:36 am

steveL wrote: It's got to be about what it enables for the end-user.

In a true spirit of open source,like GNU, yes. In a corporate environment, only the bottom line matters. All else is just a means to shareholder value. In a corrupt corporation (most today are corrupt) it's about making the CEO's numbers for his bonus and screw shareholder value.

axl · Post by **axl** » Sun Aug 05, 2018 3:46 am

khayyam wrote:axl ... you're past the point of being an annoyance with your constant trolling, speculative prognosis, and circular reasoning. Are we supposed to know what "caught a daemon" possibly means, or what might qualify the absolute condition of "at it's fullest"? You act as though you have insight when your entire argument turns on pronouncement, and arbitrary association.

Am I? I'm sorry.

What I meant by "caught a daemon" is the fact that even though some daemons have been there since forever, there is still no service manager in gentoo.

You might want to call files in /etc/init.d or files in /lib/systemd/system as service files or whatever. But most of the time they don't work. That is ... if they exist at all. For instance, find cyrus-imapd systemd service file. Or they just don't work. Because there is no fancy layer of stupid proof.

And other distros try harder. For instance debian variants don't just configure your service and start it for you when you install it (which gentoo doesn't do) but also restarts it for you when you upgrade it (which also gentoo doesn't do).

With all the other insults, it's hard for me to discern where you stand on the issue. U barely say anything about it. I went on and said lots. Maybe too much. I'm afraid to go back because I might go circular again.

I'll try to keep it donald_trump easy and non-circular. being fooled by (whatever) init into thinking it's doing services for you .... BAD. SAD.

learning to do your own service file in either init... GOOD.

Would you disagree with that? and to the original thread / point... if it were any other subject and someone would randomly ask for a guarantee for the next 10 years... ohhh... you didn't look at the original thread? the dude was looking for someone to guarantee his install with openrc for the next 10 years. THAT WAS the original thread.

also, the idea of "service manager" is stupid. and it's masking incompetence. I cannot go to an interview and say things like "service manager". if that daemon is crashing with that message what would you do? I would ask the service manager to ...