Detecting exploding batteries, part 2

[Danny Kukawka]

On Monday 25 September 2006 18:38, David Zeuthen wrote:
> On Mon, 2006-09-25 at 14:15 +0200, Danny Kukawka wrote:
[...]
> So I see us either
>
>  1. talking to the smartd people about HAL integration (make smartd a
>     hal addon) - shouldn't be much work

I don't want to see become smartd a HAL addon (as e.g. hald-addon-acpi). IMO 
it would make, if really needed - and I'm not sure about that, much more 
sense to simply add some code to smartd which set - if there are problems - a 
key in HAL or use a message interface in HAL to show information to the user.

>  2. or use just call into smartd ourselves via the tools they provide
>
> Last time I looked smartd suffered from the same symptoms that other
> user space low-level software / driver software suffers from:

Yes I know you think this kind of software is to 'unixy' but this software has 
a strong right to exist. The concept to have a small piece of software for 
special task is not bad per se.

>  - typically they require the admin to write out configuration files.
>    It gets funny when things like the installer, yast, system-config-*
>    whatever tries to do this.

And there are reasons why you need to be a admin to change this configs. There 
are not only single-user systems. In the most cases you don't want to allow a 
user to change them. For me this is the concept of a real root user/admin one 
of the big default advantages of Linux systems. 

What funny things? Yast e.g. work with this task really well and is a great 
tool.

Btw. I know we have different views about that, but IMO it's not always the 
best idea to put everything in one daemon as e.g. HAL because this kind of 
software grow easy to a "unmaintainable" piece of software. 


Cheers,
Danny