@Pär

I don't feel offended but misunderstood. Partly that comes from the
fact, that some of your presumptions are wrong. Lets get them
straightened first:

1st: Whether was I saying that Ubuntu is proprietary not that the fact
that there is a cooperation behind it makes it any less free. Where did
you get that from?

2nd: Launchpad is to my knowledge neither OpenSouce nor FreeSoftware,
nor does it belong to Ubuntu! Launchpad is a proprietary product of
Canonical. Canonical is not Ubuntu! There were discussions about exactly
that issue when the software was first introduced. Google "launchpad
proprietary".

Ergo, Launchpad being neither OpenSource nor FreeSoftware pretty much
ties my hands. Even if I would want to add this feature into the
Launchpad eco-system, how would you suggest I do that with no access at
all? So for that part, I can only tell, not code. 

You need to know that to understand the feature request part of my
comment.

So much to the facts you got wrong.
-----

So now to the misunderstanding part. Where am I exactly complaining? 

I said:
Disabling autosuspend does not break suspend/resume for me, but that
does not mean much.
I understand this bug is hard to fix without more detailed info.
Only way to get more info is a HW-DB enabled poll feature.
I have no way to implement that, as Launchpad is ClosedSource.
But I am happy to share my idea with anyone enabled to implement it.
And I'd also get my own hands dirty, if Canonical wants to sponsor that
feature.

Does sound like a bunch of perceptions and suggestions to me, no
complains to be found.

Anyhow, let's discuss this further off the list, unless you have any
comments or suggestions on the bug itself and how to fix it.


On Sat, 2008-02-09 at 11:13 +0000, Pär Lidén wrote:
> @Elias: I don't mean to sound rude, but it feels for me that you have no
> problem complaining about what others should and should not do, but then you
> are yourself not ready to do much about it. Well, you might say that Ubuntu
> is a proprietary project, because there is a corporation behind it, but all
> code it produces are completely free and open-source. Many developers work
> totatally for free on Ubuntu.
> 
> I suggest that instead of telling others what to do, you just go ahead and
> do it yourself. I understand that you may not have the time for that, but
> maybe you would then understand that other people (the paid developers) also
> has a lot of other work to do, and maybe does not have time for your
> favorite issue?
> 
> And regarding bug 3382: Yes, I agree with you, it sounds like a good idea,
> great thinking from you Elias. But, please, I ask you, could you stop
> posting about it here in this bug? I at least would be happy if you
> wouldn't. You have already posted about it many times here,  you don't need
> to post it again. I think the message has gone through clear to everyone
> here.
> 
> Also, if you would to like to support the developers in some way to do a
> better job, you would be much better of giving words of encouragement,
> instead of words of complain. I am totally sure that you criticising them
> won't give them any more energy (and definitely not any more time) to work
> on development.
> 
> This is meant as a friendly advice, I hope you don't feel dismayed or
> something.
> 
> I also want take the opportunity to thank the developers for all the hard
> work they are doing, from which I can benefit completely for free.
> 
> 
> 2008/2/9, Elias Humbolt <email address hidden>:
> >
> > @Ben Collins
> >
> > Ben, I am happy that somebody from Ubuntu is finally reacting to this
> > Bug report. If not for fixing it than at least with an official
> > statement what devs are actually thinking about the issue. And why
> > obvious simple measures are not taken.
> >
> > Your argumentations surely is not bare any logic. My first reaction
> > however was, well if suspend/resume is ought to be broken after
> > removing/disabling the autosuspend feature, why can I still successfully
> > suspend/resume on my laptop after disabling it. So now I have both, USB
> > 2.0 and suspend/resume. You understand that some doubts did arise in me
> > about your claim removal of autosuspend might screw up suspend/resume
> > for many people.
> >
> > However, these doubts do not have many grounds just yet, except for my
> > single perception on one type of system. Therefore I presume what you
> > are claiming are well tested facts.
> >
> > I am wondering however, if it would not be possible to enable
> > autosuspend for the one crowd of chipsets while disabling it for the
> > other. Sure, not an easy task to identify, which systems to enable and
> > which not.
> >
> > Extracting all this information from bug reports surly is hell. And yet,
> > if you have talked everybody into submitting their data "again", you
> > still will have to ask all of them to test whether or not disabling
> > autosuspend breaks suspend/resume for them. This is a challenge for
> > itslef. Undoable if you ask me, at least with the tools available.
> >
> > I therefore understand, why literally nothing is done about it!
> >
> > Undoable, well not if Launchpad had the proper toolset for this! I
> > actually proposed a feature which would enable you to handle a task like
> > that: The "attach HW profiles to launchpad accounts" I proposed a while
> > ago. https://bugs.launchpad.net/bugs/3382
> >
> > I just had a couple of more ideas on how else this feature could be used
> > with a little more code.
> >
> > Oh man, somebody needs to implement that! Have a look. I am happy to
> > share the idea, but I wont code for free on a proprietary project. And
> > well, the idea was mine, so don't start crying if RedHat or anybody else
> > is copying it. This idea is a free for all still!
> >
> > Imagine how much better bug tracking would work if you could start a
> > simple poll:
> > Does disabling autosuspend fix your USB2.0 problem ? yes/no
> > Does disabling autosuspend break your suspend/hibernate/resume? yes/no
> >
> > If more than one HW profile is registered with your launchpad account
> > the following question shows up:
> > Select the systems these answers apply to ? Choose form list.
> >
> > And at the end you would know not just for how may people disabling
> > autosuspend works ... but also what chipsets are affected!
> >
> > Wouldn't that be coding hours wisely spent? Whether you use it for the
> > ehci_hcd bug or any other HW related bug in the future? I am sure kernel
> > devs upstream would be happy to whitelist/blacklist autosuspend
> > accordingly if they were provided a detailed list for whom, wouldn't
> > they?
> >
> > I'd be delighted if you would share your thoughts on the feature I
> > proposed for launchpad as well as on whether or not it could be a viable
> > solution to whitelist/blacklist autosuspend in kernel if the proper
> > information would be available for whom.
> >
> >
> >
> >
> > On Mon, 2008-02-04 at 21:13 +0000, Ben Collins wrote:
> > > Elias, you are over simplifying this issue. If we disable autosuspend,
> > > then suspend/resume wont work for a good portion of people. After long
> > > ago weighing the options, we had to decide on the lesser of two evils:
> > > suspend/resume working for a large group of users, or usb2.0 working for
> > > an equally large group of users. Considering that both problems have
> > > work arounds, the decision was made based on expected behavior. Usually
> > > a system with usb2.0 ports that were affected by the problem also had
> > > usb1.0-only ports that did work. So users could continue to use their
> > > devices without much problem (although at a slower speed).
> > >
> > > Also, please don't exaggerate how many people are affected by this. Over
> > > all, it's a small percentage of people. I have > 15 laptops, covering a
> > > large range of chipsets, and none of them are affected by either
> > > problem.
> > >
> >
> > --
> > ehci_hcd module causes I/O errors in USB 2.0 devices
> > https://bugs.launchpad.net/bugs/88746
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>