On Wed, Feb 22, 2006 at 09:52:28PM +1000, Anthony Towns wrote: > On Wed, Feb 22, 2006 at 12:29:25PM +0100, Wouter Verhelst wrote: > > On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: > > > The only instance when it's usable without any non-free code is when > > > you're better off using a native driver anyway. > > The only instance where wine is serving a purpose without requiring the > > use of non-free code is when you're better off using native Linux > > software anyway. > > TurboCASH is a potential counterexample -- it's a complete, functional, > GPLed, Windows-based accounting suite, which hasn't been ported to Linux, > and which is non-trivial to port to Linux.
"...when you're better off using native Linux software anyway". I can give you a number of applications, free or otherwise, that will do accounting on Linux. Heck, I used to work for a company that wrote accounting software which (also) worked on Linux, so I should know my way around there. > Furthermore, it's reportedly better than the accounting packages we > have. Many non-free software is reportedly better than some of the software in Debian. OpenOffice.org is reportedly better than MS Office, for example. I tend not to believe third-hand experiences. > I don't know if it actually runs under Wine though. What are we talking about, then? You're claiming that it's okay to keep wine in main because there's this GPL'd application that you've apparently never even tried and which *may* work under wine, while there's a driver for ndiswrapper which is "useless" (hah) that http://ndiswrapper.sourceforge.net (i.e., the main ndiswrapper website) actually links to? Are you for real? [...] > Anyway, despite it's acronym, I'd put Wine under the same heading as > emulators. Sure. Personally, I'd put ndiswrapper there, too. [...] > There are a few lines you could draw: > > (1) running non-free drivers in order to use your system > (2) a compatability layer to run non-free applications or games > you might have > (3) a client that allows you to make use of some proprietary servers, > for which there's no free server > (4) a viewer that allows you to view documents prepared by a proprietary > program, for which there's no free writer These are all categories, but I disagree that the distinction between most of them is that significant. > At present we let all of them into main. I'm still not convinced that this is actually a bad thing to do. > > What's the difference? What is so insanely different between two ABI > > implementations that one ABI implementation can go in main, while the > > other must go to contrib? > > That's a fair point -- you could reasonably argue that ndiswrapper doesn't > depend on non-free drivers, but quite to the contrary, non-free drivers > depend on ndiswrapper to operate correctly on Linux. Exactly. > The usual argument that's made to allow (3) into main is to say that > it only matters what code's actually running on *your* cpu, not > elsewhere; but that seems to indicate ndiswrapper should be in > contrib. Actually, I'd say that the argument to allow (3) in main isn't meant to be used outside its context. > > The fact that there is useful free software for one of them, while not > > for the other? Shouldn't we let our users decide what's useful and what > > isn't? Otherwise, I'll declare that I don't find Windows software (_any_ > > Windows software, including free Windows software) useful, and you're > > back to square one. > > Well, fortunately what you do and don't declare doesn't matter that > much, though if you're just going to pontificate like that, this > conversation isn't going to get anywhere. What I meant was, if it's fair to say that CIPE isn't useful at all, then why is it fair to say that free Windows-software is at all useful? Personally, I think that if it doesn't run on Linux, it isn't useful. Honest. I haven't seen an argument in support of "CIPE isn't a good example" that didn't boil down to "actually it is, but because it defeats my point, I'll just claim it isn't useful". -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
signature.asc
Description: Digital signature
