KDBUS & Systemd Now Yields A Working System

[GreatEmerald]

Wow, this thread has been so derailed it's in the woods somewhere.

Anyway, good job, systemd developers. More features for D-BUS is always good. I hope that will also make some of the D-BUS related problems I tend to run into every now and then go away.

I don't really get the point of sandboxed software, though. The current regular program rights seem to be good enough as it is. Though I'm not using GNOME, so I'm not sure what issues they're facing on their side...

[Delgarde]

I know, Im drunk posting. Its fun. I messed my response all up. See above.

This explains so much about this thread...

[darkbasic]

Please don't waste developers' time: don't feed the troll.

[jonnor]

Kdbus was in fact a student project, it was not written from scratch by the kernel team. Sorry to tell you this but D-Bus might be the most widely installed IPC but its the least used IPC in linux. ZeroMQ and Google Protobuf might not have all the features of D-Bus but most of those advanced features are rarely even used even in D-Bus. And
D-Bus doesn't even come close to ZeroMQ is usage share not even close.

Even when comparing D-Bus vs ZeroMQ in the IPC arena for every one D-Bus Desktop application there is 1000+ ZeroMQ network applications using its native IPC there.

Today D-Bus and ZeroMQ not used for the same things, D-Bus being primarily for communicaing within a single node (often between lesser and higher privileged services) and ZeroMQ typically used for communicating between nodes (and typically unprivileged services). Are you arguing that ZeroMQ would be a better fit than kdbus for creating a secure IPC for sandboxing applications et.c.?

Btw, I urge you to remove the dbus daemon and libraries, to see how much of the system can be used afterwards.

[balouba]

That isn't a very useful comment since kernel developers have explained precisely how it does improve security and I have already linked to that

https://lwn.net/Articles/551969/

the article is pretty bad and this is still misunderstood. moving such code into the kernel exposes more kernel surface to attackers. When you exploit the kernel, you win. its better than root. generally you can disable selinux and what not.

the reason for kdbus is really just a random one because its tied to systemd and the author has influence. all his creations so far were highly criticized because none where the right thing to do, but he had the agenda and power to push them through.

[Teho]

PROOF!!!!!!! First off Whats your first and last name, and do you have any screenshot of your projects that you can share with the forum?????

What does that matter? I don't claim to be some key KDE developer without posting any proof of anything. I have never seen your name mentioned in planet.kde.org. I can't find any commits by your nick or real name from ohloh.net or kde.org. You seem to think that people have any respect for you, that your arguments have _any_ value without you actually posting some evidence for them. You once claimed you helped with Hawaii project, guess what? According to github there's no commits from on that project. You once claimed you had worked on Ogre3D, I don't see any commits from you. The claim that you have been some "major" influence in KDE4/Qt5 developement is absolutely ridiculous and guess what, I can't find anything anywhere pointing in that direction.

You seem delusional about your importance.

[ChrisXY]

Everything is sooo clean, and every library and tool is well maintained, by its original maintainers. No more long waits to get
simple bugs fixed, no licensing conflicts.

We in-vision an ecosystem where "Open Source" and "Proprietary" software work's together, in an effort to build the best possible platform for current and future generation's of users.

How do you expect to not have long waits to get simple bugs in proprietary software fixed?

I never completed this application unfortunately.

I remember seeing this "LiquidPixel" program when you advertised it the last time here. Would have been interesting if it was a real application...

[RahulSundaram]

I don't really get the point of sandboxed software, though. The current regular program rights seem to be good enough as it is. Though I'm not using GNOME, so I'm not sure what issues they're facing on their side...

https://lwn.net/Articles/562138/

[GreatEmerald]

https://lwn.net/Articles/562138/

I still don't see a point. This seems to be geared towards something similar to mobile apps, which are small and crappy. If the author/s care enough about their work, they will work with packagers and get their programs included in distros. If they don't, then it's not worth the users' attention, either (and if they really want to, then users can manually compile it). This support for such sandboxed apps sounds like pandering to lazy coders.

[RahulSundaram]

I still don't see a point. This seems to be geared towards something similar to mobile apps, which are small and crappy. If the author/s care enough about their work, they will work with packagers and get their programs included in distros. If they don't, then it's not worth the users' attention, either (and if they really want to, then users can manually compile it). This support for such sandboxed apps sounds like pandering to lazy coders.

There are plenty of use cases you are apparently not considering.

Mobile apps are small and crappy? It is amoung the fastest growing software businesses and plenty of apps are amazingly well done compared to Linux desktop apps. Also what about ISV's? What about software that doesn't fit the licensing regulations of distros? What about bleeding edge development snapshots? Those are just a few examples.