Detecting exploding batteries, part 2
danny.kukawka at web.de
Mon Sep 25 11:11:48 PDT 2006
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
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.
More information about the hal