Lack of configuration

Lack of configuration

[manday]

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)

Re: Lack of configuration

[Gustavo Padovan]

Hi,

* manday@gmx.net <manday@gmx.net> [2011-11-03 20:49:00 +0100]:

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

DBus is a must-have for any desktop system these days. And you don't really
need to reconfigure it to have it working.
A lot of application relies on DBus today to do their IPC. You are probably
getting DBus wrong, it is better than you think

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

Seriously what do you wanna configure here? BlueZ is meant to work out of the
box and no configuration is needed. As Johan said on IRC it should just works
for 99% of the users.
The only thing we are lacking today is a proper command line tool for BlueZ to
replace our python scripts.

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

The data you are talking about is at /var/lib/bluetooth. BlueZ keeps there the
information of paired devices.

	Gustavo

Re: Lack of configuration

[Simon Kenyon]

On 04/11/2011 01:20, Gustavo Padovan wrote:
> The data you are talking about is at /var/lib/bluetooth. BlueZ keeps there the
> information of paired devices.

is that documented anywhere?


-- 
simon

Re: Lack of configuration

[Anderson Lizardo]

Hi,

On Fri, Nov 4, 2011 at 5:03 AM, Simon Kenyon <simon@koala.ie> wrote:
> On 04/11/2011 01:20, Gustavo Padovan wrote:
>>
>> The data you are talking about is at /var/lib/bluetooth. BlueZ keeps there
>> the
>> information of paired devices.
>
> is that documented anywhere?

At least on my system (Ubuntu), "man bluetoothd" shows information
about some files in /var/lib/bluetooth. It is not complete.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: Lack of configuration

[Marcel Holtmann]

Hi,

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

actually the D-Bus interfaces are fully documented and come with example
command line scripts in Python.

And also /etc/bluetooth/main.conf has all configuration option
documented.

So please start looking into it first before making any accusations
here. If you wanna keep using BlueZ 3.x, you still can. Nobody is
forcing anybody to upgrade.

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

If you wanna be stuck in the 90ties, be my guest, but BlueZ has moved
on.

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

Stop whining about BlueZ using D-Bus as IPC. It is the default for
almost every single Linux service these days. Even systemd relies on
D-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.

Good that you fully understand how Bluetooth pairing works and what
needs to be done to do it. If you do not trust bluetoothd, then please
don't use it. Feel free to implement your own one. And if you install a
UI frontend for pairing purposes where BlueZ ships with a simple C
example for doing this, then you clearly got lost again.

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

Yes, it is super elegant, because it can be backed up. BlueZ
configuration is persistent. It is that smart.

As other pointed out all configuration is stored in really simple text
files under /var/lib/bluetooth where everybody would look first that
have a clue on a Linux filesystem hierarchy is build.

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

Feel free to improve it. Patches for D-Bus command line utilities
written in C are always welcome. You do not need Python or any kind of
UI to configure BlueZ. But do me favor and stop your non-sense of trying
to do pairing via configuration files. That is not how that whole
mechanism used to work or will ever work in the future.

Regards

Marcel