| View previous topic :: View next topic |
| Do you want systemd as default on Gentoo? |
| I <3 systemd!! I want Gentoo to switch!! |
|
12% |
[ 26 ] |
| Get that horse-crap away from Gentoo as far as possible! |
|
87% |
[ 186 ] |
|
| Total Votes : 212 |
|
| Author |
Message |
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
 Posted: Thu Nov 06, 2014 3:34 am Post subject: |
 |
|
| avx wrote: |
For me, Thunar doesn't generate thumbnails when built with USE=-dbus. Why the heck doesn't it just call tumbler directly with a path to a file, but instead sends that over dbus? Either I'm too stupid, too old or - well, just tell me. |
I imagine that the idea is to centralize the thumbnail generation so that a thumbnail created in your photo viewer can be used by your file manager and thunar and nautilus and whatever don't all need their own thumbnails. As a remote service, the application doesn't need to worry about paths, permissions, or library dependencies. It attaches to dbus and says "give me a thumbnail". This also stop wasting CPU if two programs are generating thumbnails for the same directory at once.
Personally, I think a standard "~/.thumbs" directory would suffice. The above works in theory, but in practice you are shoving large amounts of data over dbus for nothing, plus doing lots of extra task switching. A prime example of over-engineering.
Last edited by uudruid74 on Thu Nov 06, 2014 4:27 am; edited 1 time in total |
|
| Back to top |
|
 |
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Thu Nov 06, 2014 3:46 am Post subject: |
|
|
| steveL wrote: |
Why are you pulling namespaces and containers into the discussion?
|
Uhmm ... Thats what kdbus is all about! That *IS* the discussion.
Last edited by uudruid74 on Thu Nov 06, 2014 4:28 am; edited 1 time in total |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Thu Nov 06, 2014 3:51 am Post subject: |
|
|
| GrueXYZ wrote: |
Uh... where did I say it was a symlink to preferred shell? As far as I know, and wikipedia agrees with me (I'm sure there's a more relevant source, but I'm too lazy to look it up now) POSIX requires a bourne compatible shell at that path, it can really be anything bourne shell compatible. Like dash for example. Or some xsh-ng thing. Or... hehe, systemd-shelld. I called it first! |
You implied that people could just throw out a script and let the system figure out if it was bash or dash or some other shell. The system does not figure it out. You tell it. You do have to have a bourne shell (or compatible) at that path, but not all bourne shells are bourne again. You can't stick #!/bin/sh at the top of your script and expect the system to figure out what shell you want. Read what you wrote. Its explicit. If you need bash, you tell it bash, if you need dash, you tell it dash. If you need sh, tell it sh. The fact that it might load some other shell that understands bourne syntax has no bearing on the point you were trying to make. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Nov 06, 2014 4:23 am Post subject: |
|
|
| uudruid74 wrote: | | steveL wrote: |
Why are you pulling namespaces and containers into the discussion?
|
Uhmm ... Thats what kdbus is all about! That *IS* the discussion. |
(fixed your quoting for you.)
No it's not: I was discussing the usage of a common multiplexed bus, and you had asked whether dbus is needed at all, and what its purpose is, and why can't it be done in userspace.
If you want to bring something else up, go ahead; just don't do it in response to my post, and not mention it except out of the blue.
For a programmer you sure do make things difficult. |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Thu Nov 06, 2014 5:02 am Post subject: |
|
|
| steveL wrote: |
No it's not: I was discussing the usage of a common multiplexed bus, and you had asked whether dbus is needed at all, and what its purpose is, and why can't it be done in userspace.
|
My apologies. I thought we were talking about kdbus not dbus. Kdbus is riding on the container namespace coats. I'm getting too old and multitasking too much. Actually, after reading what they have in mind, I'm nearly convinced that they might have a slight point. Because its bus oriented and not connection oriented someone has to verify credentials, so the kernel appends metadata about who sent what message. I don't like the namespace hierarchy - they need to rework that, and I don't know if this will be any faster than a userspace implementation. They site fewer task switches, and I suppose thats true if you switch to a userspace demon to route messages rather than just going point-to-point through a directory server. A directory server would let you look up what service you are trying to talk to and then open a socket directly. Then you don't need to copy messages from point to point, and you don't get extra task switches etc. But the question of what they are going to use it for is still vague, and why it has to follow a bus. The only application mentioned so far has been namespaces for containers, and that doesn't require a message bus.
| steveL wrote: | | For a programmer you sure do make things difficult. |
Programmer? Where? I don't see any programmers.
https://fruitsofeddon.files.wordpress.com/2014/11/hacker.jpeg?w=450&h=255 |
|
| Back to top |
|
|
mayak
n00b
Joined: 16 Jul 2013
Posts: 26
|
| Posted: Thu Nov 06, 2014 7:50 am Post subject: |
|
|
while adding support for rhel/centos 7 at work I failed updating one ansible role. there is no denyhosts rpm package available from EPEL (enterprise linux rpm-repository). while searching for the reason I found the following mailing list entry:
https://lists.fedoraproject.org/pipermail/epel-devel/2014-August/010031.html
| Quote: | as the epel maintainer of denyhosts I have no intention to maintain it in EPEL 7. you would need to talk to the fedora maintainer about maintaining it in epel 7 howveer its really not worked well in the
systemd world. longer term there is plans underway to remove tcp_wrappers support from fedora so it would need to be re-written soon anyway. |
have you heard of this before? are all distributions going to remove tcp_wrappers in future releases or only fedora and rhel?
thanks. |
|
| Back to top |
|
|
mayak
n00b
Joined: 16 Jul 2013
Posts: 26
|
| Posted: Thu Nov 06, 2014 10:19 am Post subject: |
|
|
just when I thought I had finished my work on building support for rhel/centos 7 I saw NetworkManager spaming my logs.
well that's strange - I must have done something wrong during installation...
but no, it turns out the minimal (!) installation of rhel/centos 7 ships with 'NetworkManager' and 'avahid' installed and enabled (!) by default:
http://www.tecmint.com/remove-unwanted-services-in-centos-7/
they call it 'enterprise linux' and it aims at servers and the "cloud". i know you can use it as a workstation too. but please do not bloat the minimal install.
with that being said, migrating from lindows 7 to FreeBSD becomes more and more interesting...
PS. sorry for my rant - i know this is not RHEL here |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Thu Nov 06, 2014 10:34 am Post subject: |
|
|
| uudruid74 wrote: | | You implied that people could just throw out a script and let the system figure out if it was bash or dash or some other shell. The system does not figure it out. You tell it. You do have to have a bourne shell (or compatible) at that path, but not all bourne shells are bourne again. |
I never said or implied that, I have no idea where you're reading that. I said that scripts calling #!/bin/sh need a POSIX defined compatible shell and don't care whether it's bourne, bourne again or dash. I am actually saying the exact opposite of what you're implying I'm saying.
Example in practice: I can use a script I wrote on Gentoo, calling #!/bin/sh, on Debian. Gentoo symlinks /bin/sh to bash, Debian to dash. Different shells, basically, both providing bourne compatible "API" and my script is not bash nor dash specific.
| Quote: | | You can't stick #!/bin/sh at the top of your script and expect the system to figure out what shell you want. Read what you wrote. Its explicit. If you need bash, you tell it bash, if you need dash, you tell it dash. If you need sh, tell it sh. The fact that it might load some other shell that understands bourne syntax has no bearing on the point you were trying to make. |
Oh please do quote where I wrote that I expect the system to figure out what shell I want. Figure out. That implies some script analyser that will figure out the syntax and call appropriate shell. I never said that, that's silly.
Alright, maybe my comparing that to dbus is a bit stretched because a dbus API call is a complex one - with structured data transferred around, and #!/bin/sh is a simple call to a bourne compatible shell (not caring whether it's bash or dash). I was merely suggesting the "not caring which is it as long as it's compatible with the specification" to be the same in principle.
Edit: found what confused you, please see my post below, didn't want to change what I wrote here.
Last edited by 229566 on Thu Nov 06, 2014 10:50 am; edited 1 time in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Thu Nov 06, 2014 10:39 am Post subject: |
|
|
| avx wrote: | LWN: Kdbus meets linux-kernel: http://lwn.net/SubscriberLink/619068/1df53bf476960b88/
| Quote: | | In general, kdbus is meant to be a replacement for D-Bus that addresses the various issues that have come up with the latter over time. |
And here I thought dbus itself was the problem... |
Dbus IS the problem.
They didn't design it in the first place, they started out with some random thought implemented it then
over time added more random thoughts until it's the mess it is today.
Now they want to move it to the kernel so that they can get some speed back because of a badly built
program (can't say designed because it never was designed).
The kernel devs seem to understand that and are making them either design kdbus right or it won't go into the kernel.
But this is also a lesson for sysd, continually throwing things into a program with no forethought isn't a design process
it's a recipe for disaster. That's what happened to HAL and that's what will happen to sysd.
And woe be to anyone caught in the avalanche of the fallout from it.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Thu Nov 06, 2014 10:43 am Post subject: |
|
|
| uudruid74 wrote: | | Read what you wrote |
Okay I admit this has been worded poorly, but I totally did not mean analysing the script and calling specific shell. By appropriate I meant exactly what the specification defines for /bin/sh - a bourne compatible shell.
| GrueXYZ wrote: | | It issues a call #!/bin/sh and expects SOMETHING to comply, the parent shell interpreting that and delegating the call to appropriate binary, just like dbus would. |
|
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2282
Location: Adendorf, Germany
|
| Posted: Thu Nov 06, 2014 11:48 am Post subject: |
|
|
| Anon-E-moose wrote: | (...)continually throwing things into a program with no forethought isn't a design process
it's a recipe for disaster. That's what happened to HAL and that's what will happen to sysd. |
That's the point. Absolutely true and ... sad...
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Thu Nov 06, 2014 12:40 pm Post subject: |
|
|
| Yamakuzure wrote: | | Anon-E-moose wrote: | (...)continually throwing things into a program with no forethought isn't a design process
it's a recipe for disaster. That's what happened to HAL and that's what will happen to sysd. |
That's the point. Absolutely true and ... sad... |
Oh, gadzooks! Now you make me really fear what they're going to come up with after systemd!
On a more serious note, as the path for kdbus into the kernel unfolds, it seems to be clear that the kernel devs aren't going to roll over and let some half-baked crap in, the way most of the distributions have. As a result, kdbus may actually become at least halfway decent. But somehow I doubt the systemd developers will take the design lesson they're being given to heart. I think they'll just grumble about obstructionist kernel developers who just don't get it.
By day I'm a chip designer. I've proposed and pushed things in the past, and some of them have even gotten into hardware. But like every parent is in love with his/her own baby, every designer is in love with his/her own design. It's true with chips, bridges, buildings, babies, and no doubt, software. It takes a stranger to say, "Man, that baby is ugly!" In the real world with babies there's no value in saying that to the parent, and it's rude. Also in the real world, a baby isn't a product that others will have to suffer through, at least not much. But products are different.
Besides, the attack surface is only getting bigger, as is the reliance on platitudes for security.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Thu Nov 06, 2014 1:01 pm Post subject: |
|
|
| depontius wrote: |
Oh, gadzooks! Now you make me really fear what they're going to come up with after systemd! |
I think that is pretty much clear. It has been mentioned before here, but it doesn't hurt repeating it!
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
Pretty much clears the road for license circumvention by post-distribution download of pre-packaged proprietary software. It also clears the road for total obliteration of Linux distributions as we know them and enabling native write-once-run-anywhere containerized software.
Not allowing SyStEmD into Gentoo is not a question of defaults, inits and choice any more. It is a question of whether Gentoo will cease to be relevant at all as the sYsTeMd future is about nameless linux_kernel + systemd + containerized_apps. In such an ecosystem nobody will care what "distro" is run as they will all be kernel + systemd + same_software. It's not "just an init you can choose to run or not". It should be removed from the tree and considered a malware! |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Nov 06, 2014 3:06 pm Post subject: |
|
|
| uudruid74 wrote: | | steveL wrote: |
No it's not: I was discussing the usage of a common multiplexed bus, and you had asked whether dbus is needed at all, and what its purpose is, and why can't it be done in userspace.
|
My apologies. I thought we were talking about kdbus not dbus. |
OK, dbus/kdbus then, since that's what's being reimplemented in the kernel, instead of addressing the design problems with dbus, in userland usage terms.
| Quote: | | Kdbus is riding on the container namespace coats. I'm getting too old and multitasking too much. Actually, after reading what they have in mind, I'm nearly convinced that they might have a slight point. Because its bus oriented and not connection oriented someone has to verify credentials, so the kernel appends metadata about who sent what message. I don't like the namespace hierarchy - they need to rework that, and I don't know if this will be any faster than a userspace implementation. |
The point is before you even get to namespacing, you have to answer the question of just what it is you're doing routing all this data via one bus. (So much data that your userspace impl is too slow for you.)
Further all of the above can be done with sockets already: if you weren't shoving megabytes of data down the single-impl multiplexed bus, you wouldn't have a problem; but equally you wouldn't have a rationale for taking your leech-RPC into kernel-space, where it would never be dislodged, since the kernel guys don't break userland. (As ever, those seeking to exploit us use our decency against us, whereas they have no problem whatsoever breaking their consumers.)
That is the big problem with the kdbus push: it effectively locks the Linux kernel (and its developers) into supporting a monocultural userland completely controlled by Redhat.
That is a very different proposition to using patches which make devices work better for everyone. And it doesn't seem to be a concern, so far.
| Quote: | | They site fewer task switches, and I suppose thats true if you switch to a userspace demon to route messages rather than just going point-to-point through a directory server. A directory server would let you look up what service you are trying to talk to and then open a socket directly. Then you don't need to copy messages from point to point, and you don't get extra task switches etc. |
That doesn't make any sense really; a directory server is neither here nor there in terms of whether you copy a userland buffer once the connection is live, and when it comes to namespaces, the filesystem is the namespace, which is why the standard Unix lookup call is namei.
| Quote: | | But the question of what they are going to use it for is still vague, and why it has to follow a bus. The only application mentioned so far has been namespaces for containers, and that doesn't require a message bus. |
I'd imagine the rationale is that they want the bus namespaced; but a) that's a completely separate argument as to whether you should be using a single point-of-failure/bottleneck and what you're using it for.
and b) it's irrelevant anyhow since a new namespace implies a different lookup for eg a path to a Unix socket, already. So there's no need to even get into this: it's just more bulshytt pretext.
Like I said, all that's needed to avoid the copy is to have a slightly different API to message-queues. That would be much more generically useful, across the board, for every application, and also as a candidate for standardisation.
As usual though our time is kept discussing a really crappy set of ideas, instead of focussing on better ones. Reminds me very much of Microserf. |
|
| Back to top |
|
|
RazielFMX
l33t
Joined: 23 Apr 2005
Posts: 835
Location: NY, USA
|
| Posted: Thu Nov 06, 2014 3:31 pm Post subject: |
|
|
| steveL wrote: | | Like I said, all that's needed to avoid the copy is to have a slightly different API to message-queues. That would be much more generically useful, across the board, for every application, and also as a candidate for standardisation. |
This.
As I'm reading about kdbus and its ability to be a messaging bus and pass fds around, I can't help but think why not just improve the API for Posix Message Queues and Unix Domain Sockets (respectively). These are supported across operating systems* (though the interfaces and capabilities due vary slightly; standardization of an API around these proven mechanisms wouldn't hurt). What does kdbus provide that these other mechanisms do not?
* *NIX OS only
_________________
I am not anti-systemd; I am pro-choice. If being the latter makes you feel that I am the former, then so be it. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Thu Nov 06, 2014 3:51 pm Post subject: |
|
|
| RazielFMX wrote: | | What does kdbus provide that these other mechanisms do not? |
Very little, which is why the kernel devs are looking at the code but not whole heartedly embracing it.
Several have mentioned that many of the things being used for justification for kdbus to even exist
in the kernel have already been implemented in other ways.
Developers of other software are pointing out that many of the things being claimed to be needed
for kdbus have been done in userspace in their applications/software for a number of years now,
ie dealing with the need for kdbus because dbus is too slow.
_________________
PRIME x570-pro, 3700x, 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: 6097
Location: Dallas area
|
| Posted: Thu Nov 06, 2014 3:57 pm Post subject: |
|
|
It seems that the submission isn't faring too well against the peer review by the kernel devs.
I've seen reference to kdbus v2 already which means they're having to redo some of the code.
I do believe that if kdbus makes it into the kernel, it won't be anything like what LP et al were expecting to be allowed.
Which means we'll probably hear another screed from LP or one of his cabal complaining about how the kernel devs
are standing in the way of progress, etc. There is an easy solution though, make kdbus an RH patch and use it on
RH only (of course that would pretty much mean that all other distros would either have to become an RH clone
or walk away from sysd/dbus).
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Thu Nov 06, 2014 4:06 pm Post subject: |
|
|
| Anon-E-moose wrote: | | RazielFMX wrote: | | What does kdbus provide that these other mechanisms do not? |
Very little, which is why the kernel devs are looking at the code but not whole heartedly embracing it.
Several have mentioned that many of the things being used for justification for kdbus to even exist
in the kernel have already been implemented in other ways.
Developers of other software are pointing out that many of the things being claimed to be needed
for kdbus have been done in userspace in their applications/software for a number of years now,
ie dealing with the need for kdbus because dbus is too slow. |
Catch-22 in play...
Someone who understood what kdbus was trying to do, as well as understanding existing kernel interfaces, could come up with a better dbus implementation using those existing interfaces. Perhaps a few kernel patches would be necessary, but those would enhance existing facilities, making them better for all.
But those who understand kdbus don't want that solution, and those others who could create that solution can't do so because when they try to work with kdbus they're too busy holding their noses to code.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 450
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Thu Nov 06, 2014 4:49 pm Post subject: |
|
|
LoL
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Thu Nov 06, 2014 7:51 pm Post subject: |
|
|
| mayak wrote: | just when I thought I had finished my work on building support for rhel/centos 7 I saw NetworkManager spaming my logs.
well that's strange - I must have done something wrong during installation...
but no, it turns out the minimal (!) installation of rhel/centos 7 ships with 'NetworkManager' and 'avahid' installed and enabled (!) by default:
http://www.tecmint.com/remove-unwanted-services-in-centos-7/
they call it 'enterprise linux' and it aims at servers and the "cloud". i know you can use it as a workstation too. but please do not bloat the minimal install.
with that being said, migrating from lindows 7 to FreeBSD becomes more and more interesting...
PS. sorry for my rant - i know this is not RHEL here |
FreeBSD? UHmm .. Gentoo and Funtoo don't force you to install NetworkManager or avahid!
*hint* *hint* |
|
| Back to top |
|
|
uudruid74
n00b
Joined: 21 Jun 2014
Posts: 30
|
| Posted: Thu Nov 06, 2014 8:14 pm Post subject: |
|
|
From what I can see the difference between kdbus and existing socket implementations is that kdbus is "bus" oriented, not point-to-point. Instead of connecting to a specific destination, you send it over the bus and let the bus decide what to do with it. Now, I don't know if the bus sends it to everyone else on the bus (a scary thought - talk about a stampeding herd), or just to a specific listener. I haven't read all the details, but maybe this is what they want to add all these namespaces for?
With kdbus in userspace, we get:
App1 sends data to kdbus socket
task switch to kernel
kernel reads socket and sends data to kdbus socket
task switch to kdbus,
kdbus copies data to App2 socket in userspace
kernel reads socket and sends data to App2 socket
task switch to App2
App2 reads from its socket
In the kernel it becomes :
App1 sends data to kernel
task switch to kernel
kernel reads socket and sends data to App2 socket
task switch to App2
App2 reads from its socket
So - thats why they say its more efficient in the kernel. And they want the kernel to add information about the process that sent the data to manage credentials (at each message because its not connection oriented - another point the kernel devs aren't liking). Of course this security "feature" can just as easily become a serious security hole because sending a message tells everyone information about the process. They even want to allow privaledged processes the ability to snoop all bus messages secretly! Now, if they are broadcasting to multiple destinations, that the data transfer problems even worse.
I would implement this (in userspace) by removing the "bus" idea and using a directory services API to find the socket you need to connect to based on the service you want, and then connect to that socket directly. This keeps it out of the kernel and its just as efficient, and your service mapping can be implemented in userspace. The only thing it won't do is a true broadcast, but I think thats a bad design. I think they want to do things like broadcast notifications, such as when you plug in an HDMI monitor, it tells everyone and then everyone that cares will respond. I would rather have a single owner for these events and if they want to propogate them, fine. In the HDMI example, udev gets the message, it tells X (like it already does). X can tell the window manager through its event API and the window manager can move windows, expand the desktop, whatever. Broadcasting this information is going to cause an N^2 slowdown as more applications start supporting the "universal bus".
I also like how they mention that most commercial operating systems implement a single system bus plus a bus for each user. Who does this? Why don't they just come out and say they are copying Windows?
I think of it like how high speed servers changed over to switching fabrics because of the bandwith limitations of bus protocols. Why emulate an old ISA bus in the kernel when we know efficiency requires PCIe? |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Thu Nov 06, 2014 10:39 pm Post subject: |
|
|
| uudruid74 wrote: |
So - thats why they say its more efficient in the kernel. And they want the kernel to add information about the process that sent the data to manage credentials (at each message because its not connection oriented - another point the kernel devs aren't liking). Of course this security "feature" can just as easily become a serious security hole because sending a message tells everyone information about the process. They even want to allow privaledged processes the ability to snoop all bus messages secretly! Now, if they are broadcasting to multiple destinations, that the data transfer problems even worse.
|
This sounds awfully close to putting policy in the kernel. Plus the lkml discussion sounded like they were headed down that path, too. Linus has generally resisted putting policy into the kernel, and I would be surprised if he made an exception here. Others have suggested, and I agree, that it will be something like kdbus v2 that finally does make it in. By that time I would expect to see policy mechanisms in the kernel, but the policy decisions themselves would remain in userspace, where they belong.
From the lkml discussion I read, the desired policy side sounded as leaky as all-get-out, from a security point of view.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6097
Location: Dallas area
|
| Posted: Thu Nov 06, 2014 11:41 pm Post subject: |
|
|
| depontius wrote: | | From the lkml discussion I read, the desired policy side sounded as leaky as all-get-out, from a security point of view. |
It has the potential for that, which is why some of the kernel devs were making noise about it.
I doubt it will go in as the LP cabal wants it.
_________________
PRIME x570-pro, 3700x, 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 07, 2014 10:35 am Post subject: |
|
|
| uudruid74 wrote: | In the kernel it becomes :
..
So - thats why they say its more efficient in the kernel. |
All you've shown is why a userland multiplexor is necessarily less efficient than the kernel. What you appear to be missing is that the kernel is a multiplexor, so that effectively what dbus does is reimplement part of the kernel in userland. Now we're pushing an impl of the kernel that is limited, constrained, and inflexible by comparison into the kernel.
That's why this is insane.
And incidentally you've ignored what I wrote in response to you above: the reason they want to push it into kernel is primarily business-oriented (to lock the kernel into supporting the RH monoculture for all time.) The pretext given is because namespaces (which has no basis in reality) and we all know that internally the systemdiots have told themselves it will "solve" their performance problems. However these problems are the equivalent of using an O(N^3) algorithm when you could be using an O(log N) algorithm; they are down to plain old vanilla stupidity, and an unwillingness to admit error, which is fatal for a designer (and indeed a programmer.)
These design problems will not necessarily be addressed by kernel review, though, since mostly they're about userland stupidity, and kernel devs have to think of userland as crazy, or they're not approaching things right.
| Quote: | | I would implement this (in userspace) by removing the "bus" idea and using a directory services API to find the socket you need to connect to based on the service you want, and then connect to that socket directly. |
You keep going on about directory services, and it's just wrong. You sound like as much of a Windows wannabe as Poeterring from what I've read so far.
| Quote: | | This keeps it out of the kernel and its just as efficient, and your service mapping can be implemented in userspace. |
On even in /etc/services like we always have.
| Quote: | | The only thing it won't do is a true broadcast, but I think thats a bad design. |
Oh that's all right then; since you don't know that sockets can broadcast, anyone who wants to broadcast events must necessarily have the wrong idea.
| Quote: | | I think of it like how high speed servers changed over to switching fabrics because of the bandwith limitations of bus protocols. Why emulate an old ISA bus in the kernel when we know efficiency requires PCIe? |
PCIe is a bus. It's just serial, rather than parallel.
I'd explore netlink first since it's meant to be usable from userland, for userland communications. Though personally I really like SCTP; its semantics are a very good fit for what's happening here. And I would not shove data down it, beyond minimal metadata. |
|
| 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
|
|
Gentoo Chat
