On Wed, 7 Aug 2013, Pete Batard wrote: > On 2013.08.06 14:57, Alan Stern wrote: > > I agree, it does need to change. This means putting more pressure on > > manufacturers, not on the users. > > And how else are you going to put pressure on manufacturers?
I wish I knew. Good ideas are always welcome. (And you might find it worthwhile to bring up these issues on the linux-kernel mailing list, where many people will be keen to comment on, question, debate, and otherwise mess around with such ideas. Much more so than on the libusbx-devel list, where they are fairly OT.) > If Linus and other kernel developers haven't been able to get nVidia to > play fair, I'm curious about what other options you think are available. > > In my view, what Linus did, which is some form of public shaming through > less than kind words being uttered in a public forum (that he may or may > not have had an idea might end up getting a wider audience), is not that > dissimilar to trying to rally a larger number of users to one's cause, > one way or the other. Rallying people to your cause is fine. Blowing off their requests to support their hardware is not. Not unless you have an overriding technical reason -- "non-compliant" usually isn't enough. > > Holding users' devices hostage is not the way to do this > > Leaving hyperboles aside, I find that leaving users in ignorance, which > seems to be what you advocate here (unless you make sure that each user > of the quirky device is alerted to the behaviour and gets a chance to > decide whether they want to contact the manufacturer about it), is much > worse. And it's also kind of dismissive of the idea that users can > actually understand that it _is_ the role of the manufacturer to fix > issues, such as producing a device that isn't compliant with the specs. I never said a word about whether or not users should be notified of their devices' deficiencies. > Sure, your local mechanic can fix that Ford Pinto's gas tank, so that > you may avoid burning in a fire in case of a minor collision. But, as a > car owner, you should understand that this individual action will > accomplish nothing for all the _other_ Ford Pinto owners (or for future > owners of a Ford car following the same design). Worse, it may very well > send the very opposite message of what you really want which is a car I hate it when people talk about "sending messages". If you want to send a message, use Western Union. :-) > where the gas tank does follow existing safety rules, and leave > manufacturers with the idea that using a less than safe design for > placing a gas tanks, or other critical components, is fair game, as long > as only a small percentage of car owners have a chance to be affected... > > So I'm not gonna have that much of a problem saying "Sure, I *could* fix > your car. But since it doesn't follow basic safety rules, it's a > potential deathtrap (and right now it doesn't run, so I'm not putting > you in jeopardy either). Therefore, as the car owner, and even more so > since there's been a bunch of competent mechanics who tried to contact > the manufacturer and got nowhere, _you_ and every other owner of that > model need to be the ones contacting the manufacturer ASAP, to get that > issue properly fixed, and send them a clear message that safety issues, > even if they may only impact a minority of users, should not be ignored." That analogy is a little over the top, you must admit. As a general rule, non-compliant USB devices are not deathtraps. Not even malfunctioning ones. > > -- the users will be well aware of your attitude and > > will blame you when their devices don't work, instead of blaming the > > manufacturer. > > Which, as exposed above, is fine by me. Better an educated, yet possibly > angry, user than one who, because his or her device "just works", isn't > going to do anything more and allow more users to fare just as bad or > even worse. > > You gotta stop considering what's best for a limited number of > individuals, and worst for the group at some stage, and do what's best > for the whole group (even if the only way to get the original subset to > do what's best for the group is to anger them and have them give in to > transient selfishness). It seems that we have reached a level where little is left but a clash of opinions. > > I see a very similar phenomenon occuring on a smaller scale all the > > time in the linux-usb mailing list. When something goes wrong with a > > USB device, people always report it to the USB mailing list. Quite > > often it turns out the bug actually belongs to a different subsystem. > > But it often doesn't get reported on the mailing list for that > > subsystem, because the USB aspect is the most visible. > > I'd be tempted to say that it may be because people have seen that you > guys were willing to apply workarounds to get their devices to work no > matter what. ;) > > > I doubt that such a review would have much impact. Almost all the > > readers will think "I'm not using Linux, so I don't care if the device > > doesn't work with Linux. This is just another example showing how > > Linux is inferior to Windows." > > Once more, I find that pretty dismissive of the ultimate ability of > people to comprehend current and far reaching issues. It's not dismissive of people's abilities to comprehend these issues; it's disparaging of their willingness to take long-range issues into account for short-range planning (especially when the long-range goals work against short-term interests). > > A much better approach would be: "This device is not compliant with the > > USB spec and doesn't deserve to carry the USB logo." Even that might > > not hold much weight; a lot of people will care only about whether the > > device works, not how well it follows the spec. > > That's actually more accurate, and what I would expect to see in an > unbiased review, since Linux has nothing to do with the device breaking > the specs > > > Tactics are different from strategies. I approve of your strategic > > thinking, but IMO your approach to tactics is all wrong. > > Well, as I mentioned in the original post, I fear that your goals (and > Linus' ones fwiw) may be a a bit too short term and, when more and more > devices are preventing the booting of FLOSS OSes already and aim at > restricting users freedoms, fail to account for the pressing need to > keep manufacturers in check one way or the other. As I said, a difference of opinions. Undoubtedly there are Linux developers who share your view. > > But I'm not willing to stop adding support for hardware that people > > already own and should be able to use. > > So let's say a manufacturer is providing an USB device that can transfer > patient-specific heart regulation data to a pacemaker. Would you prefer > the manufacturer, who is supposed to have a stringent set of tests and > knowledge of the design, as well as possible life threatening point of > caution of the firmware, to try and fix any specs compliance issue? > Or would you prefer having a bunch of external developer who, probably > only have a partial view of the device and its points of caution, apply > workarounds to address these issues? > > Before you dismiss that scenario as unrealistic, let's consider that the > issue (crash on getting a specific sequence of descriptors, that the > Linux kernel would normally request by default, but not Windows) has to > do with a poor general buffering implementation (eg. same data being > served twice under some conditions). > If the data is small, and you are transferring multiple patient records > to multiple pacemakers, you may very well end up with the wrong patient > data on some of the target devices. Pity that, since a similar buffering > algorithm from the same manufacturer was used in a generic (non medical) > usb gadget and that users of that gadget never forcefully complained to > the manufacturer to get that problem fixed, the issue wasn't picked as > early as it should have been... This feels like a silly question. Of course I'd prefer to the manufacturer fix any compliance issues. I have said so all along. Alan Stern ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
