Re: Trying to reduce our memory and battery footprint
Le 17/10/2012 06:43, Martin Pitt a écrit : Do you have other cases in mind which would benefit from this? Hey Martin, The main benefit I'm looking forward having is finer granularity on startup conditions ... e.g why starting bluetooth-applet if there is no bluetooth device exposed by udev, we might just want to start it when a device is added. That's the case for quite some of our services, the GNOME wacom code should only be loaded if you have a compatible device. The gwibber lens should probably be stopped when you get offline, etc, etc Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
Le 16/10/2012 23:24, Robert Ancell a écrit : In conclusion I don't think we have anything to be worried about with GNOME OS at this point and by the time it did matter we may be sufficiently different anyway that it doesn't matter. Seems like GNOME OS is managing to get any discussion off-track, I shouldn't have used it there :p My point is mostly GNOME consider they should focus on their product on not downstream issues. I've heard speakers at GUADEC saying that GNOME shouldn't do compromises or efforts for distributors but that things should be the other way around ... distributors should make efforts for GNOME since their role is to distribute what upstream is doing. It's a fair statement but also a reality that shows, GNOME is less wanting to make efforts to accommodate distributors that it used to be (see how they manage transitions or hard/optional depends compared to how those were dealt with in the GNOME2 times) Cheers, Sebastien Bacher -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] accessibility
I would like the text cursor tracking zoom to be incorporated, there is code that works, it just needs to be incorporated properly https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/727290 https://code.launchpad.net/~gloob/compiz/texttracking I can understand dropping the themes, Unity doesn't really work with any non-default themes, accessible or otherwise. Why not go one step further and drop theme support? If themes are to come back in general it would be good to have some designed for low vision users in the list. Providing alternative GUIs for controlling some of the excellent compiz accessibility features would be good, show mouse is another one that is really good (stars that float around the mouse cursor without obscuring it). The OpenGL accelerated Enhanced zoom is fantastic - and actually makes the spread usable if you have more than about a dozen windows - you can zoom in and pan around, they are not all tiny thumbnails, we have this in, and turn it off by default (or have no key/mouse bindings for it) and it is one of the best features of the whole operating system! Alan. On 16/10/12 04:09, Jeremy Bicha wrote: I have three accessibility items. First, I'd like to drop the HighContrastInverse LowContrast themes. GNOME dropped support for these two themes late this cycle and they can no longer be set in an unpatched gnome-control-center. The idea is that this one theme will be significantly better than trying to support three mediocre themes. I hacked in support for these themes for 3.6.0 in Ubuntu 12.10 but gnome-themes-standard 3.6.1 isn't building for me yet with the hack. The two dropped themes aren't really terribly usable anyway, and unless someone steps up to maintain them, it's not worth the headache to try to keep them building. My second item is a requested feature. It would be really great if Unity would support the zoom and color effects built in to GNOME 3.6. By setting inverse or adjusting the brightness/conast this way, all apps (even web pages in your web browser) will respect your color setting. http://bicha.net/img/gnome-zoom1.png http://bicha.net/img/gnome-zoom2.png http://bicha.net/img/gnome-zoom3.png And finally, Unity includes a mostly hidden accessibility status menu. It's probably a good thing it's hidden as it's almost useless at the moment. I filed bug http://pad.lv/1067166 requesting that a replacement be designed and included in 13.04. Jeremy -- I work at http://libertus.co.uk -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Wed, 2012-10-17 at 13:18 +0100, Colin Watson wrote: On Wed, Oct 17, 2012 at 01:07:58PM +0100, James Hunt wrote: On 16/10/12 10:07, Colin Watson wrote: On Tue, Oct 16, 2012 at 09:59:11AM +0100, James Hunt wrote: The current thinking is in fact to have 1 process / user. I think Scott was suggesting that everything _can_ be handled by PID 1, but whilst that may be technically true, my view is that the benefits of 1 process / user outweigh having PID 1 handle everything. Won't this mean that you'll have to have extra complexity to have pid 1 tell the per-user upstart processes about dead processes, since only pid 1 is able to find out about these reliably? You'd need this, for example, to be able to have a respawning user job. Unclear at this stage: we are still gathering requirements, so no concrete design yet. However, iff the plan is to allow arbitrary amounts of data to be stored in a session, I'd prefer that to be external to PID 1 :-) I can understand that. I think we need a clear idea of how we're going to handle things like respawning before the desktop team makes any concrete plans, though; and preferably with a minimum of complex plumbing in upstart. It was my understanding that we could get this by upstart putting all of the processes in the user session in a cgroup for that user. This would require upstart to be the first process in the user session, but I think that's achievable. Is my understanding there incorrect? --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Wed, 2012-10-17 at 06:43 +0200, Martin Pitt wrote: snip I don't think the reason why starting Unity and starting the Dash takes so long is in any way related to startup order or that we wouldn't have a mechanism of starting things on demand (D-Bus activation works just fine for the most part). To be clear, I don't think that using upstart will materially effect the startup time of Unity or the desktop in general. There might be slight gains through clearer dependencies, but I don't think that's a reason to do it. I think you've pointed out some real issues there, but those are probably independent threads themselves. One opportunity where having session upstart (or systemd, FWIW) jobs would be handy is to finally replace update-notifier. It's become a collection of totally unrelated things (launching update-manager, launching Apport on crashes, launching Jockey on missing firmware, etc) just because we always need a session daemon to listen for events. This could be replaced by individual jobs that are triggered by uevents and inotify watches. This will help maintainability and improve memory usage a bit (2.5 MB RSS for upstart vs. 13 MB RSS update-notifier), and shouldn't noticeably increase CPU overhead. I think that this is the key benefit, and I think it happens in other places other than update-notifier. I think we need a way to remove the need for many of the long running services that we have in the desktop. --Ted signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Trying to reduce our memory and battery footprint
On Wed, 2012-10-17 at 08:43 -0700, Steve Langasek wrote: On Wed, Oct 17, 2012 at 08:43:31AM -0500, Ted Gould wrote: It was my understanding that we could get this by upstart putting all of the processes in the user session in a cgroup for that user. This would require upstart to be the first process in the user session, but I think that's achievable. Is my understanding there incorrect? No. cgroups provide multi-process resource control and push-button reaping of a set of related processes; they don't change the Unix semantics of PID 1 parent-of-last-resort handling, which is what we're talking about here. Now, Lennart has pushed a kernel change to allow parent-of-last-resort delegation, but a) TTBOMK that's unrelated to cgroups, b) that would tie us to a bleeding-edge kernel interface, c) it's not clear that it's needed for what we're trying to achieve. I guess I think the parent-of-last-resort is different than just simple noticing when a task dies and restarting it. For instance in[1] there is this: If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup is removed, then the kernel runs the command specified by the contents of the release_agent file in that hierarchy's root directory, supplying the pathname (relative to the mount point of the cgroup file system) of the abandoned cgroup. This enables automatic removal of abandoned cgroups. Which it seems to me that if we created a cgroup of for instance Compiz, if Compiz and all of its children were to die the cgroup would close and upstart would get notified. It could respond to that by respawing a new cgroup with a new Compiz in it. --Ted [1] http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: [Desktop13.04-Topic] GNOME plans review
On 17/10/12 18:25, Allison Randal wrote: On 10/16/2012 03:56 PM, Robert Ancell wrote: My point is we *shouldn't* take the time to update Debian as it is all cost and no benefit. If you think of Debian as being directly upstream from Ubuntu it sounds good but in reality it is a more sidestream. If it is outdated in Ubuntu we should update it in Ubuntu and if Debian also wants the update they should merge our changes across as we do the other direction. The most appropriate person to decide if the changes are appropriate is a Debian developer, not an Ubuntu developer. No benefit is a pretty serious overstatement. Debian has ~2000 volunteer packagers who maintain the majority of packages available in Ubuntu, with automated imports. Ubuntu has ~200 volunteer packagers who mostly work with forward-porting small deltas to the Debian packages that can't be automatically merged, or making sure Ubuntu integrates the latest security fixes from Debian/upstream. And then there's a small set of packages that are custom to Ubuntu or heavily modified for Ubuntu. For this last set, I agree, it is more work to port the changes back to Debian, and the changes don't always make sense for Debian to apply. But, spending a bit of time considering Debian even for these odd packages is a small price to pay for the vast benefit we get from Debian overall. You probably spend most of your time in this last set of packages, so I understand where your perspective comes from. But, it's important to keep the wider context in mind. Allison Note that here we are discussing GNOME packages, though I would assert this statement is true for pretty much all the packages that make up the Ubuntu Desktop image (i.e. the packages that are most crucial to us). The time taken to ensure synchronisation and the additional work ensure those changes are in Debian has a non-significant cost but little to no benefit to us (because we are unlikely to ever be synchronised). The GNOME packages that are not on the image or any other package for that matter, sure, the majority of them come from Debian. And that is of great benefit to us. Iain's original statement was that since we can't be in sync with GNOME then we should try and be more in sync with Debian. And it's that I disagree with - there are no great GNOME packaging improvements flowing from Debian to Ubuntu and we should focus on making our packages high quality and updating them faster. If anyone wants to push our changes back into Debian or a Debian developer pull them that is a good thing but it should be done in parallel and not block our progress. --Robert -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Collaboration with Debian [was: Re: [Desktop13.04-Topic] GNOME plans review]
On 17/10/12 18:02, Martin Pitt wrote: Robert Ancell [2012-10-17 10:48 +1300]: - By updating packages in Debian and waiting for them to flow down to Ubuntu kills our velocity. It can change the time from upstream release to being in Ubuntu from hours (which is too long in my opinion) to days. Yes, I agree that this is an issue at times. It usually works reasonably well for me to upload a new version to Debian and fakesync it into Ubuntu at the same time, but I have (1) DD upload powers and (2) everything set up to build packages for Debian, which is not true for the majority of Ubuntu Desktop developers. However, at the same time I strongly believe that directly working on Debian's packaging VCSes has some major benefits: Technically we avoid duplicate work and potential conflicts (such as naming new packages slightly differently, or a bug fix independently done on both sides works in a different way/with different API), and socially it's a great way of giving something back to Debian in return for having Debian do the vast majority of work of building Ubuntu. It also avoids the need of having to wade through large and mostly pointless merge deltas every so often, a work that nobody is really very fond of. Would an acceptable compromise be to commit fixes and new releases to Debian's GNOME svn, but then just do a -Nubuntu1 upload from those, at least for the packages which we want to keep in sync by and large? Martin I'm always hesitant to commit to a Debian repository since I don't run Debian my changes are never going to be tested properly. As you state, no-one likes to wade through the deltas and in my experience after doing that no real benefit is gained. The changes mostly come down to build-dependencies and addition/removal of patches (which are put into/come from upstream bug/git). It is faster to compare the upstream tarball changes than doing the merge from Debian. So what I suggest we do is admit merge bankruptcy. If the attempt to be in synchronisation is not bringing us more up to date or higher quality packages (I'll assert it's having the opposite effect) then we should stop trying to do it. Note of course this doesn't stop changes flowing back from Ubuntu to Debian if anyone wants to do that - we just shouldn't be using it as a criteria to judge the quality of our packages. --Robert -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
