It Doesn't Look Like KDBUS Will Make It For Linux 4.1

[erendorn]

IPC should not be cross platform portable. Why would we want applications to be cross platform portable? I want people to use Linux and those that write applications for Linux to be able to easily leverage the capabilities of the Linux kernel.

As for the Unix philosophy, what was that? Make AT&T rich? Achieve corporate dominance through vendor lock in. The old Unix ecosystem was full of proprietary solutions, but sought to leach off the commons of publicly funded academia. The purpose of Linux is not to worship Unix but to bury it.

I don't really want to trade a walled garden for a different walled garden, thank you. Achieving *whatever* dominance through vendor lock-in is bad for the end-user, because of reduced reuse and reduced competition. It does not matter who does the lock-in or who ends up dominating.
Now, leveraging platform specific capabilities is good when it's done because they are useful, but doing it to segregate platforms is awful practice.

[Luke_Wolf]

The purpose of Linux is not to worship Unix but to bury it.

No... The purpose of Linux is to be a free hobby OS for 386 AT Clones. That it grew beyond it's purpose is typical for a software project to the point where there are many adages about it happening. Now you could say that Red Hat or SUSE's purpose is that, but not Linux itself.

From: [email protected] (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID: <[email protected]>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki

Hello everybody out there using minix –

I’m doing a (free) operating system (just a hobby, won’t be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I’d like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I’ll get something practical within a few months, and
I’d like to know what features most people would want. Any suggestions
are welcome, but I won’t promise I’ll implement them :-)

Linus ([email protected])

PS. Yes – it’s free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that’s all I have :-(.

[Rich Oliver]

First off - systemd is being handle improperly in general. Somehow an init package is making itself a requirement to run applications which should be cross platform portable - while systemd is linux-only, not portable and breaks *nix philosophy badly.

IPC should not be cross platform portable. Why would we want applications to be cross platform portable? I want people to use Linux and those that write applications for Linux to be able to easily leverage the capabilities of the Linux kernel.

As for the Unix philosophy, what was that? Make AT&T rich? Achieve corporate dominance through vendor lock in. The old Unix ecosystem was full of proprietary solutions, but sought to leach off the commons of publicly funded academia. The purpose of Linux is not to worship Unix but to bury it.

[gens]

No, it simply isn't. If I said you were wrong because you are a liar, that would be an ad hominem. But demonstrating that the evidence shows you were lying is not.


It is also much more difficult with things like containers. And you conveniently ignore that memfd was created for kdbus in the first place.


It is a benefit of kdbus over dbus.


None of the things that I listed were debunked, as I explained, but you ignored. Some people disagreed with some parts, until Havoc came along and explained why they were the way they were. But none of have been debunked, and some of the ones you claim were debunked were explicitly endorsed by Linus.

to get down to the same level:
No, you !

[TheBlackCat]

calling someone out as a liar = ad hominem

No, it simply isn't. If I said you were wrong because you are a liar, that would be an ad hominem. But demonstrating that the evidence shows you were lying is not.

"Wayland uses unix sockets for control data, and passes DRM or SHM file-descriptors for buffers. It is trivial to change this to use kdbus for control data."
passing drm or memfd is faster, more light weight with same security "level"

It is also much more difficult with things like containers. And you conveniently ignore that memfd was created for kdbus in the first place.

making kdbus with containers "slighty less awful" then dbus means that it is still awful

It is a benefit of kdbus over dbus.

for the rest; you read the thread again as you seem to have missed the things that weren't "debunked"
you know, the things that were written by people who don't want "dbus in kernel over anything else"

None of the things that I listed were debunked, as I explained, but you ignored. Some people disagreed with some parts, until Havoc came along and explained why they were the way they were. But none of have been debunked, and some of the ones you claim were debunked were explicitly endorsed by Linus.

[gens]

Learn what ad hominem means. Pointing out that you were lying about what they said is not an ad hominem. Whether you agree with their reasons or not, they still gave them, despite your repeated assertion that they didn't.


Please read the explanation in the thread. Currently dbus cannot guarantee passed buffers are not altered by the sender while being read. kdbus can.


*sigh* Again, please read the explanation in the thread. They give an example, "exit-on-idle", which cannot be done safely in userspace.


The fact that you don't want to use it doesn't make it "bullshit". Yeah, we got it, you don't like systemd. But until your magical systemd replacement is released, a lot of people are using systemd.


Simply false.




Yeah, great, lets have several completely different ways to do similar things. That is a great way to make software more reliable and less buggy.


No, it wasn't. There was a discussion about whether it was as easy as it could be, but it is still easier than what is currently the case with dbus.


Which was promptly addressed by the devs and ultimately shot down by Linus.


Who said anything about streaming video? https://plus.google.com/+gregkroahha...ts/bYZxmbNXAZX

calling someone out as a liar = ad hominem

"Wayland uses unix sockets for control data, and passes DRM or SHM file-descriptors for buffers. It is trivial to change this to use kdbus for control data."
passing drm or memfd is faster, more light weight with same security "level"
just because you *can* do something doesn't mean you should do it

making kdbus with containers "slighty less awful" then dbus means that it is still awful


for the rest; you read the thread again as you seem to have missed the things that weren't "debunked"
you know, the things that were written by people who don't want "dbus in kernel over anything else"

PS please use the numbering system as it makes reading more condensed and replying much easier, ty

[TheBlackCat]

well, i guess i can reply properly
just didn't expect this kind of stupidity and ad hominem this early in the morning

Learn what ad hominem means. Pointing out that you were lying about what they said is not an ad hominem. Whether you agree with their reasons or not, they still gave them, despite your repeated assertion that they didn't.

3. the protocol guarantees that; if the dbus programs memory space can be tampered with then you don't have security

Please read the explanation in the thread. Currently dbus cannot guarantee passed buffers are not altered by the sender while being read. kdbus can.

4. the protocol is asynchronous by itself

*sigh* Again, please read the explanation in the thread. They give an example, "exit-on-idle", which cannot be done safely in userspace.

5. not needed really, just bullshit talk by some devs (you know who)

The fact that you don't want to use it doesn't make it "bullshit". Yeah, we got it, you don't like systemd. But until your magical systemd replacement is released, a lot of people are using systemd.

6. it is too complex to serve as a basic anything, what you read is some other devs thinking of implementing a protocol that would be a basis for something like dbus

Simply false.

The binder developers at Samsung have stated that the implementation we have here works for their model as well, so I guess that is some kind of verification it's not entirely tied to D-Bus. They have plans on dropping the existing binder kernel code and using the kdbus code instead when it is merged.

7. apps that use dbus shouldn't use it for performance sensitive things, as 1. and 2. point out already (those apps should use ring-buffers or even AF_UNIX)

Yeah, great, lets have several completely different ways to do similar things. That is a great way to make software more reliable and less buggy.

8. that was rebutted on the mailing list by the creator of dbus himself

No, it wasn't. There was a discussion about whether it was as easy as it could be, but it is still easier than what is currently the case with dbus.

9. too much metadata sharing is something a couple devs brought up as a security hole

Which was promptly addressed by the devs and ultimately shot down by Linus.

maybe some quote from wayland devs about how great it would be to stream video over dbus ?

Who said anything about streaming video? https://plus.google.com/+gregkroahha...ts/bYZxmbNXAZX

Wayland uses unix sockets for control data, and passes DRM or SHM file-descriptors for buffers. It is trivial to change this to use kdbus for control data.

[gens]

7. apps that use dbus shouldn't use it for performance sensitive things, as 1. and 2. point out already (those apps should use ring-buffers or even AF_UNIX)

theblackcat, don't read the mailing list today
just a friendly advice

[gens]

You are a liar. Either you are lying about having read it, or lying about the justification. Either way, besides that the justification includes:

3. Security. The kernel guarantees that data and metadata are not tampered with.
4. Avoiding race conditions.
5. It is available much earlier during boot and much later during shutdown
6. It can serve as a more basic framework to build other IPC mechanisms on top of (for example Android's binder can use this behind-the-scenes).
7. Increased performance for existing applications.
8. Easier handling of containers.
9. More metadata.

As for 1 and 2, I am sure you know much more about this sort of thing than, say, the Wayland developers.

well, i guess i can reply properly
just didn't expect this kind of stupidity and ad hominem this early in the morning

3. the protocol guarantees that; if the dbus programs memory space can be tampered with then you don't have security
4. the protocol is asynchronous by itself
5. not needed really, just bullshit talk by some devs (you know who)
6. it is too complex to serve as a basic anything, what you read is some other devs thinking of implementing a protocol that would be a basis for something like dbus
7. apps that use dbus shouldn't use it for performance sensitive things, as 1. and 2. point out already (those apps should use ring-buffers or even AF_UNIX)
8. that was rebutted on the mailing list by the creator of dbus himself
9. too much metadata sharing is something a couple devs brought up as a security hole


anything else ?
maybe some quote from wayland devs about how great it would be to stream video over dbus ?
(the only example of streaming media over dbus GKH mentioned is PA, and that is a shit idea)

[gens]

You are a liar. Either you are lying about having read it, or lying about the justification. Either way, besides that the justification includes:

3. Security. The kernel guarantees that data and metadata are not tampered with.
4. Avoiding race conditions.
5. It is available much earlier during boot and much later during shutdown
6. It can serve as a more basic framework to build other IPC mechanisms on top of (for example Android's binder can use this behind-the-scenes).
7. Increased performance for existing applications.
8. Easier handling of containers.
9. More metadata.

As for 1 and 2, I am sure you know much more about this sort of thing than, say, the Wayland developers.

what's your problem ?