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 ... 19, 20, 21 ... 25, 26, 27  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Naib
Watchman
Watchman


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

PostPosted: Thu Jun 25, 2015 8:45 am    Post subject: Reply with quote

Any IPC can be used to circumvent the GLP and yes that includes files and TIPC. If the author of a library decides to expose its entire API to an IPC (instead of requiring linkage -> gpl inclusion) then well... more fool them. HOWEVER something still needs facilitate the link (a library doesn't run without some application using it) so you need clear intentions to bypass the GPL via an IPC

1) some gpl library/program must expose its API to an IPC
2) something must launch the library.

So why is the IPC the boogyman here when it is the author of the glp'ed library that facilitated it? its like blaming the gun for someone shooting up a school - non sequitur. Would you blame Ext4 for facilitating in bypassing the GPL (and yes I have done something nasty with files as an interprocess comms to produce a crude co-processor between matlab and EFFE [FEA application] as I could take credit for EFFE watching for a certain file to auto exec and a simple matlab script was written to watch for a suitable output file...

Linking (and thus being wrapped in the gpl) will always be faster due to the shared memory
KDBus/TIPC in theory would be the next fastest
DBus
Sockets
Files


If there is a conspiracy to bypass the GPl via an IPC ( as 1st popped up here: http://slashdot.org/comments.pl?sid=5735323&cid=47959449) it for starters wouldn't be the first (gpl3 was created to close a tivo loophole iirc)


Sysd are the most vocal with regards to needing dbus, their aim is to perpetuate sysd and if you notice they created sd-bus "a fun api to provide inter process communication" which will use dbus or kdbus. While sysd has made it clear they would target ONLY linux, sdbus has been released cross-platform (inc windows).
At a guess I would think GNOME and its apps would jump onto sdbus ASAP as it would "simplify their applications dbus interface" and they would magically get a performance boost if kdbus is present - the fact KDBUS isn't that efficient doesn't change the fact it is a boost over userland AND it could, if further optimised give a big boost.

One thing I would say around KDBUS is if an in-kernel IPC is required or is deemed the next evolution, there is one thing to concider with KDBUS over others: https://xkcd.com/927/
Now I am not saying KDBUS is great or will be great if/when they sort it out

What's more realistic is RH/Systemd intention to wrap the kernel completely and thus no application needs to interface with the kernel BUT must go via systemd. Systemd includes an EFI bootloader, systemd is the handover from kernel to userspace for init... more and more of linux is being encapsulated in systemd which provides a level of abstraction. So rather than userland interfacing with the kernel, they would all interface via systemd
_________________
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


Last edited by Naib on Thu Jun 25, 2015 12:20 pm; edited 4 times in total
Back to top
View user's profile Send private message
augustin
Guru
Guru


Joined: 23 Feb 2015
Posts: 318

PostPosted: Thu Jun 25, 2015 8:51 am    Post subject: Reply with quote

Thanks, Naib. Your comment helps me understand a bit better the whole debate, although, I am sure, I still have much more to learn.
:)
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1371

PostPosted: Thu Jun 25, 2015 10:14 am    Post subject: Reply with quote

mv wrote:
Linus said very precisely his only reason why he does not kill the kdbus idea immediately: He had previously trusted one person advocating it.

This is a valid social reason. Quite the opposite of your invented marketing reasons which BTW are technically plainly false. (Except for the last one which is exactly the argument which Linus explicitly rejected as invalid.)

Nobody had expected Linus would answer such hypothetical , because nobody knows how the next kdbus patches for the next pull request will look like. Greg answered this bitchy looking question:
Greg wrote:
> Can you opine as to whether you think that kdbus should be merged?

Ah, a preemptive pull request denial, how nice.

I don't think I've ever seen such a thing before,
Linus normally would not answer. But why he did?

If an officer currently in charge to stablelize the kernel is asking for a pull request, this is a call for Linus to soonishly accept but not later. If no NOK. This he announces. The question answered was a "wake up call" for Andy Lutomirski to learn more about kdbus, which he promptly does :
http://lkml.iu.edu/hypermail/linux/kernel/1506.3/index.html#00169
This indicates his question in the first place was not meant just bitchy. He was in need of a hint from his leader.

Talking about Linus how "He had previously trusted one person" sounds to me like a Tolkien drama. I don't take the expressed trust in Linus announcement literally as his sole motivation. This is naive. Linus for sure knows more than he talks about,
augustin wrote:
What is the primary motivation for the people behind kdbus?

Linus himself uses systemd and knows about the motivation of Poettering: systemd developers want to get a kernel based infrastructure to implement a proper reboot technique.

@mv, sure I talk about the marketing arguments for kdbus in the kernel. They may be false. Perhaps not invented or implemented yet. It is what is marketed ... Your own understanding of what is going on seems to me like crazy: Why should Linus "reject" reducing mem copying of kdbus? Perhaps you got confused here:
Linus saw some performance tests using short message samples. These showed kdbus is not much faster than a sane programed user mode dbus would be (if existed). Linus rejected performance as a sole argument for kdbus inclusion.

@mv, your red marked sentence is insinuating a motivation of me which my post as a whole does not deserve. Especially in the light of my last clause there:
ulenrich wrote:
Andy Lutomirski announcing how he will test the next kdbus proposal regarding security and Linus interest in performance, which signals an important aspect of quality of the code, makes me confident the kernel developers are able to decide when to include kdbus into mainline. Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.


Naib wrote:
How many times did they change the API
That an argument to wait further for kdbus to be ready! But don't miss Linus saying at http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00753.html
Linus wrote:
I do agree that distro's that want to enable kdbus before any agreed
version has been merged would get to also act as guinea pigs and do
their own QA, and handle fallout from whatever problems they encounter
etc. That part might be good.
This lets me think Linus wants kdbus in mainline. Really just because Greg is so trustworthy? About this motivation my post:
https://forums.gentoo.org/viewtopic-p-7769316.html#7769316

Beg pardon for my overly quoting style in this post. It is ever hard for me to acknowledge all of what people have ignored and don't want to see.
_________________
fun2gen2


Last edited by ulenrich on Thu Jun 25, 2015 11:15 am; edited 1 time in total
Back to top
View user's profile Send private message
mrbassie
Guru
Guru


Joined: 31 May 2013
Posts: 527

PostPosted: Thu Jun 25, 2015 11:13 am    Post subject: Reply with quote

ulenrich wrote:

Linus wrote:
I do agree that distro's that want to enable kdbus before any agreed
version has been merged would get to also act as guinea pigs and do
their own QA, and handle fallout from whatever problems they encounter
etc. That part might be good.



you left out :

"But I don't think we really end up
having the option to make up some incompatible kdbus ABI
after-the-fact."
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1371

PostPosted: Thu Jun 25, 2015 11:19 am    Post subject: Reply with quote

mrbassie wrote:
you left out :

"But I don't think we really end up
having the option to make up some incompatible kdbus ABI
after-the-fact."
Read my f... fulminant sentence answering Naib! The warning to the distros playing the guinea pig evaluates further as a plan to accept kdbus when it is ready: Why would he warn otherwise?

[edit]changed language in request of mrbassie
_________________
fun2gen2


Last edited by ulenrich on Thu Jun 25, 2015 11:54 am; edited 2 times in total
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Thu Jun 25, 2015 11:21 am    Post subject: Reply with quote

ulenrich wrote:


Naib wrote:
How many times did they change the API
That an argument to wait further for kdbus to be ready! But don't miss Linus saying at http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00753.html
Linus wrote:
I do agree that distro's that want to enable kdbus before any agreed
version has been merged would get to also act as guinea pigs and do
their own QA, and handle fallout from whatever problems they encounter
etc. That part might be good.
This lets me think Linus wants kdbus in mainline. Really just because Greg is so trustworthy? About this motivation my post:
https://forums.gentoo.org/viewtopic-p-7769316.html#7769316

Beg pardon for my overly quoting style in this post. It is ever hard for me to acknowledge all of what people have ignored and don't want to see.


and that doesn't dismiss my point. A pull request should not have gone in. Code quality is one thing (userland writing kernel will always be ... interesting EXACTLY like vhdl writers writing python [something I have to deal with]) but having a non-stable API and expecting a pull is retarded... AND the type of thing that results in updating the kernel in lockstep.
Imagine if the 1st kdbus pull request got accepted "oh wait we want to change the API..."
_________________
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
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6277

PostPosted: Thu Jun 25, 2015 11:25 am    Post subject: Reply with quote

ulenrich wrote:
your red marked sentence is insinuating a motivation

Yeah, it was too aggressive. It is now removed.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1371

PostPosted: Thu Jun 25, 2015 11:39 am    Post subject: Reply with quote

Naib wrote:
and that doesn't dismiss my point. A pull request should not have gone in. Code quality is one thing (userland writing kernel will always be ... interesting EXACTLY like vhdl writers writing python [something I have to deal with]) but having a non-stable API and expecting a pull is retarded... AND the type of thing that results in updating the kernel in lockstep.
Imagine if the 1st kdbus pull request got accepted "oh wait we want to change the API..."
:)

This time there was no pull request. But the discussion in the kernel mailing list well may be part of the stabilizing process of the API (or ABI ? the same in this context?). Kind of an interesting thread there about misunderstandings and clarifying attempts:
http://lkml.iu.edu/hypermail/linux/kernel/1506.3/index.html#00169

But also very naive questions there sometimes:
http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00795.html
Although the author knows Linus has answered this already (he indicates by not directly talking to Linus name)
_________________
fun2gen2


Last edited by ulenrich on Thu Jun 25, 2015 11:50 am; edited 3 times in total
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Thu Jun 25, 2015 11:44 am    Post subject: Reply with quote

I know there wasn't (so that is at least an improvement upon hte previous two or three...). Just because there isn't a new pull request doesn't magically change history and scrub the fact that there were previous pull requests AND at least one API change
_________________
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
mrbassie
Guru
Guru


Joined: 31 May 2013
Posts: 527

PostPosted: Thu Jun 25, 2015 11:49 am    Post subject: Reply with quote

ulenrich wrote:
Read my fucking sentence just above answering Naib!


Was that really necessary? :roll:
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1371

PostPosted: Thu Jun 25, 2015 12:02 pm    Post subject: Reply with quote

mv wrote:
ulenrich wrote:
your red marked sentence is insinuating a motivation

Yeah, it was too aggressive. It is now removed.
And don't you think Linus would be very interested in kdbus if the 4 marketing points I listed where sanely implemented. I mean beside any emotional moments when Linus looks into Gregs wonderful eyes. My impression reading this wonderful thread: Linus is sitting before his laptop and starts Google hangout for to see Gregs trustworthy face again.
_________________
fun2gen2
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Thu Jun 25, 2015 2:31 pm    Post subject: Reply with quote

augustin wrote:
[He did say he would like to have a better performing kdbus in the kernel. As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment.


Allow me to me rephrase a little. I completely agree that this is a valid argument. I am confused as to why this issue is the only issue that he raised with it. Even if it's performance was fine, I still think there is an over-riding issue that it is functionality that doesn't need to exist at all. It doesn't need to be written, deployed, or maintained. And it's technically unsound even if it did need to exist.
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3381

PostPosted: Thu Jun 25, 2015 3:39 pm    Post subject: Reply with quote

I like this little tidbit, which draws parallels between kdbus and the in-and-out devfs: https://lkml.org/lkml/2015/6/25/42

On another level, there's something else going on here, and I don't think it's generally recognized. L.P. has forced the issue by pushing the kdbus-first requirement out to the distributions with systemd. Linus is clearly feeling the pressure, knowing that a kernel change may prevent systems from booting. He hasn't phrased it as pressure, but he clearly recognizes that the problem exists, and appears to be getting ready to act on that perceived problem.

In other words, systemd has taken over some portion of the kernel decision process and control.

There will be two further litmus tests:
1 - The next time they want to juggle the kdbus API in an incompatible way.
2 - When they reach elsewhere in the kernel and make kdbus the way to signal udev events. ("Gentoo, you have been warned!" If not exact, that's a near-exact quote.)

There are two other stated directions by the systemd team:
1 - Systemd writes to Linux, and everyone else writes to systemd. In other words, only one Linux user - systemd, the rest of us become systemd users.
2 - The kernel moves in lockstep with system.

At the risk of courting Godwin, there have been other times in history when you don't even have to read between the lines. There have been times when intentions have been stated out in the open, and nobody really believed it. Then when those intentions are acted on, people seem surprised that that's happening.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Thu Jun 25, 2015 8:04 pm    Post subject: Reply with quote

ulenrich wrote:
He did say he would like to have a better performing kdbus in the kernel.

He's already got TIPC. So kdbus is just pointless reinvention of the wheel, only they're banging on about how the circle is outmoded, and we should all be using hexagons, no wait, version 2.0 is out, now with octagons!

We can argue all we like about the difference between hexagons and octagons, but the point remains: they're both shit by comparison to what they're trying to displace.
It seems to me that half the game is to get us to argue about their crap instead of focussing on something better.
Quote:
As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better.

Why do you keep making vague allusions to something that no-one can check? That's what I mean by "politicking" in your discourse; you're holding out this mysterious sense of "don't worry, someone knows better than you" when past history would demur.

If anything, more often than not we're presented with a latest brainwave that will soon be forgotten, except that we'll all be forced to implement it, and then throw it away for the next turd. In each case, reason and technical design count for nothing; it's all about propaganda and hype.
Quote:
Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits:

I rather think Torvalds is simply dealing with what comes up, when it comes up, just like he always has.

I certainly don't see any of these as benefits:
Quote:
- boot and shutdown with systemd in a sober manner without all these special hardcoded units
- the widely and since long used dbus will run in a secured kdbus environment (without javascript)
- dbus running in the kdbus environment will scale up for use with multimedia

IOW "fixing problems we made" and then labelling it "progress".

It may be "improved on our last product" but it's still crap in the overall scheme of things.
Quote:
- virtual machines communication feature added

Yeah cos no-one else has being doing any work in VMs in the last 20 years.. systemdbust is the only way to do that, ofc /s

The arguments with the docker people will soon be forgotten, just like the arguments with pro-audio.
Quote:
Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.

This is pure nonsense; I know you're not as naive as this statement pretends.

Corporations are based on corrupted money, by definition. They regularly act against the interests of everyone else, including the community that nurtured them in the first place.

If we don't stand up for ourselves, later we'll be told "you should have complained back then"; when we respond "we did", we'll be told "all complaints were dealt with" and by implication: "you're a liar" (cue: insinuations, bitchiness and pooh-poohing as if it's all just in our heads. "Trust in me..")

Still, so long as you've got your corporate tee-shirt, everything will be fine right? Just sing along, and keep doing the work for free, so they can sell it back to you, wrapped up in crap, but with lots of sizzle.
Nowadays we venerate thieves and fraudsters as "successful" and then wonder why our kids are so unhappy, and so mean-spirited, as if it were nothing to do with us, and the paucity of empathy inherent in everyone trying to grab what they can.

The last link above (on audio) practically reads like a response to this, though.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Thu Jun 25, 2015 8:29 pm    Post subject: Reply with quote

Naib wrote:
Any IPC can be used to circumvent the GLP and yes that includes files and TIPC. If the author of a library decides to expose its entire API to an IPC (instead of requiring linkage -> gpl inclusion) then well... more fool them. HOWEVER something still needs facilitate the link (a library doesn't run without some application using it) so you need clear intentions to bypass the GPL via an IPC

1) some gpl library/program must expose its API to an IPC
2) something must launch the library.

So why is the IPC the boogyman here when it is the author of the glp'ed library that facilitated it?

Eh, we discussed this ages ago. It's not about the GPL library providing the API over dbust; it's about an LGPL-GPL combination, whereby the GPL part links to the GPL-code you want to leech, and only provides a dbust-R^IPC connection, and then your leechclient can link to the other side of that mess, which is LGPL and the only way to talk to that GPL-evasion.

This flies against all common sense for two reasons: one would normally wrap an existing API, or implement one to wrap first, since it's much easier to test and the API can be used directly, much more efficiently. The point being that there is an API first, and then it's exposed, should the authors actually want to do that.

Secondly it makes no sense to redirect what is in effect a local function call, simply to relabel it RPC (woops IPC since this is local machine) because that is orders of magnitude slower.

The original work on dcop and GNOME's ORB was much better.
It's like Poeterring and Sievers came in as a third-party, and ended up stealing the jewels from both the others. Classic carpet-bagging.

Nice try to put kdbust and TIPC on the same level, but they're worlds apart. The latter doesn't try to reinvent everything in the kernel in userland and then push for the entirety of the same mess in-kernel. It just does what's needed.

Now you can spend 20-30 years "improving" your turd until you finally end up reinventing what came before; or you can design up-front, based on past experience.
The latter is characterised by careful research, the former by bulshytt and hype, and works primarily because people are social creatures, and like to feel we're all moving forward together, even if we are going in circles.

The simple fact though, is that the kdbust "developers" have made it a point of pride that they will provide the exact same "semantics" as dbust, and as we've already seen, that is not going to work.
So expect a climbdown on that at some point in the future, once they've established their Lennux fork of Linux, and can do so quietly with one of those lovely "look what we've discovered" blog-posts ("don't you just feel special to be involved?")

I've lost count of how many of those I've read in the last 7 years, how many interfaces that were recommended to them which they shot-down with nastiness and zero-thought, only to see the light a few years later.
polkit was supposed to "obsolete PAM", and now PAM is the bees-knees and required for systemdbust.
"POSIX is full of shit", but hey now we've actually got some experience under our belt, we love POSIX RT-signals so much we've stopped every other program on your machine from using them.

You couldn't make it up, hehe.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Thu Jun 25, 2015 8:45 pm    Post subject: Reply with quote

depontius wrote:
On another level, there's something else going on here, and I don't think it's generally recognized. L.P. has forced the issue by pushing the kdbus-first requirement out to the distributions with systemd. Linus is clearly feeling the pressure, knowing that a kernel change may prevent systems from booting. He hasn't phrased it as pressure, but he clearly recognizes that the problem exists, and appears to be getting ready to act on that perceived problem.

In other words, systemd has taken over some portion of the kernel decision process and control.

Agreed; though perhaps more accurate to say "RedHat", or rather whatever the name of the dodgy tax-evading conglomerate they're part of may be.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1371

PostPosted: Thu Jun 25, 2015 10:06 pm    Post subject: Reply with quote

steveL wrote:
ulenrich wrote:
He did say he would like to have a better performing kdbus in the kernel.

He's already got TIPC. So kdbus is just pointless reinvention of the wheel,

Looking up the timelines of both projects dbus and tipc: Seems to me a parallel development. If you look up the tipc roadmap 2015/16: open problems all over the place there also. Especially the ABI for C developers using TIPC is about to be redesigned? Reading about nodes and clusters: Isn't it a different domain they talking about?

steveL wrote:
It seems to me that half the game is to get us to argue about their crap instead of focussing on something better.

If dbus is total crap inside isn't this a typical starting-point to work over the shared resource: Here at this point using TIPC is reinventing the wheel.

steveL wrote:
Quote:
As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better.

Why do you keep making vague allusions to something that no-one can check? That's what I mean by "politicking" in your discourse

On the contrary of politicking in favor of kdbus I speculate about Linus trying some tactics to get dbus in the kernel. You cannot understand it assuming Linus is pressured to accept kdbus. Me assuming the contrary I see some communication of Linus is tactic here.

steveL wrote:
I certainly don't see any of these as benefits:
Quote:
- boot and shutdown with systemd in a sober manner without all these special hardcoded units
- the widely and since long used dbus will run in a secured kdbus environment (without javascript)
- dbus running in the kdbus environment will scale up for use with multimedia

IOW "fixing problems we made" and then labelling it "progress".

1. Also openrc has an extra sysinit stage.
2. Every IPC must solve the security problem. How does TIPC?
3. Using dbus for multimedia was an idea of the automotive industry.

Quote:
Quote:
- virtual machines communication feature added

Yeah cos no-one else has being doing any work in VMs in the last 20 years.. systemdbust is the only way to do that, ofc /s

The arguments with the docker people will soon be forgotten,

@steveL, this the original domain of TIPC - it can get some merits there for sure, if not forgotten and unused.

steveL wrote:
Quote:
Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.

This is pure nonsense; I know you're not as naive as this statement pretends.

Corporations are based on corrupted money, by definition. They regularly act against the interests of everyone else, including the community that nurtured them in the first place.

I had read that history of the banks of England and the US some time ago. And I know the City of London in that respect is a special case until today. I wonder if Bitcoins will have a different outcome. I know what you talk about. Interesting in our discussion is when big money fails to implement its purpose like for example Novell with SuSE in recent years: Too many cultural differencies, it failed. The Red Hats coming from our opensource community may well have learnt their lessons. It is pure nonsense for Redhat to pay a vote for kdbus inclusion. On the contrary in the course of events of evaluation they get the high quality Linux kernel they need for their success.

In this time of exponentially growth of the mobile market where all of the big players (Apple,Google,Microsoft etc) do have their IPC and their service managment, isn't it the last chance to play a role in emerging mobile prospects for Gnu-Linux companies to have kDbus/systemD? Though I must acknowledge your argument this is the chance to die as open source also ... Naib just had a say on this: Gpl version 3
_________________
fun2gen2
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Fri Jun 26, 2015 1:22 pm    Post subject: Reply with quote

ulenrich wrote:
... isn't it the last chance to play a role in emerging mobile prospects...


Emerging? The market has been around almost a decade and Linux already has the lion's share of it via Android. It's long past emerged and Linux has already proven that it doesn't need kdbus to be successful, regardless of whatever RH has to say about it.
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7006

PostPosted: Fri Jun 26, 2015 1:46 pm    Post subject: Reply with quote

ulenrich wrote:
It is pure nonsense for Redhat to pay a vote for kdbus inclusion. On the contrary in the course of events of evaluation they get the high quality Linux kernel they need for their success.

You are really naive :)
If any company could add a new molecule that would make customer addict to their product at first try, but kill them in 10 years, they will, it is better to have anyone trying it depend on it, even if it's only for 10 years.
Make big money, and we will see how to make even more 10 years later, but for now, just take the money.

A broken kernel is not at all bad, it is a support people will pay to fix it.
And if you are the one controlling dbus, it is to YOU that people will pay that support.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Sat Jun 27, 2015 12:18 pm    Post subject: Reply with quote

ulenrich wrote:
He did say he would like to have a better performing kdbus in the kernel.

steveL wrote:
He's already got TIPC. So kdbus is just pointless reinvention of the wheel,

ulenrich wrote:
Looking up the timelines of both projects dbus and tipc: Seems to me a parallel development.

Er, whut? TIPC was started in the mid 90s.

Pretty sure dbus was begun a lot later. So: no, not parallel development at all.
Quote:
If you look up the tipc roadmap 2015/16: open problems all over the place there also. Especially the ABI for C developers using TIPC is about to be redesigned? Reading about nodes and clusters: Isn't it a different domain they talking about?

Provide some urls if you want to discuss things.

Personally I'm glad they're open and transparent about what's happening. As for "a different domain" we're talking about using localnode only.

That it does more is nice, and could be used for LAN, but that's by-the-by atm. In any event it's not an issue; if anything it makes us feel better about using it, since it is a general-purpose transport tailored for the situation, rather than an attempt to be everything to everyone via hype.

I'm not going into the rest of it; I'm hard-placed to find any meaning in it. (I wouldn't rely on bitcoin either; that thing's a scam waiting to happen.)
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


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

PostPosted: Thu Jul 02, 2015 12:28 pm    Post subject: Reply with quote

Well, lookie here, this just landed in the lkml. :D
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Thu Jul 02, 2015 5:33 pm    Post subject: Reply with quote

Nice review, and clearly correct, from the reply.
Ingo Molnar wrote:
So there exists a technical vacuum: the kernel does not have any good, modern
IPC ABI at the moment that distros can rely on as a 'golden standard'.

Does no kernel developer even know about TIPC in linux?

Seriously, this is getting embarrassing.. they're maintaining the module ffs.
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Thu Jul 02, 2015 10:59 pm    Post subject: Reply with quote

steveL wrote:
Does no kernel developer even know about TIPC in linux?

Seriously, this is getting embarrassing.. they're maintaining the module ffs.


I don't know a lot about it, but can't somone from this thread mention it on the lkml?
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Fri Jul 03, 2015 5:49 pm    Post subject: Reply with quote

gwr wrote:
I don't know a lot about it, but can't somone from this thread mention it on the lkml?

Yeah anyone can; it was brought up in earlier discussion with the networking folks. Best overview post here.

We discussed the objections at the beginning of this thread, and I pulled out two posts here which are extracted from that overview, for ease of review.

I'm probably not thick-skinned or politic enough to post to lkml, though. Certainly, I'd have a hard time staying polite with GregK-H being waspish to me again, given what's happened in the intervening 3 years.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Tue Jul 07, 2015 7:13 am    Post subject: Reply with quote

Round n+1.

http://lkml.iu.edu/hypermail/linux/kernel/1507.0/02970.html
_________________
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
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 19, 20, 21 ... 25, 26, 27  Next
Page 20 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