| View previous topic :: View next topic |
| Author |
Message |
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
 Posted: Thu Nov 20, 2014 2:05 pm Post subject: kdbus in the kernel |
 |
|
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! |
|
| Back to top |
|
 |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Fri Nov 21, 2014 3:36 pm Post subject: |
|
|
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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sat Nov 22, 2014 1:26 pm Post subject: |
|
|
http://lkml.iu.edu/hypermail/linux/kernel/1411.2/04920.html
All your kdbus are belong to us! 
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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Mon Nov 24, 2014 12:09 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Nov 24, 2014 12:25 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Nov 26, 2014 10:23 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Wed Nov 26, 2014 8:03 pm Post subject: |
|
|
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.
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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Wed Nov 26, 2014 8:59 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Wed Nov 26, 2014 9:04 pm Post subject: |
|
|
| 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."
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9280
|
| Posted: Wed Nov 26, 2014 9:23 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Wed Nov 26, 2014 10:26 pm Post subject: |
|
|
| 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." |
++
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Nov 28, 2014 11:13 am Post subject: |
|
|
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). |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sat Nov 29, 2014 12:18 pm Post subject: |
|
|
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.
The first is that I asked them why we need to add yet another IPC mechanism (and
quite possibly another exploit target) to the kernel. Apparently, they want to
use dbus to do multicast and the existing dbus software is not peformant enough.
There was not much discussion of why the existing network stack is not usable
for this, but I was not terribly concerned about it, so the remainder of our
discussion focused on compatibility. |
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
dbus before anything that needs it and that includes its own components (aside
from its pid 1). The systemd project wanting the API is not a valid reason for
why it should be in the kernel, although it could be a reason to make a CUSE
version go into systemd's pid 1.
That said, why not make kdbus use CUSE?
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
mentioned this to one of the people to whom Greg introduced me (and whose name
escapes me) as we were walking to Michael Kerrisk's talk on API design. I was
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? |
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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Nov 29, 2014 6:23 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sat Nov 29, 2014 9:24 pm Post subject: |
|
|
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.
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Nov 30, 2014 2:00 pm Post subject: |
|
|
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.
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. |
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)..
It only works because not many applications are broken and user-space memory is virtualized. But if you bypass the daemon and use a multicast transport layer (as in our multicast Unix socket implementation) you don't have that much memory to buffer the packets. |
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.
If it's only useful for dbus that that absolutely means we should not add thousands of lines of code to the kernel specifically for that application.
So either way, kernel changes are not justified. |
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. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6148
Location: Dallas area
|
| Posted: Sun Nov 30, 2014 2:50 pm Post subject: |
|
|
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:
>
> a) high number of context switches required to send messages between peer.
This is a user space design issue. The fact dbus wakes up so much
stuff wants fixing at the dbus level.
> b) the D-bus daemon doing the routing and being a bottleneck of the whole.
This is a userspace design issue.
> c) amount of messages copied between kernel space and user space.
This is mostly a userspace design issue and fixing a would fix much of c
because you wouldn't keep sending people crap they didn't need.
You've already got multicast facilities in kernel (if dbus must work by
shouting not state change subscription like saner setups), and you've got
BPF filtering facilities to try and cure some of the wakeups even doing
multicast.
Beyond that I don't see what the kernel can do given its mostly an
architectural problem.
Your model appears to be "since its causing enormous amounts of work we
should do the work faster". The right model would appear to me to be "We
shouldn't cause enormous amounts of work" |
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?
_________________
UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 01, 2014 4:57 pm Post subject: |
|
|
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.
- It also can support location transparent addressing; allows a client application to access a server without having to know its precise location in the node or the network.
If D-Bus uses this schema, I believe the central D-Bus daemon is not necessary any more. Any application can directly talk each other by one-to-one, one-to-many, and many-to-many way.
- TIPC also has another important and useful feature which allows client applications to subscribe one service port name by receiving information about what port name exist within node or network. For example, if one application publishes one system bus service like {1000, 0, 500}, any client applications which subscribe the service can automatically detect its death in time once the application publishing {1000, 0, 500} is crashed accidentally.
Q: Can I just create a AF_TIPC socket on this machine and just make it work without any further setup?
A: no extra configuration if you expect it just works in single node mode.
When publishing service name, you can specify the level of visibility, or scope, that the name has within the TIPC network: either node scope, cluster scope, or zone scope. So if you want it is just valid locally, you can designated it as node scope, which [means] TIPC then ensures that only applications within the same node can access the port using that name. |
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.
- N/A At each destination node, a final lookup is made, once again to identify node local destination ports. A copy of the message is sent each and one of them.
- If any of the found destination ports have disappeared, or are overloaded, the corresponding message copy is silently dropped.
|
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.
- Most messages are passed over intra-cluster connections.
- Packet loss rate is normally low; retransmission is infrequent.
- Available bandwidth and memory is normally high.
- For all relevant bearers packets are check-summed by hardware.
- The number of inter-communicating nodes is relatively static and limited at any moment in time.
- Security is a less crucial issue in closed clusters than on the Internet.
|
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. ;) |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3522
|
| Posted: Mon Dec 01, 2014 5:13 pm Post subject: |
|
|
| 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.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 01, 2014 5:35 pm Post subject: |
|
|
| depontius wrote: | | 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. |
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. :-) |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Dec 01, 2014 6:36 pm Post subject: |
|
|
| depontius wrote: | | 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. |
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. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Mon Dec 01, 2014 7:31 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Dec 01, 2014 7:56 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Mon Dec 01, 2014 8:09 pm Post subject: |
|
|
| 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.
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. |
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. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Mon Dec 01, 2014 9:07 pm Post subject: |
|
|
| saellaven wrote: |
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?
|
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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
