El dg 09 de 01 del 2005 a les 10:39 -0600, en/na Peter Samuelson va escriure: > [Miguel Gea Milvaques] > > I don't undestand why software loading files (as we are talking) must > > be in contrib. An example: xpdf, if you have not a pdf file you could > > not use it, only it gave us a blank page. You could read a lot of > > different files, a free pdf files or a non-free pdf files, and xpdf > > we never thing to put xpdf in contrib. > > There are several reasons why content viewers are not analogous to > device drivers. Well, at least three reasons: > > 1. Most importantly, it's a difference of *purpose*. The purpose of > xpdf is to view arbitrary PDF files. The purpose is not to load up > a PDF file and then do something completely unrelated, like play > tetris. If for some reason a tetris game required a PDF file to be > on hand in order to let the user actually play tetris, it certainly > should ship a working PDF file, or depend on something that does. > The purpouse of a software not says if a software goes in main or contrib. > It would be hard to argue that the purpose of a NIC driver is to > load a firmware blob. Loading the firmware blob is part of the > necessary procedure, but it is incidental; the user does not care > about that part.
If you to use xpdf, you must to give it a pdf file, if you want tu use a driver you need to give it a firmware blob. > It's not as though most users would install the > NIC driver just to see their favorite firmware file load and result > in some sort of status printk. > > 2. The PDF file is full of information which is to be displayed to the > user, and most PDF files have unique information in them. The point > of xpdf is to convert this information to a human-readable > representation. Thus, users care very much about *which* PDF file > they are loading into xpdf - it's not like they just need any > arbitrary PDF file. Put a different way, there's no way to predict > that most users would be satisfied by specific PDF content that > Debian might then ship as a convenience. Most users would not. > They don't want content selected by Debian, they want whatever > content they might run across. This is the same point. You are going to care very much abut *which* firmware are you loading on your driver. > > The firmware used by a NIC driver, on the other hand, has no > user-visible content; certainly it has no content that the user > specifically cares about. In the common case, there is nothing to > distinguish between one firmware release and the next, other than > bugs fixed according to the release notes. In the less common case, > some versions of the firmware will add usable features to the > driver, like hardware checksumming of TCP packets. Even then, > although the user may say "I want version X of this firmware because > I heard it makes the driver faster", there's still a limited and > predictable range of firmware content people might ever want. To > the extent that this ceases to be true (as, for example, with > Linux-based wireless access point hardware, where a community > develops around producing non-vendor firmware that does cool new > things), it begins to make sense to treat those cases as data > loaders which needn't provide or depend on specific data files. > > 3. There's a very real expectation, in the PDF case, that the user > could create his or her *own* PDF files, using any number of tools > in Debian or not in Debian. The user could quite reasonably wish to > install xpdf *solely* to view locally created content. If you find > that hard to believe, think about how most people use xdvi. > > Firmware files are not the sort of thing people can create their own > versions of. In most cases the format is not documented and there > are no free or even publicly available tools for this, and even in > cases where it *is* documented, this is not by any stretch of the > imagination a typical use case. Yes, but the difference is only the difficult could be create them. Then if you have a more difficult working sofware, it must be in contrib? > > Peter -- Miguel Gea Milvaques <[EMAIL PROTECTED]> Blog: http://www.livejournal.com/users/xerakko/
signature.asc
Description: =?ISO-8859-1?Q?Aix=F2?= =?ISO-8859-1?Q?_=E9s?= una part d'un missatge, signada digitalment
