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

[Zeerak Waseem]

On Thu, 11 Feb 2010 09:05:46 +0100, Alan McKinnon  
<alan.mckinnon@×××××.com> wrote:

> 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.
>
>

True, but even those using Openbox, icewm, etc. were introduced to the  
mess that HAL is, and also to dbus. Sure you can choose not to have  
hal/dbus/*kit, but then you also choose not to use a growing number of  
apps that seem to depend on it. The way I see it, they should be optional  
features. If you've got the useflags set, great. If not, then it'll still  
be able to compile and run.

-- 
Zeerak