On Sun, Feb 28, 2010 at 10:20 PM, Marty Jack <[email protected]> wrote: > It's more correct to say two things: > > Your dependency is (the userspace library) libudev, not (the daemon) udevd. > > The DeviceKit developers view libudev as the way forward for information that > libudev provides. They viewed DeviceKit as duplicative and redundant for > those areas. HAL was a V1 product that had severe limitations and instead of > trying to fix it, they rewrote it into what is replacing it. I agree with > that choice. (Someone who is rewriting pcmanfm might agree also that > sometimes it is better to scrap what you have and start over.) Thus, the new > design is that you should plan to use the combination of libudev, ConsoleKit, > UPower in the future.
Since we're going to use libudev directly, what's the point in providing upower as dbus service? I don't understand this quite well. > There are a few other areas where Linux is diverging from the other players, > let us say FreeBSD and OpenSolaris. One other is kernel mode setting. The > Intel driver has dropped support for user mode setting in its latest release. > The result is only that if you are on a non-Linux platform, you are stuck on > an older release. The other platform can recover from this by implementing > the necessary features, the same as it can recover from the point you raise > by implementing a libudev that acts properly. If there is sufficient > interest in the non-Linux platform, they eventually will. If not, they may > not. Well, just like we don't like to fight with backward incompatibilities and we don't like to be forced to use new solutions, those developers on other platforms don't like to be forced to adopt Linux technology everytime. So I think this is a technical + political issue, which is hard to solve. Some abstraction + encapsulation + per-platform backend is still needed here. > So, the "from now on" prediction is overly pessimistic, given that non-Linux > platforms can add the needed things. You are correct that if you want to run > on Linux, you have to use the new stuff. Maybe we can have our own wrapper lib?. > On 02/28/2010 07:38 AM, PCMan wrote: >> The upstream developers of HAL and devicekit are removing HAL along >> with many required features. >> They removed old features we needed from HAL, but refused to add them >> back in deviceKit. >> So, unfortunately, we have to directly use udev and back to the time >> when there is no corss-platform solution. >> For Linux-only solution, I found the documentation written by XFCE >> developer useful. >> >> http://wiki.xfce.org/dev/thunar-volman-udev >> >> For developers building hardware-related lxde components, read this. >> Linux-only is not a problem since the only cross-platform solution, >> HAL, is killed by upstream developer and it's impossible for BSD or >> others to have udev. >> It's a pain but we have no choices. Although theoratically free >> software is all about choices, but now we're left with no other >> choice. >> So let's face it. Writing Linux-only code, unfortunately, is >> inevitable from now on. >> >> Sigh... >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Lxde-list mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lxde-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/lxde-list > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
