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.
OK. At first glance it is distro-specific, as Ubuntu (for example) does not automatically mount new devices into /media. In fact, that would be considered undesirable behaviour from my point of view, as the user should be able to decide which devices to mount.
Also, I would hazard a guess that the popup GUI for encrypted devices doesn't work with this patch.
Tim
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.
OK. At first glance it is distro-specific, as Ubuntu (for example) does not automatically mount new devices into /media. In fact, that would be considered undesirable behaviour from my point of view, as the user should be able to decide which devices to mount.
Also, I would hazard a guess that the popup GUI for encrypted devices doesn't work with this patch.
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, as it does not provide all the functionality for pluggable media that once existed with HAL.
Tim
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).
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.
Tim
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.
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.
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. :-)
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.
Understood.
Tim
On Sep 9, 2011 12:38 PM, "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
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.
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 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.
On Sep 9, 2011 1:31 PM, "Ilya Chernykh" anixxsus@gmail.com wrote:
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
It doesn't matter to users if we provided the packages.
On Friday 09 September 2011 21:41:23 Calvin Morrison wrote:
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.
Yes but it bars inclusion of Trinity into distributions.
On Sep 9, 2011 1:42 PM, "Ilya Chernykh" anixxsus@gmail.com wrote:
On Friday 09 September 2011 21:41:23 Calvin Morrison wrote:
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.
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?
On Sep 9, 2011 1:42 PM, "Ilya Chernykh" anixxsus@gmail.com wrote:
On Friday 09 September 2011 21:41:23 Calvin Morrison wrote:
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.
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 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 22:03:56 Timothy Pearson 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 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?
On Friday 09 September 2011 22:03:56 Timothy Pearson 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 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).
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.
Tim
On Friday 09 September 2011 22:24:27 Timothy Pearson wrote:
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.
This popup menu works well without hal.
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.
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.
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.
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
-
Calvin Morrison -
Ilya Chernykh -
Nix -
Timothy Pearson