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? 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. Outside of being able to lure manufacturers to the immediate possibility of increased profits, putting pressure on them tends to boil down to 2 close factors: getting product consumers actively involved and voicing a common message (that if followed through, would result in loss of profit), or leading manufacturers to think that consumers are about to get actively involved and ask for the same thing. As such, the pressure you can apply is proportional to the number of users you can rally and their level of involvement. > 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. 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 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." > -- 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). > 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. > 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. > 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... Regards, /Pete ------------------------------------------------------------------------------ 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
