Anti Theft Software
Hello, I want to make an anti thief software for Gnome. This project will be a part of GSoc I am really excited about the project but I need ideas for the software. http://www.guardian.co.uk/technology/blog/2009/mar/02/laptop-shouts-stop-thiefhas some good existing solutions for windows and mac. Geoclue and gnome-screensaver can be used, please pour in some ideas. Regards -- hasanatka...@gmail.com I hate Capitalism,so naturally I love Open Source -- Hasanat Kazmi +923464362473 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anti Theft Software
2009/3/23 Dr. Michael J. Chudobiak m...@avtechpulse.com: Hasanat Kazmi wrote: Geoclue and gnome-screensaver can be used, please pour in some ideas. You would probably want to modify gdm (the login manager), rather than gnome-screensaver, so that the thief doesn't have to log in to be tracked... It could even be a daemon, with Gtk+ configuration screens :) Pierre-Luc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anti Theft Software
On Mon, Mar 23, 2009 at 5:31 AM, Hasanat Kazmi hasanatka...@gmail.com wrote: I want to make an anti thief software for Gnome. This project will be a part of GSoc That should read. This project will be proposed for GSoC. The student application window opens today and no proposals have been accepted yet. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anti Theft Software
Hi, did you look at: http://adeona.cs.washington.edu/ Pierre-Luc Beaudoin wrote: 2009/3/23 Dr. Michael J. Chudobiak m...@avtechpulse.com: Hasanat Kazmi wrote: Geoclue and gnome-screensaver can be used, please pour in some ideas. You would probably want to modify gdm (the login manager), rather than gnome-screensaver, so that the thief doesn't have to log in to be tracked... It could even be a daemon, with Gtk+ configuration screens :) Pierre-Luc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Konstantin Kozlov Department of Computational Biology, Center for Advanced Studies, SPb State Polytechnical University, 195251, Polytechnicheskaya ul., 29, bld 4, office 204, St.Petersburg, Russia. Tel./fax: +7 812 596 2831 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anti Theft Software
Hasanat Kazmi wrote: Hello, I want to make an anti thief software for Gnome. This project will be a part of GSoc I am really excited about the project but I need ideas for the software. http://www.guardian.co.uk/technology/blog/2009/mar/02/laptop-shouts-stop-thief has some good existing solutions for windows and mac. Geoclue and gnome-screensaver can be used, please pour in some ideas. You would probably want to modify gdm (the login manager), rather than gnome-screensaver, so that the thief doesn't have to log in to be tracked... - Mike ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anti Theft Software
integrating it with gdm may make it breakable, I mean hacker may login without gnome, in that case, he can still access whole file system while the software (if it is a part of gdm) will remain ignorant of this act as it is not executed. Running it as deamon seems a good idea, though it can also be broken but before hacker gets gets to stop it, it would have encrypted file system or atleast has executed halt command (or may be something similar to the computer unuseable) Adeona also runs as deamon, we can definetly use mic, webcam, ipadresses, traceroute, GeoGlue ( I am not sure about it), what do you people say On Mon, Mar 23, 2009 at 5:12 PM, Adam Schreiber sa...@clemson.edu wrote: On Mon, Mar 23, 2009 at 8:03 AM, Hasanat Kazmi hasanatka...@gmail.com wrote: Hello Adam, True that, thats my bad , the project will be proposed, its yet not part of Gnome No worries. I just wanted to make sure everyone had the right idea. I'll look forward to a very thought out and detailed proposal. Cheers, Adam On Mon, Mar 23, 2009 at 4:59 PM, Adam Schreiber sa...@clemson.edu wrote: On Mon, Mar 23, 2009 at 5:31 AM, Hasanat Kazmi hasanatka...@gmail.com wrote: I want to make an anti thief software for Gnome. This project will be a part of GSoc That should read. This project will be proposed for GSoC. The student application window opens today and no proposals have been accepted yet. Cheers, Adam -- hasanatka...@gmail.com I hate Capitalism,so naturally I love Open Source -- Hasanat Kazmi +923464362473 -- hasanatka...@gmail.com I hate Capitalism,so naturally I love Open Source -- Hasanat Kazmi +923464362473 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Mea Culpa: If you've been rejected from being a Summer of Code mentor on the basis of not being a Foundation member, please reapply
Hi all, Sorry for this spam, but apparently I've been a little overzealous in enforcing our requirement that only GNOME Foundation members can be Summer of Code mentors. In fact, if you are not a foundation member but easily could be, you are more than welcome as a mentor! So, if you have received a rejection for your mentor application, and you feel that your contributions are enough to hypothetically receive Foundation membership, please accept my apologies and reapply. We can always use more mentors, even if you just want to help with ranking proposals. The proposal period opens today, so now is a great time to join. :-) Thanks for your time, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mea Culpa: If you've been rejected from being a Summer of Code mentor on the basis of not being a Foundation member, please reapply
If you are contributor to GNOME, I strongly encourage you to apply for and become a GNOME Foundation member. It makes it easier for us to confirm you to outside organizations like this, for travel sponsorships for GNOME events *and* it shows the strength of the GNOME Foundation and the GNOME project. Best, Stormy On Mon, Mar 23, 2009 at 12:51 PM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: Hi all, Sorry for this spam, but apparently I've been a little overzealous in enforcing our requirement that only GNOME Foundation members can be Summer of Code mentors. In fact, if you are not a foundation member but easily could be, you are more than welcome as a mentor! So, if you have received a rejection for your mentor application, and you feel that your contributions are enough to hypothetically receive Foundation membership, please accept my apologies and reapply. We can always use more mentors, even if you just want to help with ranking proposals. The proposal period opens today, so now is a great time to join. :-) Thanks for your time, Sandy ___ 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
Metacity, Mutter, GNOME Shell, GNOME-2.28
Now that the GNOME-2.27 cycle is beginning, I'd like to come up with a definitive plan for how we are going to be developing the Metacity codebase in the context of Mutter and gnome-shell. To review the current situation: - Metacity is developed in GNOME svn by Thomas Thurman and others. This version has some not-very-maintained RENDER compositing support, but is mostly the old classic WM we know and love. - Intel has a branch of metacity (called Mutter or metacity-clutter) that virtualizes compositing to support either RENDER (not maintained or tested) or GL and Clutter. This installs as 'metacity' and is cannot be parallel installed with normal metacity. - gnome-shell has its own private Mutter branch (on my personal server). Most changes we made have been merged into the Mutter branch and in some cases metacity, but there are some unmerged changes related, in particular, to custom keybindings and gobject-introspection support. gnome-shell is set up as a Mutter plugin that is largely written in Javascript and talks to Metacity and to libraries via gobject-introspection. The 'gnome-shell' executable is a Python wrapper script that runs metacity --mutter-plugins=gnome-shell. I have two strong goals for this development cycle; the first is that there is a centralized location for development of the Metacity+Clutter codebase, and that centralized location is in GNOME version control. The second is that when GNOME-2.28 is released users can install gnome-shell as part of their normal system and chose between it and normal Metacity. With that in mind, there are a couple of approaches that could be taken: 1) The Mutter and gnome-shell changes could be folded back into normal metacity; the goal of being able to run a normal uncomposited desktop for GNOME-2.28 would likely require keeping the dual composited and non-composited code-paths. These code paths exist currently in mutter, but aren't that well tested, are a bit of a pain to maintain and make some types of changes distinctly harder. There's a risk that we'd destabilize non-composited Metacity without providing any benefits. 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. 3) The source code could be imported into gnome-shell, the Mutter plugin system removed, and the use of Javascript hard-coded. Customization/extension would be done as Javascript extensions, which could conceivably entirely replace the gnome-shell UI with something else. An advantage here is that over time, the core Window management logic could be gradually rewritten in Javascript and the C core stripped down. Of these alternatives, while I have some fondness for the third approach, the second seems most immediately practical. There's a development philosophy that will help keep it closer to what we could achieve with the third approach, which is to see the plugin system as only a loader: once the plugin is loaded it talks directly to the Metacity core, which is extended as necessary. (Things have been moving in this direction already; it's become easier to hook into Metacity now that the core objects are largely GObject-ified allowing signals and properties.) If people agree with that (better ideas than any of the above also appreciated!) then we can move almost immediately. Nobody would be forced to switch from the current metacity-clutter repository, of course. Mechanical question of the transition would include: - Do we want to import Mutter as it exists now, and evolve from that, keeping all the version control history, or do we want to break it up, review it, remove dead ends (like the multiple compositor backends) and commit it as a fresh patch sequence. The second would be an enormous amount of work, and probably not worth it. - If we import Mutter as it exists now, do we import it literally, or do we convert Metacity using the git = svn import scripts, then rebase Mutter on top of that. I think the quality of the latter is considerably better and would recommend that. (And do we want historical maintenance branches of Metacity in the Mutter repository? I think not.) - What commit policies do we have for the Mutter module? I'm thinking that we go pretty wide open but with the requirement that every not-absolutely-trivial change needs one review. So, that's my thinking. Feedback appreciated. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote: 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. I'd like to toss in here: 4) o Import mutter as a branch of metacity o When built, it installs its binary by default by default as metacity-compositor o We share a common GConf schema subset (even if e.g. compositor has a few more keys) o We share the bugzilla name metacity o Replay some of the non-compositing changes like GObject-ification and introspection support on to mainline to reduce the divergence There are some tradeoffs here, but I'd like to avoid creating a distinct mutter brand and forking the GConf keys, even if the display technology is changing a lot. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote: On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor otay...@redhat.com wrote: 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. I'd like to toss in here: 4) o Import mutter as a branch of metacity o When built, it installs its binary by default by default as metacity-compositor o We share a common GConf schema subset (even if e.g. compositor has a few more keys) o We share the bugzilla name metacity o Replay some of the non-compositing changes like GObject-ification and introspection support on to mainline to reduce the divergence There are some tradeoffs here, but I'd like to avoid creating a distinct mutter brand and forking the GConf keys, even if the display technology is changing a lot. A branch in the (future) Metacity git repository is an interesting idea, in that it allows changes to be moved somewhat more conveniently between the trees. But it could also be confusing, and unless you are going to keep on merging Metacity wholesale into mutter, there's not a big advantage in having them in the same repository. 'git cherry-pick' has no special intelligence over just applying a patch. How would you see packaging and installation working with your scheme? I don't see how different programs (metacity and metacity-clutter) could share the same GConf schema keys. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, Mar 23, 2009 at 5:11 PM, Owen Taylor otay...@redhat.com wrote: But it could also be confusing, and unless you are going to keep on merging Metacity wholesale into mutter, there's not a big advantage in having them in the same repository. 'git cherry-pick' has no special intelligence over just applying a patch. Right, it's mostly a branding thing. How would you see packaging and installation working with your scheme? OS vendors would need to ship separate metacity-compositor packages. metacity-compositor would Depend: metacity. I don't see how different programs (metacity and metacity-clutter) could share the same GConf schema keys. What problems do you see? Basically mutter would depend on the metacity schemas being installed from mainline. Thinking about this a bit more, the end of this path is that the schemas, translations etc. are removed from the compositor branch, and it's really a separate project that depends on metacity installed. It just has a fork of the core code and installs a distinct binary name. Anyways I'm not opposed to any of 1) 2) or 3), I just wanted this option out there on the table to think through. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Mon, 2009-03-23 at 17:23 -0400, Colin Walters wrote: On Mon, Mar 23, 2009 at 5:11 PM, Owen Taylor otay...@redhat.com wrote: But it could also be confusing, and unless you are going to keep on merging Metacity wholesale into mutter, there's not a big advantage in having them in the same repository. 'git cherry-pick' has no special intelligence over just applying a patch. Right, it's mostly a branding thing. In my mind, the brand is GNOME Shell. I don't think we need to brand the bits of GNOME Shell that are written in C separately. metacity-compositor is more descriptive, so probably better for an unbranded component, but I'm not sure enough better to switch back again. How would you see packaging and installation working with your scheme? OS vendors would need to ship separate metacity-compositor packages. metacity-compositor would Depend: metacity. Hmm, from the desktop vendor point of view, that's fine, especially for GNOME-2.28, though I do see more pendantic distros splitting metacity-schemas out of metacity. Not so good for the embedded case. I don't see how different programs (metacity and metacity-clutter) could share the same GConf schema keys. What problems do you see? Basically mutter would depend on the metacity schemas being installed from mainline. The problem I was referring was that two different projects can't install .schemas files with the same keys. If you didn't install the metacity schemas again, that would help. One conceivable problem is that it isn't clear to me that there's going to be a nice split of: A) Shared keys for Metacity and Mutter B) Mutter-specific keys After a while you might get to the point where it was pretty hard to guess what key was where... historical keys would be in one place, more recently added keys in another. Thinking about this a bit more, the end of this path is that the schemas, translations etc. are removed from the compositor branch, and it's really a separate project that depends on metacity installed. It just has a fork of the core code and installs a distinct binary name Splitting translations is going to be much more of a problem than schemas - how would you know if a string in mutter should be marked for translation or not looking at the code base? You wouldn't. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
Hi! 2) Mutter could be renamed as a project to mutter (binary, GConf schemas, etc. Presumably, the internals would stay Meta*) and imported into GNOME version control independently of metacity. The uncomposited and RENDER code paths would gradually be removed leaving just a Clutter based WM/CM. The main disadvantage of this approach is that any ongoing maintenance of Metacity would not feed from or to this project automatically. Actually I am bit in favor of this approach. Having the window manager and the shell separated has the advantage that they can be used independently. Think about things like Gnome Mobile or Netbooks - probably you want a composited wm here but you don't want GNOME Shell (but probably another shell that is based on a mutter-plugin). I also like that mutter would only keep that code that is based on clutter. The RENDER stuff is mostly taken care of by compiz and metacity is for non-composited Desktops. All three have their use-cases. That said, besides testing from time to time (which is restricted by the state of current open-source api drivers vs. bad performance on my intel-graphik netbook) I am not very involved in gnome-shell development. Regards, Johannes 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
Gnome Games will make 3D mandatory for 2.28
Now that 2.26 is out and we've begun to work on 2.28, I want to get this out early so that no one feels like this was a last minute surprise. This has been a year in the making and this development cycle appears to be the right time to put some polish on our new game engines and make them the default. This is not a proposal or RFC. This is what is happening; I am merely make it abundantly clear well in advance of it being released to the general public. Games which will require 3D for 2.28: * Gnometris * Lights Off (pending approval of Seed/GJS dependency during proposal period) * Same Gnome (pending approval of Seed/GJS dependency during proposal period) Games which may require 3D depending on the maturity of the engine for 2.28: * Aisleriot * GSoC project results (whatever they may be) I anticipate that two parties will be disappointed: LTSP deployments and owners of ATI graphics cards. Taking the later first, this group appears to be being well-addressed by Airlied's work; hopefully everything will just work by the time 2.28 is released. As a former LTSP admin/engineer/slave, I believe that this style of Linux terminal server deployment is deeply flawed and well on the way to being replaced by Live environments. Whatever your opinion, remember: these are just games. Don't take this announcement too seriously. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
