7 May
2012
7 May
'12
12:03 p.m.
Tim, All,
After the discussion both here and on the suse list about the removal of HAL,
that brought up a question that I don't fully understand. I know that everyone
is moving away from HAL and that it is the way of the future, but "Why?"
Briefly - what is wrong with HAL? Is it dead upstream? Does is pose
limitations on the ability to do X or Y going forward? If so what are X or Y? Is
it udev? What?
Like Qt3, all of the past versions of KDE3 and TDE have used HAL and work
fantastically - what is the motivation for dumping it?
A short sentence or two would help me understand -- or a simply link to why if
you have one will do. Thanks, I just want to make sure I understand the issue
better...
--
David C. Rankin, J.D.,P.E.
7 May
7 May
1:27 p.m.
New subject: [trinity-devel] Why is HAL a bad word?
On Mon, 07 May 2012 07:03:13 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
Tim, All,
After the discussion both here and on the suse list about the removal of HAL,
that brought up a question that I don't fully understand. I know that everyone
is moving away from HAL and that it is the way of the future, but "Why?"
Briefly - what is wrong with HAL? Is it dead upstream? Does is pose
limitations on the ability to do X or Y going forward? If so what are X or Y? Is
it udev? What?
Like Qt3, all of the past versions of KDE3 and TDE have used HAL and work
fantastically - what is the motivation for dumping it?
A short sentence or two would help me understand -- or a simply link to why if
you have one will do. Thanks, I just want to make sure I understand the issue
better...
It's dead upstream, jettisoned in favour of DeviceKit (upower/udisks/etc.).
Apparently,
the codebase was too big and complex to be maintained effectively. See:
http://lists.freedesktop.org/archives/hal/2008-May/011560.html
In addition to this, many distros have dropped it. At the time it was dropped from
Gentoo, there were some small nuisance bugs due to its functionality overlapping
with other hardware backends (disks and other devices showing up twice in some
applications was the most common one, IIRC).
Given the reasons it's now an orphan, I don't think it's wise for us to assume
its
maintenance (IIRC, Tim has already said he doesn't want to, anyway). Best to
move on.
2:07 p.m.
New subject: [trinity-devel] Why is HAL a bad word?
On 05/07/2012 08:27 AM, E. Liddell wrote:
Given the reasons it's now an orphan, I don't
think it's wise for us to assume its
maintenance (IIRC, Tim has already said he doesn't want to, anyway). Best to
move on.
Yep, I agree totally. The big question is my mind is (1) time & (2) manpower
constraints to implement its removal from tde. Every kde3 project that wants
to move forward must be addressing this issue. While it might seem
unmanageable for TDE to do it alone, or SuSE to do it alone, or whoever to do
it alone, if we could somehow coordinate TDE, SuSE and whoever else (need to
ID these) so that a common framework is chosen and the parts of the transition
broken down into block 1, 2, 3, .... so that TDE does 1, suse does 2, and so
on -- it starts to look a whole lot more doable.
Why not have a central halfreetkde3-wiki or something similar that could host
removal standards and server as a patch repository/hub....
Instead of having 10 different projects separately trying to do the same thing
10 different ways, it is far better to have 10 different projects contribute
to doing 1 thing the same way....
--
David C. Rankin, J.D.,P.E.
3:12 p.m.
New subject: [trinity-devel] Why is HAL a bad word?
On 05/07/2012 10:07 AM, David C. Rankin wrote:
On 05/07/2012 08:27 AM, E. Liddell wrote:
I mean Tim is implementing the replacement currently with his TDE
hardware library ( this is still beta ).
Given the reasons it's now an orphan, I
don't think it's wise for us
to assume its
maintenance (IIRC, Tim has already said he doesn't want to, anyway).
Best to
move on.
Yep, I agree totally. The big question is my mind is (1) time & (2)
manpower constraints to implement its removal from tde. Every kde3
project that wants to move forward must be addressing this issue. While
it might seem unmanageable for TDE to do it alone, or SuSE to do it
alone, or whoever to do it alone, if we could somehow coordinate TDE,
SuSE and whoever else (need to ID these) so that a common framework is
chosen and the parts of the transition broken down into block 1, 2, 3,
.... so that TDE does 1, suse does 2, and so on -- it starts to look a
whole lot more doable.
Why not have a central halfreetkde3-wiki or something similar that could
host removal standards and server as a patch repository/hub....
Instead of having 10 different projects separately trying to do the same
thing 10 different ways, it is far better to have 10 different projects
contribute to doing 1 thing the same way....
Instead of having 10 different projects, why doesn't everyone else join
Trinity? We are the largest fork of KDE3. Anyone else is getting hung up
on pointless technical arguments. Those people who choose to leave for
those arguments are silly because in the end they hurt themselves more.
KDE3 has a following and splitting the small developer and userbase up
is ridiculous.
Calvin
4:40 p.m.
New subject: [trinity-devel] Why is HAL a bad word?
Given the
reasons it's now an orphan, I don't think
it's wise for us to assume
its maintenance (IIRC, Tim has already said he doesn't want
to, anyway). Best to move on.
Yep, I agree totally. The big question is my mind is (1)
time & (2) manpower constraints to implement its removal
from tde. Every kde3 project that wants to move forward must
be addressing this issue. While it might seem unmanageable
for TDE to do it alone, or SuSE to do it alone, or whoever
to do it alone, if we could somehow coordinate TDE, SuSE and
whoever else (need to ID these) so that a common framework
is chosen and the parts of the transition broken down into
block 1, 2, 3, .... so that TDE does 1, suse does 2, and so
on -- it starts to look a whole lot more doable.
Why not have a central halfreetkde3-wiki or something
similar that could host removal standards and server as a
patch repository/hub....
Instead of having 10 different projects separately trying to
do the same thing 10 different ways, it is far better to
have 10 different projects contribute to doing 1 thing the
same way.... 
9 May
9 May
1:37 p.m.
New subject: [trinity-devel] Why is HAL a bad word?
the proyect wash too much time in unusefully thinks like "Greater
stability, more features" (mayor of thems are much like windows gui desktop
like), "Monitor and Display gui settings" (that linux real user modifiy at
xorg settings in console), "ew widget theme askteroid" (???, theres a lot
of v3 themes in kde-app.org), "Enhanced Quick Launch Kicker applet" (all
kicker enhanched are windows like enhanches), .... and a-lot-of stuff that
are only usefully in ubunwindo like desktops ..
I think the first thing you should do was to begin *ONLY* with the migration
to cmake, make a stimated finish, and once the main parts was migrated,
start repairing most important faults .. the result will be more focused to
expected..
this that i prevously said, permit to know more for non-manpower users know
about kde parts and colaborate better with project.. but now project need
man powers to port hal, bluetooht and a lot of fixeds! that the reality!
On Mon, May 7, 2012 at 12:10 PM, Darrell Anderson
<humanreadable(a)yahoo.com>wrote;wrote:
he doesn't want
--
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
Cofundador de Venenux; debian based multimedia alike free only zealots
users (oh well, i try but..too many free guidelines buahhh)
http://shutendouji.net
creador de massenkoh linux; debian enhanchements for better up to date
support on stable brand, including non-free soft.
Given the reasons it's now an orphan, I don't
think
it's wise for us to assume its maintenance (IIRC, Tim has already said
to, anyway). Best to move on.
Yep, I agree totally. The big question is my mind is (1)
time & (2) manpower constraints to implement its removal
from tde. Every kde3 project that wants to move forward must
be addressing this issue. While it might seem unmanageable
for TDE to do it alone, or SuSE to do it alone, or whoever
to do it alone, if we could somehow coordinate TDE, SuSE and
whoever else (need to ID these) so that a common framework
is chosen and the parts of the transition broken down into
block 1, 2, 3, .... so that TDE does 1, suse does 2, and so
on -- it starts to look a whole lot more doable.
Why not have a central halfreetkde3-wiki or something
similar that could host removal standards and server as a
patch repository/hub....
Instead of having 10 different projects separately trying to
do the same thing 10 different ways, it is far better to
have 10 different projects contribute to doing 1 thing the
same way....
We have little choice to "move on," but I want to see the existing HAL
support remain intact and loosely maintained. At least for the next few
releases and until the new detection mechanism is fully developed and
mature, which will take a release or two to mature. I believe we can
support both with build configuration options.
Keeping HAL support allows users to install Trinity on older hardware with
older operating systems. We should remember that many people run older
releases of operating systems for many years and do not play the relentless
updating game.
Regarding collaboration, like most things in life, that either happens or
doesn't. The people supporting KDE3 rather than Trinity have their reasons.
We should respect those decisions and they should respect ours. At one time
there was fallout because some people did not want the TQt layer. The only
way we keep the doors open to those people to help with collaboration is to
prove the layer does not cause problems or bugs. We should be honest with
ourselves and admit that the transition to TQt did introduce bugs. I
believe those growing pains are now behind us. When we demonstrate that no
such related bugs exist then that might convince others to return. Until
then we learn to be content with what we are doing and let others be
content with what they are doing. :-)
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
3:09 p.m.
New subject: [trinity-devel] Why is HAL a bad word?
On 05/09/2012 09:37 AM, PICCORO McKAY Lenz wrote:
the proyect wash too much time in unusefully thinks
like "Greater
stability, more features"
Greater stability and more features are "un-useful things?" I find them
to be exactly what I am looking for in a desktop environment.
"Monitor and Display gui settings" (that
linux real user modifiy at
xorg settings in console),
I don't think any sane person with a normal setup has been manually
editing their Xorg.conf's in several years... any commercial desktop in
the last 10 years has had a GUI display config. it's great!
I think the first thing you should do was to begin
*ONLY* with the migration
to cmake, make a stimated finish, and once the main parts was migrated,
start repairing most important faults .. the result will be more focused to
expected..
luckily cmake development can go along _meanwhile_ other problems are
resolved. I mean look at how many bug reports and problems have been
resolved since 3.5.10 alone.
I don't really see what you are getting at.
Calvin
4614
days inactive
4616
days old
6 comments
5 participants
participants (5)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell -
PICCORO McKAY Lenz