"Both of these articles allude to the fact that I'm working on putting the D-Bus protocol into the kernel, in order to help achieve these larger goals of proper IPC for applications. And I'd like to confirm that yes, this is true, but it's not going to be D-Bus like you know it today. Our goal (and I use 'goal' in a very rough term, I have 8 pages of scribbled notes describing what we want to try to implement here), is to provide a reliable multicast and point-to-point messaging system for the kernel, that will work quickly and securely. On top of this kernel feature, we will try to provide a 'libdbus' interface that allows existing D-Bus users to work without ever knowing the D-Bus daemon was replaced on their system."
To read all comments associated with this story, please click here.
Member since:2011-01-28
butters,
Well, first of all let me state that I do share your enthusiasm for moving this sort of IPC into the kernel.
"In the beginning, there was select and poll. Then there was epoll. But their days may be numbered. It should be obvious that the socket is the one true UNIX abstraction for IPC."
I'm not sure if you meant exactly what you said here, but select/poll/epoll are complimentary mechanisms for using sockets, sockets don't supersede them. I've found that epoll is by far the most efficient way to handle many asynchronous sockets.
"This is the way it was always meant to be. We fork a bunch of small processes, each of which does one thing well, and hook them all together with read() and write()."
It's true that multi-process blocking IO is the traditional unix way, and some people prefer that way of programming. But a big reason for phasing it out is because it scales very inefficiently compared to multi-threaded and async models.
As a popular example, take a look at the scalability differences for a traditional multi-process web server (apache MPM) versus modern asynchronous ones:
http://whisperdale.net/11-nginx-vs-cherokee-vs-apache-vs-lighttpd.h...
Member since:2005-07-08
I should have said "execution units" instead of processes. Obviously multithreading is an improvement over multiprocessing, and multiplexing coroutines on a non-blocking thread pool is an improvement over multithreading.
But an in-kernel message bus would still ease the implementation and accelerate the performance of a modern concurrent runtime platform such as Go, whose channel type would map nicely to AF_BUS.
Member since:2009-05-19
As a popular example, take a look at the scalability differences for a traditional multi-process web server (apache MPM) versus modern asynchronous ones:
http://whisperdale.net/11-nginx-vs-cherokee-vs-apache-vs-lighttpd.h...
Quite a common mistake. Comparing async performance to performance of Apache. Those don't highlight the differences in scalability of non-blocking IO, but demonstrate that Apache is big.
At an event earlier today, Microsoft unveiled the next Xbox - the third model, but confusingly named Xbox One. The big focus was TV, integrated Kinect, and all the other stuff we all expected to be forced down our throats. I think it took them 25 minutes to actually come to what should be the core of the story: gaming. Nothing groundbreaking in the gaming department, except for how Microsoft intends to handle the used games market and borrowing games from friends: pay up, buddy!
The day has finally come! Jolla has finally announced the launch device for its Sailfish operating system - and by god this is a looker. It's decidedly different from other phones out there, but it has good specifications and carries a relatively reasonably price tag - EUR 399, and it's up for pre-order today, shipping in the fourth quarter of this year.
Why does Google get so much credit in the technology industry? Why, despite the company's many obvious failings, do many geeks and enthusiasts still hold a somewhat positive view on the all-knowing technology giant? A specific talk at Google I/O this week provides the answer.
OSNews is a sponsor of this year's O'Reilly OSCON in Portland, Oregon, USA. A lucky OSNews reader will win a free three-day pass, including two tutorials days. To win the pass, post a comment on this story saying something about Open Source Software or OSCON. We'll pick a winner at random next week. If you don't have an OSNews account, you may email us your entry. Part of the conference is the 9th annual Open Source Awards, and today the 16th is the deadline for nominations. If you'd like to nominate an outstanding open source contributor, do it here. Read on for more information about OSCON. Update: The 20% discount code for OSNews readers is "OSN."
"Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
This is one of those news items that's fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It's all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products - which have Haiku and TuneTracker pre-installed.
Exactly twenty years ago, a document was published that played a huge role in establishing the web as we know it today. Twenty years later, and this simple and straightforward document is proof of an irrefutable fact: while closed technologies can change markets, open technologies can change the world.Oh multitasking. That staple of computing that got thrown out the window with many modern smartphones. We got some rudimentary thing in its place - but even as multitasking on phone and tablets improves, its user-visible side remains cumbersome. Windows 8 has a neat implementation, and now it's time Android follows in it footsteps.They're here! Whether that excites you or not remains to be seen, but the Galaxy S4, which will most likely become the best selling Android smartphone of the year by a huge margin, has been reviewed by all the major sites, and there's lots of interesting conclusions in there - although I think most of you will get the gist.Nokia has posted its quarterly results for the first quarter of 2013, and just like the quarters that came before, there's not a whole lot of good news in there. The rise in Lumia sales still can't even dream of making up for the sales drop in Symbian phones, and when broken down in versions, the sales figures for Windows Phone 8 Lumias in particular are very disappointing. In North America, Nokia is getting slaughtered.
Member since:
2005-07-08
A real pub-sub multicast socket implementation in the kernel. This has been at the top of my feature wish list for a long time. Obviously D-Bus will be the first client, but libevent would be next, and then the Wayland devs are beginning to rethink their IPC protocol.
In the beginning, there was select and poll. Then there was epoll. But their days may be numbered. It should be obvious that the socket is the one true UNIX abstraction for IPC. This is the way it was always meant to be. We fork a bunch of small processes, each of which does one thing well, and hook them all together with read() and write().
But we need more flexibility in how we compose networks of communicating processes. We can't do everything with pipelines and the client-server pattern. Even a microkernel purist would agree that IPC should be provided by a point-to-point message bus in the kernel. Anything else we might want can be built on top.