191–200 of 209 posts
The Linus profile is mostly a red herring here, because it is 1) a bad benchmark with a bunch of blocking round trips and 2) mostly profiling the gdbus bindings which are just one binding. For a more in-depth performance discussion of dbus, check out http://lists.freedesktop.org/archives/dbus/2012-March/015024... Above noted on linux-kernel here: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...
Linus is just being Linus. He's brusque, non-chalant. He's inflammatory to get people to listen. His thesis here is that bad DBus performance isn't due to context-switching overhead or buffer copies (which can be solved by moving the daemon into the kernel), but instead it's due to malloc-intensive / utf8-parsing-intensive marshalling. Secondly, he's saying that if performance is being used as an argument for kdbus,…
Sorry for going meta - I'm just a bit disappointed because your tone used to be the normal thing on HN, even when there were just as many disagreements. People were able to keep it friendly. Today not as much; I find HN has become too mainstream and "reddity", and the tone in general too emotional and aggressive, about who or what is right.
This wasn't unexpected, but still, it is good to see not everyone has moved into that direction.
Earlier 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 is indeed an interesting beast and very useful. Being able to integrate other programs into yours, relying on COM to do so is very helpful. I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). I once wrote something that processed a plethora of Word docum…
This is more of a ideological difference in how things should, and can, be done. For a long while, the only way to reliably edit Word documents was using Microsoft Word (half of it being undocumented, and half of it being documented as "this is supposed to do whatever Microsoft Office does"), so you effectively needed to embed Word within your program in order to reliably edit Word documents. A lot of that changed
In the open source world, there are canonical tools, but traditionally it's been about the format being open and accessible explicitly so you don't need to rely on/run a third-party program to do the manipulation, rather either roll your own manipulation routines following the documented standard (thereby strengthening the ecosystem with multiple implements, hopefully) or use a library (that the canonical tool may be based on/also use).
Both schemes have their advantages and disadvantages. It would be an interesting study in why/how the different ecosystems evolved to favor one over the other, how that has changed over time, and how that's influenced the size and robustness of the respective ecosystems. There's probably a lot of influence on the Windows/RPC side coming from the canonical tools being primarily interface GUI interfaces, which is then natural to want to "drive" or "control" remotely, vs "headless" interfaces that are able/meant to be scripted as a first order requirement.
Earlier 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. D-Bus is related to systemd (in that systemd relies on it), so this issue seems to have garnered a fair bit of spillover from t…
No doubt the spillover is real. Clearly highlights one of the challenges of Linux user land, I guess in the 'Bazaar' model this might be equivalent to trying to ban the selling of meat from endangered species amongst all the vendors.
but with systemd one vendor is "branching out", and offering (tightly) interconnected products.
And for a certain subset of customers, distro maintainers, this offer is tantalizing. Because it may make their life easier.
Or maybe to go back to the meat, it is not the kind of meat thats the problem. But that now you have one vendor selling whole meals.
And to stretch it a bit further, they are not selling it to the eater, but the chef.
Say you have a favorite restaurant, and when you sit down you can combine this meat with that potato etc.
But then one day you come in and you find the menu had changed to pre-set meal. Now if you want your favorite kind of meat you can only have it alongside a potato you barely tolerate (if not downright dislike).
This because the restaurant switched supplier to one that only sell pre-packaged meals rather than individual components.
Earlier quoted context omitted.
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.
I don't think it's fair to call systemd or dbus sabotage. It's entirely possible to construct explanations that rely on blinkered, tasteless incompetence, naivete, and personality cults rather than maliciousness.
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…
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…
Comparing a PPC (WinCE), iPhone1 and N900 with the similar hardware specs - there was no clear winner.
Earlier quoted context omitted.
No doubt the spillover is real. Clearly highlights one of the challenges of Linux user land, I guess in the 'Bazaar' model this might be equivalent to trying to ban the selling of meat from endangered species amongst all the vendors.
The bazaar works in the sense that each vendor stick to their product. but with systemd one vendor is "branching out", and offering (tightly) interconnected products. And for a certain subset of customers, distro maintainers, this offer is tantalizing. Because it may make their life easier. Or maybe to go back to the meat, it is not the kind of meat thats the problem. But that now you have one vendor selling whole me…
Earlier quoted context omitted.
> 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…
The Unix philosophy has proven inadequate to meet the needs of real-world software integration I'm assuming that's why it's so trendy to talk about "microservices" these days. What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. The Unix philosophy doesn't say anything against implementing service discovery mechanisms.…
It's less about service discovery mechanisms per se. It's more about using objects communicating via APIs as units of composition, rather than processes communicating via data (usually text) streams. The object-based approach hews closely to how programmers actually think, makes protocol specification as easy as declaring a method (and checked by the compiler!), and enables much more sophisticated interaction between components. See Miguel de Icaza's essay "Let's Make Unix Not Suck" for an in-depth look at how the COM model improves on Unix philosophy for software integration: http://baizid.org/literature/bongo-bong.html
Earlier quoted context omitted.
The Unix philosophy has proven inadequate to meet the needs of real-world software integration I'm assuming that's why it's so trendy to talk about "microservices" these days. What's needed is the COM philosophy, wherein services register themselves under globally named endpoints and present typed structured discoverable APIs. The Unix philosophy doesn't say anything against implementing service discovery mechanisms.…
The Unix philosophy doesn't say anything against implementing service discovery mechanisms. It's less about service discovery mechanisms per se. It's more about using objects communicating via APIs as units of composition, rather than processes communicating via data (usually text) streams. The object-based approach hews closely to how programmers actually think, makes protocol specification as easy as declaring a me…
[1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.7...
Earlier quoted context omitted.
So what's the use case for sending large packets of data over dbus where the performance gains warrant integrating the dbus server to the kernel? Are they planning to migrate the X server to dbus?
X is going to be migrated into the recycling bin. Lennart wants to migrate PA to dbus, and the possibility exists for doing the same for some future version of Wayland.
"Wayland does not currently provide network transparency, but it may in the future. It was attempted as a Google Summer of Code project in 2011, but was not successful. Adam Jackson has envisioned providing remote access to a Wayland application by either 'pixel-scraping' (like VNC) or getting it to send a "rendering command stream" across the network (as in RDP, SPICE or X11). As of early 2013, Høgsberg is experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor."
[1] https://en.wikipedia.org/wiki/Wayland_%28display_server_prot...