Hello everybody, I've sought help for getting bluetooth to work on my Gentoo box on irc and was helped, thank you JHE at this point. However, I've also realized that bluez has apparently stripped the user of any sort of useful configuration and documentation thereof. Now, I wouldn't usually care if some random program does that, I'd simply stop using it and look for an alternative, but bluez surely is not just another random program and instead integral part of linux. I was told it was after bluez 3.x that hcid.conf et al were removed in favor of an untransparent, undocumented and obscure configuration through dbus (latter I've not been told but claim by myself). I can't help it but wonder what has driven such bizarre decision to allow a fundamental component of linux no longer to be configured through configuration files. I take it certain people found it incredibly "elegant" and "progressive" to use dbus for everything they could possibly think of. Well, DBUS has its use and advantages which we are aware of, but using DBUS to write "Hello world" to the console or, in this case, making fundamental configuration, is no advantage and simply an unpractical obstacle. A user is looking forward to using the functionality of the linux bluetooth stack, bluez. So he install bluez and wants to configure it, like everything else on his system is configured. But no, not BlueZ! BlueZ is "advanced". BlueZ won't allow that. First of all, user, you will have to install DBUS, because BlueZ cannot be configured without a Desktop-Bus. Once you got DBUS, you still cannot configure BlueZ, because DBUS has no means for configuration, least of all has it ever been intended to maintain configuration. So next you will have to install our special front-ends to DBUS, which use a dedicated protocol to communicate the configuration. By now, the user asks himself "Why can I not just write that bloody config file like I always do?". Well, BlueZ knows better than you, what's best for you. So please, install the frontends, dear user... So the user installs two python scripts, but hold on, we need a python DBUS library for that. More installs ensue... Eventually, after an hour of endless compiles, configuration of DBUS, getting to know the python scripts, etc. pp., the user is finally ready to start configuring DBUS. "I could have written that config twice in that time, and would actually have had a clue what I configured", thinks the user. But BlueZ doesn't think so. BlueZ knows convenience, and it will rub it into the user's face, whether he wants it or not. Are we done? The user successfully configured BlueZ, paired his devices with the Python scripts. Although the user appreciates how bitterly elegant BlueZ' approach as configuration is, installing all of X.org just to get the GUI frontends working was a little too much for him to accept. Especially since he never wanted a frontend anyway. But BlueZ wanted it, so he did. Three months later, the user already forgot about the hassle he had with BlueZ' sadistic convenience and is happily using his bluetooth keyboard. Sadly, he has to re-setup his box. LUCKILY, Linux is configured through configuration files. So he backs up his configuration files, but wait, BlueZ! No, BlueZ is better than that. BlueZ cannot be backed up, because BlueZ is ELEGANT. BlueZ is configured through DBUS, did you forget? Actually he had, just as he had forgotten about how to set it up. Here we go again, "how convenient" thinks the user. And all so elegant. This should be an appeal to you to perhaps re-evaluate that design choise, for that user is not alone. I am that user. So are others. BlueZ' obsession with DBUS and obscuring things from the user, allegedly for the user's sake, are actually a self-centered attempt at being advanced, disregarding practicability and conformity. regards, a user (ManDay) -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
