This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some o…
I am wondering if there are "Linux Insurgents", which are groups of people with a particular agenda that find small bits of data which can be made to serve their cause and expose them. Or maybe they just don't like DBus. Or maybe they just want to feel like they are having a larger debate. If it is any consolation, while I worked at Sun in the kernel group and later, this sort of 'cherry pick a message to start a deb…
“DBus is seriously screwed up”
151–160 of 209 posts
Re: “DBus is seriously screwed up”
#152Earlier quoted context omitted.
KDBus was designed with sandboxed applications in mind. So use-case wise think android-style "use the camera app to take a picture/video", where the camera app transfers the media to another app over kdbus, thus without leaking information about the system.
If the point is to have Android style IPC, why not just pull a version of Binder into the mainline kernel?
Re: “DBus is seriously screwed up”
#153Earlier quoted context omitted.
You do realize that pretty much whole of Windows is, underneath, based on COM, including most of the .Net-exposed system API's? I'll agree that COM and DCOM are... hairy, if you're implementing COM objects 'by hand'. But there's a reason for all of it, and I have yet to see an easier and more flexible way to write cross-language components. I could write a COM object in C++, call it from VBScript in a very simple com…
COM sort of works, on Windows, when when one or preferably both sides of the connecting components are made by Microsoft. You never see non-Microsoft code talking to non-Microsoft code from a different vendor via COM. This is not a successful component interface standard.
Again, I'll agree that it's not trivial to implement a COM object. You need good understanding of C(++), the Windows API, threading, and some more things. There are tools to make it easier (e.g. to write a COM object in Visual Basic) but they generally don't make for robust components. In the hands of a competent, experienced developer, COM is a massively powerful tool.
Re: “DBus is seriously screwed up”
#154This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some o…
https://wiki.maemo.org/Phone_control#Make_a_phone_call
Can improvements be made? Probably. Should they be? Why the hell not? Should clickbait headlines stop distracting us from real work? I only wish they would.
Re: “DBus is seriously screwed up”
#155Earlier quoted context omitted.
I am wondering if there are "Linux Insurgents", which are groups of people with a particular agenda that find small bits of data which can be made to serve their cause and expose them. Or maybe they just don't like DBus. Or maybe they just want to feel like they are having a larger debate. If it is any consolation, while I worked at Sun in the kernel group and later, this sort of 'cherry pick a message to start a deb…
I also wonder if the reverse happens, with people sabotaging the system by breaking things that work, making easy things harder, and replacing fast things with slower things.
Re: “DBus is seriously screwed up”
#156I can make two observations and hypotheses from the profiling results, which agree with Linus' conclusion of "bad user-level code": - Memory allocation/deallocation are taking the most time. - All the percentages for each function are very small. The former is a characteristic of code which heavily abuses dynamic allocation. It's surprising to see how many programmers are not aware of the overhead it adds and would m…
But, is excessive modularity really the culprit? Are you saying you read the code and found that to be the case, or it's just a hunch? Reading through the comments here, it seems that whatever one's personal hobby-horse happens to be is what will get the blame.
Re: “DBus is seriously screwed up”
#157Some form of notification publish/subscribe functionality is necessary in modern Linux. But dbus isn't very UNIX-y. It's also strangely opaque. With pipelines, you can see how the plumbing works. With dbus, programs can interact in nonobvious ways. Even worse is polkit, a poor replication of Windows Group Policy. The most unixy solution is buried at the bottom of this thread, from Plan 9: https://news.ycombinator.com…
This is what I call the "but muh unix" argument, beloved of neckbeards and often invoked against systemd as wellas kdbus.
Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Any inversion of this priority is a recipe for Microsoft to eat your lunch, as they did in the early 90s when Windows NT overtook commercial Unix in the enterprise space. (Monopoly schmonopoly: Windows was the better platform. It was easy to develop for and relatively uniform across desktop and server deployments.)
The Unix philosophy has proven inadequate to meet the needs of real-world software integration: what's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. D-bus provides that for Linux and no one so far has presented a better solution.
As for Plan 9... yes, that's what you get when you apply the Unix philosophy in the extreme. Note that the UX for Plan 9 sucks, and if you look at the Plan 9 developer community it's a) very small and b) packed with the pathologically neckbearded.
Re: “DBus is seriously screwed up”
#158This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some o…
Re: “DBus is seriously screwed up”
#159This whole pulling crap out of the Linux kernel mailing list is doing the industry a disservice. Quotes are taken out of context, used by people who lack the required technical understanding, which then reach the ears of managers, who will promptly act on overblown concerns. All of it somehow backed by Linus' word, even when he doesn't actually mean it. I've started a stopwatch to see how long it will take for some o…
So totally this; it's what I've said time and again. Is Linus abrasive? Yes, he can be. He usually has reason. But people seem to rarely read the whole thread, and even if they did, they are usually outsiders who lack both the technical chops to make valid criticisms, and they aren't familiar with Linus' management style. I for one count myself as one of the former as I've been outside of kernel land for quite some t…
Re: “DBus is seriously screwed up”
#160Some form of notification publish/subscribe functionality is necessary in modern Linux. But dbus isn't very UNIX-y. It's also strangely opaque. With pipelines, you can see how the plumbing works. With dbus, programs can interact in nonobvious ways. Even worse is polkit, a poor replication of Windows Group Policy. The most unixy solution is buried at the bottom of this thread, from Plan 9: https://news.ycombinator.com…
> But dbus isn't very UNIX-y. This is what I call the "but muh unix" argument, beloved of neckbeards and often invoked against systemd as wellas kdbus. Sorry to say, but "does this feature make application developers happy" trumps "muh unix" when considering whether to add something to the kernel. Any inversion of this priority is a recipe for Microsoft to eat your lunch, as they did in the early 90s when Windows NT…
Which application developers? A hell of a lot of developers are really really happy with "muh unix". Why should a bunch of hipsters with half baked ideas get to rob those developers of that happiness because pushing through half baked ideas makes them happy?