Recently I installed a ARCH system and came to a similar issue that I have found before and wondered who exactly over at xorg thought this particular match was a good idea. I of course am refering to the good old problem of xorg devs thinking everyone uses dbus and hal these days.

For those lost in my words above let me explain. You see when you first get xorg on a system, well it don't like to play nice. Actually it does something very very bad IMHO. If you do not add a line in the xorg.conf file under Serverflags that says AllowEmptyImput "False" then xorg will start and leave you without keyboard or mouse support. So you have to literally turn the computer off. Who over at xorg thought this was a good idea? Why is it not set by default (esp if it cannot find dbus or hal on the system) to allow empty imput?

This really brings me to my second point here and that is do we really need dbus and hal. The really funny question is that back before dbus and hal linux could do everything that dbus and hal do. The only thing that I know dbus is good for is mounting external drives automatically and detecting input devices. But both of these can be accomplished without using dbus or hal. I have no issues doing either of these and I do not have either one installed. They have almost just become a unnecessary requirement for some programs that got along fine without them for years.

Back in the day when dbus was new I dare say that I was excited to see it come as it looked like it would solve alot of problems. But looking at it today I have to conclude that it just causes more problems, uses up resources, and can be a potential security risk.

I really think there needs to be a better more simpler solution as the value add of these systems are lost in the ether, or people just simply find ways to work around them.

I welcome your input if you have constructive input.

The purpose of D-Bus and HAL is automatic hardware detection. Yes, I know where you are coming from, having used Linux since Torvalds announced it in comp.minix and UNIX for a long time before Fall of 91, but I can't agree with you in earnest. Automatic hardware detection and autoconfiguration are worthwhile goals and that's what D-Bus and HAL provide.

Now, I can't disagree with you if you are complaining about HAL. It was a prototype and it is Fedora and Ubuntu's fault that it became a standard before its time. The real implementation, namely, udisk, upower and libudev are far, far better at solving the problem of publishing kernel runtime hardware detection to user space. Now, D-Bus is a different kettle of fish. As far as RPC implementations go, it is one of the cleanest and less mad things around. CORBA is a horrid hack and Sun RPC (still used in NFS) is as flaky as it can get. (And don't get me started in such abominations such as ToolTalk, the sure fire way to get your Sun Workstation owned, meh!).

Now, we have to wait (I'm frying other kettle of fish) for the X developers to get their act together and reimplement their HAL hacks using the libudev API and we will be all happy campers.

You say that Linux could do all these things before HAL and dbus, but to be honest it couldn't - it was a pain in the ass. When I first started using Linux it was RedHat 7, and configuring XFree86 was a major, major nightmare. Nothing Just Worked. All that crap has now gone - Xorg doesn't even need an xorg.conf file any more. With dbus memory sticks can be auto-mounted, when I plug a bluetooth adapter in I can tether to my mobile with no hassle, when I plug a monitor into my laptop I can flip between screens with the click of a mouse.

All the old problems with the Linux Desktop have been solved with dbus, udev, XRandR and (dare I say it) PulseAudio. HAL was a crap stop-gap, so I'll give you that, fortunately it's going away - Fedora have completely removed it in F13. To be perfectly honest, I used to think all this stuff was a waste of time. I used to compile my own kernels and glibc as well, though.

Give in to the dark side. Run dbus. Remove your xorg.conf. You know you want to.

Dave

One of the biggest problems I have with dbus really is developer of other apps that use it for no reason. There have been many times where adding dbus support is an option to a program, but its never real clear on why its needed or why the option is even there. You can compile the program without it and it works just fine. I just wish devs would not just add it just to add it. Im happy to see that some projects have shied away from it instead of just putting into there program simply for the grounds of saying "well it uses dbus so its gotta be great". Seams back in the day people added it to there project just because it was cool and new.

I do agree on your point that as of this moment there is nothing that does what dbus does thats better, and most of the time it does what its supposed to without issues.

No I don't want to... Dbus goes full retard on me with a synapics touch pad, and its way easier for me to uncomment a few lines in xorg.conf then for me to compose a horrible xml document.

If you want to use the old mouse/keyboard/synaptics drivers rather than work with the evdev driver that uses D-Bus, you can add the options "AllowEmptyInput false" and "AutoAddDevices false" to the serverflags section of your xorg.conf file and configure everything by hand.