hoping for suspend2 support in feisty

[Matt Price]

On Tue, 2006-28-11 at 18:56 -0500, Ben Collins wrote: 
> On Tue, 2006-11-28 at 16:02 +0100, Florian Hackenberger wrote:
> > On Tuesday 28 November 2006 15:11, Matthew Garrett wrote:
> > >  The chances of suspend2 itself fixing anything
> > > are pretty miniscule.
> > But AFAIK suspend2 is much faster than swsusp if compression (LZF) is enabled. 
> > I don't use swsusp, because it's just too slow with 1GB of RAM and my Laptop 
> > HD. Before switching to Ubuntu I used Gentoo and its hibernate support 
> > (suspend2) was MUCH faster. Maybe patching the kernel to support suspend2, 
> > while still using our suspend scripts would be a good idea. Some other 
> > attractive features of suspend2:
> 
> One of the main reasons I wont support suspend2 being in our kernel is
> the size of the delta to include it in our sources. The more differences
> we have between our kernel, and upstream, the more overhead in
> supporting it, whether it is security updates, or synchronizing with
> upstream (conflicts in code merges), not to mention updates to these
> patches from suspend2.
> 
> So even if suspend2 were a little more beneficial, it doesn't make sense
> for us to include it. It DOES make sense for the suspend2 folks to get
> their stuff in the upstream kernel. It's irrational for a project so
> desired by users to be continually left out of upstream, and have those
> users expect distro maintainers to do all the work in supporting it like
> this.
> 
> So instead of asking Ubuntu, or any other distro for that matter, to
> include such large patches, it would be better if people asked the
> suspend2 maintainers to work on getting things merged with the mainline
> kernel.
> 
ben I agree the process you describe here would be the best-case
scenario.  However, it looks like a merge, if it ever takes place, will
be a long time coming.  In the meantime, I would like to see ubuntu's
suspend support become as implementation-agnostic as possible.  

As I see it, actually, this issue only tangentially impacts the kernel
team -- right now, it's only my ignorance of the ubuntu build process
(and the fact that I'm a crap programmer) that forces you to keep
helping me out!  If, sometime soon, it becomes relatively easy to
routinely build suspend2-enabled kernels destined for universe --
something like the way xen kernels but maybe more the way low-latency
kernels are currently built -- then the real work would be to ensure
that the process of installing those kernels is as painless as possible
for the people who need it.  In my view, this means:

- adding a couple of simple scripts to the standard initramfs;
- making a couple of adjustments to acpi-support;
- making sure that gnome-power-manager has a rational way of deciding
what suspend technologies are available and which should be tried first;
- providing suspend2 and perhaps ususpend metapackages (I don't use
ususpend so I don't really know how easy it is to install right now) so
that someone who's experiencing problems can switch back and forth
between methods in a relatively straightforward and simple way.  

Here I'm disagreeing pretty adamantly with Matthew G., who suggests that
it's more important to keep users using swsusp and reporting bugs.  Part
of the problem here is that suspend/resume failures are generally hard
to capture in /var/log/messages or dmesg.  This is much worse with
swsusp, which in addition to the intrinsic difficulty of capturing
events after filesystems are unmounted & processes are frozen, has
almost no debugging code.  I've reported most of the swsusp failures on
most of the laptops I've used for the last year or so; nothing ever
comes of it because the bug reports are nearly useless (the fact that
reportbug doesn't work and malone was hard to use until pretty recently
didn't help, I guess).  

so:  a user whose laptop doesn't suspend currently doesn't have a lot of
options.  unless one has lots of data and customizations on the machine,
it would probably be easier to try another distro than it would be to
diagnose and correct the problem, especially if the user is relatively
inexperienced.  It's these folks that need help, and I'm trying to think
of a solution for them.  Though I should say that, if I weren't
committed to ubuntu's ease of use because of teaching constraints (I use
ubuntu/xubuntu in a class I teach) this whole issue would likely have
driven me back to Debian.  suspend capability is simply that important
to me -- without it, my power-hungry dell is useless on the road.  

In my view this is a pretty substantive issue for a significant number
of people which isn't adequately addressed by telling people "have it
our way."  There are several suspend implementations now, largely
because thedefault implementation has some serious issues; if people
need the feature they should be free to try the other implementations.
certainly it should be AT LEAST as easy to use suspend2 as it is to
install nonfree nvidia drivers!  

at least that's how it seems to me.

Matt


-- 
Matt Price
History Dept
University of Toronto
matt.price at utoronto.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20061128/e1bf52bf/attachment.pgp