At Sat, 23 Jul 2011 05:02:31 -0700, Scrap Happy <Scrap%GMX.com@localhost> wrote:
Subject: Re: Re (2): NetBSD documentation-hackathon from August 10th to August
14th
>
> But, to the client, it doesn't matter if he's paying *you* or
> someone you've subcontracted the work out to... he's still
> paying for *work* to be performed "just for him". In his mind,
> the appeal of "Linux" (or any other OSS) is that he gets
> "something for nothing" (regardless of how big a fallacy this
> is, in fact!).
I suppose that's a fair approximation of the initial naive reaction some
business folks might have when faced with such a situation, but I think
that it can be put into a bigger context such that the appeal of
something like Linux isn't quite so compelling.
The big obvious non-technical difference between NetBSD and Linux is of
course the licensing. This seems to keep coming up in these kinds of
discussions, but it seems to be a really hard thing to quantify.
Perhaps recent cases of companies suing each other (AVM vs. Cybits for
example) and a now relatively long history of companies being sued by
gpl-violations.org, etc. will help make it easier to make people more
aware of these costs.
The other mostly non-technical issue, more a similarity than a
difference between GNU/Linux and NetBSD, is that no matter which
platform one chooses there will be design and implementation trade-offs
which might equalise the costs somewhat. With NetBSD it might mean
having to do more low-level porting, but with Linux it might mean having
to rewrite something else or deal with unnecessary complexity and
overhead (look at how much effort goes into avoiding use of glibc in
some GNU/Linux-based embedded projects) or continually deal with a
fire-hose of changes in kernel upgrades.
Another big non-technical issue is the difference between NetBSD and
GNU/Linux with respect to dealing with the "vendor" so to speak. It may
be easier for a company to work with NetBSD due to the way The NetBSD
Foundation is structured and due to the way the NetBSD source and
development process is managed with core developers and appointed
committers. I've heard that working with the mainstream GNU/Linux
community is a little more hit-and-miss, especially if one is trying to
push back changes to several different parts of the GNU/Linux system.
In NetBSD there are of course similar issues with the 3rd-party software
which NetBSD includes in its distribution, but these are far fewer than
with the average GNU/Linux distribution.
> The greater the number of "supported devices", published "hacks",
> etc., the easier it is for would-be OS porters to adopt a particular
> OS (on a particular platform). That's where "Linux" is winning
> the contest (without commenting on how *good* those efforts are
> or how "worthy" the OS may be of the application!)
It's hard to think of ways to show how Linux in particular can be a bad
technical choice in a given application despite having given claims to
the contrary without really calling the Linux supporters to the carpet
and showing people how shoddy their "solutions" often are. It's a very
negative way to go about things.
These problems can go well beyond hardware support not living up to
expectations, on to deep rooted and more widespread technical problems
with choosing Linux for a project which requires further kernel work
(especially for an embedded/appliance projects). More than once I've
heard at least some resentment and dissenting comments from kernel
programmers and managers who've worked on projects which used Linux,
even from people who in other cases would and have supported the use of
Linux.
On the flip side I think it's also worth keeping in mind that with the
hoards of Linux hackers poking away at the myriad of different platforms
out there (and increasingly the hardware vendors themselves providing
Linux support directly), at least there is a reference port from which
enough hardware information can be gleaned to do a proper implementation
in NetBSD. :-) (assuming the GPL is fully upheld too of course and that
such implementations are published and/or fed back in a timely manner
into the mainstream Linux sources)
One of the things that really makes me sad in the context of GNU/Linux
vs. NetBSD (or any *BSD for that matter) is that much of the support by
hardware vendors (especially in the sever segment, but increasingly in
the embedded sector as well) seems to me to come not from some fair and
open evaluation that favoured Linux, but rather from the direct sales
and marketing efforts of large GNU/Linux support companies, such as and
especially Red Hat. FreeBSD gets more support from hardware vendors in
part due to the direct and indirect marketing efforts of the few
companies which provide FreeBSD support, but NetBSD is now more or less
limping along only on the indirect support given to The NetBSD
Foundation and that's apparently not enough to promote it to the likes
of IBM, HP, Intel, or Dell, etc. Seeing native NetBSD support in-tree
for the likes of S390 and the current POWER systems would be awesome,
but selling IBM on the idea of supporting such a port seems nearly
impossible, especially now with their apparent firm commitment to
GNU/Linux. I.e. the "sad" part is that NetBSD didn't have such a
champion at a time when it could have counted and now it seems too late.
So many hardware companies see the open-source vs. proprietary OS debate
as simply and only as GNU/Linux vs. proprietary, never anything broader.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpBzuiS2ITnJ.pgp
Description: PGP signature