Detecting exploding batteries, part 2

[David Zeuthen]

On Mon, 2006-09-25 at 20:11 +0200, Danny Kukawka wrote:
> 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.

I'm not suggesting that.

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

You're falling into the good old "root is almighty" and "non-root has no
privileges" trap. Please see the PolicyKit discussions about why such a
point of view is useless. See also recent work in SELinux / AppArmor for
similar discussions.

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

<flame>
I'll leave others to comment why yast / linuxconf / system-config-* /
whatever is pretty bad in 2006. If you don't believe me, here's a pretty
interesting analysis

 https://www.redhat.com/archives/fedora-devel-list/2006-September/msg00034.html

I'll also note that it's useless to anyone but SUSE users that smartd
and yast play well together. Sure, yast is open source but it's a
nightmare to port to other OS'es because of all the assumptions you
make. Plus lots of users don't like the approach of yast. They do seem
to like the approach of HAL, offering powerful interfaces etc. etc.

What you seem to consistently forget is that it's better (and often,
surprisingly, easier) to solve things upstream than let every distro and
their mother solve this problem. Sure, SUSE might loose out here because
you've guys already solved this well with yast. Well, sorry, it
shouldn't hold us back either to solve the problem in a distro- and
OS-neutral way. Remember that if an interface is not available in a
distro- or OS-neutral ways there are little chance that you'll write a
successful desktop app that uses it.

This is off-topic on the HAL list. Reply to me personally if you (or
anyone else) need to flame back.
</flame>

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

No-one is proposing a single daemon. 

I'm basically just proposing that perhaps smartd could install hooks to
start instances of itself as hal addon's and export a few things via HAL
properties / methods / signals. If you want smartd without these
newfangled things you simple build it without these hooks.

That's why it's important to freeze some interfaces so 3rd party like
NUT (already happening) and smartd (yet to happen) can integrate with
HAL.

What's on earth is wrong with that?

     David