Re: [E-devel] e_dbus changes
On Fri, Apr 16, 2010 at 05:41, David Seikel onef...@gmail.com wrote: On Thu, 15 Apr 2010 19:02:01 +0200 Thomas Gstädtner tho...@gstaedtner.net wrote: On Thu, Apr 15, 2010 at 15:29, William Keaney kean...@gmail.com wrote: So you will still be able to hotplug as user, no problems there at all. Computers don't usually authenticate the random human, cat, or robot that actually physically plugs in a USB key; or wonders into range with a bluetooth thingy strapped to their tail. But yes, working with fstab without requiring it is GOOD. B-) If security is your concern: don't worry. You have a lot of possibilities there, the best one being policykit that allows you to set any kind of policy for any kind of attachable device. You can allow the random cat to put in cds and mount them, or you can disallow anyone to plug in a usb-stick and mount it. Or you can just disallow anything by policykit and use just fstab, there are almost no limits. -- Download Intel#174; 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_dbus changes
On Thu, Apr 15, 2010 at 05:46, m...@zentific.com wrote: udisks only allows mounting of drives that are in fstab as of now, so it seems like this might be the case. Then again, there are still a few things missing from it so it may just destroy your hopes and dreams like hal did :) I've just finished the first version of e-udev and it seems to be working pretty well. -Mike (zmike/discomfitor) All in all, devicekit (and the other *kits) seem to be the right approach. I'm glad that hal is finally dead and looking forward to drop it from my system. It's great, that you're implementing it in E, thanks! If you need testing before you commit it, just say a word. thomasg -- Download Intel#174; 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_dbus changes
On Wed, Apr 14, 2010 at 11:46 PM, m...@zentific.com wrote: udisks only allows mounting of drives that are in fstab as of now, so it seems like this might be the case. Then again, there are still a few things missing from it so it may just destroy your hopes and dreams like hal did :) I actually find this slightly concerning. What about removable media? I actually thought that NOT requiring users to edit fstab for every. single. disk. they plug in was a Good Thing(tm). I do agree that HAL's inability to cooperate with fstab is a problem, but I don't think that abandoning hotpluggable removable media is a valid solution either. Will Keaney uberpinguin -- Download Intel#174; 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_dbus changes
On Thu, Apr 15, 2010 at 15:29, William Keaney kean...@gmail.com wrote: On Wed, Apr 14, 2010 at 11:46 PM, m...@zentific.com wrote: udisks only allows mounting of drives that are in fstab as of now, so it seems like this might be the case. Then again, there are still a few things missing from it so it may just destroy your hopes and dreams like hal did :) I actually find this slightly concerning. What about removable media? I actually thought that NOT requiring users to edit fstab for every. single. disk. they plug in was a Good Thing(tm). I do agree that HAL's inability to cooperate with fstab is a problem, but I don't think that abandoning hotpluggable removable media is a valid solution either. That is not the case. It isn't true, that everything has to be in the fstab to enable devicekit-disks to mount it or whatsoever. Like it is with hal now, both is possible, /etc/fstab or auto-mounting by devicekit. The difference is, that this now works better. Devicekit-disks can mount fstab entries, as well as attached drives without an fstab entry, and much more. All in all, there is no loss in features by dropping hal in favor of device-kit, it just works better and is generally simpler. So you will still be able to hotplug as user, no problems there at all. -- Download Intel#174; 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_dbus changes
On Thu, 15 Apr 2010 19:02:01 +0200 Thomas Gstädtner tho...@gstaedtner.net wrote: On Thu, Apr 15, 2010 at 15:29, William Keaney kean...@gmail.com wrote: So you will still be able to hotplug as user, no problems there at all. Computers don't usually authenticate the random human, cat, or robot that actually physically plugs in a USB key; or wonders into range with a bluetooth thingy strapped to their tail. But yes, working with fstab without requiring it is GOOD. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Download Intel#174; 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___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e_dbus changes
Hi, I'm going to be attempting to write a new backend for e_dbus to use the new udisks/upower framework which is succeeding hal. Some questions I've been mulling over while I've been doing it: Should I be migrating all the hal/udev calls to some kind of e_dbus_* call system so that it will be transparent to developers regardless of the backend being used? The idea here being that only one backend can be enabled at compile time (since no sane person would have both hal AND udisks/upower running simultaneously), thus saving code migration in the future should another hw backend be created. What should the new module be called? Since the old one is e-hal, I figured I'd call the new one e-udev, though I'm open to whatever. Should udisks and upower functionality be integrated into the same module? I'm thinking yes, though if there's a reason why they should remain separate then that's fine too. I'm assuming that we want all the same calls that the hal module currently provides. Is there any additional functionality that we need/want? I'd link the udisks/upower api, but it doesn't really exist outside of the code; I can say that they can do pretty much everything you'd imagine them to do if that helps :) Also, does anyone know a better dbus debugger/utility? So far I've been using a combination of d-feet, qdbus, and dbus-monitor/send to do stuff but I actually need to use all of them to get the functionality I want. If anyone has any comments/questions I'll be around in #edevelop and checking here regularly. -Mike (discomfitor/zmike) -- Download Intel#174; 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_dbus changes
On Wed, 14 Apr 2010 12:49:25 -0400 Michael Blumenkrantz m...@zentific.com wrote: I'm going to be attempting to write a new backend for e_dbus to use the new udisks/upower framework which is succeeding hal. Some questions I've been mulling over while I've been doing it: /me hopes that unlike hal, this new stuff plays well with fstab, a unix standard that has been around forever. EndoOfGrumble BeginGetMorningCaffiene -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Download Intel#174; 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___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e_dbus changes
udisks only allows mounting of drives that are in fstab as of now, so it seems like this might be the case. Then again, there are still a few things missing from it so it may just destroy your hopes and dreams like hal did :) I've just finished the first version of e-udev and it seems to be working pretty well. -Mike (zmike/discomfitor) -- Download Intel#174; 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
