9 Sep
2011
9 Sep
'11
3:45 p.m.
On Thursday 08 September 2011 21:14:18 Timothy Pearson
wrote:
> > So you did not see the patch and claim it is distro-specific. Is
> having a
> > /media folder also distro-specific?
> Where is the link? No, having a media folder is not distro specific.
If I was
wrong here I apologize. I don't have time to examine each and
every patch that exists outside of this mailing list, so I do have to
trust other people to look at some of them--this is the nature of a
large
project such
as Trinity.
Here is it.
9 Sep
9 Sep
3:46 p.m.
New subject: [trinity-devel] kdebase without hal?
On Thursday 08
September 2011 21:14:18 Timothy Pearson wrote:
> > So you did not see the patch and claim it is distro-specific. Is
> having a
> > /media folder also distro-specific?
> Where is the link? No, having a media folder is not distro specific.
If I was
wrong here I apologize. I don't have time to examine each and
every patch that exists outside of this mailing list, so I do have to
trust other people to look at some of them--this is the nature of a
large
project
such as Trinity.
Here is it. 
4 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 19:46:47 Timothy Pearson wrote:
I should mention as well that if OpenSUSE does not automount into /media
either, then the patch is not distro-specific, it is simply incomplete,
It is complete in the part that is related to KDE3. It does not provide HAL functionality
because HAL is not a part of KDE3.
as
it does not provide all the functionality for pluggable media that once
existed with HAL.
Yes, it needs either an auto-mounter such as devmon or udiskie started or
an auto-mount udev rule enabled.
With devmon the patch works well currently on my machine. Enabling automount
in udev rules comes into conflict with fsck on each boot because the devices get mounted
before fsck
starts which leads it to complain that the devices already mounted and unaccessible
(but this may be distro-specific behavior).
4:38 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 19:46:47 Timothy Pearson
wrote:
In light of this, I would consider this patch a temporary workaround to a
far more serious problem, and would reject the patch for inclusion in the
upstream TDE sources.
In fact, as a matter of policy I am going to reject all piecemeal HAL
workarounds unless they implement portions of the libraries (TUComputer,
TUPower) that I have mentioned earlier. This decision is an effort to
keep Trinity maintainable and stable, and continue with the philosophy of
having dedicated system access libraries that then distribute information
and control of system functions to higher level TDE applications.
Tim
I should mention as well that if OpenSUSE does not automount into /media
either, then the patch is not distro-specific, it is simply incomplete,
It is complete in the part that is related to KDE3. It does not provide
HAL functionality
because HAL is not a part of KDE3.
as
it does not provide all the functionality for pluggable media that once
existed with HAL.
Yes, it needs either an auto-mounter such as devmon or udiskie started or
an auto-mount udev rule enabled.
With devmon the patch works well currently on my machine. Enabling
automount
in udev rules comes into conflict with fsck on each boot because the
devices get mounted before fsck
starts which leads it to complain that the devices already mounted and
unaccessible
(but this may be distro-specific behavior).
4:52 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 20:38:35 Timothy Pearson wrote:
In light of this, I would consider this patch a temporary workaround to a
far more serious problem,
Currently there are two mediamanager backends: the hal backend and the fstab/mtab
backend.
The patch only repairs and reenables the previously disabled parts of the fstab/mtab
backend?
and makes it compatible with modern environments.
A proper solution maybe would require writing a third backend for dealing with udisks.
I hope you'll share the third backend to mediamanager once you write it.
and would reject the patch for inclusion in the
upstream TDE sources.
In fact, as a matter of policy I am going to reject
all piecemeal HAL
workarounds unless they implement portions of the libraries (TUComputer,
TUPower) that I have mentioned earlier.
The patch only solves the problem of mediamanager's detection of new disk
devices. It does not deal with other hal functionality.
This decision is an effort to
keep Trinity maintainable and stable, and continue with the philosophy of
having dedicated system access libraries that then distribute information
and control of system functions to higher level TDE applications.
5:12 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 20:38:35 Timothy Pearson
wrote:
Of course. Just look at all the new code I have added to Trinity over the
past few years and you should be able to infer that when I write something
for Trinity it gets released. :-)
In light of this, I would consider this patch a temporary workaround to
a
far more serious problem,
Currently there are two mediamanager backends: the hal backend and the
fstab/mtab backend.
The patch only repairs and reenables the previously disabled parts of the
fstab/mtab backend?
and makes it compatible with modern environments.
A proper solution maybe would require writing a third backend for dealing
with udisks.
I hope you'll share the third backend to mediamanager once you write it. and would reject the patch for inclusion in the
upstream TDE sources.
In fact, as a matter of policy I am going to
reject all piecemeal HAL
workarounds unless they implement portions of the libraries (TUComputer,
TUPower) that I have mentioned earlier.
The patch only solves the problem of mediamanager's detection of new disk
devices. It does not deal with other hal functionality. 
5:27 p.m.
New subject: [trinity-devel] kdebase without hal?
On Sep 9, 2011 12:38 PM, "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net>
wrote:
Hi.
Call this ridiculous, call it what you will.
Why don't we maintain HAL? As with Qt3, if no one supports it, it can just
"disappear into our source. No one need bother with it.
I mean it is an integral part of a desktop and there is no viable
replacement. Therefore I vote that we should adopt it.
Thoughts?
Calvin
> On Friday 09 September 2011 19:46:47 Timothy Pearson wrote:
>
>>
>> I should mention as well that if OpenSUSE does not automount into
/media
>> either, then the patch is not
distro-specific, it is simply incomplete,
>
> It is complete in the part that is related to KDE3. It does not provide
> HAL functionality
> because HAL is not a part of KDE3.
>
>> as
>> it does not provide all the functionality for pluggable media that once
>> existed with HAL.
>
> Yes, it needs either an auto-mounter such as devmon or udiskie started
or
an auto-mount
udev rule enabled.
With devmon the patch works well currently on my machine. Enabling
automount
in udev rules comes into conflict with fsck on each boot because the
devices get mounted before fsck
starts which leads it to complain that the devices already mounted and
unaccessible
(but this may be distro-specific behavior).
In light of this, I would consider this patch a temporary workaround to a
far more serious problem, and would reject the patch for inclusion in the
upstream TDE sources.
In fact, as a matter of policy I am going to reject all piecemeal HAL
workarounds unless they implement portions of the libraries (TUComputer,
TUPower) that I have mentioned earlier. This decision is an effort to
keep Trinity maintainable and stable, and continue with the philosophy of
having dedicated system access libraries that then distribute information
and control of system functions to higher level TDE applications.
5:31 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 21:27:18 Calvin Morrison wrote:
Call this ridiculous, call it what you will.
Why don't we maintain HAL? As with Qt3, if no one supports it, it can just
"disappear into our source. No one need bother with it.
I mean it is an integral part of a desktop and there is no viable
replacement. Therefore I vote that we should adopt it.
Thoughts?
Call it good or bad but hal will never return to the distributions.
5:41 p.m.
New subject: [trinity-devel] kdebase without hal?
On Sep 9, 2011 1:31 PM, "Ilya Chernykh" <anixxsus(a)gmail.com> wrote:
It doesn't matter to users if we provided the packages.
On Friday 09 September 2011 21:27:18 Calvin Morrison wrote:
> Call this ridiculous, call it what you will.
>
> Why don't we maintain HAL? As with Qt3, if no one supports it, it can
just
"disappear into our source. No one need bother with it.
I mean it is an integral part of a desktop and there is no viable
replacement. Therefore I vote that we should adopt it.
Thoughts?
Call it good or bad but hal will never return to the distributions
5:42 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 21:41:23 Calvin Morrison wrote:
It doesn't matter to users if we provided the packages.
Yes but it bars inclusion of Trinity into distributions.
I mean it is an integral part of a desktop and there
is no viable
replacement. Therefore I vote that we should adopt it.
Thoughts?
Call it good or bad but hal will never return to the distributions
5:49 p.m.
New subject: [trinity-devel] kdebase without hal?
On Sep 9, 2011 1:42 PM, "Ilya Chernykh" <anixxsus(a)gmail.com> wrote:
On Friday 09 September 2011 21:41:23 Calvin Morrison wrote:
It doesn't matter to users if we provided the packages.
Yes but it bars inclusion of Trinity into distributions.
Hal is only unsupported because it is unmaintained. If it was maintained,
why would distributions not want to include it?
I mean it is an integral part of a desktop and there
is no viable
replacement. Therefore I vote that we should adopt it.
Thoughts?
Call it good or bad but hal will never return to the distributions
6:03 p.m.
New subject: [trinity-devel] kdebase without hal?
On Sep 9, 2011 1:42 PM, "Ilya Chernykh"
<anixxsus(a)gmail.com> wrote:
I do NOT want to maintain HAL. We do not have the resources to do that.
HAL requires continual updates to work with new hardware.
It would be far easier to simply implement the libraries that I keep
mentioning. The problem is that replacing HAL (which is easier than
maintaining it) is still quite resource intensive.
Tim
On Friday 09 September 2011 21:41:23 Calvin Morrison wrote:
Yes but it bars inclusion of Trinity into distributions.
Hal is only unsupported because it is unmaintained. If it was maintained,
why would distributions not want to include it?
> I
mean it is an integral part of a desktop and there is no viable
> replacement. Therefore I vote that we should adopt it.
>
> Thoughts?
Call it good or bad but hal will never return to the distributions
It doesn't matter to users if we provided the packages.
6:17 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 22:03:56 Timothy Pearson wrote:
I do NOT want to maintain HAL. We do not have the resources to do that.
HAL requires continual updates to work with new hardware.
It would be far easier to simply implement the libraries that I keep
mentioning. The problem is that replacing HAL (which is easier than
maintaining it) is still quite resource intensive.
I have just tested... Hybernation and suspension both to disk and to RAM works
well without hal (both from the KDE menu). Auto-mounting also works well
(if you implement it with udev rules you do not need any additional services running).
K3B works well and auto-detects the media. Ejecting CD-ROM works well.
What else should hal do?
Yes but it bars inclusion of Trinity into
distributions.
Hal is only unsupported because it is unmaintained. If it was maintained,
why would distributions not want to include it?
6:24 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 22:03:56 Timothy Pearson
wrote:
maintained,
I have just tested... Hybernation and suspension both to disk and to RAM
works
well without hal (both from the KDE menu). Auto-mounting also works well
(if you implement it with udev rules you do not need any additional
services running).
Sorry, but no it does not. The original KDE media service provides popup
menus that allow you to decide if you want to mount the media, decrypt the
media, etc., which also allow the user NOT to mount something that is
plugged into the system.
Yes but it bars inclusion of Trinity into
distributions.
Hal is only unsupported because it is unmaintained. If it was why would distributions not want to include it?
I do NOT want to maintain HAL. We do not have the resources to do that.
HAL requires continual updates to work with new hardware.
It would be far easier to simply implement the libraries that I keep
mentioning. The problem is that replacing HAL (which is easier than
maintaining it) is still quite resource intensive. K3B works well and auto-detects the media. Ejecting
CD-ROM works well.
What else should hal do?
kpowersave is completely broken without it. This is a major sticking point.
Tim
8:46 p.m.
New subject: [trinity-devel] kdebase without hal?
On Friday 09 September 2011 22:24:27 Timothy Pearson wrote:
This popup menu works well without hal.
I have just
tested... Hybernation and suspension both to disk and to RAM
works
well without hal (both from the KDE menu). Auto-mounting also works well
(if you implement it with udev rules you do not need any additional
services running).
Sorry, but no it does not. The original KDE media service provides popup
menus that allow you to decide if you want to mount the media, decrypt the
media, etc., which also allow the user NOT to mount something that is
plugged into the system. K3B works well
and auto-detects the media. Ejecting CD-ROM works well.
What else should hal do?
kpowersave is completely broken without it. This is a major sticking point.
11 Sep
11 Sep
10:27 p.m.
New subject: [trinity-devel] kdebase without hal?
On 9 Sep 2011, Calvin Morrison said:
Why don't we maintain HAL? As with Qt3, if no one
supports it, it can just
"disappear into our source. No one need bother with it.
I mean it is an integral part of a desktop and there is no viable
replacement. Therefore I vote that we should adopt it.
It runs as root, is notably nonportable, gets little or no security
review, and its original authors have declared it unmaintainable (and
having looked at it, I must agree).
This seems like a bad thing to pull into Trinity.
--
NULL && (void)
12 Sep
12 Sep
12:08 a.m.
New subject: [trinity-devel] kdebase without hal?
On 9 Sep 2011, Calvin Morrison said:
Yes I agree.
BTW, discussion was closed on this a few days ago with my statement that
it will NOT be included in Trinity. :-) Quality replacement libraries
need to be written that use the latest power and device interfaces
available.
Tim
Why don't we maintain HAL? As with Qt3, if no
one supports it, it can
just
"disappear into our source. No one need bother with it.
I mean it is an integral part of a desktop and there is no viable
replacement. Therefore I vote that we should adopt it.
It runs as root, is notably nonportable, gets little or no security
review, and its original authors have declared it unmaintainable (and
having looked at it, I must agree).
This seems like a bad thing to pull into Trinity.
4617
days inactive
4620
days old
16 comments
4 participants
participants (4)
-
Calvin Morrison -
Ilya Chernykh -
Nix -
Timothy Pearson