sane-backends

Bug #85488
Comment #385

Comment 385 for bug 85488

Revision history for this message

Mark (azovap002) wrote on 2007-07-29: Is Ubuntu Really Friendly

#385

Add Canon LiDE 60 to the blacklists.

@M. Chang - I read all comments before posting, and Ben's rationale is weak and wrong. Debian's Joerg Morbitzer is on target, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419197#62 : "as long as it is that buggy and officially 'experimental' I don't want to see it in a _Debian_ kernel!" (25 Jul 2007).

The kernel.org devs admit suspend code is bad, dozens of user bug reports prove it. It should be obvious now that CONFIG_USB_SUSPEND=y was the wrong default.

Besides which, there is a lot of kernel work going into new suspend designs anyway.

But all this debating is wasteful, because there is an easy fix - put an alt kernel in the repos. If Ben feels that strongly about jamming experimental laptop goodies into a one-size-fits-all kernel, maybe Ubuntu should branch a "laptop" kernel astride the server and mobile lineup.

This bug is nearly half a year old on Ubuntu bugzilla. A simple kernel offering in the repos would have solved it months ago for everyone.

@Shuttleworth - You should focus on what makes Ubuntu special, if anything.

I work with many Linux distros. I *want* to use Ubuntu - but generally can't because of issues like this. A common fallacy is, "that will be fixed next time." What can distinguish Ubuntu from the pack is offering solutions when needed. Otherwise I fail to see the value-added. I'm spending as much time fighting Ubuntu software to make it work as any other distro.

When Ubuntu supported PowerPC I did wait - and wait - and wait. I waited across *two* major releases and known bugs were still never fixed. (Then Ubuntu dropped the platform. OK, moving on.) My point is that waiting can turn into real frustration and futility.

An experimental laptop feature is now breaking large numbers of x86 desktops. Kernel.org devs admit the code is bad and mark it experimental. The same bad code is haunting 2.6.22. Ubuntu cannot afford that kind of PR.

Average people just want to know that hardware X works. Telling them "recompile your kernel" or "rebuild your initramfs" or "wait N months for Gutsy" or "use this tweaker script" is not cutting it. If they must do all that, they can suffer with any old Linux, and don't need a "friendly" distro. I am a *software engineer* and *even I* find Ubuntu frustrating. My main frustration is why your fulltime hires can't put fixes in the repos.

When Gutsy comes, there will be similar problems. Linux will *always* have these problems. Ubuntu needs a better strategy than "wait for Happy Hope..."

Please consider a laptop-specific kernel. Please offer alt kernels in the repos to address user needs. Please avoid telling users to wait for the next release. Especially when the fix is so well nailed as this one (simply turn a compile flag off). Offering alt kernels will cut down on bugzilla duplications too.

Myself, I am not persuaded that Gutsy will fix the problem, going by my experience with 2.6.22.1 and LKML research. I am just compiling that flag out of every Linux distro we deploy.

Add Canon LiDE 60 to the blacklists.

@M. Chang - I read all comments before posting, and Ben's rationale is weak and wrong.  Debian's Joerg Morbitzer is on target, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419197#62 : "as long as it is that buggy and officially 'experimental' I don't want to see it in a _Debian_ kernel!" (25 Jul 2007).

The kernel.org devs admit suspend code is bad, dozens of user bug reports prove it.  It should be obvious now that CONFIG_USB_SUSPEND=y was the wrong default.

Besides which, there is a lot of kernel work going into new suspend designs anyway.

But all this debating is wasteful, because there is an easy fix - put an alt kernel in the repos.  If Ben feels that strongly about jamming experimental laptop goodies into a one-size-fits-all kernel, maybe Ubuntu should branch a "laptop" kernel astride the server and mobile lineup.

This bug is nearly half a year old on Ubuntu bugzilla.  A simple kernel offering in the repos would have solved it months ago for everyone.

@Shuttleworth - You should focus on what makes Ubuntu special, if anything.

I work with many Linux distros.  I *want* to use Ubuntu - but generally can't because of issues like this.  A common fallacy is, "that will be fixed next time."  What can distinguish Ubuntu from the pack is offering solutions when needed.  Otherwise I fail to see the value-added.  I'm spending as much time fighting Ubuntu software to make it work as any other distro.

When Ubuntu supported PowerPC I did wait - and wait - and wait.  I waited across *two* major releases and known bugs were still never fixed.   (Then Ubuntu dropped the platform.  OK, moving on.)  My point is that waiting can turn into real frustration and futility.

An experimental laptop feature is now breaking large numbers of x86 desktops.  Kernel.org devs admit the code is bad and mark it experimental.  The same bad code is haunting 2.6.22.  Ubuntu cannot afford that kind of PR.

Average people just want to know that hardware X works.  Telling them "recompile your kernel" or "rebuild your initramfs" or "wait N months for Gutsy" or "use this tweaker script" is not cutting it.  If they must do all that, they can suffer with any old Linux, and don't need a "friendly" distro.  I am a *software engineer* and *even I* find Ubuntu frustrating.  My main frustration is why your fulltime hires can't put fixes in the repos.

When Gutsy comes, there will be similar problems.  Linux will *always* have these problems.  Ubuntu needs a better strategy than "wait for Happy Hope..."

Please consider a laptop-specific kernel.  Please offer alt kernels in the repos to address user needs.  Please avoid telling users to wait for the next release.  Especially when the fix is so well nailed as this one (simply turn a compile flag off).  Offering alt kernels will cut down on bugzilla duplications too.

Myself, I am not persuaded that Gutsy will fix the problem, going by my experience with 2.6.22.1 and LKML research.  I am just compiling that flag out of every Linux distro we deploy.