Re: [gentoo-user] How the HAL are you supposed to use these files?

[Alan McKinnon]

On Thursday 11 February 2010 09:31:21 Walter Dnes wrote:
> On Wed, Feb 10, 2010 at 02:18:43PM +0000, Neil Bothwick wrote
>
> > On Wed, 10 Feb 2010 07:57:57 -0500, Walter Dnes wrote:
> > > > but D-Bus provides a standard way for applications to communicate
> > > > with one another and removing it can stop your desktop working as
> > > > it should.
> > > >
> > >   Then how did things manage to work on my systems for the past 9
> > >   years,
> > >
> > > pray tell?
> >
> > Because nine years ago, Linux desktop  software didn't use interprocess
> > communication. Of course things will still work, but not necessarily
> > everything. For example, Network Manager uses D-Bus to tell programs when
> > your Internet connection is available and not, so your mail client goes
> > into offline mode rather than pointlessly trying to access your mailbox.
> > KDE4 uses it quite extensively, ust as KDE3 used DCOP.
>
>   There is too much solution-in-search-of-a-problem here.  XMMS followed
> the original Unix philosophy... it did one thing did it right, namely
> playing audio.  Unfortunately, XMMS was hard-coded to use a now obsolete
> GTK library.

Unfortunately, that's analogous to a business employing 5 people, all of whom 
do their own thing all the time with no inter-person communication and no co-
ordination. Perhaps they might scribble a note on a white board once a day, 
but that's about it.

>   The "successor" to XMMS is Audacious.  It seems to subscribe to the
> Microsoft philosophy, and tries to do everything under the sun, and
> pretends it's a server, which requires dbus.  Is it *REALLY* necessary?
> I used XMMS to play mp3's and Live365.com.  I ended up switching to
> mpg123 for both functions when XMMS was dropped, and then to the Flash
> player for Live365.  I emerged Audacious, but unmerged it when I saw the
> post-install warning that said not to submit any Audacious bug reports
> if I don't have dbus installed.

Modern desktops are integrated, because that's what users want. Any two apps 
should be able to inter-communicate wherever that communication makes sense.

Example: You have any old arbitrary email client. A mail contains a URL. Click 
it. The URL should open in your preferred browser, whatever that should be. 
Please note that any email client should support launching any browser, 
whether the dev built in support for it or not. Yes, I know there are the xdg* 
scripts, but tally up the number of things a user would want to work like 
this, tally up the number of scripts in the infinite number of locations this 
will take, and then ask the user to "pick one".

Example: Notifications. I have 3 (yes, three!!) kinds of popups that show up 
here daily. There's KDE's system which is the majority of them, some GTK apps 
throw popups in the top right corner where I don't want them and them then 
there's Skype which does it's own thing. God, you gotta love proprietary 
sekrit apps </sarcasm>. The solution is a notification service, apps send 
their notifications to it and the service does whatever the user configured it 
to do with the notification. Note that the user is in control here, the user 
says what happens with popups and does it in one central place and the apps 
does one thing and one thing only with it's notifications: sends them. It's 
like syslogger, letting the app concentrate on it's real purpose (which is not 
logging, and definitely is not making sure it doesn't clobber log files from 
any other apps that might be running).

See where this is going? Do you need a hundred more examples?

When you have arbitrary, unknown (at install time) sources of data that may 
interoperate with other arbitrary, unknown (at install time) sinks of data, 
good data modelling says that a known broker of data should sit in the middle, 
which is generic enough for anything to be able to use it. 

And the transport for that is dbus.

Just to bring this back to your original statement of Unix philosophy. IPC on 
modern desktops conforms exactly to the Unix philosophy. Apps were moving away 
from that and were becoming IM clients cum custom loggers cum notifiers cum 
<insert any other crap here>.

Standardized IPC is moving back TOWARDS the Unix philosophy, not away from it. 
Apps can now concentrate on their core function, and hand over the integration 
aspects to something else dedicated to IPC and nothing else. The apps now 
merely does the minimum required to hand over data to the service via a 
messaging bus.

Which if you look at it in that light, is EXACTLY the same rationale as a 
syslogger. Do you use a syslogger? Why?

If you don;t like all this integration stuff, and you have every right to not 
like it, then you should uninstall KDE and use Openbox (or similar lightweight 
WM). These WMs exist for users that do not want desktop integration. One thing 
you cannot have is the latest KDE without it's integration features.


-- 
alan dot mckinnon at gmail dot com