Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
kdbus in the kernel
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 15, 16, 17 ... 25, 26, 27  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon May 04, 2015 1:16 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 216
Location: Ur-th

PostPosted: Tue May 12, 2015 2:43 pm    Post subject: Reply with quote

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. :D
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Tue May 12, 2015 3:57 pm    Post subject: Reply with quote

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.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43178
Location: 56N 3W

PostPosted: Tue May 12, 2015 6:49 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Wed May 13, 2015 3:47 pm    Post subject: Reply with quote

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

How sh#t happens

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.
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.


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.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43178
Location: 56N 3W

PostPosted: Wed May 13, 2015 7:14 pm    Post subject: Reply with quote

depontius wrote:
I see my role as an old guard, ready to point the way back to sanity for anyone who is ready.


++1
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3921
Location: Dallas area

PostPosted: Fri May 15, 2015 10:03 am    Post subject: Reply with quote

Sure been quiet on the mailing list (lkml) this week.

kdbusT didn't make it for the 4.1 kernel either. :wink:
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Fri May 15, 2015 3:11 pm    Post subject: Reply with quote

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.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43178
Location: 56N 3W

PostPosted: Fri May 15, 2015 6:04 pm    Post subject: Reply with quote

Red Hat could fork the kernel if they really really wanted to.
kdbus is just another Red Hat patch.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6281

PostPosted: Fri May 15, 2015 6:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43178
Location: 56N 3W

PostPosted: Fri May 15, 2015 6:42 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Fri May 15, 2015 7:22 pm    Post subject: Reply with quote

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.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3921
Location: Dallas area

PostPosted: Fri May 15, 2015 7:27 pm    Post subject: Reply with quote

From what I have heard, RH already has kdbus as a patch against the kernel.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3383

PostPosted: Fri May 15, 2015 7:42 pm    Post subject: Reply with quote

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.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1374

PostPosted: Sun May 17, 2015 12:33 am    Post subject: Reply with quote

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 ...
_________________
fun2gen2
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1696

PostPosted: Sun May 17, 2015 4:19 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6281

PostPosted: Sun May 17, 2015 8:26 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3921
Location: Dallas area

PostPosted: Sun May 17, 2015 9:16 am    Post subject: Reply with quote

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.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6281

PostPosted: Sun May 17, 2015 9:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1392

PostPosted: Sun May 17, 2015 2:19 pm    Post subject: Reply with quote

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" :roll:
Back to top
View user's profile Send private message
GFCCAE6xF
Apprentice
Apprentice


Joined: 06 Aug 2012
Posts: 266

PostPosted: Sun May 17, 2015 5:06 pm    Post subject: Reply with quote

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" :roll:

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?
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5625
Location: Removed by Neddy

PostPosted: Sun May 17, 2015 5:28 pm    Post subject: Reply with quote

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" :roll:

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.
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
tld
Veteran
Veteran


Joined: 09 Dec 2003
Posts: 1392

PostPosted: Sun May 17, 2015 5:39 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 43178
Location: 56N 3W

PostPosted: Sun May 17, 2015 6:13 pm    Post subject: Reply with quote

tld,

but its no longer an init system. Its a kernel wrapper.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7071

PostPosted: Mon May 18, 2015 2:13 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 15, 16, 17 ... 25, 26, 27  Next
Page 16 of 27

 
Jump to:  
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