# kdbus in the kernel

## gwr

I'm trying to learn about the technical reasons for kdbus and I have a few noob-type questions that maybe someone here can help me with.

I have gone all the way back in time to this blog posting:

http://blogs.gnome.org/rodrigo/2012/02/27/d-bus-optimizations/

It seems like the two main candidates (shared mem and multicast IPC were ignored because of the amount of work involved, not due to technical reasons:

"was a (maybe) good idea, as it would mean peers in the bus would use shared memory segments to send messages to each other. But this would mean mostly a rewrite of most of the current D-Bus code"

"but this seems to be too much overhead for the D-Bus"

The only slightly technical item I read was:

"as we would have to use eth0 or similar, as multicast on loopback device doesn’t exist (hence no D-Bus in computers without a network card). Also, losing packets is another caveat of this solution, as well as message order guarantee"

But wouldn't this whole thing have been easier if someone added multicast to the loopback? Is there a technical reason why that couldn't have been done rather that shoving an entirely new bus into the kernel?

Thanks!

----------

## Anon-E-moose

PATCH v2 00/13 http://lkml.iu.edu/hypermail/linux/kernel/1411.2/index.html search on kdbus

No comments from the kernel devs yet on version #2.

Edit to add: just saw some comments, and they still haven't got it clean enough (code wise) to get an ack on getting any further than they are now.

But it's interesting to watch.

----------

## Anon-E-moose

http://lkml.iu.edu/hypermail/linux/kernel/1411.2/04920.html

All your kdbus are belong to us!   :Laughing: 

And some of these "devs" wonder why Linus discouraged them from thinking that they could ever be kernel devs.

Edit to add: Security, clean well understood functions, good design are not just bolt-ons "to be done later" in revision #whatever

They are intrinsic to the whole.

----------

## gwr

Thnks for the links, they help a lot. I am no security expert, but is the claim that the only trustworthy component in the system in the kernel sensible? How does the kernel know who to trust?Last edited by gwr on Mon Nov 24, 2014 11:36 am; edited 1 time in total

----------

## truekaiser

 *gwr wrote:*   

> Thnks for the links, they help a lot. I am no security expert, but is the claim thst the only trustworthy component in the system in the kernel sensible? How does the kernel know who to trust?

 

This is where gentoo has it's strength.

Don't like the that kernel component? Don't select it and it won't compile.

It's what i do with SElinux. I just can't trust it due it's CIA backing.

----------

## steveL

 *gwr wrote:*   

> Thnks for the links, they help a lot. I am no security expert, but is the claim that the only trustworthy component in the system in the kernel sensible? How does the kernel know who to trust?

 

Not really. In any event it's just hand-waving to give a pretext, that hopefully no-one will argue with, mainly because anyone who knows it's rubbish is likely already against kdbus, and can't be bothered to get involved with the argument. Anyone who's not sure is a target of the propaganda campaign, and this is just part of the generalised FUD.

In this case, uncertainty leads to doubt of who's right, and (explicitly-invoked) fear that without kdbus, one is leaving one's system open to abuse. OFC the possibility of not having any sort of dbus at a system-wide level (as it's reimplementing the kernel) is never entertained.

The hand-waving aspect is the conflation of trustworthy (with connotations of trustworthy computing) with file-system permissions and intrusion-detection systems. kdbus has absolutely nothing to do with that discussion.

----------

## Anon-E-moose

And the battle continues   :Laughing: 

Fortunately Andy L isn't letting them put whatever they want into the kdbus code, they're having to justify much of it.

Edit to add: I get the impression that the sysd people thought that they could waltz in 

and shove slightly modified dbus code into the kernel, warts and all. 

Glad to see they're being called on their assumption.

----------

## ct85711

The real show is after they get the initial code in the kernel, on if they'll be able to add to their frame work.

----------

## The Doctor

 *ct85711 wrote:*   

> The real show is after they get the initial code in the kernel, on if they'll be able to add to their frame work.

 

No, the real show is when the kernel devs refuse patches that break things "just because."

----------

## asturm

 *Anon-E-moose wrote:*   

> And the battle continues  
> 
> Fortunately Andy L isn't letting them put whatever they want into the kdbus code, they're having to justify much of it.

 

It's quite amusing, but well, isn't that what review is for?

kdbus gets beaten until it is in shape, I'm sure it won't make it into the kernel anywhere near 3.19, 3.20.

----------

## Anon-E-moose

 *The Doctor wrote:*   

>  *ct85711 wrote:*   The real show is after they get the initial code in the kernel, on if they'll be able to add to their frame work. 
> 
> No, the real show is when the kernel devs refuse patches that break things "just because."

 

++

----------

## steveL

It's a shame the kernel devs can't really question the use-case for all this. As imo the whole kdbus thing should never even get into the kernel, and wouldn't if kernel folks were looking at the whole picture, including userland application from the top down.

ATM it's somehow "been accepted" that "RPC" is a valid thing to be doing in a local-machine context.

For the avoidance of doubt: it's not. It's completely insane, and is part of what makes me feel we've gone through the looking-glass.

It would be much more honest and to the point, to talk about an ORB which is basically what dcop was about. Incidentally dcop was a much better solution, and already easily-scriptable for humans.

Instead of saying "dbus does everything dcop does, let's use it," the position should have been "dcop does everything we need, and is much cleaner, let's use it, and maybe extend it."

I had no position on the above when it happened; I loved dcop in KDE-3.5.x and was mighty disappointed when Kommander/Kaptain (can't remember which it was) was not present in 4.x. I assumed that "since dbus is a superset of dcop" it would soon arrive, but it never did through the whole of KDE-4. Which just told me at least, that dbus is inferior.

A quick perusal of the uses of dbus, as opposed to how dcop was put together, merely confirmed that a much-less capable design-team were in charge (and loving being in charge).

----------

## Anon-E-moose

An interesting post from Richard Yao  

Starts off with:

 *Quote:*   

> I had the opportunity at LinuxCon Europe to chat with Greg and some other kdbus
> 
> developers. A few things stood out from our conversation that I thought I would
> 
> bring to the list for discussion.
> ...

 

And near the end:

 *Quote:*   

> I should probably mention one other thing that I recall from my discussion with
> 
> Greg and others, which is that the systemd project wants to depend on it. The
> 
> nature of controlling pid 1 means that systemd is more than capable of starting
> ...

 

http://lkml.iu.edu/hypermail/linux/kernel/1411.3/04542.html

The more I read about kdbus and "the need for it" the more it looks like it's really not needed.

They just want to throw some crap in the kernel and when it blows up they will want to point

fingers at the kernel instead of their crap code. My opinion.

----------

## steveL

Heh nice to see a substantive answer to the quite reasonable overview points raised.. or it would be.

Usual hand-waving implying a lack of effort on the part of the person raising the concerns, all the while making zero effort to provide a summary of the reasons why this has to be in-kernel (when we all know it doesn't require anything of the sort.) Nice to see that solid a grasp of the mess he's pushing.

If it comes down to it, I'd rather trust ryao, and his description of the discussion he had in-person with Greg-KH, which gels with everything else we heard before the propaganda campaign for this stage of the putsch started. He's done excellent work on ZFSonLinux, amongst other things, where he's actually gone in and grokked the codebase, and solved real problems at the design level.

----------

## Anon-E-moose

What a dumbass reply from GKH. 

I'm hoping that it's going to be even harder than before for them to get kdbus into the kernel.

Especially with responses like GKH's and the "oh we'll fix it later" mindset.

I'm pretty sure Linus is watching these things going on and has his own views on it.

Right now, they aren't even getting past the prelim kernel show and tell.

----------

## steveL

Well I went back to the original link gwr gave, and I agree it's a bit hand-wavey:

 *Rodrigo Moya wrote:*   

> Shared memory: this has no proof-of-concept code to look at, but was a (maybe) good idea, as it would mean peers in the bus would use shared memory segments to send messages to each other. But this would mean mostly a rewrite of most of the current D-Bus code, so maybe an option for the future, but not for the short term.

  which again indicates to me that a slightly different API to mqueues (which have indeed been implemented using shared-memory, since the 1990s, though idk what Linux does) would be much more broadly useful.

Rereading the linked thread from last comment was good, as that's the one talked about where "the networking guys rejected [earlier attempts]". Many of those objections still apply:

 *David Miller wrote:*   

> My first impression is that I'm amazed at how much complicated new code you have to add..
> 
> I can't see how this is better than doing multicast over ipv4 using UDP or something like that, code which we have already and has been tested for decades.
> 
> I really don't want to apply this stuff, it looks bloated, complicated, and there is another avenue for doing what you want to do.
> ...

 

The ballooning memory requirements were first raised here:  *David Lamparter wrote:*   

> This sounds like a terribly nice way to f*ck the entire D-Bus system by having one broken (or malicious) desktop application. What's the intended way of coping with users that block the socket by not reading?

  to which we get a pretty lame response:  *Javier Martinez Canillas wrote:*   

> this problem exists with current D-bus implementation. If a malicious desktop application doesn't read its socket then the messages sent to it will be buffered in the daemon:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=33606
> 
> dbus-daemon memory usage will balloon until max_incoming_bytes/max_outgoing_bytes limit is reached (1GB for session bus in default configuration)..
> ...

  Note this latter problem still applies when bringing kdbus into the kernel, and further that despite the excellent analysis on that bug, not one step has been taken to address the fundamental design flaw; the last comment from a known hal/udev/systemd developer with any content is from January 2011, and indicates serious miscomprehension issues, as he witters on about uid.

It's perfectly simple: stop pretending you can provide a square triangle. Firstly address the issue sanely at protocol-level (by process, and personally I'd simply kill anything that didn't conform or spammed, and disconnect slow readers.) Secondly address the fundamental problem of why on earth you're shoving megabytes of data down it in the first place. As noted here  *Martin Mares wrote:*   

> I completely agree with Alan that if routing all messages through DBUS daemon is a bottleneck, then something is seriously wrong with the way the applications use the message bus.
> 
> Also, you mentioned the need of passing fd's between applications. If I understand correctly, it is a rare case and if you handle such messages in the same way as before, it won't hurt performance.
> 
> 

 

Miller outlines the same design flaw I keep going on about, wrt single-purpose app:

 *David Miller wrote:*   

>  *Luiz von Dentz wrote:*   Like I said before there is many projects using AF_UNIX as IPC transport, the documentation actually induces people to use for this purpose, and many would benefit from being able to do multicast. 
> 
> You can't have it both ways.
> 
> If it's useful for many applications, then many applications would benefit from a userland library that solved the problem using existing facilities.
> ...

 

And after all this, it turns out that there's already a satisfactory protocol in place: TIPC which is already in kernel, and allows for clustered usage as well, in a form I'd much rather trust than any turd coming from the hal/udev/dbug/systemdiots.

If we were trying to broaden, then we might look at PGM which is supported by 0mq. But I don't think we are.

Another option in the desktop session area, after we've split out systray and DM-DE privileged ops like shutdown and hibernate, is to simply fork the X server, since apparently there's a dbus-like protocol already included as part of X. Clearly the X server is plenty fast enough at multiplexing (look: no threads!) for graphics, so maybe it'd be simple enough just to have it handling this. In another process so that it doesn't interfere with the rest of what's happening. IDK enough about it yet, so any info appreciated.

ATM TIPC looks like a clear winner.

 *Erik Hugne wrote:*   

> One problem is that TIPC does not support passing FD's between processes (SCM_RIGHTS anc. data). But adding support for this in TIPC should have a relatively small code footprint.

  is relatively easy; we just use a different channel for those, since as noted above they're rare in any case. That also helps separate control from data, which is essential ime, at the application-level.

Protocol spec here.

----------

## Anon-E-moose

I went chasing back through one of the links from SteveL's last post and ran across this (pertinent IMO) post from Alan Cox

 *Quote:*   

> > 2- The transport layer used by D-bus is not performance sensitive
> 
> > basically due:
> 
> > 
> ...

 

The biggest problem with dbus (and sysd and other things that LP has "designed") is poor design, 

ie not designed at all, just things thrown at it as they are perceived to be needed.

The fact that they don't want to redesign it properly is no reason to take the half-assed dbus code and add it to the kernel.

It would still be half-assed code and if they still need speed up then what are they going to do?

----------

## steveL

I'm just amazed at how suitable the protocol they were advised to use is:

 *Ying Xue wrote:*   

> TIPC can both support two modes: single node mode and network mode. If we hope all applications can easily to talk each other locally, let TIPC just work under single node mode. [the default]
> 
> It can guarantee multicast messages are reliably delivered in order
> 
> It can support one-to-many and many-to-many real-time communication within node or network.
> ...

 

Note the provenance:  *ticp website wrote:*   

> The Transparent Inter-Process Communication protocol allows applications in a clustered computer environment to communicate quickly and reliably with other applications, regardless of their location within the cluster.
> 
> TIPC originated at the telecommunications manufacturer, Ericsson, and has been deployed in their products for years. The open source TIPC project was started in 2000 when Ericsson released a Linux version of TIPC on SourceForge.
> 
> A project Working Group was created in 2004 to oversee the project and direct the evolution of the TIPC protocol.

 

No doubt "I believe the central D-Bus daemon is not necessary any more," is why it wasn't pursued. ;)

But that is exactly the right solution, whatever underlying mechanism/s we use. Let the kernel multiplex, as that's what it's for.

If you must mux in userland, do it like the X11 server does, and limit the processing to domain-specific data.

 *TIPC spec wrote:*   

> These assumptions[1] allow TIPC to use a simple, traffic-driven, fixed-size sliding window protocol located at the signalling link level, rather than a timer-driven transport level protocol. This in turn leads to other benefits, such as earlier release of transmission buffers, earlier packet loss detection and retransmission, earlier detection of node unavailability, to mention but some.
> 
> Of course, situations with long transfer delays, high loss rates, long messages, security issues, etc. must also be dealt with, but from the viewpoint of being exceptions rather than as the general rule.

 

The mcast part is interesting (remember this is just a data channel, not a control one):

 *Quote:*   

> MCAST_MSG messages are also subject to name table lookups before the final destinations can be determined.
> 
> A first lookup is performed, unconditionally, on the sending node. Here, all node local matching destination ports are identified, and a copy of the message is sent to each and one of them.
> 
> N/A  At the same time, the lookup identifies if there are any publications from external, cluster local, nodes. If so, a copy of the message is sent via the broadcast link to all nodes in the cluster.
> ...

 

I'd rather drop connections, but haven't read deep enough yet, to understand how we'd deal with the exceptional situations; hopefully we can get notifications of overloaded ports/processes. (I'd be surprised if not.)

 *Quote:*   

> Process Overload Protection
> 
>  TIPC must maintain a counter for each process, or if this is impossible, for each port, keeping track of the total number of pending, unhandled payload messages on that process or port. When this counter reaches a critical value, which should be configurable, TIPC must selectively reject new incoming messages.
> 
> Which messages to reject should be based on the same criteria as for the node overload protection mechanism, but all thresholds must be set significantly lower. Empirically a ratio 2:1 between the node global thresholds and the port local thresholds has been working well.
> ...

 

In any event, the less drastic model is just to do what they're doing, so I'm happy to go with their wealth of experience ;)

The exceptional cases are nonetheless where we might add policy knobs, like banning a uid, or mandating that certain channels must be kept up with, or the reader will be dropped (and must reconnect.) And as stated, we'd have a control channel for fd passing, and perhaps system-level state-notifications (though we might want RT signals for some things.)

[1]Assumptions (all applicable to localnode, or simply not an issue):

 *Quote:*   

> TIPC has been designed based on the following assumptions, empirically known to be valid within most clusters.
> 
> Most messages cross only one direct hop.
> 
> Transfer time for most messages is short.
> ...

 

IP checksumming is already carried out by network hw, and I'd hope that's either taken care of in the existing kernel impl, or simply not used for internal-node comms. Either way it's (hopefully) SEP. ;)

----------

## depontius

 *steveL wrote:*   

> 
> 
> No doubt "I believe the central D-Bus daemon is not necessary any more," is why it wasn't pursued. 
> 
> 

 

Makes one wonder how hard it would be to write an alternative libdbus on top of TIPC.

The trick with shims, and the reason that they might be a good idea,

1 - Build clean implementations of what systemd is trying to do, with cleam APIs.

2 - Build shims to allow "corrupted userspace" to run on those clean solutions.

3 - Demonstrate improvement by going to the clean API instead of the shim.

This way the shim becomes a weaning path instead of legitimizing.

----------

## steveL

 *depontius wrote:*   

>  *steveL wrote:*   
> 
> No doubt "I believe the central D-Bus daemon is not necessary any more," is why it wasn't pursued. ;)
> 
>  
> ...

 

No: you're still legitimizing the whole practice of leech-RPC, which I want nothing to do with, for one. I see it as threatening the very ecosystem on a much more fundamental level: by making the GPL irrelevant (which is further pushed via "modern" projects pretending that BSD-2/MIT is cool, because it allows companies to rip us off by selling us back our own work, proprietarised.)

I'd much rather go back to dcop for the desktop; you simply don't need to worry if you're not shoving mega-blobs of data around, but only control metadata, which is application data as far as the kernel and userspace plumbing are concerned (not control.) There were already examples of people scripting "apps" in modern phone-parlance, which was totally killed by the move to dbus in KDE-4.x.

But I do find TIPC exciting, as it's such a clean and mature IPC impl, already in the kernel for over a decade. No doubt Ericsson use it for erlang nodes; either way it's just what's needed, if we were going to implement a dbus: but why not just keep them app-specific, much like a named socket or a fifo. Essentially we already have a "libdbus" and a kdbus, which are proven.

What would be cool is an easyipc lib that allowed the admin to configure what mechanisms are used for what, in the local application domain (a bit like /etc/services). Not sure how necessary it is, but it'd be fun. :-)

----------

## truekaiser

 *depontius wrote:*   

>  *steveL wrote:*   
> 
> No doubt "I believe the central D-Bus daemon is not necessary any more," is why it wasn't pursued. 
> 
>  
> ...

 

I was thinking the same thing. Why not build a shim on top of it so users of dbus can painlessly migrate to the better system?

Well until LP and associates change the api's just to break the competitor. Yet that would also shoot down any chances of dbus ending up in the kernel.

----------

## saellaven

Again, if you're going to advocate shims, then what you're saying is that systemd is doing the right things, just is implemented wrong... the implementation sucks but the design (or lack thereof) is totally wrong as well. Further, don't be surprised when they become totally hostile to your shims because their intent is to break as much as possible so you have to use their unified CoreOS to get things to work.

Anyone remember how long it took for WINE to become usable on a majority of applications? Anyone want to go count how many apps still don't work right with WINE at all? That is what shims would replicate, only it would be native software that is either outright broken or broken in subtle ways and always subject to playing catchup, only for something else to be intentionally broken again after that.

----------

## truekaiser

 *saellaven wrote:*   

> Again, if you're going to advocate shims, then what you're saying is that systemd is doing the right things, just is implemented wrong... the implementation sucks but the design (or lack thereof) is totally wrong as well. Further, don't be surprised when they become totally hostile to your shims because their intent is to break as much as possible so you have to use their unified CoreOS to get things to work.
> 
> Anyone remember how long it took for WINE to become usable on a majority of applications? Anyone want to go count how many apps still don't work right with WINE at all? That is what shims would replicate, only it would be native software that is either outright broken or broken in subtle ways and always subject to playing catchup, only for something else to be intentionally broken again after that.

 

Wrong or not, the fact remains they are winning. Which means OUR tactics must change.

If debain decided to drop systemD than the situation would be different, sadly it is now ALL the mainline distributions running it.

Using a shim allows us to be on a equal playing field WHILE we develop a better alternative.

An updated Init system that learns from the past and leverages it rather than saying 'it's old so it's broken so lets completely throw it out' like systemD (openrc fits this imho)

An alternative to *kits so users who are not interested in becoming developers can have stuff automagically work. I'm fine with having to manually mount stuff, I don't want to have to try to teach my mother how to use a console to mount that usb drive of hers for it's pictures.(to use a simple example.)

A non professional level audio mixing system other than Pulseaudio to handle muxing and per application volumes. IE something other than jack.

And on, And on. etc.

----------

## saellaven

 *truekaiser wrote:*   

>  *saellaven wrote:*   Again, if you're going to advocate shims, then what you're saying is that systemd is doing the right things, just is implemented wrong... the implementation sucks but the design (or lack thereof) is totally wrong as well. Further, don't be surprised when they become totally hostile to your shims because their intent is to break as much as possible so you have to use their unified CoreOS to get things to work.
> 
> Anyone remember how long it took for WINE to become usable on a majority of applications? Anyone want to go count how many apps still don't work right with WINE at all? That is what shims would replicate, only it would be native software that is either outright broken or broken in subtle ways and always subject to playing catchup, only for something else to be intentionally broken again after that. 
> 
> Wrong or not, the fact remains they are winning. Which means OUR tactics must change.
> ...

 

They are winning because you just concede the ground to them.

OpenRC already IS the better alternative.

If you want to play their game with shims, be prepared to be known for shoddy, buggy software, meaning you won't have the credibility to replace them because you'll always be second best. If the other mainline distributions want to drive over a cliff, you aren't obligated to follow and if you just want to follow, why not use one of the soon-to-be RH clone distros like debian?

 *Quote:*   

> 
> 
> An alternative to *kits so users who are not interested in becoming developers can have stuff automagically work. I'm fine with having to manually mount stuff, I don't want to have to try to teach my mother how to use a console to mount that usb drive of hers for it's pictures.(to use a simple example.)

 

Pretty much already exists... I've been using Linux since 1994 and the only thing I ever needed special permissions for was mounting (and that is easily fixed too), just simply add users to the appropriate groups (like audio) automatically/by default on account creation. For systems more complex than grandma at home, which is fine with grandma in the audio group, someone SHOULD know what they are doing or else there is going to be a lot of available attack surface exposed.

 *Quote:*   

> 
> 
> A non professional level audio mixing system other than Pulseaudio to handle muxing and per application volumes. IE something other than jack.

 

ALSA does mixing natively and there have been plenty of audio demons (esd, arts, etc) in the past that have done it too. It wouldn't be too terribly hard to create a library or demon for handling per application volume adjustments.

----------

## truekaiser

 *saellaven wrote:*   

> 
> 
> They are winning because you just concede the ground to them.
> 
> OpenRC already IS the better alternative.
> ...

 

They seem to have gotten this far without people using shims. And windows has not gained from the loss of linux from the shim / emulator that is wine.

I also agree open-rc is a better alternative, but i can't deny the fact that the LP idiots are winning. If we are going to at least survive this split between linus-linux and LP-linux we must adapt.

Shim's will be temporary stepping stones to allow us to come out with a better system without making it easy for the LP crew to demonize us to their customers for being too 'old'

 *Quote:*   

> 
> 
> Pretty much already exists... I've been using Linux since 1994 and the only thing I ever needed special permissions for was mounting (and that is easily fixed too), just simply add users to the appropriate groups (like audio) automatically/by default on account creation. For systems more complex than grandma at home, which is fine with grandma in the audio group, someone SHOULD know what they are doing or else there is going to be a lot of available attack surface exposed.
> 
> 

 

Like what? Edev? few distributions offer it and even GENTOO doesn't push it as default and THEY are the ones that made it. Even then it is based off an older version of udev that still has some critical bugs that were fixed in later versions. Those later versions are not yet hard coded to need systemD so there is no need to use it.

To be clear once udev does get hard code linked i will be switching to eudev. This flexibility is why i stay with gentoo.

And what about fast user switching? Accessibility? All i have seen are hacks that require technical knowledge past the targeted user-base. While in contrast those poorly made and non documented *kits seem to work 'automaticly' with the big desktops from an end user perspective.

You can't just declare 'that program has no 'real' use and is poorly made' without providing an alternative that fulfills those metrics with the same ease of use. That includes cases in which you are right! Which is the case with the *kit's software and all of LP's work while he runs them.

 *Quote:*   

> 
> 
> A non professional level audio mixing system other than Pulseaudio to handle muxing and per application volumes. IE something other than jack.

 

ALSA does mixing natively and there have been plenty of audio demons (esd, arts, etc) in the past that have done it too. It wouldn't be too terribly hard to create a library or demon for handling per application volume adjustments.[/quote]

esd is dead

arts has been dead for several years.

While i agree alsa does a great job of mixing on it's own, for the majority of users that involves knowing alsa specific syntax and editing text files. Sadly well beyond the target user base in which Pulseaudio as sadly taken dominance.

Oh and if you want to support Steam in bringing games to linux you pretty much have to run pulse-audio.

----------

## depontius

 *saellaven wrote:*   

> 
> 
> They are winning because you just concede the ground to them.
> 
> OpenRC already IS the better alternative.
> ...

 

I believe they're "winning" because the Linux ecosystem has been flooded with former Windows developers and users, bringing their Windows sensibilities with them.  The old-time Linux developer and user base is so small that you don't need that many people coming from Windows to become the new majority.  As part of that, these new people are also early adopters, notoriously prone to be fanbois.

I also believe "winning" may be largely a misnomer, because it has occurred in noise-space - AKA forums and such.  I had previously felt that most of the backlash wouldn't start until systemd hit the real world - or the real world hit systemd, which might be a more appropriate way of putting it.  But something new has happened as we watch kdbus try to get into the kernel.  First feedback looked more like implementation issues, but as it goes, it gets more architectural.  We've also now seen the Debian fork.

I suspect what is really happening is that the "silent majority" of the Linux userbase is awakening - the ones who just want to user their computers, want them to work reliably, have already reject Windows, and don't go on a forum until they have a problem.

As for shims, the unfortunately reality is that systemd has hijacked a lot of developement.  I'm happy enough to write off GNOME, and call it software suicide.  I don't use KDE, but I'd rather not see them sail off on the same ship.  Originally there were many things I didn't like about Wayland, but I've mellowed my opinion.  I'd like to not see the whole development ship sail off into systemd-land without a way back, once they get a dose of sanity.  The purpose shims is two-fold.  Most important, it gives those projects a way back, away from systemd.  More conveniently, it lets us say modern where appropriate or desirable, instead of degenerating into codger-space.

I have a similar story.  I used to use Wirth-family languages, which have pretty much withered away.  Once upon a time I was on the Oberon2 newsgroup, asking how I could manipulate legacy binary data with Oberon2.  I've done so fairly extensively with both Pascal and Modula2, both extended versions.  The response on the Oberon2 newsgroup was that I should forget legacy binary data, and get everyone on my projects to migrate to Oberon2, then the problem would go away.  With that response, I went away, and so did Oberon2.

When in a minority situation, there is always a need to work with the majority, if only to maintain one's own way of working.  If systemd becomes the disaster we all think it will, we need to help people get back.

----------

## saellaven

 *truekaiser wrote:*   

>  *saellaven wrote:*   
> 
> They are winning because you just concede the ground to them.
> 
> OpenRC already IS the better alternative.
> ...

 

WINE will never have parity with Windows... just a simple fact as Windows is always a moving target. systemd is the same situation.

 *Quote:*   

> 
> 
> I also agree open-rc is a better alternative, but i can't deny the fact that the LP idiots are winning. If we are going to at least survive this split between linus-linux and LP-linux we must adapt.
> 
> Shim's will be temporary stepping stones to allow us to come out with a better system without making it easy for the LP crew to demonize us to their customers for being too 'old'

 

Temporary shims will become permanent shims if we cede the ground to them... and I have no doubt that many of these shims will become tomorrow's security nightmares.

 *Quote:*   

> 
> 
>  *Quote:*   
> 
> Pretty much already exists... I've been using Linux since 1994 and the only thing I ever needed special permissions for was mounting (and that is easily fixed too), just simply add users to the appropriate groups (like audio) automatically/by default on account creation. For systems more complex than grandma at home, which is fine with grandma in the audio group, someone SHOULD know what they are doing or else there is going to be a lot of available attack surface exposed.
> ...

 

Most of it can be done by simply letting the console user have access to everything... grandma isn't likely to be sshing into her box and someone that is NEEDS to know what they are doing.

 *Quote:*   

> 
> 
> And what about fast user switching? Accessibility? All i have seen are hacks that require technical knowledge past the targeted user-base. While in contrast those poorly made and non documented *kits seem to work 'automaticly' with the big desktops from an end user perspective.

 

Does grandma need fast user switching? What's wrong with the existing system of logout/switch user? When did GUI accessibility suddenly require an init system given it's already been available for nearly 20 years? Again, you're ceding the ground that their ideas are right.

 *Quote:*   

> 
> 
> You can't just declare 'that program has no 'real' use and is poorly made' without providing an alternative that fulfills those metrics with the same ease of use. That includes cases in which you are right! Which is the case with the *kit's software and all of LP's work while he runs them.

 

and again, you're trying to back-justify what they want using their logic... it's a solution in search of a problem.

 *Quote:*   

> 
> 
>  *Quote:*   
> 
>  *Quote:*   
> ...

 

and yet, I use steam without pulse or systemd without any problems...

I used esd and arts as examples of the fact that this functionality has existed for long before LP decided to start mucking up the system... lets not pretend he's some revolutionary here to fix things. He's a hack at best, he just happened to get hired at a place where he gets to force his vision onto the world.Last edited by saellaven on Mon Dec 01, 2014 9:50 pm; edited 1 time in total

----------

## saellaven

 *depontius wrote:*   

> 
> 
> I believe they're "winning" because the Linux ecosystem has been flooded with former Windows developers and users, bringing their Windows sensibilities with them.  The old-time Linux developer and user base is so small that you don't need that many people coming from Windows to become the new majority.  As part of that, these new people are also early adopters, notoriously prone to be fanbois.

 

They are "winning" because they're operating out of the largest single player in the Linux development ecosystem... RedHat. If they didn't have RH's backing, nobody would take them seriously... and it's through RH's upstream ownership of other projects like GNOME that they are forcing people to acquiesce.

 *Quote:*   

> 
> 
> I suspect what is really happening is that the "silent majority" of the Linux userbase is awakening - the ones who just want to user their computers, want them to work reliably, have already reject Windows, and don't go on a forum until they have a problem.

 

I again reiterate my story that I didn't care one whit about systemd until WilliamH abused his power to intentionally cripple the systems of people NOT using systemd because of systemd's shortsighted and arrogant self-imposed technical limitations. Break your system all you want and I don't care, but break my system and I have a problem.

 *Quote:*   

> 
> 
> As for shims, the unfortunately reality is that systemd has hijacked a lot of developement.  I'm happy enough to write off GNOME, and call it software suicide.  I don't use KDE, but I'd rather not see them sail off on the same ship.  Originally there were many things I didn't like about Wayland, but I've mellowed my opinion.  I'd like to not see the whole development ship sail off into systemd-land without a way back, once they get a dose of sanity.  The purpose shims is two-fold.  Most important, it gives those projects a way back, away from systemd.  More conveniently, it lets us say modern where appropriate or desirable, instead of degenerating into codger-space.

 

So, we'll compromise what actually works in the hopes that people will come back to what works when they irrevocably bork things... only to find that the shims and everything else are completely borked themselves, leaving us a giant pile of rubbish. I'd rather abandon evolutionary paths that don't work out.

 *Quote:*   

> 
> 
> When in a minority situation, there is always a need to work with the majority, if only to maintain one's own way of working.  If systemd becomes the disaster we all think it will, we need to help people get back.

 

then why ever develop Linux in the first place? If the goal isn't to make the best software, but to kludge things up to emulate the worst software, why bother at all?

----------

## truekaiser

 *saellaven wrote:*   

> 
> 
> and yet, I use steam without pulse or systemd without any problems...
> 
> 

 

And i think i can dismiss you right here.

While steam has no hard coded links to SystemD or pulse. Without the pulseaudio application or it's shim you will get no sound in any of the games. They are coded to either use pulse directly or only to use sdl's pulse output.

Sound is a critical component when playing video games so you are either using a shim or the application itself. You have stated you do not like shims but not that you were using one.

I on the other did state i have to use pulse(because i like sound in my games) even though i hate using it.

Because i was forced to use it i realized that despite how crap the code is, it provides something that nothing else does.

Those previous sound servers never worked out of the box, each app had to be set up to use it.

Alsa's dmix works but you have to edit text config files and know where to place them before that happens.

Pulseaudio worked, right out of the box, to use that phrase. And it has continued to work, despite a few hiccups on fringe applications, rather well despite how badly coded it is.

Do i want a better coded alternative? Yes, but it also has to be drop in compatible.

You think it's faulty logic to say to not use something without providing an alternative you can use? I realize it's as dumb as going up to someone and doing.

"hey don't use windows, it's crap software. written poorly and a security nightmare!"

They are going to ask what would you suggest, and if you have nothing then they will dismiss you.

----------

## saellaven

 *truekaiser wrote:*   

>  *saellaven wrote:*   
> 
> and yet, I use steam without pulse or systemd without any problems...
> 
>  
> ...

 

Pulse is masked on my system (and I have a USE=-pulseadudio plus apulse is not installed) and yet I get sound in every game I've played on steam. I'd like to see you substantiate this claim that I'm using pulseaudio...

Because i was forced to use it i realized that despite how crap the code is, it provides something that nothing else does.

 *Quote:*   

> 
> 
> Those previous sound servers never worked out of the box, each app had to be set up to use it.

 

each app had to be set up to use it just like each app has to be set up to use pulse... OR they could just work off the base sound system's mixer as has been available for more than a decade.

 *Quote:*   

> 
> 
> Alsa's dmix works but you have to edit text config files and know where to place them before that happens.

 

yet mine worked without any editing...

 *Quote:*   

> 
> 
> Pulseaudio worked, right out of the box, to use that phrase. And it has continued to work, despite a few hiccups on fringe applications, rather well despite how badly coded it is.

 

that despite the thousands of complaints about pulseaudio being broken out of the box and only recently becoming better if you don't count stuttering and other problems it causes... oh, and all pulseaudio really is, is a front end right back to ALSA... it, itself, is a crappy shim... you know, the very thing you're advocating more of.

 *Quote:*   

> 
> 
> Do i want a better coded alternative? Yes, but it also has to be drop in compatible.
> 
> You think it's faulty logic to say to not use something without providing an alternative you can use? I realize it's as dumb as going up to someone and doing.

 

The alternatives already exist... stop buying into the propaganda

 *Quote:*   

> 
> 
> "hey don't use windows, it's crap software. written poorly and a security nightmare!"
> 
> They are going to ask what would you suggest, and if you have nothing then they will dismiss you.

 

at one point, I could suggest Linux... Linux with systemd is going to make Windows look secure. Mark my words.

----------

## KuroNeko

I don't like programs, that work without configuration. That's not the same, as if the software works out of the box.

If it brings a configuration file, that works out of the box, that is ok. But if for whatever reason my system is missing a configuration file, I don't want that program to stamp over my whole system! I have a reason to provide my configuration and without stating my preferences, how should my system know about it?

Autoexing my USB sticks, when I plug them in? Oh, boy, we had that already!

Let the user change the network? Fine by me, as long as it isn't a machine, I want to have accessible from the internet all the time!

Distributions do a fine job of preconfiguring things, and if the resulting system doesn't work for you, you can always switch or build your own.

But it is not feasible to code the whole userspace yourself, because every program does only one thing, but does it wrong (in your opinion).

That's excatly, what some systemd followers get wrong.

Even if systemd does one thing and does it right, it can be wrong on my system. Adding one case after another will never work in every case. Providing easy configuration on the other side, can make that possible, altough it is harder on some users. (But that's, why we have distros)

Also it is amazing, how well some things work, that are told to be the worst piece of software and are in dire need of a replacement.

ALSA, X11, sysvinit (with custom rcs), you name it. They all mostly work, but some edge cases (audio over bluetooth, badly coded deamons die, when you try hard enough, without you noticing) aren't that nice. So you just replace it with a completly different software, that handles everything, but breaks your setup, because you do nothing or don't want to use it, as you don't need it.

I didn't try it, but dcop sounds awesome, for how it was. Script your desktop? Yes please!

I could even understand, that you would like to push some commands to a terminal (konsole) or to a text editor like kate, so they user can look over it, and decide what to do. That would be awesome for learning and customizing!

Could you do that with dcop? I found a few examples, where it had been done, but I didn't use KDE at that time, sadly...

Can you do that with dbus? Maybe? I have a hard time figuring out, how to handle dbus on the commandline. Where is KDCOP or whatever you would call it, and why isn't it actively promoted?

But why would I need extra low latency and high bandwith? Even if I have thousand apps open at the same time, that shouldn't be an issue!

And if I use a container? Well that could be an issue, but I have no need for it myself. I think I can trust my software, that I either compiled myself or get from a repo. If I can't, I have a much bigger issue...

And on servers, why not use TIPC? That sounds like a sound solution!

Sorry for the rant, but I don't need software, that thinks it is smarter than me, because maybe it's right, but it will never teach me and that's just unfair!   :Smile: 

Neko

----------

## Anon-E-moose

Interesting commentary from Richard Yao again http://lkml.iu.edu/hypermail/linux/kernel/1412.0/01208.html

 *Quote:*   

> I had hoped that I could avoid reading through the code for yet another
> 
> IPC mechanism when I asked why we needed kdbus at LinuxCon Europe. In
> 
> hindsight, I should have just checked out the code and read it instead
> ...

 

 *Quote:*   

> That said, it is still not clear to me that dbus must be inside the
> 
> kernel to be able to perform multicast and zero copy using memfd. Is
> 
> there something that I have missed that make this not the case?

 

Seems there are a few kernel devs that just aren't sold on the whole

dbus in the kernel is necessary brouhaha. 

This is from a previous post in this thread.

 *Quote:*   

> >> P.S. I also mentioned my concern that having the shim in the systemd repository
> 
> >> would have a negative effect on distributons that use alterntaive libc libraries
> 
> >> because the systemd developers refuse to support alternative libc libraries. I
> ...

 

and a previous post

 *Quote:*   

> >> told quite plainly that such distributions are not worth consideration. If kdbus
> 
> >> is merged despite concerns about security and backward compatibility, could we
> 
> >> at least have the shim moved to libc netural place, like Linus' tree?
> ...

 

I'm thinking that what I bolded is what the sysd/dbus/kdbus cabal really wants.

----------

## depontius

 *Anon-E-moose wrote:*   

> Interesting commentary from Richard Yao again http://lkml.iu.edu/hypermail/linux/kernel/1412.0/01208.html
> 
> 

 

I found this thread on this morning's LKML scan - the whole thing was good reading.  What I like is that now serious architecture as well as implementation questions are being asked by kernel devs - people of much greater weight than forum-watchers.

----------

## Anon-E-moose

 *depontius wrote:*   

>  *Anon-E-moose wrote:*   Interesting commentary from Richard Yao again http://lkml.iu.edu/hypermail/linux/kernel/1412.0/01208.html
> 
>  
> 
> I found this thread on this morning's LKML scan - the whole thing was good reading.  What I like is that now serious architecture as well as implementation questions are being asked by kernel devs - people of much greater weight than forum-watchers.

 

Especially since many times the answers by kdbus devs to questions by kernel devs has been "quick put it in the kernel, we'll worry about implementation and fixing it later"

----------

## depontius

 *Anon-E-moose wrote:*   

>  *depontius wrote:*    *Anon-E-moose wrote:*   Interesting commentary from Richard Yao again http://lkml.iu.edu/hypermail/linux/kernel/1412.0/01208.html
> 
>  
> 
> I found this thread on this morning's LKML scan - the whole thing was good reading.  What I like is that now serious architecture as well as implementation questions are being asked by kernel devs - people of much greater weight than forum-watchers. 
> ...

 

It's also good to see that while that answer is good enough for Phoronix, it's not good enough for kernel devs.

----------

## steveL

 *saellaven wrote:*   

> Again, if you're going to advocate shims, then what you're saying is that systemd is doing the right things, just is implemented wrong... the implementation sucks but the design (or lack thereof) is totally wrong as well. Further, don't be surprised when they become totally hostile to your shims because their intent is to break as much as possible so you have to use their unified CoreOS to get things to work.
> 
> Anyone remember how long it took for WINE to become usable on a majority of applications? Anyone want to go count how many apps still don't work right with WINE at all? That is what shims would replicate, only it would be native software that is either outright broken or broken in subtle ways and always subject to playing catchup, only for something else to be intentionally broken again after that.

 

 *truekaiser wrote:*   

> Wrong or not, the fact remains they are winning. Which means OUR tactics must change.

 

No it does not. They're fighting a propaganda campaign: by all means take them on in that arena if you want.

That does not change any of the technical facts. And I'd point out that on that front, you've completely ignored the issue of how many human hours would be wasted on what saellaven described above: playing catch-up with a sh1tty design none of us wants to code on, because it is so braindead, against a hostile upstream which much like M$ will be doing everything it can to break interoperability.

Those decisions will be propagandised as "looking after the user" when we all know the intent is the opposite: to dumb us down and feed us crap "entertainment" we have to pay for, despite the fact that we as a Community designed, coded, debugged and continue to maintain the underlying software infrastructure.

It's exactly the same battle as in the 80s and 90s, it's just changed venue.

 *Quote:*   

> Using a shim allows us to be on a equal playing field WHILE we develop a better alternative.

 

No it doesn't: it cripples us before we've even begun our generation's contribution to the collective commons.

 *Quote:*   

> An updated Init system that learns from the past and leverages it rather than saying 'it's old so it's broken so lets completely throw it out' like systemD (openrc fits this imho)

 

So that's done, and can only improve over time, providing we keep our wits about us.

 *Quote:*   

> An alternative to *kits so users who are not interested in becoming developers can have stuff automagically work. I'm fine with having to manually mount stuff, I don't want to have to try to teach my mother how to use a console to mount that usb drive of hers for it's pictures.(to use a simple example.)

 

Yeah this has all been done, for many of us already. Unless you were expecting your mother to handle a Gentoo install?

 *Quote:*   

> A non professional level audio mixing system other than Pulseaudio to handle muxing and per application volumes. IE something other than jack.

 

Nah, sorry. You will never convince me that we should base the next-gen desktop on anything other than jack for audio. 

The only reason pro-audio programmers haven't addressed the "let me wander around with my bluetooth headset and automagically hear whatever is playing on the nearest device" use-case is that pro-audio users typically have zero interest in that.

They were happy to work on it with Poeterring, but he simply showed no inclination to listen to a bloody word, and his whole approach was woefully amateur from the beginning. You can't take someone like that seriously.

He got a knockback from pro-audio, same as he got a knockback from kernel folks when he first tried to be a kernel-dev.

edit: link to example of "braindead" design.Last edited by steveL on Tue Dec 02, 2014 6:34 pm; edited 1 time in total

----------

## steveL

 *KuroNeko wrote:*   

> I didn't try it, but dcop sounds awesome, for how it was. Script your desktop? Yes please!
> 
> I could even understand, that you would like to push some commands to a terminal (konsole) or to a text editor like kate, so they user can look over it, and decide what to do. That would be awesome for learning and customizing!
> 
> Could you do that with dcop? I found a few examples, where it had been done, but I didn't use KDE at that time, sadly...
> ...

 

When 4.x was being conceived, everyone wanted to collaborate across-desktops. So KDE agreed to use dbus, and forget about dcop.

It's a shame really, as dcop had been in-place since KDE-2 (if you know KDE, two series is a long time) and was much nicer.

For instance you had kommander which enabled quick and efficient scripting, which was a step up from kaptain (Qt based) to make nice user-interfaces.

Thanks for querying this; I had a bookmark for kaptain, but had deleted stuff about kommander. As you'll see the docs for the latter are rather threadbare (no tutorial examples.) The ALSA MIDI Kommander (which I just found) is a nice use-case.

So officially it's "dead" technology, and no doubt sneered at by dbus-fanbois. But it was so much more useful; as the last url shows, people actually used it to "applify" their desktop under their own control. I've not seen anything like the same sort of end-user adoption with dbus.

It rocked, and I was sorely disappointed when nothing similar appeared on 4.x, as I'd only discovered kommander during 3.5.x (which was a sweet spot, much like 4.10 without semantic-craptop.)

 *Quote:*   

> But why would I need extra low latency and high bandwith? Even if I have thousand apps open at the same time, that shouldn't be an issue!

 

Because nub-skool "designers" think it's a good idea to shove megablobs of data around the wrong bus. They're trying to enforce One True IPC so no-one will notice that LGPL-GPL combination in so many "dbus-only" 'services'.

 *Quote:*   

> And on servers, why not use TIPC? That sounds like a sound solution!

 

Well, why not use it everywhere, assuming you actually need pub/sub semantics.

Going back to TIPC, I missed out the description of sub-addressing earlier:

 *Ying Xue wrote:*   

> The basic unit of functional addressing within TIPC is the port name, which is typically denoted as {type,instance}. A port name consists of a 32-bit type field and a 32-bit instance field, both of which are chosen by the application.
> 
> Often, the type field indicates the class of service provided by the port, while the instance field can be used as a sub-class indicator. Further support for service partitioning is provided by an address type called port name sequence.
> 
> This is a three-integer structure defining a range of port names, i.e., a name type plus the lower and upper boundary of the instance range. This addressing schema is very useful for multicast communication.
> ...

 

So I guess you would want to provide a minimal lib that does the client side, along with a daemon ORB (assuming it were in fact necessary to optimise userland dcop.)

 *Quote:*   

> If you use this schema, a central daemon is not necessary. Any application can directly talk to any other: one-to-one, one-to-many, and many-to-many.

 

----------

## KuroNeko

Thanks for the links, SteveL!

That's sounds a lot, like some things, that I feel, are missing on my desktop sometimes.

Quickly hacking together a gui for a command line application or connecting a few application in e.g. krunner. Why isn't that possible on dbus?   :Sad: 

Also a question: Letting every application spawn their own bus/IPC interface/whatever sounds good (if there are simple to use libs), but how would you know, if you're really talking to the program, you think, you are talking to?

Maybe you could solve that with a setgid bit? Then every trusted application would run in the message group, or similiar.

Scanning for available services would be a simple lookup of all applications running as the current user and in the message group.

A central daemon really isn't needed there anymore.

I hope, I'm not missing something...

----------

## Anon-E-moose

 *Quote:*   

> Allow me to be more specific:
> 
> > - performance: fewer process context switches, fewer copies, fewer
> 
> > syscalls, larger memory chunks via memfd. This is really important
> ...

 

They need kdbus because they expect "hundreds of thousands of messages passed at boot time"

That's fricking insane, along with a hellaciously exaggerated lie I would hope.

If they're going to push stupid arguments like the above then I would hope that kdbus never gets into the kernel.

Good question from R Yao though, "Are any of them examples of good software design"

We know that anything connected with the LP cabal doesn't have a clue about software design good or bad.

http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02144.html

 *Quote:*   

> > - being in the kernle closes a lot of races which can't be fixed with
> 
> > the current userspace solutions. For example, with kdbus, there is a
> 
> > way a client can disconnect from a bus, but do so only if no further
> ...

 

I'm at a loss as to how kdbus would improve on dbus in this supposed race generating condition. 

I bet that Richard will pretty much say the same thing.

 *Quote:*   

> > Of course, some of the bits above could be implemented in userspace
> 
> > alone, for example with more sophisticated memory management APIs, but
> 
> > this is usually done by losing out on the other details. For example,
> ...

 

Again, lets take code that supposedly would need clients to trust each other in a dbus implementation

and let them not trust each other in kdbus. WTF?

 *Quote:*   

> > Another benefit of having this in the kernel, rather than as a userspace
> 
> > daemon, is that you can now easily use the bus from the initrd, or up to
> 
> > the very end when the system shuts down. On current userspace D-Bus,
> ...

 

A darned good question. 

WHY does one need dbus to start in an initramfs, BEFORE THE USER CAN EVEN LOG IN and any user programs are started?

If this is the best justification that people like GKH and the LP cabal can come up with then we really don't need kdbus.

They need to go back and design dbus and do it right.

----------

## depontius

 *Anon-E-moose wrote:*   

> 
> 
>  *Quote:*   > Another benefit of having this in the kernel, rather than as a userspace
> 
> > daemon, is that you can now easily use the bus from the initrd, or up to
> ...

 

Come on, you know the answer to that.  They've even as much as said that they want to completely wrap the kernel.  I believe the words were, "systemd writes to the kernel, and everyone else writes to systemd".  Getting into the initrd is simply another step upstream, and readily goes along with getting kdbus into the kernel.

Here's the interesting question...  At what point will they pursue getting the userspace dbus daemon into the initrd?  I suspect that right now all efforts are at getting into the kernel, and they won't easily accept defeat.  But clearly getting anything into the initrd would have been another "logical" step for them.

Now for a funny conspiracy theory...

I suspect that pretty much everyone here is comfortable on the command line.  I know I pretty much use my GUI as a way to push xterms around and manage my display space,as well as run GUI apps, which I'll admit that I prefer.  (I don't use a tiling WM because I like to use window overlap to my advantage.)

Let's pretend that "the crowd" moving from Windows to Linux have a deep-seated inferiority complex, because they're not comfortable with the command line.  Perhaps this is the reason they push dbus so hard - it's an attempt to render the command line obsolete.  Take those old-school greybeard "experts" and turn them into dinosaurs.

But you know, what's a command line, what's a shell?  It's basically the simplest way to take user input and translate it into a command to the computer.  With dbus it's simply a different way of specifying command and parameters, and I might add that the parameters are certainly more verbose, so I'd hate to type all of that crap in on any command line.  But let's say someone came out with a bunch of executables that did nothing with a command line, perhaps exited with a "Meant to be called using dbus!" error message.  It would be no big problem to build a "dbus command wrapper" that would take its command line and turn it into dbus messages.  Take the generic wrapper and symlink it to specific command names, rather like busybox does.  At the simplest level, it would need a configuration file to tell it how to build dbus messages for each type of command line.  Perhaps more complex, but more general, I believe the "introspection" capability could be used to do that stuff automagically, with a truly generic wrapper.  At that point we're most of the way to a "dbus shell" - perhaps it could be tacked into .bashrc or something like that, and then our systems run the way we like again, even after the dbus crowd has its way.

----------

## Anon-E-moose

Even though I use windows (occasionally) I still have a cmd (dos shell) icon on the desktop for ease of use.   :Laughing: 

----------

## Naib

 *Anon-E-moose wrote:*   

> Even though I use windows (occasionally) I still have a cmd (dos shell) icon on the desktop for ease of use.  

 at least install msysgit to get UNIX coreutils & sh/bash

----------

## steveL

 *depontius wrote:*   

> But you know, what's a command line, what's a shell?  It's basically the simplest way to take user input and translate it into a command to the computer.  With dbus it's simply a different way of specifying command and parameters, and I might add that the parameters are certainly more verbose, so I'd hate to type all of that crap in on any command line.  But let's say someone came out with a bunch of executables that did nothing with a command line, perhaps exited with a "Meant to be called using dbus!" error message.  It would be no big problem to build a "dbus command wrapper" that would take its command line and turn it into dbus messages.  Take the generic wrapper and symlink it to specific command names, rather like busybox does.  At the simplest level, it would need a configuration file to tell it how to build dbus messages for each type of command line.  Perhaps more complex, but more general, I believe the "introspection" capability could be used to do that stuff automagically, with a truly generic wrapper.  At that point we're most of the way to a "dbus shell" - perhaps it could be tacked into .bashrc or something like that, and then our systems run the way we like again, even after the dbus crowd has its way.

 

Ugh that is horrible. You really need to let go of the idea that we can "all just get along."

You cannot "get along" with someone who is trying to intimidate and control you. You can submit, fight or walk away.

I choose to walk away, as it's less noise and less wasted time. The latter is more and more important to me, the older I get.

----------

## depontius

 *steveL wrote:*   

>  *depontius wrote:*   But you know, what's a command line, what's a shell?  It's basically the simplest way to take user input and translate it into a command to the computer.  With dbus it's simply a different way of specifying command and parameters, and I might add that the parameters are certainly more verbose, so I'd hate to type all of that crap in on any command line.  But let's say someone came out with a bunch of executables that did nothing with a command line, perhaps exited with a "Meant to be called using dbus!" error message.  It would be no big problem to build a "dbus command wrapper" that would take its command line and turn it into dbus messages.  Take the generic wrapper and symlink it to specific command names, rather like busybox does.  At the simplest level, it would need a configuration file to tell it how to build dbus messages for each type of command line.  Perhaps more complex, but more general, I believe the "introspection" capability could be used to do that stuff automagically, with a truly generic wrapper.  At that point we're most of the way to a "dbus shell" - perhaps it could be tacked into .bashrc or something like that, and then our systems run the way we like again, even after the dbus crowd has its way. 
> 
> Ugh that is horrible. You really need to let go of the idea that we can "all just get along."
> 
> You cannot "get along" with someone who is trying to intimidate and control you. You can submit, fight or walk away.
> ...

 

Sorry I wasn't clear, you mistake my meaning.  This was a worst-case theoretical argument, not a practical suggestion.

I'm just saying that even if systemd completely "won" and managed to wipe out the classical command line from every single upstream project, replacing it all with some sort of dbus-based GUI, we could still get a command line back.

The command line is a philosophy, not a specific implementation.  Philosophically, the command line is the least distance between me and invoking a computer program to do work for me.

----------

## steveL

 *KuroNeko wrote:*   

> That's sounds a lot, like some things, that I feel, are missing on my desktop sometimes.
> 
> Quickly hacking together a gui for a command line application or connecting a few application in e.g. krunner. Why isn't that possible on dbus?  :(

 

Because it's a crappy replacement for dcop, that is nowhere near as nice to code nor script against.

 *Quote:*   

> Also a question: Letting every application spawn their own bus/IPC interface/whatever sounds good (if there are simple to use libs), but how would you know, if you're really talking to the program, you think, you are talking to?

 

Either you started it up (in which case you know its pid) or it's running as a service on a known port, in most cases. If we're talking about pub/sub of just about anything, then I think we should look at some sort of easyipc lib, with configuration.

 *Quote:*   

> Maybe you could solve that with a setgid bit? Then every trusted application would run in the message group, or similiar.
> 
> Scanning for available services would be a simple lookup of all applications running as the current user and in the message group.
> 
> A central daemon really isn't needed there anymore.

 

A central deamon isn't needed now: the basis of the permission system is the (mount) namespace. The kernel does the permission handling so we don't have to.

I'm not quite clear what problem you're trying to solve above. I agree groups can be useful, but I'd need a more specific case to have any idea what you're really getting at. One-size-fits-all solutions don't.

The beauty of having an ecosystem is that you have various ways of thinking cooperating; the thing to understand is that there are several mechanisms in POSIX, eg for IPC. Each are tuned for different scenarios, and trying to shove them all through one bottleneck is simply stupid.

Eg dbus keeps going on about not losing messages: POSIX supplies that semantic for message queues. However you simply don't need that for most cases (and as we've seen it's inappropriate at protocol level for general data), and again, trying to munge all the different types of communication into one, is exactly what led to the current snafu. Instead of stepping back and rethinking the design, they plow on with stubborn idiocy, and they've now made it about face. They clearly feel they would lose face if they admitted any flaws, which is fatal if you're a programmer.

It's simply blinkered thinking, which is what you get from inexperienced people. Especially the ones who think they don't need to do their research before blanket-declaring everything they can't get their heads around as useless.

----------

## steveL

 *depontius wrote:*   

> Sorry I wasn't clear, you mistake my meaning.  This was a worst-case theoretical argument, not a practical suggestion.

 

Well that was a lot of text, so it seemed important to you.

 *Quote:*   

> I'm just saying that even if systemd completely "won" and managed to wipe out the classical command line from every single upstream project, replacing it all with some sort of dbus-based GUI, we could still get a command line back.

 

I'd rather use that as an opportunity to pre-filter out the crap; call it self-selective evolution ;) however..

 *Quote:*   

> The command line is a philosophy, not a specific implementation.  Philosophically, the command line is the least distance between me and invoking a computer program to do work for me.

 

systemd is never going to get rid of invoking a program with exec*, which is the basis for the thinking behind the command-line and most particularly having a Unix-style shell.

The latter means C programs don't have to worry about splitting and globbing, in particular, which they do on Windoze (unless you're using a ported shell.)

I understand your point that you could theoretically wrap dbus idiocy. But to my mind, if you've got to that point, you've lost your machine already. It's no longer yours, nor is it one I'd have any interest in using.

My interest is in getting rid of dbus altogether. I'm fine with the GUI I had in 1999; the most I'd want is to be able to plug in a usb-stick or device, and that's not exactly a problem.

----------

## sitquietly

 *steveL wrote:*   

> .....You really need to let go of the idea that we can "all just get along."  You cannot "get along" with someone who is trying to intimidate and control you. You can submit, fight or walk away.
> 
> I choose to walk away...

 

I do too.  I know something about how control can be imposed.  I worked for a company that obtained a contract to build systems for the U.S. Air Force.  That became a significant proportion of our revenue, as military and nsa contracts are now a significant proportion of the revenue for Red Hat.  We didn't even realize, certainly I didn't realize, how much control the Air Force had gained over us by virtue of a contracted system that is "vital to the national interest."  Our system was in fact important to the security of several military bases, but it was probably not as vital as Red Hat systems that run our entire nuclear submarine force.

The Air Force exercised their right to take direct control of the management of our company -- if you falter on the schedule or attaining the goals of such a military contract they have the right to assume direct control over your company.  I ended up with an Air Force lieutenant occupying the office beside my workspace, I had to pass a security clearance, and the Air Force gained the right to direct not only our management decisions but also our engineering decisions. 

I had designed a very capable embedded controller. I had built it as an unapproved skunkworks project, working with a fellow engineer in my home development lab, and then produced my working system in a high level meeting with the consultant who was being paid huge sums to build this "Entry Control Unit".  It was impossible to dismiss my design since it was siting on the table working!  It had lots of analog and digital i/o, timers, monitored voltages to detect attempts to tamper with the external circuits, and a really sweet private RS-485 network that I designed with a distributed database that enabled continuation of secure operations even in face of loss of the host communications.  All in mere kilobytes of EPROM.  The documentation was the best I've ever written and the system was my proudest work.

I liked it!   :Cool:    So did the Air Force.    :Evil or Very Mad: 

The Air Force needed a large number of "Entry Control Units" for their massive systems and mine, though designed by me for the commercial product that I was in charge of getting to market, was grabbed for their use.  

I had done the Unix-thing and used plain ascii for the command language and an extensible protocol, i.e. a dictionary and a command interpreter.  It was easy to understand, efficient, and extensible.  Lets say, to stretch my point, that it was like Linux was before Red Hat and Poettering.  The Air Force would have none of that.  Their edict was that the data and commands must be kept in an unreadable binary format, just like Red Hat has for some reason started forcing on the Linux system logs.  They hired their own consultant to obfuscate my code -- yes they actually said that they wanted to make the code harder to understand.  For some months I worked in a locked steel Faraday cage assisting in the transformation of my system into a properly binary and obfuscated mess for the Air Force.

My point is not really about my particular experience or whether I liked or disliked the Air Force's redesign of my system.  It is that Red Hat is known to be dominated by American military and security agencies -- their main income is from military contracts and a Chairman of the Joint Chiefs of Staff became the Chairman of the Board of Red Hat.  I know from my experience that Red Hat products (e.g. kdbus, systemd) _could_ be directly engineered by those national agencies.  

We are entering a period in which the heart of Linux is re-engineered by Red Hat.  I don't trust that re-engineering to produce the system that I want to use or work on.  

Gentoo seems to be one of the best cultures in which to bring along the best engineering of systems that follow The Linux Philosophy.  I sure hope that we can continue to make it possible to run a Gentoo linux system as a large set of simple tools...which can be connected with well specified interfaces...which are usually textual data streams.

Thanks to every Gentoo developer who makes it possible for me to run a very capable hardened workstation with 

USE="-avahi -consolekit -dbus -gnome -policykit -pulseaudio -systemd"

----------

## Navar

 *Anon-E-moose wrote:*   

> If this is the best justification that people like GKH and the LP cabal can come up with then we really don't need kdbus.
> 
> They need to go back and design dbus and do it right.

 

While I stepped away from Linux (and *nix in general) pre-Gnome/RHEL emergence days, it seems they've wanted this for quite some time, almost a decade.

I wasn't a fan of working with CORBA quite awhile ago but, this was interesting, from a performance aspect.  Personally, it would have caused me to avoid dcop/dbus from the get go.

----------

## Anon-E-moose

Here's a fun read, it's about dbus, but makes one ponder the "need" for kdbus.

http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt

From the end of the blog

 *Quote:*   

> While this exercise has been quite educational in many ways I am surprised that this undocumented early-alpha quality code base is used for anything serious. Many concepts are either not defined, or defined by the behaviour of the implementation. The APIs are ad-hoc without any obvious structure, partially redundant (what's the difference between Terminate and Kill ?), and not documented in a way that allows a reimplementation.
> 
> If this is the future I'll stay firmly stuck in the past ... 

 

And they want to push their alpha level (at best) undesigned code into the kernel.   :Rolling Eyes: 

----------

## tld

 *Anon-E-moose wrote:*   

> Here's a fun read, it's about dbus, but makes one ponder the "need" for kdbus.
> 
> http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt
> 
> 

 Oh...my...f*****g God.  That's one of the most painful things I've ever read.  It actually makes any Windows technical scavenger hunt I've ever dealt with look almost elegant.

I recall reading elsewhere that, in spite of being out there in the field, for example in RHEL7 (as in E for Enterprise), the DBUS API definition itself if documented as being "beta"...which essentially means you can't communicate with it in a way that isn't guaranteed not to break in the future.  I guess that's how they "get off the hook" when the break your shit later on.

That really is an amazing read...no words.

----------

## tld

You know, those folks really do remind me of some of the supposedly "black belt" Windows coders I've worked with over the years.  A great deal of what I recall really starts to make sense now.  There seems to be a mindset that nothing that is simple can ever possibly be good enough...and that any such thing must be immediately obscured behind enough layers of ill/un-documented abstraction so as to never be understood by anyone, ever again, without brute force reverse engineering.  What's more, it's a mindset that seems to be inherited directly from MS themselves.  Is it just me??Last edited by tld on Sun Dec 07, 2014 2:52 pm; edited 1 time in total

----------

## khayyam

 *Anon-E-moose wrote:*   

> From the end of the blog
> 
>  *Quote:*   While this exercise has been quite educational in many ways I am surprised that this undocumented early-alpha quality code base is used for anything serious. Many concepts are either not defined, or defined by the behaviour of the implementation. The APIs are ad-hoc without any obvious structure, partially redundant (what's the difference between Terminate and Kill ?), and not documented in a way that allows a reimplementation. If this is the future I'll stay firmly stuck in the past ...  

 

Anon ... all of that can be explained with two little words (or one neologism if you so like): "dbus-haters".

best ... khay

----------

## Anon-E-moose

 *khayyam wrote:*   

> Anon ... all of that can be explained with two little words (or one neologism if you so like): "dbus-haters".
> 
> best ... khay

 

 :Laughing:  LoL  :Laughing: 

Note: I don't even have dbus emerged, and have found no pkgs (on my system) that won't work without it

----------

## NeddySeagoon

tld,

Its the CYA mentality.  You don't understand my code so you can't fire me.

----------

## Anon-E-moose

What's sad about it is that a programmer, looking at nearly a decade old code (in current usage) has that hard a time figuring out what is going on.

And the same mindset that gave us hal, dbus, etc is giving us The next generation headache™ and people think this is a "good thing" *shakes head in amazement"

----------

## Anon-E-moose

 *NeddySeagoon wrote:*   

> tld,
> 
> Its the CYA mentality.  You don't understand my code so you can't fire me.

 

I'm not sure if it's that or simply that they are amateur programmers with no understanding of proper design.

I suppose one could argue either way.   :Very Happy: 

----------

## steveL

 *steveL wrote:*   

> You really need to let go of the idea that we can "all just get along."  You cannot "get along" with someone who is trying to intimidate and control you. You can submit, fight or walk away.
> 
> I choose to walk away, as it's less noise and less wasted time.

 

 *sitquietly wrote:*   

> I do too.  I know something about how control can be imposed.

 

Thanks for an excellent post, sitquietly. I'm splitting it to keep focus on this part: (emphasis added)

 *Quote:*   

> The Air Force exercised their right to take direct control of the management of our company -- if you falter on the schedule or attaining the goals of such a military contract they have the right to assume direct control over your company.

 

That makes it a bad idea, in business-terms, to do any business with them, afaic. You'd simply have no recourse, and if that were a company you'd built up over years, it'd be a real killer.

OFC if you've only built it up with the hope of selling it on, as every VC does, then that's not an issue. It would just kill the craft of what you're doing, as you experienced.

 *Quote:*   

> I worked for a company that obtained a contract to build systems for the U.S. Air Force.  That became a significant proportion of our revenue, as military and NSA contracts are now a significant proportion of the revenue for Red Hat.  We didn't even realize, certainly I didn't realize, how much control the Air Force had gained over us by virtue of a contracted system that is "vital to the national interest."

 

Yeah Red-Hat are light-years away from the company they were in the early 90s (the kudos they've been trading on wrt the community, ever since.)

 *Quote:*   

> Our system was in fact important to the security of several military bases, but it was probably not as vital as Red Hat systems that run our entire nuclear submarine force.
> 
> I ended up with an Air Force lieutenant occupying the office beside my workspace, I had to pass a security clearance, and the Air Force gained the right to direct not only our management decisions but also our engineering decisions.
> 
> I had designed a very capable embedded controller.. All in mere kilobytes of EPROM.  The documentation was the best I've ever written and the system was my proudest work.

 

Oh man, gutted. I love the "kilobytes of EPROM" part :-)

 *Quote:*   

> I had done the Unix-thing and used plain ascii for the command language and an extensible protocol, i.e. a dictionary and a command interpreter.  It was easy to understand, efficient, and extensible.  Lets say, to stretch my point, that it was like Linux was before Red Hat and Poettering.  The Air Force would have none of that.  Their edict was that the data and commands must be kept in an unreadable binary format, just like Red Hat has for some reason started forcing on the Linux system logs.

 

The sad part is how stupid all that is. The issue was addressed in the round years ago, with encrypted filesystems.

 *Quote:*   

> They hired their own consultant to obfuscate my code -- yes they actually said that they wanted to make the code harder to understand.  For some months I worked in a locked steel Faraday cage assisting in the transformation of my system into a properly binary and obfuscated mess for the Air Force.
> 
> My point is not really about my particular experience or whether I liked or disliked the Air Force's redesign of my system.  It is that Red Hat is known to be dominated by American military and security agencies -- their main income is from military contracts and a Chairman of the Joint Chiefs of Staff became the Chairman of the Board of Red Hat.
> 
> I know from my experience that Red Hat products (e.g. kdbus, systemd) _could_ be directly engineered by those national agencies.

 

And the one thing we know from history, is that if people think they can gain an advantage by doing something, even if they are wrong and trying to fix a gas-pipe with a scalpel, then they will do it. As you described above with your project, they are under the delusion that security-by-obscurity which does indeed have some place in human situations (eg if you don't know where something material is, it is harder to steal it, since you cannot remove it, by definition) also applies to digital tech, which by definition is duplicated the instant it is entered, and is free to reproduce, or transmission would not function.

 *Quote:*   

> We are entering a period in which the heart of Linux is re-engineered by Red Hat.  I don't trust that re-engineering to produce the system that I want to use or work on.

 

Me neither. It worries me that now we'll have to keep a healthy dose of scepticism for every kernel update. It used to be the case that we could rely on the transparent focus on the craft, as the soul of how Linux operates.

Looking forward 10 years and more, what happens when Torvalds retires or dies? There are several people in the kernel-world who follow his methodology, but equally there are plenty of shills who are only in it for the payout. Real coders don't care about marketing, they care about code sometimes to the exclusion of all else, so many of the influential people, especially in the wider Linux monde, are the public-faces of the kleptocrats, afaic. "Interesting times" ahead, for those who live long enough.

 *Quote:*   

> Gentoo seems to be one of the best cultures in which to bring along the best engineering of systems that follow The Linux Philosophy.  I sure hope that we can continue to make it possible to run a Gentoo linux system as a large set of simple tools...which can be connected with well specified interfaces...which are usually textual data streams.

 

Thanks for that link: it was truly excellent, and good to see that reiteration of a commitment to the UNIX philosophy, at the heart of Linux, when it was starting out.

We need to get back to that ground, and refuse to leave it.

----------

## steveL

 *Anon-E-moose wrote:*   

> Here's a fun read, it's about dbus, but makes one ponder the "need" for kdbus.
> 
> http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt

 

 *tld wrote:*   

> That's one of the most painful things I've ever read.  It actually makes any Windows technical scavenger hunt I've ever dealt with look almost elegant.

 

This bit is hilarious:

 *Quote:*   

> D-Bus is low-overhead because it uses a binary protocol.. the protocol is ASCII-only. The value of any string is .. encoded in UTF-8

 

As we've seen (thanks Navar) dbus is nothing like low-overhead, by comparison to the "dead" technologies it supplanted.

 *Quote:*   

> I recall reading elsewhere that, in spite of being out there in the field, for example in RHEL7 (as in E for Enterprise), the DBUS API definition itself if documented as being "beta"...which essentially means you can't communicate with it in a way that isn't guaranteed not to break in the future.  I guess that's how they "get off the hook" when the break your shit later on.

 

Yeah, though that doesn't stop Poeterring mislabelling it a "standard", and tub-thumping about how everyone else has to "get on board". Real standards require more than one implementation of something new, before they even consider standardising it (usually so that everyone can cooperate across variant impls.)

And ofc in other areas, he'll quite openly advocate breaking ABI and not ever worrying about the consumer, in the name of "innovation", when to every one else it looks like he just doesn't know how. There are indeed variant ABIs in dbus (equivalent to soname: eg some.long.crap.systemd1) so the technical point about how relabelling it IPC is both stupid and misleading, still stands.

The guy's an amateur, afaic. I wouldn't trust him with a pair of scissors.

This just makes me grin:  *Quote:*   

> Creating/closing sessions is exclusively the job of PAM

  as I've been advocating just using PAM, and ditching nubkit, for quite a while. 

Typically I've been told polickysh1t is supposed to make PAM redundant for those poor users who simply can't get their head round a config (not like it's needed for the vast majority in any case: that's what a distro is for.) Not to mention requiring an embedded js interpreter to get the same effect, instead.

I'm glad though, as this means that we're not going to get any "but systemd only needs polkit" crap down the road.

I'd class that as a "Quiet Change" in standardisation-speek. ;)

----------

## steveL

 *Anon-E-moose wrote:*   

> If this is the best justification that people like GKH and the LP cabal can come up with then we really don't need kdbus.
> 
> They need to go back and design dbus and do it right.

 

 *Navar wrote:*   

> While I stepped away from Linux (and *nix in general) pre-Gnome/RHEL emergence days, it seems they've wanted this for quite some time, almost a decade.

 

Yeah, IPC has been all the rage since the early 90s (when much of the interesting work has already been done.) I couldn't find any info on NML from chasing that url, though I love the RTAPI stuff.

Did you take a look at the TIPC links before?

 *Quote:*   

> I wasn't a fan of working with CORBA quite awhile ago but, this was interesting, from a performance aspect.  Personally, it would have caused me to avoid dcop/dbus from the get go.

 

Yeah CORBA was a beast back then. Thanks for the paper, it was interesting. dcop was already 6 times faster than dbus, but it could easily have used the orb methodology for optimisation. Though I agree you might as well just use the C orb and build up from there.

And if you're going to pub/sub, use TIPC.

----------

## Anon-E-moose

Another nice post from Patrick from a year earlier than the last one 

http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt

Funny comment

 *Quote:*   

>  *Quote:*   Then, one of the most complex bits of the whole thing, which is the
> 
> remarshalling service that translates old dbus1 messages to kdbus
> 
> GVariant marshalling and back is a systemd socket
> ...

 

And in conclusion

 *Quote:*   

>  *Quote:*   I just hope you guys do it knowing what's at stake here. 
> 
> Yes, that's why some of us are so antagonistic. Propaganda much?
> 
> So, to summarize: No one else can implement what systemd does, and thus you must use it. It is so brilliant that you shouldn't even try!
> ...

 

----------

## Navar

 *steveL wrote:*   

> Did you take a look at the TIPC links before?

 

No, sadly I had not heard of it (or simply don't remember in the zillion other kernel options).  So thanks for that.  I did burn some of my dinner in the process of getting lost scanning through the spec today.   :Razz:   :Laughing: 

I guess a bigger question would be what on the Linux user space side is making use of TIPC?

----------

## Navar

 *Anon-E-moose wrote:*   

>  *Quote:*   So, to summarize: No one else can implement what systemd does, and thus you must use it. It is so brilliant that you shouldn't even try!
> 
> Just reading this propaganda is making me unhappy, with that level of dishonesty and misdirection I don't see how we can have a nice discussion. Most of the arguments are either circular ("No one can write logind without writing logind") or false ("Cgroups are at the center of what a server does").
> 
> At the same time everyone who disagrees is a luddite ... or illiterate ... or whatever. Anyway, YOUR UGLY, so I win discussion! or something something. 

 

Yep.  The simplest response I've seen is simply refering to us who won't drink their kool-aid as 'haters'.  Like every other political/internet/etc. diatribe in that vein, it de-evolves into hyperbolic comparisons, the I win button, and supposedly good theater.  Embarass away your (peer) opposition, argument over.  I'm even almost fine with that sort of asshatery until there are pretend (no olive branch) attempts to emo-'understand' why there's backlash (aka, playing the victim card).  Sometimes they're not even pretending--which just re-iterates anyone stating issues was talking to a wall.  Don't break the user experience, don't forget the user, and try to make the user actually look forward to any features/fixes/changes you're doing; versus forcing that, fundamentally.  I used to enjoy seeing new OSs and DE paradigms who were showing how they could improve my experience and workflow (including eye candy aesthetics), rather than make it awkward for their version of style.

An answer to that has always been quiet shunning, ignoring and a major movement away from their forced way.  I don't know how you achieve that from devs and users when it's a popularity contest that they'd already held the crown in.  It can happen on its own when negative things blow up on the prior two groups--something we're expecting and semi-hopeful for.  Although I consider the process painful either way particularly with respect to security and (dev)user experience who ultimately lose time instead of enjoyably progressing.

----------

## Anon-E-moose

From  todays News and Announcements

[ GLSA 201412-12 ] D-Bus: Multiple Vulnerabilities  https://forums.gentoo.org/viewtopic.php?p=7666718#7666718

Thank Gawd that we aren't trying to introduce such shoddy code into the kernel.    :Laughing: 

----------

## krinn

wonder how many vulnerabilities you need to swap a "multiple vulnerabilities" into a "shitload of vulnerabilities" status  :Smile: 

----------

## NeddySeagoon

I can just see the argument now ... dbus is insecure, we must have kbus now!

----------

## tld

 *Anon-E-moose wrote:*   

> From  todays News and Announcements
> 
> [ GLSA 201412-12 ] D-Bus: Multiple Vulnerabilities  https://forums.gentoo.org/viewtopic.php?p=7666718#7666718
> 
> Thank Gawd that we aren't trying to introduce such shoddy code into the kernel.   

 Holy crap...check out that list of references!  Maybe someone can explain something to me regarding the entries in the vulnerabilities database...is that "Original release date" when the vulnerability was actually reported???  If so, it looks like the oldest one goes back to the beginning of July!

It's almost as though, in order to counter the arguments that folks like myself have been making...that systemd will introduce Windows-like reboot frequency to Linux...they've decided to "save them up" to make things look better.  Sounds like a plan to me...to replace weekly reboots with an approach that leaves you're servers vulnerable for five months.  FFS...I actually hope I'm misinterpreting that.  If (God forbid) I was an IT guy supporting RHEL7 I'd go through the fucking roof at that announcement.

Just wow...

EDIT:  Yea...I know that's DBUS and not systemd...all from the same brilliant minds though... :Wink: .  Actually, looking at the original bugs I think a lot of them were actually resolved some time ago.  In any case, why would anyone want this sort of crap code in their init system, especially in a server.

----------

## ct85711

It would be interesting to see all the security issues that is currently open on systemd.  I wouldn't be surprised if there's quite a few open, but not released to the public while they wait for RH to eventually fix it.  (Assuming the security reports are not published, till a patch has been made.  I don't know on how that system works, to know if there's a deadline for the times the dev's just ignore the issue.)

----------

## depontius

 *tld wrote:*   

> Holy crap...check out that list of references!

 

About half of the bugs in that list look like plain old bugs, and about half look like poorly thought-out implementation details.

But with the first bug, the "defined behavior" is at fault.

----------

## mrsteven

 *tld wrote:*   

> It's almost as though, in order to counter the arguments that folks like myself have been making...that systemd will introduce Windows-like reboot frequency to Linux...they've decided to "save them up" to make things look better.

 

I always thought they already have some sort of official reasoning about that. Something like: "Yes, you will have to reboot a little bit more often, but thanks to systemd this will be so freaking fast that you should not care about that." However, the idea of having a freedesktop patchday also seems to be... interesting...  :Rolling Eyes: 

----------

## ct85711

How could a patch day sound good?  As it's going to be like M$, of only releasing patching once a quarter (unless it is a major issue).

----------

## depontius

 *ct85711 wrote:*   

> How could a patch day sound good?  As it's going to be like M$, of only releasing patching once a quarter (unless it is a major issue).

 

We use RedHat at work, and I've been hearing about "patch Thursdays", though I haven't really seen it that way yet.

But then again, that would just feed the conspiracy theory side of things.

----------

## ct85711

The reason I started using linux so long ago, was because I was tired of having to wait for a dang update to eventually come when some company feels like they want to release one.  If linux changes to become like that; I'll switch to some other OS.

----------

## MustrumR

 *ct85711 wrote:*   

> The reason I started using linux so long ago, was because I was tired of having to wait for a dang update to eventually come when some company feels like they want to release one.  If linux changes to become like that; I'll switch to some other OS.

 

With linux you still have to wait for Linus Torvalds or Greg Kroah-Hartman to release an update (unless you decide to use a non-released version).

----------

## ct85711

That is a lot of times different, on a developer waiting to make sure it is properly fixed, and some company waiting just because they missed their deadline for releasing a patch and have to sit on it till next cycle.

----------

## steveL

I think it was more of a ploy to put Greg K-H on the same level as Torvalds, when they're blatantly not on anything like the same level, whatsoever.

----------

## grot

I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.

 *truekaiser wrote:*   

>  *saellaven wrote:*   
> 
> and yet, I use steam without pulse or systemd without any problems...
> 
>  
> ...

 

To play Natural Selection 2 and Crusader Kings 2, the common "no-audio" fix is to override the ini and use the alsa driver entirely instead of pulse. In my experience, this "fix" does not interfere with any other steam games that I have tried, although I would say my experience with linux games is pretty limited. Ofc, I might be misinterpreting what the command does, I'm still pretty new to this stuff. The command to run is

```
SDL_AUDIODRIVER=alsa steam
```

Although, it does seem to me that the group that benefits the most from systemd and family are gamers... which is kind of sad considering Red Hat is pushing it.

----------

## arnvidr

What does systemd do for games? And why is a fix needed to play games without pulseaudio? I have never encountered a problem, with steam or otherwise.

----------

## Naib

Nothing and pulseaudio isn't needed for games (yet...)

I have a number of steam games and all work without systemd. I do have pulse only due to per-app mixing and my lazyness to re-install OSS4 (really is quite good) but I am holding out due to Skype (hopefully the web-client that uses WebRCT so no plugins needed will be released soon )

I can't think of any benefit systemd could bring to gamers. Only a slight advantage to game producers bringing their servers to Linux as in they only have to target one init system for daemon management HOWEVER almost all online games already provide a Linux server binary and all the publishers do was go 'sod it, we will just provide the binary and let the distro's sort it'

Works for bf4, CSS, CSGO, UTx ...

Now considering the performance issue with systemd esp around the logging, why on earth would a gamer choose systemd? I even launch games directly from SLiM for increased performance and I am an openbox user so my WM is already light

----------

## steveL

 *Naib wrote:*   

> I even launch games directly from SLiM for increased performance and I am an openbox user so my WM is already light

 

That sounds cool; would be good to see a write-up.

----------

## truekaiser

 *grot wrote:*   

> I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.
> 
>  *truekaiser wrote:*    *saellaven wrote:*   
> 
> and yet, I use steam without pulse or systemd without any problems...
> ...

 

I use pulse only, not systemD. And yes i tried that, did not work for my games on steam so yes i am stuck using pulseaudio if i want audio in my games.

----------

## saellaven

 *truekaiser wrote:*   

>  *grot wrote:*   I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.
> 
>  *truekaiser wrote:*    *saellaven wrote:*   
> 
> and yet, I use steam without pulse or systemd without any problems...
> ...

 

I'm curious as to why your system specifically is required to use pulse... like I said, I don't have pulse installed at all, yet the sound in all of my steam games (roughly 20) works fine (without any SDL_AUDIODRIVER line either). 

Have you tried removing pulse from your system completely? It wouldn't be the first time that pulse has been known to screw up sound that works otherwise and, circling back a couple pages when you declared that _I_ don't know what I'm talking about just because your system is broken, is part of the reason why I argue that shims are the WRONG approach because they WILL break.

----------

## lotuskip

Here is an interesting quote from way back (1999!):

 *Linus Torvalds wrote:*   

> message passing as the fundamental operation of the OS is just an excercise in computer science masturbation.  It may feel good, but you don't actually get anything DONE.

 

I'm forced to conclude that Lennart and his cabal are wankers (from a purely technical point of view, no slander intended).

----------

## Naib

Well there is no need to be so crude on the topic

----------

## truekaiser

 *saellaven wrote:*   

>  *truekaiser wrote:*    *grot wrote:*   I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.
> 
>  *truekaiser wrote:*    *saellaven wrote:*   
> 
> and yet, I use steam without pulse or systemd without any problems...
> ...

 

Working as i actually get sound. Working as it doesn't matter how badly, or at all( *looks at zsnes, higan, any source engine based game as on hand examples) they even BOTHER to follow alsa documentation and just try to exclusively grab the audio device that i still get sound from it an other programs at the same time. Which has happened to me on pure alsa no matter the dmix config.

tweaking is fine, it just has to be a one time thing. For what I play and what i do using a pure alsa config would result in me tweaking it every time I changed what i want to do at the time. do I want to play a game? tweak the user's .asound config so I get sound and HOPE the game followed alsa documentation and doesn't blindly grab the audio device which removes audio from other programs or segfaults(hexchat did that to me for example once) them. Do I want to play music while I practice and improve my pitiful writing skills? Change the .asound file again to what the music player likes.

Pure alsa has not 'just worked' for me since I had to replace my old workhorse soundblaster audigy 2, and that is because THAT card was one of the last on the market with hardware muxing.

Don't get me wrong, I don't like LP. I hate what he is doing and what he is trying to do. and init system should stay an init system and a slow message bus should not be put into the kernel to gain speed that it can gain by improving it's code. But lets not cut off our nose to spite our face here.

On the one hand people complain that the sound system is stuck in the 90's. Then on the other you rally against a program that, while bad in the past, has improved under different hands which brings it nearly on par with windows. Simply because of the person who started it, who then abandoned it when he saw something shiny. I think you need to look in the mirror to see who is keeping the linux audio system in the 90's mindset.

----------

## grot

 *truekaiser wrote:*   

> Simply because of the person who started it, who then abandoned it when he saw something shiny. I think you need to look in the mirror to see who is keeping the linux audio system in the 90's mindset.

 

Sorry, kaiser, but you're doing that weird thing that some people do which is to take valid criticisms as personal attacks; you're assuming we're holding a personal grudge since some people here feel consistently let down by what LP has produced.

I've never had a major issue with alsa or pulse. Although pulse will mute itself 10% of the time when I press play, and in some cases disabling pulse just works. But I don't want to get too deep into alsa config files just yet. Overall I think I'm happy with pulse... It's saving me work - I think...

From my amateur position, though, for whatever reason, pulse is simply not the complete package it set out to be, and to say an incomplete package will get you out of the 90s is folly. Besides that, who doesn't love the 90s?

----------

## grot

 *lotuskip wrote:*   

> Here is an interesting quote from way back (1999!):
> 
>  *Linus Torvalds wrote:*   message passing as the fundamental operation of the OS is just an excercise in computer science masturbation.  It may feel good, but you don't actually get anything DONE. 
> 
> I'm forced to conclude that Lennart and his cabal are wankers (from a purely technical point of view, no slander intended).

 

Like the other guy said - crude. But I loved the quote. Slowly learning about this message bus stuff.

----------

## steveL

 *grot wrote:*   

> ..to say an incomplete package will get you out of the 90s is folly. Besides that, who doesn't love the 90s?

 

LMAO. Brilliant! ;-)

Yup all the interesting stuff being rediscovered, and labelled innovation, was done back then, when it comes to IPC, realtime scheduling and threading. The one that makes me laugh the most is seeing people argue aio is no good, and then advocating the "Java approach" which effectively relies on aio, as well as its literature (Goetz) reiterating what was written up in the 90s (Butenhof, though you need Gallmeister too.)

Personally I find it much easier to read the clearer specifications, without all the "modern" hand-waving and advocacy.

Not knocking Goetz mind; it's very useful reinforcement material.

----------

## saellaven

 *truekaiser wrote:*   

> 
> 
> Working as i actually get sound. Working as it doesn't matter how badly, or at all( *looks at zsnes, higan, any source engine based game as on hand examples) they even BOTHER to follow alsa documentation and just try to exclusively grab the audio device that i still get sound from it an other programs at the same time. Which has happened to me on pure alsa no matter the dmix config.
> 
> tweaking is fine, it just has to be a one time thing. For what I play and what i do using a pure alsa config would result in me tweaking it every time I changed what i want to do at the time. do I want to play a game? tweak the user's .asound config so I get sound and HOPE the game followed alsa documentation and doesn't blindly grab the audio device which removes audio from other programs or segfaults(hexchat did that to me for example once) them. Do I want to play music while I practice and improve my pitiful writing skills? Change the .asound file again to what the music player likes.
> ...

 

I miss my old hardware based sound cards too...

and I'm not a big fan of ALSA, it definitely has its issues... for the last couple major kernel releases, I'm lacking stereo sound due to some changes in the hda_intel driver that I haven't had a chance to debug. One of these days, I want to get around to trying OSS4 (my biggest concern is just being dependent on another out of tree driver), as my experience with OSS was that it always just worked (again, might have been having hardware with real mixers then).

 *Quote:*   

> 
> 
> Don't get me wrong, I don't like LP. I hate what he is doing and what he is trying to do. and init system should stay an init system and a slow message bus should not be put into the kernel to gain speed that it can gain by improving it's code. But lets not cut off our nose to spite our face here.
> 
> On the one hand people complain that the sound system is stuck in the 90's. Then on the other you rally against a program that, while bad in the past, has improved under different hands which brings it nearly on par with windows. Simply because of the person who started it, who then abandoned it when he saw something shiny. I think you need to look in the mirror to see who is keeping the linux audio system in the 90's mindset.

 

Clearly I believe there are problems in the Linux sound stack... but I don't believe pulseaudio solves those problems, it just adds more complexity and broken thinking to them. That Lennart was involved in pulseaudio isn't a valid reason to not use pulseaudio, pulseaudio itself is why I don't want to use pulseaudio. Ditto for systemd. That Lennart was involved in both projects (and several others that I also don't use) is not an indictment of those projects, though I would argue that the many flaws of those projects ARE an indictment of the key person they all share, in that Lennart's ego is always in the way of him achieving quality work.

The proper solution, is to fix the broken design with a better design (and that may just be OSS4, I haven't played with it enough to say so)... not to create more shims and hackery on top of what is already there, or things just continue to become more precarious. I'm not against progress at all... but it has to be at least as stable and robust as what it is replacing, and pulseaudio, systemd, etc simply are not.

Finally, again since you refused to acknowledge it after insulting my personal integrity and knowledge, at this time steam games do NOT rely on pulseaudio or shims emulating it... that your system "needs" pulseaudio for sound to work is an issue with your system. You could apologize for being wrong and attacking me over your error, though I don't expect you to.

----------

## Naib

There is no need to feign butthurt. Steam ships with libpulse so if you are using the steam runtime (which is advisable) and since steam also uses SDL it will by default use pulse.

You.can override that with SDL_AUDIODRIVER=alsa

----------

## steveL

There is no need for language like that either; this isn't OTW. It's perfectly possible to demur from someone's statements without personalising the whole thing with off-colour nonsense like "feigning butthurt."

Clearly steam does not require pulse, but will work with it if it's running. Which seems reasonable, as does SDL defaulting to it given the current fedora-lite userland.

----------

## mrbassie

Do you guys think SteamOS will wind up switching to systemd? 

On the surface it would appear an obvious yes, given that it's debian based. On the other hand, I imagine Valve chose Debian rather than a different or descendant distro due to Debian's well earned reputation for stability. From what I've read systemd is nowhere near stable yet and considering they keep adding new fangled wheels-with-right-angles to it whenever they get bored (it no longer being a unicycle) I can't see how it will be for many years.

----------

## Navar

 *mrbassie wrote:*   

> Do you guys think SteamOS will wind up switching to systemd? 
> 
> On the surface it would appear an obvious yes, given that it's debian based. On the other hand, I imagine Valve chose Debian rather than a different or descendant distro due to Debian's well earned reputation for stability.

 

Eh, people pick Debian, etc. as much of a use case of environment they're familiar with for years as much as anything else (and Gentoo is pretty much there too).  That is in large part why Debian, RedHat, etc. ever became the major distros over time.  They added (perceived) ease, they came with package managers (which didn't exist), etc.  In the same vein, it's amazing Slackware is still going, but for partially the same reasons and kudos to them.

Anyway, if I had to wager, I'd say with a 90% prediction interval that the corporate folk of Valve picked Debian because they were: a) particularly familiar with it w.r.t. to Linux exposure, b) don't want to re-invent wheels and bike shed past their goal particularly w.r.t. costs.  They will not care about systemd being running as their MCP since their end game is something else entirely, much like chrome OS (front side 'views' versus back end details).  Even if it causes them issues, my understanding is they could always just default back to the prior init systems and freeze at Debian 7 'wheezy' or whatever it is that added the Borg vote.  Worst case they might have to fix some broken script functionality if they attempt anything too exotic.

----------

## gwr

 *saellaven wrote:*   

> 
> 
> I again reiterate my story that I didn't care one whit about systemd until WilliamH abused his power to intentionally cripple the systems of people NOT using systemd because of systemd's shortsighted and arrogant self-imposed technical limitations. Break your system all you want and I don't care, but break my system and I have a problem.
> 
> 

 

I apologize for rewinding this thread a bit, but I'd really like some additional context around what WilliamH did in relation to saellaven's earlier post above. I have seen allusions to this elsewhere, and I have bits and pieces of ideas. I'd appreciate a technical explanation, if possible, but I understand that politics are tied up in this, too. I'm not looking to bash anyone, just curious about what I should know about it.

----------

## saellaven

 *gwr wrote:*   

>  *saellaven wrote:*   
> 
> I again reiterate my story that I didn't care one whit about systemd until WilliamH abused his power to intentionally cripple the systems of people NOT using systemd because of systemd's shortsighted and arrogant self-imposed technical limitations. Break your system all you want and I don't care, but break my system and I have a problem.
> 
>  
> ...

 

short, short version (you can dig through past threads for a more detailed version if you want)...

WilliamH is lead of OpenRC and is also on the systemd herd. Immediately upon being elected to the Council, he asked the Council to break booting with a separately mounted /usr in OpenRC (where it has always worked) unless people use an initramfs*, largely because systemd upstream decided that they no longer wanted to support a separate /usr. SteveL developed a patch set for OpenRC to ensure it could continue to boot a separate /usr no matter what and has supported those patches since. WilliamH was made aware of them, rejected them without explanation, and then went on to not only continue to push the Council to mandate the breakage of OpenRC, but also refused to disclose the information that the patches existed to his fellow Council members before ultimately having the vote forced. In rubber stamping his proposal, the Council, on their part, assumed good faith from one of their fellow Council members and, apparently, did no independent research or thought into the situation, including the fact that the initramfs "solution" makes systems more fragile, prone to breakage and has continued to cause problems for people attempting their solution ever since.

The patches still exist, are still supported by SteveL, myself and others, and yet WilliamH still continues to abuse his authority as lead of OpenRC in refusing to accept them. The only reasonable explanation is that WilliamH is intentionally holding OpenRC back out of 

1) wanting to cripple it to favor systemd (since systemd is technologically inferior in this regard, he wants to bring others down to its level because its proponents are so vocal that it's the best thing ever) 

2) pettiness because he doesn't like SteveL on a personal level (which is not a technical reason to reject the very simple patch) 

or 3) simple incompetence.

* introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade

----------

## tclover

 *saellaven wrote:*   

> 
> 
> * introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade

 

Can you develop a little about it? Just asking because I do _not_ have any of those crippling issues using an initramfs, quite the opposite... after several breakages of my system for various reasons (mainly risky experiments), bringing back a functional system was only possible thanks to a minimal shell available in the initramfs.

I did not follow various things before SystemD became such a hot topic, notably the separate `/usr' debacle _because_ of using an initramfs. (Booting from either ZFS on dm-crypt LUKS or LVM2 on top of dm-crypt LUKS require such a thing.)

Well then, I am talking about the project on my sig... because I do know that the officially supported tools (genkernel and dracut) are... massive with udev, bash, and part of coreutils/util-linux bundled. Quite the hammer from a lightweight tool solely depending on busybox/mdev (with extra package for additional functionality.)

(I won't be surprised when SystemD itself would be included...)

----------

## tld

Interesting...thanks for the summary.  I've sort of only half followed that /usr situation.  I've never had a separate /usr partition, however I also don't use an initramfs and absolutely would never want to.  I'd be in flames if I got burned by that one.  Seriously screwed.

----------

## steveL

 *saellaven wrote:*   

> introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade

 

 *tclover wrote:*   

> Can you develop a little about it?

 

Consider that you're using some disk tool in initramfs. Now that tool is upgraded on your main machine (ie the rootfs.) Your initramfs is using older software.

Now we hope that's not an issue, but sometimes it is, or might be. I'd rather not have to worry about it.

Similarly we were told on the list not to worry about building an initramfs since they're small, and quick to build. At the same time we were told that an "initramfs is the new root", so you can do all your recovery from there. Personally I'd rather not have to think about what to build in, but just use the rootfs, since I configure my kernel to start the rootfs without modules, when I install. (It's the first thing I have to do before I can really start emerging anything, and is a milestone in the install process, ime. I also build in my fixed ethernet so I don't have to worry about bring-up order for eth0.)

Obviously if you need module setup, or network etc, to start the rootfs in the first place then you need an initramfs. However this is no different to the situation before: you always needed an initrd if you had eg root on raid, encrypted or lvm (but not /usr, at least for lvm.)

The point is that if you didn't need an initrd before, you don't need an initramfs now either. Only that was obfuscated, or lied about if we're being accurate.

 *Quote:*   

> Just asking because I do _not_ have any of those crippling issues using an initramfs, quite the opposite... after several breakages of my system for various reasons (mainly risky experiments), bringing back a functional system was only possible thanks to a minimal shell available in the initramfs.

 

Well I've always just done exactly the same with init=/bin/bash from grub and my rootfs. 

But no-one's knocking anyone else's use-case here. We're just annoyed at inaccurate information being used to justify dropping support for ours.

 *Quote:*   

> I did not follow various things before SystemD became such a hot topic, notably the separate `/usr' debacle _because_ of using an initramfs. (Booting from either ZFS on dm-crypt LUKS or LVM2 on top of dm-crypt LUKS require such a thing.)

 

Exactly: you'd have needed an initrd in the days before all this came up. An initramfs is exactly the same thing, from the kernel's pov, just using a different underlying ramfs "technology". (Yes I'm aware it's always there: I just don't need it.)Last edited by steveL on Wed Jan 07, 2015 8:05 pm; edited 1 time in total

----------

## saellaven

 *tclover wrote:*   

>  *saellaven wrote:*   
> 
> * introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade 
> 
> Can you develop a little about it? Just asking because I do _not_ have any of those crippling issues using an initramfs, quite the opposite... after several breakages of my system for various reasons (mainly risky experiments), bringing back a functional system was only possible thanks to a minimal shell available in the initramfs.
> ...

 

if a backwards incompatible change happens on disk after a key utility gets upgraded (say, LVM or ext4 or whatever, it does happen, though infrequently) but the initramfs doesn't get updated, you could find yourself with a foo-2.xx format on disk with a foo-1.xx utility in your initramfs that can't read the disk, leaving you with a system that cannot boot without major intervention. You may also find you have problems with out of kernel-tree modules and all kinds of other goodies.

Thus, you have to rebuild your initramfs after every update of ANYTHING in it just in case, or else you can find yourself with a non-working system even if everyone on the system itself is fine. Now, keep in mind that every time you do that, you're potentially booting with an untested initramfs that could break anyway, so you need to keep multiple initramfs and matching kernels around. Instead of making things more robust, it makes things far more fragile.

Me?

I avoid the initramfs completely, so my system is always booting with what is installed on the system currently. I also keep my current and last known working kernel around (as well as an initramfs kernel just in case WilliamH intentionally breaks OpenRC because he doesn't like a separate /usr or whatever), plus I keep a second minimal Gentoo installation handy so that I can boot to that as a repair tool if needed (it's more or less equivalent to something like sysrescuecd, where I have all of the tools I would need to fix my system in the event of catastrophic breakage installed).

By intentionally keeping the most fragile part of boot out of my boot process, my system is far more likely to boot than not. That said, if you require a bluetooth keyboard or something else (like your LUKS setup) that requires a fully functional system already running just to boot up, you're stuck with an initramfs. That said, the initramfs is completely unnecessary for boot with a separate /usr, it's just a problem because WilliamH solely decided to make it a problem and then decided to abuse his position on the Council to make it a distribution-wide problem unless you use SteveL's patches.

----------

## tclover

 *steveL wrote:*   

> Consider that you're using some disk tool in initramfs. Now that tool is upgraded on your main machine (ie the rootfs.) Your initramfs is using older software.
> 
> Now we hope that's not an issue, but sometimes it is, or might be. I'd rather not have to worry about it.
> 
> Similarly we were told on the list not to worry about building an initramfs since they're small, and quick to build. At the same time we were told that an "initramfs is the new root", so you can do all your recovery from there. Personally I'd rather not have to think about what to build in, but just use the rootfs, since I configure my kernel to start the rootfs without modules, when I install. (It's the first thing I have to do before I can really start emerging anything, and is a milestone in the install process, ime. I also build in my fixed ethernet so I don't have to worry about bring-up order for eth0.)
> ...

 

There are valid reasons... but I don't see a _valid_ to reject an initramfs as de facto (inflexible like) stance. I do understand why those who did _not_ need an initramfs took such an opposition to such matter/sabotage. However, the worries you don't want to think of are no different to other sensible updates (such as OpenRC when a major update hit the tree that require care that can render a system unbootable.) Such updates are worrisome, and there is no way to avoid them. I guess trying to avoid useless hassles is a sane stance.

But, I've been using an initramfs since 2011... and I did not bump into that system update which require rebuilding the initramfs. I can only think of 3 reasons, actually a sole reason, (ZFS/LUKS/LVM2 use cases): _metadata/header/format_ change. However, those come rarely enough (compared to OpenRC major update for example) to not burden the use of an initramfs. With a good tool, it's like: kernel update... an additional command is executed to build an initramfs. Period. Easy as that.

So, I don't see the prejudice of using an initramfs as being an worrisome burden.

 *steveL wrote:*   

> 
> 
> Well I've always just done exactly the same with init=/bin/bash from grub and my rootfs. 
> 
> But no-one's knocking anyone else's use-case here. We're just annoyed at inaccurate information being used to justify dropping support for ours.
> ...

 

This is a little short sighted example... Let me put another easy breakage that shows the short comings of this.

I've just broken a hardware a few months ago, a hardware that did not survive half a dozen of kernel panics (my fault as usual.) And I did not have any other machine with Linux. I had to resend the hardware knowing I would never get is back again. What should have I done to get my data (LVM2 & ZFS on LUKS) without any other hardware around with Linux? Moreover, I was living in a new city shortly after moving, so I did not know anybody with a Nix OS. You know what? My initramfs saved my arse, well my data (again.) Booted (with a hardware having W7) from a pendrive with kernel+initramfs=minimal shell available, so I could copy my data to another disk.

Sorry to say this, but `init=/bin/bash' is just... no apropos of ths kind of issues. And, I did have a few hard ones... in the past.

I completely second on the last sentence. Moronic with that.

----------

## saellaven

 *tclover wrote:*   

> 
> 
> There are valid reasons... but I don't see a _valid_ to reject an initramfs as de facto (inflexible like) stance. I do understand why those who did _not_ need an initramfs took such an opposition to such matter/sabotage. However, the worries you don't want to think of are no different to other sensible updates (such as OpenRC when a major update hit the tree that require care that can render a system unbootable.) Such updates are worrisome, and there is no way to avoid them. I guess trying to avoid useless hassles is a sane stance.

 

For people that want or need an initramfs, more power to them... none of us oppose it in that case. We object to being forced to use one for political reasons (as the technical justifications were entirely phony)

 *Quote:*   

> 
> 
> But, I've been using an initramfs since 2011... and I did not bump into that system update which require rebuilding the initramfs. I can only think of 3 reasons, actually a sole reason, (ZFS/LUKS/LVM2 use cases): _metadata/header/format_ change. However, those come rarely enough (compared to OpenRC major update for example) to not burden the use of an initramfs. With a good tool, it's like: kernel update... an additional command is executed to build an initramfs. Period. Easy as that.

 

Since the mandate for an initramfs, people have had a near endless number of issues with systems that wouldn't boot because of it. It's either luck or diligence in rebuilding your initramfs that you didn't get bit, as I know for certain there was at least one upgrade in there about 3 years ago that broke backwards compatibility and caused grief (I want to say to lvm2 or e2fsprogs, but I don't remember for sure).

 *Quote:*   

> 
> 
> This is a little short sighted example... Let me put another easy breakage that shows the short comings of this.
> 
> I've just broken a hardware a few months ago, a hardware that did not survive half a dozen of kernel panics (my fault as usual.) And I did not have any other machine with Linux. I had to resend the hardware knowing I would never get is back again. What should have I done to get my data (LVM2 & ZFS on LUKS) without any other hardware around with Linux? Moreover, I was living in a new city shortly after moving, so I did not know anybody with a Nix OS. You know what? My initramfs saved my arse, well my data (again.) Booted (with a hardware having W7) from a pendrive with kernel+initramfs=minimal shell available, so I could copy my data to another disk.
> ...

 

Hence why I have another system setup to repair things if something goes wrong. That system is updated about once a month when everything installed is in a known working condition. Worst case scenario for me, is that lilo (I never cared for grub) gets broken, in which case, I bust out an actual sysrescuecd disc (hasn't happened in about a decade or so).

But, at the end of the day, we're expected to know our system and our needs, tailoring them as needed. Things like mandating an initramfs stems precisely from the arrogance and ignorance that someone else knows what is best for everyone and tries to force it on us (ie, the 'one true way').

----------

## ct85711

For me, I stopped using any kind of ramfs, back in either 2001 or 02.  So I remember using the old initrd quite well, and all the trouble I was encountering with it.  Surprisingly enough, once I recompiled the kernel so that it didn't need a initrd/initramfs (on a original Redhat linux distro); all those troubles stopped and never had to worry about it since.    The key thing is, Why should I be forced to use a initramfs when my system hasn't ever needed one to begin with?  I have NEVER needed LUKS, LVM, or any other special thing.  When my system dies, I download a random linux live cd to in the worse case to fix my problems.  Either way from how I've seen it, if my drive fails, it doesn't matter what was on it, as what's dead is still dead, not going to change that.  Note, that's why you back up your important information (I don't bother backing up anything, but nothing on my system is that critical if I loose it either).

----------

## steveL

 *steveL wrote:*   

> Consider that you're using some disk tool in initramfs. Now that tool is upgraded on your main machine (ie the rootfs.) Your initramfs is using older software.
> 
> Now we hope that's not an issue, but sometimes it is, or might be. I'd rather not have to worry about it.
> 
> Similarly we were told on the list not to worry about building an initramfs since they're small, and quick to build. At the same time we were told that an "initramfs is the new root", so you can do all your recovery from there. Personally I'd rather not have to think about what to build in, but just use the rootfs, since I configure my kernel to start the rootfs without modules, when I install.

 

 *tclover wrote:*   

> There are valid reasons... but I don't see a _valid_ to reject an initramfs as de facto (inflexible like) stance.

 

I'm not the one taking an inflexible stance though; the nub-skool are.

I'm perfectly content for anyone to use w/e TF they want, since it makes zero difference to me. I just don't see the point in pretending regressions are "innovative progress."

If I'm inflexible about anything, it is about not accepting snakeoil-salesmen at face-value.

 *Quote:*   

> I do understand why those who did _not_ need an initramfs took such an opposition to such matter/sabotage.
> 
> However, the worries you don't want to think of are no different to other sensible updates (such as OpenRC when a major update hit the tree that require care that can render a system unbootable.)

 

No they're not. I never forget to run dispatch-conf, since update runs it for me automatically, and shouts at me if I didn't run it the last time against its advice.

Why should I add another item to my kernel upgrade routine, in order to do a load of unnecessary crap that I never needed before, and I don't need now, so that I can leave myself open to breakage I don't even have to think about now, all so that some twat who would've been kicked out of Computing within his first two years in my day, can strut around posturing about how everyone's machines are his?

Hand-waving about how everything is the same at the end of the day, doesn't add anything, it merely clouds the issue, which to me is essentially about diversity in an ecosystem as opposed to an unpleasantly-enforced monoculture.

 *Quote:*   

> Such updates are worrisome, and there is no way to avoid them.

 

Really? Yet here you are saying I can do exactly that for a whole class of worry:

 *Quote:*   

> I guess trying to avoid useless hassles is a sane stance.
> 
> But, I've been using an initramfs since 2011... and I did not bump into that system update which require rebuilding the initramfs.

 

So what? Don't extrapolate from your experience to the ROTW; that's just insane, especially when it comes to computing, imo.

It's not "a worrisome burden" for you; good for you. Use what you want, no-one minds or really even cares, apart from the neo-fascists who want to turn your computer into their device.

As for the part about init=/bin/bash is was just a minimal example; keep a sysresccd disk around, or download one from another box when things fsck up. Live-disks are two-a-penny, with GUI and everything.. But I don't see any major difference between relying on the /boot partition and relying on a small root on the same drive, apart from less work for me ;-)

----------

## steveL

 *ct85711 wrote:*   

> Either way from how I've seen it, if my drive fails, it doesn't matter what was on it, as what's dead is still dead, not going to change that.
> 
> Note, that's why you back up your important information.

 

++

----------

## MustrumR

About separate usr without initramfs this is what I would do:

 - Have sys-apps/busybox on rootfs

```

cat > /init << EOF

#!/bin/bb

busybox mount /usr &&

exec /sbin/init || exec /bin/busybox sh

EOF

```

And boot with init=/init

This is fully compatible with the usr-gentoo overlay which tries to move some stuff from / to /usr.

----------

## khayyam

 *steveL wrote:*   

> I just don't see the point in pretending regressions are "innovative progress."

 

steve ... just to be clear, the use of an initramfs is a "regression"? Certainly they should not be required, but for LVM on a LUKS encrypted volume they are necessary. No, they are not the "new root", and no you shouldn't need them to have a separate /usr, they may even have to be maintained (which is actually less of an issue than its being made out to be ... as not all initramfs are created equal) ... but those questions seem to be unrelated to the initramfs facility itself. As tclover stated "there are valid reasons" so your "not being inflexible" seems rather ... well, inflexible (indeed, rather intolerant and dictatorial).

best ... khay

----------

## saellaven

 *khayyam wrote:*   

>  *steveL wrote:*   I just don't see the point in pretending regressions are "innovative progress." 
> 
> steve ... just to be clear, the use of an initramfs is a "regression"? Certainly they should not be required, but for LVM on a LUKS encrypted volume they are necessary. No, they are not the "new root", and no you shouldn't need them to have a separate /usr, they may even have to be maintained (which is actually less of an issue than its being made out to be ... as not all initramfs are created equal) ... but those questions seem to be unrelated to the initramfs facility itself. As tclover stated "there are valid reasons" so your "not being inflexible" seems rather ... well, inflexible (indeed, rather intolerant and dictatorial).
> 
> best ... khay

 

Requiring an initramfs solely for a separate /usr IS indeed a regression... it wasn't broken until WilliamH intentionally broke it and the patches exist, though he won't accept them because he wants it broken. Ergo, it is a regression.

There's nothing wrong with an initramfs if you need one for technical reasons, but a separate /usr is not one of those technical reasons, despite what WilliamH and the rubber stamp Council claim, as we've proven,

----------

## asturm

 *saellaven wrote:*   

> Requiring an initramfs solely for a separate /usr IS indeed a regression... it wasn't broken until WilliamH intentionally broke it and the patches exist, though he won't accept them because he wants it broken. Ergo, it is a regression.

 

Isn't that utter BS?

From the wiki:

 *Quote:*   

> When the /usr partition is on a separate file system, tools and drivers that have files stored within /usr cannot be used unless /usr is available. If those tools are needed to make /usr available, then we cannot boot up the system.

 

Unless your boot needs something from /usr, you're set.

----------

## khayyam

 *saellaven wrote:*   

> Requiring an initramfs solely for a separate /usr IS indeed a regression... it wasn't broken until WilliamH intentionally broke it and the patches exist, though he won't accept them because he wants it broken. Ergo, it is a regression.

 

saellaven ... please do not conflate the "initramfs facility itself" with the rationale provided by developers for its "requirement", that wasn't the line of reasoning I was following, nor was it the subject of the quote from tclover and steveL's reply to which I was responding.

 *saellaven wrote:*   

> There's nothing wrong with an initramfs if you need one for technical reasons, but a separate /usr is not one of those technical reasons, despite what WilliamH and the rubber stamp Council claim, as we've proven,

 

Fair enough, but it has nothing to do with what I was responding to, or the context in which steve responded to tclover.

best ... khay

----------

## steveL

 *saellaven wrote:*   

> Requiring an initramfs solely for a separate /usr IS indeed a regression... it wasn't broken until WilliamH intentionally broke it and the patches exist, though he won't accept them because he wants it broken. Ergo, it is a regression.

 

 *khayyam wrote:*   

> saellaven ... please do not conflate the "initramfs facility itself" with the rationale provided by developers for its "requirement", that wasn't the line of reasoning I was following, nor was it the subject of the quote from tclover and steveL's reply to which I was responding.

 

Hmm it was actually; you're changing my words or the context they were put in, to mean something else. FTR I'm not saying you're doing so maliciously (just in case someone who doesn't know us thinks we're arguing..)

 *steveL wrote:*   

> I just don't see the point in pretending regressions are "innovative progress."

 

 *khayyam wrote:*   

> steve ... just to be clear, the use of an initramfs is a "regression"?

 

No; when did I say the use of anything is a regression? Regressions is a wider point about various changes we've seen that are hyped for years as "essential" and then quietly not mentioned any more once they've served their purpose, which is in fact pretext to justify arm-twisting us into accepting bad ideas. And meantime our machines are clogged down with more and more crap, all inturgrated since ofc you want to feel that your pid1 is capable of introspecting glib; I mean, who wouldn't, right? Right? ;)

In this case, I see it as a regression in Gentoo that support for a working model is deliberately crippled, and people are fed utter nonsense to justify it. When we even mention it, we get accused of all sorts of sins, but no-one questions the people who fed them the lies in the first place. And they are lies, pure and simple; the technical discussion was had back then, the requirements were listened to, and proof of concept was delivered. Then the hand-waving and the "we don't want to listen to you, but here's some vague crap to make it sound reasonable" began, as it has so many times before.

That's a regression in the same way that dropping openrc and moving to systemd would be a regression: in the capability of the end-product, which in Gentoo's case is a from-source distro that you can do whatever you want with.

So much for "just do the work and prove your point, and we'll work with you." It's hard to keep up "good faith" when the people you're dealing with don't show any, and just use the very idea as yaf stick to beat you with, should you have the temerity to point out the emperor's clothes they're all raving about, don't seem to cover much.

But then, the developers are way behind the users, as a collective. Still, we only want them to keep churning out ebuilds, even if they're not very capable with bash, and have far too inflated an opinion of themselves. Arrogance in young males is nothing new; we've all been there. It's the older ones who nod and pretend to be wise, while doing sweet fanny adams about any of the messes they see in front of them, that annoy me; principally because they know better, but also because they are so smug about doing nothing to show leadership.

For all those still clinging to some ridiculous notion that Gentoo (and Linux more broadly) is "not about choice", prove it. Argue it out and show us how it's not; as atm all you've done is provide a propaganda^W marketing slogan with zero actual substance. An application of Linux that is locked-down doesn't prove it either: it just proves you can choose to do that with a Linux.

----------

## saellaven

 *genstorm wrote:*   

>  *saellaven wrote:*   Requiring an initramfs solely for a separate /usr IS indeed a regression... it wasn't broken until WilliamH intentionally broke it and the patches exist, though he won't accept them because he wants it broken. Ergo, it is a regression. 
> 
> Isn't that utter BS?
> 
> From the wiki:
> ...

 

Correction... if you need something from /usr to mount /usr, then you need an initramfs. There is no technical reason why you can't mount /usr separately as long as you (can) mount /usr first otherwise... which is exactly what SteveL's patch does. The only reason that patch is not a part of openrc right now is because WilliamH is abusing his position to keep it out and further abused his position on the Council to enforce this political (because it isn't a technical) decision on everyone.

Thus, you need an initramfs if you use LUKS or whatever... and you need an initramfs if you buy the RedHat BS that "/usr is the new /" where we just haphazardly install anything and everything to /usr out of ignorance or laziness. You do not need an initramfs if everything you need to boot is on / and never have until WilliamH brought his agenda to Gentoo (and again, a trivial patch fixes it but he won't accept it).

----------

## Ant P.

 *saellaven wrote:*   

> You do not need an initramfs if everything you need to boot is on / and never have until WilliamH brought his agenda to Gentoo (and again, a trivial patch fixes it but he won't accept it).

 

Heh, I now know where you're coming from. I got to deal with that brain damage first-hand when I was fixing the runit ebuild.

Unprivileged-uid-usable binaries dumped into /usr/sbin/, other (boot-required) stuff needlessly thrown in /usr/bin/ when /bin/ would have been fine... 4 months to apply one-line patches for things like, oh, having consoles *work properly* on boot... no prize for guessing the maintainer.

----------

## khayyam

 *steveL wrote:*   

>  *khayyam wrote:*   steve ... just to be clear, the use of an initramfs is a "regression"? 
> 
> No; when did I say the use of anything is a regression? Regressions is a wider point about various changes we've seen that are hyped for years as "essential" and then quietly not mentioned any more once they've served their purpose, which is in fact pretext to justify arm-twisting us into accepting bad ideas. And meantime our machines are clogged down with more and more crap, all inturgrated since ofc you want to feel that your pid1 is capable of introspecting glib; I mean, who wouldn't, right? Right? ;)

 

steve ... well, context here is important ... tclover asked that the question of boot failure when using initramfs be elaborated, s/he then agrees with you wrt "inaccurate information being used to justify dropping support", and all through the exchange s/he is focused on the initramfs facility and not the rational provided by developers/upstream for dropping support for separate /usr (which, again, s/he agrees is not a valid reason for requiring an initramfs ... in fact s/he calls it "moronic"). You then respond in a roughshod manner taking what was said as somehow a justification for what s/he's already disavowed, and so the "valid reasons", and "reject[ion] of the  initramfs de facto" is made a whipping boy for "regressions". In short, you constructed a stawman in place of the argument, or discussion, tclover was having, hence my question: is the use of an initramfs a regression ... as that is all tclover was defending, the facility itself and "valid reasons" for its use.

 *steveL wrote:*   

> In this case, I see it as a regression in Gentoo that support for a working model is deliberately crippled, and people are fed utter nonsense to justify it. When we even mention it, we get accused of all sorts of sins, but no-one questions the people who fed them the lies in the first place. And they are lies, pure and simple; the technical discussion was had back then, the requirements were listened to, and proof of concept was delivered. Then the hand-waving and the "we don't want to listen to you, but here's some vague crap to make it sound reasonable" began, as it has so many times before.

 

But tclover had already described those justifications as "moronic", so you weren't even arguing against a position s/he'd taken ... if s/he'd argued such a case then your "regression" would have made sense.

best ... khay

----------

## Anon-E-moose

It's kind of funny how the argument "I don't need or use an initramfs so you shouldn't or it's moronic" 

sounds an awful lot like the justifications that LP uses for his choices in systemd "I don't need it so no one else should".

Seriously folks. 

We all (pretty much) agree that the /usr thing re. udev wasn't a good idea. Let it go. Move forward instead of being stuck somewhere in the past.

----------

## saellaven

 *Anon-E-moose wrote:*   

> It's kind of funny how the argument "I don't need or use an initramfs so you shouldn't or it's moronic" 
> 
> sounds an awful lot like the justifications that LP uses for his choices in systemd "I don't need it so no one else should".

 

To be clear, I have no problem with the people that want or need an initramfs and I believe it is certainly a valuable tool for those who need it. I'm not against the facility existing, just the mentality that we HAVE to use it. The Council's decision to mandate it was the moment I got involved in the systemd debate precisely because I'm all about choice and they're trying to remove choice.

 *Quote:*   

> 
> 
> Seriously folks. 
> 
> We all (pretty much) agree that the /usr thing re. udev wasn't a good idea. Let it go. Move forward instead of being stuck somewhere in the past.

 

I only brought it up because someone asked and I tried to give the short version rather than give all the minutia. Further, the simple fact is the problem still exists primarily because WilliamH isn't out for the most robust openrc possible.

----------

## depontius

 *Anon-E-moose wrote:*   

> It's kind of funny how the argument "I don't need or use an initramfs so you shouldn't or it's moronic" 
> 
> sounds an awful lot like the justifications that LP uses for his choices in systemd "I don't need it so no one else should".
> 
> Seriously folks. 
> ...

 

Hmmmm....  Something of a middle-ground.  Some of the /usr-related complaints were being directed toward the OpenRC developer, suggesting that he's "gone over to systemd" and is therefore not sufficiently interested any more.  Normally when one loses interest in an owned project, you hand the reins over to others who still are.  To put the tin-foil hat on for a moment, the argument could be made that OpenRC is being gently ridden into the ground.

That's perhaps a tin-foil hat theory, (I find it fun now and then to keep one laying around.) but it is worth remembering that the time may come when it becomes necessary to fork OpenRC.  Some may argue that one such time was back with the /usr issue.  That time/opportunity missed, the /usr fix can be queued as one of the first enhancements, shortly followed by start-stop-daemon enhancements being discussed in other threads.

----------

## tclover

Thanks Khayyam, for clarifying a few things which is _more_ than necessary seeing how SteveL, and a few others, like to keep that confusion between the _facility_ and being _forced_ to use the "facility" (initramfs) going as far as _never_ use an initramfs (because it's, _"obviously"_, too much a maintenance _burden_.)

After reading SteveL response and subsequents other answers, I decided to not waste unnecessary times reading or posting subsequent posts which would be, for sure, _mere_ waste of time.

----------

## steveL

 *khayyam wrote:*   

> steve ... just to be clear, the use of an initramfs is a "regression"?

 

 *steveL wrote:*   

> No; when did I say the use of anything is a regression? Regressions is a wider point about various changes we've seen that are hyped for years as "essential" and then quietly not mentioned any more once they've served their purpose, which is in fact pretext to justify arm-twisting us into accepting bad ideas. And meantime our machines are clogged down with more and more crap, all inturgrated since ofc you want to feel that your pid1 is capable of introspecting glib; I mean, who wouldn't, right? Right? ;)

 

 *khayyam wrote:*   

> steve ... well, context here is important ... tclover asked that the question of boot failure when using initramfs be elaborated, s/he then agrees with you wrt "inaccurate information being used to justify dropping support", and all through the exchange s/he is focused on the initramfs facility and not the rational provided by developers/upstream for dropping support for separate /usr (which, again, s/he agrees is not a valid reason for requiring an initramfs ... in fact s/he calls it "moronic").

 

No s/he also in fact asserted that I am taking an "inflexible stance" in rejecting initramfs across the board which I never did. That is the strawman here, and you are merely repeating it, despite being told twice "no, that's not what I am saying".

I am not sure what I can do beyond reiterate that both of you are spinning my position up in to something it is not, and then attacking that supposed position of mine.

As usual, everyone focusses on the people discussing the issue, rather than the actual issue. And we get the usual cognitive dissonance crap about "can't we all just get along? move on.." implying as ever that the problem is the people, not the actual issue. 

Instead of personalising it, just talk about the issue. Since we've all agreed that there was no technical reason for the drop of support, despite the pretext of several being presented, it was a bad move. Period.

Now by all means move on: just don't pretend that issue has anything whatsoever to do with how we discussed things here, now.

----------

## khayyam

 *steveL wrote:*   

>  *khayyam wrote:*   steve ... well, context here is important ... tclover asked that the question of boot failure when using initramfs be elaborated, s/he then agrees with you wrt "inaccurate information being used to justify dropping support", and all through the exchange s/he is focused on the initramfs facility and not the rational provided by developers/upstream for dropping support for separate /usr (which, again, s/he agrees is not a valid reason for requiring an initramfs ... in fact s/he calls it "moronic"). 
> 
> No s/he also in fact asserted that I am taking an "inflexible stance" in rejecting initramfs across the board which I never did. That is the strawman here, and you are merely repeating it, despite being told twice "no, that's not what I am saying".

 

steve ... no, that conflation begins with you, you move from "boot failure when using initramfs" to the whole question of separate /usr, and what "your told on the list [...] initramfs is the new root", etc, so you come down as practically dismissive of any suggestion of an initramfs being in any way useful.

Additionally, when you return with your "I just don't see the point in pretending regressions are innovative progress", this is in reply to the following ... which you'd sniped:

 *tclover wrote:*   

> There are valid reasons... but I don't see a _valid_ to reject an initramfs as de facto (inflexible like) stance. I do understand why those who did _not_ need an initramfs took such an opposition to such matter/sabotage.

 

To me that reads altogether different to an "assert[ion] that [you are] taking an "inflexible stance" in rejecting initramfs across the board", if you read what its in response to you have a slew of reasons most of which don't relate to what tclover had asked for ... so, a barrage of reasons (again, mostly about separate /usr) that hardly comes across as anything but down on initramfs. Again, your judgement was  that this discussion is *all* about separate /usr ... but that was far from the question asked, and there was no disagreement there.  

 *steveL wrote:*   

> I am not sure what I can do beyond reiterate that both of you are spinning my position up in to something it is not, and then attacking that supposed position of mine.

 

You could take it as an object lesson in how not to rub people the wrong way, myself included. If you want to now state that we are "spinning your position" I'll remind you that this "position" was focused on what you wanted to bang on about, and paid little attention to what tclover had actually asked ... so, hows that for spin?  

 *steveL wrote:*   

> As usual, everyone focusses on the people discussing the issue, rather than the actual issue. And we get the usual cognitive dissonance crap about "can't we all just get along? move on.." implying as ever that the problem is the people, not the actual issue.

 

It might focus on "people" because someone might wonder why you feel the need to be so aggressive about such a minor point (particularly as the major point you wanted to make re "regression" wasn't even contested) ... you're acting like people we're actually in substantive disagreement. Novel idea, maybe I said something because you *were* acting kind of boorish.   

 *steveL wrote:*   

> Instead of personalising it, just talk about the issue. Since we've all agreed that there was no technical reason for the drop of support, despite the pretext of several being presented, it was a bad move. Period.

 

Honestly, good advice sometimes comes from the wrong person ...

 *steveL wrote:*   

> Now by all means move on: just don't pretend that issue has anything whatsoever to do with how we discussed things here, now.

 

... but so does bad, or unintelligible, advice ...

best ... khay

----------

## WWWW

I have to say this to support SteveL.

Yes, initramfs does have its drawbacks.

I think what SteveL says or aims is for simplicity in a process in general. Cut off all the unnecessary stuff as much as possible to have something working.

initramfs did become somewhat bloated over time. I remember the time the kernel itself was able to boot itself alone.

I had to give up this idea due to using zfs, or when using lvm. Now I have to resort to genkernel which is immensely bloated and grabs tons of stuff to build the initramfs.

The difference between one building something and knowing where all the pieces fall in contrast to build something blindly adding everything in the hopes this way it'll boot. The former has it's merit.

Here the conflict is taking away the former option without apparent reason.

Take as an example GRUB vs UEFI booting. Grub has taken away the option to boot in a simple way and favored placing files all over the place.

Before everything needed used to reside under /boot/grub/ now the files are scattered all over the place. Even the more intuitive grub file in /etc has a big fat warning on top "DON'T CHANGE ME HERE IT WILL BE OVERWRITTEN!!".

Grub has evolved to a configuration completely automated but it fails in many scenarios where somebody doesn't use the 'ubuntu linux' experience.

Try to set a boot entry manually in grub2. Plain schizophrenic. Crazy order of things, insane syntax, modules dependencies, etc. And prolly you end up with a borked entry that needs further fixing.

Now try UEFI boot entry.

1- kernel in /boot (this is an extra step due to initramfs)

2- boot kernel in /esi

3- boot the machine

Without an initramfs it get's reduced to 2 steps:

1- kernel in /esi

2- boot the machine

No fucking around with insane amount of files, syntax, etc whatsoever. I never got around using grub2 due to this.

It's been a while since I don't use separate /usr anymore thanks to systemd isis terrorism borking my system. So I can't go into detail about this.

In other words, I supposed it comes down to defending the "simplicity of a process", nothing more and nothing less. Sure initramfs can solve or work in many scenarios, but if it can be done in a more concise way? Why not? Why destroy, impede, discourage the 'simplicity of a process'?

thanks

----------

## ct85711

The part I am waiting for is when we get to the point that initramfs is no longer needed at all, even for zfs and lvm and stuff.  Yes, I know it's been said the kernel devs said they will not add support to the kernel, but who said anything that a package adds onto the kernel such that you install the package that adds an addition to the kernel (not meaning as a module, actual addition to the kernel).  You recompile the kernel adding the support for the package into the kernel. I'm not meaning adding a kernel module that gets loaded after the kernel is running (from what I've seen/read, for boot up having the core parts as a module won't work).

----------

## steveL

 *steveL wrote:*   

> No s/he also in fact asserted that I am taking an "inflexible stance" in rejecting initramfs across the board which I never did. That is the strawman here, and you are merely repeating it, despite being told twice "no, that's not what I am saying".

 

 *khayyam wrote:*   

> steve ... no, that conflation begins with you, you move from "boot failure when using initramfs" to the whole question of separate /usr, and what "your told on the list [...] initramfs is the new root", etc, so you come down as practically dismissive of any suggestion of an initramfs being in any way useful.

 

That is pure inference on your part, and I have told you several times that it is incorrect. When will you simply accept my word that that is not what I am saying?

 *Quote:*   

> Additionally, when you return with your "I just don't see the point in pretending regressions are innovative progress", this is in reply to the following ... which you'd sniped:
> 
>  *tclover wrote:*   There are valid reasons... but I don't see a _valid_ to reject an initramfs as de facto (inflexible like) stance. I do understand why those who did _not_ need an initramfs took such an opposition to such matter/sabotage. 
> 
> To me that reads altogether different to an "assert[ion] that [you are] taking an "inflexible stance" in rejecting initramfs across the board"

 

Utter nonsense: that's exactly what s/he was getting at: you have reasons, but no reason "to reject an initramfs as de facto (inflexible like) stance". The clear implication is that I am taking an inflexible stance and it is unjustified.

Since I am not taking such a stance, the premise is flawed, so the conclusion is irrelevant.

 *steveL wrote:*   

> Since we've all agreed that there was no technical reason for the drop of support, despite the pretext of several being presented, it was a bad move. Period.
> 
> Now by all means move on: just don't pretend that issue has anything whatsoever to do with how we discussed things here, now.

 

 *Quote:*   

> ... but so does bad, or unintelligible, advice ...

 

I'm sorry you're having such trouble with reading comprehension. ;) Seems perfectly clear to me: how we discuss things here has got absolutely zero to do with the flawed, politically-driven decision. And that was the issue we were discussing: no-one's really that interested in meta-discussion.

----------

## greyspoke

WWWW - roll your own initramfs.  I am not a programmer, but I managed to do this (when I had a separate /usr) well enough to assemble arrays with mdadm, start lvm volumes and then mount and check /usr and /var with some basic shell scripting.

It is explained pretty well on the wiki:  https://wiki.gentoo.org/wiki/Custom_Initramfs

----------

## khayyam

 *steveL wrote:*   

>  *khayyam wrote:*    ... no, that conflation begins with you, you move from "boot failure when using initramfs" to the whole question of separate /usr, and what "your told on the list [...] initramfs is the new root", etc, so you come down as practically dismissive of any suggestion of an initramfs being in any way useful. 
> 
> That is pure inference on your part, and I have told you several times that it is incorrect. When will you simply accept my word that that is not what I am saying?

 

steve ... yes, inference ... derived from premises ... are you saying that without access to your inner thoughts that any such premises are false, and so I should simply accept your word on the matter?

 *steveL wrote:*   

>  *khayyam wrote:*   To me that reads altogether different to an "assert[ion] that [you are] taking an "inflexible stance" in rejecting initramfs across the board" 
> 
> Utter nonsense: that's exactly what s/he was getting at: you have reasons, but no reason "to reject an initramfs as de facto (inflexible like) stance". The clear implication is that I am taking an inflexible stance and it is unjustified.

 

There is such a thing as generosity of interpretation, and no I simply do not see such a "clear implication", but then my focus is on the context, whereas you seem to focused entirely on the "implied" meaning of that one sentence. 

 *steveL wrote:*   

> Since I am not taking such a stance, the premise is flawed, so the conclusion is irrelevant.

 

Way to fail at logic ... your "stance" in relation to a request re "boot failure when using initramfs" is to offload on the questioner the grievances WRT separate /usr, "unpleasantly-enforced monoculture", etc, etc ... basically acting rather unpleasant ... when the poster then says (to paraphrase) "there are valid reasons ... I don't see any reason to reject it outright" you take this as 1). "falsely" accusing you of some position you don't hold 2). providing something you can justly respond to ... and so bring in another clang of "regression" a la separate /usr ... and 3). further your stance in regard to the whole question ... "as usual, everyone focuses on the people discussing the issue, rather than the actual issue" ... the "actual" issue being whatever you happen to want the issue to be. When I draw your attention to this you claim this is misrepresentation, spin, and I can't possibly know what you really meant so I should take your word on the matter. In short, I should ignore the context and any possibility of deriving premises from that context.   

 *steveL wrote:*   

> I'm sorry you're having such trouble with reading comprehension. ;) Seems perfectly clear to me: how we discuss things here has got absolutely zero to do with the flawed, politically-driven decision. And that was the issue we were discussing: no-one's really that interested in meta-discussion.

 

I still say that particular sentence is incomprehensible, anyhow, shame that the post in question has nothing whatsoever to do with the issue "we" are discussing ... but then it seems that you've decided what is, and what isn't, "meta" to your discussion.

best ... khay

----------

## steveL

@khayyam: I don't know why you're taking this so personally, nor indeed accusing me of all kinds of stuff. You seem to want to hold me to some artificial standard of conduct no-one else has to follow. My replies must be tailored to exactly what the other party has said, and I am not allowed to go off on a tangent, or if I do, I must be admonished about it over several posts, none of which acknowledge my right to do exactly that.

And it's not like you don't go off on tangents (sometimes massively so); but somehow if I state that the one thing we seem to get with consistency from the nub-skool is regression, that must be "aggression" on my part, and I must be dragged over the coals for it. Just for the record, I wasn't being aggressive; and you cannot possibly know what tone I am taking since this is non-verbal. So please, let it go.

Or don't; either way I'm out of this sub-thread as it is both tedious and futile. I'm sorry you're evidently so stressed-out atm.

All I'd say is: as usual people are trying to turn the spotlight on to the person discussing the flaw, rather than simply discussing the flaw, and moving on. Dunno if that's cognitive dissonance or what; all I know is it's both very unpleasant, and nothing I want to emulate. Ever.

----------

## Naib

v3 is out 

http://lkml.iu.edu/hypermail/linux/kernel/1501.2/00487.html

----------

## Anon-E-moose

 *Naib wrote:*   

> v3 is out 
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1501.2/00487.html

 

Maybe by v50 or so they'll get it right   :Laughing: 

----------

## Shamus397

Bleah.

 *Theodore T'so wrote:*   

> I have to agree with Michael here; it's really, **really** disengenuous to say that that if you don't want kdbus, you can just #ifconfig it out. The fact that it systemd will be using it means that it will very shortly become a core kernel feature which is absolutely mandatory. Sure, maybe it can be configured out for "tiny kernels", just as in theory we can configure out the VM system for really tiny embedded systems. But we should be treating this as something that is not optional, because the reality is that's the way it's going to be in very short order.

 

Seen here.

----------

## Anon-E-moose

It seems like they're still not having easy sailing, getting through the kernel dev (well, except for GKH   :Rolling Eyes:  )

I would like to see it's status be like reiser4, if you want it get the patches and apply them, 

but when something breaks in the kernel because of it, don't come and yell at the kernel devs.

----------

## depontius

 *Anon-E-moose wrote:*   

> It seems like they're still not having easy sailing, getting through the kernel dev (well, except for GKH   )
> 
> I would like to see it's status be like reiser4, if you want it get the patches and apply them, 
> 
> but when something breaks in the kernel because of it, don't come and yell at the kernel devs.

 

Remember the old proverb, "Be careful what you ask for, because you may get it."  Did we really want World Domination?  That meant a massive influx of Windows users and developers, and that has brought us to systemd.  I've been coming to the opinion that any significant / rapid growth was going to do something like this.  The old guard is just too small to educate all of the newcomers, especially the incoming developers, fast enough.

What will be interesting will be the dynamics of the old-guard non-systemd distributions over time, and how they relate to the systemd distributions.  I've seen signs that more of the old guard are waking to this, and are if not as strident about it as some here, certainly as firm.  The interesting thing to watch will be the server market, where the old guard has tended to work.

----------

## Ant P.

World domination = monoculture = bad. No, I don't want that.

But we don't need to worry about that happening in RedHat's brave new world — their OS software stack has no user-serviceable parts inside and the GUI is a bad knockoff of OS X; if GNOME3 ever got a marketshare that mattered, they'd be nuked into oblivion by Apple's lawyers while their snubbed ex-users break out a set of World's Smallest Violins.

----------

## depontius

 *Ant P. wrote:*   

> World domination = monoculture = bad. No, I don't want that.

 

World Domination has been an ongoing goal/joke for some time now, even Linus has used it.

 *Ant P. wrote:*   

> ... their OS software stack has no user-serviceable parts inside and the GUI is a bad knockoff of OS X

 

Windows users don't generally want user-servicable parts inside - they're used to not having or needing them anyway.  To be fair, Linux hasn't done the best job of having user-servicable parts, either.  Default configurations tend to be incomplete or have other problems, and it frequently seems that "user-servicable" means that "user MUST service" parts inside.  (Example...  If dmix had shipped with better defaults and perhaps a GUI configuration tool, pulseaudio might never have gotten off the ground, much less survived past its first horrible incarnation.)  (Alternate example, XOrg has done a really good job of working out-of-the-box, but leaving the ability to tweak intact.)  

As for "bad knockoff of OS/X", some call Windows that, anyway.

----------

## depontius

The kdbus 3.0 inclusion debate continues, and an interesting turn has emerged.  The kdbus developers have considered it to be an add-on, and were therefore seeking to use ioctl() calls to run it.  One of the major characters on this round sees that kdbus will likely quickly become a non-optional (or normally-required) core part, and therefore should have syscalls instead of ioctl() calls.

In that light, syscall APIs are generally much more carefully scrutnized for proper definition.  A decent pointer into the discussion:

https://lkml.org/lkml/2015/1/22/180

----------

## steveL

 *depontius wrote:*   

> In that light, syscall APIs are generally much more carefully scrutinized for proper definition.  A decent pointer into the discussion:
> 
> https://lkml.org/lkml/2015/1/22/180

 

Interesting thanks for the link. I found this a bit worrying:  *Michael Kerrisk wrote:*   

> the API is so big and hard to grok that it's hard to even begin to work out what's missing from the documentation.

 

That just says to me that it's ill-conceived. What we want is something like LADSPA, that does not sprawl.

As for this:  *David Herrmann wrote:*   

> We know, that our API will not be perfect, none is. But we will try hard to fix anything that comes up, as long as we can. And this effort will manifest in ABI-breaks.

 

No. You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped. 

That's why you do things in userland instead, and even there people use simple APIs like LADSPA, and hide the complexity instead of exposing everyone to it, as if that were clever instead of dumb.

I don't see this going well, given the encouraging noises being made toward the kdbus "developers".

Though again, we should be using TIPC.

----------

## Anon-E-moose

 *steveL wrote:*   

> As for this:  *David Herrmann wrote:*   We know, that our API will not be perfect, none is. But we will try hard to fix anything that comes up, as long as we can. And this effort will manifest in ABI-breaks. 
> 
> No. You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped. 

 

I know that Linus has made that clear many times before.

Just because they wrote kdbus it doesn't mean they get a free hand in doing whatever they want, when and if it gets included into the mainline kernel. If it has warts then it will have warts the rest of it's life.

----------

## Anon-E-moose

This just makes me want to shake my head

 *Quote:*   

> The fact that there is no performance-critical application using DBus
> 
> is, imho, an argument *pro* kdbus. People haven't been capable of
> 
> making classic dbus1 fast enough for low-latency audio, thus, we
> ...

 

What the hell is dbus being used for "audio". Use your bastard child pulseaudio

 *Quote:*   

> Starting up 'gdm' sends ~5k dbus messages on my machine. It takes >1s
> 
> to transmit the messages alone. Each dbus1 message has to be copied 4
> 
> times for each direction. 

 

This is just insane, 5k messages...for "gdm", and multiple copying of the messages.   :Rolling Eyes: 

Sounds like an ill thought out design (dbus).

Design it right and then there probably won't be a need for kdbus to speed it up  :Rolling Eyes: 

----------

## ct85711

I find this funny, that someone would assume that a group that has no clue what they are doing in linux pick DBUS for a good reason.  This is going over the part of where the automotive group's software supposedly sends over 500k messages through dbus.  If that group actualy knew what they were doing, after seeing dbus being so crappy and slow, they would have switched away from dbus where they would of had this problem.

http://lkml.iu.edu/hypermail/linux/kernel/1501.2/02263.html

 *Greg Kroah-Hartman  wrote:*   

> I tend to trust that they knew what they were doing, they wouldn't have
> 
> picked D-Bus for no good reason.

 

I liked Johannes Stezenbach responce (on next msg in the thread) in what the automative group actually would do.

 *Quote:*   

> The automotive developers I had the pleasure to work with would
> 
> use anything which is available via a mouse click in the
> 
> commercial Embedded Linux SDK IDE of their choice 

 

----------

## steveL

 *YDIW wrote:*   

> The fact that there is no performance-critical application using DBus is, imho, an argument *pro* kdbus.
> 
> People haven't been capable of making classic dbus1 fast enough for low-latency audio, thus, we present kdbus.

 

 *Anon-E-moose wrote:*   

> This just makes me want to shake my head.
> 
> What the hell is dbus being used for "audio".

 

Yeah that's just dumbass, pure and simple. Use jack ffs.

Separate control from data, and put control down a reliable channel like message queues, which allow you to launch a thread when a message arrives on an empty queue, with no thread waiting to service the request, as well as to prioritise should the application need it.

 *Quote:*   

> Use your bastard child pulseaudio

 

Lul. "You couldn't do audio right, so now you want to shove it in the kernel instead?" Same as the rest..

 *YDIW wrote:*   

> Starting up 'gdm' sends ~5k dbus messages on my machine.
> 
> It takes >1s to transmit the messages alone.
> 
> Each dbus1 message has to be copied 4 times for each direction. 

 

 *Quote:*   

> This is just insane, 5k messages...for "gdm", and multiple copying of the messages.
> 
> Sounds like an ill thought out design (dbus).
> 
> Design it right and then there probably won't be a need for kdbus to speed it up

 

Absolutely. That's just nuts.

From the school of YDIW.. no thanks.

----------

## depontius

 *steveL wrote:*   

> 
> 
> As for this:  *David Herrmann wrote:*   We know, that our API will not be perfect, none is. But we will try hard to fix anything that comes up, as long as we can. And this effort will manifest in ABI-breaks. 
> 
> No. You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped. 
> ...

 

It's clear that Linus doesn't care about userspace much, as shown by his easy acceptance of systemd.  He has also made some of the "World Domination" remarks from time to time, and may well see the linkage between systemd and that.  Now with kdbus, systemd is about to hit him where he lives.

A few weeks back when I finally got around to removing *kit from my own system I also set USE="-dbus", then put entries in package.use as needed, though I may revisit this at some point and try harder to get rid of it.  In the meantime I'm barely dependent on it.  (This has prompted me to look harder att his topic - I really rather like "notification", which is probably what now drives dbu for me, and may be an acceptable use/role for it.)

Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.  (Hot chocolate and an added blanket might be more appropriate for this time of year.)  I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel.

----------

## tclover

 *depontius wrote:*   

> A few weeks back when I finally got around to removing *kit from my own system I also set USE="-dbus", then put entries in package.use as needed, though I may revisit this at some point and try harder to get rid of it.  In the meantime I'm barely dependent on it.  (This has prompted me to look harder att his topic - I really rather like "notification", which is probably what now drives dbu for me, and may be an acceptable use/role for it.)

 

Exactly! ... barely depending on it for... guess... JACK: *notification* to start a server when need be. I don't usually start JACK server myself, even if I could do it manually and simply. I just leave it to LADI to handle it when need be: start a particular studio with clients & connect clients to the server in a portable manner... JACK died? restart the same studio with the client connections and possibly new client connections not saved in the *studio*. Can you imagine that pain in the arse to do this kind of repetitive task again and again? I'd rather use my sparse time for meaningful things instead. Barely depending on it for this particular usage... and barely stand it for its cluster fuck & buggy implementation. Checkout this hilarious post (Patrick's Playground Blog): http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt

So, I am curious to see what the kernel maintainers would threw at it and what the kDbus folks will do.

I am not in the least interested in the 5K gdm's start up message madness... but having a sane/simple & low latency implementation IPC (--I realize that, this is not exactly their plan, but the review could do something... maybe I am wishing too much--) would surely serves something... like getting rid of D-Bus. It's feel like a cat bitting its tails, right? Anyway, I am following the review.

I could go on in a similar manner for udev. I can pretty much manage quick migration with mdev, and this might necessary in a near future rather than later because eudev is not so much of a fork... with lack of dev manpower. But, I still need device hotplug in X session. LVM2 (hard) dependency is not an issue... could get rid of it completely with GPT partitioned disks. 

 *depontius wrote:*   

> Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.  (Hot chocolate and an added blanket might be more appropriate for this time of year.)  I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel.

 

Sure... funny times awaits the more adventurous ones... right? Well, maybe not with such people & methodology.

----------

## depontius

 *tclover wrote:*   

> 
> 
>  *depontius wrote:*   Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.  (Hot chocolate and an added blanket might be more appropriate for this time of year.)  I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel. 
> 
> Sure... funny times awaits the more adventurous ones... right? Well, maybe not with such people & methodology.

 

I'm more thinking of watching the sparks once it become apparent that the kdbus developers want to churn the design in-kernel.  In the discussion thread we've been watching, they just stated that as an express reason why they went for ioctl instead of syscall.  They plan on churning kdbus.  I'm sure that one will sit well.  The question will be whether Linus has noticed that comment before first inclusion, or if the fight happens when the churn starts.

----------

## tclover

 *depontius wrote:*   

> I'm more thinking of watching the sparks once it become apparent that the kdbus developers want to churn the design in-kernel.  In the discussion thread we've been watching, they just stated that as an express reason why they went for ioctl instead of syscall.  They plan on churning kdbus.  I'm sure that one will sit well.  The question will be whether Linus has noticed that comment before first inclusion, or if the fight happens when the churn starts.

 

Maybe not... but he should now. The guy who tried to justify the choice ioctl vs. syscal just kept throwing random stuff after another without providing any _real_ logical reasons to do so... but "we're doing this way... (wait why already? somebody noticed... wait)". Well, let's hope nobody followed this one.

----------

## Anon-E-moose

This particular person seems to be taking them to task, so to speak over the design.

 *Quote:*   

> So, I'm thinking about things such as the following:
> 
> * The odd choice of ioctl() as the API mechanism for what should become
> 
> a key user-space API. (BTW, which other widely used IPC API ever
> ...

 

http://lkml.iu.edu/hypermail/linux/kernel/1501.2/05080.html

Edit to add: GKH seems to have gotten hurt feelings  here http://lkml.iu.edu/hypermail/linux/kernel/1501.2/05249.html  :Rolling Eyes: 

Quite frankly I still wonder what his payoff will be for getting kdbus into the kernel.

----------

## depontius

 *Anon-E-moose wrote:*   

> This particular person seems to be taking them to task, so to speak over the design.
> 
>  *Quote:*   So, I'm thinking about things such as the following:
> 
> * The odd choice of ioctl() as the API mechanism for what should become
> ...

 

The guy who has been doing most of the challenging is a name I don't recognize, not that I recognize very many.  Ted Tso did make one comment in the thread, to the tune that this is going to be a mainstream API, kind of shooting a hole in the ioctl() justification.

As for Greg KH having hurt feelings :

http://cs.boisestate.edu/~amit/teaching/552/old/handouts/ols_2006_keynote_files/ols_2006_keynote_21.jpg

----------

## Anon-E-moose

LoL

And to add, GKH says that the kdbus devs know what they're doing as they've been at it for 2+ years.

Well, in the world I'm from, constantly changing api's doesn't give a warm fuzzy that they know that they're doing.

And we're seeing justifications all over the place for it, from audio usage to multi kilo messages to well that's the way we designed it, tuff.

They are not going to be able to churn the code if and when it gets included in the kernel, they better think it out properly first.

----------

## khayyam

 *depontius wrote:*   

> Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.

 

depontius ... that depends on who's driving the train :)

best ... khay

----------

## steveL

 *steveL wrote:*   

> You do not break userland. More generally, your consumer, but once an ABI is in the kernel it cannot be dropped.

 

 *depontius wrote:*   

> It's clear that Linus doesn't care about userspace much, as shown by his easy acceptance of systemd.  He has also made some of the "World Domination" remarks from time to time, and may well see the linkage between systemd and that.  Now with kdbus, systemd is about to hit him where he lives.
> 
> I believe Linus' easy acceptance of systemd is about to get challenged as they try to shove not just their code, but their methodology and philosophy, into the kernel.

 

Well there's two strands there. I don't expect Torvalds to care about userspace; he's not meant to. He's supposed to stick with the attitude that it can do all kinds of crazy things, as that's the only way for a kernel-side coder to think.

As such he might tut from time to time when he comes up for air, but it's not his problem (and we don't him to lose his focus on the kernel.)

Except as you say, when changes are being pushed into the kernel (the second strand) to paper over userland madness, instead of telling userland to go back to the drawing-board.

 *Quote:*   

> A few weeks back when I finally got around to removing *kit from my own system I also set USE="-dbus", then put entries in package.use as needed, though I may revisit this at some point and try harder to get rid of it.  In the meantime I'm barely dependent on it.  (This has prompted me to look harder att his topic - I really rather like "notification", which is probably what now drives dbu for me, and may be an acceptable use/role for it.)

 

Heh it's funny you should mention that, as I got to this page about inotify following links given above. I rather liked this comment (it made me smile;):

 *neilbrown  wrote:*   

> I wonder what other, possibly less common, use cases there are.
> 
> One of my favourites is as a publish/subscribe (aka 'multicast') IPC mechanism. It is a bit clunky, but it can be made to work.
> 
> Who needs dbus when you can muck about with files and dnotify :-)

  (or inotify, or fanotify? nowadays.)

I just like the idea of eg a simple file with the number of new emails (for instance) which we could watch for modification if we wanted to, a bit like we could watch a /proc directory or file.

At least for the simple cases, keep them simple.

 *depontius wrote:*   

> Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show.  (Hot chocolate and an added blanket might be more appropriate for this time of year.)

 

Hehe indeed. Though it's also nice to get into the technical stuff as a downtime thing. The other comments on that page are quite interesting, for instance:

 *wahern wrote:*   

> With kqueue+EVFILT_VNODE you never have to worry about overflow because the kernel always has a place to store the event.
> 
> .. OS X Finder does just fine with EVFILT_VNODE. And OS X has the O_EVTONLY descriptor flag, which permits the kernel to unmount volumes with open descriptors.

 

The latter sounds useful, and one wonders why we can't do the same thing; after all the kernel must know what the fd is for.

Though by the sound of it, you're exploring the options for a dbus-free system much more intensely than most, already :)

Have you tried installing the TIPC kernel module? Just wondering how difficult it is to get that running, even if nothing's actually using it yet, for a testbed. (According to the site, it's part of kernel sources since Linux 2.6.39+, though the utils are downloaded from there.) I really must set aside a couple of days to getting up to date..

Have to say I'm quite impressed, checking out the programming docs, and the draft protocol. The former is loverly, lucid and to the point, and I especially like the tips and caveats ("THINGS TO NOTE" and "THINGS TO REMEMBER"), the latter from a higher-level design view.

TIPC goes back over 15 years, and is still being updated, so it's a live project, and an excellent candidate afaic.

Still, time for some lemonade.. ;-)

----------

## khayyam

 *tclover wrote:*   

> [...] I can pretty much manage quick migration with mdev, and this might necessary in a near future rather than later because eudev is not so much of a fork... with lack of dev manpower. But, I still need device hotplug in X session.

 

tclover ... device hotplugging does in fact work with mdev, mdev can be configured to react to events and so setup usb devices, etc, so for example:

/etc/mdev.conf

```
SUBSYSTEM=usb;DEVTYPE=usb_device;.* root:root 660 */opt/mdev/helpers/proc-bus-usb
```

/etc/X11/xorg.conf.d/30-mouse.conf

```
[...]

  # /dev/input/mice will provide support for hotpluging mouse.

  # Without the need to restart X server.

  option  "device"  "/dev/input/mice"

[...]
```

The only real issue that anyone might have with dbus removal is the hard dependencies of DE's and/or their expectation that the dbus service will be running (ie, when using consolekit). If you're not using a DE, consolekit, etc, then its quite easy to have everything work without dbus ... well, you have to wrangle with useflags, and setup xorg without evdev, but its fairly simple to do so.

 *steveL wrote:*   

> Though by the sound of it, you're exploring the options for a dbus-free system much more intensely than most, already :)

 

What's dbus? :)

```
# qlop --gauge dbus | echo $?

0
```

best ... khay

----------

## tclover

Thanks steveL for...

```
# CONFIG_TIPC is not set
```

I did not know that such an (in-kernel) IPC was available till your previous post about it.

(Could somebody give an overview (short or _high_ level) of it regarding perf/latency/message compared to the infamous D-Bus?

Just asking... because I happen to have requested multiple times "why depending on D-Bus at all?" on a few things I use. And then... "we need an IPC in order to set up a communication between processes and be able to control... & provide functionalities if _this_ or _that_ service is available; and do not want waste ridiculous amount of time doing a _custom_ IPC." No viable alternative to suggest? Well then... D-Bus then.)

EDIT: Anybody noticed this: nobody mentioned TIPC on the review? or did I miss it?

----------

## Anon-E-moose

 *khayyam wrote:*   

>  *depontius wrote:*   Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show. 
> 
> depontius ... that depends on who's driving the train 
> 
> best ... khay

 

I read that yesterday, and just shook my head

 *Quote:*   

> In the end, all is well, and I'm still confused why writing a config file needs dbus and xml and stuff.

 

It shouldn't need dbus or xml, but that's stuff being driven by...tada...RH

 *Quote:*   

> But I guess that's called progress ... 

 

Yeah   :Rolling Eyes:  progress

Re: dbus

I don't have it installed on my system, and don't need it. 

Of course I'm running openbox not a full de, but even when I was running lxde I had it turned off.

I don't need notifications.

----------

## depontius

 *khayyam wrote:*   

>  *depontius wrote:*   Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show. 
> 
> depontius ... that depends on who's driving the train 
> 
> best ... khay

 

I just noticed - that was supposed to be "a train wreck might", not "a train might".  Oops.

----------

## khayyam

 *Anon-E-moose wrote:*   

>  *khayyam wrote:*    *depontius wrote:*   Sometimes the best attitude toward a train might just be to get out a folding chair, a tall glass of icy lemonade, and watch the show. 
> 
> that depends on who's driving the train :) 
> 
> I read that yesterday, and just shook my head

 

Anon ... when I read it I spilt my lemonade :)

 *Anon-E-moose wrote:*   

>  *bonsaikitten wrote:*   In the end, all is well, and I'm still confused why writing a config file needs dbus and xml and stuff. 
> 
> It shouldn't need dbus or xml, but that's stuff being driven by...tada...RH

 

"Confused? You won't be, after this week's episode of ... Soap."

best ... khayLast edited by khayyam on Sat Jan 24, 2015 12:07 pm; edited 3 times in total

----------

## tclover

 *khayyam wrote:*   

> tclover ... device hotplugging does in fact work with mdev, mdev can be configured to react to events and so setup usb devices, etc, (...)
> 
> The only real issue that anyone might have with dbus removal is the hard dependencies of DE's and/or their expectation that the dbus service will be running (ie, when using consolekit). If you're not using a DE, consolekit, etc, then its quite easy to have everything work without dbus ... well, you have to wrangle with useflags, and setup xorg without evdev, but its fairly simple to do so.
> 
> (...)

 

I was not _implying_ device hotplug in general but _only_ with X _itself_ with evdev(--I am aware of mdev device _hotplug_); nor implying D-Bus dependency in general,--because, as you're saying, a D-Bus free OS is manageable,--Well, depends on the usage/requirements, as said above, and as you're saying--DE or no DE environment.

----------

## Anon-E-moose

evdev doesn't require dbus, but does require some variant of *udev, not sure if mdev works with it or not, maybe khayyam knows.

----------

## khayyam

 *Anon-E-moose wrote:*   

> evdev doesn't require dbus, but does require some variant of *udev, not sure if mdev works with it or not, maybe khayyam knows.

 

Anon ... evdev uses {e,}udev (exclusively) ... its not possible to have INPUT_DEVICES="evdev" set for xorg if {e,}udev isn't installed, and running, on the system ... so, mdev doesn't suffice.

best ... khay

----------

## depontius

An amusing thought...

I strongly suspect that dbus or libdbus is going to go virtual in the next few months.  Eventually kdbus will most likely make it into the kernel, and hilarity will ensue as the stable-API fights begin.  However there will come a time when there are firm users for both userspace and kernel dbus.  After a brief peek, probably both dbus and libdbus are going to have to go virtual.  (Some stuff uses the lib, some talks directly.)

They're not going to manage an overnight conversion getting the whole world to move from userspace to kernel dbus, no matter what night they pick.  It just isn't going to happen that way, no matter how hard anyone holds their breath, whines, criticizes others for being laggards or haters.  It's logistically impossible.

So if dbus and libdbus are virtual, how about adding a third implementation, maybe even using cleaner plumbing?  Perhaps TIPC?  I know it might be called misuse, but I suspect it would still be an improvement.

I'm stuck.  I mentioned before that I like X notifications, and had dbus pretty well out of my system except for that.  I forgot about one other thing, and there may be a few more.  I've got over a decade of finances in gnucash.

Looks like gnucash requires libsecret, which requires gnome-keyring, which requires dbus.  I'm stuck with dbus, as long as my money is stuck inside gnucash.

I have no idea how difficult a task it would be, making an alternative implementation of dbus based on say, TIPC.  Today when I did my upgrades and got 3.18.3, I went ahead and added TIPC as a module, so I'm at least ready to investigate.

I wonder how much of the current performance problems of dbus are because they keep passing around "freedesktop.org" (or is that "org.freedesktop"?) perhaps multiple times with every message.  EDIT - That's a joke, if it wasn't obvious.

----------

## gwr

 *depontius wrote:*   

> 
> 
> Looks like gnucash requires libsecret, which requires gnome-keyring, which requires dbus.  I'm stuck with dbus, as long as my money is stuck inside gnucash.
> 
> 

 

Sigh. This is what happens when we depend on middleware to use services on a local machine. Zero advantage and downsides too numerous to bother listing.

My computer is not the Internet. I don't want Internet solutions to trivial problems. Silicon Valley is responsible for breeding this Web-fad nonsense and now I need middleware to encrypt something.

----------

## steveL

 *tclover wrote:*   

> Thanks steveL for...
> 
> ```
> # CONFIG_TIPC is not set
> ```
> ...

 

You're more than welcome. :)

Not sure about performance and latency comparison, but this post ties together an overview, and links to the previous discussion with kernel-folks about it (the "we tried to talk to the networking folks, but they shot us down" discussion occasionally referred to as 'justification' for "so can we haz kdbus?")

Someone linked us to a page about performance of dbus vs dcop and orbit as well, where dbus was the slowest of all three, and GNOME's CORBA impl was the fastest, by far. DCOP was lovely and dbus is a shoddy replacement afaic, especially based on the amount of scripting there was for DCOP, and simply does not happen for dbus.

 *Quote:*   

> Just asking... because I happen to have requested multiple times "why depending on D-Bus at all?" on a few things I use. And then... "we need an IPC in order to set up a communication between processes and be able to control... & provide functionalities if _this_ or _that_ service is available; and do not want waste ridiculous amount of time doing a _custom_ IPC." No viable alternative to suggest? Well then... D-Bus then.)

 

There's so many things wrong with that objection; it sounds to me like someone who simply does not know the existing interfaces. Arguing that using one of the N variants of IPC provided, is "custom" is simply nub.

Mind, I'm all for an easy-ipc lib; I just think it's only interesting if the admin can configure it, similarly to /etc/services, on a domain-specific basis. Other than that, the programmer should know how to use the standard APIs already, or they're wet behind the ears.

 *Quote:*   

> Anybody noticed this: nobody mentioned TIPC on the review? or did I miss it?

 

I haven't seen it, but I imagine they'd simply be told "we talked to the networking folk before" without ofc mentioning that they didn't listen to a bloody word. (See the post a couple up from the linked one, to see what I mean.)

I'd love to see a DCOP-style interface on top of TIPC, and would be happy to put some code-time into helping out with it, for one.

(So long as we're not using C++ ;)

----------

## khayyam

 *gwr wrote:*   

>  *depontius wrote:*   Looks like gnucash requires libsecret, which requires gnome-keyring, which requires dbus.  I'm stuck with dbus, as long as my money is stuck inside gnucash. 
> 
> Sigh. This is what happens when we depend on middleware to use services on a local machine.

 

gwr ... services? nay, "protocol stacks" ...

```
% equery -NC depgraph -l =net-wireless/bluez-5.2

 * Searching for bluez5.25 in net-wireless ...

 * dependency graph for net-wireless/bluez-5.25

 [  0]  net-wireless/bluez-5.25  x86 

 [  1]  dev-libs/glib-2.40.2  (>=dev-libs/glib-2.28) x86 

 [  1]  sys-apps/dbus-1.8.10  (>=sys-apps/dbus-1.6) x86 

 [  1]  sys-apps/hwids-20141010  (>=sys-apps/hwids-20121202.2) x86 

 [  1]  net-print/cups-1.7.5  (net-print/cups) x86 

 [  1]  dev-libs/libical-0.48-r2  (dev-libs/libical) x86 

 [  1]  sys-libs/readline-6.2_p5-r1  (sys-libs/readline) x86 

 [  1]  sys-apps/systemd-9999  (sys-apps/systemd) M[package.mask] 

 [  1]  virtual/udev-215  (>=virtual/udev-172) x86 

 [  1]  virtual/pkgconfig-0-r1  (virtual/pkgconfig) ~x86 

 [  1]  dev-lang/python-2.7.9-r1  (>=dev-lang/python-2.7.5-r2) x86 

 [  1]  dev-lang/python-3.4.2  (dev-lang/python) M[package.mask] 

 [  1]  dev-lang/python-3.3.5-r1  (>=dev-lang/python-3.3.2-r2) M[package.mask] 

 [  1]  dev-python/dbus-python-1.2.0-r1  (>=dev-python/dbus-python-1) x86 

 [  1]  dev-python/pygobject-2.28.6-r55  (dev-python/pygobject) x86 

 [  1]  dev-python/pygobject-3.12.2  (dev-python/pygobject) x86 

 [  1]  sys-devel/automake-1.13.4  (>=sys-devel/automake-1.13) x86 

 [  1]  sys-devel/automake-1.15  (>=sys-devel/automake-1.15) [~x86 keyword] 

 [  1]  sys-devel/autoconf-2.69  (>=sys-devel/autoconf-2.69) x86 

 [  1]  sys-devel/libtool-2.4.2-r1  (>=sys-devel/libtool-2.4) x86 

[ net-wireless/bluez-5.25 stats: packages (20), max depth (1) ]
```

hehe ... "standard socket interface to all layers".

best ... khay

----------

## gwr

 *khayyam wrote:*   

> 
> 
> gwr ... services? nay, "protocol stacks" ...
> 
> 

 

That just makes me sad.

----------

## depontius

 *khayyam wrote:*   

> 
> 
> ```
> % equery -NC depgraph -l =net-wireless/bluez-5.2
> 
> ...

 

But from the bluez page you referenced...

"The BlueZ kernel modules, libraries and utilities are known to be working prefect on many architectures supported by Linux."

It's working prefect.  (Cheap shot, I know.  My wife is into language, annoyed by misuse, and sometimes it rubs off on me.)  ("loose" instead of "lose" gets to me too, because of how common it seems to be.)

----------

## khayyam

 *depontius wrote:*   

> It's working prefect.

 

depontius ... which makes prefect sense ... its was *already* prefected before it was "working" :)

best ... khay

----------

## depontius

On a more serious note...  I want a shim.  I want a way out of dbus-dependence.  I didn't know better when I started using it, but I do now, and I'm trapped.

(This is why I think that at the right point, shims for systemd-* might be a very good idea.)

1 - Unknowingly using bad software.

2 - Use shim to stop using that bad software.

3 - (minor miracle)

4 - Do things the right way.

----------

## khayyam

 *depontius wrote:*   

> On a more serious note...  I want a shim. I want a way out of dbus-dependence.  I didn't know better when I started using it, but I do now, and I'm trapped.

 

depontius ... I think most everyone is going to disagree with you on this (again), myself included. I won't go over old ground, but I don't think shims will make a blind bit of difference. I'm inclined to think you'll get your wish ... but it'll be more of the same, and further testament to the depths of the problem.

best ... khay

----------

## tclover

 *depontius wrote:*   

> So if dbus and libdbus are virtual, how about adding a third implementation, maybe even using cleaner plumbing?  Perhaps TIPC?  I know it might be called misuse, but I suspect it would still be an improvement.

 

This is just... a wild guess--you should take a look on TIPC before talking about it being a valid alternative. I've took a quick look and it seems it's based on TCP (and connection communication friendly) and then share the sames caveats: no way to make a low latency, multicast IPC out from it... no idea on perf side. (I gave up on the introduction because of its complexities... it's almost seem more complicated than kDbus on first glance... and kDbus might have a chance with the new filesystem implementation: domain = mount point; bus = directory; conection = file inside a bus... I just get bored and stopped reading kdbus.text compared to... well, you know what I mean.

 *depontius wrote:*   

> I'm stuck.  I mentioned before that I like X notifications, and had dbus pretty well out of my system except for that.  I forgot about one other thing, and there may be a few more.  I've got over a decade of finances in gnucash.

 

Depending on anyting depending on gnome-keyring is crazy: that thing brings too many GNOME/SystemD OS bloat/crap.

EDIT: multicast (above): refer to the ability to send a message to a bus with broadcast option--client subscribed to broadcast receive it--for kDbus; and multicast in TIPC... a client has to send the message to _each_ client (in which case, the client shoud have an opened communication to/from _each_ client.) Which way is easier (app side)? ... the latter require the apps managing too many connections to other client; and the former requires only a single connection to a bus.

EDIT2: Thanks to SteveL for that overview... so the previous EDIT should be alleviated in regard of what TIPC offer to subscribe to service (port name.) Now, why is D-Bus so popular when a _better_ alternative is there? (Well, TIPC seems complicated... but even then D-Bus is worse with a no workable known API.)

----------

## steveL

 *tclover wrote:*   

> This is just... a wild guess--you should take a look on TIPC before talking about it being a valid alternative. I've took a quick look and it seems it's based on TCP (and connection communication friendly) and then share the sames caveats: no way to make a low latency IPC out from it... no idea on perf side.

 

Huh? What do you base that on?

The section on existing protocols specifically discusses TCP and why it's not so useful in the local context, similarly for SCTP. In a nutshell, they have to deal with situations that simply do not arise in a local cluster, nor indeed within a node.

So I cannot see what the above assertion is based on, at all. Sure, we don't need several layers from TIPC for a local-node setup, but that only means there's less to do at runtime, and less to worry about.

It certainly is not based on TCP, that I have read so far. The possibility of using TCP (or SCTP) as a bearer is another matter, akin to many other situations, like running ssh over TCP.

----------

## steveL

 *tclover wrote:*   

> EDIT: multicast (above): refer to the ability to send a message to a bus with broadcast option--client subscribed to broadcast receive it--for kDbus; and multicast in TIPC... a client has to send the message to _each_ client (in which case, the client shoud have an opened communication to/from _each_ client.) Which way is easier (app side)? ... the latter require the apps managing too many connections to other client; and the former requires only a single connection to a bus.

 

That's incorrect too; "multicast" in the TIPC spec refers to multicasting across nodes on the network (as this obviously requires more work on the part of the protocol stack.)

I put up in this post an extracted summary from Ying Zue's mail; this bit was cut out:

 *Ying Zue wrote:*   

> TIPC multicast mechanism is very useful for D-Bus. It has several cool and powerful special features:
> 
> 1. It can guarantee multicast messages are reliably delivered in order.
> 
> 2. It can support one-to-many and many-to-many real-time communication within node or network.
> ...

 

In this case, he's talking about multicasting to processes (clients, or ports), which is the dbus use-case.

For easy discussion purpose, this is the rest of what I'd extracted:

 *Ying Xue wrote:*   

> The basic unit of functional addressing within TIPC is the port name, which is typically denoted as {type,instance}. A port name consists of a 32-bit type field and a 32-bit instance field, both of which are chosen by the application.
> 
> Often, the type field indicates the class of service provided by the port, while the instance field can be used as a sub-class indicator. Further support for service partitioning is provided by an address type called port name sequence.
> 
> This is a three-integer structure defining a range of port names, i.e., a name type plus the lower and upper boundary of the instance range. This addressing schema is very useful for multicast communication.
> ...

 

So messages absolutely can be "multicast" in the dbus-sense of the word; it is in fact a lot easier.

Note I'm not saying it's all milk and honey, nor do I have any special expertise, and am making no claim to authority about any of this. I just think TIPC is a much saner basis.Last edited by steveL on Sun Jan 25, 2015 10:47 am; edited 1 time in total

----------

## tclover

 *steveL wrote:*   

>  *tclover wrote:*   This is just... a wild guess--you should take a look on TIPC before talking about it being a valid alternative. I've took a quick look and it seems it's based on TCP (and connection communication friendly) and then share the sames caveats: no way to make a low latency IPC out from it... no idea on perf side. 
> 
> Huh? What do you base that on?
> 
> (...)

 

 *http://tipc.sourceforge.net/doc/draft-spec-tipc-10.html#anchor4 wrote:*   

>  TCP [RFC0793] has the advantage of being ubiquitous, stable, and wellknown by most programmers. Its most significant shortcomings in a real-time cluster environment are the following:
> 
> *    It lacks any notion of service addressing and addressing transparency. Mechanisms exist (DNS, CORBA Naming Service) for transparent and dynamic lookup of the correct IP-adress of a destination, but those are in general too static and expensive to use.
> 
> *    TCP has non-optimal performance, especially for intra-node communication and for short messages in general. For intra-node communication there are other and more efficient mechanisms available, at least on Unix, but then the location of the destination process has to be assumed, and can not be changed. It is desirable to have a protocol working efficiently for both intra-node and inter-node messaging, without forcing the user to distinguish between these cases in his code.
> ...

 

(Trying to read other things... in the same time.)

----------

## steveL

Well thanks for quoting the part I referred to, as it shows you misread it.

Could have just said that, though, instead of presenting it as if it answered my point.

----------

## tclover

 *steveL wrote:*   

> (...)
> 
> Could have just said that, though, instead of presenting it as if it answered my point.

 

Indeed! Just, trying to make room for reading... and not to get lost.

EDIT: I see... I've read the ref. link to the reply of TIPC maintainer/author to "netdev" kernel mailing list... What a suprise! A 3 years old message with SystemD cabals & kDbus authors on the CC list. Now, somebody has to make the link between this old thread to the current kDbus review...

Thanks! (again)

----------

## steveL

No worries; sorry if I was a bit grumpy. I'd dug out info for you, and was feeling a bit put-upon. The drama ;-)

----------

## depontius

 *khayyam wrote:*   

>  *depontius wrote:*   On a more serious note...  I want a shim. I want a way out of dbus-dependence.  I didn't know better when I started using it, but I do now, and I'm trapped. 
> 
> depontius ... I think most everyone is going to disagree with you on this (again), myself included. I won't go over old ground, but I don't think shims will make a blind bit of difference. I'm inclined to think you'll get your wish ... but it'll be more of the same, and further testament to the depths of the problem.
> 
> best ... khay

 

I'm curious about this.  Previously I was suggesting shims as a migration path away from systemd-* interfaces.  However the general fear was that shims would legitimize those interfaces, rather than act as a path away.  I wasn't intending their use that way at all, but I'm a bit dismayed to see that as part of the Devuan announcement they're planning shims in precisely the way others feared, and not as I hoped.

However I believe the situation is different with dbus.  It is already an established, "legitimate" inteface, no matter how much several people here may dislike it.  A dbus shim would do nothing to legitimize it, and would pretty much only be the start of an escape path.

This weekend I also took a preliminary look at what it might take to make gnucash fork at libsecret.  I'm not using gnome-keyring anyway - in fact as far as I can tell the relevant directories were dangling symlinks left over from when I did a minor disk reorganization a year ago  (My /home is on nfsv4, but I also have a /local mounted on the machine - handy for firefox/thunderbird directories and their sqlite files.) and therefore impossible to use.

----------

## khayyam

 *depontius wrote:*   

>  *khayyam wrote:*    *depontius wrote:*   On a more serious note...  I want a shim. I want a way out of dbus-dependence.  I didn't know better when I started using it, but I do now, and I'm trapped. 
> 
> I think most everyone is going to disagree with you on this (again), myself included. I won't go over old ground, but I don't think shims will make a blind bit of difference. I'm inclined to think you'll get your wish ... but it'll be more of the same, and further testament to the depths of the problem. 
> 
> I'm curious about this.  Previously I was suggesting shims as a migration path away from systemd-* interfaces.  However the general fear was that shims would legitimize those interfaces, rather than act as a path away.

 

depontius ... its not a question of "legitimising" but complexity of design, its actually a lot more difficult to swim with (inflatable) arm-bands, or ride a bike with stabilisers, and they don't help particularly when try to learn how to do so (if anything they get in the way). They are adopted for other reasons (ie, safety, psychology, etc) but are more a hindrance than a help (the body is actually quiet buoyant in water, and momentum provides most of whats needed for balance). The problem with computers/software is that we've adopted arm-bands and stabilisers in the form of "usability" and it acts as a hindrance to use, because like arm-bands and stabilisers it don't actually help if we consider the environment computers provide (they are not brains that can magically understand the user, its the user that is in fact the interface). This is the primary conception of computing that has developed since the late 70's, everything is focused on the computer (which has no intelligence, it "computes", that is, undertakes repetitive tasks based on commands). This has lead us to where we are now, the demands of this metaphor now make all the "shims" (in the form of "usable interfaces") necessary for the computer to fulfil the role of a tool.  

I could go on ... but that's a general outline of how we come to have something like the userspace we have (so, gnucash depends on gnome-keychain depends on dbus, etc, etc).

best ... khay

----------

## depontius

 *khayyam wrote:*   

> 
> 
> I could go on ... but that's a general outline of how we come to have something like the userspace we have (so, gnucash depends on gnome-keychain depends on dbus, etc, etc).
> 
> best ... khay

 

I'm capable of being purist, but also know that I need to be practical at times, too.  From a practical side I see four options:

1 - Get my money out of gnucash and into something else - but what?

2 - Patch gnucash or libsecret to do away with gnome-keyring.

3 - Some sort of dbus shim.

4 - Just live with it, and ignore that fact that there's some ugly plumbing in there.

So right now I see two reasons I have dbus on my system - gnome-keyring and I like notifications.

I see what you said about the complexity problems with shims, but which of option #3 or #4 would you say is worse?

----------

## tclover

 *steveL wrote:*   

> Mind, I'm all for an easy-ipc lib; I just think it's only interesting if the admin can configure it, similarly to /etc/services, on a domain-specific basis. Other than that, the programmer should know how to use the standard APIs already, or they're wet behind the ears.

 

This shouldn't be difficult to implement with such an easy API... I remove the "difficult API" said previously! I second a lib for that kind of things... to give at least a "named service" (string) translated to a (TIPC) "named port" {TYPE,INSTANCE} (two 32-bits integer.) It will certainly help... What about a "bearer" (link) implementation?

I'm yet to finish reading the specs, but, so far so good. The API looks almost more easy to grasp... for even the "simpler" (than D-Bus) kDbus, minus the "bearer" link left to be implemented (which a TCP-like or not choice.) And the ZONE/CLUSTER/NODE address space & one-to-many(multicast+broadcast)/many-to-one/one-to-one(unicast (low latency)) make kDbus' domain/bus/connection counterpart... almost a toy.

(Some facts: kernel(good config)+JACK gives a ~20ms latency; or ~<10ms for RT kernel.)

Direct peer-to-peer (or one-to-one) communication (for low latency) on ~weak~ hardware achieve a ~100us for Round Trip Time (send+receive message) is not that bad... (The 4us of kDbus is not trustworthy considering the politics of systemD cabals.)

PS: I added net-misc/tipcutils-2.0.3 on my overlay (it has a cmdline utils for AF_TIPC ("ports") sockets creation compared to version 2.0.0 available in the official tree); and dev-perl/IO-Socket-TIPC in order to test a few things for those interested...

----------

## khayyam

 *depontius wrote:*   

> I'm capable of being purist, but also know that I need to be practical at times, too.  From a practical side I see four options:
> 
> 1 - Get my money out of gnucash and into something else - but what?
> 
> 2 - Patch gnucash or libsecret to do away with gnome-keyring.
> ...

 

depontius ... if I imagine the above as the options provided in some role play game then I'm to choose, but my choice is based on being a participant, I could have opted not to enter the kingdom of gnucash and instead entered the forest of sqlite ... it would then have been trivial to extract myself from the choices above and to build a raft to cross the stream of doo-doo. So, I read the above as an outcome, rather than something inevitable that I'm now forced to extricate myself from ... that's not about "purism", its about design ... and the point still stands, if you follow the logic of shims (be they dbus shims, interface shims, or whatever "stop gap" measures) then its this that creates the limits imposed by the above set of choices. You can say "that isn't practical" look at the current doo-doo I'm in ... but I'm still in the position to reflect on how you ended up there, and advise you not to build a platform on such a foundation so you can clean your boots :)

best ... khay

----------

## depontius

 *khayyam wrote:*   

> I could have opted not to enter the kingdom of gnucash and instead entered the forest of sqlite ... 

 

But sqlite is a lightweight database, not a double-entry ledge accounting system.  There's just a bit of difference.

OTOH, "grisb" is in portage, and it will read gnucash files - but it's not a double-entry ledger.  This pits financial goodness against computing goodness.  However grisb can export QIF and CSV, so it might end up being an export tool if I really need to get out of gnucash.

In the meantime, as mentioned before, I've determined that in my situation the gnome-keyring can't work, because it's directory was a dangling symlink, and I can certainly make it so, again.  Better yet, I can make it dangle into a place where as an ordinary user, I can't write, so it can't be automagically fixed by any sort of smart scripting.  In this way, it's just dead, useless code.  I have to think through if there is any possible exposure, here.

Come to think of it, given that I've been running for years with an impossible-to-work gnome-keyring, maybe the best shim of all is a dead shim.  Maybe that's what I want to add - a way to close the hole caused by an unused feature.

----------

## khayyam

 *depontius wrote:*   

>  *khayyam wrote:*   I could have opted not to enter the kingdom of gnucash and instead entered the forest of sqlite ...  
> 
> But sqlite is a lightweight database, not a double-entry ledge accounting system.  There's just a bit of difference.

 

depontius ... that's not the point though, the point is "design", and where that design will lead (dead ends, or what-have-you). Now, unless you are saying that its impossible to make a "double-entry ledge accounting system" without inevitably relying on dbus, then that point is valid.

best ... khay

----------

## depontius

 *khayyam wrote:*   

>  *depontius wrote:*    *khayyam wrote:*   I could have opted not to enter the kingdom of gnucash and instead entered the forest of sqlite ...  
> 
> But sqlite is a lightweight database, not a double-entry ledge accounting system.  There's just a bit of difference. 
> 
> depontius ... that's not the point though, the point is "design", and where that design will lead (dead ends, or what-have-you). Now, unless you are saying that its impossible to make a "double-entry ledge accounting system" without inevitably relying on dbus, then that point is valid.
> ...

 

In fact, from the ebuild it appears that gnucash is equipped to use sqlite, postgres, or mysql.  Funny thing is, I don't see something in the ebuild requiring at least one of those to be set, so I'm not sure if it's native store is really one of those, or if they're really there for import.

The dbus is used by gnome-keyring, which is used by libsecret, which is used to store passwords for accessing home banking web sites, which I'm not doing.  So that stuff is dead weight to me.

Over ten years ago, when I picked up gnucash, I simply wanted a double-entry ledge bookkeeping program for my personal finances.  I wasn't as worried about the software design side of things.  I've been cognizant of security issues, but at the time thought of them as being more implementation issues.  It's not that many years that events have forced me to think of problems (other than Windows, of course) being architectural and even worse, platform-architectural issues.

I am where I am, and for the moment I'm going to make sure gnome-keyring can't work.  In the longer term I may look at some "dead shims" to make sure that not only can they not work, they can't do anything at all.

----------

## juggling_ben

 *depontius wrote:*   

> 
> 
> The dbus is used by gnome-keyring, which is used by libsecret, which is used to store passwords for accessing home banking web sites, which I'm not doing.  So that stuff is dead weight to me.
> 
> 

 

Hello fellow gnucash lover

Probably getting offtopic, but just playing around, gnucash doesn't really depend on libsecret or gnome-keyring. It will build fine without it (ie outside of portage). There is no way to disable it at configure time, however, and will just automatically detect it if it exists.

I've created an enhancement: bug 537930

----------

## steveL

 *steveL wrote:*   

> Mind, I'm all for an easy-ipc lib; I just think it's only interesting if the admin can configure it, similarly to /etc/services, on a domain-specific basis.

 

 *tclover wrote:*   

> This shouldn't be difficult to implement with such an easy API... I remove the "difficult API" said previously!

 

Yay :-)

 *Quote:*   

> I second a lib for that kind of things... to give at least a "named service" (string) translated to a (TIPC) "named port" {TYPE,INSTANCE} (two 32-bits integer.) It will certainly help...

 

Indeed it'd be simple; though I think it should be more extensive so we could have say (for the two common uses):

```
# notify on file if required

email: file "/var/somepath" with data: count

mixer: [

  ctrl: mqueue "alsa/mixer"

  data: tipc 1000:0:1000

]/mixer

audio: [

  ctrl: fifo "/var/run/alsa/volume"

  data: tipc 2000:0:1000

]/audio
```

The point being that we should be able to tell a generic API that we want to use one of the N variants of IPC available, including fifos, mqueues and AF_UNIX sockets, depending on the service and the semantics (so a service might not support being used with "file" for example, which would result in a hard error at startup, whatever else happened.) Really this starts to overlap with a stay-around pid2 as well, since this implies dependency and configuration checks.

Though I think that's also necessary, if we consider containers and cgroups, quite apart from monitoring which is the use-case I'd like satisfied more neatly.

In any event, the app shouldn't care since it's down to the lib to establish the channel, so long as the semantic is fulfilled. The admin or distro can then tweak in the light of concrete experience, and system constraints.

RT signals are also an important part of the mix, though that tends to be within a specific domain, usually within one application amongst threads, or related processes. Really it's up to the app to wire that, but we need to consider it wrt mqueues, which can be configured to trigger RT signals, as well as a thread. So the app may need to know what mechanism is in-use, in specialist situations (which we'd likely just write a simple shim to the existing lib for.)

 *Quote:*   

> What about a "bearer" (link) implementation?

 

I don't think we need to worry about that, since our primary focus is local-machine. TIPC gives us the ability to extend that across the LAN (at least for SOHO users) very easily, should we need to extend in the future; atm however the focus is on efficient intra-node comms, certainly as far as the proposed kdbus changes go, which are at best very speculative in ABI terms. (Not something we want to base our computing platforms on, at least round here.)

 *Quote:*   

> I'm yet to finish reading the specs, but, so far so good. The API looks almost more easy to grasp... for even the "simpler" (than D-Bus) kDbus.. the ZONE/CLUSTER/NODE address space & one-to-many(multicast+broadcast)/many-to-one/one-to-one(unicast (low latency)) make kDbus' domain/bus/connection counterpart... almost a toy.

 

Yeah, I need to get my head round, and it would be good to document, the whole addressing ranges idea, and how that works in practice with simple pub/sub testcases.

 *Quote:*   

> (Some facts: kernel(good config)+JACK gives a ~20ms latency; or ~<10ms for RT kernel.)
> 
> Direct peer-to-peer (or one-to-one) communication (for low latency) on ~weak~ hardware achieve a ~100us for Round Trip Time (send+receive message) is not that bad... (The 4us of kDbus is not trustworthy considering the politics of systemD cabals.)

 

These figures are from testing using ticputils? Cool :)

The other aspect of it is not to send blobs of data down what are really meant to be control channels, either at lib or app level (metadata iow.) For instance it would be foolish to start using a different IPC, be that kdbus or anything else, for X direct-rendering data. Similarly it's foolish to start using anything other than jack to actually handle the audio data, though as above we might want a way to tap into it (we'd be using "jack/foo" not "alsa/foo" for anything pro-audio, though.)

As Ant said, and the kernel folks continually pointed out in the previously-linked dialogue, if you rethink the uses of the metadata bus, with knowledge of what else is already provided, you come up with a much cleaner, and much more efficient design, since you're not shoving everything down it. Instead you let the kernel multiplex for you, since that is its main task in life.

 *Quote:*   

> I added net-misc/tipcutils-2.0.3 on my overlay (it has a cmdline utils for AF_TIPC ("ports") sockets creation compared to version 2.0.0 available in the official tree); and dev-perl/IO-Socket-TIPC in order to test a few things for those interested...

 

Nice work :-) Thanks muchly.

Would be good to see what mv thinks of the perl API.

----------

## tclover

 *steveL wrote:*   

> Indeed it'd be simple; though I think it should be more extensive so we could have say (for the two common uses):
> 
> ```
> # notify on file if required
> 
> ...

 

That's fine but... it's a little hard to read. So, what about--hoping to keep `/etc/services' simplicity--

```
"NAME"    "FACILITY"    "[OPTIONS]" # Just like the extra fields in `/etc/services'

"NAME"    "ADRESS:PORT/IPC"    "[OPTIONS]" # To put it in another manner

ladi    128.1.1000/tipc # To lmake an example (colon `:' or dot `.'?)

ladi    128.1/tipc  [RDM|DGRAM|STREAM|SEQPACKET] # To illustrate a possible option (socket type)

ladi    128.1:STREAM/tipc  [OPTIONS] # Or <ADDRESS:PORT|SOCKET(-TYPE)/IPC> makes more sense?

# WARN: 0 in <ZONE.CLUSTER.NODE> is special and are not permited in a "node" address or "named port" or "name service"
```

EDIT(PREVIOUS WITH):TIPC Network Address: This address is a 32-bit integer, structured into three fields, zone (8 MSB), cluster, (12 bits), and node (12 LSB).

This syntax is more readable and has the optional flexibility to add extra fields for particular IPC.

 *steveL wrote:*   

> Though I think that's also necessary, if we consider containers and cgroups, quite apart from monitoring which is the use-case I'd like satisfied more neatly.

 

Yes, this is what I have in mind as a primary concern monitoring in order to supervise and control the availability of services/functionalities. And this what most users want when using D-Bus. However...

 *steveL wrote:*   

> The other aspect of it is not to send blobs of data down what are really meant to be control channels, either at lib or app level (metadata iow.) For instance it would be foolish to start using a different IPC, be that kdbus or anything else, for X direct-rendering data. Similarly it's foolish to start using anything other than jack to actually handle the audio data, though as above we might want a way to tap into it (we'd be using "jack/foo" not "alsa/foo" for anything pro-audio, though.)

 

Indeed, it would be foolish to jump blindly in a new toy when existant protocols satisfy particular needs e.g X or JACK. Although with a low latency & data capable communication IPC (TIPC set max packet size to 66000 bytes),--this is where some are waiting to threw away licence concerns (who said RH already?... Oracle?... the starting block are full of chalengers),--data transactions become an interesting perspective. I provided the above figures to put some perspective on the latency concerns. (I did not, yet, have the time to test TIPC--TIPC latency figure is on the spec papaer; JACK latency data are commonly found on the intertubes.) Of course, some politics become almost transparent with this... as if audio transport data is the _real_ motive to write a new in-kernel IPC when there are at least:

* a low latency & network friendly audio transport (where mixer concerns vanish);

* an already good low latency in-kernel IPC;

good implementation available.

But this just provide (other) justifications of their... pitiful failure with PulseAudio... when it was _first_ sold as a mixer capable solution implying that... as if there weren't any available. 

Stopping here. There are way too many deceiving schemes behind this, and GKH finally said it all in a short sentence--"trust us, we know what we're doing!"

----------

## Anon-E-moose

 *Quote:*   

> On Tue, 20 Jan 2015 09:13:59 +0800
> 
> > That's because people have not done anything really needing performance
> 
> > on the desktop over D-Bus in the past due to how slow the current
> ...

 

LoL

----------

## Anon-E-moose

 *tclover wrote:*   

> There are way too many deceiving schemes behind this,

 

Indeed

 *Quote:*   

> and GKH finally said it all in a short sentence--"trust us, we know what we're doing!"

 

We know what you're trying to do, too...subvert the kernel and put it under RH's control.

Trust you...don't make me laugh.

----------

## WWWW

To solve this problem the IPC one, engineers should implement IPC in hardware.

CPU designers should come up with a cpu layer that has hardwired IPC paths, within cpu, or even extending to cpu-mem.

This way the complexity of this issue would be resolved. IPC appears to be a stand alone paradigm unrelated to software, arch, languge etc.

Imagine the posibilities!! Real time ipc, zero latency, etc...

----------

## ct85711

As much it would be nice to see a hardware based IPC, I don't think it's feesible.  My understanding of IPC is that if you do hardware based, it's going to end up as static routes.  This in turn effectively boils down to Apple, Google, M$ paying for static routes for their software only, and turn into hardware lock-in. So I'd have to say, No to hardware-based IPC.

Now my understanding of IPC can also be wrong, which can be the case.

----------

## tclover

 *tclover wrote:*   

>  *steveL wrote:*   Indeed it'd be simple; though I think it should be more extensive so we could have say (for the two common uses):
> 
> ```
> # notify on file if required
> 
> ...

 

EDIT2:

 *SteveL wrote:*   

> Would be good to see what mv thinks of the perl API.

 

Just take a look to the module doc (`perldoc $PATH_TO_MODULE') to see how easy it is to actually create connection[-less] sockets and then send "messages" easily with a couple of lines. Couldn't be easier... I don't know if you ever tried to write something for D-Bus, be it directly or indirectly with language binding,--I did in python,-- to see what I mean. It's not exactly difficult,--well, this depends on what the "client" would be doing,--but it's far from being strait forward and simple. And there are test programs (in C for server, client et al along with doc for this end) in the source files of tipcutils package. Should be easy enough to write anything on it...

----------

## Anon-E-moose

I've been keeping up with the mailing list and it's getting funny.

People are questioning the speed of kdbus and now GKH is saying that they don't want kdbus for the speed it's for the other things

I do remember when they were pushing for it simply for the speed aspect, and that includes comments from that lying POS GKH. 

Talk about moving the goal posts.

The good thing, is if it's so transparent that I can see it, I'm pretty sure others do to.

----------

## depontius

 *Anon-E-moose wrote:*   

> I've been keeping up with the mailing list and it's getting funny.
> 
> People are questioning the speed of kdbus and now GKH is saying that they don't want kdbus for the speed it's for the other things
> 
> I do remember when they were pushing for it simply for the speed aspect, and that includes comments from that lying POS GKH. 
> ...

 

I follow it occasionally, but not terribly faithfully.  The stuff I've been noticing more about is handling of metadata, whether kdbus connections are connectionless or not, and whether the in-between spot they seem to be aiming at constitutes a giant security problem waiting to happen.

As for the talking-out-both-sides nature of the debate, I've had that happen to me.  In one case, probably 6-9 months ago I was arguing Unix Philosophy vs systemd.  One responder argued the Unix Way was outmoded, obsolete, and holding Linux back.  Another responder on the same subthread argued that SysV-Init was flawed from a Unix Philosophy point of view, and systemd was actually more adherent to the Unix Way, once you realized how modular it really is.

Yes, they argue both sides of every issue, but never against each other.

----------

## Anon-E-moose

I'm waiting for the reality of what it means to be included in the kernel to hit the kdbus devs upside the head.

They keep on saying "we'll be able to change things down the road" not little things but major interface changes

such as whether to include metadata or not depending on how fast the kdbus code is.

And the kernel devs have been trying to tell them that things won't change if it ever gets to be included.

So far those statements seem to have gone right over the kdbus devs heads.

They seem to think that because they "created" the code they'll be able to change things as if it were user-space code.

We know different, we've heard "we don't break user-space" for a long time.

Hell, it's the main reason that Linus banned Kay from being able to submit any patches to the kernel, he got tired of it not sinking in to Kay.

Right now, I'm still seeing the need for kdbus re:speed being questioned.

Oh well, it'll be an interesting train wreck if it ever gets that far.

----------

## depontius

The 3.19 kernel was released last night.  I built and booted it this morning, so I could build AMDKFA.  Even if I don't have any HSA userspace yet, I just wanted to get this far.  (I'm having AMDIOMMU_V2 problems that are probably BIOS-related, but that's another story.)

In the release article on Phoronix they were talking about how once Linus said that 3.20 probably wouldn't happen, and it would be 4.0 instead.  It appears that hasn't happend, whereupon a call rang out for 4.0, so they could break that nasty backwards compatibility.  No mention of systemd, but I suspect it was behind the covers.  Anyone for replacing syscalls with a kdbus message?

----------

## 229566

 *depontius wrote:*   

> Anyone for replacing syscalls with a kdbus message?

 

Ugh.

But in another article from Phoronix, it would appear that live kernel patching lands in 3.20. That's something I'm looking forward to. 

Personally I believe it would make little sense to have a major version bump now. What kind of major new development will the kernel see? kdbus? That hasn't happened yet. Frankly I don't even remember if there was any when 2.6.x switched to 3.x, I think it was just for some numbering convenience as 2.6 part was supposed to stay for a while.

----------

## NeddySeagoon

GrueXYZ,

Some have it that 3.0 was to celebrate the dawn of the third decade of the kernel.

If thats true, its a while before we get to 4.0

----------

## Shamus397

This seems to be a recurring theme:

 *In response to GKH, Johannes Stezenbach wrote:*   

> Well, IMHO you got it backwards. Before adding a complex new IPC API to the kernel you should do the homework and gather some evidence that there will be enough users to justify the addition.
> 
> But maybe I misunderstood the purpose of this thread and you're just advertising it to find possible users instead of already suggesting to merge it? If someone has some convincing story to share why kdbus would solve their IPC needs, I'm all ears.
> 
> (I'm sorry this implies your responses so far were not convincing: not verifiable facts, no numbers, no testimonials etc.)
> ...

 

Found here. That whole thread is quite interesting, and it gives me a least a little hope that the kernel devs aren't going to be buffaloed by GKH and friends.  :Smile: 

EDIT: Interestingly enough, seems the mailing list has fallen silent on the topic for close to a month now.

----------

## ct85711

I found this rather funny, to see the claims that kdbus is going to be faster, and yet it's slower than regular kernel methods doing.

http://lkml.iu.edu/hypermail/linux/kernel/1502.0/02862.html

 *Quote:*   

> 
> 
> From: Andy Lutomirski
> 
> Date: Wed Feb 04 2015 - 18:03:37 EST 
> ...

 

Then a comment Andy made later is a nice catcher:  http://lkml.iu.edu/hypermail/linux/kernel/1502.1/00114.html

 *Quote:*   

> 
> 
> Date: Sun Feb 08 2015 - 11:55:13 EST 
> 
> I tried to disable metadata. I may have failed.
> ...

 

Shamus397:  The mailing list hasn't gone quiet, it's just broken up into sections (based on the date).  If you click on Other mail archives (on top of the page, in thread view) -> Kernel Mailing List -> select which date

----------

## Anon-E-moose

 *Quote:*   

> This makes me wonder what dbus1 is doing wrong.

 

Most of us are wondering this.   :Laughing: 

As far as the posts, there was only one last week and that was from Andy with no replies, and none this week (as of this morning when I looked).

also from that post (the one that I quoted at the top of this post)

 *Quote:*   

> >
> 
> > * We have not optimized kdbus code-paths for speed, yet. Our main
> 
> > concerns are algorithmic challenges, and we believe they've been
> ...

 

Optimizations are one thing, removing or adding fields ie. breaking user space code is quite another.

Andy and other kernel devs keep trying to get this point across and it still seems like the kdbus devs don't understand

or perhaps they're so arrogant that they think they'll be able to do whatever they want if it gets included in the kernel.

Re: the performance guesses, performance is the original reason that they claimed they needed kdbus for.   :Rolling Eyes: 

----------

## ct85711

I find it funny, every time someone goes through tests and proves their original claim for the use of kdbus wrong, they go start claiming that's completely wrong.  That they are NOT going for that, but for something else.  It will be funny when someone and tests out how secure kdbus really is; then they'll have lost all their original claims for kdbus.

----------

## Anon-E-moose

ct85711, it's the same thing that was done with justifying sysd.

First it was marvelously fast boot up times, then when it only proved marginally faster in many cases, 

that quit being touted and other improvements were pushed in it's place.

Notice that fast boot times is hardly ever used as justification for sysd nowadays.

In the world of having arguments it's called "moving the goal posts" so as to avoid "losing the argument".

I'm more curious as to why all the parties that were trying to justify kdbus have quit posting.

Maybe LP is getting ready to write another of his whining screeds about being attacked because they won't let him in the kernel.   :Rolling Eyes: 

Edit to add: I went googling to see what was going on with kdbus outside the mailing list and

ran across a statement claiming that kdbus was needed for properly sandboxed applications in X (and wayland).

Of course the one making such a statement was a gnome dev, "surprise, surprise, surprise"

The only other thing I've seen mentioned is how it would make "ta da" pulseaudio work better.

I suppose thats the reason that we've seem multi-meg data transfers mentioned re: the need for kdbus

So basically it sounds like gnome is the main driver for kdbus.

Makes me wonder what they promised GKH to get it into the kernel. A job with RH/gnome perhaps.   :Rolling Eyes: 

----------

## steveL

 *Anon-E-moose wrote:*   

> ct85711, it's the same thing that was done with justifying sysd.
> 
> First it was marvelously fast boot up times, then when it only proved marginally faster in many cases, 
> 
> that quit being touted and other improvements were pushed in it's place.
> ...

 

Indeed; we've been here before with paludis, which has a similar history of ever-changing selling points, "advantages" that turned out not to be.

 *Quote:*   

> Makes me wonder what they promised GKH to get it into the kernel. A job with RH/gnome perhaps.

 

I imagine he already has stock options, as do quite a few kernel devs from what I recall; something about RH giving them all a load of stock in the early days/first floatation. Mind, I've no idea how accurate that is.

----------

## tld

 *Anon-E-moose wrote:*   

> ct85711, it's the same thing that was done with justifying sysd.
> 
> First it was marvelously fast boot up times, then when it only proved marginally faster in many cases, 
> 
> that quit being touted and other improvements were pushed in it's place.
> ...

 

Bingo...everything these folks dish out ends up being a cure in search of a disease...and not a nice cure either...more the chemotherapy variety...

Tom

----------

## steveL

 *steveL wrote:*   

> Indeed it'd be simple; though I think it should be more extensive so we could have say (for the two common uses):
> 
> ```
> # notify on file if required
> 
> ...

 

 *tclover wrote:*   

> That's fine but... it's a little hard to read. So, what about--hoping to keep `/etc/services' simplicity--
> 
> ```
> "NAME"    "FACILITY"    "[OPTIONS]" # Just like the extra fields in `/etc/services'
> 
> ...

 

Hmm the issue is when we want to group settings to apply them to one service. I'm not especially fussed about the exact format, so long as it does enough: the simple cases should stay simple one-liners, but if we need more, then we have to be able to accommodate it. For some things that are in the IPC domain, we need to cope with several stanzas per-logical item (or the conf is going to get messy, and people will ask "why didn't you use a standard init parser?", or even worse "XML".)

miroR linked us to the postfix docs via a thread on grsec. I find the setup of master.cnf to be exactly along the lines we've been discussing.

So you have a Service type = inet | unix | fifo | pass (= single conn AF_UNIX; pass accepted fd), where the "service name syntax depends on the service type" eg specifying the smtp port (-D means run under debugger):

```
smtp      inet  n       -       n       -       -       smtpd -D
```

postfix master is a daemon manager, xinetd on steroids (not so surprising when we consider the author is Wietse Venema.) I really like the approach, because it constrains the complexity to the domain.

As well as for an easy-ipc lib, whereby the admin configures the ports, protocols and any pub/sub ranges for TIPC, I'd also like us to look at using similar configs within openrc, for the xinetd functionality in combination with monitoring; then we can easily inspect the postfix config, or any other like it.

That ties into the cgroup handling we added over a year ago; we may need to look at the Gentoo kernel options for openrc, in case we need to stop systemd idiocy from preventing us using cgroups sanely.

Note that the master.cf is more like the runscript-specification, and there is another main.cf where the admin configures variables used by it, along the lines of /etc/rc.conf or /etc/conf.d/svcfoo.conf. spawn handles the "one-shot" daemons of xinetd.

 *Quote:*   

> Yes, this is what I have in mind as a primary concern monitoring in order to supervise and control the availability of services/functionalities. And this what most users want when using D-Bus. However...

 

Hmm I think we need to look at that use-case with scepticism; most apps (and thus most users) should not care about services going up or down. The things that do, tend to be things like systray apps, which we should treat as one class of thing, as it's quite simple. 

Thereafter, each use-case should be explained and justified, before we end up with yaf spaghetti-junction of things that need to be recompiled every time a so-called convenience layer changes.

We must use a stable API like LADSPA for any such layer, so that the shim layers have a stable ABI to support, and not some junk design bolted onto, every time some nub has a brainwave. I don't much care what's in it, so long as it's well-thought through, and we separate by domain, so that we're not shoving everything down the one, inappropriate, IPC mechanism.

Service dependencies that are affected are of course the domain of the init-manager, pid2 (makes a nice working name, anyhow;)

 *steveL wrote:*   

> The other aspect of it is not to send blobs of data down what are really meant to be control channels, either at lib or app level (metadata iow.) For instance it would be foolish to start using a different IPC, be that kdbus or anything else, for X direct-rendering data. Similarly it's foolish to start using anything other than jack to actually handle the audio data, though as above we might want a way to tap into it (we'd be using "jack/foo" not "alsa/foo" for anything pro-audio, though.)

 

 *Quote:*   

> Indeed, it would be foolish to jump blindly in a new toy when existant protocols satisfy particular needs e.g X or JACK.
> 
> Although with a low latency & data capable communication IPC (TIPC set max packet size to 66000 bytes),--this is where some are waiting to threw away licence concerns (who said RH already?... Oracle?... the starting block are full of challengers),--data transactions become an interesting perspective. I provided the above figures to put some perspective on the latency concerns. (I did not, yet, have the time to test TIPC--TIPC latency figure is on the spec papaer; JACK latency data are commonly found on the intertubes.)
> 
> Of course, some politics become almost transparent with this... as if audio transport data is the _real_ motive to write a new in-kernel IPC when there are at least:
> ...

 

Heh. You're right though, the pieces are already in place, and we have a lovely in-kernel IPC mechanism, that's been through many iterations and serious real-world testing by Ericcson for 20 years.

There's zero upside in allowing kdbus to infect our machines, imo.

memsealing we can use to implement mmapped message-queues, where the receiver gets a struct iovec (or equivalent with const void *base: see man uio.h); we'd need to support usage with aio_suspend/lio_listio for POSIX (see man aio.h) which can be done in userland, since glibc does them in userland.

wrt io_submit for linux, that would have to be supported from the kernel side, but would be a much nicer basis for a userland wrapper, since there's no extra threading.

Though there are caveats; see also Arvid Norberg's excellent answers  on stackoverflow.

----------

## Naib

 *tld wrote:*   

>  *Anon-E-moose wrote:*   ct85711, it's the same thing that was done with justifying sysd.
> 
> First it was marvelously fast boot up times, then when it only proved marginally faster in many cases, 
> 
> that quit being touted and other improvements were pushed in it's place.
> ...

 Same thing with paludis. The problem is systemd sort of functions how svchost does on windows as well as how services.exe.  Windows and Linux aim to get a very similar job done (boot the system up into a definable state) but differently. Windows method works (you may argue that how it manages it is rubbish but that doesn't actually negate the fact it does work), linux method works (and equally windows people cannot comprehend the apparent haphazardness of it and perceive the existence of a million and one distro's as proof linux doesn't work - negating the fact pretty much all the distro's are quite well aligned since the early 00's when libc patches and updates became more frequent...) 

if there is an influx of ex-windows programmers... systemd makes more sense to them 

if you concentrate on counter-arguing what systemd is it holds the discussion point, to a larger audience, on what systemd does, allowing the systemd proponents to argue how systemd does foo (be it by spinning the truth or discussion around perceived issues).The discussion needs to equally shift to what other init's do, how their architecture protects against certain things.

Same with kdbus. Concentrate on what it isn't doing or is doing poorly and it will keep morphing to "correct" the perceived weaknesses or redefining itself to blank out that which cannot be perceived.  Push the agenda of userland application bus

----------

## steveL

 *Naib wrote:*   

> Same with kdbus. Concentrate on what it isn't doing or is doing poorly and it will keep morphing to "correct" the perceived weaknesses or redefining itself to blank out that which cannot be perceived.  Push the agenda of userland application bus

 

Yes, but at some point technology has to function; you're talking about slipping one past computer programmers in their domain of expertise, not selling sausages to drunk people at a fair.

Someone quoted somebody or the other in one of these threads; something to do with public relations doesn't work with technology, because at some point technology has to face nature.

As the systemdidiots keep changing their stance, never arguing both sides in the same discussion, but both sides across the debate, so more and more people are going to get fed up of it. Especially kernel coders.

----------

## Shamus397

An "interesting" patch made its way into the kernel recently, written by Greg KH: http://ostatic.com/blog/greg-k-h-tries-to-code-linus-behavior

Also, version 4 of Greg K H's ill-conceived kdbus hits the LKML: https://lkml.org/lkml/2015/3/9/340

----------

## Anon-E-moose

 *Quote:*   

>  It continues by saying that while the writers do not wish the quality of the kernel code to decrease but if anyone "feels personally abused, threatened, or otherwise uncomfortable due to this process" they should write the Linux Foundation and file a complaint. The Linux Foundation Technical Advisory Board will then take action to resolve the issue.

 

I predict that next up will be more whining from Kay and LP, "wah, wah, they're saying things about us".

Along with GKH complaining about their sloppy, incomplete and dangerous kdbus not being included in the kernel.

The funny thing is, I've seen as much or more abuse from Kay, LP and GKH as from Linus. Talk about the pot and the kettle.

----------

## depontius

 *Shamus397 wrote:*   

> An "interesting" patch made its way into the kernel recently, written by Greg KH: http://ostatic.com/blog/greg-k-h-tries-to-code-linus-behavior

 

I wonder if the "Code of Contuct" or "Conflict Resolution" will apply when invoked by those racally systemd-haters, or if it's really only there for systemd-promoters.

----------

## steveL

Oh God not another "technical" advisory committee that is in fact a mechanism of political control.

I feel sorry for whoever gets the wrong side of them.. sounds like a mish-mash of Council and devrel, neither of which work at what they take on in direct contravention of their mandate and the Code of Conduct.

I suppose from their perspective, they're just doing to the kernel what they did to debilian, which was apparently a test-run.

Hmm wonder if they think they've already done Gentoo, only us mopes don't know about it.

----------

## depontius

 *steveL wrote:*   

> Hmm wonder if they think they've already done Gentoo, only us mopes don't know about it.

 

I think they're biding their time.  At the moment, taking on Gentoo is also sort-of taking on Google, and they've probably figured out that they're not really up to that, no matter that they've taken over everyone else but Slackware.

Hmmmm....

As the "old guard" retrenches to Gentoo and Slackware, and considering moving to BSD, I wonder if there's any fear of completely alienating them.  The question here is, what would really happen if the old guard picked up and left Linux.  What would happen if the Linux kernel were really in the hands of Linus and the systemd crowd, without the old guard shoring things up?

----------

## steveL

 *depontius wrote:*   

> As the "old guard" retrenches to Gentoo and Slackware, and considering moving to BSD, I wonder if there's any fear of completely alienating them.  The question here is, what would really happen if the old guard picked up and left Linux.  What would happen if the Linux kernel were really in the hands of Linus and the systemd crowd, without the old guard shoring things up?

 

Then we'd have lost, by ceding the ground to them, instead of carrying on to show why Linux was built in the Unix tradition, and no other.

Sure, Linux would lose out too, but why spend decades bringing up another GPL sourcebase, just so preppy can go to the moon?

----------

## NeddySeagoon

depontius,

Moving to BSD is not a long term solution.

Turing Linux into windows needs to be resisted by keeping the old codebase alive and in use.

I don't have much confidence that the systemd borg can be stopped or reversed any time soon and as others have said, reversing the damage will be a huge undertaking as so much needs to be switched at once - everything that systemd has engulfed.  Think of the minicomputer revolution being replayed all over again, where Microsoft and Red Hat take the place of say, Apollo and DEC, for all the same reasons. 

If Linux is lost to systemd and the 'old guard' move to BSD, it will only be a matter of time before BSD gets attractive enough for the process to be repeated on BSD.  Then where do we go?

We stick to Linux and make it work because there are no other long term options.

----------

## steveL

 *NeddySeagoon wrote:*   

> Moving to BSD is not a long term solution.
> 
> Turning Linux into windows needs to be resisted by keeping the old codebase alive and in use.

 

Agreed.

 *Quote:*   

> I don't have much confidence that the systemd borg can be stopped or reversed any time soon and as others have said, reversing the damage will be a huge undertaking as so much needs to be switched at once - everything that systemd has engulfed.

 

I think it only looks that way when seen from the perspective of all those borked dependency specifiers, which isn't actually that big a deal in the overall scheme of things.

Upstream programmers don't target one OS, let alone one OS-specific init-system.

Though it does mean some work on the part of the distros or their users, more usually, to find the old code repo, and get rid of technical pollution[1], that's really the distros shooting themselves in the foot. Many aren't anything more than "white-labelled" rebadges in any case, so about as much contribution in code terms imo, as the web-2.0 virtual hosting salesmen make to the infra of the web; ie: none.

From their perspective, it's just a business, and business is led by sales, which are led by fashion, not sense. From a community perspective, as best I can see, they're not-very-useful middlemen in any case, so why bother trying to win a marketing war?

As you said, just keep using the existing codebases which work, and don't try to lock us in, and patch those in collaboration with other distros who turned down the kool-aid, and most importantly, their users.

We'll have an easier time of it, as we allow the strengths of a diverse ecosystem to work for us, rather than spending all our time putting out fires brought on by megalomania and the consequent desire to control everything and everyone, which leads systemdiots to try and argue for, and implement, a monoculture built on repression of the underlying craft. Our problems will be localised.

[1] It's technical "pollution" because the dependency specifiers are deliberately borked so existing implementations are broken.

This is done on the pretext that systemd has swallowed the existing project, and then crippled it a couple of versions later so it will only work on a systemd-pid1 machine (poor thing).

The reason it is borked, is that if systemd provides the functionality as part of its package (of so many projects..), then there is no reason at all to take over the dependency namespace. Just depend on systemd instead, for the packages moving to Lennux, and leave the existing package name for its current usage.

After all that's not a fork, as the "new" project is.

----------

## ovitters

I'm wondering: Did you try to hold a discussion with the various people you're accusing, making fun of and attributing malice to?

I congratulate the various people participating here to investigate just enough to congratulate the rest about "being right", but one of the last messages is talking about what should be done. Seems nobody will do anything, so I predict kdbus goes into the kernel, everyone will complain again about how evil e.g. Red Hat is though life just goes on.

I do think it's good to be critical and I think a few good critical points were raised. However, they're lost in the noise of the echo chamber and the various wrong assertions. I don't think anyone here will build up credit, so even for the good critical points you're not getting anywhere. There's more to stuff than just black/white good/evil, etc.

----------

## NeddySeagoon

ovitters,

Lots of people are doing different practical things but there is no joined up effort like there is over at Red Hat.

kbus will probably go into the kernel at some time.  Thats not important. What is important is that the old stuff still works so that those of us who think that kbus, systemd and friends should be avoided can contine to avoid them.

Try Olde Fashioned Gentooee if you want a nice fast boot.

It doesn't have any uevents to process, doesn't use udev or systemd, it doesn't do anything automatically behind your back. It just works.

There are many other efforts. Devuan, the systemd free Debian fork and all the distros listed as using eudev.

There will we lots I don't know of too.

----------

## truekaiser

 *Anon-E-moose wrote:*   

>  *Quote:*    It continues by saying that while the writers do not wish the quality of the kernel code to decrease but if anyone "feels personally abused, threatened, or otherwise uncomfortable due to this process" they should write the Linux Foundation and file a complaint. The Linux Foundation Technical Advisory Board will then take action to resolve the issue. 
> 
> I predict that next up will be more whining from Kay and LP, "wah, wah, they're saying things about us".
> 
> Along with GKH complaining about their sloppy, incomplete and dangerous kdbus not being included in the kernel.
> ...

 

I think you may be right, i read it over it looks more like an attempt at a coup d'tat. Get rid of linus and they, and red-hat by proxy, has complete control of the kernel. they can shut out all NON system-d users. Hell even all non red-hat users.

----------

## roki942

 *truekaiser wrote:*   

>  *Anon-E-moose wrote:*    *Quote:*    It continues by saying that while the writers do not wish the quality of the kernel code to decrease but if anyone "feels personally abused, threatened, or otherwise uncomfortable due to this process" they should write the Linux Foundation and file a complaint. The Linux Foundation Technical Advisory Board will then take action to resolve the issue. 
> 
> I predict that next up will be more whining from Kay and LP, "wah, wah, they're saying things about us".
> 
> Along with GKH complaining about their sloppy, incomplete and dangerous kdbus not being included in the kernel.
> ...

 +1

----------

## Ant P.

Everyone else is merely collateral damage to RedHat in their blood knight crusade against Oracle, after all.

Let them shut us out! Let them try. Once they're done surgically attaching everything to systemd, they'll be too fat to compete with the rest of Linux, which remains agile.

I won't mind seeing both GNOME and KDE crash and burn, with the ship they've chosen to chain themselves to.

----------

## Anon-E-moose

 *Ant P. wrote:*   

> Everyone else is merely collateral damage to RedHat in their blood knight crusade against Oracle, after all.
> 
> Let them shut us out! Let them try. Once they're done surgically attaching everything to systemd, they'll be too fat to compete with the rest of Linux, which remains agile.
> 
> I won't mind seeing both GNOME and KDE crash and burn, with the ship they've chosen to chain themselves to.

 

++

----------

## steveL

 *ovitters wrote:*   

> I'm wondering: Did you try to hold a discussion with the various people you're accusing, making fun of and attributing malice to?
> 
> I congratulate the various people participating here to investigate just enough to congratulate the rest about "being right",

 

And you're not mocking anyone there, are you?

Did you try to hold a discussion yet, with those you're spuriously characterising, with a glib remark?

Apparently not, 4 posts in over a year.

Pot, meet kettle. Yes the kettle's shinier and does the job better: that's because it's pared down to essential simplicity.

Now now, pot. No need to get so snarky just because no-one wants to setup your pottering factory in order to build all the rest..

And FTR, I have indeed communicated with GregK-H on the Gentoo mailing list, about udev and initramfs. Thankfully we got the actual requirement out of him, before he started the vague hand-waving. He's good at documentation, yes. So what? Doesn't change the fact that he just puts people down instead of addressing the issue, when it's something not on his agenda, and he thinks they're not important. The recently linked lkml discussion has shown the same traits.

 *Quote:*   

> but one of the last messages is talking about what should be done. Seems nobody will do anything, so I predict kdbus goes into the kernel

 

I'm sure you do; what with being a "GNOME team member", and all.

 *Quote:*   

> everyone will complain again about how evil e.g. Red Hat is though life just goes on.

 

Ah more bitchiness. How charming.

 *Quote:*   

> I do think it's good to be critical and I think a few good critical points were raised.

 

Yes, got to sound like you're actually being quite mature here, even though you haven't actually said anything substantive.

 *Quote:*   

> However, they're lost in the noise of the echo chamber and the various wrong assertions.

 

Which you're free to pick anyone up on, at any time. You don't even need to lecture anyone while you do it; you can just pick one or two, and not have to take lots of time out. It's easy: try it and see.

 *Quote:*   

> I don't think anyone here will build up credit, so even for the good critical points you're not getting anywhere. There's more to stuff than just black/white good/evil, etc.

 

Yes, but sh1t and shinola are still easy to distinguish:

 *Quote:*   

> Whether it's a WTF language, a WTF framework, or WTF policies, we can recognize a WTF from a mile away, and are quick to say so when we spot one. 
> 
> Non-programmers (our coworkers, managers, friends, spouses) often have a hard time understanding when we complain that things suck.

 

That's all that's happening with systemdbug; more and more people are looking at it, thinking "WTF?" and turning away. As time goes on, more and more programmers will look at it, and you can't hide behind a "developer" badge when it comes down to actually getting things done. Nor when it comes to talking bullcrap about the value of modularity, which is much more than 50 programs inappropriately lumped together, to make a fedora-src/Gnome-OS/Lennux download.

People quietly turning away aren't going to show up on the noisy propaganda channels systemdiots like to use to propagate their "message" on.

By all means feel free to pontificate some more about how we're all haters because we care about our craft: it won't change the fact that all you're doing is talking lots and lots of vague, with no actual content. Or y'know, summarise each of at least some of those oh-so-damaging assertions you claim are false in a line, and then show why it's wrong.

You know, that technical discussion you claim to be such an authority on. Cos atm you just come across as yaf fanboi, trying the "gentle persuasion" trick via slipped-in nastiness amidst some polite language, with zero content.

----------

## GFCCAE6xF

 *Shamus397 wrote:*   

> An "interesting" patch made its way into the kernel recently, written by Greg KH: http://ostatic.com/blog/greg-k-h-tries-to-code-linus-behavio

 

I know this is a little OT and itwire is a bit of a shitty news source but take a look at: http://www.itwire.com/opinion-and-analysis/open-sauce/67269-linux-foundation-begins-clampdown-on-torvalds

Interesting parts imo:

 *Quote:*   

> Torvalds is now nearing 50, the age which people, especially in the US and more so in the technology industry there, tend to comsider as over the hill. Thus it is not surprising to see this move.
> 
> [...]
> 
> Torvalds is one of the few people in the FOSS community who has the honesty and integrity that these others claim to have. And the way he has managed the kernel project is wholly responsible for its success.
> ...

 

----------

## Anon-E-moose

I find it amusing that a gnome team member is trying to lecture on having meaningful discussions with devs

when there were many attempts at meaningful discussions from a variety of end users at the early stages of gnome3.,

where the end users by and large didn't want it, they wanted gnome 2 refined instead.

What was the result? 

They were all blown off by the arrogant pricks that pass for gnome devs because "the devs knew better".   :Rolling Eyes: 

The same thing pretty much applies to the development of systemd, with the same result.

So please enlighten us why we should waste our time on devs who won't listen anyway?

----------

## Anon-E-moose

 *GFCCAE6xF wrote:*   

> I know this is a little OT and itwire is a bit of a shitty news source but take a look at: http://www.itwire.com/opinion-and-analysis/open-sauce/67269-linux-foundation-begins-clampdown-on-torvalds

 

 *Quote:*   

> The so-called patch was written by Linux Foundation technical advisory board member Greg Kroah-Hartman, who is also an employee of the Foundation

 

Talk about a conflict of interest.   :Rolling Eyes: 

Especially since he's also the one pushing kdbus (with little traction) to be included into the kernel.

Sounds very much like the crap that debian did, where the "technical committee" 

made a choice, ala sysd for all users even though they didn't have the legal power to do what they did.

It'll be interesting to see what transpires.

Will Linus put up with it? Will linux kernel be forked?

Edit to add: Another interesting tidbit from that link

 *Quote:*   

> Garrett has been trying to promote himself as a leader in the FOSS commmunity for nearly a decade and has now even manoeuvred his way onto the board of the Free Software Foundation, an organisation of which he has been a bitter critic in the past.

 

Garrett is also on the TAB. http://www.linuxfoundation.org/programs/advisory-councils/tab for a list of who's who.   :Rolling Eyes: 

And this

 *Quote:*   

> People in the FOSS community are famous for masking more Machiavellian objectives under the guise of "be excellent to everyone", a timeworn phrase that is bandied about by the most power-hungry and bigoted individuals.
> 
> They push the silly view that the Linux kernel project and other FOSS projects should be some kind of utopia where everyone is treated equally and talent is recognised. The truth is, there is vicious and bitter jockeying for position in the FOSS community and people are as cut-throat as in any other technology community.
> 
> Torvalds is one of the few people in the FOSS community who has the honesty and integrity that these others claim to have. And the way he has managed the kernel project is wholly responsible for its success.

 

I'm pretty sure that the motives for the "code of conduct" weren't put out to help devs (in general) but a few like GKH, etc.

And they don't like the fact that Linus is pretty open and honest.

----------

## Ant P.

 *Anon-E-moose wrote:*   

> Edit to add: Another interesting tidbit from that link
> 
>  *Quote:*   Garrett has been trying to promote himself as a leader in the FOSS commmunity for nearly a decade and has now even manoeuvred his way onto the board of the Free Software Foundation, an organisation of which he has been a bitter critic in the past. 
> 
> Garrett is also on the TAB. http://www.linuxfoundation.org/programs/advisory-councils/tab for a list of who's who.  :roll:

 

Also brainwashed-and-crazy. He quit his professional coding career to take up being offended on other people's behalf, showed up to FOSDEM with clown hair to get a rise out of everyone, and requested the reddit /r/linux mods label him part of a terrorist movement. Unironically.

----------

## mrbassie

[quote="Anon-E-moose"] *GFCCAE6xF wrote:*   

> 
> 
> Sounds very much like the crap that debian did, where the "technical committee" 
> 
> made a choice, ala sysd for all users even though they didn't have the legal power to do what they did.
> ...

 

That could actually be a good thing. We could have Linux as is and they could have Lennux (I'm stealing that steve) with all the crap that would otherwise be rejected getting in and nobody being rude to anybody. Remeniscent of the Golgafrinchams from HHGTTG. 

Everyone wins in the very short term and in the slightly less short term Lennux-NT dies a horrible death and becomes an amusing memory.

----------

## Anon-E-moose

This is a comment from slashdot on the CoC fiasco

 *Quote:*   

> "Linus' leadership role is on its way out, I fear. Linux is done, too. It's suffering from the same disease that has affected GNOME, Firefox and Debian: technological correctness taking a backseat to political correctness."

 

I do believe that the CoC was put forth to exert pressure on Linus, so there is some bit of truth to the comment.

And the bit about tech correctness taking a backseat to PC is spot on. PC will be the death of linux (as we know it)

----------

## steveL

 *Anon-E-moose wrote:*   

> This is a comment from slashdot on the CoC fiasco
> 
>  *Quote:*   "Linus' leadership role is on its way out, I fear. Linux is done, too. It's suffering from the same disease that has affected GNOME, Firefox and Debian: technological correctness taking a backseat to political correctness." 
> 
> I do believe that the CoC was put forth to exert pressure on Linus, so there is some bit of truth to the comment.

 

Absolutely: [emphasis added] *Susan Linton wrote:*   

> the document is clearly aimed squarely at Linus Torvalds who has been quoted saying what some characterize as abusive comments to developers. Torvalds, who admits he is "not a nice person," is straightforward and has little patience for sloppy and buggy code. Torvalds is downright rude sometimes but perhaps the Code of Conflict can rein him in. The commit was signed by 60 developers and Torvalds accepted the patch no doubt knowing that it was directed at him.

 

 *Quote:*   

> And the bit about tech correctness taking a backseat to PC is spot on. PC will be the death of linux (as we know it)

 

Yes, I agree, though it's easy to miss that the "political correctness" on display is not politically correct; it's at best politically-naive. IMO it is in fact just another form of politicking: we can make you do what we want, by constantly questioning how you say things, and thus avoid the substantive part of what you actually said. "thought-police" iow.

 *Quote:*   

> Torvalds was quoted as saying the code is what's important - not the color, gender, or sexual orientation of the submitter.

 

I absolutely agree with that 100%. The political issues around all those liberation struggles, are not served by misunderstanding the nature of the domain.

 *Quote:*   

> Torvalds was scolded by many for that position and now complaints can be filed against him.

 

..which is what this is really about; exerting control, under the guise of the community, but actually to protect the interests of a fifth-column and their corporate masters. After all, stating that kdbus is badly-conceived, and shows no awareness of either the system it runs on, nor the milieu it operates within, as well as being nothing more than a cop-out from actually designing a userland, is hardly  "on message".

So much more so when you baldly assert that the systemd-udev team are a crappy set of maintainers, and ask whether we can do anything about it.

Just a shame you're asking Greg-KH, since he's very much on their side in this whole debate, and is clearly interested in number-one and his stock-options, like any red-blooded Crapitalist should be. He's also been involved in some absolute howlers of design, along the way, always backing the systemdiots. Can't see a race coming? (despite being a self-proclaimed "kernel-expert" such that you don't bother to run RFCs by the ROTW.) Can't do any testing with the supposed audience for your inappropriate decision-making? Can't develop software.

It's always easier to coopt a documentation guy, since they don't birth code as a way of life.

They're just interested in "communicating to a wider audience" which goes nicely with the whole "coddle the user in a maze of dependency hell" approach, under the pretext of "reaching out to the mainstream" (bizspeek for "sell-out".)

FTR as someone who has in the past been involved with "liberation struggles" at a much more in-depth level than these preppy-wannabes, I feel confident in asserting that their political correctness is nothing of the sort.

It's about on a level with "some of my best friends are black." ("right on, dude.")Last edited by steveL on Sat Mar 14, 2015 2:27 pm; edited 2 times in total

----------

## steveL

 *Quote:*   

> The so-called patch was written by Linux Foundation technical advisory board member Greg Kroah-Hartman, who is also an employee of the Foundation

 

 *Anon-E-moose wrote:*   

> Talk about a conflict of interest.

 

Indeed; rewriting the rules or constitution to give yourself more power is a favoured trick of kleptocrats and dictators.

Doing it so blatantly is par for the course, too; after all it must be okay, if they're doing it so openly, right?

But there again, we don't know whether this was discussed widely within the community, only that it was discussed amongst about a 100 developers. And they must have some sort of consensus or Torvalds would not have taken the patch. Supposedly; I'm fairly sure he gave up on reviewing everything Greg-KH does a while back. That's the point of "trusted lieutenants": you trust them, or the whole thing breaks down.

Ultimately every community needs some set of guidelines as it gets larger, which tend to come about as an accumulation of mailing-list behaviour, that needs to be communicated to newcomers. As with so many things, the simple need becomes coopted as a level of control instead.

No-one can really argue with the need for a default setting of politeness and manners; it's when that becomes the only setting allowed amongst people who actually know each other quite well, and need to vent or let off steam from time to time, that you get the issue of martinets using it to arm-twist entire communities.

So the question is what power does this "technical" advisory committee have, which is apparently setup for completely non-technical issues; or at best acting outside its mandate to power-grab over social matters (which can only be for political purposes; there is no good reason to do so.)

Are they allowed to stop someone's code coming in (after all they're "technical" so that's their area, right?) on the basis that they've been bad-mouthing on a mailing-list?

Or are they a set of proctors, ie experienced moderators and IRC operators, who will proactively try to stop flamewars from breaking out, by nipping bad behaviour in the bud, via the simple mechanism of finding out what's wrong. (Somehow I doubt it.)

In any event, the glaring question is: WTF does any of this have to do with a "Technical Advisory Board"?

One might reasonably expect any such were appointed for technical expertise, and not competence with moderation of social matters, which experience tells us do not go hand-in-hand for the vast majority. So why are we knowingly setting ourselves up for failure?

 *Quote:*   

> I'm pretty sure that the motives for the "code of conduct" weren't put out to help devs (in general) but a few like GKH, etc.
> 
> And they don't like the fact that Linus is pretty open and honest.

 

Starting to look that way; as you said a re-run of Debian Technical Committee and Gentoo Council/devrel; strategy seems to be going well.

You can always denounce anyone who spots it as a hater, or point to some bulshytt you posted about echo-chambers, along with a fairly predictable response which is much politer than any you'd get on a systemdbug list or channel, as indicator of how persecuted you all are, really, despite being the ones working for the corporate anti-GPL/pro-tivoization/anti-privacy agenda.

 *Quote:*   

> People in the FOSS community are famous for masking more Machiavellian objectives under the guise of "be excellent to everyone", a timeworn phrase that is bandied about by the most power-hungry and bigoted individuals.
> 
> They push the silly view that the Linux kernel project and other FOSS projects should be some kind of utopia where everyone is treated equally and talent is recognised. The truth is, there is vicious and bitter jockeying for position in the FOSS community and people are as cut-throat as in any other technology community.
> 
> Torvalds is one of the few people in the FOSS community who has the honesty and integrity that these others claim to have. And the way he has managed the kernel project is wholly responsible for its success.
> ...

 

I prefer Linus over Lennart.

What about you? ;)

----------

## steveL

@tclover Glad we're past that. :-)

supervision-scripts looks interesting. Clean sh, which makes a change.

Only had one thing to tweak, but forgot what it was now, and off out. No bugs :-)

Glancing again, I notice a couple of portability issues:

```
[ -n "${1}" -a -n "${2}" -a -d "${CG_ROOT}/${1}" ] || return 0

local ctrl="${1}" group head=$(cgroup_find_path "${1}")

group="${CG_ROOT}/${1}${head}${CG_NAME}_${SVC_NAME}"
```

POSIX recommends against the -a form, and it's obsoleted. (cf: Application Usage.)

Also, you shouldn't assign in 'local' for portability, especially with multiple names (last one came up on dash, iirc.)

So, it's much easier just to treat it like C89, and forward declare, as you then have the field splitting defined not to happen for the word following the '='. So splitting it out, I'd do this:

```
[ -n "$1" ] && [ -n "$2" ] || return 0

[ -d "$CG_ROOT/$1" ] || return 0

local ctrl group head

head=$(cgroup_find_path "$1") && ctrl=$1 || return 0 # or use an if

group=$CG_ROOT/$1$head${CG_NAME}_$SVC_NAME
```

I tend to split out parameter-checking to keep it obvious by inspection. Not sure what you're doing with ctrl.

Anyhow, I'll clone it now, and take a look at the rest in more-depth soon.

Nice work.

----------

## tclover

@mods: Sorry for another off topic ride ;-) but I got to answer to this with a short answer first.

@steveL: *Fake* issues serving as discussion threads could do the trick. A short POSIX off topic won't hurt this thread after many, certainly.

First, I was aware of the 'local' POSIX compatibility issue. It's just... convenient to be able use the same relevant variable name in different *local* scope to keep consistency/efficiency on variable naming scheme. Without 'local' keyword, naming *local* scope variable is problematic and could lost possible readers. Unset can be used to unset *local* scope variables but not masking *global* ones--this is the issue here and could lead to confusion.

And after scripting a great deal for BusyBox/ash,--which has not a proper POSIX compliency,--I just tend to _abuse_ the use of 'local' for consistency sake.

 *steveL wrote:*   

> Glancing again, I notice a couple of portability issues:
> 
> ```
> [ -n "${1}" -a -n "${2}" -a -d "${CG_ROOT}/${1}" ] || return 0
> 
> ...

 

Second, assigning while declaring variable makes the code concise but... the lack of a comma operator could bring in error prone declarations. I do take some care when doing so, however, you're right that I should refrain from it for compatibility reasons--with declaration first, and the assignment. I should take a look (on POSIX doc) for 'declare' counterpart because many shell has this builtin.

Regarding the '-a' (AND) and '-o' (OR), the related section uses some examples like `test "$1" -a "$2"' with '$1' asigned to '!' and '$2' to NULL. Such a nice example! I usually do not use that syntax but only with bash! for obvious reasons when relying on an unknown sh[ell] (POSIX compliant or not.) I always use test operand like '-n', '-z' ... for that making the pointed issue almost irrelevant. Sometimes I _do_ use the syntax you're highlighting on the previous example but it become heavy in scripts using that syntax quite often. So, a preference goes to '-a'/'-o' on plain sh with the previous cautious usage.

NOTE: I prefer by far using '(( $+var ))'/'[[ $+var ]]' when scripting for zsh.

So, the main issue is rather declaration & assignment because my guess is that many modern shells support '-[ao]' for test bultin. I have to think again for the 'local' usage--it won't be that easy to get concise/breve/efficient code otherwise.

But lets discuss this on the issue tracker to not go too far off here.

----------

## Anon-E-moose

Seems like GKH is trying to earn his money from RH

 *Quote:*   

> Add kdbus branch to linux-next?
> 
> Hi Stephen,
> 
> Can you add the:
> ...

 

What a whore!!!

Edit to add:

A whore being someone that sells part of themselves for money,

and IMO Greg has sold his soul for "filthy lucre"

----------

## steveL

 *tclover wrote:*   

> A short POSIX off topic won't hurt this thread after many, certainly.

 

Indeed; it's as on-topic as anything, and this is a chat forum. I don't tend to use web-interfaces these days; I used to love them, but everything's all 5.0-rc_beta1-alpha01-jboss-jquery-argle now.

 *Quote:*   

> First, I was aware of the 'local' POSIX compatibility issue. It's just... convenient to be able use the same relevant variable name in different *local* scope to keep consistency/efficiency on variable naming scheme. Without 'local' keyword, naming *local* scope variable is problematic and could lost possible readers. Unset can be used to unset *local* scope variables but not masking *global* ones--this is the issue here and could lead to confusion.

 

You've misunderstood; I never said "don't use local". I just said "use it portably."

 *Quote:*   

> Second, assigning while declaring variable makes the code concise but... the lack of a comma operator could bring in error prone declarations.

 

Only if you don't know the language; as with any language learn the idioms before you judge anything.

If the idioms change every 3 or 4 years, the language isn't ready.

In some cases (eg if it changes significantly every 3 or 4 years for over 30 years) the designers aren't really designers; they "just want it to work", which is how they threw the language together.

 *Quote:*   

> Regarding the '-a' (AND) and '-o' (OR), the related section uses some examples like `test "$1" -a "$2"' with '$1' asigned to '!' and '$2' to NULL. Such a nice example! I usually do not use that syntax but only with bash! for obvious reasons when relying on an unknown sh[ell] (POSIX compliant or not.) I always use test operand like '-n', '-z' ... for that making the pointed issue almost irrelevant. Sometimes I _do_ use the syntax you're highlighting on the previous example but it become heavy in scripts using that syntax quite often.

 

Huh? The variant I put up is much lighter in terms of following what's happening.

 *Quote:*   

> So, a preference goes to '-a'/'-o' on plain sh with the previous cautious usage.

 

Not following that at all. If you got rid of all the redundant braces, you'd be able to see what you're doing a lot better, as well as giving others (including yourself 6 months later) less cognitive load.

Still do what you want; I'm sincerely not bothered at all.

----------

## steveL

 *Quote:*   

> Add kdbus branch to linux-next?
> 
> Can you add the:
> 
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/ kdbus
> ...

 

Yes, because "this is all about us being good guys, and doing everything the right way", see we're humble really.

It's all about getting the right testing done, cos gosh-darn it, we've got the Right Stuff (this isn't a corporate game at all, oh no.. this is the Waltons.)

Just don't talk about things we don't understand like modularity, cohesion and coupling, let alone how to write network apps (we're desktop developers^W^W "kernel-experts", remember.) Or we'll get stroppy, throw a tantrum, and then just wait a week or two and act as if nothing happened.

 *Quote:*   

> The code has been reworked and reviewed many times, and this last round seems to have no objections,

 

You mean no-one cba repeating the same old arguments over and over; funnily enough they think you're going to actually rethink what you're doing, now that the glaring userland problems have been pointed, over 2 major rounds this time, and indeed over the last 5 or so years.

Silly rabbits; they expect good faith. Instead they're going to get another code-dump of most awful ordure, then be told it's their fault as "it's in the kernel now," so let's you all just hurry up and make it work so I can sell the sizzle not the sausage, and we marketing bods can take all the money while we're about it. After all, no sales, no business.

You work for us now, not the other way round. "Like my Lamborghini? No you can't touch it, back to work, prole!"

 *Anon-E-moose wrote:*   

> What a whore!!!
> 
> Edit to add:
> 
> A whore being someone that sells part of themselves for money,
> ...

 

Yeah, like Mark Thomas used to wear a T-shirt saying "meeja hore" on stage.

Still best watch out, the new-age thought-police are on your case.. CoC-2.0(the liars refrain) will be on your tail soon.. ;-)

Huxley was an optimist.

"Good night, Jim bob!"

----------

## tclover

 *Quote:*   

> The code has been reworked and reviewed many times, and this last round
> 
> seems to have no objections, so I'm queueing it up to be merged for
> 
> 4.1-rc1.

 

So all the important questions/queries about the design--ioctl vs. syscals and BIG (meta)data to name the fundamental ones--have been wiped out on cosmetic documentation rewording without any notice on the supposedly NEXT round of the patchset?! WTF, so the *review* is done? And I thought a review was about discussing technical points instead of wording a few sentences.

And where is the ChangeLog of the modifications per review suggestions?! Down in the (hi)story hole?

Is this a bad joke... with last minute important fixes of the USER-SPACE test suite on the LAST round of the "review"?

EDIT(LATS-MINUT-IMPORTANT-FIX[irony]): GOD BLESS RH!

----------

## tclover

 *steveL wrote:*   

> Huh? The variant I put up is much lighter in terms of following what's happening.

 

True if it was a complicated test chain. It's just a test of the controller and parameter name followed by the actual control (supervision) group which should be non NULL to be processed. Well, your splitting may improve reading a supposedly order but... any of those three test is fatal whatsoever might be the other arguments.

 *Quote:*   

>  *Quote:*   So, a preference goes to '-a'/'-o' on plain sh with the previous cautious usage. 
> 
> Not following that at all. If you got rid of all the redundant braces, you'd be able to see what you're doing a lot better, as well as giving others (including yourself 6 months later) less cognitive load.

 

Just stating a preference of using '-a/o' cautiously as stated above because of... yet the braces introduces this heaviness I am talking about. Just decided to go with it since the design embraced a "keep it simple and sane!" approach which brings in quite a few useful features with simple helpers costing a very few lines.

----------

## mv

 *tclover wrote:*   

>  I always use test operand like '-n', '-z' ... for that making the pointed issue almost irrelevant

 

You are wrong: Even if using -n and -z properly, it is impossible to combine it with -a reliably, unless you have checked the content of the variables in advance.

Here is an example: 

```
A='='

[ -n "${A}" -a -n "${A}" ]
```

Your result may depend on the shell; try that e.g. in bash-4.2_p53.

----------

## tclover

 *mv wrote:*   

>  *tclover wrote:*    I always use test operand like '-n', '-z' ... for that making the pointed issue almost irrelevant 
> 
> You are wrong: Even if using -n and -z properly, it is impossible to combine it with -a reliably, unless you have checked the content of the variables in advance.
> 
> Here is an example: 
> ...

 

Right... bash-4.3_p30 fails, BusyBox-1.22.1/ash fails, zsh-5.0.5 (with or without `emulate sh') fails...

EDIT: However... I may or may not update the related lines because... the relevant line is meant to fails for _such_ bad arguments. Phew, that's quite some lucky turns of it.

----------

## steveL

 *tclover wrote:*   

> However... I may or may not update the related lines because... the relevant line is meant to fails for _such_ bad arguments. Phew, that's quite some lucky turns of it.

 

That's nonsense. Just check the arguments before you use them if they're not script literals; that's what shell functions and case are for.

In that way you can just notify the user properly, instead of the script looking borked.

It's like writing any code: you have to check your pre-conditions since, as you say, that is what allows us to fail early and fail hard, so the user can simply sort out whatever the problem is, and try again/restart the service etc.

The first thing my boss made me work on when I started learning bash, was supporting routines to verify our inputs. Most often than not that finds mistakes in my script much more than it does in the inputs.

And you're right, it really does help when you can bail out with decent error messages before the event, and catches our bugs before they happen; and when they do we always get a stack trace(bash), and the user always knows that it is a bug, which saves everyone time.

Hmm thinking on it, we do deliberately allow for some things to fail similarly in configure space, but they're script-internals that are always meant to be integral, not user input.

So we would get error messages if they happen to be rewritten by the application script, to be non-numeric, but we don't check them everywhere, we just use them, specifically because they are not user input, but script-internal (and we want an ugly error message if the script borks them.)

Thus I do see where you're coming from; but you have to draw a distinction between what belongs to the script (because we set it ourselves) and everything else (user inputs, configuration, data from the file-system.) The former is only what we explicitly assigned, or have verified. perl's bless/taint is a nice metaphor for this.

----------

## tclover

 *steveL wrote:*   

> That's nonsense.

 

Maybe not...

You're almost right on every single detail you're covering afterward, stilll...

In this case '$1' is an internal simple '[:alpha:]' word--controller name,--so the 1st/3rd test are done on plain word ('[:alpha:]' & '/'). Now, the only risky one is '$2' which comes from configuration files and normally the test would almost pass if '$2' is !NULL and may start with garbage like '[:punct:]' which is the source of... the issue here. If it's the case--a user configured a controller e.g. 'CGROUP_CPU="= !"' --the following 'while' loop would just die right away and nothing would be done with that garbage--which is the right way to treat this for such a voluntary borkage.

So, leaving it as is for now--I don't see any reason to bother for such a (user) voluntary borkage.

----------

## steveL

 *tclover wrote:*   

> You're almost right on every single detail you're covering afterward, still...

 

Which part was factually incorrect?

 *Quote:*   

> So, leaving it as is for now--I don't see any reason to bother for such a (user) voluntary borkage.

 

Look how much time you've just spent, reasoning out why you might be okay possibly in this instance.

I prefer write once, and forget (until I want to rework it.) 

Write robust, so you can reuse without worry.

----------

## tclover

 *steveL wrote:*   

> I prefer write once, and forget (until I want to rework it.) 
> 
> Write robust, so you can reuse without worry.

 

A good approach certainly.

But it's almost the case here, the risky argument is tested beforehand with '[ -n "$arg" ]' so risky '[:punct:]' won't be coming. Though I did not write the whole thing myself,--this is qnikst's contribution to OpenRC/CGroup,--I've just cleaned it and improved a few things, and then integrated it to supervision service model. I don't bit the robust thing _first_ unless there is a reason to... it. I prefer by far the simple/efficient approach first and then compose what might arise afterwards and THIS put my time on efficient usage instead of looking to perfection and robustness pointlessly--it might come along the way or _never_ (no problem with me.)

I've just took the time to respond to your well meaning and useful inquiries and then found out that it was right to leave it 'as is' unless _actual_ issues arise.

----------

## Yamakuzure

Oh my god, just update that instead of writing again and again why updating it would be a good idea but you won't do it because it is not a problem (now). You certainly are a "yes, but..."-person, right? It only wastes your precious time as a developer. Do it, say "thank you" and move on.

----------

## steveL

 *tclover wrote:*   

> Though I did not write the whole thing myself,--this is qnikst's contribution to OpenRC/CGroup

 

Actually most of the "newer" cgroup code is my script.

The borkage is ofc all Hubbs, who really should be forcibly retired if he refuses to get off the pot.

Especially since he refused to correct the copyright, which I raised with qnikst about a year ago.

No I won't take it up with the same spineless leeches who refused to do anything about his libel.

And no, I'm not interested in suing Gentoo Foundation Inc., either.

----------

## tclover

 *steveL wrote:*   

>  *tclover wrote:*   Though I did not write the whole thing myself,--this is qnikst's contribution to OpenRC/CGroup 
> 
> Actually most of the "newer" cgroup code is my script.

 

Well then you can follow a clean up attempt patch discussion here then. Though, they seem to be notoriously playing dead sometimes, I've set a month duration on bpaste for the patch. And WH found a funny ("tried to apply the patch manually and almost have to edit everything at hand") excuse which is blatantly false for the first patch... I've just played an apparently deaf/(false-)polite hear on it. And then included that single line blocker on the second round.

----------

## saellaven

 *steveL wrote:*   

> 
> 
> And no, I'm not interested in suing Gentoo Foundation Inc., either.

 

Unfortunately, that might be exactly what it takes to knock williamh off his high horse where he's been abusing his position for a long time now while everyone that can do something about it twiddles their thumbs.

----------

## steveL

 *steveL wrote:*   

> And no, I'm not interested in suing Gentoo Foundation Inc., either.

 

 *saellaven wrote:*   

> Unfortunately, that might be exactly what it takes to knock williamh off his high horse where he's been abusing his position for a long time now while everyone that can do something about it twiddles their thumbs.

 

I understand where you're coming from, but it really wouldn't do that; it would just cause more division, and wagon-circling, none of which would help us make better software.

Besides which, I really don't have the time for it. It's hard enough right now to clear any time at all for Gentoo work, due to deadlines and because of the amount I've wasted on it over the last few years (I've been told in no uncertain terms. ;)

Basically I can get time for Gentoo, including at work and using it for work stuff, so long as I maintain my current hiatus from interaction with any official developer channels, apart from the ones I've always hung out in, on IRC. eg I haven't used bugzilla for the best part of a year.

And I have to admit that prospect is rather appealing.

It's not like I ever got any joy out of it, only a load of abuse from whoever felt like it at whatever point, along with accusations of whinging if I let off steam about it elsewhere, or trolling if I answered back (along with a pile-in of vipers abusing official positions).

Too old for that sh1t now.

Thinking back I do recall not quite believing the people who told me how crappy the developer list was, when I first joined the forums. It took me months to first post, but have to admit: they were right.

The freeks took over the show, and they're utter saps when it come to politics in the real-world; the ones who aren't just selling out to corporates as a good career move, usually because they've just left college.

Still who cares, so long as they churn out ebuilds? ;) Eventually they'll learn the basics.

Perhaps that's why there's such a large "silent majority" amongst the developers, as I've been told so often.

I don't understand the mindset that can expect any sort of respect for that, though; and certainly not ego-massages just to behave as well as any 13 year-old girl does on a daily basis -- under much more trying circumstances, in the main.

Plus ca change. ;-)

----------

## steveL

 *tclover wrote:*   

> I've just took the time to respond to your well meaning and useful inquiries and then found out that it was right to leave it 'as is' unless _actual_ issues arise.

 

No it's not. What Yamakuzure said; just look how much time you've wasted solely to argue and reason that a less robust, less generically useful variant is somehow "right". Which you knew was the case before you wasted even more time on it.

The time to sort out the fundamentals is before you distribute it, not after you've wiped the user's hard-drive. (That's a C reference to UB, or undefined behaviour; don't take it literally and start arguing about how this couldn't possibly blah blah blah.)

----------

## mv

 *steveL wrote:*   

> The time to sort out the fundamentals is before you distribute it

 

This is not the idea of open software. Instead: publish as soon as possible so that others can contribute and provide such minor patches. (OTOH, I do not understand why rejecting such a patch which really does no harm and in some corner case might improve things.)

The situation is different, of course, when you mark a release as "stable".

----------

## steveL

 *steveL wrote:*   

> The time to sort out the fundamentals is before you distribute it

 

 *mv wrote:*   

> This is not the idea of open software. Instead: publish as soon as possible so that others can contribute and provide such minor patches.

 

Not true; first you have to know the language you're using before you start unleashing "hello world"-2.0 onto the rest of us.

I'm really not interested in "open software" written by people who haven't learnt how to code yet; not when it comes to delivery, nor distribution.

 *Quote:*   

> OTOH, I do not understand why rejecting such a patch which really does no harm and in some corner case might improve things.

 

Me neither, though we do run into this kind of thing on IRC all the time.

It's almost like it's a point of pride not to concede things could be done better, or something; really I think it's just part of being attached to your work, which is what you have to let go of.

It takes a long time to do that, ime, though some people have that attitude from the beginning.

It's natural for anyone who cares about what they're doing. The flipside is they also usually care about doing things right.

IME you just have to be straightforward, and occasionally blunt to get through.

----------

## tclover

 *steveL wrote:*   

> It's almost like it's a point of pride not to concede things could be done better, or something; really I think it's just part of being attached to your work, which is what you have to let go of.
> 
> It takes a long time to do that, ime, though some people have that attitude from the beginning.
> 
> It's natural for anyone who cares about what they're doing. The flipside is they also usually care about doing things right.
> ...

 

Couldn't be truer for... OpenRC team/upstream. These guys threw the same *mantra* of FORM-BEFORE-CONTENT several times on me before closing bug/issue without taking a look at the patch.

Oh boys, are they just a bunch of Kings--that want anybody before them to kiss their feet before engaging in any meaningful discussion--or something?!

Just opened another bug then and wait their... reaction--just do not hold your breath. LULZ

----------

## depontius

Speaking of kdbus in the kernel, which we haven't been for a few posts now, there has been stunningly little feedback on the V4 release.  Only a few minor suggestions, which have generally been accepted with thanks.  No discussion of the design point, or anything like that.  With absolutely no possible conflict of interest, Greg KH has directed that it be pulled into linux-next for inclusion as part of linux-4.1.

So at one end of the spectrum we have a subsystem flawed at the specification level getting fastpathed into the kernel.  At the other end we have debate about fine points of shell scripting delaying a subsystem which I strongly suspect is already in far better shape than kdbus.

There has got to be a happy medium somewhere in there.

----------

## Anon-E-moose

 *depontius wrote:*   

> Greg KH has directed that it be pulled into linux-next for inclusion as part of linux-4.1.

 

Making it into linux-next doesn't mean that it will be "included" in the 4.1 release.

There were some performance questions, last week, but haven't seen any real answers back yet.

----------

## depontius

It's not April 1 yet, but...

The systemd Project Forks the Linux Kernel

http://distrowatch.com/weekly.php?issue=20150330#community

----------

## bstaletic

depontius,

How nice of them! They're going to leave linux users alone and can use they're own systemdOS.

----------

## Anon-E-moose

It would be for the best if it wasn't a joke.

That would fix all the problems, for those that want they could run Pottering OS

and the rest of us could continue on with the linux we've known for a long time.

----------

## ct85711

Hopefully what they will do next, is make it so only Red Hat can use systemd, forcing everyone that wants to use Gnome & systemd has to use Red Hat's distro, so everyone can finally forget about this trash and get on with having a system that actually works.

----------

## grot

Phoronix counters that the systemd devs did not actually fork the linux kernel - that Ivan guy is not a systemd developer. http://www.phoronix.com/scan.php?page=news_item&px=Systemd-No-Linux-Fork

I'm curious if there's more to this - how often are mistakes like this made?

rofl - just found this https://github.com/systemdaemon/systemd/issues/1

edit: just saw this link was already put up in the politics of systemd thread

----------

## Anon-E-moose

http://lkml.iu.edu/hypermail/linux/kernel/1503.3/04981.html

 *Quote:*   

> In general, there seems to be a number of misconception in this thread
> 
> about what kdbus is supposed to be. We're not inventing something new
> 
> here with a clean slate, but we're moving parts of an existing
> ...

 

They simply want to shove the crappy dbus code into the kernel "hoping" that it will make dbus faster.

They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel. 

*sigh*

----------

## steveL

 *Anon-E-moose wrote:*   

> They simply want to shove the crappy dbus code into the kernel "hoping" that it will make dbus faster.
> 
> They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel. 

 

Ah but we're in the world of shifting goalposts, and pretext rather than craft since this is all about "modern" business-methods (and "strategy"), not about delivering great software.

Now the reason it "must" be in kernel is "race gaps that exist when retrieving per-message metadata", which arise from dbus' idiotic implementation in userland, and reimplementing a borked "semantic" that must be preserved even though it flies in the face of all sense. As discussed to death in earlier iterations, including when the networking guys told them five years ago, just to use TIPC.

The simple truth is that Linux already has a much better "kdbus" in-kernel, well-designed and tested for 7 years before it even came near the kernel in 2000.

The sad fact is that the self-styled "kernel experts" who are in fact kernel-rejects and a documentation guy, have no clue about userland programming either, and thus are still trying to "fix" their broken metaphor by pushing it into kernel-space, a la Windoze -- when they should be rethinking their userland lunacy ("because userland can do crazy things, we do all of them.")

The only reason RedHat are pursuing it, is so that dbus GPL-evasion is baked into the kernel, and supported forever more (never to be questioned again.)

After all, they control the userland now, what with the pretty much "industry"-wide capitulation to systemd in bindists. Oh wait. ;)

----------

## Ant P.

 *Anon-E-moose wrote:*   

> They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel.

 

Of course they won't - improving the userspace DBus would give all Unixes an equal playing field, and Redhat is currently trying to murder the competition through tighter and tighter bundling.

Very Microsoft of them.

----------

## Anon-E-moose

http://lkml.iu.edu/hypermail/linux/kernel/1503.3/06122.html *hmm*

 *Quote:*   

> I've heard the following use cases for per-connection metadata:
> 
> - Authenticating to dbus1 services.
> 
> - Identifying connected users for admin diagnostics.
> ...

 

*chuckle* moving the goal post seems to be the kdbus peoples forte

 *Quote:*   

> This all feels to me like a total of about four people are going to
> 
> understand the tangle that is kdbus security, and that's bad. I think
> 
> that the kernel should insist that new security-critical mechanisms
> ...

 

I don't think they want people (other than themselves) to understand the code.

And of course they have no desire to use it correctly.

It's their wedge to get into the kernel, since Linus has slapped Kay's hand far too often

and they need a way to "bypass" Linus saying "no" to their requests.

I do believe that Linus and others will see this for what it is, 

and make them either do the right thing or abandon kdbus completely.

----------

## pjp

[split] chaff from kdbus in the kernel

----------

## Shamus397

Hrm, looks like it's going in: http://lkml.iu.edu/hypermail/linux/kernel/1503.3/00378.html

If it were me, I'd have it read "if you have an ordinary machine, choose N here"...  :Razz: 

----------

## asturm

That is from two weeks ago, so nothing new just now. kdbus is in linux-next to receive more testing, but that doesn't mean it automatically goes into mainline.

----------

## steveL

Yeah nothing to worry about; just keep looking into my eyes, not around the eyes..

After all, it's not like anyone would dream of turning around later and saying "Well you had your chance; no-one responded to the 5th round of sales-pitch, so we put it in, you should have spoken back then" and other variants on "it's all your fault, suckers!"

Just deal with it, move on, etc; all the things we don't do, when we want to make y'all get in line.

----------

## asturm

I was merely preventing the thread from entering a sub-loop duplicating from this comment by repeating what Anon-E-moose had said himself. But if you disagree, go on!

----------

## Anon-E-moose

I'm still seeing a couple of kernel devs who aren't too thrilled with kdbus as it is at the moment, so I doubt that it will go in until things get hammered out.

And again, just because it's up for review that does not mean automatic inclusion in the kernel

----------

## asturm

Now, that happened: https://lkml.org/lkml/2015/4/13/645

----------

## depontius

 *genstorm wrote:*   

> Now, that happened: https://lkml.org/lkml/2015/4/13/645

 

IIRC, it's been in linux-next for less than a month, unless the pull request I saw only a few weeks ago wasn't the first.  Does someone really need to look this up?

----------

## Anon-E-moose

 *genstorm wrote:*   

> Now, that happened: https://lkml.org/lkml/2015/4/13/645

 

Reading it now.

Some of the kernel devs don't like kdbus (or the people working on it) much.  :Laughing: 

Andy L says

 *Quote:*   

> Kdbus is very much a port of userspace dbus to the
> 
> kernel, and it appears to be a port designed to preserve some
> 
> questionable design decisions instead of learning from them.

 

Pretty much what a lot of us have been saying. 

Will see how GKH responds to his critique.

A gem from Andy

 *Quote:*   

> The fact that some existing userspace does awful things does *not*
> 
> justify adding new kernel mechanisms with which to repeat those
> 
> mistakes.

 

He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF)

----------

## depontius

 *Anon-E-moose wrote:*   

> 
> 
> A gem from Andy
> 
>  *Quote:*   The fact that some existing userspace does awful things does *not*
> ...

 

Oh, he's just a hater!

(Some people would take a statement like that seriously, and consider it reason to discount Andy's statement.  That's sad.)

----------

## Naib

 *depontius wrote:*   

>  *Anon-E-moose wrote:*   
> 
> A gem from Andy
> 
>  *Quote:*   The fact that some existing userspace does awful things does *not*
> ...

 this is when the CoC is thrown in his face to dismiss his statement

----------

## steveL

 *Anon-E-moose wrote:*   

> Will see how GKH responds to his critique.

 

By talking past his points, instead of addressing them, casting aspersions on the "doubter" wrt dodgy benchmarks (ironic when you consider on whom he's casting doubt) and neatly excising the summary and NAK so he can pretend they didn't happen.

 *Andy Lutomirski  wrote:*   

> The fact that some existing userspace does awful things does *not*
> 
> justify adding new kernel mechanisms with which to repeat those
> 
> mistakes.

 

 *Quote:*   

> He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF)

 

Kroah-Hartman's approach to dissenting opinion isn't very programmer-like, imo. Thankfully, Lutomirski was having none of it in the mail you quoted:

 *Quote:*   

> Then I'll have to find a way to embolden my NACK further.
> 
> The design is bad, full stop.

  (ordering changed)

The only bit that concerns me is where he stated "I generally like the concept of having a better in-kernel IPC mechanism" as it implies he isn't aware of TIPC, nor the previous discussion in 2012, when the networking people advised them to use it.

ie: there already is a better in-kernel IPC mechanism. (cf also: SOCK_RDM.)

----------

## Anon-E-moose

The biggest thing I've noticed is that some of the kernel devs have mentioned (several times) 

that dbus could possibly be speeded up with a look at how it's implemented internally.

The *bus devs have been refusing to do this.

So it's obvious, at least to me, that they want kdbus in the kernel not for any real speedup but for other reason.

And yes, many of them have been brought up in these threads, ie bypassing the gpl, etc.

I doubt that I'm the only one that is seeing things this way. 

And we've yet to hear Linus' view on kdbus.

Of course he may be waiting to see if it even makes muster, ie gets past the kernel devs with the NAKs.

----------

## depontius

Greg KH's pull request says kdbus has been in linux-next "for several months".  This seems disingenuous to me.  A quick check with Google, and it appears that the pull request for linux-next was around March 15, just under one month ago.  The initial patches appear to have been first submitted back in October, about six months ago.

All else aside, does anyone know what the "average latency" is for a new large-ish feature to get added to the kernel?  Six months from first patch actually seems kind of fast.

To be honest, I (sadly) expect kdbus to go in, maybe on 4.1, maybe on 4.2.  I expect the real fireworks to happen when they expect to treat the kernel code with all of the stability of the rest of systemd.  Come to think of it, I don't know how stable userspace dbus has been, if it's been more stable than the rest of systemd.

----------

## mv

 *depontius wrote:*   

> All else aside, does anyone know what the "average latency" is for a new large-ish feature to get added to the kernel?  Six months from first patch actually seems kind of fast.

 

For unionfs/unionmount/aufs/overlayfs it took about 10-15 years or so - despite being used (and needed to be patched in) by dozens of distributions since many years - I think nobody ever had any doubts that this feature is useful - and still only the most primitive of these (overlayfs) is in the kernal, finally.

Similarly, compression for ext2 took so many years of continuous request that the maintainer finally gave up.

squashfs with lz4 took a year, even after squashfs+lz4 was in the tree.

I never understood, why such useful features needed so many years to become included (I mean: after they have been written and been well-tested).

Then everybody knows how it was with reiser4 which is still not in the kernel, and probably will never be.

Of course behind these, there was not the pressure of money and power.

----------

## Naib

 *mv wrote:*   

> 
> 
> I never understood, why such useful features needed so many years to become included (I mean: after they have been written and been well-tested).
> 
> 

 

Its a very passive way to prove whether what is being requested to be added (till the end of time) is actively being used AND is stable from a userspace point of view.

That has at least been a constant push from the kernel lot - don't break userland.  If a kernel module has been around for years AND is being used/depended upon & only the kernel facing API/ABI breaks & is updated then that is a very nice tick.

cgroups was a nice idea but (poorly implemented and now there is talk of a parallel implementation so userland depending on cgroups is not broken...) do we really want that from kdbus which is soo needed applications just do not work

----------

## mv

 *Naib wrote:*   

> That has at least been a constant push from the kernel lot - don't break userland.  If a kernel module has been around for years AND is being used/depended upon & only the kernel facing API/ABI breaks & is updated then that is a very nice tick.

 

Concerning the mentioned filesystems/filesystem features, they satsified all these conditions for many years and nevertheless haven't been included for many years.

Compared to this, I was really surprised how quickly cgroups had been included.

And now seeing something being pushed through, practically untested, actually undesired, when the same thing is already implemented better in the kernel (as SteveL pointed out here, several times) - it is really unbelievable and only explainable through the enormous market power of RedHat.

Edit: Fixed typo in the first sentence which made it not understandable.Last edited by mv on Wed Apr 15, 2015 1:12 pm; edited 1 time in total

----------

## Anon-E-moose

Just read this from Andy in reply to GKH and just about spewed my drink

 *Quote:*   

> I find myself comparing kdbus to win32k, and that's not a good sign...

 

 :Laughing:   :Laughing:   :Laughing: 

----------

## arnvidr

The discussion on the list seems clear that it cannot be merged for 4.1 at least, and they're talking about discussing it on some conference now, this summer. Because several of them are still wondering why this should be in the kernel (and why the design is so messed up).

Greg K-H's arguments seem really useless to me, "it is that way because dbus is that way". And naturally getting "fix the bad design before trying to put it in the kernel" reply.

----------

## steveL

 *arnvidr wrote:*   

> Greg K-H's arguments seem really useless to me, "it is that way because dbus is that way". And naturally getting "fix the bad design before trying to put it in the kernel" reply.

 

Yeah, he's beyond disingenuous, imo; he simply keeps referring people back to previous answers that haven't been given; eg: in response to this mail (which is expanded on here.) Someone tell me where he "addresses these misconceptions" please. (Note, as usual, the language implies it's all just a misunderstanding on the part of the "doubter".)

As a result the discussion just goes in circles.

Finally when everyone's had enough, we'll hear the "no more objections were made" and later it will be presented as "all technical objections were responded to and dealt with," even though the responses were woefully inadequate.

I don't hold out much hope for the "summer conference" resulting in anything other than a woozy "Greg's all right" (he bought me a pint) decision on the part of people who understandably want to believe the best of others. 

So I'd guess we'll be testing the config option to disable the crapfest soon enough, irrespective of how bad a technical and design decision it might turn out to be down the road.

----------

## Naib

For reference when overly complicated BS gets into kernelspace "to make intercommunication easier"

http://tech.slashdot.org/story/15/04/15/1359225/remote-code-execution-vulnerability-found-in-windows-http-stack

Windows put font raster management into the kernel "to speed it up"  it then was a nasty vuln into the system. If the only valid arguement is "for speed" then well  :Wink: 

----------

## gwr

 *steveL wrote:*   

> 
> 
> Finally when everyone's had enough, we'll hear the "no more objections were made" and later it will be presented as "all technical objections were responded to and dealt with," even though the responses were woefully inadequate.
> 
> 

 

This is what I think is going to happen. Almost every thread just peters out after a long stream of objections, questions, and critiques are ignored. It's a war of attrition and eventually the kernel devs will surrender.

----------

## Anon-E-moose

The "discussion" between GKH and the kernel devs seems to be heating up. (it can all be gotten to by the lkml link)

 *Quote:*   

> > Look, us kernel developers only work on one huge, multithreaded, global
> 
> > state binary.  Our experience in multi-application interactions with
> 
> > shared state and permission requirements is usually quite limited.  If
> ...

 

----------

## Anon-E-moose

And another kernel dev

 *Quote:*   

> On Wed, Apr 15, 2015 at 01:40:36PM +0200, Greg Kroah-Hartman wrote:
> 
> > 
> 
> > You have to trust someone to help make your system work together in a
> ...

 

----------

## Anon-E-moose

Steve has this to say in another post

 *Quote:*   

> ...Is there a reason that this patch must go in this merge window? Having
> 
> something this controversial take place during the merge window
> 
> suggests its a bit premature to push in now. Especially since it
> ...

 

I think the big hurry is that GKH knows that if people take the time to 

really look at it, then there is no way in hell of it getting into the kernel in

it's current form. Something they desperately want, it seems like

----------

## gwr

 *Anon-E-moose wrote:*   

> And another kernel dev

 

I'm pretty ignorant about how these things work. How much of a difference does it make that kernel devs raise flags? Do any of them have the authority to prevent kdbus from being included in the kernel?

----------

## Anon-E-moose

As of right now there are 2 NAKs for inclusion and no ACKs.

If GKH and comrades can't convince the kernel devs what are the chances of Linus accepting the code. He's even pickier than them.

----------

## Anon-E-moose

 *Quote:*   

> On Wed, Apr 15, 2015 at 10:44:40AM +0200, Greg Kroah-Hartman wrote:
> 
> > If you really don't like userspace using features the kernel provides
> 
> > you, well, there's nothing I can say that will change that odd feeling,
> ...

 

Wonder when the CoC will be invoked.   :Rolling Eyes: 

----------

## gwr

 *Anon-E-moose wrote:*   

> As of right now there are 2 NAKs for inclusion and no ACKs.
> 
> If GKH and comrades can't convince the kernel devs what are the chances of Linus accepting the code. He's even pickier than them.

 

Thanks. Is there a number of ACKs that are required, or is it a percentage of people who get say?

----------

## Anon-E-moose

This is a great read by Alan and a valid set of reasons for not letting kdbus in as it exists.

 *Quote:*   

> On Wed, 15 Apr 2015 00:39:22 +0200 (CEST)
> 
> Jiri Kosina <jkosina@xxxxxxx> wrote:
> 
> > On Tue, 14 Apr 2015, Greg Kroah-Hartman wrote:
> ...

 

----------

## Anon-E-moose

From Al Viro

 *Quote:*   

> On Wed, Apr 15, 2015 at 01:49:36PM +0200, Greg Kroah-Hartman wrote:
> 
> > > There is no comparison between the elegance of X11 property setting and a
> 
> > > chunk of proposed kernel code that is half the size of a tiny X server!
> ...

 

Oh boy, I'm waiting till I see Linus' response over this   :Laughing: 

----------

## Anon-E-moose

Linus chimes in

 *Quote:*   

> On Wed, Apr 15, 2015 at 11:11 AM, Greg Kroah-Hartman
> 
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Wed, Apr 15, 2015 at 01:33:27PM -0400, Steven Rostedt wrote:
> ...

 

and added this in the next email

 *Quote:*   

> On Wed, Apr 15, 2015 at 11:18 AM, Linus Torvalds
> 
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> >
> ...

 

----------

## gwr

In answer to Linus, GKH posted this. He never did follow up on it, which is typical of all of these types of questions.

I find it inconceivable that people who have spent this much time and effort writing something for supposed performance improvements do not have any published measurements.

 *Quote:*   

> Someone from BMW did the testing on one of their car systems a while ago
> 
> and posted some numbers, it was a factor of 10 faster.  I'll try to dig
> 
> it up, but it was burried in a powerpoint presentation, so it might be
> ...

 

----------

## ulenrich

While kDbus gets delayed the kernel guys tasted blood now! They want a more general approach to better achieve what steveL described as "circumventing the GPL":

 *Quote:*   

> For me the biggest issue is the container problem: it's really hard to
> 
> containerise kdbus because of the stateful nature of the protocol and
> 
> the fact that it has a well known system bus. Separation into domains
> ...

 

 *Quote:*   

> We can however leave it in userspace [Alan talks about the policy part] until we understand the right small
> 
> clean way to support it and other needs. At the moment for example
> 
> cluster people can't really use this stuff because its not network aware,
> ...

 

 *Quote:*   

> > In filesystem terms
> 
> >
> 
> > - stop writing a dbus only file system
> ...

 

----------

## bstaletic

ulenrich,

How is that circumventing GPL? It sounds, to me at least, as if kernel developers are saying "Let's leave everything as is and build a sane IPC protocol". Which is fine with me.

----------

## steveL

 *ulenrich wrote:*   

> They want a more general approach to better achieve what steveL described as "circumventing the GPL"

 

*Sigh* what nonsense.

You don't seem capable of distinguishing the argument (about "unintended", or rather unmentioned effects) from the implementation (of IPC: which is not RPC.)

By all means witter on; just keep my name out of it unless you have a clue what you're talking about.

----------

## Shamus397

And (who I presume to be) Alan Cox comes in with a smackdown:

 *One Thousand Gnomes wrote:*   

> > Don't make idle comments, the tty layer is far more complex and larger
> 
> > than the kdbus code, with much nastier issues and problems. And we
> 
> > handle that just fine 
> ...

 

Good to know that the kernel devs aren't so easily buffaloed as (ahem) others have been.  :Very Happy: 

And it gets even better:

 * Eric W. Biederman wrote:*   

> > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> 
> >> Here's the kdbus pull request for 4.1-rc1.
> 
> >>
> ...

 

Also, for those who missed Andy's first NACK, here's a link.  :Very Happy: 

----------

## Shamus397

That thread is full of gems, and it seems that GKH just refuses to take no for an answer, no matter what anyone tries to tell him:

 *One Thousand Gnomes wrote:*   

> > operating systems anymore. Those "legacy" oses provide a system bus
> 
> > that allows them to send thousands of queries just fine, but when moving
> 
> > to Linux, we don't have anything other than D-Bus, so their library is
> ...

 

It would seem if Alan Cox is telling you that your code is broken, it would behoove you to take what he says seriously. But only if your name is not GKH, apparently.  :Smile: 

But wait! Al Viro has this to say in reply to Andy:

 *Al Viro wrote:*   

> On Wed, Apr 15, 2015 at 01:22:12PM -0700, Andy Lutomirski wrote:
> 
> > This leads me to a potentially interesting question: where's the
> 
> > buffering? If there's a bus with lots of untrusted clients and one of
> ...

 

AF_TWITTER!  :Very Happy:  Seems that the kernel devs really do get it.  :Very Happy: 

----------

## ulenrich

 *Shamus397 wrote:*   

> It would seem if Alan Cox is telling you that your code is broken, it would behoove you to take what he says seriously. But only if your name is not GKH, apparently. 

 

Alan says the concept is broken. (If it only was the code there was no need for plumbers conferences)

GKH says the concept is needed and proven with dbus since years. The only problem remaining with dbus he solves with his kdbus implementation (race condition).

Perhaps the policy problem can be abstracted into something similar to a firewall: All of it (capabilities, rules, roles etc) translated into an address space of numbers and then filtered. Reading that policykit rules now you might think you'll understand the impact, because it seems to be plain english language. But the effects of inherited capabilities you won't recognize yet.

----------

## krinn

 *gwr wrote:*   

> In answer to Linus, GKH posted this. He never did follow up on it, which is typical of all of these types of questions.
> 
> I find it inconceivable that people who have spent this much time and effort writing something for supposed performance improvements do not have any published measurements.
> 
>  *Quote:*   Someone from BMW did the testing on one of their car systems a while ago
> ...

 

I think i'm bettter than him at googling  :Smile: 

Here's the powerpoint presentation he should refer to : https://github.com/gregkh/presentation-kdbus/blob/master/stuff/EG-SI-IPC%20CommonAPI%20CPP.pptx?raw=true

Of course i'm not him, so it might not be that source, but i don't think there's that many ppt presentation made by bmw guys that shown some benchmarking results.

Look at page 21: 3.6x improvement speed, first it's not 10x (yeah, numbers climb by themselves every times someone use them, but well 3.6x isn't that bad still).

The problem is that it doesn't gave any fact, but numbers, nowhere you can see tests procedure, just "suppose true" results ; so nobody can claim this result are flaw or true anyway. And you are leaved to guess what the "guys" (bmw guys?) did to find those numbers.

Here's what we got:

1/ "measuring empty messages (no playload) to compare network performance rather than marshalling performance"

The thing i notice here: comparing "empty message" performance vs "marshalling performance" can gives real different numbers, while if dbus doesn't use any trick to improve it, systemd-libdbus may have ones (more recent code and assuming they learn from dbus) and as such could get an even more better (marshalling) performance gap between them, and it could be really 10x better or more.

But if the numbers you get aren't that good, it is just better to not speak about them... So even if we assume the tests were fairly made, they only prove systemd-libdbus is better with empty message than dbus, but the "hidden" or not done tests about real test scenario with "not empty message" can lead to a different kind of result: it could be really better, but it could also be really, really worst result.

2/ "Comparing to dbus-ping using AF-BUS"

It is strange to see two results: "libdubs, afbus, clone" vs "systemd".

Assuming clone and libdbus share same performance, i expect to get 3 results still: "libdbus, clone" "afbus" and "systemd".

It look suspect that "afbus" get the same result as "dbus", it prove AF-BUS doesn't improve performance or that if you assume everyone claims AF-BUS improve performance, how can you endup with dbus result (2074) the same as AF-BUS one?

But maybe the guys added unneed "," and the result is about "dbus + clone + AF_BUS"... or maybe indeed AF-BUS doesn't improve numbers when you test the framework only. It is not very clear.

3/ That's not that good to provide numbers without knowing the nature of those numbers: 2074 vs 7407, but 2074 what? potatoes? eggs? ms? seconds? hours???

While everyone can see indeed 7407 is greater number than 2074, if those number refer to latency, than 2074 is really a better number...

Without knowing what those numbers are, we can only assume 7407 "something" is better than 2074 "something" because the guys claims it is.

At least it prove one thing: seeing how the results are given in a real unprofessional way, it raise question about their "professional" way to do the tests too.

4/ Finally i will classify this as bullshit claims without proof, it is numbers given without procedure to check them, in a test you cannot reproduce yourself to see if the results are good or bad (even if you assume someone tests are done fairly, it is not "normal" that the procedure use to made the tests is not given, just to enable somebody else to redo the tests to confirm no mistake were done in the procedure).

5/ Now that GKH is referring to this document (if it is really this one, as remember he might not refer to this one), i see it more like the classical systemd propaganda (see common practice), Mr X do a bullshit document, now refer to it, as long as you are not Mr X it should prove in everyone minds your claims are true, as your claims are backup by another source. Of course not "everyone" will trust you because of Mr X's obscure claims were done in his document, but you don't need to convince everyone, but if you can get all the mass to get convince because they don't question your claims, you win.

So what about the remain "few" that you didn't convince?

Don't worry, the mass cannot be wrong, not only the "few" will be see as wrong, but the mass itself will do the work for you: just wait, one of the poorest minded in the mass will certainly post a message against the "few" with some "haters" tag in it ; few are haters and get discredit ; you win again! thanks to your unconditional fans.

While this is proven good tactic, it start to get weak if the mass have some brains, or if the "few" have names...

So that tactic sure works with systemd and lamba users, but when the mass are kernel devs, it start to show its limit, and it is even worst when the "few" have names like alan cox.

I will endup with this: look at page 20 in the same presentation.

It gave you another hint on something: "Kernel based to ensure security isolation".

What it gave is the real difference from kdbus vs dbus, because of the "security isolation" kernel may gives (again: no proof there, it is just a claims from systemd devs kdbus will be more secure because in kernel, i personally think with my own logic that anything in kernel is less secure, the application itself "might" be more secure as the kernel will protect it, but at a cost, and this cost is less secure kernel that would carry your insecure code. So for me, adding something in kernel to get protection from the kernel will higher your security at the cost of lowering the kernel security itself ; not really something i see as a "good deal", but i don't think it's something that someone that ask you to reboot your system to update his software really care about).

The biggest second thing to notice here is that the kdbus design is more about be in kernel than anything else.

It mean they (i'm unsure english have the same reference, but here's the french one) "sell the bear skin before killing it". If kdbus isn't in kernel, there's no kdbus concept at all. If kdbus isn't in kernel, it's a dbus++ not kdbus.

So even if its the greatest shitty concept or code made so far, you must have it in kernel, else it is dead.

It is a "designer" problem, you don't need good code or working implementation or anything, you need to have it in kernel (dot) ; that's the whole point of kdbus, be in kernel, this is how they are selling it to everyone, and this is why it must be in kernel ; at any costs...

This is something that should scared the kernel devs the most...

ps: found the link to that ppt from https://lwn.net/Articles/551969/

interesting in it is that quote  *Quote:*   

> "Kroah-Hartman's conclusion is that "if you want a faster D-Bus, rewrite the daemon, don't mess with the kernel".

 

----------

## ulenrich

@krinn,

that performance comparison was not about kdbus, but as stated in the power point presentation:  *Quote:*   

> Early benchmarks of systemd´s D-Bus client library on Pandaboard:
> 
> dbus-ping-systemd and dbus-test-service-systemd
> 
> Measuring empty messages (no payload) to compare framework performance rather than marshalling performance
> ...

 

about using dbus via an optimized systemd dbuslib compared with pings using AF-Bus and then a gateway to dbus. The presentation intended to move the audience to _only_ use dbus without any gateway needed. Because the numbers perfectly fit what developers expect an outcome of performance gain with kdbus (x-times less copying the messages) this mentioning of that old presentation of 2012 is due to human remembrance short-circuit. A further hint is times, the LWN article of 2013 says abaout kdbus: "Kdbus will require a recent kernel as it uses control groups (cgroups); it also requires some patches that were only merged into 3.10-rc kernels" ... which wasn't 2012.

These kind of optimizations in 2012 motivated GKH to say: "if you want a faster D-Bus, rewrite the daemon, don't mess with the kernel". Which he mentions in the kernel mailing list thread to have said but he changed his attitude. 

In the article you linked, it is explicitly written what big money stood behind kdbus development:

https://lwn.net/Articles/551969/  *Quote:*   

> The automotive industry will be particularly interested because it is used to using the QNX message passing, which it mapped to libdbus. It chose D-Bus because it is well-documented, well-understood, and is as easy to use as QNX. But, it doesn't just want a faster D-Bus (which could be achieved by rewriting it), it wants more: namespace support, audit support, SELinux, application separation, and so on. 

  regarding this motivation the article you linked claims:  *Quote:*   

> in the kernel, kdbus gets a number of attributes almost for free. It is namespace aware, which was easy to add because the namespace developers have made it straightforward to do so. It also integrated with the audit subystem, which is important to the enterprise distributions. For D-Bus, getting SELinux support was a lot of work, but kdbus is Linux Security Module (LSM) aware, so it got SELinux (Smack, TOMOYO, AppArmor, ...) support for free. 

 

The article further describes the status of the kernel side in 2013, memfd was not merged:  *Quote:*   

>  and then Heo came up with zero and one-copy. He would be happy if it is merged by the end of the year, but if it isn't, it shouldn't stretch much past that, and he encouraged people to start looking at kdbus for their messaging needs in the future. 

 

Now in the kernel mailing list they are discussing distinct issues regarding kdbus. Both are worth the time to delay kdbus:

1. Alan Cox is reiterating what the LWN article mentions GKH said at the time:  *Quote:*   

> Kdbus ended up with a naming database in the kernel to track the message types and bus names, which "scared the heck out of me", Kroah-Hartman said.

  This a very conceptual thing I hope some kernel developer, who will participate that planed conference in summer, has an illuminating new idea to better handle it:  policy is awful complex

2. kdbus is not capable to be use beyond the local system domain. It should be splited in layers. Thus parts of it can be reused for other purpose. If kdbus gets into mainline Linux as it is now it is for limited purpose like so much dead end crap you can find in the kernel. 

[edit] to not provoke the Gentoo user forum community as Neddy requested I remove my trolling in the last line of this postLast edited by ulenrich on Sat Apr 18, 2015 1:13 pm; edited 2 times in total

----------

## NeddySeagoon

ulenrich,

If only you had not added that last line, the rest of your post might have stood on its technical merits.

That last line makes me doubt that the rest of the post is honest and unbiased.

----------

## steveL

What technical merits? All he's doing is the usual "repeat some of what you've already heard to make it sound like I've said something."

Utter nonsense as usual.

----------

## krinn

 *ulenrich wrote:*   

> [edit] to not provoke the Gentoo user forum community as Neddy requested I remove my trolling in the last line of this post

 

If you post that trolling message because you think i was trolling, i wasn't, but i really don't think that many bmw ppt exist with benchmark related to lib/k/dbus ; and GHK might have done himself the same error as me and refer really to that doc.

At least, please take time to reread it, you'll see i have put some warning that i'm of course unsure it is really the doc he is speaking about.

----------

## NeddySeagoon

steveL,

Technial merits was probably the wrong term.  Self consistent would have been better.

Its perfectly possible to make a self consistent argument that is based on one or more false premises.

Like this.

dbus and its would be successor kdbus are both a load of dingos kidneys.  

Thats an assertion based on my opinion, which may or may not have any basis in fact.  As its an opinion, I'm not required to support it or defend it.

----------

## steveL

Neddy: indeed; insanity is often self-consistent. It's only when you question the flawed premise, typically a part of the background that everyone takes as read, that you trigger the defensive strikes.

In systemd's case the biggest flawed premise is that "shell is bad" (leading to the dumbass conclusion: "let's use javascript instead".)

----------

## ulenrich

 *krinn wrote:*   

>  *ulenrich wrote:*   [edit] to not provoke the Gentoo user forum community as Neddy requested I remove my trolling in the last line of this post 
> 
> If you post that trolling message because you think i was trolling, i wasn't, but i really don't think that many bmw ppt exist with benchmark related to lib/k/dbus ; and GHK might have done himself the same error as me and refer really to that doc.
> 
> At least, please take time to reread it, you'll see i have put some warning that i'm of course unsure it is really the doc he is speaking about.

 

No, no I didn't talk about you in the last sentence I removed. And for sure GKH has done the same error "remembering" that power presentation. I was just doing a little detectives work by looking up the years (2012 of the presentation and 2013 of the LWN article).

Today sitting in the sun thinking, 

@krinn, what performance test do you want: If kdbus reduces copying the messages from four to just one copy, the test depends on the size of the messages. If you benchmark empty ping messages, you probably will have less performance difference to user space dbus. If you take big messages your benchmark probably will show a four times faster kdbus. Not much news a benchmark would tell, what do you think should be tested? 

The little thing trollish of your post was at the end saying in seven sentences : kernel dbus not in the kernel is not kernel dbus.

It seems quiet clear to me what motivations play the game here:

- The BMW, automotive guys want 

a) big messages

b) extra secured by kernel means for their new live saving techniques in cars

- The Gnome wants

c) responsiveness of cut down in little pieces desktop parts (symbolize a dbus action with a pipe and imagine the messages pure ascii and the unix veteran becomes a Gnome fanboi)

- Poettering wants to

d) get rid of his "special" units by providing that typical systemD mechanism he would like to proudly present from the first init part at boot. 

- The container buisiness wants 

e) a more general solution kdbus cannot deliver

- Everyone wants a

f) secure kernel. But having so many different security/policy subsystems - mostly layerd orthogonal to each other - shows: We have a problem not solved in sober principles.

- /me wants 

g) a first step to the foundations of artificial intelligence: A way all the different units lying around me and in my body, in my car and cloth can work together in a secure way (... coming up next more soonishly you may think)

... it's hot in here, the roof is on fire.

----------

## krinn

 *ulenrich wrote:*   

> @krinn, what performance test do you want

 

Well, actually none, i'm not the one asking any tests ; but GHK gives tests results to backup his claims of better performance.

If you start using test result, i will ask you the test procedure to be able to check your claim, else everyone could claim random result, and while you say you found 100x better speed, i could answer i found myself 10000x time slower result testing the very same part as you.

I don't think Linus is asking anything else, GHK claim something, Linus wants see how to check it's true.

 *ulenrich wrote:*   

> The little thing trollish of your post was at the end saying in seven sentences : kernel dbus not in the kernel is not kernel dbus. 

 

Ah ok, that's the part you find trolling, well, here's why i said that:

Nowhere to be found anything about security of kdbus, except because it is in kernel ; so the kdbus security might be 0, and its security is only given by the kernel. So if kdbus isn't in kernel, the security argument is gone, and without this one, kdbus looks empty or at best, poor.

You may find that trolling to say kdbus have 0 security, but can you tell me about kdbus security then? Because all i see (of course i didn't dig it, as i'm not interest in kdbus myself) is that kdbus is secure by being in kernel. This might not be the reality, but this is how they are selling kdbus.

So, if kdbus primary selling argument is security, and that argument is strong because it is base on kernel security, if you can't get kdbus in kernel, that primary selling argument is gone, and kdbus itself might be dead then. In order to not let it die, you would do anything you can to let it be in kernel.

----------

## ulenrich

 *krinn wrote:*   

>  *ulenrich wrote:*   @krinn, what performance test do you want 
> 
> Well, actually none, i'm not the one asking any tests ; but GHK gives tests results to backup his claims of better performance.
> 
> If you start using test result, i will ask you the test procedure to be able to check your claim, else ...

 

Well, for sure a very legitimite question Linus asked. I just showed GHK didn't gave it one correct thought at that point in the kernel mailing discussion. Otherwise he would have asked my question: What messages to test? Empty ping messages wouldn't show the memfd effects but would openly show other issues in the new code.

GKH may have been deeply frustrated at that point in the discussion, because as I just pointed out in my post, he himself had thought and spoken out all of it two years ago, what his critics say today. And he thinks they will come to the same conclusions once they got familiar with it. But I like it time being given for just the chance other ideas showing up.

----------

## NeddySeagoon

ulenrich,

Benchmarks are worderful things but often flawed.  They only tell you how good the code is running benchmarks, which are often difficult to relate to real world use cases.

An example from my day job a few years ago.  A real time application runs an interrupt every 20ms.  The Interrupt code takes 18ms to run, leaving 2ms every 20ms for the main loop.  It works well as intended.  One day someone makes some changes to the code (I forget why) The interrupt code now runs in 16ms leaving 4ms for the main loop.  The perpertrator, who should have known better,  claims that they have made a factor of two speed improvement. 

Its left as an exercse for the reader to work out how the speed measuremet was being made.

Some that we are all fanilliar with - Graphics card performance :)

Hyperthreading.  I'm aware of a few applications where enabling hyperthreading halves performance but Intel won't tell you that.

----------

## Naib

 *NeddySeagoon wrote:*   

> 
> 
> An example from my day job a few years ago.  A real time application runs an interrupt every 20ms.  The Interrupt code takes 18ms to run, leaving 2ms every 20ms for the main loop.  It works well as intended.  One day someone makes some changes to the code (I forget why) The interrupt code now runs in 16ms leaving 4ms for the main loop.  The perpertrator, who should have known better,  claims that they have made a factor of two speed improvement. 
> 
> Its left as an exercse for the reader to work out how the speed measuremet was being made.
> ...

 Sounds as bad as an issue we had at work with the main powerup sequencer being event driven that triggered cascaded timers... fell apart when a "28V avail" edge was significantly delayed - system would power ready at 14V, 28V ready interupt thrown at 16V  :Smile: 

but yes benchmarks are ... subjective, just like stats "Do not trust any statistics you did not fake yourself." I have used "benchmarks" to force IT to upgrade hardware above and beyond what they had on their books purely because I wanted simulation machines to have Core2 chips and I knew how to weight a simulink sim to get the best outi of it

----------

## steveL

 *ulenrich wrote:*   

> GKH may have been deeply frustrated at that point in the discussion, because as I just pointed out in my post, he himself had thought and spoken out all of it two years ago, what his critics say today. And he thinks they will come to the same conclusions once they got familiar with it.

 

Nonsense on both fronts. We've discussed the underlying issues to death on these forums, and they haven't even factored into GKH's discussion yet.

 *Quote:*   

> But I like it time being given for just the chance other ideas showing up.

 

Which is down to the kernel process, not kdbus numpties.

----------

## gwr

 *steveL wrote:*   

> We've discussed the underlying issues to death on these forums, and they haven't even factored into GKH's discussion yet. 

 

The lkml can't even get an answer about whether it needs to exist, let alone whether it has technical deficiencies.

----------

## NeddySeagoon

 *Tony Hoare wrote:*   

> “There are two ways of constructing a piece of software: One is to make it so simple that there are obviously no errors, and the other is to make it so complicated that there are no obvious errors.” 

 

... and systemd fails on both counts.

----------

## ulenrich

 *gwr wrote:*   

>  *steveL wrote:*   We've discussed the underlying issues to death on these forums, and they haven't even factored into GKH's discussion yet.  
> 
> The lkml can't even get an answer about whether it needs to exist, let alone whether it has technical deficiencies.

 

You cannot point any interested party to this five month long thread, because it is a wild discussion mixing Dbus,kDbus,systemD and Redhat commercial strategies. When talking about some of dbus technical defiencies as if they still exist in kdbus, when talking about older network based ipc like this could provide dbus stateful features, when talking about sudo as ultima ratio like it has not given us a constant stream of exploits, I doubt any kernel developer would read more than half a page of this thread.

----------

## steveL

 *ulenrich wrote:*   

> I doubt any kernel developer would read more than half a page of this thread.

 

Yeah, not with spurious page-long "debates" which simply regurgitate what we already know in a Markov-chain response to anyone and everyone.

In any event, that's irrelevant; the same points were raised in 2012, and they still haven't been addressed.

So nice try to flame us all, but completely off the mark.

----------

## mv

 *ulenrich wrote:*   

> sudo as ultima ratio like it has not given us a constant stream of exploits

 

Nice try. Try again with a sane argument (or give references to the "constant stream of exploits" which I was able to do for policykit in a few minutes).

Hint: Most sudo bugs do not allow for any exploit - usually, the opposite is true (i.e. under certain cases you do not get the required permissions).

Of course, this does not mean that sudo cannot contain such a bug or never did contain, but the chances are practically a low as you can get it, because in contrast to policykit it satisfies the main necessary condition for security: To keep the privileged code as simple as possible.

BTW: I was not claiming that using sudo is without any danger. Everything which raises privileges is an extreme danger.

But having such a complex thing running when it is even unneeded (as for all "home" systems - from desktop to laptop) is just plain stupidity.

----------

## tld

I'm convinced that the dbus/systemd proponents simply don't believe that anything can be good if it's simple, which seems to mirror the way MS approaches everything.  Code that allows privilege escalation is the last place you want complex meta-data and layers of abstraction to the point were it becomes impossible to determine if it's safe or not...but Lord knows, it can't possibly be "flexible" enough without that right? (Queue mandatory fabricated requirements nobody needs)...  :Rolling Eyes: 

----------

## Anon-E-moose

Now there is some point being raised that maybe, just maybe, kdbus should be withdrawn from the merge request

until it can be properly reviewed. And some people still think that at most a new IPC should be put into the kernel

not "dbus".

----------

## Shamus397

Wow, sanity in the kernel development process, who would've thought it?  :Wink: 

I bet steam is coming out of Poettering's ears right about now.  :Very Happy: 

----------

## gwr

 *Anon-E-moose wrote:*   

> Now there is some point being raised that maybe, just maybe, kdbus should be withdrawn from the merge request
> 
> until it can be properly reviewed. And some people still think that at most a new IPC should be put into the kernel
> 
> not "dbus".

 

How has it not been properly reviewed before? Weren't all of the previous submissions that were criticized proper reviews? It should be "withdrawn until you solve the problems already brought up".

----------

## tld

 *Anon-E-moose wrote:*   

> And some people still think that at most a new IPC should be put into the kernel
> 
> not "dbus".

 Which of course is the sane thing to do if there's a need.

I guarantee you this approach won't fly with the dbus/systemd crowd for two reasons:  a) It's an approach that actually just might be beneficial to other totally unrelated projects, and b) it does nothing to promote the dbus/systemd lock-in that they're really after in all this.  I can only imagine the excuses they'll dredge up to cloak all that.

----------

## tld

 *gwr wrote:*   

> How has it not been properly reviewed before? Weren't all of the previous submissions that were criticized proper reviews? It should be "withdrawn until you solve the problems already brought up".

 From the way it looks based on the lkml posts it appears that it's hugely complex making it very difficult to review in any detail, even for experienced kernel devs...which is pretty scary right there.  However the kernel devs primarily appear to be questioning the entire design...that is, whether or not it even makes sense to be doing what they're trying to do, no matter how the code is doing it...let alone doing so in the kernel.  The dbus folks just don't want to hear that and will just endlessly talk around it demanding specifics around what's wrong with the code.

I don't see the kernel devs ever letting anything get in the kernel forever with such high level questions still open...at least I'd sure hope not.

----------

## NeddySeagoon

Well, Red Hat already maintains a huge kernel patch set. Whats one more patch to them?

Or Red Hat could follow through an the systemd April Fool and just fork the kernel.

----------

## miket

Over at LWN, where you find a lot of systemd/kdbus/*kit cheerleading, comes an article about the delays in getting kdbus merged into the kernel.  They call the situation "The kdbuswreck".

Actually, I think that is an apt term to describe the project itself.

There you go.  systemdamage and kdbuswreck.

----------

## Anon-E-moose

 *miket wrote:*   

> There you go.  systemdamage and kdbuswreck.

 

LoL

----------

## depontius

 *miket wrote:*   

> Over at LWN, where you find a lot of systemd/kdbus/*kit cheerleading, comes an article about the delays in getting kdbus merged into the kernel.  They call the situation "The kdbuswreck".
> 
> Actually, I think that is an apt term to describe the project itself.
> 
> There you go.  systemdamage and kdbuswreck.

 

Naaah, it's just those haters who work on the kernel.  THEY'RE the problem.  There are no problems with systemd - NOTBUG!

EDIT - while this is said in all snark, I'm sure there are those who will espouse this opinion.

----------

## khumba

 *miket wrote:*   

> There you go.  systemdamage and kdbuswreck.

 

I like "dbust":

 *One Thousand Gnomes wrote:*   

> If the userspace folks choose to continue to implement dbust over it but the kernel layer is clean and generic then all is good, because someone can replace dbust with something better. If its got dbust hard wired into it then its a complete mess.

 

----------

## gwr

From lwn.net kdbuswreck article:

 *Quote:*   

> attempt to derive a bit of light from the massive amounts of heat that have been generated so far

 

That's not a biased statement at all, is it?

----------

## Shamus397

It's funny to see LP whining about that article (still behind the paywall), and complaining about the title "The Kdbuswreck".  :Smile: 

I didn't know that "mezcalero" was Poettering; it explains quite a bit from comments to articles I've read on LWN.

----------

## roki942

Boy he's really touchy.  A bus wreck does not assume that there was something wrong with the bus. Though  it can be the driver's fault .... and LP is driving the Kbus .... guess he's saying the light turned red too soon.

----------

## depontius

 *Shamus397 wrote:*   

> It's funny to see LP whining about that article (still behind the paywall), and complaining about the title "The Kdbuswreck". 
> 
> I didn't know that "mezcalero" was Poettering; it explains quite a bit from comments to articles I've read on LWN.

 

I rather like that "One Thousand Gnomes" seems to be Alan Cox.

----------

## krinn

 *Shamus397 wrote:*   

> I didn't know that "mezcalero" was Poettering; it explains quite a bit from comments to articles I've read on LWN.

 

Could it be finally that he doesn't that much crazy fan, but a lot of nickname???

(don't read this if you are easy scare): "Could it be that ulenrich is... LP!!!"

----------

## mv

@krinn: Do you know that people with technical doubts in the whole *kit story are discredited with the "conspiracy theory" argument?

You make it too easy for some to fasttalk around the technical facts...

----------

## krinn

 *mv wrote:*   

> @krinn: Do you know that people with technical doubts in the whole *kit story are discredited with the "conspiracy theory" argument?
> 
> You make it too easy for some to fasttalk around the technical facts...

 

I don't think, even the lamest one, would use a small taunt/funny quote to use it to backup any "conspiracy theory". Even someone not knowing ulenrich may get it easy.

----------

## ulenrich

 *krinn wrote:*   

>  *Shamus397 wrote:*   I didn't know that "mezcalero" was Poettering; it explains quite a bit from comments to articles I've read on LWN. 
> 
> Could it be finally that he doesn't that much crazy fan, but a lot of nickname???
> 
> (don't read this if you are easy scare): "Could it be that ulenrich is... LP!!!"

 

I doubt LP was able to produce constantly over the years as much invalid bugs as I have done:

https://bugs.gentoo.org/buglist.cgi?email1=%20eulenreich%40gmx.de&emailreporter1=1&list_id=1822580

And just for the record, there is a dbus-kdbus benchmark comparison available from Tizen crowd:

http://download.tizen.org/misc/media/conference2014/slides/tdc2014-kdbus-in-tizen3.pdf

page 10  - It depends on the messages size - as expected.

----------

## ulenrich

 *Shamus397 wrote:*   

> It's funny to see LP whining about that article (still behind the paywall), and complaining about the title "The Kdbuswreck". 

 

 *LP wrote:*   

>      Also, I don't think calling kdbus a "wreck" is appropriate at all. 

 

 *corbet wrote:*   

> ...and I never did that. The title refers to the discussion, not the technology.
> 
> ....
> 
> With regard to the title...perhaps it was a bad choice, but "buswreck" (or "trainwreck") is a fairly common English term for an unfortunate situation. I still believe that you have to stretch pretty hard to say that "The kdbuswreck" (note "the") somehow refers to the code. 

 

Germans associate "wreck" with "Schiffswrack" - a ship stranded on the shore. But later on  *jjmarin wrote:*   

> I agree that "The kdbuswreck" is a misleading title, IMHO, I think the title should be more precise to convey the general meaning of the article, maybe something like "The kdbus debate wreck"... anyway, I'm sure there must be a much better suggestion for the title  

 

Perhaps following correction given by Linus himself solves the kdebuswreck debate:

http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04915.html *Quote:*   

> No Greg.
> 
> Just remove the shit. Really. Take out the command line and the task
> 
> name. You already admitted that there is no actual valid use for it.
> ...

 

----------

## truekaiser

 *ulenrich wrote:*   

> 
> 
> Perhaps following correction given by Linus himself solves the kdebuswreck debate:
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04915.html *Quote:*   No Greg.
> ...

 

At which point gkh cries, STOP OPPRESSING ME!!1!

and gets linus removed via the standard of conduct patch he rammed through earlier..

----------

## steveL

 *ulenrich wrote:*   

> And just for the record, there is a dbus-kdbus benchmark comparison available from Tizen crowd:
> 
> http://download.tizen.org/misc/media/conference2014/slides/tdc2014-kdbus-in-tizen3.pdf
> 
> page 10  - It depends on the messages size - as expected.

 

Oh jeez; that's as about as useful as a claim from a manufacturer that some new product in the same range is better than their existing pile of turd.

A better comparison was the one between dbus, Gnome's ORB, and dcop. ie alternative technologies doing the same thing.

So in this case, a comparison between kdbus and TIPC is what's needed. Anything else is just propaganda^W advertising^W marketing^W "communicating" (nonsense.)

I see where krinn is coming from: you unfailingly repeat the same old gloss that we've heard before, and never address the substantive technical issues, when it comes to anything Poeterring-related.

I'm tired of repeating the same old URLs over and over. If you want to counter the claims, read them and just for a change, show us you've read them in the arguments you make.

----------

## steveL

 *truekaiser wrote:*   

> At which point gkh cries, STOP OPPRESSING ME!!1!
> 
> and gets linus removed via the standard of conduct patch he rammed through earlier..

 

It's much more insidious than that; the whole idea is to set the tone for when Linus retires/dies.

Once he's gone, no-one else is going to have any sort of standing to simply talk straightforwardly, instead of couching everything in politically-(in)correct vague, which as we all know is exactly how corporates take over in the background.

Everyone ends up self-censoring, and their headspace is wasted on that, instead of correcting mistakes.

Multinationals play a long game, while forcing everyone else to focus on last quarter's results, or next week's shopping.

Meanwhile, "I can't tell Linus, but I sure as hell can tell you."

----------

## roki942

oh I like this one http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04649.html

 *Quote:*   

> > Did I miss anything else here?Â Are there any technical reasons I'm
> 
> > forgetting about for why this can't be pulled in as-is for this merge
> 
> > window?
> ...

 

----------

## mrbassie

http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04853.html

----------

## Naib

Lol standard approach to build a system...

The number of times I have crafted a large analogue circuit in say Matlab, saber, simetrix ONLY for it to not run (damn Jacobian matrix...) Wasting days...

Only to start from scratch, build it up submodule by submodule with a suitable testbench strapped around to check it... Only for the complete model to work. 1st looks show there to be no obvious differences but there must be

----------

## arnvidr

 *mrbassie wrote:*   

> http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04853.html

 And three days later, no reply.

----------

## ct85711

Actually the discussion is on the next archive page over.  Here's the link to the start of the kdbus chain for this week.  http://lkml.iu.edu/hypermail/linux/kernel/1504.3/00006.html  (Haven't seen anything posted for yesterday, the 25th, though I am thinking it's just a delay before it gets updated on this archive.

----------

## tld

 *mrbassie wrote:*   

> http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04853.html

 Very interesting read, especially this:

 *Quote:*   

> This code has astonishingly complex interactions with all kinds of other
> 
> kernel subsystems and concerns. As a community we should understand
> 
> them and accept them before letting them in.
> ...

 

Seems like he's saying they need to break their monolithic mess into small pieces that each...Oh, I don't know..."do one thing and do it well"?  :Wink:   With those folks pigs will fly first I think.  That philosophy somehow seems to be lost on everyone these days.  I was reading an article this morning about Ubuntu 15.04 moving to systemd and the "controversy".  The article totally white-washed it saying that systemd wasn't monolithic because it "creates 69 binaries"...what a flaming load of crap.

Tom

----------

## Anon-E-moose

 *Quote:*   

> This code has astonishingly complex interactions with all kinds of other
> 
> kernel subsystems and concerns. As a community we should understand
> 
> them and accept them before letting them in.

 

This is the most frightening part of their push to have it in the kernel so quickly.

It touches all kinds of subsystems. 

Which brings up the question "is that really needed" for dbus 

or is this just a slight of hand to get more control over kernel pieces 

and somehow filter them through sysd thereby cutting out any and all other init systems.

ie. a wrapper around the kernel...long live sysd.   :Rolling Eyes: 

I don't think they want people, especially the kernel devs to see what the true interactions

with all the subsystems is. 

Unlike GKH's whine, I don't trust the ones who wrote kdbus, I don't trust their motives, 

I don't trust GKH's push to have it in come hell or high water without any meaningful reviews.

Nack, Nack, Nack...ad infinitum.

----------

## Naib

 *Anon-E-moose wrote:*   

>  *Quote:*   This code has astonishingly complex interactions with all kinds of other
> 
> kernel subsystems and concerns. As a community we should understand
> 
> them and accept them before letting them in. 
> ...

 

Hanlon's razor... 

They probably did that because they are userland coders and not use to atomic structure. The problem is if it went in as-is those tentrils would probably start getting abused. There is no need for it to start linking across everything... its a messagebus Userland <> Userland .... not a Userland --> deepKernel

----------

## steveL

 *Naib wrote:*   

> They probably did that because they are userland coders and not use to atomic structure.

 

The real problem is they're not even good userland coders; they don't seem to know the POSIX base at all, let alone the rest of the UNIX world.

Consequently, they are blinkered in their approach; to put it mildly.

 *Quote:*   

> The problem is if it went in as-is those tendrils would probably start getting abused.

 

s/probably/definitely/ -- if there's a way to make money doing something, then someone will do it, even if most of us think it reprehensible.

If you think that's far-fetched, consider the milieu most of these nubs come from (Windoze) for the archetype of where RedHat is going.

 *Quote:*   

> There is no need for it to start linking across everything... its a messagebus Userland <> Userland .... not a Userland --> deepKernel

 

Follow it through, and you arrive at TIPC.

Unfortunately: "You won't get round us with that design nonsense.." ;-)

----------

## Anon-E-moose

Linus just posted this http://lkml.iu.edu/hypermail/linux/kernel/1504.3/02040.html

 *Quote:*   

> >> That said, either you're running your test on a potato, or dbus is
> 
> >> seriously screwed up. No way should it take 4+ seconds to send a 1000b
> 
> >> message to back and forth 20k times. But as mentioned, I can't even
> ...

 

 :Laughing:  LoL  :Laughing: 

and in the follow up post

 *Quote:*   

> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> >
> 
> > IOW, all the people who say that it's about avoiding context switches
> ...

 

----------

## Anon-E-moose

A good read by Andy L. http://lkml.iu.edu/hypermail/linux/kernel/1504.3/01895.html

----------

## Naib

Get ready for the sysd manoeuvre "kdbus is not about speed improvement its about, um, security... Wait no its about ... STOP THIS CAMPAIGN OF HATE"

Funny how they are having to review userland calls to get an idea what kdbus is suppose todo

----------

## gwr

Wow, and then there is this gem of a reply by Linus

http://thread.gmane.org/gmane.linux.kernel/1930358/focus=1937733[

"Conditional byte order is worse than silly - it's terminally stupid."

----------

## Anon-E-moose

It's funny to watch the different linux threads on the news reporting sites.

It seems the kdbus and dbus devs are commenting heavily that "kdbus is good to go".

Seems they've given up trying to get it past the kernel devs and all their commentary

and is trying to get the court of public opinion "to put pressure on the kernel devs" to get it in.

Of course if it should get in and cause the havoc with the kernel that it seems it might, 

then the kernel devs would be the ones getting booed not the kdbus/dbus devs nor their mindless cheering section.   :Rolling Eyes: 

----------

## Naib

appeal to the masses unfortunately works... especially if the PR team is better.

----------

## asturm

 *Anon-E-moose wrote:*   

> It seems the kdbus and dbus devs are commenting heavily that "kdbus is good to go".

 

Can you provide links?

----------

## Anon-E-moose

 *genstorm wrote:*   

>  *Anon-E-moose wrote:*   It seems the kdbus and dbus devs are commenting heavily that "kdbus is good to go". 
> 
> Can you provide links?

 

I don't have the links at hand, I was reading from lwn, linuxtoday, slashdot and a few others, so I don't remember where I saw the comments.

I wouldn't even have known that any of them were kdbus/dbus devs until one of them 

answered to defend them (devs), by way of saying "no we don't" in response to criticism.

Which I took to mean they were in the (k)dbus dev circle. 

But the number of (k)dbus devs is far outnumbered by the amount of people (who knows who they are) 

commenting about it should be in the kernel now, and they pooh pooh the concerns of the kernel devs.

Using the same responses and tactics (by (k)dbus devs) that we see in the lkml discussions.

Edit to add: the whole "it's good to go" seems to be the party line of those (k)dbus devs on the lkml discussions.

It's either "that's a minor problem" or "just put it in and we'll work on those problems later"

And the last week Havoc Pennington has joined the fray (on the side of (k)dbus seemingly)

even though he only worked on the original dbus code and admits that he knows nothing

of the current implementation.

What I don't hear from any user space devs is that perhaps they should relook at the design and see if it can be improved.

And that's scary.

----------

## Anon-E-moose

Ted Tso has this to say on the lkml

 *Quote:*   

> So the question is if one of the justifications for moving the daemon
> 
> into kernel space is that it's performance is crap, then I think it is
> 
> useful to determine whether a fully optimized userspace daemon would
> ...

 

Note: I have a non-dbus system and it works perfectly well.

----------

## toralf

Linus used to use less words to describe the current implementation of kdbus : "full of shit"

----------

## arnvidr

Last reply from Linus seems to lay the discussion dead *Quote:*   

> Now, there may be *other* reasons why kdbus is a good idea. But quite
> 
> frankly, every time somebody asks "why", performance seems to be one
> 
> of the main answers.
> ...

 Haven't seen many responses from anyone but Havoc lately, and he rightly defers any questions not about the current dbus to the kdbus developers.

Maybe they'll be forced to look at the dbus mess now.

----------

## Anon-E-moose

 *arnvidr wrote:*   

> Haven't seen many responses from anyone but Havoc lately, and he rightly defers any questions not about the current dbus to the kdbus developers.

 

On the one hand Havoc says he doesn't know much about the current implementation of dbus,

but he still continues on trying to be an apologist for it. He's just a tool, IMO.

 *Quote:*   

> Maybe they'll be forced to look at the dbus mess now.

 

That would be nice but I wouldn't hold my breath waiting for it.

Since this last push to get kdbus into the kernel, it's been mentioned, several times, by kernel devs to relook at their dbus code.

They just keep on trying to get kdbus into the kernel (real soon) and then they'll work on the problems of it.   :Rolling Eyes: 

----------

## Naib

so the question is ... why does it need to be in the kernel. if it is just "dbus in the kernel" then it would work in userland. 

If it is for speed, "dbus in userland" still works

But speed has been shown to be a possible red herring.   If it was about needing dbus and speed then there would be a drive for userland optimisation, which isn't occurring... why does it need to be in the kernel?

----------

## EmaRsk

There something I don't understand. (Well, there A LOT I don't understand, but if Linus says kdbus is shit, I believe him, and I dislike dbus - and systemd - enough already).

If they want kdbus in the kernel, why don't they just maintain a patchset?

I mean, the Con Kolivas patches aren't in the official kernel, too, and still they're available for everyone.

Debian maintains its own kernel patchset, Gentoo does the same, as almost every other distro, I suppose.

Couldn't they just maintain a kdbus patchset?

It seems to me that the only reasons to rush this into the official kernel tree, must be political reasons.

Am I missing something? Could there be a real technical reason?

----------

## steveL

Why does it need to be in the kernel? Because then a nice GPL-evasion mechanism is baked-in, forever, and no-one is going to dream of arguing that that's what it's main purpose is, because Linux.

----------

## gwr

 *steveL wrote:*   

> Why does it need to be in the kernel? Because then a nice GPL-evasion mechanism is baked-in, forever, and no-one is going to dream of arguing that that's what it's main purpose is, because Linux.

 

Isn't dbus already a gpl-evasion mechanism? Why concern themselves of baking it right into the kernel if systemd is already forcing most major players to use it?

----------

## steveL

 *gwr wrote:*   

> Isn't dbus already a gpl-evasion mechanism? Why concern themselves of baking it right into the kernel if systemd is already forcing most major players to use it?

 

So no one will "dream of arguing that that is what it's main purpose is, because Linux."

Once it's in the kernel, it's in forever effectively, or at least the medium-term (10-15 years minimum.)

Everyone else will be responsible for it, so it won't be associated with RedHat, Sievers and Poeterring any more; it'll just be part of the accepted background of Linux itself, rather than a woefully ill-designed userland project.

IMO it would in fact be a stain on the reputation of Linux, one which Windoze newbs will find familiar, so in user-acceptability terms it won't be such a big deal for RedHat and other corporations seeking to "monetise" the userbase into an "income-stream."

They're after people on the level of a mobile-phone or television user, not any of us.

ATM, systemd can be avoided because it's userland, as so many of us already do, and so do other distros.

Linux is still about choice, as it has been from the beginning.

Cheers, Mr. Torvalds; I owe you a beer. :-)

----------

## Anon-E-moose

Looking at the traffic (lkml) over the last few days and even last week, it seems that there are 

a great number of people who doubt the wisdom of putting kbdus into the kernel, 

at least for the moment and for the current design of it. So there's hope on that front.

I think what's going to happen, is that the ones that want (k)dbus in the kernel 

will start screeds disguised as a blog about how the kernel devs are keeping

the kernel in the dark ages, because they're all luddites who are stuck in the past.

The CoC might even be invoked if they can figure out how it would apply.

There have been a few kernel devs who even have the temerity to say that

there only needs to be a minimum in the kernel, ie the bus transport, not all of kdbus.

We'll see.

----------

## depontius

 *toralf wrote:*   

> Linus used to use less words to describe the current implementation of kdbus : "full of shit"

 

That guy?  Whoever the heck he is, he's just a hater!

I wonder if this whole kernel push was a miscalculation by the systemd people, or a deliberate part of a plan.  Hanlon's Razor would say the former.

I suspect that Linus and several others are going to start to dig in their heels shortly.  If the systemd folks keep up with their normal "public opinion" approach, I see bad things.  What would happen to Linux if Linus walked away saying, "This has quit being fun, goodbye!"

----------

## saellaven

 *depontius wrote:*   

>  *toralf wrote:*   Linus used to use less words to describe the current implementation of kdbus : "full of shit" 
> 
> That guy?  Whoever the heck he is, he's just a hater!
> 
> I wonder if this whole kernel push was a miscalculation by the systemd people, or a deliberate part of a plan.  Hanlon's Razor would say the former.
> ...

 

systemd rolled just about everyone else in the linux world... I'm sure they figured they had the momentum and a big enough key player given GKH's kernel role (not to mention how many other kernel devs are working at redhatd) to push the kernel devs into adopting it regardless of the need or quality.

I have to admit that, for as much of a technological pragmatist as Linus is, I thought that there was a good chance he might roll over myself... I can still envision a scenario where GKH and friends harass him with the CoC policy to the point where he just says "f it, I've made enough money off linux to support my family for the rest of my life, I'm walking away... you want it so bad, you're in charge Greg."

----------

## gwr

 *Quote:*   

> "f it, I've made enough money off linux to support my family for the rest of my life, I'm walking away... you want it so bad, you're in charge Greg."

 

Every project needs people who have authority to say no. Once you lose that person, then all is lost and it becomes a free-for-all. If they don't like Linus' management, then they can fork the kernel. That is the entire point of open source software.

----------

## Anon-E-moose

Have to chuckle at this. http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04680.html

 *Quote:*   

> From: Eric W. Biederman
> 
> Date: Thu Apr 30 2015 - 16:14:25 EST 
> 
> On April 29, 2015 7:47:53 AM CDT, Harald Hoyer <harald@xxxxxxxxxx> wrote:
> ...

 

Once again a kernel dev explains what's needed, sadly I don't think it'll sink into the "kdbus needs to be the way it is" crowd.

----------

## asturm

 *Anon-E-moose wrote:*   

> Have to chuckle at this. http://lkml.iu.edu/hypermail/linux/kernel/1504.3/04680.html

 

Yeah, the list was quite entertaining those last few days.  :Wink: 

----------

## krinn

am i the one thinking how kernel devs speak about kdbus show the same conceptual spirit systemd was built?

And that this pic would explain everyone really shortly the problem by just changing systemd with kdbus word in it : 

http://www.microlinux.fr/download/systemd.jpg

----------

## ulenrich

just found Linus say in the year 2022  *Quote:*   

> The apparent inability (and perhaps more importantly - total unwilling[n]ess) from the kdbus team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many kdbus features to never be merged.
> 
> Much of it did get merged over the years (mostly because some people spent the time to separate things out), but no, we're not going to suddenly start merging code like that just because the project is in trouble. None of the basic issues have been solved. 

  [edit] faked kdbus for a name in two places.

This little piece makes me wonder GKH does not know nothing about Linux history

----------

## steveL

Heh, 2022.

This was an interesting tidbit from grsecurity:

 *PAX wrote:*   

> the original intention of those backing LSM was to allow for the existence of proprietary security modules that used the kernel's GPL'd interfaces

  especially combined with this:

 *RSBAC wrote:*   

> It seems that LSM is about to be removed from the official kernel and SELinux allowed to have their individual hooks. Reason: All other LSM users live outside the official tree. ..wonder why

 

Granted that's from April 2006, and in 2009 the former page mentions:

 *PAX wrote:*   

> New security modules are finally being allowed mainline, so hopefully the push from certain individuals to make SELinux the 'one true security model' for Linux is over.

 

However that does not change the intent, nor the efforts taken to pursue that intent.

It's interesting because the same putsch to combine proprietary code with GPL, is now underway with the kdbust-GPL-evasion-or-nothing campaign.

And OFC, we all know who the main backer of SELinux (which seems far too complex to make a decent security infra, imo) is: RedHat.

It's at this point, we really should decide to treat RedHat as hostile, both to Gentoo and the wider Free Linux infrastructure, ie our community.

If it's not in tune with this I don't want it on machines I am liable for.

----------

## FreeAsInFreedom

This is my first post here on Gentoo forums.

About 10 to 15 years ago I was a big Linux enthusiast. I've been using it work and at home since then.

Gradually, over the years that tapered until the last couple of years when I had no idea what's going on.

On a whim a couple of weeks ago I felt like getting back up to date, and then I stumbled upon the whole systemd fiasco.

Just wanted to give that intro and say I'm glad that I eventually found this forum for people who actually get it.

----------

## FreeAsInFreedom

So, I've done a load of research and looking around to figure out what's going on with systemd/kdbus.

Here are some observations:

Linus is sponsored by the Linux Foundation, and is listed as a "Fellow".

Right beneath him as another "Fellow". It's that familiar name I've seen LKML threads, Greg Kroah-Hartman.

That annoying guy trying to stick his filthy kdbus in the kernel like a used car salesman. "Trust me. It's all great stuff we really need."

Here's a simplified explanation for what's going on.

You have a group of Red Hat employees - Pottering et al pushing systemd in all the corporate distros.

And then right in the kernel itself you have Greg Kroah-Hartman pushing kdbus.

Why? Because they're getting paid to. It's as simple as that.

Well actually in Pottering's case it seems more like an ego trip being enabled by a Red Hat position and paycheck.

If you look at GKH's blog you can see all the buddy-buddy references he makes to the systemd developers.

Having the systemd/kdbus monstrosity in Linux serves Red Hat's interest primarily.

I noticed that Jim Zemlin (Linus' "boss") has not voiced any opinion at all on the systemd.

Linus himself seems muzzled.

The angle that's being taken is to just shove systemd/kdbus on the community like it's inevitable.

The way these tech sites are pushing it.

Looks like it's been a sockpuppet social media blitz looks like another part of it I bet. I've dealt with this in completely different areas like GMOs, fluoridation, etc. It appears similar.

Anyway, just a fewf observations.

What else do people make of the specific political/money factors?

To me it looks like it's definitely a factor. Sort of the elephant in the LKML mailing list is not addressing how corporate money is behind it all.

It's like an unspoken rule that it must only be revolve around technical issues.

That's good to a point, but eventually I think you need to realize these people have bad character and bad intentions.

I would love for Linux to give a unequivocable and permanent "NO" on this kdbus.

Unfortunately Linus himself gets paid from the some source of funding of systemd/kdbus invasion.

A final note: maybe it seems kind of extreme but I think the concerns about NSA wanting a backdoor in Linux/RedHat machines are a legitimate concern.

This blog gets into that

https://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/

----------

## steveL

You want this topic, FreeAsInFreedom, for the "political and money factors."

Bear in mind RedHat "gave" stock (and/or options) to quite a few core Linux developers after their IPO in the late 1990s.

Not sure on exact details, never bothered to look it up.

----------

## Shamus397

Getting back on topic (ahem), this made it's way into the kdbus discussion, though surprisingly nobody from the kdbus camp wanted to jump in to 'refute' it:

 *Austin S Hemmelgarn wrote:*   

> I don't know how I managed to not notice this comment before, but I find it particularly hilarious.
> 
> The part about 'no common interoperability' is just plain BS with the exception of some of the insanity being touted by systemd advocates and the insanity that is accessibility software on linux, you can easily string together pretty much arbitrary strings of commands using fifo's to achieve almost anything; the actual interoperability issues (WRT to the command line at least, which is where all the stuff you are complaining about works) come up only with stuff (like journald for example) that just refuses to use text interfaces on the command-line.

 

Have not yet seen GKH & friends pop up on the list since the smackdown by Linus.  :Very Happy: 

----------

## depontius

Title : "On the Importance of Bike Shedding"

For the time being, kdbus has disappeared from LKML,as far as I can tell.  The silence is deafening.  I'm betting that in a few months it's going to reappear with the absolute minimum of changes, basically answering Linus' worst criticisms in the least intrusive way possible.  I know Linus objected to selectable endianism, and there were two other items that I don't remember at the moment.  I think the fix will involve those two other things, and selectable endianism will be papered over, but not really removed.

I've spent over three decades in corporate America, and this looks like a standard pattern.  A common corporate way to craft a new standard is to take whatever they've got on hand, bless it, and call it a standard.  Frequently there will be some attempts at documentation that make it look "designed", as opposed to the years of happenstance, bug fixes, and enhancements that it really is.  But if you peel away the covers you won't find architecture, you'll find "stuff".

Many things on the internet today were done with bikeshedding - people discussing, proposing, testing preliminary implementations, and especially important - throwing away bad stuff.  Corporations seldom throw away anything - they fix it to the point where it can meet (often amended / reduced) requirements, and ship it.  For all the criticism bikeshedding is often given, it can be a valuable process for producing some good standards.

But kdbus looks more like the standard corporate model.  Someone had an idea, threw something together, and got it working.  There appears to have been no introspection (in spite of the "introspection" feature) or willingness to toss a prototype and start over.

Along this line, one of my favorite stories was "xcb".  They wanted to produce a set of native C bindings for X, instead of using Xlib.  They did so, and found out that it was small and fast.  Next they implemented Xlib using xcb, and discovered that it was both smaller and faster than the original Xlib.  Unfortunately by the time xcb was really maturing people were starting to move past xlib into other solutions to the same problems.

I suspect that someone could re-examine dbus and put a compatible implementation on a better infrastructure, possibly using some new (not kdbus) kernel feature, possibly only using only existing kernel features, and solve all of the performance and security issues of dbus today.  But I doubt that's going to happen, especially not by the dbus developers.  It would take The Right Stuff to do what is needed.

----------

## NeddySeagoon

depontius,

You must be nearly as old and cynical as me.

Your post reminds of a few quotes ...

 *Fred Brooks Jr wrote:*   

> Plan to throw one away, you will anyway

 

How sh#t happens

 *Benjamin Franklin wrote:*   

> If you fail to plan, you are planning to fail!

 

Most Linux software was like Topsy but constrained by the do one thing and do it well dictum.

systemd has rather grown like a cancer ... free of almost all constraints and its still growing.

I suppose I should add in *Edmund_Burke wrote:*   

> All that is necessary for the triumph of evil is that good men do nothing.

 Thats not aimed at systemd but everyone else around who does nothing.

----------

## depontius

 *NeddySeagoon wrote:*   

> depontius,
> 
> You must be nearly as old and cynical as me.
> 
> 

 

Hair quite grey, but at least it's still there.

 *NeddySeagoon wrote:*   

> 
> 
> Your post reminds of a few quotes ...
> 
>  *Fred Brooks Jr wrote:*   Plan to throw one away, you will anyway 
> ...

 

Saw this, long ago at work.  It struck a chord then, and still does.

 *NeddySeagoon wrote:*   

> 
> 
>  *Benjamin Franklin wrote:*   If you fail to plan, you are planning to fail! 
> 
> Most Linux software was like Topsy but constrained by the do one thing and do it well dictum.
> ...

 

The other sad and perhaps cynical thing I've learned from too many years in industry is that sometimes tides are too big to fight.  That's the root of my rather defeatist attitude toward systemd.  Over the years I've my head has gotten sore too many times from banging it into walls trying to fight stupid things.

I've said before, I see systemd as a symptom of Windows users coming to Linux, not to escape Windows, but because Linux has become "kewl".  Old-schoolers are overwhelmed by sheer numbers, including developers, because Windows developers have been coming over, as well as users.  Since they're not "escaping" Windows they're happy to bring their Windows sensibilities with them.  Classic Linux is outside their comfort zone, and rather than learn their new home, they're porting their comfort zone to Linux.

I see my role as an old guard, ready to point the way back to sanity for anyone who is ready.

----------

## NeddySeagoon

 *depontius wrote:*   

> I see my role as an old guard, ready to point the way back to sanity for anyone who is ready.

 

++1

----------

## Anon-E-moose

Sure been quiet on the mailing list (lkml) this week.

kdbusT didn't make it for the 4.1 kernel either.   :Wink: 

----------

## depontius

Makes me more than a little afraid.  I seriously doubt that they are re-evaluating the dbus architecture, and figuring out how to do the job properly.  I'm sure that they're doing the absolute minimum and hoping that they can make it through next time.

I also have this ugly feeling that they're preparing some sort of Plan-B to get kdbus shoved into the kernel, no matter how many dead bodies it goes over.

----------

## NeddySeagoon

Red Hat could fork the kernel if they really really wanted to.

kdbus is just another Red Hat patch.

----------

## mv

 *NeddySeagoon wrote:*   

> Red Hat could fork the kernel if they really really wanted to.
> 
> kdbus is just another Red Hat patch.

 

It is rather evident that this is their plan.

With most distributions forcibly depending on systemd, and systemd depending forcibly on that patch: The social pressure on vanilla linux will be enormously.

It is completely unimportant whether their patch is accepted now: The main thing is that they can say later that they offered it.

----------

## NeddySeagoon

mv,

With most distros becoming Red Hat clones by stealth is one thing.

When all the binary distros are running a Red Hat kernel its rather blatent.

That sort of pressure is a double edged sword.

Some binary distros may revert to sanity, even if it means dropping Gnome.

----------

## depontius

I expect that in the coming weeks LKML will become extremely interesting - the pressure will become UGLY.

Yes, RedHat could fork the kernel.  I don't expect that, I expect them to try to control it.

----------

## Anon-E-moose

From what I have heard, RH already has kdbus as a patch against the kernel.

----------

## depontius

 *Anon-E-moose wrote:*   

> From what I have heard, RH already has kdbus as a patch against the kernel.

 

That's perfectly in line with their RH7 beta.  I haven't heard any RH7 beta news, but perhaps there are some performance issues around dbus, which is why this is getting heat.

In spite of the fact that RH could keep this patchset around forever, even release the source and make it part of the "default kernel", I expect them to shove really hard to get it into the vanilla kernel.

----------

## ulenrich

My gosh,  every Redhat Linux had an ongoing forking of the kernel. Pretty much to the extent it had that much features you couldnt guess the Linux main version, if you didn't know the number nor the release date. 

More than the red hats of the US military it is the application developers of the german car industrie who want the simplicity of dbus with a performance Kdbus can deliver. I must admit the evil germans pushed kdbus ...

Why dbus? It is complexity hidden behind curtains. The only question waiting in the long run: Was the dbus concept just too simple? If, then out of a sudden, now behind the curtains: "Who let the dogs out!" And complexity of this now seemingly simple minded dbus blows up again for developers. The kernel developers proposal of splitting the kdbus into more general layers will have its benefit then: To catch the wild dogs they will be able to quickly provide the next frontend for the next purpose IPC: Ldbus 

For sure we will see such next letter new implementation ...

----------

## ct85711

The part I find funny, is that they keep mentioning that they do not want to break compatibility with older versions.  So they are not wanting to redo the old dbus because they would end up breaking backwards compatibility doing so, same with kdbus supporting the old dbus routine.  Since when has the fear of breaking backwards compatibility ever stopped progress.  All they have to do, like normal convention, is bump the version to the next major version, and continue on.  All they need to do then is make a note at beginning of the documentation, that the new major version is not compatible to the old version and maybe add some simple wrapper functions for transitioning.  Half the time, this isn't a concern for RH to begin with since they don't support old versions to worry about.

----------

## mv

 *ct85711 wrote:*   

> Since when has the fear of breaking backwards compatibility ever stopped progress.

 

There are many examples of this: Cobol and Fortran are still actively used, despite there are nowadays much superior languages. But just too many programs are written in it to get rid of the inherited waste.

Apparently, a similar thing happened in the German car industry if ulenrich is right (I suppose he will have some reliable source of information for this): In the moment when they had to decide about a standard means of IPC, they have made the wrong choice (or perhaps a better choice like was TIPC was not yet available at that time), and now it is cheaper for them to continue with the inherently broken dbus concepts and pay money to push it into the kernel to make the speed bearable for them instead of hiring people to rewrite the IPC parts of their software according to a modern sane standard like TIPC.

----------

## Anon-E-moose

The whole "don't break compatibility" is bogus, a red herring.

It's easy to rewrite the whole "guts" of (k)dbus to be more effecient and or faster and leave the interface the same.

They are not wanting to rewrite the guts, despite being given great hints by the kernel devs and others.

I don't know it their resistance to taking others advice is a perverted form of NIH 

or if there is some landmines hidden in the the twisted code (that no one has been able to follow through properly yet) and they really want to be part of (k)dbus.

Do I trust the good intentions of RH, LP, cabal et al, etc? I say no, they haven't earned the right to my trust.

----------

## mv

 *Anon-E-moose wrote:*   

> It's easy to rewrite the whole "guts" of (k)dbus to be more effecient and or faster and leave the interface the same.

 

But you would have to invest work/money to do it. It is cheaper if you can get the same optimization effect by pushing the rubbish into the kernel as it is.

As you pointed out a while ago, the dbus people actually know what would have to be done to make it fast - and it would not require any new kernel feature, just a sane usage of shared memory and/or TIPC. They simply prefer to avoid doing their homework:

Once they should succeed with the push, the brokenness of their concept becomes suddenly less visible (concerning speed), and concerning security, they are suddenly not reliable to it anymore, anyway: As pointed out, it is then they kernel guys who will take the blame for the broken concept.

----------

## tld

 *Anon-E-moose wrote:*   

> The whole "don't break compatibility" is bogus, a red herring.

 Especially coming from the folks that talk about requirements to update your kernel in "lock step" with dbus...talk about "compatibility"   :Rolling Eyes: 

----------

## GFCCAE6xF

 *tld wrote:*   

>  *Anon-E-moose wrote:*   The whole "don't break compatibility" is bogus, a red herring. Especially coming from the folks that talk about requirements to update your kernel in "lock step" with dbus...talk about "compatibility"  

 

This is news to me, why would they want the kernel updated in lock-step with dbus? I thought kdbus was meant to go in the kernel... I know systemd uses 'normal' dbus but the mix of systemd and dbus has nothing to do with kernel features afiak so this makes no sense. Do you have links to their mails where they talk about this?

----------

## Naib

 *GFCCAE6xF wrote:*   

>  *tld wrote:*    *Anon-E-moose wrote:*   The whole "don't break compatibility" is bogus, a red herring. Especially coming from the folks that talk about requirements to update your kernel in "lock step" with dbus...talk about "compatibility"   
> 
> This is news to me, why would they want the kernel updated in lock-step with dbus? I thought kdbus was meant to go in the kernel... I know systemd uses 'normal' dbus but the mix of systemd and dbus has nothing to do with kernel features afiak so this makes no sense. Do you have links to their mails where they talk about this?

 It does with the abi in flux, something that systemd will keep in step with.

----------

## tld

 *GFCCAE6xF wrote:*   

> This is news to me, why would they want the kernel updated in lock-step with dbus? I thought kdbus was meant to go in the kernel... I know systemd uses 'normal' dbus but the mix of systemd and dbus has nothing to do with kernel features afiak so this makes no sense. Do you have links to their mails where they talk about this?

 Ah...my mistake actually.  That was in reference to systemd and not dbus:

http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html

Still rather astonishing that an init system would have those sorts of kernel requirements...glad I'll never have to deal with it...

Tom

----------

## NeddySeagoon

tld,

but its no longer an init system.  Its a kernel wrapper.

----------

## krinn

do anyone think we're close to have a new challenger for the "software fiasco of the year" with kdbus?

What will be interesting is what redhat will do, sure they can have a patch kernel for themselves, calling it a fork or not, but it's personal use. Now if systemd depend on that patch (so systemd need a kernel with kdbus patch), that would force anyone to use a kernel with the patch (so a non vanilla kernel anymore), and write in stone redhat has fork the kernel.

And how distro will look at this: getting deeper redhat dependent or finally back to sanity and dropping systemd and all the shit.

----------

## tld

 *krinn wrote:*   

> Now if systemd depend on that patch (so systemd need a kernel with kdbus patch), that would force anyone to use a kernel with the patch (so a non vanilla kernel anymore), and write in stone redhat has fork the kernel.
> 
> And how distro will look at this: getting deeper redhat dependent or finally back to sanity and dropping systemd and all the shit.

 Exactly.  Those distros let themselves get strong armed into using systemd by malicious dependencies by Gnome etc.  They should have realized it wouldn't end there.  It'll get very interesting if using systemd starts forcing them to use a kernel full of ugly hacks.

----------

## Anon-E-moose

 *tld wrote:*   

> It'll get very interesting if using systemd starts forcing them to use a kernel full of ugly hacks.

 

Which is part of the reason that RH is lobbying so hard for kdbus to get into the kernel.

They know that it's an uphill publicity battle to tell other distros not only do you need systemd but our patch set too.

Effectively killing everyone as a separate distro off, but with kdbus in the kernel, 

they can easily convince themselves that RH still has their interests first and foremost.

----------

## mrbassie

But, but, but we need to end the duplication of effort and have standardisation otherwise..umm..something bad! Oh yeah and we have to kill Microsoft because...something! We can't use desktops without systemd...oh wait!

----------

## Naib

Round ? I have lost count

http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02614.html

----------

## Anon-E-moose

 *Naib wrote:*   

> Round ? I have lost count
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02614.html

 

They keep on ignoring the fact that the kernel devs have told them (albeit not so plainly as I state it here)

that kdbus won't be allowed in the kernel the way it is written right now.

And that involves a lot more than just shuffling metadata. 

This is what I see happening, the (k)dbus cabal will push, yet again, for kdbus to be included.

The kernel devs will say the same thing they've said for all the candidates so far "nack on it the way it is written"

Lather...rinse...repeat.   :Rolling Eyes: 

----------

## steveL

 *Anon-E-moose wrote:*   

> They keep on ignoring the fact that the kernel devs have told them (albeit not so plainly as I state it here)
> 
> that kdbus won't be allowed in the kernel the way it is written right now.
> 
> And that involves a lot more than just shuffling metadata. 
> ...

 

It's odd, reading GregK-H's posts, it's as if those NAKs never happened.

I'm sure some social-anthropology student somewhere can describe it much better than any of us, but it strikes me that the use of language is quite interesting. By breezily carrying on, as if the thing hadn't been trashed into the ground, the impression is given that everything's hunky-dory in lala-land: "y'know, just those crazy kernel-devs carrying on as usual, heh what can you do.. roll up, roll up, business as usual." ("one born every second.")

From the pov of apparatchik-watching, it strikes me that anyone other than that shill would never even get away with it.

As such it represents a classic case of how you can coopt a "technical" community via social methods; geeks pretending that politics doesn't matter, are just easy victims -- precisely because they ignore the machinations, while being subject to the same old cognitive dissonance (a term originally from the propaganda^W advertising industry, as a way of describing what they do) as every other human being.

From a technical pov, "sd-bus coupled with GCC plugins to construct kdbus sandbox profiles during compilation thanks to sd-bus semantics" sounds like utter shite to me, especially the "thanks" part.

I dread to think what bs they'll inflict on gcc, which will then become a "required part of Lennux" so if you're unfortunate enough to be on a bindist tied into systemdbust, you'll be a botnet-vector waiting to be pwnt.

But still, the NSA can push patches for their malware to your machine, as can just about anyone else, so that's all good then. /s

Most of all it sounds like gibber: 

```
"Maybe I'm an idiot, but I have no idea what anyone is talking about.

What is it? It's complete gibberish. It's insane.

When is this idiocy going to stop?"
```

In any event, I fully expect the kdbust-crowd to keep pushing, and keep on acting as if the blatant problems can all be fixed in the wash.

Later it'll just be the usual "all complaints were responded to" becoming "all complaints were dealt with" even though everyone involved in the discussion saw the responses given as pitifully inadequate.

As Charlie Brooker puts it, "Welcome to the World of Bullshit."

----------

## sitquietly

 *steveL wrote:*   

> .....
> 
> I'm sure some social-anthropology student somewhere can describe it much better than any of us, but it strikes me that the use of language is quite interesting. By breezily carrying on, as if the thing hadn't been trashed into the ground.....it represents a classic case of how you can coopt a "technical" community via social methods; geeks pretending that politics doesn't matter, are just easy victims.....

 

You've helped me understand the situation in this thread.  Thanks.  it has caused me to take positive steps to reduce the future impact of the re-basing of *nix by the corporate and government boys.  I've been able to run without avahi/consolekit/policykit/pulseaudio/systemd for a long while but getting rid of any dependence of my daily workflow on dbus has been more difficult.  Even Gentoo ports pull in dbus for lots of packages where it is not actually needed for the function of the software.  The prime example of this problem is gtk3, which I would like to have available as a gui toolkit but must avoid completely because it absolutely must have dbus in order to draw a user interface (??).

What I've found so far is that a dbus-free desktop is more responsive and presents fewer interruptions (less noise from popups telling me things I already know like "you just inserted a cdrom").  There have been few real losses.  qpdfview is now a good substitute for okular for example. I had to learn to use handbrake's command line instead of the (gtk3-based) gui.  I use a "simple" fluxbox/rox-filer desktop.  It has the feel and workflow of a classic "direct manipulation", "drag and drop" interface.  

I have actually found it more difficult to eliminate dbus from my FreeBSD system!  Many of the FreeBSD ports do not provide "knobs" for disabling dbus, where the Gentoo package does provide for USE="-dbus".  If dbus goes the way I think it will then FreeBSD desktop users will eventually have more trouble coping than Gentoo users.  I'm planning to "git branch pure" in my FreeBSD ports clone and start modifying some of the ports to eliminate "linuxisms," such as dbus, where possible.

I was wondering if anyone has gone through gtk3 or kdelibs to patch out dbus?  That would be helpful to my goal of avoiding messy tentacles.

----------

## depontius

 *steveL wrote:*   

> It's odd, reading GregK-H's posts, it's as if those NAKs never happened.

 

I followed your link, looked elsewhere on the thread, and found this:

 *Quote:*   

> I also have a question is someone of you guys planning to submit a talk
> 
> to future Linux events about kdbus and sdbus ? I have a presentation not
> 
> finished about kdbus, sd-bus coupled with GCC plugins to construct kdbus
> ...

 

What the heck is "sd-bus"?  It looks obviously related to dbus in some way, but they seem to be shoving it sideways into gcc?!?

Google tells me that "sdbus" is something to do with Windows that causes a lot of BSODs, and "sd-bus" has people riding it.

----------

## augustin

 *sitquietly wrote:*   

> 
> 
>  There have been few real losses.  qpdfview is now a good substitute for okular for example. 

 

Sorry, what?

Okular depends on systemd?

----------

## arnvidr

 *augustin wrote:*   

>  *sitquietly wrote:*   
> 
>  There have been few real losses.  qpdfview is now a good substitute for okular for example.  
> 
> Sorry, what?
> ...

 

From what I gathered, he removed gtk3, since it depends on dbus.

----------

## Naib

 *depontius wrote:*   

>  *steveL wrote:*   It's odd, reading GregK-H's posts, it's as if those NAKs never happened. 
> 
> I followed your link, looked elsewhere on the thread, and found this:
> 
>  *Quote:*   I also have a question is someone of you guys planning to submit a talk
> ...

 sd-bus is the backend hooks associated with sd-devices... systemd replacement for udev . Yes thats right kids udev is going away   :Laughing:   :Laughing:   :Laughing:   :Laughing: 

----------

## augustin

 *arnvidr wrote:*   

>  *augustin wrote:*    *sitquietly wrote:*   
> 
>  There have been few real losses.  qpdfview is now a good substitute for okular for example.  
> 
> Sorry, what?
> ...

 

Thanks, but I must be getting something wrong.

Okular is a KDE application, no?

gtk is a GNOME library, right?

Doesn't okular use Qt / the KDE libs?

Also, what I still don't get is the technical relationship between dbus and systemd, beside the fact that they are being developed by the same people (?).

http://en.wikipedia.org/wiki/D-Bus

----------

## Anon-E-moose

 *Naib wrote:*   

> Yes thats right kids udev is going away     

 

As predicted by many of us, well, except for the gentoo dev who kept on trying to lie to us about udev.   :Rolling Eyes: 

----------

## bstaletic

So what happens when there's no more udev, only sdbus? Do we switch to devuan's vdev? Are there any viable alternatives to {e,}udev?

----------

## sitquietly

 *augustin wrote:*   

>  *arnvidr wrote:*    *augustin wrote:*    *sitquietly wrote:*   
> 
>  There have been few real losses.  qpdfview is now a good substitute for okular for example.  
> 
> Sorry, what?
> ...

 

I'm left utterly flabbergasted as to what any of this palaver about systemd has to do with the topic of this thread, which is "kdbus in the kernel".  :Very Happy:  :Very Happy: 

You all were discussing the agenda to move dbus from user space into the kernel, "weaponized dbus". Is anyone here responding in a defensive way by preparing to remove dbus from your system. To eliminate dbus from your system requires eliminating all use of gtk3 AND kdelibs, amongst others. Okular of course is a kdelibs client.

----------

## Anon-E-moose

 *sitquietly wrote:*   

> I'm left utterly flabbergasted as to what any of this palaver about systemd has to do with the topic of this thread, which is "kdbus in the kernel". 

 

Possibly because the sysd people are some of the ones pushing for kdbus to be "included" in the kernel

and they've already said that once kdbus gets into the kernel, they will start using it.

 *Quote:*   

> You all were discussing the agenda to move dbus from user space into the kernel, "weaponized dbus". Is anyone here responding in a defensive way by preparing to remove dbus from your system. To eliminate dbus from your system requires eliminating all use of gtk3 AND kdelibs, amongst others. Okular of course is a kdelibs client.

 

I don't run dbus on my system and haven't for the last year or so.

That gtk3 requires dbus is an absurd dependency.  

Note: I've blocked gtk3 and don't run kdelibs on my system.

I use openbox with the lxde panel (gtk2) and a few qt apps.

I have had to block some apps since they insist that dbus be available one way or another.

I find the next most suitable app to use in that case.

----------

## patrix_neo

I think I just read:

Resistance is futile, asimliate and propagate!

This is just the beginning of a very long journey between the good and the bad. 

It's actually back.

The answer is twofold...first there is the heroes going against the oppression, and finally the truth will hitting everyone. That will happen. Tell me I am wrong...I dare you.

It might take a century in between...finally everyone is up to par. Muy Bien.

A thing like kdubus is just a way to cope with SystemD, if I am right. Which is, as I see it, a variable to destroy freedom as I have felt it to be.

Entanglement. I might be wrong, I might be foolish, but I will stand by it as long it is not....

----------

## steveL

 *bstaletic wrote:*   

> So what happens when there's no more udev, only sdbus? Do we switch to devuan's vdev? Are there any viable alternatives to {e,}udev?

 

Just carry on using eudev, afaic. We don't need it to do any more than it already does; after all that was the point of udev in the first place, that it be a simple userland multiplexor of rt-netlink info from kernel notification-chains. (so the kernel doesn't have to worry about it, but the admin can, as desired by configuration.)

X is the classic example of a userland multiplexor.

Really, all desktop users really care about in the main, is being able to plug in removable devices, and have them show up.

We got past that point ages ago.

----------

## steveL

 *sitquietly wrote:*   

> I've been able to run without avahi/consolekit/policykit/pulseaudio/systemd for a long while but getting rid of any dependence of my daily workflow on dbus has been more difficult.  Even Gentoo ports pull in dbus for lots of packages where it is not actually needed for the function of the software.  The prime example of this problem is gtk3, which I would like to have available as a gui toolkit but must avoid completely because it absolutely must have dbus in order to draw a user interface (??).
> 
> What I've found so far is that a dbus-free desktop is more responsive and presents fewer interruptions (less noise from popups telling me things I already know like "you just inserted a cdrom").  There have been few real losses.  qpdfview is now a good substitute for okular for example. I had to learn to use handbrake's command line instead of the (gtk3-based) gui.  I use a "simple" fluxbox/rox-filer desktop.  It has the feel and workflow of a classic "direct manipulation", "drag and drop" interface.

 

Yeah the RISC-OS filer was lovely. I must take a look at rox soon.

 *Quote:*   

> I was wondering if anyone has gone through gtk3 or kdelibs to patch out dbus?  That would be helpful to my goal of avoiding messy tentacles.

 

Hmm I don't actually have an issue with dbus within the X session, though obviously I'd prefer dcop back again (or a better version, that is competitive with CORBA: either way both were much more performant than dbus.)

I don't see it happening soon, for kdelibs; it'd take a lot of work, and only really be feasible for the release after KF5.

I could be wrong; it might be simple enough to plug in another transport, and provide the qdbus interface.

Though really, one would need to address the GPL-functionality issue wrt licensing, to do it properly.

----------

## depontius

 *steveL wrote:*   

> simple userland multiplexor of rt-netlink info from kernel notification-chains. (so the kernel doesn't have to worry about it, but the admin can, as desired by configuration.)

 

Presuming kdbus does at some point make it into the kernel, it's going to be really interesting to see the fur flying when systemd developers try to remove rt-netlink in favor of kdbus.

----------

## steveL

 *steveL wrote:*   

> simple userland multiplexor of rt-netlink info from kernel notification-chains. (so the kernel doesn't have to worry about it, but the admin can, as desired by configuration.)

 

 *depontius wrote:*   

> Presuming kdbus does at some point make it into the kernel, it's going to be really interesting to see the fur flying when systemd developers try to remove rt-netlink in favor of kdbus.

 

Yeah I saw you commented on that here, but forgot to respond. I don't think it's a good idea at all, since things like dhcpcd were the primary intended consumer of rt-netlink, not udev. (the clue's in the name, ofc.)

Notification-chains just flowed naturally into passing off device information to userland.

Anyhow, another follow-up discussion is here (technical.)

----------

## tclover

 *steveL wrote:*   

> [...]
> 
> I'm sure some social-anthropology student somewhere can describe it much better than any of us, but it strikes me that the use of language is quite interesting. By breezily carrying on, as if the thing hadn't been trashed into the ground, the impression is given that everything's hunky-dory in lala-land: "y'know, just those crazy kernel-devs carrying on as usual, heh what can you do.. roll up, roll up, business as usual." ("one born every second.")
> 
> From the pov of apparatchik-watching, it strikes me that anyone other than that shill would never even get away with it.
> ...

 

Nice post! Just quoting the tasty part of it... What a good summary this "Empire of risng scum" is. Iit couldn't better summarized. Thanks for this, I did not really know (the origin of) apparatchik, though, the word doesn't really matter--I am not one of those who are in love with words/language if you'd like. Only the underlying,--not so underlain anyway like any PR, ads or "empty words, just void" as I like to call them,--the dynamics, the discrete subversion of "the aim" does.

----------

## Anon-E-moose

 *steveL wrote:*   

>  *bstaletic wrote:*   So what happens when there's no more udev, only sdbus? Do we switch to devuan's vdev? Are there any viable alternatives to {e,}udev? 
> 
> Just carry on using eudev, afaic. We don't need it to do any more than it already does;

 

Indeed, for a long time I was using udev 171-r6 before switching to eudev.

I didn't switch because udev wasn't working, I just got tired of having to modify ebuilds 

because the gentoo devs didn't (and still don't) have a clue as to how to write an ebuild

using generic dependencies.

----------

## asturm

 *Anon-E-moose wrote:*   

> because the gentoo devs didn't (and still don't) have a clue as to how to write an ebuild
> 
> using generic dependencies.

 

Pardon?

----------

## Anon-E-moose

Used to a requirement for a dependency (pre the devs from the last few years) was simple, ie "udev"

In their infinite wisdom   :Rolling Eyes:  they've now gone to ">=udev-[whatever version they use]" as a dependency requirement.

Many of the ebuilds that I was changing was simply from things like this.

It's not that it didn't work in the more generic sense, they worked perfectly fine.

Like many of the changes that have been foisted upon the users by gentoo devs 

ie libav vs ffmpeg as default for example, they seem to be ill thought out.

----------

## asturm

 *Anon-E-moose wrote:*   

> Used to a requirement for a dependency (pre the devs from the last few years) was simple, ie "udev"

 

That hasn't changed, a version dependency usually comes from buildsystem or packaging constraints, or upstream recommendation, otherwise there is none applied.

 *Anon-E-moose wrote:*   

> In their infinite wisdom   they've now gone to ">=udev-[whatever version they use]" as a dependency requirement.

 

Maybe it worked for you, that doesn't mean the version requirement is somehow meaningless for everyone else the maintainers have to care for. Maintaining your own system will always be easier than being responsible for anyone else's.

----------

## Anon-E-moose

 *genstorm wrote:*   

>  *Anon-E-moose wrote:*   Used to a requirement for a dependency (pre the devs from the last few years) was simple, ie "udev" 
> 
> That hasn't changed, a version dependency usually comes from buildsystem or packaging constraints, or upstream recommendation, otherwise there is none applied.

 

No, the constraints don't come from other things, I've looked at too many tar balls and seen that myself.

 *Quote:*   

>  *Anon-E-moose wrote:*   In their infinite wisdom   they've now gone to ">=udev-[whatever version they use]" as a dependency requirement. 
> 
> Maybe it worked for you, that doesn't mean the version requirement is somehow meaningless for everyone else the maintainers have to care for. Maintaining your own system will always be easier than being responsible for anyone else's.

 

Actually if it worked for me, it would work for most others. My system isn't extraordinary or unusual.

I'm sure part of the reason for the version dependencies is simply to get people to upgrade because the devs know best.   :Rolling Eyes: 

One could also make the case that it's ignorance on their part or perhaps laziness in checking whether versions are needed or not.

Anyway on to other things.

----------

## asturm

 *Anon-E-moose wrote:*   

>  *genstorm wrote:*    *Anon-E-moose wrote:*   Used to a requirement for a dependency (pre the devs from the last few years) was simple, ie "udev" 
> 
> That hasn't changed, a version dependency usually comes from buildsystem or packaging constraints, or upstream recommendation, otherwise there is none applied. 
> 
> No, the constraints don't come from other things, I've looked at too many tar balls and seen that myself.

 

If you only looked at the tarballs, that's not enough.

 *Anon-E-moose wrote:*   

> Actually if it worked for me, it would work for most others. My system isn't extraordinary or unusual.

 

Most < All (you see what's the problem?)

----------

## steveL

Well it used to be that if there was a requirement for a specific version, you had to comment to explain why, or provide a bug id.

I'm willing to take Anon's summary description at face value, for one, as if there'd been comments to that effect, either in the ebuilds or the eclasses applying the deps, he'd have seen them, and discounted those occurrences.

I don't think there's any merit in making him "prove his assertion" or some other such nonsense; it's perfectly acceptable for him to have a feel for how things have gone in his experience of the last X years, without having to justify it, or be picked up on faux rudeness.

Actually I wouldn't mind seeing the ebuilds Anon works on, if he has an overlay? If not, no worries.

----------

## gwr

Here we go again!

http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02614.html

----------

## Naib

 *gwr wrote:*   

> Here we go again!
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02614.html

 

Been posted already

----------

## gwr

My bad. It's worth getting annoyed at twice, though. :)

 *Naib wrote:*   

>  *gwr wrote:*   Here we go again!
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1506.0/02614.html 
> 
> Been posted already

 

----------

## depontius

However we may all know that kdbus has been submitted - again, I haven't seen much discussion since in lkml.

Am I missing something or has it all been quiet?  Any idea what that means?

----------

## Naib

 *depontius wrote:*   

> However we may all know that kdbus has been submitted - again, I haven't seen much discussion since in lkml.
> 
> Am I missing something or has it all been quiet?  Any idea what that means?

 "There is no objections, it must be getting pulled. Good work all we have finally gotten kdbus accepted. By accepted I mean not objected"

----------

## Anon-E-moose

 *depontius wrote:*   

> However we may all know that kdbus has been submitted - again, I haven't seen much discussion since in lkml.
> 
> Am I missing something or has it all been quiet?  Any idea what that means?

 

I think it means the (k)dbus devs don't have a clue.

They've been told that kdbus won't go into the kernel the way it is right now and 

all they're doing is cosmetic fixes, not addressing the issues brought up by the

kernel devs. 

I predict that GKH will next say "kdbus is good to go because no one has made any negative comments in the mailing list"

Then there will be the same issues raised by the kernel devs. SSDD.   :Wink: 

----------

## gwr

From David Herrmann the latest post:

> I have some more patches pending, mainly metadata rework for 4.2. However, this

> breaks backwards compat so I want to get everything else out first.

Wow, it's like they aren't even paying attention to a word anyone says.

----------

## steveL

 *gwr wrote:*   

> Wow, it's like they aren't even paying attention to a word anyone says.

 

Yup, as discussed before it's as if those NAKs never happened.

Honestly, anyone would think you haven't been paying attention to your own thread.. ;p

----------

## gwr

 *steveL wrote:*   

> 
> 
> Honestly, anyone would think you haven't been paying attention to your own thread.. ;p

 

Ha! I my brain can't process the idiocy. It keeps resetting.

----------

## steveL

 *gwr wrote:*   

> Ha! I my brain can't process the idiocy. It keeps resetting.

 

Hehe; indeed, the idiocy does keep coming round, with the fanbois constantly acting as if this is the first they've heard of any problems with the design and usage of dbust..

And people wonder why we keep on complaining until things are better, or at least acknowledged to be problems. ;-)

----------

## depontius

Bruce Schneier has his yearly "Movie-Plot Terror Contest" - an venture into the absurd exercise.  Adapting that concept, just a little...

1 - Linus takes off on vacation / funeral / wedding / etc, and leaves a trusted lieutenant in charge for the duration.  Something goes wrong in the handoff, and an untrusted party manages to get kdbus into the mainline kernel.

OR

2 - There is a zero-day in the kernel servers, and someone slides kdbus in that way.

Starting with  either of the above...

The mysterious "they"  who slid kdbus into the kernel don't tell anyone.  There just "happens" to be an error in the kernel configurator so that kdbus never shows as an option.  However you can add CONFIG_KDBUS and CONFIG_KDBUS_* suboptions, and it will build, just as you asked.  This sits unseen in the kernel for a few releases, and just for appearance on every other release, they try to push kdbus in, in the usual way.  Then at some point the presence of kdbus is REVEALED, along with the fact that it's been in there for at least six months.  A patch is submitted to enable it in the kernel configurator.

----------

## saellaven

 *steveL wrote:*   

>  *gwr wrote:*   Ha! I my brain can't process the idiocy. It keeps resetting. 
> 
> Hehe; indeed, the idiocy does keep coming round, with the fanbois constantly acting as if this is the first they've heard of any problems with the design and usage of dbust..
> 
> And people wonder why we keep on complaining until things are better, or at least acknowledged to be problems. 

 

But keep in mind, we (the "I don't want systemd crowd") are haters that don't want to talk about the technical stuff because we're idiots... after all, a million distributions turning into redhat clones can't be wrong!

----------

## gwr

 *depontius wrote:*   

> Bruce Schneier has his yearly "Movie-Plot Terror Contest" - an venture into the absurd exercise.  Adapting that concept, just a little...
> 
> 1 - Linus takes off on vacation / funeral / wedding / etc, and leaves a trusted lieutenant in charge for the duration.  Something goes wrong in the handoff, and an untrusted party manages to get kdbus into the mainline kernel.
> 
> OR
> ...

 

I may never sleep with the lights off again.

----------

## Naib

 *gwr wrote:*   

>  *depontius wrote:*   Bruce Schneier has his yearly "Movie-Plot Terror Contest" - an venture into the absurd exercise.  Adapting that concept, just a little...
> 
> 1 - Linus takes off on vacation / funeral / wedding / etc, and leaves a trusted lieutenant in charge for the duration.  Something goes wrong in the handoff, and an untrusted party manages to get kdbus into the mainline kernel.
> 
> OR
> ...

 

now consider this... 

 *Quote:*   

> Torvalds insists that people like Greg Kroah-Hartman have taken over huge parts of the day-to-day work maintaining Linux and that they've built up enough trust to be respected

 

http://www.bloomberg.com/news/articles/2015-06-16/the-creator-of-linux-on-the-future-without-him

----------

## Anon-E-moose

As soon as Linus steps down, "linux" will splinter into more pieces than "unix" ever did.

----------

## depontius

 *Anon-E-moose wrote:*   

> As soon as Linus steps down, "linux" will splinter into more pieces than "unix" ever did.

 

I think if Linux were still a hobby, or slightly more than a hobby, it could keep going.  The splintering is going to happen because of all of the corporate interests.

Years back I saw a cartoon, focused on driving.  There was a guy in a car, in a sea of cars, all at a standstill, puffing exhaust.  There was one thought bubble, leading down to every driver, "If we had mass transit, I would have this highway to myself!"

In a not quite similar vein, I think that's what has happened and is happening to the internet, and to Linux.  For those of us with grey hair, there were plenty of online ventures, before the internet took over.  CompuServe, Prodigy, AOL, GEnie, The Source, and those are just a few of the bigger names.  Then there was also the BBS scene.  Other than BBS, those were done by companies who wanted to OWN it.  They each wanted to take over the market and be THE online provider.

The internet succeeded because NOBODY owned it - it was a level playing field.  Fast-forward ten years (way before today) and all of those same companies want to OWN the internet - they want it all for themselves, all the customers, all the packets, all the revenue.  They haven't figured out that the reason the internet succeeded was because it wasn't owned - that in fulfilling their dreams, they're killing it.  Who knows, maybe today they won't - these days people seem to be much more sheep-like in that respect than they used to.

Same for Linux.  (Same for other things too, but right now these are the two that come to mind.)

By the way, in my "nightmare scenario" / "movie plot dystopia", one of those CONFIG_KDBUS_* is CONFIG_KDBUS_UDEV, which ties udev notification to kdbus to systemd.

----------

## tld

 *Anon-E-moose wrote:*   

> As soon as Linus steps down, "linux" will splinter into more pieces than "unix" ever did.

 Yup...and one can only hope that the kernel devs that actually know what they're doing will go with the right splinter.  It sure doesn't look like too many would be very happy with any kdbus crowd version of the kernel.

----------

## KuroNeko

Not sure in which thread this belongs:

http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html

 *Quote:*   

> kdbus support is no longer compile-time optional. It is now
> 
>           always built-in. However, it can still be disabled at
> 
>           runtime using the kdbus=0 kernel command line setting, and
> ...

 

----------

## Naib

Wow just wow

----------

## tld

 *KuroNeko wrote:*   

> Not sure in which thread this belongs:
> 
> http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html

 

Does anyone even have a clue what they're talking about there?  None of this is in the kernel at all as yet right?  What am I missing?

EDIT: Are they saying that to use the new systemd you have to use kernel patches of theirs??  If so, this while thing's just gone to a new level of absurdity.Last edited by tld on Fri Jun 19, 2015 6:31 pm; edited 1 time in total

----------

## i4dnf

I suppose that's how they think they can force kdbus inclusion in 4.2.

Interesting how they've timed this release with Linus' holidays ...

----------

## KuroNeko

 *tld wrote:*   

>  *KuroNeko wrote:*   Not sure in which thread this belongs:
> 
> http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html 
> 
> Does anyone even have a clue what they're talking about there?  None of this is in the kernel at all as yet right?  What am I missing?
> ...

 

As far as I understood, kdbus support is now always built. Systemd will figure out at boot if kdbus is supported on your kernel and use it if it can. You can override the default at compile time or via kernel command line.

----------

## Anon-E-moose

This is what phoronix says

 *Quote:*   

> One month after the huge systemd 220 update, systemd 221 is out and primarily geared for fixing bugs.
> 
> Lennart Poettering announced the systemd 221 release this morning as a bug-fix release. In addition, systemd 221 now makes sd-bus.h and sd-event.h public and makes KDBUS support no longer optional. KDBUS support is now always built-in rather than offering a compile-time option. KDBUS support can be disabled at runtime if passing the kdbus=0 option to the kernel command-line.
> 
> KDBUS as the new in-kernel IPC mechanism remains not yet mainlined as of Linux 4.1. It's not yet clear whether KDBUS will be accepted for the Linux 4.2 kernel, but systemd developers suggest, "We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled."

 

What they're trying to do is get other distros (than RH) to use their kdbus patches against the kernel.

Looks like their attempt at a groundswell support to "force" the kernel devs hands. 

I don't think it will work in that respect. 

Next up name calling and calls for Linus to step down and let someone "more modern" be the leader.   :Rolling Eyes: 

----------

## gwr

 *Quote:*   

> KDBUS support no longer optional. KDBUS support is now always built-in rather than offering a compile-time option. KDBUS support can be disabled at runtime if passing the kdbus=0 option to the kernel command-line.

 

So, it's both mandatory and optional. Got it.

----------

## steveL

 *gwr wrote:*   

> So, it's both mandatory and optional. Got it.

 

Heh "mandatory": it's the new "optional". ;-)

----------

## steveL

 *Quote:*   

> Torvalds insists that people like Greg Kroah-Hartman have taken over huge parts of the day-to-day work maintaining Linux and that they've built up enough trust to be respected

 

Does anyone who's followed any of this thread, or the others on systemdbust, think for one second that if the above had happened, say last year, that we wouldn't now be downloading gentoo-sources with kdbust built-in?

Now factor in what Torvalds has said about exactly that code.

 *Anon-E-moose wrote:*   

> As soon as Linus steps down, "linux" will splinter into more pieces than "unix" ever did.

 

Looks like it; after all, Greg KH certainly ain't going to stop with his campaign of "niceness" to push kdbust.

He's shown zero awareness of the NAKs based on fundamental design flaws and idiotic usage, in his continued posts, acting as if they never happened and it's just business as usual.

I for one will not be using a kernel led by such a non-coder, only interested in furthering his own position. Classic apparatchik behaviour, no doubt bolstering his stock position in RedHat.

I'll keep a close eye on what people like hpa, Andy Lutomirski, and Russell King(? the ARM guy) get up to, instead. No doubt I'll end up on a "splinter" kernel, which will be mocked as "traditionalist" or some other such specious nonsense.

No way on Earth would I accept GregKH as equivalent to Linus, nor any of the above or several other kernel coders I can think of.

That's not to say a non-coder cannot lead a project; they just have to realise they're an administrator and display humility instead of chutzpah: the exact opposite of this outta-control documentation bod, iow.

Enjoy your corporate overlords when they take over your machine, and don't say you weren't warned.

 *avx wrote:*   

> IMHO, the biggest threats aren't MS or Apple, it's the companies standing on the shoulders of our long time linux user's work and sh*ttng down our throat.

  posted here

Don't forget the Linux Philosophy (thanks, sitquietly) which is what these guys are meant to cherish and nurture.

----------

## stephan-t

oohhh wait the new kdbus in kernel is optional? and it disable but the systemd developers put into their code and born the sdbus.

I long time ago not watching the systemd developer changes, but its disgusting.

----------

## i4dnf

 *stephan-t wrote:*   

> oohhh wait the new kdbus in kernel is optional?

 

It is not even in the official kernel tree yet, it exists only as a set of patches. I guess that makes it even more disgusting, no?

----------

## Naib

 *stephan-t wrote:*   

> oohhh wait the new kdbus in kernel is optional? and it disable but the systemd developers put into their code and born the sdbus.
> 
> I long time ago not watching the systemd developer changes, but its disgusting.

 no, that discussion point was posted in the kdbus discussion (this thread) as a "flip of the coin" post between this and the SysD thread.

It is todo with a change in systemd but with ramifications with regards to kdbus

Basically systemd has stated for a long time that they will hard depend on kdbus once it is available (they have also stated they expect lockstep bump of sysd+kernel and they plan to depreciate udev in favour of sd-device)

While the kdbus kernel patch has been worked on sustemd has had support ready for it (its sd-bus). 

At a guess it would appear that the systemd lot are getting pissed off that it is taking "too long" to appear in the kernel. 

Next approach is the appeal of the masses. Mandate that sd-bus is compiled by systemd is the 1st step - I mean what harm will it do right? There is nothing it can talk to (when has redundant code ever caused any issues...) If you or your distro patch in the present kdbus GREAT systemd will communicate via kdbus instead of dbus (sd-bus talks both) - sd-bus is meant to be a "light weight, OS agnostic wrapper for dbus which can use either libdbus or kdbus"

Next step will be enabling sd-device and completely depreciating udev - non systd distro will have to make a decision to either go to systd or use eudev (or static dev -libudev is being used by userland apps tho...)

The existence of sd-device will more than likely demand kdbus as how can the init system talk to the device manager if udev service isnt started"

Again forcing distro that have committed to systemd to now commit to sd-device and thus sd-bus via kdbus.

Finally by shear inertia and pressure from other distros in the managing of such a key patchset outside of the tree a head-on conflict will erupt and the threat of taking the kernel away (ffmpeg-libav saga and ignoring the other exists) or it is merged in in whatever state it is.

The kernel devs need to be VERY careful. Stay clearly objective and technical and ignore any borderline soft personal attack as any hostile personal response will just provide the platform to justify becoming the one true fork

It is a gamble by the sysd (RedHat) lot and I am not sure if they are completely ignorant of game theory or are very VERY aware of it and are setting up an end-game situation - worst-case for them is they roll back their goals with the sysd project), ie their win-win situation is golden and their lose-lose is becoming less and less likely & less of a driver into obscurity

----------

## steveL

 *Naib wrote:*   

> Basically systemd has stated for a long time that they will hard depend on kdbus once it is available (they have also stated they expect lockstep bump of sysd+kernel and they plan to depreciate udev in favour of sd-device)

 

Sorry to be pedantic, but the word you're looking for is "deprecate"; depreciation is a specific term, and means: the loss in value of a financial asset over time. See how odd this reads when you hold that thought in your head:

 *Quote:*   

> Next step will be enabling sd-device and completely depreciating udev - non systd distro will have to make a decision to either go to systd or use eudev (or static dev -libudev is being used by userland apps tho...)
> 
> The existence of sd-device will more than likely demand kdbus as how can the init system talk to the device manager if udev service isnt started"
> 
> Again forcing distro that have committed to systemd to now commit to sd-device and thus sd-bus via kdbus.
> ...

 

Any distro that's dumb enough not to jump ship to eudev, deserves whatever they get, afaic.

They're just middle-men, looking to profit from whatever seems easiest; not much different from most Windows OEMs, imo.

If they had half a brain, they'd realise there's not much profit in being one of 20 fedora-clones.

No doubt they think they can survive as a "brand" because they're led by numpties with an MBA and not much else.

The problem with sd-bust is what you said: it's a wrapper for the existing crappy design; kdbust is going in to Lennux without any of the design flaws even acknowledged, let alone resolved.

The thing I find amazing is that they get all this review for free, with everything explained to them, and they still don't listen.

Which indicates, as if we didn't already know, that this is not about delivering the best solutions, but a business-war of propaganda and politicking designed to land-grab Linux for the rest of time.

After all, Torvalds is only human, and soon enough he won't want to do much beyond see his grandchildren.

That is the prize that RedHat is going for: control of a codebase that no corporation nor conglomerate, could ever develop.

That's why the VCs gave stock options to kernel devs in the 90s: to keep them on side (or at least: conflicted) for the long game.

 *Quote:*   

> It is a gamble by the sysd (RedHat) lot and I am not sure if they are completely ignorant of game theory or are very VERY aware of it and are setting up an end-game situation - worst-case for them is they roll back their goals with the sysd project), ie their win-win situation is golden and their lose-lose is becoming less and less likely & less of a driver into obscurity

 

They're part of a huge conglomerate now: obscurity is not a concern, only the profit margin. You're right though: the win-win is golden for them, and shitty for everyone else, just like Microsoft killed the truly-independent PC software business.

"You want to compete with us? But we're your only supplier."

If people haven't realised that this is vendor lock-in, pure and simple, then they are as dumb as they want to be.

I'd much rather use Linux as Torvalds intended.

In the meantime, there's no point beating ourselves up about the gullibility of the madding crowd.

In 15 or 20 years, another "One True Way" is going to come round again, after a decade or so where systemd is considered an embarrassment, then simply forgotten as if it never happened, since that's how humans usually handle their mistakes.

By then whichever division of RedHat is managing Poeterring will no doubt have depreciated to zero ;) but no-one will care, as it's just part of the background, and sheeple are more interested in kewl desktop effects than functional software. "Look, shiny!"

----------

## Anon-E-moose

From lkml (Andy Lutomirski) http://lkml.iu.edu/hypermail/linux/kernel/1506.2/04853.html

 *Quote:*   

> Hi Linus,
> 
> Can you opine as to whether you think that kdbus should be merged? I
> 
> don't mean whether you'd accept a pull request that Greg may or may
> ...

 

Hmm

Edit to add: A/o right now there are only about 5 posts in this particular "subject" including one from GKH. 

Worth a read.

----------

## Naib

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/04860.html

----------

## gwr

I think this is getting a bit silly for the kernel devs, and I can't blame them for this inquiry. GKH has essentially side-stepped every single question and concern raised by them, and patches and pull requests continue to come in for code that is still rapidly changing. Meanwhile, it appears RH has the effort to spend shimming around the kernel rather than spending the effort to fix dbus or address any kernel issues. Why would any kernel dev _want_ to spend the time reviewing something that doesn't get addressed? GKH is being disingenuous at best.

----------

## steveL

 *gwr wrote:*   

> GKH has essentially side-stepped every single question and concern raised by them, and patches and pull requests continue to come in for code that is still rapidly changing. Meanwhile, it appears RH has the effort to spend shimming around the kernel rather than spending the effort to fix dbus or address any kernel issues. Why would any kernel dev _want_ to spend the time reviewing something that doesn't get addressed?

 

Precisely; the whole thing is a giant waste of time. It's a bad design, period.

Everyone with any sort of experience who's reviewed it along the way, has said the same thing.

The response has without fail been to simply ignore whomever it was, and keep up the propaganda and arm-twisting campaign.

Lot harder to do when Torvalds has come out and flat-out labelled dbust "bad userspace code", which is shorthand for "this is bad userspace code and design, so there's no point in trying to optimise it, nor support its usage mode in the kernel."

It's always better for userland beginners to learn the proper facilities, for everyone concerned.

It used to come up a lot, less so nowadays since we've had 20 years of people learning in public, with mistakes there for others to learn from, or discussion to refer back to.

OFC that's not in play, when you have outsiders (like Windoze rejects) invading the community in order to make a name and a buck; they don't care about the traditions, and they don't care about the craft, only in getting themselves ahead at the expense of everyone else.

 *Quote:*   

> GKH is being disingenuous at best.

 

It's odd, I feel a vague sense of relief reading his bitchiness. He's carried on like that with me in the past, and I know it's wrong, but I feel almost glad that it's not just me. I think it's more that I can see it as bitchiness, plain and simple, when it's not directed at me.

That in itself makes me realise, that it wasn't my problem; independent verification if you like.

It does give the lie to his default posture of "friendly big-brother, who you really do want in charge (look: how smug^W confident I sound, I must be right..)" Like most apparatchiks, he knows what line to sell, but scratch the surface by disagreeing, which is seen as hostile opposition as you're getting in his way, and he has a right to advance, goddammit.. and you get the snipey put-downs, to make an example of you so others will be cowed.

It's pure bully-boy behaviour, imo.

This is just pathetic:

 *GregK-H wrote:*   

> How about you just wait for the real merge request to be submitted, and
> 
> we can go from there. Perhaps I wasn't going to do it this release?
> 
> Perhaps I was? Who knows? Who cares.

 

Perhaps you could be a bit more collaborative, rather than assuming everyone just has to fall in line whenever you breezily feel to drop a  shedload of crappy code into the kernel.

Does anyone really want such an attitude in charge of kernel-development when Torvalds steps back from the daily grind?

If so, expect the quality to nosedive, as the Red Queen lays about her, whilst all the real coders move on to something else (like the "hater's fork".)

 *Quote:*   

> > The current state of uncertainty is problematic, I think. The kdbus
> 
> > team is spending a lot of time making things compatible with kdbus,
> 
> > and the latest systemd release makes kdbus userspace support
> ...

 

More weasel words; systemdbust clearly makes the userspace support compile by default, and we've all seen exactly what their "you can turn it off with a compile-time switch" really means: "if you turn this off, we'll conduct a campaign of vilification against you" which no-one in their right mind wants to deal with.

Life's far too short to devote headspace to working with such asshole numpties.

They're foisting it on to downstream bindists as they've foisted everything else for the last 7-10 years.

Anyone who wants to argue different is either hopelessly naive or a liar, afaic.

No-one gave them any trouble when they told us partitioning schemes that have been in use for over 30 years, are "broken by design", nor when they dicked about with races they introduced, should have foreseen, and never bothered to test; instead they got away with the insanity of hw bus names exposed to the admin, as well as the bulshytt ride that is loginkit.

There's "crazy userland", and then there's "desktop": where any old shit will do, so long as it looks pretty. After all, "the kernel will stop us doing anything dangerous, right?" Not any more: not with all that insanity on top of it. That's what PAM is for, but you drowned that in polkit-js-systemdbust-login too.

That's the trouble with business led by sales and marketing: it's not about getting the job done any more, it's all about the hype and the sizzle, not the sausage. You can keep it.

----------

## augustin

 *Quote:*   

> > Can you opine as to whether you think that kdbus should be merged? I
> 
>  > don't mean whether you'd accept a pull request that Greg may or may
> 
>  > not send during this merge window -- I mean whether you think that
> ...

 

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html

----------

## Yamakuzure

 *Linus Torvalds wrote:*   

> We don't merge kernel code just because user space was written by a retarded monkey on crack.

 Hear hear!  :Wink:  *Andy Lutomirski wrote:*   

>  I don't intend to review that part for security in advance because I've already said my part: I think the design is unfit for its purpose. Given that I don't see how one is supposed to use it in a sensible manner for sandboxing in the first place, it's hard to evaluate whether it will do its job a priori.

 From his answer to Linus.

----------

## Anon-E-moose

This was posted by Ingo (in response to the post that augustin quoted)

 *Quote:*   

> Beyond the cons, I see four arguments in favor of kdbus:
> 
> - In its current form kdbus really does not hurt the core kernel in any appreciable
> 
> way: like Android's Binder it sits in its own corner that doesn't hurt anyone.

 

http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00073.html

Interesting reasoning on his part.

As far as Linus trusting GKH, I think Linus will look back (sometime in the future) and realize what a horrible mistake he made in doing so.

For me, I won't have k(dbus) on my system as it works perfectly well without it.

And if it should somehow become mandatory to even use linux, then I see a bsd variant in my future.

I don't need the political crap nor devs, ie GKH, selling out the majority of linux users just for some goodies that they will get from RH (or whoever).

----------

## gwr

 *Anon-E-moose wrote:*   

> 
> 
> Interesting reasoning on his part.
> 
> 

 

It's true if you only look at the situation from the kernel's perspective. It doesn't hurt the kernel, it hurts some of the Linux-based distributions that use it. I don't share that point of view, because it's a bit like biting the hand that feeds you.

----------

## Naib

 *Anon-E-moose wrote:*   

> This was posted by Ingo (in response to the post that augustin quoted)
> 
>  *Quote:*   Beyond the cons, I see four arguments in favor of kdbus:
> 
> - In its current form kdbus really does not hurt the core kernel in any appreciable
> ...

 

Thats a very top-level view of kdbus "it sits in its own corner"  and if it did then sure, why not... 

If KDBUS really was just a bolt on then the kernel developers remaining as independent from wider distribution political battles would find it hard to not accept the concern (assume KDBUS was from a kernel point of view, good code... what argument exists to reject it, atomic to the kernel?) 

Which comes back to the present implementation that spreads its fingers across alot of kernel functions -ie isn't just in its own little corner and the reasoning being "faster"  faster isn't itself a good reason (Windows kernel put font rendering into the kernel and it resulted in an exploit from a webpage...). The argument for its inclusion will more than likely morph from one of performance to one of security in association with sd-bus & sd-devices, which then ties up a very specific boot sequence for linux at the point of init handover...

----------

## gwr

 *Naib wrote:*   

> ... which then ties up a very specific boot sequence for linux at the point of init handover...

 

But, apparently according to Linus' reasoning, that isn't a kernel issue.

----------

## Naib

and he has a point when viewing linux as a kernel.

----------

## gwr

 *Naib wrote:*   

> and he has a point when viewing linux as a kernel.

 

Although, it's still confusing to me that Linus views putting it in the kernel for "performance reasons" to be invalid. If kdbus really does only occupy a corner of the kernel and it's up to distributions to decide whether to use it or not, why would he care if the performance was utter crap? Why pick on that criteria, and not, oh, I dunno, that the entire design is bafflingly pointless?

----------

## ulenrich

 *gwr wrote:*   

> Although, it's still confusing to me that Linus views putting it in the kernel for "performance reasons" to be invalid.

  He did say he would like to have a better performing kdbus in the kernel. As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better. Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits:

- boot and shutdown with systemd in a sober manner without all these special hardcoded units 

- the widely and since long used dbus will run in a secured kdbus environment (without javascript)

- virtual machines communication feature added

- dbus running in the kdbus environment will scale up for use with multimedia 

The last one is possible due to less mem copying using dbus in a kdbus environment, which was the point people talked about performance. Most of the above would be used by the majority of Linux users from day one. Also the adoption rate of application programmers will boom, because dbus protocols do hide complexity. If all of the security problems of dbus can be solved in the kernel the rate of security issues of new applications will go down. And for sure the argument of steveL: To be able to circumvent the GPL will push Linux as a choosen environment for applications.

Andy Lutomirski announcing how he will test the next kdbus proposal regarding security and Linus interest in performance, which signals an important aspect of quality of the code, makes me confident the kernel developers are able to decide when to include kdbus into mainline. Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.

----------

## Naib

They are stupid, how many pull request have there been before ? How many times did they change the API

----------

## mv

 *ulenrich wrote:*   

> Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits

 

It is very dirty rhetoric trick to formulate marketing buzzwords pretending that they were from Linus.

Linus said very precisely his only reason why he does not kill the kdbus idea immediately: He had previously trusted one person advocating it.

This is a valid social reason. Quite the opposite of your invented marketing reasons which BTW are technically plainly false. (Except for the last one which is exactly the argument which Linus explicitly rejected as invalid.)

Edit: removed a too aggressive formulation.Last edited by mv on Thu Jun 25, 2015 11:22 am; edited 1 time in total

----------

## augustin

 *ulenrich wrote:*   

>  *gwr wrote:*   Although, it's still confusing to me that Linus views putting it in the kernel for "performance reasons" to be invalid.  He did say he would like to have a better performing kdbus in the kernel. As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better. Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits:
> 
> - boot and shutdown with systemd in a sober manner without all these special hardcoded units 
> 
> - the widely and since long used dbus will run in a secured kdbus environment (without javascript)
> ...

 

I am still trying to get up to speed. Is systemd the main/only motivation to include kdbus into the kernel (besides GPL circumnavigation, as pointed out by Steve, I believe)?

What is the primary motivation for the people behind kdbus?

----------

## Naib

Any IPC can be used to circumvent the GLP and yes that includes files and TIPC.  If the author of a library decides to expose its entire API to an IPC (instead of requiring linkage -> gpl inclusion)  then well... more fool them.  HOWEVER something still needs  facilitate the link (a library doesn't run without some application using it) so you need clear intentions to bypass the GPL via an IPC 

1) some gpl library/program must expose its API to an IPC

2) something must launch the library.

So why is the IPC the boogyman here when it is the author of the glp'ed library that facilitated it?  its like blaming the gun for someone shooting up a school - non sequitur. Would you blame Ext4 for facilitating in bypassing the GPL (and yes I have done something nasty with files as an interprocess comms to produce a crude co-processor between matlab and EFFE [FEA application] as I could take credit for EFFE watching for a certain file to auto exec and a simple matlab script was written to watch for a suitable output file...

Linking (and thus being wrapped in the gpl) will always be faster due to the shared memory

KDBus/TIPC in theory would be the next fastest

DBus 

Sockets

Files

If there is a conspiracy to bypass the GPl via an IPC ( as 1st popped up here: http://slashdot.org/comments.pl?sid=5735323&cid=47959449) it for starters wouldn't be the first (gpl3 was created to close a tivo loophole iirc) 

Sysd are the most vocal with regards to needing dbus, their aim is to perpetuate sysd and if you notice they created sd-bus "a fun api to provide inter process communication"  which will use dbus or kdbus. While sysd has made it clear they would target ONLY linux, sdbus has been released cross-platform (inc windows).

At a guess I would think GNOME and its apps would jump onto sdbus ASAP as it would "simplify their applications dbus interface" and they would magically get a performance boost if kdbus is present - the fact KDBUS isn't that efficient doesn't change the fact it is a boost over userland AND it could, if further optimised give a big boost. 

One thing I would say around KDBUS is if an in-kernel IPC is required or is deemed the next evolution, there is one thing to concider with KDBUS over others: https://xkcd.com/927/

Now I am not saying KDBUS is great or will be great if/when they sort it out

What's more realistic is RH/Systemd intention to wrap the kernel completely and thus no application needs to interface with the kernel BUT must go via systemd. Systemd includes an EFI bootloader, systemd is the handover from kernel to userspace for init... more and more of linux is being encapsulated in systemd which provides a level of abstraction. So rather than userland interfacing with the kernel, they would all interface via systemd

----------

## augustin

Thanks, Naib. Your comment helps me understand a bit better the whole debate, although, I am sure, I still have much more to learn.

 :Smile: 

----------

## ulenrich

 *mv wrote:*   

> Linus said very precisely his only reason why he does not kill the kdbus idea immediately: He had previously trusted one person advocating it.
> 
> This is a valid social reason. Quite the opposite of your invented marketing reasons which BTW are technically plainly false. (Except for the last one which is exactly the argument which Linus explicitly rejected as invalid.)

 

Nobody had expected Linus would answer such hypothetical , because nobody knows how the next kdbus patches for the next pull request will look like. Greg answered this bitchy looking question:

 *Greg wrote:*   

> > Can you opine as to whether you think that kdbus should be merged?
> 
> Ah, a preemptive pull request denial, how nice.
> 
> I don't think I've ever seen such a thing before,

  Linus normally would not answer. But why he did? 

If an officer currently in charge to stablelize the kernel is asking for a pull request, this is a call for Linus to soonishly accept but not later. If no NOK. This he announces. The question answered was a "wake up call" for Andy Lutomirski to learn more about kdbus, which he promptly does :

http://lkml.iu.edu/hypermail/linux/kernel/1506.3/index.html#00169

This indicates his question in the first place was not meant just bitchy. He was in need of a hint from his leader.

Talking about Linus how "He had previously trusted one person" sounds to me like a Tolkien drama. I don't take the expressed trust in Linus announcement literally as his sole motivation. This is naive. Linus for sure knows more than he talks about,  *augustin wrote:*   

> What is the primary motivation for the people behind kdbus?

 

Linus himself uses systemd and knows about the motivation of Poettering: systemd developers want to get a kernel based infrastructure to implement a proper reboot technique.

@mv, sure I talk about the marketing arguments for kdbus in the kernel. They may be false. Perhaps not invented or implemented yet. It is what is marketed ... Your own understanding of what is going on seems to me like crazy: Why should Linus "reject" reducing mem copying of kdbus? Perhaps you got confused here:

Linus saw some performance tests using short message samples. These showed kdbus is not much faster than a sane programed user mode dbus would be (if existed). Linus rejected performance as a sole argument for kdbus inclusion.  

@mv, your red marked sentence is insinuating a motivation of me which my post as a whole does not deserve. Especially in the light of my last clause there: *ulenrich wrote:*   

> Andy Lutomirski announcing how he will test the next kdbus proposal regarding security and Linus interest in performance, which signals an important aspect of quality of the code, makes me confident the kernel developers are able to decide when to include kdbus into mainline. Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.

 

 *Naib wrote:*   

> How many times did they change the API

  That an argument to wait further for kdbus to be ready! But don't miss Linus saying at http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00753.html

 *Linus wrote:*   

>  I do agree that distro's that want to enable kdbus before any agreed
> 
> version has been merged would get to also act as guinea pigs and do
> 
> their own QA, and handle fallout from whatever problems they encounter
> ...

  This lets me think Linus wants kdbus in mainline. Really just because Greg is so trustworthy? About this motivation my post:

https://forums.gentoo.org/viewtopic-p-7769316.html#7769316

Beg pardon for my overly quoting style in this post. It is ever hard for me to acknowledge all of what people have ignored and don't want to see.Last edited by ulenrich on Thu Jun 25, 2015 11:15 am; edited 1 time in total

----------

## mrbassie

 *ulenrich wrote:*   

> 
> 
>  *Linus wrote:*    I do agree that distro's that want to enable kdbus before any agreed
> 
> version has been merged would get to also act as guinea pigs and do
> ...

 

you left out :

"But I don't think we really end up

having the option to make up some incompatible kdbus ABI

after-the-fact."

----------

## ulenrich

 *mrbassie wrote:*   

> you left out :
> 
> "But I don't think we really end up
> 
> having the option to make up some incompatible kdbus ABI
> ...

  Read my f... fulminant sentence answering Naib! The warning to the distros playing the guinea pig evaluates further as a plan to accept kdbus when it is ready: Why would he warn otherwise?

[edit]changed language in request of mrbassieLast edited by ulenrich on Thu Jun 25, 2015 11:54 am; edited 2 times in total

----------

## Naib

 *ulenrich wrote:*   

> 
> 
>  *Naib wrote:*   How many times did they change the API  That an argument to wait further for kdbus to be ready! But don't miss Linus saying at http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00753.html
> 
>  *Linus wrote:*    I do agree that distro's that want to enable kdbus before any agreed
> ...

 

and that doesn't dismiss my point. A pull request should not have gone in. Code quality is one thing (userland writing kernel will always be ... interesting EXACTLY like vhdl writers writing python [something I have to deal with]) but having a non-stable API and expecting a pull is retarded... AND the type of thing that results in updating the kernel in lockstep.

Imagine if the 1st kdbus pull request got accepted "oh wait we want to change the API..."

----------

## mv

 *ulenrich wrote:*   

> your red marked sentence is insinuating a motivation

 

Yeah, it was too aggressive. It is now removed.

----------

## ulenrich

 *Naib wrote:*   

> and that doesn't dismiss my point. A pull request should not have gone in. Code quality is one thing (userland writing kernel will always be ... interesting EXACTLY like vhdl writers writing python [something I have to deal with]) but having a non-stable API and expecting a pull is retarded... AND the type of thing that results in updating the kernel in lockstep.
> 
> Imagine if the 1st kdbus pull request got accepted "oh wait we want to change the API..."

   :Smile: 

This time there was no pull request. But the discussion in the kernel mailing list well may be part of the stabilizing process of the API (or ABI ? the same in this context?). Kind of an interesting thread there about misunderstandings and clarifying attempts:

http://lkml.iu.edu/hypermail/linux/kernel/1506.3/index.html#00169

But also very naive questions there sometimes:

http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00795.html

Although the author knows Linus has answered this already (he indicates by not directly talking to Linus name)Last edited by ulenrich on Thu Jun 25, 2015 11:50 am; edited 3 times in total

----------

## Naib

I know there wasn't (so that is at least an improvement upon hte previous two  or three...). Just because there isn't a new pull request doesn't magically change history and scrub the fact that there were previous pull requests AND at least one API change

----------

## mrbassie

 *ulenrich wrote:*   

>  Read my fucking sentence just above answering Naib!

 

Was that really necessary?  :Rolling Eyes: 

----------

## ulenrich

 *mv wrote:*   

>  *ulenrich wrote:*   your red marked sentence is insinuating a motivation 
> 
> Yeah, it was too aggressive. It is now removed.

  And don't you think Linus would be very interested in kdbus if the 4 marketing points I listed where sanely implemented. I mean beside any emotional moments when Linus looks into Gregs wonderful eyes. My impression reading this wonderful thread: Linus is sitting before his laptop and starts Google hangout for to see Gregs trustworthy face again.

----------

## gwr

 *augustin wrote:*   

> [He did say he would like to have a better performing kdbus in the kernel. As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment.

 

Allow me to me rephrase a little. I completely agree that this is a valid argument. I am confused as to why this issue is the only issue that he raised with it. Even if it's performance was fine, I still think there is an over-riding issue that it is functionality that doesn't need to exist at all. It doesn't need to be written, deployed, or maintained. And it's technically unsound even if it did need to exist.

----------

## depontius

I like this little tidbit, which draws parallels between kdbus and the in-and-out devfs: https://lkml.org/lkml/2015/6/25/42

On another level, there's something else going on here, and I don't think it's generally recognized.  L.P. has forced the issue by pushing the kdbus-first requirement out to the distributions with systemd.  Linus is clearly feeling the pressure, knowing that a kernel change may prevent systems from booting.  He hasn't phrased it as pressure, but he clearly recognizes that the problem exists, and appears to be getting ready to act on that perceived problem.

In other words, systemd has taken over some portion of the kernel decision process and control.

There will be two further litmus tests:

1 - The next time they want to juggle the kdbus API in an incompatible way.

2 - When they reach elsewhere in the kernel and make kdbus the way to signal udev events.  ("Gentoo, you have been warned!"  If not exact, that's a near-exact quote.)

There are two other stated directions by the systemd team:

1 - Systemd writes to Linux, and everyone else writes to systemd.  In other words, only one Linux user - systemd, the rest of us become systemd users.

2 - The kernel moves in lockstep with system.

At the risk of courting Godwin, there have been other times in history when you don't even have to read between the lines.  There have been times when intentions have been stated out in the open, and nobody really believed it.  Then when those intentions are acted on, people seem surprised that that's happening.

----------

## steveL

 *ulenrich wrote:*   

> He did say he would like to have a better performing kdbus in the kernel.

 

He's already got TIPC. So kdbus is just pointless reinvention of the wheel, only they're banging on about how the circle is outmoded, and we should all be using hexagons, no wait, version 2.0 is out, now with octagons!

We can argue all we like about the difference between hexagons and octagons, but the point remains: they're both shit by comparison to what they're trying to displace.

It seems to me that half the game is to get us to argue about their crap instead of focussing on something better.

 *Quote:*   

> As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better.

 

Why do you keep making vague allusions to something that no-one can check? That's what I mean by "politicking" in your discourse; you're holding out this mysterious sense of "don't worry, someone knows better than you" when past history would demur.

If anything, more often than not we're presented with a latest brainwave that will soon be forgotten, except that we'll all be forced to implement it, and then throw it away for the next turd. In each case, reason and technical design count for nothing; it's all about propaganda and hype.

 *Quote:*   

> Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits:

 

I rather think Torvalds is simply dealing with what comes up, when it comes up, just like he always has.

I certainly don't see any of these as benefits:

 *Quote:*   

> - boot and shutdown with systemd in a sober manner without all these special hardcoded units 
> 
> - the widely and since long used dbus will run in a secured kdbus environment (without javascript)
> 
> - dbus running in the kdbus environment will scale up for use with multimedia

 

IOW "fixing problems we made" and then labelling it "progress".

It may be "improved on our last product" but it's still crap in the overall scheme of things.

 *Quote:*   

> - virtual machines communication feature added

 

Yeah cos no-one else has being doing any work in VMs in the last 20 years.. systemdbust is the only way to do that, ofc /s

The arguments with the docker people will soon be forgotten, just like the arguments with pro-audio.

 *Quote:*   

> Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.

 

This is pure nonsense; I know you're not as naive as this statement pretends.

Corporations are based on corrupted money, by definition. They regularly act against the interests of everyone else, including the community that nurtured them in the first place.

If we don't stand up for ourselves, later we'll be told "you should have complained back then"; when we respond "we did", we'll be told "all complaints were dealt with" and by implication: "you're a liar" (cue: insinuations, bitchiness and pooh-poohing as if it's all just in our heads. "Trust in me..")

Still, so long as you've got your corporate tee-shirt, everything will be fine right? Just sing along, and keep doing the work for free, so they can sell it back to you, wrapped up in crap, but with lots of sizzle.

Nowadays we venerate thieves and fraudsters as "successful" and then wonder why our kids are so unhappy, and so mean-spirited, as if it were nothing to do with us, and the paucity of empathy inherent in everyone trying to grab what they can.

The last link above (on audio) practically reads like a response to this, though.

----------

## steveL

 *Naib wrote:*   

> Any IPC can be used to circumvent the GLP and yes that includes files and TIPC.  If the author of a library decides to expose its entire API to an IPC (instead of requiring linkage -> gpl inclusion)  then well... more fool them.  HOWEVER something still needs  facilitate the link (a library doesn't run without some application using it) so you need clear intentions to bypass the GPL via an IPC 
> 
> 1) some gpl library/program must expose its API to an IPC
> 
> 2) something must launch the library.
> ...

 

Eh, we discussed this ages ago. It's not about the GPL library providing the API over dbust; it's about an LGPL-GPL combination, whereby the GPL part links to the GPL-code you want to leech, and only provides a dbust-R^IPC connection, and then your leechclient can link to the other side of that mess, which is LGPL and the only way to talk to that GPL-evasion.

This flies against all common sense for two reasons: one would normally wrap an existing API, or implement one to wrap first, since it's much easier to test and the API can be used directly, much more efficiently. The point being that there is an API first, and then it's exposed, should the authors actually want to do that.

Secondly it makes no sense to redirect what is in effect a local function call, simply to relabel it RPC (woops IPC since this is local machine) because that is orders of magnitude slower.

The original work on dcop and GNOME's ORB was much better.

It's like Poeterring and Sievers came in as a third-party, and ended up stealing the jewels from both the others. Classic carpet-bagging.

Nice try to put kdbust and TIPC on the same level, but they're worlds apart. The latter doesn't try to reinvent everything in the kernel in userland and then push for the entirety of the same mess in-kernel. It just does what's needed.

Now you can spend 20-30 years "improving" your turd until you finally end up reinventing what came before; or you can design up-front, based on past experience.

The latter is characterised by careful research, the former by bulshytt and hype, and works primarily because people are social creatures, and like to feel we're all moving forward together, even if we are going in circles.

The simple fact though, is that the kdbust "developers" have made it a point of pride that they will provide the exact same "semantics" as dbust, and as we've already seen, that is not going to work.

So expect a climbdown on that at some point in the future, once they've established their Lennux fork of Linux, and can do so quietly with one of those lovely "look what we've discovered" blog-posts ("don't you just feel special to be involved?")

I've lost count of how many of those I've read in the last 7 years, how many interfaces that were recommended to them which they shot-down with nastiness and zero-thought, only to see the light a few years later.

polkit was supposed to "obsolete PAM", and now PAM is the bees-knees and required for systemdbust.

"POSIX is full of shit", but hey now we've actually got some experience under our belt, we love POSIX RT-signals so much we've stopped every other program on your machine from using them.

You couldn't make it up, hehe.

----------

## steveL

 *depontius wrote:*   

> On another level, there's something else going on here, and I don't think it's generally recognized.  L.P. has forced the issue by pushing the kdbus-first requirement out to the distributions with systemd.  Linus is clearly feeling the pressure, knowing that a kernel change may prevent systems from booting.  He hasn't phrased it as pressure, but he clearly recognizes that the problem exists, and appears to be getting ready to act on that perceived problem.
> 
> In other words, systemd has taken over some portion of the kernel decision process and control.

 

Agreed; though perhaps more accurate to say "RedHat", or rather whatever the name of the dodgy tax-evading conglomerate they're part of may be.

----------

## ulenrich

 *steveL wrote:*   

>  *ulenrich wrote:*   He did say he would like to have a better performing kdbus in the kernel. 
> 
> He's already got TIPC. So kdbus is just pointless reinvention of the wheel, 

 

Looking up the timelines of both projects dbus and tipc: Seems to me a parallel development. If you look up the tipc roadmap 2015/16: open problems all over the place there also. Especially the ABI for C developers using TIPC is about to be redesigned? Reading about nodes and clusters: Isn't it a different domain they talking about? 

 *steveL wrote:*   

> It seems to me that half the game is to get us to argue about their crap instead of focussing on something better.

 

If dbus is total crap inside isn't this a typical starting-point to work over the shared resource: Here at this point using TIPC is reinventing the wheel.

 *steveL wrote:*   

>  *Quote:*   As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better. 
> 
> Why do you keep making vague allusions to something that no-one can check? That's what I mean by "politicking" in your discourse

 

On the contrary of politicking in favor of kdbus I speculate about Linus trying some tactics to get dbus in the kernel. You cannot understand it assuming Linus is pressured to accept kdbus. Me assuming the contrary I see some communication of Linus is tactic here.

 *steveL wrote:*   

> I certainly don't see any of these as benefits:
> 
>  *Quote:*   - boot and shutdown with systemd in a sober manner without all these special hardcoded units 
> 
> - the widely and since long used dbus will run in a secured kdbus environment (without javascript)
> ...

 

1. Also openrc has an extra sysinit stage. 

2. Every IPC must solve the security problem. How does TIPC? 

3. Using dbus for multimedia was an idea of the automotive industry. 

 *Quote:*   

>   *Quote:*   - virtual machines communication feature added 
> 
> Yeah cos no-one else has being doing any work in VMs in the last 20 years.. systemdbust is the only way to do that, ofc /s
> 
> The arguments with the docker people will soon be forgotten,

 

 @steveL, this the original domain of TIPC - it can get some merits there for sure, if not forgotten and unused.

 *steveL wrote:*   

>   *Quote:*   Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid. 
> 
> This is pure nonsense; I know you're not as naive as this statement pretends.
> 
> Corporations are based on corrupted money, by definition. They regularly act against the interests of everyone else, including the community that nurtured them in the first place.

 

I had read that history of the banks of England and the US some time ago. And I know the City of London in that respect is a special case until today. I wonder if Bitcoins will have a different outcome. I know what you talk about. Interesting in our discussion is when big money fails to implement its purpose like for example Novell with SuSE in recent years: Too many cultural differencies, it failed. The Red Hats coming from our opensource community may well have learnt their lessons. It is pure nonsense for Redhat to pay a vote for kdbus inclusion. On the contrary in the course of events of evaluation they get the high quality Linux kernel they need for their success. 

In this time of exponentially growth of the mobile market where all of the big players (Apple,Google,Microsoft etc) do have their IPC and their service managment, isn't it the last chance to play a role in emerging mobile prospects for Gnu-Linux companies to have kDbus/systemD? Though I must acknowledge your argument this is the chance to die as open source also ... Naib just had a say on this: Gpl version 3

----------

## gwr

 *ulenrich wrote:*   

> ... isn't it the last chance to play a role in emerging mobile prospects...

 

Emerging? The market has been around almost a decade and Linux already has the lion's share of it via Android. It's long past emerged and Linux has already proven that it doesn't need kdbus to be successful, regardless of whatever RH has to say about it.

----------

## krinn

 *ulenrich wrote:*   

> It is pure nonsense for Redhat to pay a vote for kdbus inclusion. On the contrary in the course of events of evaluation they get the high quality Linux kernel they need for their success.

 

You are really naive  :Smile: 

If any company could add a new molecule that would make customer addict to their product at first try, but kill them in 10 years, they will, it is better to have anyone trying it depend on it, even if it's only for 10 years.

Make big money, and we will see how to make even more 10 years later, but for now, just take the money.

A broken kernel is not at all bad, it is a support people will pay to fix it.

And if you are the one controlling dbus, it is to YOU that people will pay that support.

----------

## steveL

 *ulenrich wrote:*   

> He did say he would like to have a better performing kdbus in the kernel.

 

 *steveL wrote:*   

> He's already got TIPC. So kdbus is just pointless reinvention of the wheel, 

 

 *ulenrich wrote:*   

> Looking up the timelines of both projects dbus and tipc: Seems to me a parallel development.

 

Er, whut? TIPC was started in the mid 90s.

Pretty sure dbus was begun a lot later. So: no, not parallel development at all.

 *Quote:*   

> If you look up the tipc roadmap 2015/16: open problems all over the place there also. Especially the ABI for C developers using TIPC is about to be redesigned? Reading about nodes and clusters: Isn't it a different domain they talking about?

 

Provide some urls if you want to discuss things.

Personally I'm glad they're open and transparent about what's happening. As for "a different domain" we're talking about using localnode only.

That it does more is nice, and could be used for LAN, but that's by-the-by atm. In any event it's not an issue; if anything it makes us feel better about using it, since it is a general-purpose transport tailored for the situation, rather than an attempt to be everything to everyone via hype.

I'm not going into the rest of it; I'm hard-placed to find any meaning in it. (I wouldn't rely on bitcoin either; that thing's a scam waiting to happen.)

----------

## Shamus397

Well, lookie here, this just landed in the lkml.  :Very Happy: 

----------

## steveL

Nice review, and clearly correct, from the reply.

 *Ingo Molnar wrote:*   

> So there exists a technical vacuum: the kernel does not have any good, modern
> 
> IPC ABI at the moment that distros can rely on as a 'golden standard'.

 

Does no kernel developer even know about TIPC in linux?

Seriously, this is getting embarrassing.. they're maintaining the module ffs.

----------

## gwr

 *steveL wrote:*   

> Does no kernel developer even know about TIPC in linux?
> 
> Seriously, this is getting embarrassing.. they're maintaining the module ffs.

 

I don't know a lot about it, but can't somone from this thread mention it on the lkml?

----------

## steveL

 *gwr wrote:*   

> I don't know a lot about it, but can't somone from this thread mention it on the lkml?

 

Yeah anyone can; it was brought up in earlier discussion with the networking folks. Best overview post here.

We discussed the objections at the beginning of this thread, and I pulled out two posts here which are extracted from that overview, for ease of review.

I'm probably not thick-skinned or politic enough to post to lkml, though. Certainly, I'd have a hard time staying polite with GregK-H being waspish to me again, given what's happened in the intervening 3 years.

----------

## Naib

Round n+1. 

http://lkml.iu.edu/hypermail/linux/kernel/1507.0/02970.html

----------

## Anon-E-moose

The kdbus crowd has given up on trying for 4.2 kernel and are aiming for 4.3.

So expect more "changes" soon, though they will only be cosmetic and not in the direction that the kernel devs have said is needed to get ACKs for their code.   :Rolling Eyes: 

----------

## arnvidr

 *Anon-E-moose wrote:*   

> So expect more "changes" soon, though they will only be cosmetic and not in the direction that the kernel devs have said is needed to get ACKs for their code.  

 They're not cosmetic at all, it seems, only bug fixes and the like. Which naturally has nothing to do with the reasons people NACKed it. Because "the design is valid" :p

----------

## mrbassie

Pardon my ignorance but what does 'nack' stand for (I'm assuming it's an acronym)?

----------

## khayyam

 *mrbassie wrote:*   

> Pardon my ignorance but what does 'nack' stand for (I'm assuming it's an acronym)?

 

mrbassie ... I've always taken it to be derived from Negative-Acknowledge Character (so "a negative response"), but I'm not sure why exactly I made that assumption ... perhaps because many kernel components use NAK/NACK, i2c for instance.

best ... khay

----------

## gwr

 *Quote:*   

> Drop unused features. This includes KDBUS_MSG_MAX_ITEMS, required attach
> 
> flags on buses and filtering oneself on broadcasts. Those were all unused
> 
> and I haven't seen any code using them now. As there is no need for them,
> ...

 

http://lkml.iu.edu/hypermail/linux/kernel/1507.0/02970.html

I don't understand...  they didn't break the ABI and old code works but they lack support for them? Does not compute.

----------

## NeddySeagoon

gwr,

embrace, extend, extinguish ...  It's Red Hat following the Microsoft path.

----------

## khayyam

 *gwr wrote:*   

>  *Quote:*   Drop unused features. This includes KDBUS_MSG_MAX_ITEMS, required attach flags on buses and filtering oneself on broadcasts. Those were all unused and I haven't seen any code using them now. As there is no need for them, drop support for them. We do _not_ break ABI, so old code still works. But we lack support for those features now. If anything turns up, we might have to revert these.
> 
> But I really doubt that. 
> 
> I don't understand...  they didn't break the ABI and old code works but they lack support for them? Does not compute.

 

gwr ... you're not misunderstanding it properly. When it says "unused" it means "now" in the future, those "unused" features "lack support" (retroactively) ... they can't be supported "now" because they don't exist now. In the future any features lacking support "now" will be retrofuturised so that the ABI will not break anything "unused" in the past. See, simple.

best & chuckles ... khay

----------

## gwr

 *khayyam wrote:*   

> See, simple.

 

It seems easy when you put it like that.

----------

## John R. Graham

 *khayyam wrote:*   

>  *mrbassie wrote:*   Pardon my ignorance but what does 'nack' stand for (I'm assuming it's an acronym)? 
> 
> mrbassie ... I've always taken it to be derived from Negative-Acknowledge Character (so "a negative response"), but I'm not sure why exactly I made that assumption ... perhaps because many kernel components use NAK/NACK, i2c for instance.

 You obviously have a knack for explaining such things. :Wink: 

Sometimes in the most geeky of discussions, you'll see someone reply with 0x06 (hexadecimal for ACK in ASCII) or 0x15 (hexadecimal for NAK in ASCII) to indicate agreement or disagreement respectively, but this level of geekiness if mostly just annoying, akin to leetspeak.

- John

----------

## Naib

popcorn time.

An NSA employee has waded into the mess that is KDBUS

http://lkml.iu.edu/hypermail/linux/kernel/1507.1/01758.html

It appears KDBUS has the ability to fake credentials because a solution for all the userland DBUS applications had to be found  :Smile: 

----------

## gwr

 *Naib wrote:*   

> popcorn time.
> 
> An NSA employee has waded into the mess that is KDBUS
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1507.1/01758.html
> ...

 

Interesting how that thread just died. Does no one care?

----------

## saellaven

 *gwr wrote:*   

>  *Naib wrote:*   popcorn time.
> 
> An NSA employee has waded into the mess that is KDBUS
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1507.1/01758.html
> ...

 

Not sure where else they can go... to sum up:

A: kdbus can fake credentials

B: That's because it needs to in order to support dbus1 apps

A: But it's a security risk

B: Won't someone think of the applications?!!?! There are millions of legacy dbus1 apps that we need to support with kdbus

C: "But this is more like "userspace is broken, lets port it into the kernel and keep the brokenness while doing so thus setting the brokenness in stone" due to the first mantra." / "ok, we have some userspace functionality that we need to be compatible to it, but in order to do this, we need to do something in the kernel that is broken by design"

A: why don't you just use a socket for dbus1 compatibility?

D: But we'll break java and haskell since they depend on dbus1

E: "If kdbus is better (or even just cooler or more popular) the change over will be swift and painless. The *only* reason that won't be true is if the benefits of kdbus are unclear, in which case it shouldn't be adopted" / "There are so many ways uids are being (miss/ab)used on Linux systems these days that the idea of trusting a bus just because its non-root uid is listed in a table somewhere (or worse, coded in an API) is asking for exploits."

E: "There is absolutely no reason to expect that these two examples don't have native kdbus implementations in the works already. That's the risk you take when you eschew the "standard" libraries. Further, the primary reason that developers deviate from the norm is (you guessed it!) performance. The proxy is going to kill (or at least be assumed to kill) that advantage, putting even more pressure on these deviant applications to provide native kdbus versions."

B: Please tell me how it can be exploited since I don't know any better even though I'm trying to force this on everyone

B: All of this is built on the assumption that you can trust UIDs and I can't imagine why you'd want to talk to another UID's bus

A: If you assume this, you can't be sure that user space won't violate it in the future. The credential metadata is apparently superfluous... but I guess we'll have to allow the credential faking because dbus1

Basically, it comes down to the kdbus crowd not understanding security issues very well but wanting to move dbus1 support to kdbus to, again, continue the embrace/extend/extinguish mindset... and everyone just drops it despite the security concerns. Hey, anything for the cause, right? Why let potentially easily exploitable code get in the way?

----------

## ct85711

 *Quote:*   

> Interesting how that thread just died. Does no one care?

 

First off, you can't say the thread is necessarily dead yet, as it's historically shown that during weekends, the kdbus threads stall out and pick up during the regular work week.  (This trend has been seen numerous times in that all messages stop during weekend times and pick up during the work week).

Hate to say it, but this is a good example of a reason why I may be pushed away from linux if/when kdbus/sysd becomes manditory.

----------

## gwr

 *saellaven wrote:*   

> 
> 
> Basically, it comes down to the kdbus crowd not understanding security issues very well but wanting to move dbus1 support to kdbus to, again, continue the embrace/extend/extinguish mindset... and everyone just drops it despite the security concerns. Hey, anything for the cause, right? Why let potentially easily exploitable code get in the way?

 

This is putting (possible) financial consideration above security. That's mind-boggling to me, particularly because it's happening right out in the open.

----------

## saellaven

 *gwr wrote:*   

>  *saellaven wrote:*   
> 
> Basically, it comes down to the kdbus crowd not understanding security issues very well but wanting to move dbus1 support to kdbus to, again, continue the embrace/extend/extinguish mindset... and everyone just drops it despite the security concerns. Hey, anything for the cause, right? Why let potentially easily exploitable code get in the way? 
> 
> This is putting (possible) financial consideration above security. That's mind-boggling to me, particularly because it's happening right out in the open.

 

That's been RedHat's angle all along. It's all about creating a vendor lock-in, where they are the source of every key part of your system (by means of having virtually every systemd and related developer on their payroll) and, thus, you have to go to them for support... and through the process of getting other distros to join in for "ease of release maintenance," basically every systemd using distro will just become a clone of RedHat with the serial numbers filed off and a few tweaks made so they can claim they aren't.

Down the road, when the exploits start happening, the NSA, RedHat, etc will all claim that they had this discussion in public but that they all decided "nothing could be done about it" so they just had to hope for the best.

And therein lies more proof that of the lie that systemd is more secure, technologically better, etc. Early on, a good chunk of us here in the Gentoo forums started pointing out the flawed logic, arrogance, security concerns, etc of the one true program to rule us all and our concerns consistently get ignored. I'm sad to see a couple systemd sycophants just got re-elected to the Gentoo Council, where they've already used their influence to push systemd's shortcomings onto our distribution in an attempt to make openrc weaker to make systemd look better than it really is.

----------

## tld

 *saellaven wrote:*   

> And therein lies more proof that of the lie that systemd is more secure, technologically better, etc.

 The aspect of systemd that's boogled my mind more than anything is how anyone would ever want that bloated sack of desktop-centric crap, just sitting there begging for exploits, on a server OS like RHEL.  Mind boggling.  I've read several things were people argue that systemd was designed for servers and not desktops, and I find those arguments patently insane.  Redhat is clearly pushing systemd, kdbus etc for business reasons in spite of how horrific an idea it is for a server OS, and a lot of folks are covering that up with a bunch of spin.

----------

## ct85711

The fun question is, do we go ahead make a small program showing of the known (sysd devs already stated they knew of this exploit) credential-faking exploit in dbus?

----------

## saellaven

 *ct85711 wrote:*   

> The fun question is, do we go ahead make a small program showing of the known (sysd devs already stated they knew of this exploit) credential-faking exploit in dbus?

 

someone will... whether it's benign or not is another question. At the end of the day, your security model can't be based around "well, we just hope people won't do that." It's not like this is even a missed buffer overflow, it's insecure intentionally by design at this point. If they're going to go through the trouble of making a new interface, wouldn't it make sense to cut ties with a legacy interface that is known to be exploitable rather than to bake it in even deeper? Meanwhile, they are tying everything together using this totally insecure IPC mechanism, replacing a ton of well tested small applications to tie them together under the same roof, and releasing alpha software that isn't even feature stable as production code.

What could possibly go wrong?

----------

## depontius

 *saellaven wrote:*   

> 
> 
> What could possibly go wrong?

 

Well if something goes wrong, it's OBVIOUSLY the fault of that legacy Unix stuff, adn that means that we all need to double-down on systemd.  Get those Slackers and Gentooers to adopt the One True Way.  Fold more services and functions into systemd.  That's the way forward.  Really.  Trust me.

----------

## roki942

 *depontius wrote:*   

>  *saellaven wrote:*   
> 
> What could possibly go wrong? 
> 
> Well if something goes wrong, it's OBVIOUSLY the fault of that legacy Unix stuff, adn that means that we all need to double-down on systemd.  Get those Slackers and Gentooers to adopt the One True Way.  Fold more services and functions into systemd.  That's the way forward.  Really.  Trust me.

 

And Global Warming makes the swampland they're selling an outstanding investment for our grand kids!   :Laughing: 

----------

## Yamakuzure

 *Naib wrote:*   

> popcorn time.
> 
> An NSA employee has waded into the mess that is KDBUS
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1507.1/01758.html
> ...

 I'd like to read all those, but http://lkml.iu.edu/hypermail/ is emtpy. (and all links go 404)

----------

## Anon-E-moose

Links to hypermail have been messed up for a couple of days.

----------

## saellaven

you can read the thread here

http://thread.gmane.org/gmane.linux.kernel/1992832

----------

## steveL

I quite liked this one:

 *Hellwig wrote:*   

> This whole argument of we did something stupid in userspace long ago, and
> 
> now need to move it to kernelspace is not very helpful.

 

That's effectively a description of kdbus entire; trying to move into kernel some utterly shit ideas from userland, all the while pretending they weren't a pile of turd in the first place.

That it's still ongoing, gives the lie to "kernel developers are always focussed on the best technical result", as anyone with real experience and half a brain already knows it's a massive dud.

Doesn't bode well for the future of Linux without Torvalds, especially if Greg K-H is involved in any way, shape or form. (viz: more bulshytt from that purveyor of "quality" bulshytt.)

----------

## Anon-E-moose

 *steveL wrote:*   

> Doesn't bode well for the future of Linux without Torvalds, especially if Greg K-H is involved in any way, shape or form. (viz: more bulshytt from that purveyor of "quality" bulshytt.)

 

Indeed, the whole we can't change the inside of the code and leave the interface (API/ABi) alone is complete and utter BS.

And quite frankly their attitude and lies are reasons for not having (k)dbus in the kernel.

----------

## Naib

 *Anon-E-moose wrote:*   

> 
> 
> And quite frankly their attitude and lies are reasons for not having (k)dbus in the kernel.

 Its a reason to be suspicious and drive closer review, but as a reason not to include it... dangerous territory, bordering on discrimination and thus opening the door for a coup.

----------

## gwr

From here: http://article.gmane.org/gmane.linux.kernel/1993918

 *Quote:*   

> I wish we could, but we can't break programs that are currently running
> 
> today, that would be pretty mean.
> 
> thanks,
> ...

 

This is really cherry-picking an argument. As if it wouldn't be mean to consciously give them an insecure protocol. Or a second-rate one.

This "once crap, always crap" argument is bogus. Software migrates to new APIs every day. In fact, they expect hundreds of maintainers and developers to migrate to systemd every day.

----------

## mv

 *gwr wrote:*   

> Software migrates to new APIs every day.

 

Except for the kernel where it is a declared policy not to, and for a good reason. This is IMHO the main non-technical reason why kdbus has nothing lost in the kernel: The (almost explicitly stated) intention of the kdbus developers is to violate this kernel policy continuously in the future.

----------

## gwr

 *mv wrote:*   

>  *gwr wrote:*   Software migrates to new APIs every day. 
> 
> Except for the kernel where it is a declared policy not to, and for a good reason. This is IMHO the main non-technical reason why kdbus has nothing lost in the kernel: The (almost explicitly stated) intention of the kdbus developers is to violate this kernel policy continuously in the future.

 

You can make new APIs without changing old ones.

----------

## steveL

 *Anon-E-moose wrote:*   

> Indeed, the whole we can't change the inside of the code and leave the interface (API/ABi) alone is complete and utter BS.

 

I'm not quite following the grammar, only the sense there ;)

Those guys wouldn't know an ABI guarantee if it slapped them in the face, afaic.

 *Quote:*   

> And quite frankly their attitude and lies are reasons for not having (k)dbus in the kernel.

 

Agreed; anyone who thinks provenance is irrelevant, is essentially a nub imo, with no experience of the real-world.

Or we'd all still be stuck on Windows®, dreaming of a better way to use our computers.

 *grw wrote:*   

> [ Greg-KH]  is really cherry-picking an argument. As if it wouldn't be mean to consciously give them an insecure protocol. Or a second-rate one.

 

Indeed; though he sounds like an affable sort of guy, doesn't he, and who wants to be mean..

That kind of psychobabble is fine^W legal in an advertisement (making people feel socially pressured is practically de-rigeur) but fundamentally flawed when it comes to a technical discussion.

But then, this is a propaganda campaign, carried out over "new" media, aimed at establishing RedHat as equivalent to Microsoft when it comes to buying Linux; not a process aimed at getting the best results for users.

That's the last thing on any of the Poeterring cabal's minds afaic, or we wouldn't have been subjected to so many breakages for so little benefit (I'd count it as negative) over the last 5-7 years.

----------

## mv

 *gwr wrote:*   

> You can make new APIs without changing old ones

 

Yes, you can, but it means that you have to carry on the old API forever. I doesn't seem that this the intention of the kdbus developers (especially since, if I understood correctly, they desire to implement security issues in their first API attempts for compatibility with dbus1).

----------

## ulenrich

 *mv wrote:*   

>  *gwr wrote:*   You can make new APIs without changing old ones 
> 
> Yes, you can, but it means that you have to carry on the old API forever. I doesn't seem that this the intention of the kdbus developers (especially since, if I understood correctly, they desire to implement security issues in their first API attempts for compatibility with dbus1).

 

Yes, they carry the old api of dbus1 for compatibility. @mv, you criticized polkit use regarding dbus some months ago for exactly these flaws? Question for me as a new user of kdbus (thanks to Gentoo early adoption): Would kdbus respect any such an invocation of kdbus with a faked user from another user? @mv, can you tell a testing example?

----------

## mv

 *ulenrich wrote:*   

> @mv, you criticized polkit use regarding dbus some months ago for exactly these flaws?

 

No, I criticized polkit by its mere existence: The idea to have a complex daemon running to nihilate UNIX permissions is completely broken. Whether the attack finally succeeds over a dbus race or some other backdoor - such a complex thing with an embeeded interpreter will always have some - plays no role. It is impossible to fix such a fundamentally flawed concept.

----------

## miroR

There is a red marked sentence point in this forum thread, which is incomprehensible, at around:

(this same topic)

https://forums.gentoo.org/viewtopic-t-1004624-start-475.html#7769446

 *mv wrote:*   

>  *ulenrich wrote:*   your red marked sentence is insinuating a motivation 
> 
> Yeah, it was too aggressive. It is now removed.

 

While I agree that this might have been kind and humble to do by mv, can you guys now give some explanation to the reading public what that red marked sentence was about?

A big portion of that page is, now that line was removed, incomplete and incomprehensive talk, because the reading public can only be guessing what you people meant at that point, since that "red marked sentence" is mentioned in quite a few places.

EDIT: 2015-08-13 09:10+02:00

I only care for the general public to have easier reading, and not be driven away. It's also fine for me, it not being corrected, as you can see below, mv replied to this post. Just, it's better thinking about future readers when one deletes things. Thanks!

EDIT END

And you are suggested as:

 *Ignorant Guru's Blog wrote:*   

> a good read for catching up on the sensationalized push to put kdbus into the kernel

 

 and rightly so, it's really worth it, from places such as:

[IgnorantGuru's Blog]

kdbus: systemd’s Kid Cousin Come To Stay (No, Not PID 1, In Your Kernel, Silly)

[[ same address as in the quote ]]

https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/

(find the link under: "This Gentoo forum thread").

Can some of you correct that incomprehensiveness? (no, not for me, forget me, for the reading public; and no, not in the next post below, but where that red marked sentence is, on page 20, probably, or even 19 --lost the track myself)

Thank you in advance!Last edited by miroR on Thu Aug 13, 2015 7:13 am; edited 1 time in total

----------

## Perfect Gentleman

i've enabled kdbus in kernel. may i disable/uninstall dbus?

----------

## mv

 *miroR wrote:*   

> There is a red marked sentence point in this forum thread, which is incomprehensible

 

I removed the sentence for a reason. It contributed no new facts and does not help to understand something better. I do not want to repeat it.

----------

## tclover

 *Perfect Gentleman wrote:*   

> i've enabled kdbus in kernel. may i disable/uninstall dbus?

 

Do whatever you want with those crap bus and open new threads when appropriate for support (to avoid spamming and trolling here.) -- This is *not* a support thread in case you did not notice.

Thanks.

----------

## Naib

 *Perfect Gentleman wrote:*   

> i've enabled kdbus in kernel. may i disable/uninstall dbus?

 no, only systemd makes use of kdbus

----------

## ulenrich

 *Naib wrote:*   

>  *Perfect Gentleman wrote:*   i've enabled kdbus in kernel. may i disable/uninstall dbus? no, only systemd makes use of kdbus

  @Naib, you may well have a decisive opinion of things you don't know nothin' about. But don't contradict yourself: How should the only user systemd fake a wrong identity? Such would be a self-deception of systemD but not a security issue.

@mv, I am just thinking about the fake identity case, I get two in my mind:

1. user2user exploit:

UserB fakes identity of UserA and gets able to start something in the session of UserA.

2. system exploit case:

UserA has extended admin rights on a system. UserB has not but fakes UserA identity and is able to issue system commands. 

As this is about dbus1 compatibility of kdbus, is this exploitation possible using traditional dbus?

----------

## Naib

In what way was what I wrote wrong?

Right now systemd is the only thing geared up to make use of kdbus.  All those nice dbus applications cannot speak via kdbus

----------

## mv

 *ulenrich wrote:*   

> As this is about dbus1 compatibility of kdbus, is this exploitation possible using traditional dbus?

 

I do not spend time looking for exploits, but when I think about the huge list of races which I had collected in a few hours and posted somewhere in this forum some weeks/months ago (which were not only in systmed but in many other consumers of dbus) I would be surprised if such exploits were not possible. Simply, I do not want to spend all of my time looking for bugs and/or hoping that the developers find these always quicker than any hacker: If I wanted this, I could use windows as well. I prefer to have a system for which it is rather unlikely to contain any critical security vulnerability at all. With policykit, it is impossible to have such a system, with classical unix permissions it is not a big deal.

----------

## saellaven

 *mv wrote:*   

>  *ulenrich wrote:*   As this is about dbus1 compatibility of kdbus, is this exploitation possible using traditional dbus? 
> 
> I do not spend time looking for exploits, but when I think about the huge list of races which I had collected in a few hours and posted somewhere in this forum some weeks/months ago (which were not only in systmed but in many other consumers of dbus) I would be surprised if such exploits were not possible. Simply, I do not want to spend all of my time looking for bugs and/or hoping that the developers find these always quicker than any hacker: If I wanted this, I could use windows as well. I prefer to have a system for which it is rather unlikely to contain any critical security vulnerability at all. With policykit, it is impossible to have such a system, with classical unix permissions it is not a big deal.

 

What we're looking at is a design flaw in security.

It's like having a locked door with an open window next to it because your design specs say that there always has to be an open window next to the lock. You can redesign that lock all you want in an effort to improve it's security. You could even theoretically make the lock impossible to open and yet someone can still just enter through the window.

kdbus, being a completely new IPC method, could have removed the prior design flaw... but instead, they chose to keep it in. Anyone reviewing the code knows full well that it is a fundamental flaw in design, though apparently the kdbus devs weren't insightful enough to see that themselves. Rather than take the time to fix the design now before it becomes widely used, the solution is to just keep it there and hope nobody ever comes along and hops through the open window.

Much of the rest of the systemd/freedesktop.org stack is full of these types of things because it's amateur hour over there. They have an agenda and the agenda has nothing to do with security. The worst part, is they are all intentionally interconnected and linked into code executing in PID1, meaning that open window next to the lock could easily lead right inside your bank vault (because a vault has a lock too). Unfortunately, distro maintainers, in an effort to do as little work as possible, largely jumped on board, leaving us in the situation where these people will have domain over the majority of Linux boxes in the future. It's going to bring the same vulnerabilities that Microsoft brought, where again, security was always an afterthought, and you might as well just mark every kdbussystemd pwned going forward.

----------

## ulenrich

With kdbus in the kernel the big Linux companies will sell their customers a special feature: The  employees of the customers get a large window of privilege escalation. It is to show: Everyone can be the boss everywhere. 

I would like to see this feature in business  :Smile: 

But maybe there is just a fool on the hill looking down the valley ...Last edited by ulenrich on Sun Jul 26, 2015 10:37 pm; edited 1 time in total

----------

## ct85711

They will probably call this a race condition requiring polkit to monitor the kernel that's monitoring everything else (including polkit).

----------

## gwr

 *ct85711 wrote:*   

> They will probably call this a race condition requiring polkit to monitor the kernel that's monitoring everything else (including polkit).

 

Mexican standoff.

----------

## Naib

There seems to be a kdbus USE flag on the kernel now...

----------

## baaann

 *Naib wrote:*   

> There seems to be a kdbus USE flag on the kernel now...

 

Mike Pagano is following the Gentoo philosophy of offering choice and adds a disclaimer

 *Quote:*   

> NOTE: This is not some kind of Gentoo endorsement of kdbus.  Nor is it a Mike Pagano endorsement of kdbus

 

----------

## steveL

I thought Gentoo wasn't about choice any more, and Linux has never been about choice, or at least that's what I swore I read at least a few times on the developer ML.

Apparently it's about choice when Poeterring et al's work is up for inclusion, and thereafter it's not; or something.

Note: I'm fine with the option. I just wish the last sentence didn't describe so much of what I see happening.

----------

## Anon-E-moose

 *Yamakuzure wrote:*   

>  *Naib wrote:*   popcorn time.
> 
> An NSA employee has waded into the mess that is KDBUS
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1507.1/01758.html
> ...

 

They've been back up since the 1st of the month (some problem on their end)

Edit to add: It was working fine for the last few days, but it seems a little flaky today. *shrugs*

----------

## Anon-E-moose

From the "kdbus: to merge or not to merge?" thread on lkml. https://lkml.org/lkml/2015/8/10/693

 *Quote:*   

> Anyway, the real issue for me here is that Andy is reporting all these
> 
> actual real problems that happen in practice, and the developer
> 
> replies are dismissing them on totally irrelevant grounds ("this
> ...

 

And yet another person noticing that the (k)dbus devs are just dismissing any and all criticisms.

At this rate, Linus may just decide to have them on the same footing as BFS, which is NOT included in the kernel, but the patches are easy to apply.

----------

## tld

 *Anon-E-moose wrote:*   

> And yet another person noticing that the (k)dbus devs are just dismissing any and all criticisms.
> 
> At this rate, Linus may just decide to have them on the same footing as BFS, which is NOT included in the kernel, but the patches are easy to apply.

 

This actually raises a question I've been meaning to ask:

Since none of this BS has actually been merged into the kernel, what on earth does the new Gentoo kdbus USE flag even do??  Does it pull in patches from these jackasses?

If so, to Steve's point, even in the interest of "choice" in Gentoo, when on earth is a USE flag ever added that pulls in third party patches not even recognized by upstream?  I would just hope the sames hoops would be jumped through when it starts getting prohibitively difficult to avoid this crap.

Tom

----------

## saellaven

I think the more enlightening part of Linus post was what he opened with

 *Linus wrote:*   

> 
> 
> On Sun, Aug 9, 2015 at 3:11 PM, Daniel Mack <daniel@zonque.org> wrote:
> 
> >
> ...

 

David Lang had another key point too, which we've talked about to some degree here in regard to systemd as PID1 in several of the many technical threads we've had shut down over politics,

 *David Lang wrote:*   

> 
> 
> On Sun, 9 Aug 2015, Greg Kroah-Hartman wrote:
> 
> > The issue is with userspace clients opting in to receive all
> ...

 

So, once again, we see that the systemd/kdbus crew have absolutely no clue about security, system level programming, etc.

Now, mind you, the stated purpose of systemd is that "systemd talks to the kernel, everything else talks to systemd" and the way everything talks to systemd, is through kdbus... and not only is kdbus a massive mess full of exploits (some potential privilege escalation problems in addition to "minor" things like apps being able to DOS a system), but these people don't have enough experience to even acknowledge the problem when pointed out to them.

Worse, in an effort to try to push kdbus into the kernel, the latest versions of systemd are pushing it on users by default.

Even more crazy, systemd as PID1 is tied into everything else on the system, meaning you have a privileged program touching everything that is touching a bus that is full of holes too.

----------

## steveL

 *saellaven wrote:*   

> So, once again, we see that the systemd/kdbus crew have absolutely no clue about security, system level programming, etc.
> 
> Now, mind you, the stated purpose of systemd is that "systemd talks to the kernel, everything else talks to systemd" and the way everything talks to systemd, is through kdbus... and not only is kdbus a massive mess full of exploits (some potential privilege escalation problems in addition to "minor" things like apps being able to DOS a system), but these people don't have enough experience to even acknowledge the problem when pointed out to them.
> 
> Worse, in an effort to try to push kdbus into the kernel, the latest versions of systemd are pushing it on users by default.
> ...

 

Lindows is back ;-)

I found this part interesting, as we discussed the ballooning memory issue at the beginning of this thread (not in quotes as it gets messy, and it's my post):

--

The ballooning memory requirements were first raised here:  *David Lamparter wrote:*   

> This sounds like a terribly nice way to f*ck the entire D-Bus system by having one broken (or malicious) desktop application. What's the intended way of coping with users that block the socket by not reading?

  to which we get a pretty lame response:  *Javier Martinez Canillas wrote:*   

> this problem exists with current D-bus implementation. If a malicious desktop application doesn't read its socket then the messages sent to it will be buffered in the daemon:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=33606
> 
> dbus-daemon memory usage will balloon until max_incoming_bytes/max_outgoing_bytes limit is reached (1GB for session bus in default configuration)..
> ...

  Note this latter problem still applies when bringing kdbus into the kernel, and further that despite the excellent analysis on that bug, not one step has been taken to address the fundamental design flaw; the last comment from a known hal/udev/systemd developer with any content is from January 2011, and indicates serious miscomprehension issues, as he witters on about uid.

It's perfectly simple: stop pretending you can provide a square triangle.

--

However that is still baked into the whole undesign; if you take away that idiotic requirement, you can simply use TIPC, as they were advised to do in March 2012.

That seems like a much better idea.

In fact what they were told in 2012 still seems to be apposite:

 *David Miller wrote:*   

> I really don't want to apply this stuff: it looks bloated, complicated, and there is another avenue for doing what you want to do.
> 
> Applications have to change to support the new multicast facilities, so they can equally be changed to use a real transport that already supports multicasting.

 

----------

## krinn

 *tld wrote:*   

> 
> 
> Since none of this BS has actually been merged into the kernel, what on earth does the new Gentoo kdbus USE flag even do??  Does it pull in patches from these jackasses?
> 
> If so, to Steve's point, even in the interest of "choice" in Gentoo, when on earth is a USE flag ever added that pulls in third party patches not even recognized by upstream?  I would just hope the sames hoops would be jumped through when it starts getting prohibitively difficult to avoid this crap.

 

The real problem is not that it's not recognize by upstream, it is because upstream recognize this cannot be include (yet/as-is) for security reason.

I think that use flag is/should pull the patches.

It should just be kick out if we have a real QA team ; as this patch will not only gave more "choice", but security issue (and you don't even need to dig that yourself if you trust lklm devs).

But maybe that useflag is hardmask, no idea.

Do they add this useflag to vanilla kernel too?

----------

## asturm

You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources.

----------

## steveL

 *genstorm wrote:*   

> You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources.

 

Seems to me it would be better to have an explicit USE=kdbus flag, rather than lump it in with "experimental".

That would help both sides: people who want to avoid it, and people who want to depend on it.

----------

## davidm

 *steveL wrote:*   

>  *genstorm wrote:*   You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources. 
> 
> Seems to me it would be better to have an explicit USE=kdbus flag, rather than lump it in with "experimental".
> 
> That would help both sides: people who want to avoid it, and people who want to depend on it.

 

I'm probably going to give it a shot if it makes it to the stable kernel since I'm already using systemd but I was thinking about this as well and it seemed to me that we would probably have to introduce a kdbus use flag.  Otherwise wouldn't other programs try pulling in userspace dbus unnecessarily as a redundant dependency?  I guess you might also read the current kernel configuration but that would be even more messy.  I'm not a developer but was just wondering how it might all fit together in Gentoo and considered there might be issues.

On the politics of it all, I just appreciate Gentoo allowing for a CHOICE and though I use systemd I think upstream should also try to respect that by not trying to cram it down users' throats.  I sincerely hope they do not go that route.

----------

## roki942

 *steveL wrote:*   

>  *genstorm wrote:*   You should be aware that external patches are already pulled in by USE=experimental, and kdbus is only another addition. It's a security issue you choose yourself, if you want to test it. Only in gentoo-sources. 
> 
> Seems to me it would be better to have an explicit USE=kdbus flag, rather than lump it in with "experimental".
> 
> That would help both sides: people who want to avoid it, and people who want to depend on it.

 

 *Quote:*   

> Keeping with the theme of ‘Gentoo is about choice” I’ve added the ability for users to include kdbus into their gentoo-sources kernel.  I wanted an easy way for gentoo users to test the patchset while maintaining the default installation of not having it at all.
> 
> In order to include the patchset on your gentoo-sources you’ll need the following:
> 
> 1. A kernel version >= 4.1.0-r1
> ...

 http://www.mpagano.com/blog/?p=208

----------

## asturm

Guys, the kdbus use flag was mentioned right here in the thread. Does it hurt to do this

```
$ equery u gentoo-sources
```

before post?

----------

## Anon-E-moose

```
 * Found these USE flags for sys-kernel/gentoo-sources-4.0.5:

 U I

 - - build        : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first

                    half of bootstrapping [make stage1]

 - - deblob       : Remove binary blobs from kernel sources to provide libre license compliance.

 - - experimental : Apply experimental patches; for more information, see

                    "https://wiki.gentoo.org/wiki/Project:Kernel/Experimental".

 - - symlink      : Force kernel ebuilds to automatically update the /usr/src/linux symlink
```

```
 * Found these USE flags for sys-kernel/gentoo-sources-4.1.5:

 U I

 - - build        : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first

                    half of bootstrapping [make stage1]

 - - experimental : Apply experimental patches; for more information, see

                    "https://wiki.gentoo.org/wiki/Project:Kernel/Experimental".

 - - kdbus        : Apply the kdbus patch. This also requires the "experimental" use flag.

 - - symlink      : Force kernel ebuilds to automatically update the /usr/src/linux symlink
```

----------

## Anon-E-moose

 *saellaven wrote:*   

> I think the more enlightening part of Linus post was what he opened with
> 
> ...

 

The whole post was good, and I notice that not one response to it from any of the (k)dbus devs including GKH.

----------

## steveL

Cheers roki.

genstorm: No ofc not; does it hurt to explain yourself more fully instead of point-scoring? you have my sympathy.

----------

## asturm

This is a forum; I don't think I need to use more words when the context is right there above my post, as I was answering to krinn...

----------

## steveL

Yes, well I believe you..

----------

## NeddySeagoon

Moved the systemd absorbs sudo discussion to The Politics of systemd as its not kdbus related -yet.

----------

## asturm

 *steveL wrote:*   

> Yes, well I believe you..

 

So you disagree about context now?

----------

## ct85711

http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04789.html

 *David Herrmann wrote:*   

> It means kdbus messages carry information about the sender, which LSMs
> 
> might prevent you to read via /proc. Just like you can send dbus
> 
> messages to a peer, which LSM-enhanced dbus-daemon might not allow. If
> ...

 

I'm not too knowledgeable on the security setups, so someone may be able to correct my understanding. However, this is sounding like kdbus is specifically working to break the security policies that is put in place.

How I see it, if LSM or some other security policy blocks something, shouldn't that mean it shouldn't be bypassed?

----------

## depontius

 *ct85711 wrote:*   

> http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04789.html
> 
>  *David Herrmann wrote:*   It means kdbus messages carry information about the sender, which LSMs
> 
> might prevent you to read via /proc. Just like you can send dbus
> ...

 

But... but... but... it's systemd, so of course it's OK.

----------

## ulenrich

 *ct85711 wrote:*   

> http://lkml.iu.edu/hypermail/linux/kernel/1508.3/04789.html
> 
>  *David Herrmann wrote:*   It means kdbus messages carry information about the sender, which LSMs
> 
> might prevent you to read via /proc. Just like you can send dbus
> ...

  The answer is

 *Andy_Lutomirski wrote:*   

> > If
> 
> > you use LSMs, we clearly advise you to wait for kdbus to gain LSM
> 
> > support. We explicitly support legacy dbus1-compat for exactly such
> ...

  Which pretty much looks like the end of Kdbus in kernel implementing a dbus1-compat feature then. At least some more time to wait for mainline kdbus inclusion until "kdbus to gain LSM support" (David Herrmann announces future work to be done?). At this point the most sincere way of a workaround would be to configure the kernel exclusively "Kdbus OR LSM", which for sure will amuse everybody loughing out loud. Just having heard the Redhat goals talk to a Fedora audience (via youtube - I am not a member of that herd): One of their main objectives these days is hardening the kernel (mitigating security flaws they name it (*)). This a key business goal I cannot imagine Redhat will compromize on that.

(*)"mitigating security flaws" may or may not be kernel related though. But interestingly you can see discussion about gresecurity on the kernel mailing list.

----------

## steveL

Some context sheds light on just why this is so brain-dead at conception:

 *Andy Lutomirski wrote:*   

> I spotted this: 
> 
> ```
> +/**
> 
> ...

 

Note the inexcusable lack of transparency in adding a patch, which just happens to nullify existing kernel-security:

 *Andy Lutomirski  wrote:*   

> I haven't checked the context in which it's used, but in order for
> 
> kdbus_proc_permission to do what it claims to do, it appears to be
> 
> missing calls to security_inode_permission and
> ...

 

To which we get the lame response:

 *David Herriman wrote:*   

> Both are expected to be added by lsm patches (both hooks you mentioned
> 
>  are empty if no lsm is selected).

 

iow: by default we open a gaping attack vector, on every machine running kdbus.

Only if you specifically select an LSM, will there be even a remote chance of just the level of security we expect as minimum.

Note that would depend on your provider, and in today's scene, if you trust these "developers" you're a fool, afaic.

They've already shown stunning levels of incompetence, arrogance, and plain stupidity, as well as clearly trying to enforce vendor lock-in to RedHat, across the whole of binary Linux.

And if you don't happen to be using LSMs, what happens in this stunning new vision of a Brave New Lennux? You get screwed, only we lie to you and tell you we're "slightly more restrictive" than existing practice, again pretending to more competence than in-play.

Accept this into the kernel? Don't make me laugh; what needs to happen is a final big NACK to the whole idea, and further to the whole team involved, who clearly don't have the experience to design a sand-castle, let alone the "core of the Linux OS userland" (akin to the various BSDs' userlands, which are in reality made up of many, ecosystem-respecting components, from separate projects.)

----------

## steveL

 *ulenrich wrote:*   

> Just having heard the Redhat goals talk to a Fedora audience (via youtube - I am not a member of that herd)

 

Sounds an awful lot like you work for RedHat.

Feel free to follow up in "the politics of".

----------

## ulenrich

@steveL, if you'd know where I work, you would not believe my interest in Gentoo and Debian as a hobby.

/Me, having a very positive view on Redhat, I offered a bet: Redhat will not compromize on security.

 *steveL wrote:*   

> Sounds an awful lot like you work for RedHat.

  Sounds like an awful lot of people have worked for Redhad and got fired. Or they didn't get a job they desired ...

----------

## ct85711

 *Quote:*   

> Clarification: Fedora Rawhide only. The kdbus code is not included in
> 
> the F23 kernel.
> 
> Your point otherwise stands. I just don't want Phoronix or someone
> ...

 

http://lkml.iu.edu/hypermail/linux/kernel/1509.0/00414.html

It's interesting, that RH won't even use kdbus in Fedora.  They want to push it into the kernel, but yet they won't even use it in their products.

----------

## depontius

 *ct85711 wrote:*   

>  *Quote:*   Clarification: Fedora Rawhide only. The kdbus code is not included in
> 
> the F23 kernel.
> 
> Your point otherwise stands. I just don't want Phoronix or someone
> ...

 

Hmmmm.....  Years back people tried to interpret IBM's frequently-inconsistent actions, and had a really rough time of it.  There was another point of view that was much closer to reality - that IBM was not one big unified company.  There were many factions inside, each with its own agenda.

I suspect that the same could be said of just about ANY company, or at the very least any company not still under the sway of it's major charismatic founder / re-invigorator.  So I'm sure part of RedHat sees kdbus and systemd as a way to be the new Microsoft.  I'm equally sure another part of RedHat understands the security implications.

----------

## steveL

 *steveL wrote:*   

> Sounds an awful lot like you work for RedHat.

 

 *ulenrich wrote:*   

> Sounds like an awful lot of people have worked for Redhat and got fired. Or they didn't get a job they desired ...

 

Before I deal with your jibe, I must point out that it sounds even more like you work for RH now.

Precisely because you're trying to get a rise out of me; the insult is based on "insider" knowledge of how RH works.

As for your jibe, no: you're way off base. Never worked for them, never applied, never been interested.

Trying to be smart and avoid the question, all the while having a dig at me isn't working.

It just makes you look dishonest.

No wonder you have a "very positive view on Redhat".

As for me, I now think of you as a liar.

Good day.

----------

## GFCCAE6xF

Steve he didn't point at you specifically with the not working for Red Hat line, I think you may be taking all of this a little too seriously.

You seem to have accused him of being a what? Some paid RH employee using mysterious "insider" knowledge to troll these forums (or just you) all because... he admitted to watching a youtube video and thinking RH wont sabotage their own business with security problems? I mean come on, really?

His "jibe" seems perfectly fair. If his views make him a RH employee then going by the tone and hive-mind of these echo chamber threads it makes quite a lot of sense that a lot of people have been fired from RH or couldn't land the job.

----------

## augustin

Steve and all,

Once more, can we stop with all the bickering and name calling?

Can we stick to factual, technical information?

Our little problems, disagreements and disputes pale in comparison to this world's real problems, the humanitarian emergencies that are being ignored by all, the true misery and despair rampant in many countries, the dire environmental degradation that we have not yet started to take seriously (I think Earth Overshoot Day was August 15th, this month, so as of today, we have been overshooting this year's natural allowance for 3 weeks already).

So please, in the name of all that really matter, keep the discussion here civil, factual, informative, with care to elevate the signal/noise ratio.

Thanks.

----------

## steveL

 *GFCCAE6xF wrote:*   

> Steve he didn't point at you specifically with the not working for Red Hat line

 

This is nonsense; it was in direct response to a quote of mine.

Note he regularly chops out and ignores what I'm saying, so what he does leave in, to come back at with some specious line, is relevant.

As for the rest, I'm not taking it that seriously, nor do I care enough to get into it.

In this thread and others, ulenrich avoids straight questions, and deflects into personal attacks on me, instead of dealing with the issues head-on.

Y'all can keep making out he's a nice guy, but imo he's most assuredly not: he's simply a shill.

----------

## ulenrich

@steveL, in contrary to you as the emotional guy, I am not. I play with any emotionally put argument of yours:

 *steveL wrote:*   

> Sounds an awful lot like you work for RedHat.

   *ulenrich wrote:*   

> /Me, having a very positive view on Redhat, 

  But keeping some truth anyway (I very much dislike Fedora).

 *steveL wrote:*   

> Y'all can keep making out he's a nice guy, but imo he's most assuredly not:

 Holds true, assured by myself. Never pretended to be nice. 

 *steveL wrote:*   

> In this thread and others, ulenrich avoids straight questions, and deflects into personal attacks on me, instead of dealing with the issues head-on.

 My attack on you was weeks before, which you never acknowledged directly.

----------

## steveL

 *ulenrich wrote:*   

> @steveL, in contrary to you as the emotional guy, I am not. I play with any emotionally put argument of yours:
> 
>  *steveL wrote:*   Sounds an awful lot like you work for RedHat. 

 

How is that an emotive argument?

 *Quote:*   

>  *ulenrich wrote:*   /Me, having a very positive view on Redhat,   But keeping some truth anyway (I very much dislike Fedora).

 

Jeez, you're doing it again; quoting yourself, with words you didn't say, and here you go again trying to play cool and not really a RedHat stooge, with your putdown of Fedora.

 *steveL wrote:*   

> Y'all can keep making out he's a nice guy, but imo he's most assuredly not:

 

 *Quote:*   

> Holds true, assured by myself. Never pretended to be nice. 

 

Yes you did; you've pm'ed me twice declaiming what a nice guy you are really, and how your weird and wacky arguments that no-one else understands, aren't understood by you either; they're just attempts at surreal comedy to take the heat out of flamewars.

My position is that they're nothing of the sort; they have an overwhelming tendency to name-drop and make out like we all need to sign up to the RedHat corporate programme.

AFAIC you're basically a cheerleader for RedHat and systemdbust, going solely from the content of your posts.

Funnily enough I don't recall seeing you post in any other threads, either before or since this whole systemdiot "gentle Putsch" started.

I'm sure you have ofc; it just seems odd that you've never been around much, but are suddenly such a stridently vocal supporter of the vendor lock-in agenda.

 *Quote:*   

> My attack on you was weeks before, which you never acknowledged directly.

 

Nonsense; you dived back into a thread that had died weeks before, simply to accuse me with more insane ramblings.

----------

## gwr

Looks like kdbus was merged into kernel-next. I guess time will tell if it makes it into 4.4.

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=951919803d261b05a8fb97678cb09a24fa1ba47a

----------

## Anon-E-moose

 *gwr wrote:*   

> Looks like kdbus was merged into kernel-next. I guess time will tell if it makes it into 4.4.
> 
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=951919803d261b05a8fb97678cb09a24fa1ba47a

 

It's been in kernel-next a few times now, and no closer to being in the kernel.

I believe, that until the issues brought up by Andy L, and others get addressed, instead of being ignored there won't be an acceptance into the kernel.

kernel-next is just a holding spot for the next kernel, but just because something is there it doesn't mean it will get merged.

As you say time will tell.

----------

## gwr

 *Anon-E-moose wrote:*   

> 
> 
> It's been in kernel-next a few times now, and no closer to being in the kernel.

 

Whoops, I didn't notice that before. I figured once it was merged into kernel-next it was a done deal.

----------

## depontius

 *gwr wrote:*   

>  *Anon-E-moose wrote:*   
> 
> It's been in kernel-next a few times now, and no closer to being in the kernel. 
> 
> Whoops, I didn't notice that before. I figured once it was merged into kernel-next it was a done deal.

 

I wonder if anyone is going to try to engineer a "bookkeeping accident" that just happens to get kdbus into the kernel.  Has anything ever gotten into the kernel by such an accident, before?

----------

## Anon-E-moose

My understanding of kernel-next is that it is a repository of code for Linus to pick and choose what goes into the next kernel release.

In other words lots of potential changes to the kernel, but I don't think that something would accidently get into the kernel.

----------

## Naib

Here we go again

http://lkml.iu.edu/hypermail/linux/kernel/1510.1/00292.html

----------

## ulenrich

 *Naib wrote:*   

> Here we go again
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1510.1/00292.html

  Pretty boring for me just watching this teaching. 

As we all know kdbus has no chance of inclusion if not hooked with lsm. Now there are people exactly trying that:

http://www.spinics.net/lists/selinux/msg17808.html

Where you can find in the follow up "Organization: National Security Agency"

----------

## depontius

 *ulenrich wrote:*   

>  *Naib wrote:*   Here we go again
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1510.1/00292.html  Pretty boring for me just watching this teaching. 
> 
> As we all know kdbus has no chance of inclusion if not hooked with lsm. Now there are people exactly trying that:
> ...

 

Does this effectively mean that one must run selinux in order to hope for a secure system?

----------

## gwr

 *depontius wrote:*   

> 
> 
> Does this effectively mean that one must run selinux in order to hope for a secure system?

 

I don't think they have come out and said so directly, but the implications of what I am seeing is that yes, they expexct to spin it that selinux is required for security because of backwards compatibility reasons.

----------

## gwr

 *ulenrich wrote:*   

> 
> 
> Where you can find in the follow up "Organization: National Security Agency"
> 
> 

 

Wow, I thought you were kidding at first.

----------

## khayyam

 *depontius wrote:*   

> Does this effectively mean that one must run selinux in order to hope for a secure system?

 

depontius ...  "one", hehe, its all about you and your needs isn't it? ;) ... it's "not a product for 'end-users'", so kindly shudup, and "send patches" ;)

best ... khay (the NSA shill)

----------

## ulenrich

 *depontius wrote:*   

> Does this effectively mean that one must run selinux in order to hope for a secure system?

  You probably wanted to ask this regarding systemd. That is another thread.

kdbus without any lsm compatibility: Despite you enabled an additional Linux security module there would be a path around with kdbus. In current state kdbus disables any of that effectively  :Sad: 

----------

## krinn

http://www.spinics.net/lists/selinux/msg17810.html

 *Quote:*   

> The effective uid/gid is used as it was used
> 
> in all areas of the previous kdbus code except for areas where the
> 
> uid/gid was never set beyond the basic initialization to zero/root;
> ...

 

When i see that i have two things coming to my mind:

1- while he review kdbus with lsm he found a bug ; showing how good the code was review, and how so true kernel devs are when they ask them to review that shit ; really.

2- the "i expect this was a bug" is also kinda telling ; well, it doesn't look that good, i think it might be a bug, but no, i'm not sure... Why? Because i don't know what this is doing, but hell yes, i have no problem to change a code that i have no idea what it is doing and why it was done like that  :Very Happy: 

And this is what they call "security"???

----------

## depontius

 *krinn wrote:*   

> 
> 
> And this is what they call "security"???

 

But it's the systemd people doing it, so it must be ok, or at least forgiveable.  It's good enough for US politics, so it must be good enough for Linux.

----------

## khayyam

I guess this short blog post by Rob Landley on sysfs, kdbus, and kernel devdelopment, belongs here.

best ... khay

----------

## Anon-E-moose

 *khayyam wrote:*   

> I guess this short blog post by Rob Landley on sysfs, kdbus, and kernel devdelopment, belongs here.
> 
> best ... khay

 

GKH will bite Linus in the ass one day. 

Just because he's been there for a while doesn't mean he's really trustworthy.

By his actions I would say that he has proven that he can't be trusted.

And Kay has always been a complete and utter clueless moron, thus the reason Linus banned him from kernel development/patching

at least in the development kernel (latest and greatest).

Edit to add: The above are my views/opinions. Take them as you will.

----------

## gwr

 *Anon-E-moose wrote:*   

>  *khayyam wrote:*   I guess this short blog post by Rob Landley on sysfs, kdbus, and kernel devdelopment, belongs here.
> 
> best ... khay 
> 
> GKH will bite Linus in the ass one day. 
> ...

 

That was a disappointing read. It seems difficult to believe that Linus wouldn't notice that kind of thing going on.

----------

## Naib

 *gwr wrote:*   

>  *Anon-E-moose wrote:*    *khayyam wrote:*   I guess this short blog post by Rob Landley on sysfs, kdbus, and kernel devdelopment, belongs here.
> 
> best ... khay 
> 
> GKH will bite Linus in the ass one day. 
> ...

 

He probably does but it is a very silly political game. Not getting dragged into it and sticking purely to technical aspects of the kernel (and being very OBJECTIVE w.r.t. patching, ie not blocking kdbus outright) allows him to fully observe and not antagonise any potential coup

----------

## krinn

The reality is that, if Linus die, we're in deep shit.

----------

## Anon-E-moose

 *krinn wrote:*   

> The reality is that, if Linus die, we're in deep shit.

 

The kernel will more than likely fork. 

It'll be RH and the devs they own vs all the others.

----------

## Naib

Lmao

https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html

Kdbus is being pulled from fedora/rh... That nice attempt of a coup by systems to bypass the process showed quite clearly in practice the flaws

----------

## ct85711

Now, hopefully the devs will scrap kdbus as a whole and throw it away....

It's been said, that most of the reason to make kdbus is because of dbus inefficiencies.  Maybe they'll figure it out and remake dbus and be done with everything...

----------

## davidm

 *Naib wrote:*   

> Lmao
> 
> https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html
> 
> Kdbus is being pulled from fedora/rh... That nice attempt of a coup by systems to bypass the process showed quite clearly in practice the flaws

 

I'm using systemd on Gentoo myself but OUCH.  I do think they need to slow down, focus more on quality and be far less pushy.  Make people want to switch by killing them with the features and the stability and not by forcing them to do so with underhanded tricks and power plays.

----------

## Anon-E-moose

From the Naib link:

 *Quote:*   

> The upstream developers asked me to remove the module from Fedora while they rethink some of the approach they are taking with kdbus.

 

Maybe the NAKS from the kernel devs, everytime they have asked for it to be included in the kernel, is starting to sink in.

Either that or they have found out that the "vast gains" of using kdbus aren't that vast after all.

----------

## Naib

what's just as interesting was Fedora failed a few internal reviews and F23 wasn't going to be released. Today... it now passes and F23 is being released. 

related or co-incidental?

----------

## depontius

 *Anon-E-moose wrote:*   

> Either that or they have found out that the "vast gains" of using kdbus aren't that vast after all.

 

The gains may be measured in lock-in, not performance.  The latter may be minor compared to the former.

The real question here is how fast after kdbus goes into the kernel, presuming it does, will someone (GKH?) call for removal of netlink as a method of reporting udev events?  You know, the lock-in of systemd as the one true whatchamacallit.  (I use that term because it's fearfully more than an init system.)

----------

## khayyam

 *davidm wrote:*   

> I'm using systemd on Gentoo myself but OUCH.  I do think they need to slow down, focus more on quality and be far less pushy.  Make people want to switch by killing them with the features and the stability and not by forcing them to do so with underhanded tricks and power plays.

 

davidm ... but those are the "features" ... 

"systemd is poorly designed? Its claims, wrt the "brokeness" of the function systemd intended to replace, or its own "features", are spurious? No, it has innovative underhanded tricks and power plays ... haytre".

The problem with systemd is that its now like the boy who cried wolf, no one should give it, or its adherents, any credence.

best ... khay

----------

## roki942

Can I be the first to say it? 

"LP this is your wake up call!"

edit:

Oops, my bad .... that sounds personal, but I never met the guy.

Should have been: "Systemd this is your wake up call!"Last edited by roki942 on Fri Oct 30, 2015 9:33 pm; edited 1 time in total

----------

## GFCCAE6xF

 *Naib wrote:*   

> what's just as interesting was Fedora failed a few internal reviews and F23 wasn't going to be released. Today... it now passes and F23 is being released. 
> 
> related or co-incidental?

 

Leave it for the reader to research  :Smile: 

http://pkgs.fedoraproject.org/cgit/kernel.git/

----------

## steveL

 *GFCCAE6xF wrote:*   

> http://pkgs.fedoraproject.org/cgit/kernel.git/

 

Lol: 

```
Drop kdbus     Lines -52081/+3
```

The whole of the "UNIX Operating System Source Code Level Six", as presented in Lions[1], is 9073 lines.

[1] Lions' Commentary on UNIX 6th Edition with Source Code (John Lions, 1977, published: 1996 Peer-to-Peer.)

Sure, it's a "specially-edited selection" but the point stands. According to ESR in the foreword, it's the "entire source of the UNIX Version 6 kernel."

----------

## gwr

 *steveL wrote:*   

>  *GFCCAE6xF wrote:*   http://pkgs.fedoraproject.org/cgit/kernel.git/ 
> 
> Lol: 
> 
> ```
> ...

 

The vast majority of lines of code appears to be the endlessly verbose XML documention that is needlessly intermixed with the source code.

----------

## steveL

 *gwr wrote:*   

> The vast majority of lines of code appears to be the endlessly verbose XML documentation that is needlessly intermixed with the source code.

 *shudder* ;)

----------

## NeddySeagoon

There has to be a halloween reference to kdbus there somewhere but I can't spot it.

----------

## Naib

 *NeddySeagoon wrote:*   

> There has to be a halloween reference to kdbus there somewhere but I can't spot it.

 the dead will rise again?

----------

## depontius

 *Naib wrote:*   

>  *NeddySeagoon wrote:*   There has to be a halloween reference to kdbus there somewhere but I can't spot it. the dead will rise again?

 

Oh, come on!  It's obvious... "Trick or Treat!"  (with a higher probability of the former, most here would say)

----------

## khayyam

 *depontius wrote:*   

>  *Naib wrote:*    *NeddySeagoon wrote:*   There has to be a halloween reference to kdbus there somewhere but I can't spot it. the dead will rise again? 
> 
> Oh, come on!  It's obvious... "Trick or Treat!"  (with a higher probability of the former, most here would say)

 

no, no, "all your base are belong to us" ... as the new improved halloween is 365 days a year.

best ... khay

----------

## steveL

Enough with the quote trees already: flatten 'em out, people! ;x

 *NeddySeagoon wrote:*   

> There has to be a halloween reference to kdbus there somewhere but I can't spot it.

 

 *Naib wrote:*   

> the dead will rise again?

 

 *depontius wrote:*   

> Oh, come on!  It's obvious... "Trick or Treat!"  (with a higher probability of the former, most here would say)

 

"Trick or Trick" ;)  (story)

 *khayyam wrote:*   

> no, no, "all your base are belong to us" ... as the new improved halloween is 365 days a year.

 

Heh: "All your Data are belong to US" seems apposite.

Though "All your data belong to us" is a different matter, relating to the freedom of information implicit in the "digital age", and the rights of everyone to knowledge, since all knowledge we have comes from our society.

That's why the sociopathic fantasy of the "Nietschzian Superman" is so useless; as if no-one ever had to change his dirty nappy.. ;-)

----------

## gwr

Article: kdbus not dead - from the systemd conference

http://www.golem.de/news/systemd-konferenz-kdbus-ist-nicht-tot-1511-117313.html

From Google Translate:

 *Quote:*   

> 
> 
> The systemd maintainer Lennart Poettering reaffirmed a developer conference that kdbus will continue hand and "not dead". The implementation in the kernel and userspace will however rebuilt. How long that will take, is not yet clear.
> 
> For more than two years working Linux hackers and the systemd team with kdbus on implementing an interprocess communication (IPC) at the kernel level, which is a kind of replica of the previous D-Bus functionality. Systemd-founder Lennart Poettering has "not exactly a success story," described the development of this technology at the Conference as systemd, which is primarily due to the criticism from the kernel community well. But Poettering said just as clearly: "kdbus is not dead".
> ...

 

----------

## Anon-E-moose

 *gwr wrote:*   

> Article: kdbus not dead - from the systemd conference
> 
> http://www.golem.de/news/systemd-konferenz-kdbus-ist-nicht-tot-1511-117313.html

 

Even if it never gets included in the kernel (like bfs, bfq and reiser4 to name a few) it doesn't mean it's dead.

They can carry the patches to the kernel and all the distros can apply it along with many others that they apply anyway.

I'm only really concerned that kdbus doesn't make it into the kernel with the (crappy) code that they've had in the past.

I'm sure there will be lots of commentary on lkml over it when the rewrite gets released.

----------

## gwr

 *Anon-E-moose wrote:*   

>  lots of commentary on lkml over it when the rewrite gets released.

 

I find it interesting that they wish to re-architect it, given that they just finished trying to push it into the kernel and fought bitterly that it was ready.

----------

## steveL

 *Quote:*   

> The presence of the IPC in the kernel is necessary, for example to already be able to communicate early in the boot process it. The need to use tools like NetworkD. But despite these repeated statements on the clear need for kdbus

 

Nah, these statements are simply bullshit, that's why no-one's playing with your square ball..

IPC is necessary in the kernel, sure, but that's why we have at least 5 variants of it already.

 *Quote:*   

> Actually, however, this is only a strategic "step back".

 

Well, how about a "strategic" decision: NO. You do not know what you are doing, and everything you are trying to do is better done using existing facilities, while forgetting about some of the idiot design "constraints" inflicted by your wilful ignorance and lack of basic research, plus a large dose of intransigence (ie: pig-headed behaviour.)

Poettering, Sievers and Kroah-Hartman are simply not qualified to architect such solutions, and the pain they have inflicted on admins and users over the last 7 or 8 years must stop.

Go away. Perhaps move into management, with the rest of the bulshytters, and let the Peter principle continue.

 *Quote:*   

> In an interview with Golem.de confirmed Poettering that will be discussed with the renovation work on some of the criticism from the kernel community. The work could lead to a more generic IPC. Presumably, the technology has thus also a greater chance of being taken up in the medium term but still in the Linux kernel.

 

It's called TIPC, and it's already in the kernel, and has been available for Linux for 15 years. It also happens to be multi-platform.

"Catch-up with the modern-world, numpty; we sorted this stuff out in the 1990s, while you guys were gawking at your first view of a WIMP display (done badly.)"

 ~ Unix-greybeard.

----------

## gwr

 *steveL wrote:*   

> 
> 
> It's called TIPC, and it's already in the kernel, and has been available for Linux for 15 years. It also happens to be multi-platform.
> 
> 

 

I can't give conference talks and impress my fans with old technology.

----------

## krinn

 *steveL wrote:*   

> It's called TIPC

 

From the features list on the wikipedia link, i see it really lack the feature

- Made by Pottering.

As such, i don't think they would use it, as this missing is a huge stopper.

----------

## steveL

 *steveL wrote:*   

> It's called TIPC, and it's already in the kernel, and has been available for Linux for 15 years. It also happens to be multi-platform.

 

 *gwr wrote:*   

> I can't give conference talks and impress my fans with old technology.

 

Lul.. the saps could just run dcop over TIPC, and it would all be about the uses they put the technology to: that would get them loads of new conference material, about how efficient they were being, on the one hand, and about how the desktop apps were run over domain-specific, tuned mechanisms, rather than clumped through one badly-designed bottleneck ("now in 60 moving parts!")

They could even use capnrpc, and compare against a forked X, running under the logged-in user's uid, since it has an inter-desktop app-protocol already (or used to.)

There's plenty of fun stuff to be done (or brought-back), for people who actually have the time and inclination to work on it.

Just follow the advice of the kernel network hackers, and focus on the fun part in userland, instead of trying to hijack Linux.

Do this by understanding all the options available, from POSIX first, so that your apps run on other systems too, and select the ones which are most suited, rather than just what some nub told you to use, for those rare, but important, parts where you're not using a library.

 *krinn wrote:*   

> From the features list on the wikipedia link, i see it really lack the feature
> 
> - Made by Pottering.
> 
> As such, i don't think they would use it, as this missing is a huge stopper.

 

Hah; well you called it:  *krinn wrote:*   

> does anyone think we're close to have a new challenger for the "software fiasco of the year" with kdbus?
> 
> What will be interesting is what redhat will do, sure they can have a patch kernel for themselves, calling it a fork or not, but it's personal use. Now if systemd depend on that patch (so systemd need a kernel with kdbus patch), that would force anyone to use a kernel with the patch (so a non vanilla kernel anymore), and write in stone redhat has fork the kernel. 
> 
> And how distro will look at this: getting deeper redhat dependent or finally back to sanity and dropping systemd and all the shit.

 

and here we are, 5 months later:  *Naib wrote:*   

> Lmao
> 
> https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html
> 
> Kdbus is being pulled from fedora/rh... That nice attempt of a coup by systemd to bypass the process showed quite clearly in practice the flaws

 

Hopefully, the Linux kernel bods will reconsider the lazy-thinking that says "let's hand over all control of cgroups to systemd" as well.

(discussed here and further below.)

----------

## krinn

 *steveL wrote:*   

> Hah; well you called it:  *krinn wrote:*   does anyone think we're close to have a new challenger for the "software fiasco of the year" with kdbus? 

 

By that time, i didn't want to push my seer capacity as most unbelievers are always shocked when i do ; i think now everyone can just admit it: krinn is a seer!

My only regret, is that it looks like Redhat may not be pushing systemd (like i suppose earlier).

But i'm just a seer, never said i was God (i could, but i will wait until everyone admit my seer status first).

----------

## steveL

 *steveL wrote:*   

> Hah; well you called it:  *krinn wrote:*   does anyone think we're close to have a new challenger for the "software fiasco of the year" with kdbus? 

 

 *krinn wrote:*   

> At that time, i didn't want to push my seer capacity as most unbelievers are always shocked when i do ; i think now everyone can just admit it: krinn is a seer!
> 
> My only regret, is that it looks like Redhat may not be pushing systemd (like i suppose earlier).
> 
> But i'm just a seer, never said i was God (i could, but i will wait until everyone admit my seer status first).

 

LOL; yes, we admit it.

All hail the Great Krinn, of the Church of Krinn the Divine!

We're not worthy. ;-)

----------

## NeddySeagoon

krinn,

Maybe we shall see he headline ... seer wins lottery!

----------

## gwr

"Official" announcement on LKML of redesign and resubmission "when it's ready".

http://lkml.iu.edu/hypermail/linux/kernel/1511.1/00247.html

----------

## Anon-E-moose

 *gwr wrote:*   

> "Official" announcement on LKML of redesign and resubmission "when it's ready".
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1511.1/00247.html

 

Wow, what a S. Storm over asking for a simple "what's going on" 

And how arrogant and rude the (k)dbus/sysd people are.

And what a huge hypocrite GKH is.

They all need to be bitch slapped back to reality.

Edit to add: From one of the emails by Andy L.

 *Quote:*   

> As a developer, I'm willing to ask for feedback on ideas and to ask
> 
> for feedback on code. In many cases, I've gotten (correct!) feedback
> 
> telling me that my design is wrong or needs major changes. I *always*
> ...

 

I guess since Linus said a while back that he trusted (without qualifying about what) GKH 

that GKH thinks he has elevated privileges or status somehow.   :Rolling Eyes: 

----------

## Naib

That thread is golden

----------

## gwr

 *Anon-E-moose wrote:*   

> 
> 
> And how arrogant and rude the (k)dbus/sysd people are.
> 
> And what a huge hypocrite GKH is.
> ...

 

Unbelievable how he trots out the idea that no one is asked up-front design questions and in the immediate reply somone not only quotes the kernel development process, but also state that he himself has asked for just such up-front clarification.

You'd think that if you _failed_ to develop something acceptable for the linux kernel that you'd be more than happy to include them up front on the second go-round.

----------

## Naib

the denial and defense at Phoronix is beautiful

http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/833825-kdbus-is-indeed-going-back-to-the-drawing-board#post833825

----------

## gwr

 *Naib wrote:*   

> the denial and defense at Phoronix is beautiful
> 
> http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/833825-kdbus-is-indeed-going-back-to-the-drawing-board#post833825

 

I find it interesting how people think that its either wise or proper (or both) to develop a kernel component without involving kernel devs from the beginning. 

Okay, sure you _can_ do it, but why would you? Why would you not draw upon all the expertise available?

Let's say for the sake of argument that the people who have to approve your stuff are completely wrong about their approach. You still have to work with them to get it approved. I don't get the "here, this code descends from upon high" approach.

----------

## digi_owl

 *Anon-E-moose wrote:*   

>  *gwr wrote:*   "Official" announcement on LKML of redesign and resubmission "when it's ready".
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1511.1/00247.html 
> 
> Wow, what a S. Storm over asking for a simple "what's going on" 
> ...

 

Starting to think that GKH has mastered the art of passive-aggressiveness.

Especially in light of what Landley wrote about recently in regards to getting mdev working, and having to deal with GKH and Sievers.

http://www.landley.net/notes-2015.html#05-07-2015

And as i write that i glance once more at the Landley blog, and notice the crap being pulled about stable vs unstable. Where else have we seen that? Oh yeah, systemd. WTF is going on in the Linux world these days?! Is it yet another case of running out of external enemies and so we turn on each other?

----------

## khayyam

 *digi_owl wrote:*   

> Starting to think that GKH has mastered the art of passive-aggressiveness. Especially in light of what Landley wrote about recently in regards to getting mdev working, and having to deal with GKH and Sievers.

 

digi_owl ... that was already posted earlier in this thread and in the politics of systemd thread. Its worth following the various links to the LKML and LWN posts/discussion.

As for "WTF is going on", well, there's money involved, I wouldn't be surprised if GKH's deal with RH includes renumeration reflected by share value (or, some such). 

best ... khay

----------

## krinn

 *khayyam wrote:*   

> As for "WTF is going on", well, there's money involved, I wouldn't be surprised if GKH's deal with RH includes renumeration reflected by share value (or, some such). 

 

Never underestimate what ego or need for fame can let people do too.

Hookers have money goal, that's a valid goal if you have none ; but the facebook generation is fucking in pool on public tv just to read their names in some trash magazine...

----------

## digi_owl

 *khayyam wrote:*   

>  *digi_owl wrote:*   Starting to think that GKH has mastered the art of passive-aggressiveness. Especially in light of what Landley wrote about recently in regards to getting mdev working, and having to deal with GKH and Sievers. 
> 
> digi_owl ... that was already posted earlier in this thread and in the politics of systemd thread. Its worth following the various links to the LKML and LWN posts/discussion.
> 
> 

 

Knew that, was too lazy to dig up the relevant post and quote it. Feel free to sue me.

----------

## khayyam

 *digi_owl wrote:*   

>  *khayyam wrote:*    ... that was already posted earlier in this thread and in the politics of systemd thread. Its worth following the various links to the LKML and LWN posts/discussion. 
> 
> Knew that, was too lazy to dig up the relevant post and quote it. Feel free to sue me.

 

digi_owl ... I point it out, and provide links, as not everyone reads the entire thread, and if a subject has been brought up, or discussed, then it serves no purpose to repeat such discussion ... pointing it out prevents things becoming repetitive, which is something long threads like this are prone to. So, sue yourself.

best ... khay

----------

## Anon-E-moose

 *khayyam wrote:*   

> As for "WTF is going on", well, there's money involved, I wouldn't be surprised if GKH's deal with RH includes renumeration reflected by share value (or, some such). 

 

I've long maintained that GKH was getting something for his efforts in getting kdbus into the kernel.

He even violates his own advice about how things are done in the kernel when it comes to this issue.

So there's definitely some form of pay, whether stock options, a "job" directly with RH, or something else.

----------

## steveL

 *Anon-E-moose wrote:*   

> And how arrogant and rude the (k)dbus/sysd people are.
> 
> And what a huge hypocrite GKH is.
> 
> They all need to be bitch slapped back to reality.

 

++

 *gwr wrote:*   

> Unbelievable how he trots out the idea that no one is asked up-front design questions and in the immediate reply someone not only 
> 
> quotes the kernel development process, but also state that he himself has asked for just such up-front clarification.

 

Indeed.

 *Quote:*   

> You'd think that if you _failed_ to develop something acceptable for the linux kernel that you'd be more than happy to include them up front on the second go-round.

 

Yeah Herriman's replies are pathetic, as Zjilstra points out.

And ofc his reply to that, is even worse. The chutzpah is amazing.

He says "No," in the same idiotic way he says "Correct," instead of addressing the substantive: of how he's going to plug whatever gaping security-hole had been pointed out.

So, Anon is absolutely correct in his summation, imo; just a shame that Torvalds feels unable to deliver the type of final "No, you numpty" he would normally, due to his perfectly respectable sense of loyalty to Kroah-Hartmann.

Apparatchiks, and sociopaths, always use your decency against you, ime. Losing your decency, is ofc the worst thing you can do.

You're supposed to recuse yourself, instead, if you feel conflicted (which is where the BDFL model falls down: no-one else feels like it's their place to deliver a resounding "verbal" warning, so "friends" can take advantage, and often will if they see personal gain in it.)

As ever, it's the non-technical things which trip the geeks up, as they all the while delude themselves, that being apolitical puts them above the crowd, rather than at their meagre mercy.

----------

## steveL

 *khayyam wrote:*   

> As for "WTF is going on", well, there's money involved, I wouldn't be surprised if GKH's deal with RH includes renumeration reflected by share value (or, some such). 

 

 *krinn wrote:*   

> Never underestimate what ego or need for fame can let people do too.
> 
> Hookers have money goal, that's a valid goal if you have none; but the facebook generation is fucking in pool on public tv just to read their names in some trash magazine...

 

LOL: that is classic.

Though I think it explains the fanbois, more than the people who have stock options (possibly vested) in RedHat, given to kernel hackers at the time of their IPO.

Definitely one to draw your kids' attention to, though might want to remove/edit the first bit. ;-)

----------

## gwr

 *steveL wrote:*   

> The chutzpah is amazing.

 

And here's the disheartening thing about it all: Sarah Sharp gets wide-spread press for being criticized by Linus based on his mannerisms, regardless of how correct he is, however few in the media surrounding the industry so much as bats an eye when something technically outrageous is written using the single word "No".

There are lots of little unsolved commentaries on programming in the computing world that we can argue about for hours. Just recently Linus complained voiciferously about the readability of GCC overflow checking.

What surprises me is that he has been all but silent on the entire subject of kdbus from a technical perspective. Is it just easier to argue about syntax? Does he not see anything until he has to merge it?

----------

## steveL

 *steveL wrote:*   

> The chutzpah is amazing.

 

 *gwr wrote:*   

> And here's the disheartening thing about it all: Sarah Sharp gets wide-spread press for being criticized by Linus based on his mannerisms, regardless of how correct he is, however few in the media surrounding the industry so much as bats an eye when something technically outrageous is written using the single word "No".

 

Heh, good point (or the word "Correct";)

It's a funny one, because on one hand, I do not recognise Torvalds' twisting of the term "professional", and indeed do not like abuse of users or newbs one iota; OTOH I have a tendency to use exactly the same sort of language, when I think I'm dealing with someone who should know better, either because they're experienced, or because they are laying claim to some sort of authority they are simply unqualified to claim, and they're also promulgating nonsense.

With someone experienced, I take it for granted that they don't ego-attach to their code, nor do they have any problem with calling crap code a load of crap.

Sometimes I point out to them that they knew it in their gut already, which is why they were running it by me, rather than simply committing it; if it's the first time I've carried on like that, or they appear to be quite sensitive to criticism.

It does not stop me expressing myself first though: I'd rather avoid any doubt, as far too often people (especially USians, I've found) "explain away" any criticism capable of being misunderstood.

This was quite hard for me, when I first started doing the "internet generation" thing, mainly because British English is so couched with little phrases designed to soften the blow of anything that might even be thought of as criticism (likely due to the feudal nature of the society; still: not alone there, any more. ;)

"Oh well he said something nice there" seems to be what that type of person latches on to, not the surrounding criticism, that only someone with no sensitivity whatsoever could miss, or at least so I used to think.

Nonetheless, there is a world of difference between attacking code, and attacking a person; criticism of behaviour is harder, and must be put formally, without losing its clarity, or it is far too easy to tip into attacking the person directly, without holding out any hope for them to change, or indeed any sort of concession that you might just be misinterpreting. (The last is less of an issue when someone has been conducting a campaign/vendetta against you.)

 *Quote:*   

> There are lots of little unsolved commentaries on programming in the computing world that we can argue about for hours. Just recently Linus complained voiciferously about the readability of GCC overflow checking.
> 
> What surprises me is that he has been all but silent on the entire subject of kdbus from a technical perspective. Is it just easier to argue about syntax? Does he not see anything until he has to merge it?

 

Hmm to me that reads a lot like acting-out (or deflection): iow, it's what he wants to say about kdbust, but his "rational" side won't let him:

 *Linux Torbalds wrote:*   

> [Performance is] a f*cking bad excuse for that braindamage.
> 
> I'm sorry, but we don't add idiotic new interfaces like this for idiotic new code like that.
> 
> Yes, yes, if this had stayed inside the network layer I would never have noticed. But since I *did* notice, I really don't want to pull this.
> ...

  ;-)

I mean, by the end, he's conceding that actually the gcc interface is fine, so it seems to me the above-mangled rant is about something else, which could ofc be anything.

----------

## gwr

 *steveL wrote:*   

> and indeed do not like abuse of users or newbs one iota; OTOH I have a tendency to use exactly the same sort of language, when I think I'm dealing with someone who should know better, either because they're experienced, or because they are laying claim to some sort of authority they are simply unqualified to claim, and they're also promulgating nonsense

 

I'd rather there be no abuse as well. However, if it came down to censoring debate rather than tolerating assholes, I would prefer to tolerate the assholes than risk the loss of liberalism in technology. It is often _very_ easy for immoral people to squeeze through the cracks of political correct speech.

 *steveL wrote:*   

> This was quite hard for me, when I first started doing the "internet generation" thing, mainly because British English is so couched with little phrases designed to soften the blow of anything that might even be thought of as criticism (likely due to the feudal nature of the society; still: not alone there, any more. ;)

 

Hey, I'm Canadian, so I inherited not only the British demeanor, but added some additional colonial friendliness to the mix. 

Still, there are professional people I am -very- direct with simply because they have taken advantage of the abiguity of political correctness in the past.

----------

## Anon-E-moose

Interesting post  http://lkml.iu.edu/hypermail/linux/kernel/1511.1/02782.html

----------

## krinn

 *Anon-E-moose wrote:*   

> Interesting post http://lkml.iu.edu/hypermail/linux/kernel/1511.1/02782.html

 

Andy start review and found problems, he submit the problems, they discard them.

Now they are telling they are rewriting it all (as the "discard them" strategy has fail) taking problems that were submits.

And they will send the diff once done for review.

Nobody is or should still keep reviewing what was submit, as it might be obsolete once the rewrite is done, and because it's not an easy job without doc

That's good strategy, if you want review it ; forget what was review (mostly by Andy) and review the original + patches again from start or just review the patches and accept what wasn't review as correct.

I wonder if anyone will have the faith to review it from start (because i don't think Andy will have it).

If none do it, and they only review the patches, then only them will be good, but what wasn't review will remain buggy.

And without doc ; just the changes will be hard to review, increasing chance anyone will only review the changes only.

That's what he is telling, he is already discourage just by the task of reviewing the changes.

Linus really should drop all this crap, so they will comes back with something valid, easy to review, and fresh (to boost anyone faith back into getting into that huge review work).

With some hope, they won't even comeback and we're done with this crap!

----------

## Anon-E-moose

IMO the best case scenario re: kdbus is that Linus refuses to put it into the kernel.

Then RH or whoever can carry the patches against the kernel, the same as bfs, reiser4, etc.

This way any problems that come from the interaction between kdbus and the kernel 

will reflect on RH and staff not the kernel people or at least it should work that way.

----------

## gwr

 *steveL wrote:*   

> [by the end, he's conceding that actually the gcc interface is fine, so it seems to me the above-mangled rant is about something else, which could ofc be anything.

 

He concedes it's necessity for multiplication, but there's no reason to have that logic otherwise.

----------

## steveL

 *steveL wrote:*   

> and indeed do not like abuse of users or newbs one iota; OTOH I have a tendency to use exactly the same sort of language, when I think I'm dealing with someone who should know better

 

 *gwr wrote:*   

> I'd rather there be no abuse as well. However, if it came down to censoring debate rather than tolerating assholes, I would prefer to tolerate the assholes than risk the loss of liberalism in technology. It is often _very_ easy for immoral people to squeeze through the cracks of political correct speech.

 

Indeed; though it only really works when you have a politically-naive crowd, like most geeks, and nowadays afaict most everyone, unfortunately.

Which is why it's so important that all of us protect our community. No point relying on fresh-faced IT graduates to have a real clue.

After all, that's why "burn-and-churn" can even work enough for it to be a phrase: because they're typically so goddamned naive.

 *Quote:*   

> Hey, I'm Canadian, so I inherited not only the British demeanour, but added some additional colonial friendliness to the mix. 

 

Heh; I'm glad you knew what I meant from your own experience.

 *Quote:*   

> Still, there are professional people I am -very- direct with simply because they have taken advantage of the ambiguity of political correctness in the past.

 

Yeah, though I think it's sensible not to allow politically-incorrect apparatchiks, to remove all sense of what "politically-correct" really meant, when it first came into use as a term, afair in the late 80s.

In the first instance, it simply meant: don't use racist or sexist language, and ofc this widened with the various "liberation struggles" that were, and still are ongoing. In essence: don't be an asshole (as these things usually amount to.)

That apparatchiks twist it, like they twist everything, to suit their ends, doesn't mean we should suddenly allow tolerance to mean tolerance of abuse, which is a very typical sociopath argument: "My right to be a shithead" to anyone and everyone is the same as other people's rights to say, talk the truth to power. (khayyam has written this up, but I can't find the posts.)

OFC it's all 'amusing', since only "the little people" are affected: "power-players" just keep on playing the same game.

WRT a balance, I think IRC does well overall, where you have voluntary ops who've been recruited to the position, and not asked for it.

So do these forums, but I wouldn't extend that to other web-forums, in the way I'd suggest someone explore non-gentoo channels on freenode.

 *steveL wrote:*   

> by the end, he's conceding that actually the gcc interface is fine, so it seems to me the above-mangled rant is about something else, which could ofc be anything.

 

 *gwr wrote:*   

> He concedes it's necessity for multiplication, but there's no reason to have that logic otherwise.

 

Oh I'm fine doing my overflows by hand, but then I also much prefer unsigned, from asm days.

I don't like signed-overflow being undefined-behaviour in C; but then we insist on 2's comp as well, which isn't guaranteed by C, but effectively is by POSIX (via mandated exact-width signed types, which C does require to be 2's comp, and available if provided. C99 7.18.1.1.)

In general, it's not just multiplication; that's wrt unsigned such as the calloc case. Otherwise, sure ((x = u + N) < u) is simple enough not to need a wrapper.

Not that the logic is unneeded, mind: just that it can be written clearly without an intervening wrapper that obfuscates what most C coders recognise as a Carry test on unsigned addition. Though you're right that it's more common to test against a lower maximum.

For portability, you have to do the subtraction from max before addition of signed, for instance, unless you're able to rely on/mandate signed-overflow as defined behaviour (eg: -fwrapv, which also specifies 2's comp) in which case you can just check the sign of the result. And ofc you have to regard the incoming sign.

Trickier still with floating-point, ofc, though that's what lib routines are for.

So I'm quite happy to have it in the compiler, given that only it really knows what applies at runtime, but I'd still much rather have a decent set of flags; testing Carry is all this is really about.

edit: I hate side-effects ;)Last edited by steveL on Tue Nov 17, 2015 7:50 pm; edited 1 time in total

----------

## truekaiser

 *digi_owl wrote:*   

>  *Anon-E-moose wrote:*    *gwr wrote:*   "Official" announcement on LKML of redesign and resubmission "when it's ready".
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1511.1/00247.html 
> 
> Wow, what a S. Storm over asking for a simple "what's going on" 
> ...

 

I read that, and think. They are using instability as a form of lock in by only letting udev dev's know ahead of time what the api will change to.

----------

## Shamus397

Well, this is interesting. It seems that since kdbuswreck is meeting heavy resistance, they're trying to do an end run with this thing. LGPL-2, naturally.  :Wink: 

----------

## Naib

Dupe

----------

## steveL

 *Shamus397 wrote:*   

> Well, this is interesting. It seems that since kdbuswreck is meeting heavy resistance, they're trying to do an end run with this thing. LGPL-2, naturally. ;)

 IDK, it looks like someone knocking up a basic "how to use memfd"; that and the barebones to clone a new namespace (which is already part of systemdbust.)

There isn't anything more: it certainly is nothing like a bus implementation; just minimal userland code to do the above, so far. (oh and someone's basic rb-tree, not very well implemented.)

My overwhelming impression is: are they really so stubborn that they cannot admit TIPC already does this much better? [1]

As for the C code, it's a shame they haven't done their time in ##c, never mind ##posix.

I'm not going to do a code review: they should go and learn the basics for themselves, including how to research in the first place.

About the only interesting part for me was that the S390 and CRIS architectures need the stack and flags parms to syscall(__NR_clone) passed the other way round. I certainly wouldn't use their "ABI" for it; it feels like another landgrab, since one would naturally just provide a static helper for the purpose, unused given that it's only going to be used in specific places that know it's a syscall.

Naming sucks as well, as per usual. IDK why "clever" people can't get their heads round the concept of notation.. they always seem to want to obfuscate, as if that proves how smart they are, instead of how dumb.

On the "UNIX sucks! POSIX sucks!" front, it's amusing to see the lofty comments about "a basic ISO-C11/POSIX environment"; the pretension in acting like they're progressive in pushing C11, rather than nubskull, is hilarious. Especially when you consider that all of the StdC headers they include were specified in C99.

And that their code cannot work with anything other than gcc, and will only ever compile, never mind run, on Linux.

And that their code is not standards-compliant in the first place.

[1] Note that Sievers and Poettering both received two copies of that email, in 2012.

Surely it's time to move past these chumps?

----------

## steveL

 *truekaiser wrote:*   

> Starting to think that GKH has mastered the art of passive-aggressiveness.

 

Definitely; he's a nasty piece of work, ime.

 *Quote:*   

> Especially in light of what Landley wrote about recently in regards to getting mdev working, and having to deal with GKH and Sievers.
> 
> http://www.landley.net/notes-2015.html#05-07-2015

 

Yeah, I felt a lot of empathy for what he wrote; and I must confess, a certain sense of commiseration.

 *Quote:*   

> And as i write that i glance once more at the Landley blog, and notice the crap being pulled about stable vs unstable. Where else have we seen that? Oh yeah, systemd. WTF is going on in the Linux world these days?! Is it yet another case of running out of external enemies and so we turn on each other?

 

 *digi_owl wrote:*   

> I read that, and think. They are using instability as a form of lock in by only letting udev dev's know ahead of time what the api will change to.

 

Agreed; they've been using sysfs as a means of vendor (=team) lock-in for years now.

Such behaviour would never be tolerated within a software house.

But then, as Jenny Holzer said: abuse of power comes as no surprise.

----------

## depontius

 *digi_owl wrote:*   

> WTF is going on in the Linux world these days?!

 

Or perhaps someone thinks systemd is the way to desktop dominance, and doesn't realize that they're selling Linux's soul to do so.

----------

## Shamus397

 *Naib wrote:*   

> Dupe

 

Apologies, but I didn't see your topic.  :Wink: 

----------

## Shamus397

 *steveL wrote:*   

> My overwhelming impression is: are they really so stubborn that they cannot admit TIPC already does this much better?

 

I think the reason that they're ignoring TIPC is that it's stable and works well, and thus doesn't fit into their worldview—not to mention the whole NIH syndrome that their project suffers from.

I have no idea what their gameplan is with BUS1 (isn't it cute, it almost looks like PID1, doesn't it?) but if I were to guess, I would say that they're going to push this as a replacement for DBUSt and you'll see the same metastasis with it that we've seen with DBUSt and other related projects.  :Wink: 

----------

## steveL

 *steveL wrote:*   

> My overwhelming impression is: are they really so stubborn that they cannot admit TIPC already does this much better?

 

 *Shamus397 wrote:*   

> I think the reason that they're ignoring TIPC is that it's stable and works well, and thus doesn't fit into their worldview—not to mention the whole NIH syndrome that their project suffers from.

 

Heh, yeah, we can't be dealing with all that boring, reliable stuff that just works in the background, quietly minding its own business, and doing what it's supposed to do, and always has done.

No, we want innurvation, and interesting times, with conferences and kewl stuff to take home; insecure fanbois a must! That's how we keep score, well that and the money..

 *Quote:*   

> I have no idea what their gameplan is with BUS1 (isn't it cute, it almost looks like PID1, doesn't it?) but if I were to guess, I would say that they're going to push this as a replacement for DBUSt and you'll see the same metastasis with it that we've seen with DBUSt and other related projects. ;)

 

IDK I have to admit I've lost all interest in what nuttiness they're going to come up with next.

I imagine they'll start banging on about "correctness" and "standards", just like McCreesh did when the much-vaunted speed of paludis turned out to be a load of hype, as a new way of brow-beating people, to avoid the embarrassing truth that even RedHat couldn't make their crapfest operate, when a) they have a shedload of resource to throw at it, and b) it's their in-house project.

Eventually, after another 5-10 years, they'll end up in the same place openrc was at 7 years ago, much like C++ ended up in the same place as LISP after 30 years of kitchen-sink, ad-hoc "throw it in and let the users patch it down for us."

Nonetheless, it's been good in terms of bumping into people I'd never have spoken with, like yourself, and being able to discuss cleaner ways of doing things, on the basis of forward planning in design from what sysadmins specify.

Rather than: landgrab and polish up the turd from self-proclaimed "kernel and userland experts", after we've crippled everyone's machines and wasted countless end-user hours.

The defence by the collective of its inheritance, has helped to remind us that Linux has always been about choice, and that dbust was a busted flush from the beginning.

Most of all, we have to conclude that we cannot trust anyone apart from ourselves when it comes to defending the ability to pass that legacy on to the next generation.

Certainly not corporations, and certainly not entitled nubskulls whose only real skill is the kind of PR a script would do better, and a burning belief that they're the one ("I'm a rockstar, right?")

----------

## Tony0945

 *depontius wrote:*   

> Or perhaps someone thinks systemd is the way to desktop dominance, and doesn't realize that they're selling Linux's soul to do so.

 

Don't realize? Or don't care?

----------

