On Mon, 2009-05-11 at 16:10 +0200, Lennart Poettering wrote: > On Mon, 11.05.09 16:47, Maxim Levitsky (maximlevitsky at gmail.com) wrote: > > > 1 - like he says, hal will still be there, just like libbonbo is. > > I figure you mean libbonobo? The phasing out is mostly done AFAIK, > with the exception of the panel. > > > 2 - there will be huge wave of very unpleasant bugs, and again there > > will be release or two containing most of them (remember folks, you > > don't have the money to buy every system/device) in the world to test. > > And while users do report bugs, its time consuming for user and > > developer to do remote debugging. > > HAL is pretty buggy too. It's sometimes ridiculous. For example, it > patches ACLs *after* it sent out signals that a device was created, to > the effect that when PA tries to open the device then it often enough > cannot because the access fails. > > > Just an example, we have a linux lab at my university. > > Users bring usb sticks, plug it in, and it doesn't work. > > (I figured out that this is due to stale .hal-mtab file in /media) > > Yes, HAL is broken in many ways. > > HAL was a first attempt to figure out what we actually want on > Linux. Now we know that pretty well, so the second try is hopefully > going to be a bit smoother. > > Also note that the process to swich to udev has been going on since > quite some time. In F11 quite a few subsystems have already been > switched over. A few are still remaining. > > > Thus ONLY incremental changes are possible (and no 'buts' or 'ifs') > > Even if you create an experimental branch (like kernel mode-setting) > > it just won't progress, because developers are already full of bug > > fixing the current stuff that user use. Even now, I hear that > > modesetting still crashes the system there and there. > > Those changes are mostly incremental. HAL and the new udev/dkit stuff > do not conflict. Things are moved over bit-by-bit. Nice to hear that. Probably then I worry about that too much then. > > In the end in Free Software it's always at the developer's discretion > how things are handled. If you want to have a greater influence on how > things are handled, become a developer of the specific project too! > And I'll promise you you'll start to see things more like the other > devs by doing so. I am not a developer yet, but I think I agree with you. Although I do report bugs, and sometimes even fix them. Speaking of which, few words: First I discovered that skype doesn't work well with PA 0.9.14 ether. while I hear sound, the echo suppression logic is very broken. Probably is is better to leave that junk alone. Best regards, Maxim Levitsky