[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Julian Hall wrote: > Neil Williams wrote: > > That's only because the vast majority of *machines* are Windows > machines. I'd be interested to know what make of printer (for > example) is most common within Linux. The CUPS team could probably help you with that but, as is the case with most free software, the lack of a licence or download registration means that any statistics are unreliable at best. That's part of the freedom - you are free to use the code without telling anyone, without getting registered with anyone and without saying what you plan to do with the software. >>> My point is that if those people with specific problematic hardware do > not at >>> least contribute to the data set of the free software tool for that > hardware, >>> that hardware will never be supported. There are simply too many devices > out >>> there and they change too often (thanks mainly to patents). > > Simple example of that. I sold my Radeon All In Wonder (the TV part > refused to work in Linux and ATI ignored my emails asking for help). > After researching on the web I found the Pinnacle DC10+ *allegedly* > worked in Linux, so I spent about £100 on one, only to find Pinnacle > changed the design to a proprietary chip. I was in contact with the > developer *and* Pinnacle for at least a month or so. The developer > was quite happy to help *IF* Pinnacle would give the specs required > for the chip. They ignored all requests. In the end after realising > I was banging my head against a brick wall I gave up. Such problems are not insurmountable - reverse engineering is a possibility - but such efforts consume huge amounts of effort and time. For this to happen in the free software world, there has to be sufficient motivation. This is what makes it difficult to get the last % of any particular hardware to conform - if the bulk are OK, there is insufficient drive to resolve the last few cases. In the early stages, cracking one card can lead to solutions for lots of others. TV card support on GNU/Linux has improved. It may be worth trying to see if one of the generic drivers has improved sufficiently to work with your card. > So, despite my best efforts to contribute and loyalty to Linux, all I > got was a £100 hole in my pocket and a video capture card I can only > use in Windows. So far. It takes a lot longer than a month or two to make significant progress. It took me the best part of a year to create a small utility using existing free software communication tools for the Palm. > You can see why after that I was happy to pay the > small amount Turbo-Print asked for, in order to get something that > actually *works*. Just don't give up. Keep contributing to any project that has a chance of solving the problem. Make wishlist bug reports, make your problem known, accessible and thereby solvable. Don't fixate on a single developer and give up if he can't solve the problem. Make your problem public in the bug reports so that anyone trying to research the problem can find useful, relevant and detailed information on the problem and the data behind it. > Don't forget that without Turbo-Print I would have another piece of > hardware that only works properly in Windows. If I hit three then > chances are that Linux would (regretfully) come off the system. > Ethics and an ideology are fine in theory, but I don't see the point > of being a martyr and denying myself the functionality of equipment I > have bought just to be a purist. It's partially thanks to the > Turbo-Print team that I support Linux at all. Whilst I disagree with that rationale and excuse, it would be self-defeating to follow such a path and NOT help the free software community solve the problem. Eventually, your lack of involvement would force a situation where that third bridge was crossed. You have to keep up because it is inevitable that you'll want to obtain another piece of hardware in the future and if the preceding problems have not been solved, you reach that threshold. Yet you still consider all of this on a purely selfish basis. There are more people involved here than just you. Consider those who might buy this hardware in the future. Consider those who may buy hardware based on this chip. Do you want to share your experience with them? Do you realise that by not sharing you are actually denying them the support they need? > Free software *is* the > best solution (which is why I persevered with MADWifi rather than take > the easy route of using ndiswrapper for Wifi), but in the absence of > free I'll take proprietary in Linux over being forced back to Windows. Fine, but please remember that new hardware is always being released to maintain income streams due to patents and other false marketing restrictions like inbuilt obsolescence. It is unacceptable for free software to stand still - progress can only come from adding support for as many devices as possible. That requires user involvement beyond just contacting the developer. >>> It's one thing using proprietary, it's another to deprive the free software >>> team of the data they would need to provide a free software solution. > There's >>> obviously something different about this particular Epson - my Epson worked >>> fine. > > Depends what you do with it and what performance level you will settle > for. This printer is capable of 5760dpi in full photographic mode, > borderless printing up to A4 and printing on CDs. To the best of my > knowledge it is being worked on, but as I've said before *in the > interim* I need something that works. Just don't neglect those who are working on the problem. Provide some data and feedback for them. Help keep them motivated to solving the problem. Let them know that there ARE users out there who would value the additional support for these less commonly used functions. We are all volunteers and volunteers NEED support, motivation and encouragement. It doesn't take much, just a helpful message, a bug report with lots of helpful information, a little positive feedback. >>> That indicates missing data and the only practical way for the CUPS >>> developers to GET that data is for users of that printer to contribute that >>> data to CUPS. If they aren't using CUPS, they can't provide the data. > > Fair comment, although the CUPS team do seem to have the data as > suggested by the fact they are making *some* progress. They could do with your feedback and probably some debugging data from you. It doesn't take much. >>> The problem is that this money isn't actually supporting the free software >>> community, neither is the code. > > Forgive me, but is that saying I should pay the developers? No, although that may be suitable for some developers. Support for free software generally means feedback, encouragement, information, debug data - basically just someone coming alongside the development team and saying "Yes, this is important to me and I want to help you all to solve it." In the volunteer world, time is more important than money, a encouraging message more relevant than a cheque and information the key to progress. >>> Not my intention. I do think we need to ensure that everyone is aware of > the >>> compromises involved and how the community could be missing out. > > Unfortunately although not your intention, that was how the comments > came over, at least to me. 'My way or no way' is the quickest way to > lose support. I only ever seek to provoke engagement, discussion and to challenge misunderstandings. When the method being proposed directly harms the free software community, I will always make that stand. You must see beyond your own needs and consider others - including those who will come after you. Free software is forever, it is imperative that it remains current. > Hardware OEMs are in business to make money. You could argue the > valid point that X OEM could give all the technical data to the Linux > community, drop driver/module development entirely and then save all > their development costs. The Linux community would use the data to > produce working solutions for Linux. Come to think of it they'd also > save whatever money they pay Microsoft for the privilege of getting > the data from them they need to write the drivers. You've got to get through the layers of lawyers first. As Robin pointed out, these units are not generally bespoke items from that single manufacturer. The devices are built from standard components in much the same way as the PC itself is built from standard components. This is where laptops become such a problem because the components are not standardised. In the proprietary world of secrets, reservation of rights and cross-licensing, it can be impossible for the front-line OEM to release the specs for the chips even if the supplier of the chips would otherwise agree. You've got to discover who was the real manufacturer beneath the layers of re-badging that goes on. Linmodems are a good example. > Until that happy state of affairs anyone using equipment where Linux > has not caught up yet, or the OEM refuses to cooperate (such as > Pinnacle) has two choices; stick to Windows, or use a proprietary > interim solution until Linux catches up. There is always the option - indeed the obligation - to support the free software solution with data that can help them catch up. You are benefiting from the contributions made by previous free software developers who were willing to share their code with you. There is an obligation there to respect their efforts and ensure that their work does not go to waste by becoming irrelevant or obsolete. To do so is simply the decent, civil and sharing thing to do. > OK there's a third option, > spend money pursuing freedom to buy equipment that does work in Linux, > but isn't that playing into the hands of the hardware OEMs? They > don't get badgered to release the information, so they ignore the issue. No. By not buying the latest and greatest gadget and picking something that does the job without the bells and whistles added by marketing, you are hurting them in their pockets. Hardware suppliers want you to replace every component in every PC as often as possible. If the units won't breakdown then they have to persuade you that your very life depends on getting the next whizzo feature that they tell you you need. Ignore the marketing, look at the real performance and buy only what you absolutely require. If that doesn't work with GNU/Linux then if you use a proprietary solution to fill the gap make SURE that the free software alternative has a chance to catch up and close the gap completely. It's the only viable long-term solution. It is simply sharing what you have (the hardware) with those who need something from it (the debugging data). > >>> GNU/Linux can have hardware parity with Windows (albeit with a time > delay on >>> new products) but only if someone contributes the data from each type of >>> hardware. > > Only if that information is available. In the DC10+ example above it > isn't. With the best will in the world I can't supply information I > don't have, and nor can anyone else. If someone chooses to reverse engineer that device, they can write a programme that queries the hardware directly and produces debugging data that is independent of the "secret" specs. You would simply run the programme and send the data to the developer. Naturally, you must be able to trust the developer! The information is always available - it's only a matter of motivation and need. It's a SMOP. Simple Matter Of Programming. Don't think that every free software device driver has had to be written with full access to the original specifications. There is more than one way to support a device. This is the area where IP, DRM and Trustworthy Computing become such a potential nightmare. This is why the EU are right to pursue MS for usable inter-operability documentation. Such secrets serve only to line the pockets of lawyers. We need to be able to share raw data obtained from low level interrogation of hardware devices and use that data to create free software drivers. >>> If that money went to further free software development it wouldn't be a >>> problem. Instead, CUPS is losing out. > > Simple question, how do you suggest 'that money [goes] to further free > software development'? Do I send a cheque to the CUPS development team? 1. Some projects do accept donations, especially those that try to write new drivers for hardware devices. (pilot-link) 2. Some projects accept donations that directly support other developers, like SourceForge, KDE, Apache and Debian. 3. Other groups and organisations directly support such developers by working to protect their rights to do what they do. See the FFII, AFFS, FSF and other such groups. Think laterally, ask the CUPS team whether they need direct funding or whether they use other projects that may need funding like SourceForge or GNU. Probably the most valuable thing you can give the CUPS team is your time. Your time running their test programmes, feeding back results, providing encouragement, data and a clear picture of the needs of users. Start by filing a bug report of wishlist severity. Make sure that the report is as informative, helpful and supportive as possible. Offer to help by providing data etc. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: OpenPGP digital signature