Re: External dependencies, DeviceKit-power and GNOME Power Manager
Richard Could you give me an estimation about how much effort we need to migrate HAL to DeviceKit-power in a distro like Solaris? Are the interface of DeviceKit-power similar with that defined in HAL specification? Jeff Richard Hughes wrote: During the 2.25 release cycle I would like to move GNOME Power Manager away from a HAL dependency and onto a new DeviceKit-power dependency. DeviceKit-power is a new mechanism daemon that moves the battery profiling and statistics interface system-wide, and also does the history recording once per system, rather than once per session. It also moves to an interface that is legacy-free and is more focused on the entire power management system than HAL ever was. You can see some screenshots of the new functionality on my blog: http://blogs.gnome.org/hughsie/2008/11/09/gnome-power-manager-and-devicekit-power/ -- At the moment you have to compile with --enable-devicekit to get the new functionality. Q: Why is system wide better? A: There's no point doing the data collection, statistics profiling and calculations in every session on a multiuser workstation. There's also the point that at GDM you run a g-p-m instance, which doesn't have access to the profiling data you generate in the session, and so you get "unknown time remaining". Q: What's wrong with HAL? A: HAL has grown into a mega-daemon doing a little bit of everything, it evolved with DBUS over a number of years and is now pretty horrible code. The DeviceKit set of daemons replace core functionality of HAL and are developed by the very same maintainers as HAL was. HAL also has a very low level interface, and so apps needed tons of complicated code in the session to do simple things like work out remaining battery lifetime. Q: Is anything else going to use DeviceKit-$foo? A: In the future gvfs will depend on DeviceKit-disks, not HAL Q: Yet another system daemon?!? A: No, all the DeviceKit daemons are system activated and low footprint, so if you don't need them they don't get started. Q: Can't you have --enable-hal and enable-devicekit in configure? A: Not without a thousand #ifdefs, we would essentially have two seporate engines which I don't want to support. I'm was trying to do that on trunk and it's was getting crazy. DeviceKit-power also implements a QoS (Quality of Service) interface for latency control, and in the future will be used for _aggressive_ application power control. This is needed to produce a desktop that uses little power when idle, but doesn't feel sluggish. There's more information about this on my blog too. What I propose is to switch trunk to using DeviceKit-power, and if distros don't want to ship the very new code in 2.26.0, they can stick with the old HAL only code of 2.24.x, like some distros last cycle did with GDM. Of course, I'll still continue to actively maintain the 2.24 in parallel with the new development. Switching to DeviceKit-power allows me to make g-p-m the simple session process it should be, rather than the mess of legacy and complex code it is now. DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit daemon which is a thin dbus wrapper around udev. So, comments please. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
[Late to the party, a colleague forwarded this thread to me] Joe Marcus Clarke wrote: While it's refreshing for someone other than me to say this ;-), I have to admit that getting HAL working on FreeBSD was a good thing. I look forward to the better API promised by DK. However, unlike Solaris (or maybe Solaris is in the same boat right now) the FreeBSD GNOME project doesn't have a lot of resources. Right now, there are four of us that work on porting everything from Glib to Gecko to FreeBSD. We've prided ourselves on staying as up-to-date as possible with GNOME. However, when something very OS-specific comes out, it always takes us a while to get in sync since not all four of us know C, python, etc. At some point, we will catch up. However, it would be better if we could have a transition period where both the new and legacy technologies work together to allow us to stay current, and give us the extra time to port the new modules. Most of what Joe says about FreeBSD also applies to Solaris. I'm the one who ported HAL to Solaris, though I no longer actively work on it. Several groups share responsibilities per their specialty: one person is responsible for the power/acpi code, another for printing, etc (the desktop group has never touched a line of HAL code, they are strictly an API consumer) - in that sense, DK's functional breakup would probably do us good. But it also means that the transition will take more time as more inter-group coordination is required. I think DK port will be primarily driven by GNOME (as was HAL): when our desktop folks fail to build their latest GNOME components and realize their schedule jeopardized, they'll start pestering the OS folks. The OS folks will grumble for a while and eventually ask mgmt to fund a project to transition from HAL to DK. At least that's my pessimistic prediction :) One more thing to mention. We've been trying to make HAL interfaces more suitable for multi-seat environments, especially Sun Rays, and there are some private patches to achieve that (including DBus patches to route signals to users vs broadcasting to all), though they never made it into production. Looks like we'd have to revisit those. Last time I looked, ConsoleKit had some undelivered promises in this area, wink. All that said, we are committed to the continuing open collaboration. Great to see these types of discussions, keep 'em coming - critical decisions in the desktop space require a lot of transparency. -Artem ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Le mardi 25 novembre 2008 à 13:39 -0500, David Zeuthen a écrit : > The kernel is definitely part of this and, FWIW, we (the ConsoleKit > developers) are working with the Linux kernel developers and security > people to get this right (initially the session id wasn't readable to > user space etc.). I am very pleased to learn that kernel developers are working on it. The problem has been known for a very long time and it is heartwarming to see things that matter for the desktop can move on again. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 19:29 +0100, Josselin Mouette wrote: > Le mardi 25 novembre 2008 à 13:03 -0500, David Zeuthen a écrit : > > You are of course very free to do whatever you want with your operating > > system but a couple of points here > > > > - ConsoleKit has nothing to do with assigning device permissions; dunno > >know from where you got that idea. However, ConsoleKit as a mechanism > >is typically used to dynamically manage ACL's on device nodes. > > I thought ConsoleKit was responsible for propagating the information > about console seats that is used to set these permissions. ConsoleKit only maintains a database of seats and sessions and associated information. Think about it as just an information provider; a mechanism... that's all it is. > Apparently > this is wrong and pam_console is still responsible for it on Redhat, so > please forgive the mistake. This is off-topic but both HAL, pam_console and udev are used in Fedora to manage mode, owner/group and ACL's. It's somewhat a mess right now but that's another story. (And it's Red Hat, not Redhat.) > > > - FWIW, mediating device access through group membership is > >considered broken by most people that care about security [1]. > >AFAIK, Ubuntu is moving away from it too. > > I am well aware that group membership is not a silver bullet. Still, I’d > be glad if security people helped implement the missing pieces in the > kernel rather than tell us every available solution we have is wrong :) The kernel is definitely part of this and, FWIW, we (the ConsoleKit developers) are working with the Linux kernel developers and security people to get this right (initially the session id wasn't readable to user space etc.). Of course there are still things the kernel don't know about; for example whether a session is currently active (now, whether the kernel should know about that is a different question) and, in the future, what devices are mapped to each seat (something the kernel probably shouldn't care about). Anyway, for GNOME, it's actually really useful to know if the session is active; it means you can implement nice policy (according to user owned preferences) in e.g. Rhythmbox to pause the music. Of course, it's also use for dynamic ACL management; normally users should only have ACL's for devices when their session is active. FWIW, ConsoleKit, as an abstraction, makes it possible for GNOME to rely on things like session activity without relying on bleeding Linux versions on Linux at all (e.g. FreeBSD, Solaris, whatever). David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Le mardi 25 novembre 2008 à 13:03 -0500, David Zeuthen a écrit : > You are of course very free to do whatever you want with your operating > system but a couple of points here > > - ConsoleKit has nothing to do with assigning device permissions; dunno >know from where you got that idea. However, ConsoleKit as a mechanism >is typically used to dynamically manage ACL's on device nodes. I thought ConsoleKit was responsible for propagating the information about console seats that is used to set these permissions. Apparently this is wrong and pam_console is still responsible for it on Redhat, so please forgive the mistake. > - FWIW, mediating device access through group membership is >considered broken by most people that care about security [1]. >AFAIK, Ubuntu is moving away from it too. I am well aware that group membership is not a silver bullet. Still, I’d be glad if security people helped implement the missing pieces in the kernel rather than tell us every available solution we have is wrong :) > Again, you are free to do whatever you want in your OS. No one forces > you to use dynamic ACL's and if something in the future does that, then > I agree that it's problematic for something like GNOME to depend on. I see that we agree then. As long as this remains clear, I have no objection to making ConsoleKit a mandatory piece of the desktop. Actually, the uses that e.g. PulseAudio can have for it are really nice things to have. > Please avoid spreading misinformation. Thanks. This was certainly not my intention. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 17:41 +0100, Josselin Mouette wrote: > However I wouldn’t like if ConsoleKit became mandatory for some uses, > because its security model reproduces some of the mistakes of > pam_console. Currently we still replace at_console policies by specific > group memberships. If this stops being possible we’d certainly have a > problem with that. You are of course very free to do whatever you want with your operating system but a couple of points here - ConsoleKit has nothing to do with assigning device permissions; dunno know from where you got that idea. However, ConsoleKit as a mechanism is typically used to dynamically manage ACL's on device nodes. FYI, device permissions is (currently) managed by HAL and on purpose (to suit Debian) it's an optional, not mandatory, feature. It's still an open question what component will replace it in a non-HAL world. - FWIW, mediating device access through group membership is considered broken by most people that care about security [1]. AFAIK, Ubuntu is moving away from it too. (That is not to say, UNIX groups are useless for managing device permissions; for example it's useful to have a 'video' UNIX group and put, say, Fluendo video server system user in that group. But IMHO, it's a mistake to do that for regular users since such privileges are very hard to revoke.) Again, you are free to do whatever you want in your OS. No one forces you to use dynamic ACL's and if something in the future does that, then I agree that it's problematic for something like GNOME to depend on. Please avoid spreading misinformation. Thanks. David [1] : Once member of a group, always member of a group.. copy /bin/bash to $HOME; chown to group, set the setgid bit... OWNED! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 17:43 +0100, Josselin Mouette wrote: > Le mardi 25 novembre 2008 à 10:47 -0500, Joe Marcus Clarke a écrit : > > At some point, we will catch up. However, it would be better if we > > could have a transition period where both the new and legacy > > technologies work together to allow us to stay current, and give us the > > extra time to port the new modules. > > And don’t forget the Hurd! They haven’t ported HAL yet, and now there is > need for another layer! Clearly the solution here is Solid[1]. Ross [1] http://solid.kde.org/ -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Le mardi 25 novembre 2008 à 10:47 -0500, Joe Marcus Clarke a écrit : > At some point, we will catch up. However, it would be better if we > could have a transition period where both the new and legacy > technologies work together to allow us to stay current, and give us the > extra time to port the new modules. And don’t forget the Hurd! They haven’t ported HAL yet, and now there is need for another layer! -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Le mardi 25 novembre 2008 à 15:25 +, Richard Hughes a écrit : > Right, but I need more than feedback from gentoo, FreeBSD and Solaris > for these project, we need _code_. The days of easily being able to run > a desktop GNOME instance without PackageKit, ConsoleKit, PolicyKit or > DeviceKit are numbered, and it's important the people "doing something > different" know that. I don’t think there is a problem with that, since integration between the desktop and the system is definitely the next step in GNOME development and these pieces are clear requirements. However I wouldn’t like if ConsoleKit became mandatory for some uses, because its security model reproduces some of the mistakes of pam_console. Currently we still replace at_console policies by specific group memberships. If this stops being possible we’d certainly have a problem with that. It is also very unlikely that Debian embraces PackageKit as long as its target feature set is stick to the RPM capabilities. After discussing this issue with Ubuntu maintainers, I think the same will probably hold for Ubuntu since we pretty much agreed. Furthermore, Synaptic is already integrated in totem (through gnome-app-install) and nautilus to install new applications and codecs, so we are ahead of what PackageKit promises to achieve, and we would actually lose functionality by switching to it. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Luis Medinas wrote: > On Tue, 2008-11-25 at 15:25 +, Richard Hughes wrote: >> On Tue, 2008-11-25 at 14:45 +, Luis Medinas wrote: >>> Not to mention just like Consolekit it requires some tweaking to work >>> on Linux distros. From what i remember lot's of distros like Debian >>> and Gentoo required some changes on HAL to get it working. Someone >>> from Gentoo please correct me but Consolekit isn't still working on >>> Gentoo. >>> So i would appreciate that these new projects get more feedback from >>> distributors and other OS like FreeBSD and Solaris. >> Right, but I need more than feedback from gentoo, FreeBSD and Solaris >> for these project, we need _code_. The days of easily being able to run >> a desktop GNOME instance without PackageKit, ConsoleKit, PolicyKit or >> DeviceKit are numbered, and it's important the people "doing something >> different" know that. >> > PackageKit isn't still a problem for most distros or FreeBSD and Solaris > but Consolekit and Policykit is because it was heavily pushed to GNOME > without it's been supported by those distributors (same for hal a few > years ago) it's important to keep GNOME sane to run in most of > distributions or OS. Packagers have better things to do than porting > this stuff to their platforms. While it's refreshing for someone other than me to say this ;-), I have to admit that getting HAL working on FreeBSD was a good thing. I look forward to the better API promised by DK. However, unlike Solaris (or maybe Solaris is in the same boat right now) the FreeBSD GNOME project doesn't have a lot of resources. Right now, there are four of us that work on porting everything from Glib to Gecko to FreeBSD. We've prided ourselves on staying as up-to-date as possible with GNOME. However, when something very OS-specific comes out, it always takes us a while to get in sync since not all four of us know C, python, etc. At some point, we will catch up. However, it would be better if we could have a transition period where both the new and legacy technologies work together to allow us to stay current, and give us the extra time to port the new modules. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 15:25 +, Richard Hughes wrote: > On Tue, 2008-11-25 at 14:45 +, Luis Medinas wrote: > > Not to mention just like Consolekit it requires some tweaking to work > > on Linux distros. From what i remember lot's of distros like Debian > > and Gentoo required some changes on HAL to get it working. Someone > > from Gentoo please correct me but Consolekit isn't still working on > > Gentoo. > > So i would appreciate that these new projects get more feedback from > > distributors and other OS like FreeBSD and Solaris. > > Right, but I need more than feedback from gentoo, FreeBSD and Solaris > for these project, we need _code_. The days of easily being able to run > a desktop GNOME instance without PackageKit, ConsoleKit, PolicyKit or > DeviceKit are numbered, and it's important the people "doing something > different" know that. > PackageKit isn't still a problem for most distros or FreeBSD and Solaris but Consolekit and Policykit is because it was heavily pushed to GNOME without it's been supported by those distributors (same for hal a few years ago) it's important to keep GNOME sane to run in most of distributions or OS. Packagers have better things to do than porting this stuff to their platforms. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Hi, I think what Richard was trying to say it that _the_ API of the DeviceKit projects is exactly the D-Bus interface. E.g. we're trying to be careful to make sure that this stuff can be reimplemented if so desired. E.g. if you wanted, you could write a Python or Java program that implements the services org.fd.DK.Power and org.fd.DK.Disks. I think that's what Richard meant. Of course we'll be taking patches for FreeBSD and Solaris in the C/GObject reference implementations that we ship in the DeviceKit projects. It shouldn't be much work at all porting your C code from HAL to DeviceKit; the code base should be significantly much nicer than what you find in HAL. The currently released DeviceKit projects ships with an API that is currently subject to change. We need input from FreeBSD and Solaris hackers on these D-Bus interfaces before they can be frozen. FWIW, to be honest, this desire to make it possible for the DeviceKit services to be reimplemented is first and foremost to ensure that we can change our own reference implementations as we see fit. I don't expect it to be a useful thing for people to reimplement the DeviceKit services; it would be better if everyone worked on the same code base. Hope this clarifies. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 14:45 +, Luis Medinas wrote: > Not to mention just like Consolekit it requires some tweaking to work > on Linux distros. From what i remember lot's of distros like Debian > and Gentoo required some changes on HAL to get it working. Someone > from Gentoo please correct me but Consolekit isn't still working on > Gentoo. > So i would appreciate that these new projects get more feedback from > distributors and other OS like FreeBSD and Solaris. Right, but I need more than feedback from gentoo, FreeBSD and Solaris for these project, we need _code_. The days of easily being able to run a desktop GNOME instance without PackageKit, ConsoleKit, PolicyKit or DeviceKit are numbered, and it's important the people "doing something different" know that. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Luis Medinas wrote: > On Tue, 2008-11-25 at 12:47 +0100, Denis Washington wrote: >> Richard Hughes wrote: >>> DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit >>> daemon which is a thin dbus wrapper around udev. >>> >> As udev is Linux-specific AFAIK, is there support for any other Unix >> platform in DeviceKit? If we lost FreeBSD support for instance, that >> would be a regression (hal works there). > > Not to mention just like Consolekit it requires some tweaking to work on > Linux distros. From what i remember lot's of distros like Debian and > Gentoo required some changes on HAL to get it working. Someone from > Gentoo please correct me but Consolekit isn't still working on Gentoo. > So i would appreciate that these new projects get more feedback from > distributors and other OS like FreeBSD and Solaris. I haven't had time to look at DK yet. We have a lot invested in HAL as KDE is now making extensive use of it. I still have some HAL items on my TODO list, and right now, I'm the only one working on HAL on FreeBSD. Getting DK working on FreeBSD would take some time, and based on Richard's previous email, it doesn't sound like I'd be able to leverage the existing C code already in HAL. Additionally, I'm not comfortable writing Python, so if that is a requirement, I'll need to come up to speed on that first. Therefore, at this point, I'd say that if 2.26 requires DK, it would seriously slow the FreeBSD adoption of 2.26 (maybe up to an additional six months). Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: [EMAIL PROTECTED] FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 12:47 +0100, Denis Washington wrote: > Richard Hughes wrote: > > DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit > > daemon which is a thin dbus wrapper around udev. > > > > As udev is Linux-specific AFAIK, is there support for any other Unix > platform in DeviceKit? If we lost FreeBSD support for instance, that > would be a regression (hal works there). Not to mention just like Consolekit it requires some tweaking to work on Linux distros. From what i remember lot's of distros like Debian and Gentoo required some changes on HAL to get it working. Someone from Gentoo please correct me but Consolekit isn't still working on Gentoo. So i would appreciate that these new projects get more feedback from distributors and other OS like FreeBSD and Solaris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 12:47 +0100, Denis Washington wrote:
> As udev is Linux-specific AFAIK, is there support for any other Unix
> platform in DeviceKit? If we lost FreeBSD support for instance, that
> would be a regression (hal works there).
DeviceKit (not -power or -disks) is a very small simple daemon that is
basically a thin wrapper over udev. You pretty much say "give me devices
that support power_supply" and it returns a list of object paths you can
use.
It's designed to be very easy to implement for Solaris and FreeBSD, and
you could even do it in a few hundred lines of python, if you knew all
the hardware details about those platforms. You would just have to
populate a directory tree that looked like a power_supply class under
Linux and everything would "just work" assuming there was something on
those platforms that could parse the trivial udev rules [1].
One option that might be best (but slightly controversial) would be for
FreeBSD or Solaris to present a Linux compatible /sys device tree,
either populated in userspace, or better, in the kernel.
Even if The FreeBSD guys couldn't get a DeviceKit daemon ready for the
2.26 release, they can happily ship supported 2.24 code until they do.
Richard.
[1] ATTR{idVendor}=="046d", ATTR{idProduct}=="c50e", ENV{ID_PRODUCT}="MX1000
Laser Mouse", ENV{DKP_BATTERY_TYPE}="mouse"
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Richard Hughes wrote: DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit daemon which is a thin dbus wrapper around udev. As udev is Linux-specific AFAIK, is there support for any other Unix platform in DeviceKit? If we lost FreeBSD support for instance, that would be a regression (hal works there). Regards, Denis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Mon, 2008-11-24 at 20:00 +0100, Michael Biebl wrote: > If the DeviceKit-power daemon does data collection and stuff, > shouldn't it be then running all the time (and as soon during the boot > process as possible)? Sure, you could start them easily at boot (a single DBUS send request would do it) but I would argue boot time is not interesting, and it needs to happen as quickly as possible. > What about DeviceKit-disks and S.M.A.R.T. monitoring (which I think it > does): > If the service is only started as soon as you log in and start an > application like palimpsest, isn't there a risk that we could miss > important events, i.e. shouldn't DeviceKit-disks not also be started > as soon as possible and running all the time? That's a different discussion :-) Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 04:19 +0100, Frederic Peters wrote: > Richard Hughes wrote: > > > During the 2.25 release cycle I would like to move GNOME Power Manager > > away from a HAL dependency and onto a new DeviceKit-power dependency. > > Will g-p-m break on non-DeviceKit-powered systems or will it handle > this case gracefully, falling back to the current code ? If you compile with --enable-devicekit and then don't install then it will fallback to showing nothing in the panel. Falling back to HAL from DeviceKit is very complicated in the current code, the equivalent is having your dodge viper with it's V10 fall back to a 55cc moped engine. Technically possible, but not a very good idea. Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Richard Hughes wrote: > During the 2.25 release cycle I would like to move GNOME Power Manager > away from a HAL dependency and onto a new DeviceKit-power dependency. Will g-p-m break on non-DeviceKit-powered systems or will it handle this case gracefully, falling back to the current code ? Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
> interaction e.g. for device locking). If a few core modules (gvfs, > nautilus, gnome-mount) are ported to hal, we should be in good shape > for 2.26. > You probably mean migrated to DeviceKit (or migrated away from hal) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Mon, Nov 24, 2008 at 4:23 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: > Le lundi 24 novembre 2008, à 18:25 +, Richard Hughes a écrit : >> Q: Is anything else going to use DeviceKit-$foo? >> A: In the future gvfs will depend on DeviceKit-disks, not HAL > > Does it sound possible to port all GNOME away from hal to DeviceKit-$foo > in the 2.26 timeframe? No, it doesn't sound feasible, really. There is quite a long list of hal dependencies ( http://fedoraproject.org/wiki/Features/DeviceKit#Scope ). But thankfully, it is not really necessary to port everything immediately, hal and DeviceKit can happily coexist (with some minimal interaction e.g. for device locking). If a few core modules (gvfs, nautilus, gnome-mount) are ported to hal, we should be in good shape for 2.26. Matthias (hoping David will correct him when he misrepresents things) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Le lundi 24 novembre 2008, à 18:25 +, Richard Hughes a écrit : > Q: Is anything else going to use DeviceKit-$foo? > A: In the future gvfs will depend on DeviceKit-disks, not HAL Does it sound possible to port all GNOME away from hal to DeviceKit-$foo in the 2.26 timeframe? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
thanks, Matthias. On Mon, 2008-11-24 at 13:45 -0500, Matthias Clasen wrote: > > (thinly veiled self-interest: when is DeviceKit-disks going to be > > released, so we can dump gfloppy and use DK-disks that instead?) > > I don't think there has been a proper DeviceKit-disks release yet. > The current plan is to have a solid DeviceKit-disks release together > with a gvfs backend and various other necessary bits of porting > by next spring. But the snapshots of DK-disks and gnome-disk-utility > that we currently ship in Fedora work fine, as far as I can tell. awesome! ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
2008/11/24 Richard Hughes <[EMAIL PROTECTED]>: > > Q: Why is system wide better? > A: There's no point doing the data collection, statistics profiling and > calculations in every session on a multiuser workstation. There's also > the point that at GDM you run a g-p-m instance, which doesn't have > access to the profiling data you generate in the session, and so you get > "unknown time remaining". > > > Q: Yet another system daemon?!? > A: No, all the DeviceKit daemons are system activated and low footprint, > so if you don't need them they don't get started. > If the DeviceKit-power daemon does data collection and stuff, shouldn't it be then running all the time (and as soon during the boot process as possible)? What about DeviceKit-disks and S.M.A.R.T. monitoring (which I think it does): If the service is only started as soon as you log in and start an application like palimpsest, isn't there a risk that we could miss important events, i.e. shouldn't DeviceKit-disks not also be started as soon as possible and running all the time? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
Le lundi 24 novembre 2008 à 18:25 +, Richard Hughes a écrit : > DeviceKit-power is a new mechanism daemon that moves the battery > profiling and statistics interface system-wide, and also does the > history recording once per system, rather than once per session. It also > moves to an interface that is legacy-free and is more focused on the > entire power management system than HAL ever was. I have been wondering for a while why g-p-m was per-session and not system-wide, so kudos for making it happen. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
On Mon, Nov 24, 2008 at 1:32 PM, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > hi; > > while I really love DeviceKit, there are a couple of questions I'd like > to have an answer: > > On Mon, 2008-11-24 at 18:25 +, Richard Hughes wrote: > >> DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit >> daemon which is a thin dbus wrapper around udev. > > while DeviceKit has seen at least one release, has there been a release > of DeviceKit-power? You can find DeviceKit and DeviceKit-power releases at http://hal.freedesktop.org/releases/ > > (thinly veiled self-interest: when is DeviceKit-disks going to be > released, so we can dump gfloppy and use DK-disks that instead?) I don't think there has been a proper DeviceKit-disks release yet. The current plan is to have a solid DeviceKit-disks release together with a gvfs backend and various other necessary bits of porting by next spring. But the snapshots of DK-disks and gnome-disk-utility that we currently ship in Fedora work fine, as far as I can tell. > is DeviceKit, and DK-power at that, supported by any distro? can I > compile them on a Debian without distro-specific tweaking, or do I need > Fedora to have them work properly? I think the main requirement is a recent udev (>= 130) Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
hi; while I really love DeviceKit, there are a couple of questions I'd like to have an answer: On Mon, 2008-11-24 at 18:25 +, Richard Hughes wrote: > DeviceKit-power and DeviceKit-disks just depend on the trivial DeviceKit > daemon which is a thin dbus wrapper around udev. while DeviceKit has seen at least one release, has there been a release of DeviceKit-power? (thinly veiled self-interest: when is DeviceKit-disks going to be released, so we can dump gfloppy and use DK-disks that instead?) is DeviceKit, and DK-power at that, supported by any distro? can I compile them on a Debian without distro-specific tweaking, or do I need Fedora to have them work properly? ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
