Re: non-local D-Bus (was: New libgtop maintainer)
On 11/08/13 12:46, Jasper St. Pierre wrote: I think we've said that remote DBus is possible, but would take a considerable amount of work to actually get working. Cross-posting to dbus@ for this reply since I don't think we've really written this down anywhere. Here is my opinion on remote D-Bus, as a D-Bus maintainer: * The well-known session bus is local. If you don't mind everyone capable of spoofing TCP on your local LAN being privileged (possibly root-equivalent) on your machine, it is, or used to be, possible to share it over TCP, in conjunction with home directories shared via NFS or something. We don't intentionally break that configuration, but we don't test or support it either. It wouldn't surprise me if more opinionated projects like systemd *do* intentionally break non-local session buses at some point, and to be honest that would probably be a good thing for general system robustness. * As far as I'm concerned, the well-known system bus (on Unix only) is local and always has been. If you want to access another system's system bus remotely, opening a ssh tunnel to something equivalent to socat is one sensible approach (I believe udisks remote management works like that). * Non-standard buses (like the AT-SPI accessibility bus) are designed by whoever sets them up; they get to say whether that bus is local, remote, or either-according-to-sysadmin-choice. I would recommend always-local. dbus.fd.o will not intentionally break non-standard buses, but we don't specifically test or support them either. If you rely on non-local D-Bus, please be prepared to send us patches when we accidentally break it. I would accept high-quality patches to improve non-local D-Bus, but my top priorities are the well-known session and system buses in a local-only configuration, as seen in typical Linux distributions. Regards, S ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On 11/08/13 13:20, Maciej Piechotka wrote: As a question - what about timeouts? Usually gnome-system-monitor is useful when there is heavy I/O, CPU usage or swapping and in such cases dbus timeouts can and do happen. During system bus service activation (the first time the system service is started), there are a couple of timeouts that are only configurable system-wide by the sysadmin: the activated system service must connect to the system bus within 'activation_timeout' milliseconds (25 seconds by default), although I think systemd activation might bypass this and have its own timeout inside systemd instead. Once it has started authentication, it must also complete authentication within 'auth_timeout' milliseconds (30 seconds by default) to make it harder to DoS the system bus. For method calls and replies once the system service is already up, ask yourself how long am I prepared to wait for this information? and set your timeout accordingly. Method calls usually use the special timeout of -1 milliseconds (interpreted as an implementation-dependent default, which in practice is 25 seconds) but whenever this is not reconfigurable by the caller, that should be considered to be a library bug. S ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 1:46 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: On Sun, Aug 11, 2013 at 7:28 AM, Robert Roth robert.roth@gmail.com wrote: On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com wrote: Hello everyone, Matthias Clasen (mclasen) asked me to write and let you know that I will be taking over the maintenance of libgtop. libgtop is the library used by System Monitor and Control Center (if you are a developer of an application using libgtop, please let me know) to query system information, but unfortunately the development has stalled, the last release has happened in 2011, almost two years ago. My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Thanks for reading, I was trying to hack on the libgtop code a little while ago, and I just found it hard to hack on. The code was generated, and it seemed to be put together by this giant mess of perl scripts. I've also hacked some small features in the libgtop code, and wasn't hard, but maybe I took only the low-hanging fruits. Extending existing libgtop implementations (meaning include/... and sysdeps/linux/... code) with new features looked pretty hassle-free for me. Of course, If there are server changes required (I don't know cases when we would need that, I didn't need any so far), it might be hard. My case was https://bugzilla.gnome.org/show_bug.cgi?id=663265 It took a while to figure out how everything was generated and pieced together. So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? I guess the client-server split is required for the root access indeed, in that case replacing it with a DBUS system service would be an option, but seems like libgtop is a server indeed, and can be connected to from the network too, and I don't know whether that's possible with DBUS, Hm, I didn't know it was supposed to be connectable from the network. In fact, when I read the code a little while ago, I swore it only listened on a UNIX socket. I think we've said that remote DBus is possible, but would take a considerable amount of work to actually get working. I'm not sure how true that is nowadays. No dbus is not a network protocol. It is simply not designed for that kind of use. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sat, Aug 10, 2013 at 2:42 PM, Matthias Clasen matthias.cla...@gmail.comwrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com wrote: My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Tbh, I think it would be good to start out by reevaluating the rationale for this library. Do we really need it anymore ? What data does g-s-m get from it ? For storage-related data, gio has probably encroached into the territory already. You might be right on that, I will check what GIO can do. For other data, libgtop is mostly a thin wrapper of /proc, iirc. Thas is true for linux systems, but libgtop also supports some BSDs, and other systems, which don't seem to have a procfs and e.g. control-center uses the sysinfo requested from libgtop, implemented as a thin /proc wrapper on linux, and as a bunch of sysctl calls on OpenBSD (these are the two implementations I have checked now, the OpenBSD implementation being the most active libgtop port, and the linux one for obvious reasons). So even if we only look at getting the number of cores, this is an information we need both in System Monitor and Control Center, and dropping libgtop would mean we'd have to implement at least for Linux and OpenBSD in both GCC and GSM, which is obvious code duplication, something to avoid, if we already have it in one place. I could be wrong, of course. I'm open for discussion on the topic, but I would say that libgtop should be kept and developed further as the library to get system info in GNOME projects. Please share your ideas, thoughts on the topic. Robert --- Robert Roth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sat, Aug 10, 2013 at 3:09 PM, Robert Roth robert.roth@gmail.com wrote: On Sat, Aug 10, 2013 at 2:42 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com wrote: My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Tbh, I think it would be good to start out by reevaluating the rationale for this library. Do we really need it anymore ? What data does g-s-m get from it ? For storage-related data, gio has probably encroached into the territory already. You might be right on that, I will check what GIO can do. For other data, libgtop is mostly a thin wrapper of /proc, iirc. Thas is true for linux systems, but libgtop also supports some BSDs, and other systems, which don't seem to have a procfs Before we take this fact into consideration here, perhaps we should first find out if a modern GNOME system actually work on BSD. We wouldn't want to end up like some projects where they create several abstraction layers to ensure portability and then have only one working implementation underneath. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.comwrote: Hello everyone, Matthias Clasen (mclasen) asked me to write and let you know that I will be taking over the maintenance of libgtop. libgtop is the library used by System Monitor and Control Center (if you are a developer of an application using libgtop, please let me know) to query system information, but unfortunately the development has stalled, the last release has happened in 2011, almost two years ago. My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Thanks for reading, I was trying to hack on the libgtop code a little while ago, and I just found it hard to hack on. The code was generated, and it seemed to be put together by this giant mess of perl scripts. So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? The other thing is that libgtop seems to be munging a lot of procfs files. I wonder if it'or something (completely made up example). s possible to investigate new kernel APIs or make ones so that instead of looking for MemTotal: in /proc/meminfo, we could just read /proc/mem/memtotal Robert -- Robert Roth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 01:13:40PM +0300, Zeeshan Ali (Khattak) wrote: On Sat, Aug 10, 2013 at 3:09 PM, Robert Roth robert.roth@gmail.com wrote: On Sat, Aug 10, 2013 at 2:42 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com wrote: My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Tbh, I think it would be good to start out by reevaluating the rationale for this library. Do we really need it anymore ? What data does g-s-m get from it ? For storage-related data, gio has probably encroached into the territory already. You might be right on that, I will check what GIO can do. For other data, libgtop is mostly a thin wrapper of /proc, iirc. Thas is true for linux systems, but libgtop also supports some BSDs, and other systems, which don't seem to have a procfs Before we take this fact into consideration here, perhaps we should first find out if a modern GNOME system actually work on BSD. We It does. I am actually running a full GNOME 3.8.3 installation on OpenBSD. And part of my job is to deploy such combo on hundreds of machines. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 1:49 PM, Antoine Jacoutot ajacou...@gnome.orgwrote: On Sun, Aug 11, 2013 at 01:13:40PM +0300, Zeeshan Ali (Khattak) wrote: On Sat, Aug 10, 2013 at 3:09 PM, Robert Roth robert.roth@gmail.com wrote: On Sat, Aug 10, 2013 at 2:42 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com wrote: My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Tbh, I think it would be good to start out by reevaluating the rationale for this library. Do we really need it anymore ? What data does g-s-m get from it ? For storage-related data, gio has probably encroached into the territory already. You might be right on that, I will check what GIO can do. For other data, libgtop is mostly a thin wrapper of /proc, iirc. Thas is true for linux systems, but libgtop also supports some BSDs, and other systems, which don't seem to have a procfs Before we take this fact into consideration here, perhaps we should first find out if a modern GNOME system actually work on BSD. We It does. I am actually running a full GNOME 3.8.3 installation on OpenBSD. And part of my job is to deploy such combo on hundreds of machines. For me this is a pretty good and solid argument for keeping libgtop as an abstraction layer for getting system information, even if we would only have OpenBSD and linux-based systems using GNOME, even if there would be only these two implementations (but there are some more). In fact keeping everything up-to-date, buildable and ported to each system seems like the biggest challenge for me in maintaining libgtop, and would appreciate users of non-linux based OSs using GNOME willing to help sending me a note to know who can test newly ported/help porting new code. Robert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 02:17:29PM +0300, Robert Roth wrote: It does. I am actually running a full GNOME 3.8.3 installation on OpenBSD. And part of my job is to deploy such combo on hundreds of machines. For me this is a pretty good and solid argument for keeping libgtop as an abstraction layer for getting system information, even if we would only have OpenBSD and linux-based systems using GNOME, even if there would be only these two implementations (but there are some more). In fact keeping everything up-to-date, buildable and ported to each system seems like the biggest challenge for me in maintaining libgtop, and would appreciate users of non-linux based OSs using GNOME willing to help sending me a note to know who can test newly ported/help porting new code. You can count on Jasper L.A (jas...@openbsd.org) and myself (ajacou...@openbsd.org) to keep maintaining the OpenBSD backend. -- Antoine ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre jstpie...@mecheye.netwrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.comwrote: Hello everyone, Matthias Clasen (mclasen) asked me to write and let you know that I will be taking over the maintenance of libgtop. libgtop is the library used by System Monitor and Control Center (if you are a developer of an application using libgtop, please let me know) to query system information, but unfortunately the development has stalled, the last release has happened in 2011, almost two years ago. My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Thanks for reading, I was trying to hack on the libgtop code a little while ago, and I just found it hard to hack on. The code was generated, and it seemed to be put together by this giant mess of perl scripts. I've also hacked some small features in the libgtop code, and wasn't hard, but maybe I took only the low-hanging fruits. Extending existing libgtop implementations (meaning include/... and sysdeps/linux/... code) with new features looked pretty hassle-free for me. Of course, If there are server changes required (I don't know cases when we would need that, I didn't need any so far), it might be hard. So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? I guess the client-server split is required for the root access indeed, in that case replacing it with a DBUS system service would be an option, but seems like libgtop is a server indeed, and can be connected to from the network too, and I don't know whether that's possible with DBUS, The other thing is that libgtop seems to be munging a lot of procfs files. I wonder if it'or something (completely made up example). s possible to investigate new kernel APIs or make ones so that instead of looking for MemTotal: in /proc/meminfo, we could just read /proc/mem/memtotal See the discussion in the thread for more details, it's not only about procfs, it's completely different for *BSD systems. The linux implementation could probably be improved by reading /proc/mem/memtotal , but if we read /proc/meminfo for other information anyway, maybe searching for MemTotal: in the file is less expensive than reading another file from procfs --- Robert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
. In fact keeping everything up-to-date, buildable and ported to each system seems like the biggest challenge for me in maintaining libgtop, and would appreciate users of non-linux based OSs using GNOME willing to help sending me a note to know who can test newly ported/help porting new code. Sounds good to me. Thanks for stepping up to maintain it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, Aug 11, 2013 at 7:28 AM, Robert Roth robert.roth@gmail.comwrote: On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre jstpie...@mecheye.netwrote: On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.comwrote: Hello everyone, Matthias Clasen (mclasen) asked me to write and let you know that I will be taking over the maintenance of libgtop. libgtop is the library used by System Monitor and Control Center (if you are a developer of an application using libgtop, please let me know) to query system information, but unfortunately the development has stalled, the last release has happened in 2011, almost two years ago. My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Thanks for reading, I was trying to hack on the libgtop code a little while ago, and I just found it hard to hack on. The code was generated, and it seemed to be put together by this giant mess of perl scripts. I've also hacked some small features in the libgtop code, and wasn't hard, but maybe I took only the low-hanging fruits. Extending existing libgtop implementations (meaning include/... and sysdeps/linux/... code) with new features looked pretty hassle-free for me. Of course, If there are server changes required (I don't know cases when we would need that, I didn't need any so far), it might be hard. My case was https://bugzilla.gnome.org/show_bug.cgi?id=663265 It took a while to figure out how everything was generated and pieced together. So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? I guess the client-server split is required for the root access indeed, in that case replacing it with a DBUS system service would be an option, but seems like libgtop is a server indeed, and can be connected to from the network too, and I don't know whether that's possible with DBUS, Hm, I didn't know it was supposed to be connectable from the network. In fact, when I read the code a little while ago, I swore it only listened on a UNIX socket. I think we've said that remote DBus is possible, but would take a considerable amount of work to actually get working. I'm not sure how true that is nowadays. The other thing is that libgtop seems to be munging a lot of procfs files. I wonder if it'or something (completely made up example). s possible to investigate new kernel APIs or make ones so that instead of looking for MemTotal: in /proc/meminfo, we could just read /proc/mem/memtotal See the discussion in the thread for more details, it's not only about procfs, it's completely different for *BSD systems. The linux implementation could probably be improved by reading /proc/mem/memtotal , but if we read /proc/meminfo for other information anyway, maybe searching for MemTotal: in the file is less expensive than reading another file from procfs Well, my goal was to get all munging out of libgtop entirely (for Linux, at least) and move to better interfaces entirely. Perhaps /proc/mem/memtotal is a bad example because sysinfo() exists. And we should probably use that instead of parsing /proc/meminfo. --- Robert -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
Il giorno dom, 11/08/2013 alle 06.45 -0400, Jasper St. Pierre ha scritto: So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? I think that root access is required if we want to implement monitoring of: * per process disk activity (à la iotop) * per process network usage (à la nethogs) That said, a DBus service should be perfectly fine for these features. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Sun, 2013-08-11 at 14:03 +0200, Stefano Facchini wrote: Il giorno dom, 11/08/2013 alle 06.45 -0400, Jasper St. Pierre ha scritto: So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? I think that root access is required if we want to implement monitoring of: * per process disk activity (à la iotop) * per process network usage (à la nethogs) That said, a DBus service should be perfectly fine for these features. As a question - what about timeouts? Usually gnome-system-monitor is useful when there is heavy I/O, CPU usage or swapping and in such cases dbus timeouts can and do happen. Moving into more complex area - since application handling on Linux moves to systemd+cgroups would it make sense to get information per cgroup rather then per-process (+ nice user-readable name such as Web or Epiphany rather then /usr/libexec/WebKitPluginProcess)? Possibly something less readable for systems without cgroup-like session handling. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
Il giorno dom, 11/08/2013 alle 14.20 +0200, Maciej Piechotka ha scritto: On Sun, 2013-08-11 at 14:03 +0200, Stefano Facchini wrote: Il giorno dom, 11/08/2013 alle 06.45 -0400, Jasper St. Pierre ha scritto: So, I wonder if it makes sense to stop generating libgtop and instead just focus on a solid, easily understood codebase. I never really understood why we had a client/daemon split, either; it doesn't seem that we're doing anything too fancy on either side. Is it that we require root for reading some of the files? Should we move to a system DBus service instead? I think that root access is required if we want to implement monitoring of: * per process disk activity (à la iotop) * per process network usage (à la nethogs) That said, a DBus service should be perfectly fine for these features. As a question - what about timeouts? Usually gnome-system-monitor is useful when there is heavy I/O, CPU usage or swapping and in such cases dbus timeouts can and do happen. Yes you're right, when there's high disk activity dbus can be slow. I was more thinking of network usage, because it's the only one I started prototyping as DBus service :) Moving into more complex area - since application handling on Linux moves to systemd+cgroups would it make sense to get information per cgroup rather then per-process (+ nice user-readable name such as Web or Epiphany rather then /usr/libexec/WebKitPluginProcess)? Possibly something less readable for systems without cgroup-like session handling. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New libgtop maintainer
On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth robert.roth@gmail.com wrote: My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Tbh, I think it would be good to start out by reevaluating the rationale for this library. Do we really need it anymore ? What data does g-s-m get from it ? For storage-related data, gio has probably encroached into the territory already. For other data, libgtop is mostly a thin wrapper of /proc, iirc. I could be wrong, of course. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
New libgtop maintainer
Hello everyone, Matthias Clasen (mclasen) asked me to write and let you know that I will be taking over the maintenance of libgtop. libgtop is the library used by System Monitor and Control Center (if you are a developer of an application using libgtop, please let me know) to query system information, but unfortunately the development has stalled, the last release has happened in 2011, almost two years ago. My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, only for the next cycle) are to review the buglist of the module, and extend it to provide library support for various gnome-system-monitor enhancement requests, but in the meantime keep it simple and fast enough to back the upcoming Usage application. Thanks for reading, Robert -- Robert Roth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
