[Slackbuilds-users] Slackware and Plug'n'Play for removable devices

[Robby Workman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Niki Kovacs wrote:

> Currently, I chose a Slackware fork named KateOS, developed by a small 
> team of polish developers. It's XFCE-focused, it uses a 2.6 kernel only, 
> it includes all the things that I miss in Slack, like dbus, hal, gamin, 
> pmount, ... to make plug'n'play just work... although even this needed 
> some manual readjustment. On the other hand, it's not as rock-solid as 
> Slack. For example, it uses a rather recent version of X11... which 
> crashes on older hardware, while Slackware's X version remains stable.


I'd be interested to see some more details on those crashes, and I'm
guessing the xorg devs would be interested as well.  :)


> I've tried to build a working dbus/hal for Slack 11.0 and... well... I 
> didn't fail, I didn't succeed. I know the various problems related to 
> using HAL, you have to build it against 2.6 headers, and you can only 
> use up to 0.5.7.1, because versions after that require PAM, etcetera 
> etcetera.
> 
> My question to you on the list: if someone has a *working* HAL - by 
> working I mean: which builds out of the box on a stock 11.0 Slack 
> install - would it be possible to publish it on SlackBuilds.org? 
> Eventually with a BIGFATWARNING.readme file? Sadly, the impossibility of 
> handling removable devices automagically was a showstopper in using 
> Slack... the only showstopper on the list. All the other things I could 
> handle... even the missing base GNOME libs.
> 
> Any suggestions for this?


Well, from a personal standpoint (not necessarily speaking for the SBo
project as a whole), I wouldn't mind seeing a HAL build script at SBo,
and even if it's not feasible to get something acceptable under the
project guidelines, I'd be more than happy to refer people to a known
good script (unofficially, of course - not endorsed by SBo).

A better solution, IMHO, and be advised that this might be approaching
a <rant> warning, would involve some people who have the necessary
skills working with the HAL developers to implement shadow auth in
the PolicyKit backend.  The lead developer of HAL more or less stated
that he was open to such changes, but it wouldn't be a priority for
him.  That's completely understandable, IMHO - developers tend to work
on things that interest them personally.
In the long-term, some of these talented guys who are "forking" Slack
into various directions would be better served by addressing the
underlying causes of Slackware not going in the direction they would
would like it to go.  By eliminating the hard necessity of PAM to
include HAL, it would be a much easier decision to go for HAL in the
official Slackware package set.  Of course, I'm not at all claiming to
speak for Pat on this, as this is just my take on the matter, but it
would certainly be one less hurdle to overcome.  The downside, of
course, at least from the perspective of the "fork" maintainers, is
that much of their reason for existence might be gone.  I guess, in
that respect, it would depend entirely upon their goals.  As I've
stated publicly on more than one occasion: the work that I do is
geared toward helping improve Slackware, so if I have to decide
between staying true to the goals of Slackware or forking, well, it's
an easy decision for me.   :-)

RW

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)

iD8DBQFF161w7QPvQNDlLwQRAroiAJ9yqlsRVWwKTfKNsZJIgFOqHuxbHACgmFBr
WulGbiUSltLn0Kf4CVOimVc=
=3+Ea
-----END PGP SIGNATURE-----