Because Slackware is one of the oldest Linux distros around and even though I am not currently using it that should not stop me from learning from it.
at the time of posting? maybe not. at other times plenty of better things to do.

It's still just a patch though, so it's still unofficial. If Linus and crew accept this, then this is going to give Lennart all the weaponry him and the rest of the systemd developers they need to force redevelopments for kdbus or even force systemd out on users unless Gentoo can effectively maintain eudev with minimal upstream. I don't see this as a positive addition to the kernel.

1 members found this post helpful.

from Greg K-H's G+ page:
Considering how long it took to get there, It appears to be a done deal.

https://plus.google.com/111049168280...ts/L6vvYQpiAEq

The patch is submitted, but remember even then it must be reviewed and this code has been under heavy scrutiny by the main developers. It may be accepted, or it may be kicked out. Lots of patches are always submitted, but not all of them gain acceptance. Time will tell though, and I hope this doesn't mean what I think it means.

1 members found this post helpful.

i wonder who was it that woke up one day and though "hmmm we will need 18446744073709551615 different flags"

If it's stable is one thing, but if it's not stable, it can be bad.

The kernel has always had some issue at some point rear it's head, and caused a major problem. Problems are fixed but not often does a problem get repaired swiftly. Case in point: Everyone assumed EXT4 was stable and safe until way late in the 2.x series to early in the 3.x series something went terribly wrong and caused data-loss. It took patches and a few revisions before it cleared up and EXT4 was safe again, but the problem was real.

The reliability of this feature is going to be called into question, and should anything cause a problem with kdbus, anything using it would be at the mercy of the kernel, not just D-Bus. This is a kernel driver, not a system daemon that can be patched and rebuilt quickly, restarted with a command and trigger, and such. If anything were to cause kdbus to fail, it would not only crash the kernel, but any work to repair it would have to be done via chroot or another system by proxy, and then rebuild the kernel, reboot the machine, etc.

Plus even by then, who knows what may have changed in the kernel? 3.19 is still a few revisions out, and we haven't even pulled the plastic wrap off of 3.18 yet. By that time, improvements might even be made to netlink and binder, but again who knows?

1 members found this post helpful.

I have the greatest respect for Debian. It is a good thing to see people who run other distros posting here.

2 members found this post helpful.

all in all kdbus looks to have a documentation


i personally would just like the systemd related devs to STOP F**KING CALLING IT ZERO COPY
it's shared memory, zero copy is something different entirely
(and you don't want RAM to RAM copy using zero copy)

2 members found this post helpful.

I know back when Kay got blocked from the merge of kdbus patches that Linus said Kay needs to clean up the coding mess that was in udev and such, so how much of the bad code was, in fact, cleaned up that would make Linus reconsider the kdbus patch?

http://lkml.iu.edu//hypermail/linux/...4.0/01331.html

I know kdbus now is mainly is Greg's baby, but I do wonder the state of code still coming from Kay will affect the decision on this, especially when Lennart made it public knowledge he planned on killing udev's netlink support in favor of kdbus.

http://thread.gmane.org/gmane.comp.s...40/focus=19510

If this ends up "breaking" non-systemd systems, I don't want to even imagine the flack the kernel team could get for this, much less the systemd developers. The question is, who's neck will go on the chopping block if this breaks systems, or is used maliciously to purposely break systems?

Has kernel code ever been introduced that broke systems on purpose directly or indirectly and was forcibly retracted back out of the kernel by the kernel team to restore order?

Huh. It will be interesting to see how this plays out. Working with device driver developers is a bit like herding cats under the best of circumstances. How will they respond to demands that they rewrite all of their drivers to kdbus? I've had trouble in the past just getting in touch with some of them (as the email address in the source code turned stale).

He didn't mention the fourth option: (d) port new must-have device drivers to netlink for eudev.

No, herding cats is saying it lightly. It's more like herding mice in a warehouse full of cheese.

1 members found this post helpful.

There, I fixed that for you.

4 members found this post helpful.

Likewise I have great respect for Slackware. It is a good thing that only a small minority of users (in all distributions) are elitist and do not want other distro users joining in discussions.

As far as I'm concerned, having a full-featured DE allows me to run Linux on my workstation to be productive, not Windows or Mac OS X. Running irssi in a Ratpoison session just won't do it.

I doubt many, if any, of the "elitists" object to people joining discussions about their distribution, if those people have used the distribution in the past, and are therefore familiar with it, and are able to contribute to the discussion. What they most likely object to are people disrupting discussions with assumptions about a distribution they are ignorant of. In other words, the reaction is based on whether people are trying to be constructive or destructive to the discussion.

In the interest of making an on-topic contribution; my belief is, if Slackware adopts systemd there would be a small lose of users, but not an exodus. Most would continue using Slack.