From owner-freebsd-questions@FreeBSD.ORG Fri Oct 28 20:37:46 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8B75106566B for ; Fri, 28 Oct 2011 20:37:46 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id 98F7C8FC19 for ; Fri, 28 Oct 2011 20:37:46 +0000 (UTC) Received: from r56.edvax.de (port-92-195-104-16.dynamic.qsc.de [92.195.104.16]) by mx02.qsc.de (Postfix) with ESMTP id 283821DC32 for ; Fri, 28 Oct 2011 22:37:44 +0200 (CEST) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id p9SKbia7002331 for ; Fri, 28 Oct 2011 22:37:44 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Fri, 28 Oct 2011 22:37:44 +0200 From: Polytropon To: FreeBSD Message-Id: <20111028223744.4118d205.freebsd@edvax.de> In-Reply-To: <20111028160419.14aa5bb3@scorpio> References: <20111028081055.4A5B3106564A@hub.freebsd.org> <20111028063620.3b5304d2@scorpio> <20111028211254.4a29fdd7.freebsd@edvax.de> <20111028160419.14aa5bb3@scorpio> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Fast personal printing _without_ CUPS X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:37:47 -0000 On Fri, 28 Oct 2011 16:04:19 -0400, Jerry wrote: > On Fri, 28 Oct 2011 21:12:54 +0200 > Polytropon articulated: > > > So let me make this more clear: IF the hardware manufacturer > > wants to allow developers to write drivers for their hardware > > for free, THEN everything they'd have to do is to publish the > > control codes for the sheet feeder and the ink pee motors. > > Conclusion: If they don't do it, they don't want developers > > to do so. It is their RIGHT, because they own the product, > > and they may sell it under any circumstances they think will > > lead to profit. Market rules again. > > I am just going to reply to this one point because it is where you > entire argument breaks down. > > Assume Big Corporation creates a new printer known as "Printer-101" and > releases its code for any moron, sorry I meant expert to use to write > OS specific drivers for. > [...] > We haven't even touched on what happens if Big Corporation finds a > glitch with the printer and needs a modification in its firmware and > modifications to Poly's driver script. Who supplies them and what > happens when Poly disappears? Valid point, haven't thought about that yet. The implications are interesting... It does not invalidate my argumentation, but it is worth being considered. "Bad advertising" could be considered a downside in unit sales, such as it happens with GPU vendors whose cards to not work properly on Linux -- they won't get recommended for use, instead a competitor will make the sale. But the manufacturers can create that effect theirselves by releasing crappy drivers. Due to the short life of hardware, they don't seem to consider drivers an essential part of their product, as it "does break next year anyway", an attitude fully matching the current "state of the art", the throwaway society. That's why driver support is often designed towards (and limited to!) a specific kind of "Windows" (as they make the main target audience, the majority, the biggest slice of market share). Fully understandable from a corporate point of view. Shortsighted in many cases maybe, but understandable. Why invest time (and therefore, money) in developing Linux drivers when the product will be withdrawn in the next year anyway, and the amount of Linux users going to buy the product are nearly zero, so the revenue will be quite small, and in _no_ relation to the investition of developing drivers. Take USB hard disks for example. As manufacturers have decided to use _one_ plug, as well as _one_ command set, I can virtually buy any external hard disk without worrying about compatibility, and I don't need any company to develop a driver for that disk for the OS I'm using. I wish this could be the default situation with any device, be it a media player, printer+scanner, USB toy or anything else. A standard that gives a broad interface with _all_ options available so the manufacturer can invent any extraordinary functionality he wants, depending on that "tool- set". Basically, that's what their current drivers do: They take a limited set of commands (in some programming language, assembler, C, whatever is currently considere "modern" in "Windows", who knows) and implements the functionality with this _closed_ set of tools, creating something new. Why not do that with a toolset that's available anywhere, and that can be ported to any new platform? Without paying license fees and handing them over to customers, hoping on the "good will" of possible competitors who hold the licensing rights so they won't destroy the product, and maybe the whole manufacturing company? The big chance: The "Yes, it also works on ..." could increase unit sales, and the perspective for the future would be good: Without developing sets of new drivers (for different kinds of "Windows" on different architectures, {m,n}-matrix) they could state that their product will also work with future devices. Interoperability, maybe this will also be more important in the future? A unified structure that gets PROPERLY (!) implemented on different platforms could be the solution. It would not limit inventions or further development. > Check out "MOVED" in the ports. There are numerous applications that > are just abandoned or discontinued. If something breaks I want someone > to contact. I realize that is not the Open Source way however. The > thought of someone actually being responsible is rare indeed. There are companies offering support for payment, while the product they are using and promoting basically is free of charge. Maybe such a model could be adopted in such cases? > I buy my cars from known corporations and not the local chop-shop. My > drugs come form known pharmaceutical corporations and not the local > pusher. I like my device specific codes to come from those best able to > supply them, the OEM. This is what you _need_ to rely on as long as you cannot validate the products yourself. In many cases, you need very precide knowledge, maybe technology and tools, to be sure. This is _knowing_. By purchasing, you can only hope that the seller didn't lie to you. I would call that _believing_. After all, prices do _not_ imply quality! I think you can remember many "established and trusted companies" that came out with absolutely overpriced crap. Just because you _trust_ them does NOT mean that they are worth being trusted. Their goal is not to provide you a safe, ecological and easy to use car, a good medicine curing you, or a device that will do what you need. You _hope_ they do, and you often _feel_ they do, but without validation, you can't be sure. > As stated in another post, if a suitable platform were created for > manufacturers to distribute their drivers, whether it be printers, > modems, wireless devices, etcetera, the problem would be solved. I agree it's complicated, but with some consensus it sounds at least possible. In other fields it is reality (like unified plugs, unified chargers, unified rules), why not regarding drivers? > Of > course it is easier for all the non-windows based OSs to have a pissing > contest rather than create a unified front so I am confident that the > prospect of that occurring in my life time are nil. Diversity vs. unification... a discussion going to burst the list's capacity and purpose. :-) You just have to consider what's the trend at the moment, and in my experience, the trend is growing diversification, not just within the Linux and UNIX world, but also in "Windows" land, as well as among devices in general (esp. mobile market). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...