[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100817153304.GI21182@thunk.org>
Date: Tue, 17 Aug 2010 11:33:04 -0400
From: Ted Ts'o <tytso@....edu>
To: Neil Brown <neilb@...e.de>
Cc: Jesse Barnes <jbarnes@...tuousgeek.org>,
Pavel Machek <pavel@....cz>,
Felipe Contreras <felipe.contreras@...il.com>,
Alan Stern <stern@...land.harvard.edu>,
paulmck@...ux.vnet.ibm.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
david@...g.hm, Brian Swetland <swetland@...gle.com>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
arve@...roid.com, mjg59@...f.ucam.org, florian@...kler.org,
rjw@...k.pl, peterz@...radead.org, tglx@...utronix.de,
menage@...gle.com, david-b@...bell.net, James.Bottomley@...e.de,
arjan@...radead.org, swmike@....pp.se, galibert@...ox.com,
dipankar@...ibm.com
Subject: Re: Attempted summary of suspend-blockers LKML thread, take three
On Tue, Aug 17, 2010 at 05:08:58PM +1000, Neil Brown wrote:
>
> Maybe this is the first real fork of Linux - google might be rich enough to
> persist with it.
Define "real fork"? Both SuSE and Red Hat have carried patches, in
some cases for years, forward porting them to newer kernels. Does
that make them forks?
SuSE has made changes to e2fsprogs, and carried those patches for
years and years, and even added options to command-line programs which
SLES's init scripts are dependent on --- and this was done without
even consulting me first. Yet you don't see me calling out SLES for
"forking" e2fsprogs and how it "got away" with it.
Can we please cut out this whole forking nonsense? I've been told
that it's only something Slashdot kiddies and ZDNet media types
looking for advertising impressions. Yet you're a kernel programmer,
and one who works for a distribution, and you've made this same claim;
you should know better.
> I'm surprised at this comment Ted!
> Power saving is not the single supreme goal, yet you make it sound like
> it is.
>
> It should be no surprise to anyone if the most maintainable solution uses a
> little more power than the most highly optimised solution. I think most of
> us would still prefer the more maintainable solution.
I think part of the problem here is what's considered "acceptable" to
one set of developers may not be considered "acceptable" to another
set. As I've said many times before, what makes sense for a cell
phone battery and highly power-optimized hardware may not make sense
for a devices with 6-cell laptop battery. And I think it's still to
be seen whether or not suspend-from-userspace really is as minor as
people think it is, and what compromises might have to be made in how
app programs are forced to develop their applications, etc.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists